Organizacje to wielkie mechanizmy, złożone z funkcjonalnych bloków (komórki organizacyjne), te z mniejszych elementów, a te zaś wymagają zasobów: są nimi ludzie i narzędzia jakich używają, nawet te w pełni zautomatyzowane. Koszt systemów komputerowych to w 2020 roku ok. 8% przychodów firm (ok. 10% w branży finansowej). Udział ten stale rośnie, a to oznacza, że jakość tych systemów ma stale rosnący wpływ na marże i konkurencyjność firm (https://www.flexera.com/blog/technology-value-optimization/it-spending-by-industry/).

Wprowadzenie

Trzy lata temu pisałem o projektowaniu urządzeń zawierających bloki funkcjonalne realizowane przez komputer. Komputery coraz częściej (tam gdzie to tylko możliwe) zastępują swoje mechaniczne funkcjonalne odpowiedniki, zgodnie z tezą „komputer to uniwersalny mechanizm” . Poniżej publikowany wcześniej uproszczony schemat blokowy pralki. Elementy zaznaczone kolorem pomarańczowym zostały zastąpione komputerem (komputer to: procesor, pamięć, program).

Niedawno opisywałem systemowe podejście do całych organizacji pokazując ich model (tu jeden dział pionu produkcji) 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 systemów – organizacja jako mechanizm – Jarosław Żeliński IT-Consulting

Oprogramowanie „w czymś” czyli embedded software

Pod pojęciem „oprogramowanie wbudowane” (ang. embedded software) rozumiemy:

Oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika, ale jest częścią systemu. Na przykład oprogramowanie osadzone jest w telewizorach, samolotach i grach wideo. Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.

Autor zwraca uwagę, że jest to „oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika” jednak w drugiej części zdania generalizuje, że to oprogramowanie, które „jest częścią systemu”. W streszczeniu pisze:

Nauka o obliczeniach systematycznie abstrahowała od świata fizycznego. Systemy oprogramowania wbudowanego, jednakże, angażują świat fizyczny. […] Obowiązujące abstrakcje systemów obliczeniowych pomijają „niefunkcjonalne” aspekty. [wyjaśniamy] dlaczego oprogramowanie wbudowane nie jest tylko oprogramowaniem na małe komputery i dlaczego potrzebuje fundamentalnie nowego spojrzenia […]. [autor] Proponuje architektury komponentów oparte na zasadzie zwanej „projektowaniem zorientowanym na aktora” […]. Następnie sugeruje, że aktorzy mogą definiować interfejsy, które deklarują dynamiczne aspekty, które są istotne dla oprogramowania wbudowanego […]. Te interfejsy mogą być zorganizowane w „system”, który wspiera rodzaj sprawdzania w czasie projektowania i w czasie działania, z którego korzysta konwencjonalne oprogramowanie.

Tu już widać ogólniejsze, i zorientowane na użytkownika, podejście bardziej „holistyczne”. Najczęściej nadal jednak pod pojęciem oprogramowanie wbudowane uznajemy, że „Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.” co oczywiście jest prawdą.

Rosnący udział oprogramowania w urządzeniach pokazano na poniższym wykresie:

Jak widać funkcje realizowane przez oprogramowanie stanowią co najmniej 80% całości kosztów. Tu autorzy badali co prawda roboty przemysłowe, jednak jak już wspomniano oprogramowanie wbudowane jest także „osadzone jest w telewizorach, samolotach i grach wideo” . Wystarczy spojrzeć na smartfon, który jako telefon, był kiedyś w 100% urządzeniem elektromechanicznym, później elektronicznym, obecnie jest to system składający się z urządzeń peryferyjnych (nadajnik, odbiornik, głośnik, ekran video, zasilacz) . Trend nie jest taki nowy . Więcej .

Robert C. Martin, w swojej książce Czysta Architektura , wskazuje na konieczność projektowania oprogramowania w taki sam sposób jak urządzenia i firmy, którego jest ono częścią (patrz rozdz. 29: Clean Embedded Architecture).

Oprogramowanie w organizacji

Do napisania tego artykułu skłonił mnie wpis „Software ? the Elephant in the MBSE Living Room” Douga Rosenberga (tak, to między innymi ten od ICONIX) . „Słoń w pokoju” to popularny w j. angielskim idiom oznaczający

?? ważny lub ogromny temat, pytanie lub kontrowersyjna kwestia, o której wszyscy wiedzą, ale nikt o niej nie wspomina lub nie chce o niej rozmawiać, ponieważ sprawia, że przynajmniej niektórzy z nich czują się niekomfortowo ??

https://dictionary.cambridge.org/dictionary/english/elephant-in-the-room

W naszym języku popularnie mówi się „temat tabu” lub, zależnie od kontekstu, „temat zamiatany pod dywan”. Takim tematem jest oprogramowanie jako część czegoś większego. Dlaczego to taki temat tabu? Moim zdaniem dlatego, że od dekad wmawiano nam, że oprogramowanie (inżynieria oprogramowania) rządzi sie jakimiś innymi prawami niż „klasyczne inżynierie”. Mamy rok 2023 i okazuje, że raczej nie, i okazuje się że dowodem jest to, że oprogramowanie zawsze jest częścią czegoś większego, a ta większa część to nic innego jak produkt „tradycyjnej inżynierii”. Skoro więc pralka, telefon, telewizor czy samolot powstają w cyklu: wymagania, projekt, testy, prototyp, produkcja, to znaczy, że rygor ten dotyczy także każdej części składowej: komputera z jego oprogramowaniem także. Trudno będzie przekonać np. producenta samolotów, że Auto Pilot (obecnie komputer), będzie powstał z pominięciem któregokolwiek z tych etapów.

Takim nadrzędnym bytem dla oprogramowania jest także każda firma, urząd itp. Nigdzie oprogramowanie nie jest samodzielnym wolnostojącymi bytem, organizację inwestują w „oprogramowanie wspomagające zarządzanie”. Innymi słowy, każdy system informatyczny to coś co zastępuje urządzenie (jego fragment) lub w człowieka, w pracach możliwych do opisania (model) określonym mechanizmem.

Wbrew temu co wielu ludzi pisze, organziacje sa i będa silosami z prostego powodu: i ekonomia i organizacje, i urządzenia, i ludzie są zorganizowane zasobowo. Patrząc na to: organizacje budują ekonomię, a ludzie i ich narzędzia budują organizacje. Więc gdzie są te mityczne procesy? To nic innego ja spojrzenie na silosy z perspektywy tego, co i w jakiej kolejności powstaje wewnątrz organizacji. Każdy elementarny proces biznesowy to nic innego jak produkt wytworzony z pomocą określonego zasobu: ludzi i ich narzędzi. To dlatego każdy system modelowany z użyciem notacji UML/SysML, jest modelowany z perspektywy swojej wewnętrznej struktury (architektura systemu) oraz z perspektywy zachowań siebie i swoim komponentów.

Poniżej, bardzo dobrze znany diagram opisujący wewnętrzny łańcuch wartości: kluczowe procesy biznesowe i zasoby w firmie.

Warto tu zwrócić uwagę na to, że wyraźnie oddzielono część operacyjną od części zabezpieczającej zasoby. Warto także zwrócić uwagę że to silosy. Modelując np. firmę skorzystamy z poniższego jej metamodelu: każda firma podzielona jest (składa się z) na komórki organizacyjne, te zaś grupują ludzi i ich narzędzia (zasoby):

Mając zdefiniowane typy bloków systemu jakim jest firma, można zbudowac jej model:

Na powyższym modelu pokazano kluczowe bloki funkcjonalne czyli komórki organizacyjne. Pełny model tej firmy byłby bogatszy, jednak byłaby to hierarchia kilku czytelnych diagramów. Tak zobrazowane przepływy pokazują mechanizm działania firmy jako systemu. Na kolejnych modelach, od ogółu do szczegółu, można pokazać nawet poszczególne stanowiska produkcyjne (tak zwane cele). Na innych modelach, w tej samej notacji ale z innej perspektywy, można pokazać strukturę produktów do modelowania BOM. Te modele to nie są modele procesów biznesowych, to modele organizacji z perspektywy mechanizmu jej działania. Pamiętajmy, że model np. samochodu czy nawet całej ich floty, nie jest modelem korporacji taksówkowej.

A gdzie procesy biznesowe? Osobno, na kolejny kilku prostych modelach BPMN przepływ pracy rozumiany jako odbierane, tworzone i wysyłane dokumenty. A wszystko to powiązane „śladowaniem” czyli macierzami pokazującymi związki zasobów z procesami, dokumentami itp. Pamietajmy, że np. na produkcji fizycznie przemieszczają określone np. dobra konsumpcyjne a zupełnie osobne dowody księgowe (dokumenty) opisujące gdzie i do czego doszło. Nie da sie na jednym diagraie (typie diagramu) pokazać na raz wszystkiego.

Bardzo ważne jest dobieranie właściwych metod i narzędzie modelowania (notacja, paradygmat) do celu jaki chcemy zrealizować w toku przygotowania do wdrożenia. Tam gdzie mamy do czynienia z dokumentami tworzymy analityczne modele z użyciem notacji BPMN (np. obszar finansów, sprzedaży, itp.). Tam gdzie mamy do czynienia z projektowaniem produktów CAD/CAM ich produkcją (dowolny poziom) stosujemy modele systemowe MBSE i notacje SysML (np. systemy MES, PLM, tu warto znać podstawy normy ISA-95). Tam gdzie chcemy modelować blok będący komputerem wraz z oprogramowaniem (wymagania na oprogramowanie), stosujemy UML .

Poniżej poglądowy schemat tych zależności:

A gdzie gdzie jest słoń?

Popatrzmy na kolejny poniższy diagram:

Nasz słoń jest tu zasobem: to komputer i oprogramowanie. Systemy IT to integralna część organizacji: to nasze „oprogramowanie wbudowane” w nią. Każdy podsystem np. FK, workflow, WMS czy MES, to takie właśnie „embedded systems” firmy, i nie ma żadnego uzasadnienia do traktowanie tych systemów inaczej niż pozostałych zasobów. Innymi słowy: nie należy patrzeć na oprogramowanie ERP jak na „coś innego”, oprogramowanie jest integralną częścią nadrzędnego bytu jakim jest organizacja.

Podsumowanie

Powoli kończy się era „świętych krów” inżynierii. Inżynieria oprogramowania, po prawie 20 latach „zwinnego” podejścia do tej gałęzi inżynierii, zaczyna dojrzewać do bycia „prawdziwą inżynieria” z analizami, projektowaniem i testowaniem na „desce kreślarskiej”, jaką są systemy CASE i podejście MBSE, jakimi stanowią uniwersalne systemowe podejście do multidyscyplinarnej inżynierii (mechatromnika) .

Organizacje to też systemy i ich inżynieria: mamy inżynierię procesów biznesowych, inżynierię zasobów, inżynierie finansową. Organizacje to systemy i tak należy je traktować i modelować . Koszty utrzymania i rozwoju systemów IT to już ponad 8% przychodów firmy i wartość ta powoli ale nadal stale rośnie. Rośnie także dyscyplina ich tworzenia, wdrażania i zarządzania ich kosztami.

Żródla