Organizacje to wiel­kie mecha­ni­zmy, zło­żo­ne z funk­cjo­nal­nych blo­ków (komór­ki orga­ni­za­cyj­ne), te z mniej­szych ele­men­tów, a te zaś wyma­ga­ją zaso­bów: są nimi ludzie i narzę­dzia jakich uży­wa­ją, nawet te w peł­ni zauto­ma­ty­zo­wa­ne. Koszt sys­te­mów kom­pu­te­ro­wych to w 2020 roku ok. 8% przy­cho­dów firm (ok. 10% w bran­ży finan­so­wej). Udział ten sta­le rośnie, a to ozna­cza, że jakość tych sys­te­mów ma sta­le rosną­cy wpływ na mar­że i kon­ku­ren­cyj­ność firm (https://​www​.fle​xe​ra​.com/​b​l​o​g​/​t​e​c​h​n​o​l​o​g​y​-​v​a​l​u​e​-​o​p​t​i​m​i​z​a​t​i​o​n​/​i​t​-​s​p​e​n​d​i​n​g​-​b​y​-​i​n​d​u​s​t​ry/).

Wstęp

Trzy lata temu pisa­łem o pro­jek­to­wa­niu urzą­dzeń zawie­ra­ją­cych blo­ki funk­cjo­nal­ne reali­zo­wa­ne przez kom­pu­ter. Komputery coraz czę­ściej (tam gdzie to tyl­ko moż­li­we) zastę­pu­ją swo­je mecha­nicz­ne funk­cjo­nal­ne odpo­wied­ni­ki, zgod­nie z tezą ​„kom­pu­ter to uni­wer­sal­ny mecha­nizm” . Poniżej publi­ko­wa­ny wcze­śniej uprosz­czo­ny sche­mat blo­ko­wy pral­ki. Elementy zazna­czo­ne kolo­rem poma­rań­czo­wym zosta­ły zastą­pio­ne kom­pu­te­rem (kom­pu­ter to: pro­ce­sor, pamięć, program). 

Niedawno opi­sy­wa­łem sys­te­mo­we podej­ście do całych orga­ni­za­cji poka­zu­jąc ich model (tu jeden dział pio­nu pro­duk­cji) w duchu MBSE :

Artykuł powyż­szy koń­czy­łem słowami:

Czym są więc wyma­ga­nia na opro­gra­mo­wa­nie? To ta część mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, któ­rą chce­my zacząć reali­zo­wać jako dzia­ła­ją­ce opro­gra­mo­wa­nie lub jego ele­ment. Wymagania na opro­gra­mo­wa­nie to nie są cele użyt­kow­ni­ków! Wymagania na opro­gra­mo­wa­nie to mecha­nizm ich osiągania.

źr.: Modelowanie sys­te­mów – orga­ni­za­cja jako mecha­nizm – Jarosław Żeliński IT-Consulting

Oprogramowanie ​„w czymś” czyli embedded software

Pod poję­ciem ​„opro­gra­mo­wa­nie wbu­do­wa­ne” (ang. embed­ded softwa­re) rozumiemy:

Oprogramowanie wbu­do­wa­ne to opro­gra­mo­wa­nie, któ­re nie jest bez­po­śred­nio widocz­ne lub wywo­ły­wa­ne przez ludz­kie­go użyt­kow­ni­ka, ale jest czę­ścią sys­te­mu. Na przy­kład opro­gra­mo­wa­nie osa­dzo­ne jest w tele­wi­zo­rach, samo­lo­tach i grach wideo. Oprogramowanie wbu­do­wa­ne jest uży­wa­ne do ste­ro­wa­nia funk­cja­mi urzą­dzeń sprzętowych.

Autor zwra­ca uwa­gę, że jest to ​„opro­gra­mo­wa­nie wbu­do­wa­ne to opro­gra­mo­wa­nie, któ­re nie jest bez­po­śred­nio widocz­ne lub wywo­ły­wa­ne przez ludz­kie­go użyt­kow­ni­ka” jed­nak w dru­giej czę­ści zda­nia gene­ra­li­zu­je, że to opro­gra­mo­wa­nie, któ­re ​„jest czę­ścią sys­te­mu”. W stresz­cze­niu pisze:

Nauka o obli­cze­niach sys­te­ma­tycz­nie abs­tra­ho­wa­ła od świa­ta fizycz­ne­go. Systemy opro­gra­mo­wa­nia wbu­do­wa­ne­go, jed­nak­że, anga­żu­ją świat fizycz­ny. […] Obowiązujące abs­trak­cje sys­te­mów obli­cze­nio­wych pomi­ja­ją ​„nie­funk­cjo­nal­ne” aspek­ty. [wyja­śnia­my] dla­cze­go opro­gra­mo­wa­nie wbu­do­wa­ne nie jest tyl­ko opro­gra­mo­wa­niem na małe kom­pu­te­ry i dla­cze­go potrze­bu­je fun­da­men­tal­nie nowe­go spoj­rze­nia […]. [autor] Proponuje archi­tek­tu­ry kom­po­nen­tów opar­te na zasa­dzie zwa­nej ​„pro­jek­to­wa­niem zorien­to­wa­nym na akto­ra” […]. Następnie suge­ru­je, że akto­rzy mogą defi­nio­wać inter­fej­sy, któ­re dekla­ru­ją dyna­micz­ne aspek­ty, któ­re są istot­ne dla opro­gra­mo­wa­nia wbu­do­wa­ne­go […]. Te inter­fej­sy mogą być zor­ga­ni­zo­wa­ne w ​„sys­tem”, któ­ry wspie­ra rodzaj spraw­dza­nia w cza­sie pro­jek­to­wa­nia i w cza­sie dzia­ła­nia, z któ­re­go korzy­sta kon­wen­cjo­nal­ne oprogramowanie.

Tu już widać ogól­niej­sze, i zorien­to­wa­ne na użyt­kow­ni­ka, podej­ście bar­dziej ​„holi­stycz­ne”. Najczęściej nadal jed­nak pod poję­ciem opro­gra­mo­wa­nie wbu­do­wa­ne uzna­je­my, że ​„Oprogramowanie wbu­do­wa­ne jest uży­wa­ne do ste­ro­wa­nia funk­cja­mi urzą­dzeń sprzę­to­wych.” co oczy­wi­ście jest prawdą. 

Rosnący udział opro­gra­mo­wa­nia w urzą­dze­niach poka­za­no na poniż­szym wykresie:

Jak widać funk­cje reali­zo­wa­ne przez opro­gra­mo­wa­nie sta­no­wią co naj­mniej 80% cało­ści kosz­tów. Tu auto­rzy bada­li co praw­da robo­ty prze­my­sło­we, jed­nak jak już wspo­mnia­no opro­gra­mo­wa­nie wbu­do­wa­ne jest tak­że ​„osa­dzo­ne jest w tele­wi­zo­rach, samo­lo­tach i grach wideo” . Wystarczy spoj­rzeć na smart­fon, któ­ry jako tele­fon, był kie­dyś w 100% urzą­dze­niem elek­tro­me­cha­nicz­nym, póź­niej elek­tro­nicz­nym, obec­nie jest to sys­tem skła­da­ją­cy się z urzą­dzeń pery­fe­ryj­nych (nadaj­nik, odbior­nik, gło­śnik, ekran video, zasi­lacz) . Trend nie jest taki nowy . Więcej .

Oprogramowanie w organizacji

Do napi­sa­nia tego arty­ku­łu skło­nił mnie wpis ​„Software ? the Elephant in the MBSE Living Room” Douga Rosenberga (tak, to mię­dzy inny­mi ten od ICONIX) . ​„Słoń w poko­ju” to popu­lar­ny w j. angiel­skim idiom oznaczający 

?? waż­ny lub ogrom­ny temat, pyta­nie lub kon­tro­wer­syj­na kwe­stia, o któ­rej wszy­scy wie­dzą, ale nikt o niej nie wspo­mi­na lub nie chce o niej roz­ma­wiać, ponie­waż spra­wia, że przy­naj­mniej nie­któ­rzy z nich czu­ją się niekomfortowo ??

https://​dic​tio​na​ry​.cam​brid​ge​.org/​d​i​c​t​i​o​n​a​r​y​/​e​n​g​l​i​s​h​/​e​l​e​p​h​a​n​t​-​i​n​-​t​h​e​-​r​oom

W naszym języ­ku popu­lar­nie mówi się ​„temat tabu” lub, zależ­nie od kon­tek­stu, ​„temat zamia­ta­ny pod dywan”. Takim tema­tem jest opro­gra­mo­wa­nie jako część cze­goś więk­sze­go. Dlaczego to taki temat tabu? Moim zda­niem dla­te­go, że od dekad wma­wia­no nam, że opro­gra­mo­wa­nie (inży­nie­ria opro­gra­mo­wa­nia) rzą­dzi sie jaki­miś inny­mi pra­wa­mi niż ​„kla­sycz­ne inży­nie­rie”. Mamy rok 2023 i oka­zu­je, że raczej nie, i oka­zu­je się że dowo­dem jest to, że opro­gra­mo­wa­nie zawsze jest czę­ścią cze­goś więk­sze­go, a ta więk­sza część to nic inne­go jak pro­dukt ​„tra­dy­cyj­nej inży­nie­rii”. Skoro więc pral­ka, tele­fon, tele­wi­zor czy samo­lot powsta­ją w cyklu: wyma­ga­nia, pro­jekt, testy, pro­to­typ, pro­duk­cja, to zna­czy, że rygor ten doty­czy tak­że każ­dej czę­ści skła­do­wej: kom­pu­te­ra z jego opro­gra­mo­wa­niem tak­że. Trudno będzie prze­ko­nać np. pro­du­cen­ta samo­lo­tów, że Auto Pilot (obec­nie kom­pu­ter), będzie powstał z pomi­nię­ciem któ­re­go­kol­wiek z tych etapów. 

Takim nad­rzęd­nym bytem dla opro­gra­mo­wa­nia jest tak­że każ­da fir­ma, urząd itp. Nigdzie opro­gra­mo­wa­nie nie jest samo­dziel­nym wol­no­sto­ją­cy­mi bytem, orga­ni­za­cję inwe­stu­ją w ​„opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie”. Innymi sło­wy, każ­dy sys­tem infor­ma­tycz­ny to coś co zastę­pu­je urzą­dze­nie (jego frag­ment) lub w czło­wie­ka, w pra­cach moż­li­wych do opi­sa­nia (model) okre­ślo­nym mechanizmem. 

Wbrew temu co wie­lu ludzi pisze, organ­zia­cje sa i będa silo­sa­mi z pro­ste­go powo­du: i eko­no­mia i orga­ni­za­cje, i urzą­dze­nia, i ludzie są zor­ga­ni­zo­wa­ne zaso­bo­wo. Patrząc na to: orga­ni­za­cje budu­ją eko­no­mię, a ludzie i ich narzę­dzia budu­ją orga­ni­za­cje. Więc gdzie są te mitycz­ne pro­ce­sy? To nic inne­go ja spoj­rze­nie na silo­sy z per­spek­ty­wy tego, co i w jakiej kolej­no­ści powsta­je wewnątrz orga­ni­za­cji. Każdy ele­men­tar­ny pro­ces biz­ne­so­wy to nic inne­go jak pro­dukt wytwo­rzo­ny z pomo­cą okre­ślo­ne­go zaso­bu: ludzi i ich narzę­dzi. To dla­te­go każ­dy sys­tem mode­lo­wa­ny z uży­ciem nota­cji UML/SysML, jest mode­lo­wa­ny z per­spek­ty­wy swo­jej wewnętrz­nej struk­tu­ry (archi­tek­tu­ra sys­te­mu) oraz z per­spek­ty­wy zacho­wań sie­bie i swo­im komponentów. 

Poniżej, bar­dzo dobrze zna­ny dia­gram opi­su­ją­cy wewnętrz­ny łań­cuch war­to­ści: klu­czo­we pro­ce­sy biz­ne­so­we i zaso­by w firmie. 

Warto tu zwró­cić uwa­gę na to, że wyraź­nie oddzie­lo­no część ope­ra­cyj­ną od czę­ści zabez­pie­cza­ją­cej zaso­by. Warto tak­że zwró­cić uwa­gę że to silo­sy. Modelując np. fir­mę sko­rzy­sta­my z poniż­sze­go jej meta­mo­de­lu: każ­da fir­ma podzie­lo­na jest (skła­da się z) na komór­ki orga­ni­za­cyj­ne, te zaś gru­pu­ją ludzi i ich narzę­dzia (zaso­by):

Mając zde­fi­nio­wa­ne typy blo­ków sys­te­mu jakim jest fir­ma, moż­na zbu­do­wac jej model:

Na powyż­szym mode­lu poka­za­no klu­czo­we blo­ki funk­cjo­nal­ne czy­li komór­ki orga­ni­za­cyj­ne. Pełny model tej fir­my był­by bogat­szy, jed­nak była­by to hie­rar­chia kil­ku czy­tel­nych dia­gra­mów. Tak zobra­zo­wa­ne prze­pły­wy poka­zu­ją mecha­nizm dzia­ła­nia fir­my jako sys­te­mu. Na kolej­nych mode­lach, od ogó­łu do szcze­gó­łu, moż­na poka­zać nawet poszcze­gól­ne sta­no­wi­ska pro­duk­cyj­ne (tak zwa­ne cele). Na innych mode­lach, w tej samej nota­cji ale z innej per­spek­ty­wy, moż­na poka­zać struk­tu­rę pro­duk­tów do mode­lo­wa­nia BOM. Te mode­le to nie są mode­le pro­ce­sów biz­ne­so­wych, to mode­le orga­ni­za­cji z per­spek­ty­wy mecha­ni­zmu jej dzia­ła­nia. Pamiętajmy, że model np. samo­cho­du czy nawet całej ich flo­ty, nie jest mode­lem kor­po­ra­cji taksówkowej.

A gdzie pro­ce­sy biz­ne­so­we? Osobno, na kolej­ny kil­ku pro­stych mode­lach BPMN prze­pływ pra­cy rozu­mia­ny jako odbie­ra­ne, two­rzo­ne i wysy­ła­ne doku­men­ty. A wszyst­ko to powią­za­ne ​„śla­do­wa­niem” czy­li macie­rza­mi poka­zu­ją­cy­mi związ­ki zaso­bów z pro­ce­sa­mi, doku­men­ta­mi itp. Pamietajmy, że np. na pro­duk­cji fizycz­nie prze­miesz­cza­ją okre­ślo­ne np. dobra kon­sump­cyj­ne a zupeł­nie osob­ne dowo­dy księ­go­we (doku­men­ty) opi­su­ją­ce gdzie i do cze­go doszło. Nie da sie na jed­nym dia­gra­ie (typie dia­gra­mu) poka­zać na raz wszystkiego.

Bardzo waż­ne jest dobie­ra­nie wła­ści­wych metod i narzę­dzie mode­lo­wa­nia (nota­cja, para­dyg­mat) do celu jaki chce­my zre­ali­zo­wać w toku przy­go­to­wa­nia do wdro­że­nia. Tam gdzie mamy do czy­nie­nia z doku­men­ta­mi two­rzy­my ana­li­tycz­ne mode­le z uży­ciem nota­cji BPMN (np. obszar finan­sów, sprze­da­ży, itp.). Tam gdzie mamy do czy­nie­nia z pro­jek­to­wa­niem pro­duk­tów CAD/CAM ich pro­duk­cją (dowol­ny poziom) sto­su­je­my mode­le sys­te­mo­we MBSE i nota­cje SysML (np. sys­te­my MES, PLM, tu war­to znać pod­sta­wy nor­my ISA-95). Tam gdzie chce­my mode­lo­wać blok będą­cy kom­pu­te­rem wraz z opro­gra­mo­wa­niem (wyma­ga­nia na opro­gra­mo­wa­nie), sto­su­je­my UML .

Poniżej poglą­do­wy sche­mat tych zależności:

A gdzie gdzie jest słoń?

Popatrzmy na kolej­ny poniż­szy diagram:

Nasz słoń jest tu zaso­bem: to kom­pu­ter i opro­gra­mo­wa­nie. Systemy IT to inte­gral­na część orga­ni­za­cji: to nasze ​„opro­gra­mo­wa­nie wbu­do­wa­ne” w nią. Każdy pod­sys­tem np. FK, work­flow, WMS czy MES, to takie wła­śnie ​„embed­ded sys­tems” fir­my, i nie ma żad­ne­go uza­sad­nie­nia do trak­to­wa­nie tych sys­te­mów ina­czej niż pozo­sta­łych zaso­bów. Innymi sło­wy: nie nale­ży patrzeć na opro­gra­mo­wa­nie ERP jak na ​„coś inne­go”, opro­gra­mo­wa­nie jest inte­gral­ną czę­ścią nad­rzęd­ne­go bytu jakim jest organizacja. 

Podsumowanie

Powoli koń­czy się era ​„świę­tych krów” inży­nie­rii. Inżynieria opro­gra­mo­wa­nia, po pra­wie 20 latach ​„zwin­ne­go” podej­ścia do tej gałę­zi inży­nie­rii, zaczy­na doj­rze­wać do bycia ​„praw­dzi­wą inży­nie­ria” z ana­li­za­mi, pro­jek­to­wa­niem i testo­wa­niem na ​„desce kre­ślar­skiej”, jaką są sys­te­my CASE i podej­ście MBSE, jaki­mi sta­no­wią uni­wer­sal­ne sys­te­mo­we podej­ście do mul­ti­dy­scy­pli­nar­nej inży­nie­rii (mecha­trom­ni­ka) .

Organizacje to też sys­te­my i ich inży­nie­ria: mamy inży­nie­rię pro­ce­sów biz­ne­so­wych, inży­nie­rię zaso­bów, inży­nie­rie finan­so­wą. Organizacje to sys­te­my i tak nale­ży je trak­to­wać i mode­lo­wać . Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów IT to już ponad 8% przy­cho­dów fir­my i war­tość ta powo­li ale nadal sta­le rośnie. Rośnie tak­że dys­cy­pli­na ich two­rze­nia, wdra­ża­nia i zarzą­dza­nia ich kosztami. 

Żródla