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. 

Łańcuch wartości M.E.Porter
Łańcuch war­to­ści M.E.Porter

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):

Firma, dia­gram defi­ni­cji blo­ków SysML.

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:

Poglądowy model fir­my pro­duk­cyj­nej (nota­cja SysML, opra­co­wa­nie autora)

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:

Model systemu służy do określenia składników systemu.

A gdzie gdzie jest słoń?

Popatrzmy na kolej­ny poniż­szy diagram:

Model dzia­łu pro­duk­cji (nota­cja SysML, opra­co­wa­nie autora)

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. 

Z per­spek­ty­wy orga­ni­za­cji i ryn­ku, opro­gra­mo­wa­nie wbu­do­wa­ne to jest to opro­gra­mo­wa­nie, któ­re­go uży­wa się wewnątrz fir­my ale któ­re­go nie widzą, nie mają z nim kon­tak­tu, klien­ci tej firmy. 

Żródla

Crnkovic, I., Mustapi, M., & Åkerholm, M. (2003). Modern Technologies for Modeling and Development of Process Information Systems.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml
Graaf, B., Lormans, M., & Toetenel, H. (2003). Embedded Software Engineering: The State of the Practice. Software, IEEE, 20, 61 – 69. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​3​.​1​2​4​1​368
Harjunkoski, I., & Bauer, R. (2014). Sharing Data for Production Scheduling Using the ISA-95 Standard. Frontiers in Energy Research, 2. https://​doi​.org/​1​0​.​3​3​8​9​/​f​e​n​r​g​.​2​0​1​4​.​0​0​044
Koźmiński, A. K. (1979). Decyzje: ana­li­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Lee, E. A. (2002). Embedded Software. In M. V. Zelkowitz (Ed.), Advances in Computers (Vol. 56, pp. 55 – 95). Elsevier. https://​doi​.org/​1​0​.​1​0​1​6​/​S​0​0​6​5​-​2​4​5​8​(​0​2​)​8​0​004 – 3
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Szilárd Jaskóa, Adrienn Skropa, Tibor Holczingera, Tibor Chovánb, & János Abonyib. (2020). Development of manu­fac­tu­ring exe­cu­tion sys­tems in accor­dan­ce with Industry 4.0 requ­ire­ments: A review of stan­dard- and onto­lo­gy-based metho­do­lo­gies and tools | Elsevier Enhanced Reader. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​c​o​m​p​i​n​d​.​2​0​2​0​.​1​0​3​300

Jarosław Żeliński

Masz pytania to treści artykułu, potrzebujesz pomocy? Kliknij tu! BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.