Wprowadzenie

Pojęcie ‘system’ stało się bardzo popularne, głównie za sprawą “systemów informatycznych”, jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii [zotpressInText item=”{5085975:CHQUCPGA}”]. Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system:

1. układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość
2. zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość
3. narządy lub inne części żywego organizmu pełniące razem określoną funkcję
4. uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię
5. określony sposób wykonywania jakiejś czynności lub zasady organizacji czegoś
6. forma ustroju państwowego
7. zespół skał powstałych w ciągu jednego okresu geologicznego
8. log. całościowy i uporządkowany zespół zdań połączonych ze sobą stosunkami logicznego wynikania

Jak widać jest to pojęcie bardzo uniwersalne dziedzinowo, jednak generalnie wszystkie te definicje to szczególne rodzaje tej pierwszej. My skupimy sie na pierwszych dwóch: pierwsza z uwagi na jej ogólność, druga z uwagi na fakt, że komputer to system będący urządzeniem, a w zasadzie zespołem urządzeń.

Organizacje, firmy w szczególności, to złożone “systemy systemów”. Poniżej model firmy po raz pierwszy opublikowany w 1985 roku:

Model ten jest nada aktualny i wykładany na studiach MBA. Pokazuje, że żadna firma nie jest organizacyjnym monolitem.

w 1998 roku M.E.Porter, w kolejnym wydaniu swojej książki [zotpressInText item=”{5085975:9MPPQESP}”], dodał rozdział o systemach informatycznych, w którym zwrócił uwagę na to, że system informatyczny firmy powinien architektonicznie odpowiadać wyżej zobrazowanej strukturze firmy, jeżeli to wystąpi zjawisko tak zwanego “niedopasowania oporu” czyli niezgodność systemu jakim jest firma, z systemem jakim jest oprogramowanie ją wspierające.

Teza jakoby monolityczny system informatyczny, z jedną centralną bazą danych, był adekwatny dla firm, już wtedy została praktycznie obalona (najbardziej znane dziś systemy ERP powstały znacznie przed 1998 roku, do tej pory rozwijana jest jedynie technologia ich implementacji a nie architektura, to dlatego ich kompleksowe wdrażanie to od wielu lat serie porażek).

Z książki Portera można wyciągnąć ważny wniosek: system informatyczny powinien stanowić odwzorowanie ww. procesów z tą uwagą, że procesy wspierające, jako najczęściej regulowane prawem, nie budujące przewagi rynkowej, i z tego powodu rzadko będące także tajemnicą przedsiębiorstwa, powinny (mogą być) wspierane jedną standardową aplikacją. Pozostałe, jako unikalny w każdej firmie proces operacyjny (na schemacie Primary), powinny być wspierane przez samodzielne, dedykowane dziedzinowo, zintegrowane na poziomie logiki przepływu danych, aplikacje.

Ten artykuł to wyjaśnienie czym jest tak zwany “system systemów” [zotpressInText item=”{5085975:5B9ZHAYU}”] i jak sie to ma do firm. Zainteresowanym polecam także [zotpressInText item=”{5085975:78G4HG9Z}”]. Poniżej troszkę teorii, praktyki i przykładów.

Modele i meta-modele

Pojęcie model i meta-model jest bardzo ważne zarówno w analizach jak i w modelowaniu systemów. Słownik języka polskiego definiuje pojęcie model jako (w naszym obszarze dziedzinowym): ?konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu?. Przedrostek meta- oznacza: ?pierwszy człon wyrazów złożonych wskazujący na wyższy stopień, następstwo lub zmienność czegoś?.

Modelowanie jest ważne, jednak wiele modeli, pozbawionych ich meta-modeli, jest wadliwa gdyż ich tworzenie i jednoznaczna interpretacja mogą być niemożliwe [zotpressInText item=”{5085975:3PJSCD8F},{5085975:4U34KY6A}”]. OMG.org publikuje specyfikację MOF, o której już pisałem. Jest to standardowy opis warstw abstrakcji, modelowania i meta-modelowania:

Schemat powyższy obrazuje podstawowe cztery poziomy abstrakcji. Licząc od dołu mamy:

• M0 – warstwa podstawowa, jest to to co jest (może być) modelowane: realny świat, urządzenie, system aktów prawnych, działające oprogramowanie w pamięci komputera, komputer, itp. na tym poziomie mówimy o obiektach (entity), to realne byty.
• M1 – jest to model świata istniejącego w warstwie M0, tu byty rzeczywiste są reprezentowane z pomoca absgtrakcyjnych, prostych symboli na schematach blokowych (jeden do jednego: symbol – obiekt rzeczywisty).
• M2 – jest to meta-model wartswy M0, są to klasy (typy) elementów z jaki zbudowany jest świat M0.
• M3 – jest to meta-meta-model, są to definicje pojęć, użytych do powstania metamodelu, jest to np. definicja notacji, jakiej użyjemy to modelowania warstwy M2.

Warstwa M0 to analizowany świat (system). Warstwa M3 to metoda modelowania (typy elementów na diagramach modeli). Warstwa M2 i M1 to np. modele w notacji UML (i jej pochodnych): M2 to diagramy klas a M1 to diagramy obiektów (specyfikacje instancji tych klas). W dalszej części będziemy korzystali z warstw udostępnianych przez UML.

Notacja SysML

Notacja UML jest bardzo nadmiarowa, jako Unified Modeling Language (Ujednolicony Język Modelowania) jest ogólna, i nie precyzuje zastosowania swoich elementów, specyfikuje ich znaczenie (np. klasa ma swoją definicję w UML, ale to czy użyjemy pojęcia klasy do modelowania komponentów, ich interfejsów, czy systemu pojęć, to samodzielna decyzja użytkownika UML). UML niesie z sobą piętno inżynierii oprogramowania, gdyż pierwotnie notacja ta powstała jako narzędzie służące do projektowania w inżynierii oprogramowania. Jednak szybko odkryto, że pojęcia modeli i meta-modeli są bardzo przydatne, więc schematy blokowe w tej notacji zaczęły dominować w publikacjach traktujących o systemach i ich modelach. Kilka lat po opublikowaniu specyfikacji UML pojawiła się zawężona i uporządkowana specyfikacja: notacji SysML (System Modeling Language, [zotpressInText item=”{5085975:E9MDNWLY}”]), stanowiącej profil UML i jego podzbiór:

Diagramy wykorzystywane do modelowania systemów:

Notacja ta szybko zdobyła sobie uznanie w przemyśle, doskonale nadaje się do modelowania szerzej rozumianych systemów np. samochodów [zotpressInText item=”{5085975:JJUK9U4T}”], a generalnie tak zwanych urządzeń mechatronicznych, czyli złożonych elektromechanicznych urządzeń, których częścią są także komputery (więc także oprogramowanie). Korzyści ze stosowania abstrakcyjnych modeli tego typu systemów są na tyle duże, że notacja SysML staje się przemysłowym standardem w systemach zarządzania produktami i ich produkcją [zotpressInText item=”{5085975:KQHL22X8}”].

Mechanizm

Słownik języka polskiego definiuje pojęcie mechanizm jako: sposób, w jaki coś powstaje, przebiega lub działa, np. sposób działania organizacji, oprogramowania. W nauce mechanizmy są obiektami o określonych własnościach i procesami zorganizowanymi w taki sposób, że powodują one regularne zmiany, począwszy od początku, czy też warunków początkowych, aż do zakończenia działania lub warunków końcowych.

Statystycznie określona korelacja nie jest modelem mechanizmu, nie określa ona związku przyczynowo-skutkowego, jest jedynie stwierdzeniem statystycznej powtarzalności [zotpressInText item=”{5085975:LCAP9JJ4}”]. Cytując Cravera, możemy powiedzieć: ?mechanizm jest wyjaśnieniem powiązania, którego Hume szukał między przyczyną a skutkiem?, ?mechanizm zachowania jest złożonym systemem, który opisuje to zachowanie poprzez interakcję wielu komponentów, przy czym interakcję między komponentami można opisać jako związki uogólnień (generalizacji) komponentów tego systemu? [zotpressInText item=”{5085975:LKGQJ85W}”].

Tak więc model może opisywać (wyjaśniać) mechanizm powstawania czegoś (zachowania się czegoś). Innymi słowy jeżeli jakiś np. schemat blokowy coś wyjaśnia, to znaczy, że jest on modelem tego czegoś. Jeżeli to coś ma dopiero powstać, do model ten jest projektem tego czegoś. I tu pojawia się pojęcie MBSE: Model-based System Engineering.

Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone zainteresowanie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonej akceptacji MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemów.”

[zotpressInText item=”{5085975:RA6YBH48}”]

Metody określane jako MBSE sprawdzają się bardzo dobrze jako narzędzie specyfikowania wymagań, tu wymaganiem jest właśnie model czyli projekt systemu [zotpressInText item=”{5085975:63PW4WQU}”].

Systemy – analiza i modelowanie

Jak już wspomniano, komputer jest coraz częściej elementem nadrzędnej konstrukcji. Dlatego pod pojęciem ‘model systemu’ rozumiemy coś więcej niż oprogramowanie:

Praktyka pokazuje, że podejście to doskonale sprawdza się w projektowaniu systemów informatycznych, które z zasady są częścią nadrzędnego bytu, jakim jest organizacja, będąca ich (przyszłym) użytkownikiem.

W notacji SysML modele systemów są ograniczone wyłącznie do ich abstrakcji, dlatego znaczna część elementów notacji UML nie jest tu stosowana (dotyczy to głównie część UML służącej do revers-inżynierii kodu i do generowania kodu z diagramów). Mamy tu cztery filary modelowania:

1. Modele struktury, 2. modele zachowania, 3. modele wymagań, 4. Model parametryczny. Od końca:

Model parametryczny to nowy typ diagramu. Jest to narzędzie modelowania wielkości fizycznych przepływających między elementami systemu, np. przekazywany moment obrotowy wału silnika czy napięcie i prąd zasilania (ale także sygnały i komunikaty czyli informacje). Modele wymagań to strukturalna forma prezentacji potrzeb, generalnie rozumianych tu jako potrzeby interesariuszy oraz zewnętrzne cechy systemu. Modele zachowania to typowe dla UML diagramy maszyny stanowej, aktywności i sekwencji.

Modele struktury w SysML mają jednak pewną specyfikę: to co w UML jest co najwyżej “dobrą praktyką modelowania” w SysML jest obligatoryjne: deklarowanie typów elementów systemu (metamodel systemu) przed ich użyciem, zaś określony system jest instancją tego metamodelu. Pierwszy do Block Definition Diagram, drugi to Internal Block Diagram. Model parametryczny budowany jest jako uzupełnienie drugiego.

Przykady:

Powyższy diagram to dziedzinowy metamodel systemu: deklarujemy tu z jakiego typu elementów będzie (jest) zbudowany system. Jest to drzewiasta struktura dekompozycji systemu oraz jednostki miary. Konkretny system, strukturę fizyczną systemu, modelujemy jako instancję tego metamodelu:

Powyższy model to specyfikacje instancji typów elementów (klas elementów) zadeklarowanych na Diagramie Definicji Bloków. Jeżeli chcemy wyrazić wielkości fizyczne opisujące system stosujemy Diagram Parametryczny:

Diagram parametryczny pozwala uruchomić symulację systemu.

Jak modelujemy firmy

W artykule Przeciążanie BPMN czyli jak nie modelować produkcji opisałem jak modelować część produkcyjnę fabryki. Tu przedstawię nieco bardziej szerszą perspektywę [zotpressInText item=”{5085975:L53UAHAG}”].

Typy elementów to klasy (rodzaje) komponentów, urządzeń:

Typy elementów (całych bloków) deklarujemy by planować ich przyszłe wykorzystanie ale także pozyskanie (zlecenie wykonania, zakup). Typowe bloki to: napędy, sterowniki, budowle, maszyny specjalistyczne itp. Jednym z wielu jest komputer. Przypominam, że komputer to: procesor, pamięć i program. Tak więc tam gdzie pojawia się “oprogramowanie” realnie będzie to komputer i jakiś styk z nim (człowiek lub np. cyfrowo-sterowane urządzenie).

Mając zadeklarowane typy elementów możemy przystąpić do świadomego projektowania (analizy i modelowania istniejącego) zakładu:

Takie podejście pozwala opisać całość systemu jakim jest np. zakład produkcyjny [zotpressInText item=”{5085975:WGVB6SZI},{5085975:MEPY6AUS}”]. Może on zawierać maszyny, urządzenia i systemy sterujące wielu dostawców, system ERP itp. Zrozumienie i zaprojektowanie całości oszczędza ogromne ilości czasu i pieniędzy: pozwala zaprojektować nie tylko określone aplikacje, ale zaplanować to które kupić jako COTS (ang. commercial off-the-shelf, gotowe oprogramowanie dostępne na rynku), które jako zlecić jako dedykowane, zaprojektować interfejsy i od razu wszystko ładnie uruchomić. Pozwala “oczyścić” nasze pomysły z wszelkich błędów niespójności, niekompletności rozwiązania. Usuwanie błędów na etapie projektowania jest to o kilka rzędów tańsze niż ich odkrywanie i usuwanie w toku wdrożeń.

Niezależnie od tego czy chcemy zaprojektować i zrozumieć zmywarkę, samolot, czy ubojnię (tak, analizowałem taką i dokumentowałem) zawsze mamy do czynienia z czymś więcej niż tylko komputer i aplikacje biznesowe. Teza, że wdrożenia systemów ERP to tylko oprogramowanie i wymaganie na nie było może prawdziwa kilka dekad temu, teraz ‘system’ to przedsiębiorstwo a nie raz kraj (system transportu krajowego, albo planowany KseF).

Tak więc zajmując się tylko “wymaganiami na oprogramowanie”, zajmujesz się pewna małą częścią większej całości, jaką jest organizacja. To zaś oznacza, że nie masz zrozumienia wpływu tego oprogramowania na tę całość, i jest bardzo prawdopodobne, że nieświadomie szkodzisz całej tej organizacji. Jeżeli zaś jakiś dostawca, jednego z typów tych systemów, nie znając tej organizacji, uważa że jego rozwiązanie jest dobre, to po prostu nie wie co mówi.

Posiadanie takiej dokumentacji to także wiedza dla przyszłych pracowników, a nie raz chronine know-how. Bardzo często komponenty tak projektowanych systemów trafiają później celowo do różnych podwykonawców, co zapobiega ryzyku przejęcia know-how (znajomości i zrozumienia całości systemu) przez potencjalną konkurencję.

Podsumowanie

Pojęcie mechanizm jest w powszechnym użyciu, jednak w analizie i nauce ma ono specyficzne znaczenie: to wyjaśnienie działania czegoś, to abstrakcja [zotpressInText item=”{5085975:LCAP9JJ4},{5085975:LKGQJ85W}”]. Z perspektywy zarówno organizacji jak i oprogramowania, postrzeganych jako systemy, pojawia się drugie pojęcie jakim jest “to z czego system się składa” (composition) [zotpressInText item=”{5085975:IWBHW8XL}”]. Mechanizm nigdy nie jest jednym elementem, jednak jako wyjaśnienie jest abstrakcją, czyli “ukrywa” (abstrachuje od) szczegóły: mechanizm, jako opis, jest idealizacją [zotpressInText item=”{5085975:LKGQJ85W}”].

Od wielu lat do opisu organizacji stosuje się poniższy, trójwarstwowy model:

Wierzchołek to strategia organizacji, jej rola w otoczeniu w jakim sie znajduje. Dolna, trzecia warstwa, to aktualny opis tej organizacji. Tu jest “wszystko to co istnieje” (zasoby i detaliczne procedury). Środkowa warstwa to właśnie MODEL DZIAŁANIA ORGANIZACJI, abstrakcyjny opis tego “co i po co” się dzieje a nie “jak i dlaczego”.

Chcąc zrozumieć, dlaczego organizacja tak a nie inaczej się zachowuje, musimy jej opis doprowadzić do takiego poziomu abstrakcji, by możliwe było skupienie się wyłącznie na mechaniźmie jej działania. Jest to możliwe jedynie traktując organizację jako system [zotpressInText item=”{5085975:EMPAJKU9},{5085975:6J8ZX2MR}”].

Czym są więc wymagania na oprogramowanie? To ta część mechanizmu działania organizacji, którą chcemy zacząć realizować jako działające oprogramowanie lub jego element. Wymagania na oprogramowanie to nie są cele użytkowników! Wymagania na oprogramowanie to mechanizm ich osiągania.

Czy można opisać przyszły system suchym opisem dotychczasowych faktów? Nie! Trzeba go zaprojektować czyli stworzyć coś czego nie było!

Gilotyna Hume’a – nazwa problemu sformułowanego przez szkockiego filozofa Davida Hume’a dotyczącego niemożności wnioskowania, co powinno być, na podstawie tego, co jest (ang. is-ought problem).

D. Hume, A Treatise of Human Nature, Oxford, Clarendon Press 1965 (reprint I wydania), s. 469

Bo sam opis stanu obecnego i wywiady z pracownikami nie stanowią sobą przyszłych rozwiązań.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy?

Wprowadzenie

Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach [zotpressInText item=”{5085975:QJUPRFNR}”]).

A gdzie dokładny opis machania łopatą albo obsługi koparki? Ten opis to procedura, instrukcja stanowiskowa lub instrukcja obsługi urządzenia (patrz Procesy a procedury).

Do modelowania produkcji używamy notacji SysML i korzystamy z tego, że znakomita większość dzisiejszego oprogramowania wspomagającego produkcję została zbudowana w oparciu o normę ANSI ISA-95. Struktura integracji w systemach tego typu wygląda tak:

Niedawno cytowałem:

SLIM (Systems LIfecycle Management) jest śro­do­wi­skiem dla zin­te­gro­wa­nej inży­nie­rii sys­te­mów opar­tej na mode­lach, nota­cji SysML (OMG Systems Modeling Language) i pro­duk­tach PLM (Product Lifecycle Management). Dzięki temu podej­ściu inży­nie­ro­wie zło­żo­nych sys­te­mów mogą opra­co­wy­wać i zarzą­dzać wyso­ko­po­zio­mo­wą archi­tek­tu­rą systemu/produktu w SysML i jed­no­cze­śnie łączyć się, komu­ni­ko­wać i syn­chro­ni­zo­wać ze szcze­gó­ło­wy­mi wyma­ga­nia­mi, czę­ścia­mi…

Source: Inteligentna pralka czyli czym jest mechatronika – Jarosław Żeliński IT-Consulting

W czym rzecz? W tym, że produkcja to złożony system powiązanych ze sobą maszyn, obsługujących je ludzi (ale nie zawsze, bo są roboty) oraz produktów jakie powstają z ich użyciem. To co się dzieje na takiej hali to nie procesy biznesowe, hala produkcyjna to pewien złożony mechanizm wytwarzania lub przetwarzania określonych rzeczy. Wyzwaniem jest tu stworzenie modelu tej hali i tych rzeczy [zotpressInText item=”{5085975:8BLSMKW4}”]. Opisuje to między innymi specyfikacja ANSI/ISA-95 [zotpressInText item=”{5085975:3NTCEURC}”]. Na jej podstawie można także opisać jakimi danymi zarządzamy i jak integrujemy dziedzinowe podsystemy zarządzające produkcją [zotpressInText item=”{5085975:WCZIC2ZZ}”].

Norma ANSI/ISA-95

Kluczem do napisania tego artykułu jest warstwowa struktura zarządzania produkcją opisana w normie ANSI/ISA-95:

Dlatego granica między modelem procesów biznesowych (tu używamy notacji BPMN) a modelem systemu produkcji (tu używamy notacji SysML) jest granica miedzy Level 4 a Level e3. Systemy MES operują w warstwie Level 3. Śledzenie i kolekcjonowanie danych to Levels 2, 1,0. (patrz także: OPC Foundation. (2024). ISA-95 Common Object Model—4 Concept [Organisation]. OPC Foundation. https://reference.opcfoundation.org/ISA-95/v100/docs/4)

Polecam także ten krótki film:

Proces biznesowy

Zgodnie z definicją BPMN proces biznesowy to aktywność i jej produkt, złożoność aktywności nie ma znaczenia, ten symbol to abstrakcja dowolnej pracy ograniczonej materialnym (dokument) wejściem i wyjściem (więcej na stronie Notacja BPMN…).

Poniżej dwa kluczowe dla produkcji procesy biznesowe: przyjęcie zamówienia i uzupełnienie niedoboru.

Co do zasady nie łączymy tych procesów w jeden, bo liczba zamówień nie musi być równa liczbie zleceń produkcyjnych: możemy mieć produkcję na zapas, łączenie zamówień w jedno zlecenie produkcji itp.. Na to nakłada się zarządzanie partiami produkcyjnymi.

Powyższe diagramy to typowe modele analityczne procesów. Liczba aktywności nie może być większa niż liczba dokumentów lub zmiany ich statusów (zgodnie z definicją BPMN elementarny proces to aktywność i jej produkt, mogą nim dwa dokumenty, ale analitycznym modelu nie dopuszczamy aktywności bez produktu).

Proces rejestracji i weryfikacji Zamówień jest z reguły realizowany przez system ERP/MRPII: osoba odpowiedzialna za przyjmowanie zamówień rejestruje je i weryfikuje. Wadliwe zamówienia są anonsowane zamawiającemu, pozostałe są rejestrowane ze statusem [przyjęte] (patrz stan vs status dokumentu).

A gdzie są te wszystkie potrzebne detale?

Integracja systemów

Proces uruchamiający zlecenia produkcyjne jest sterowany niedoborem produktów a nie zamówieniem od klienta, gdyż na takim zamówieniu może być wiele produktów, każdy o innym cyklu życia i produkcji.

Tu pojawia się “magiczna” granica między modelami procesów biznesowych, opartych na zadaniach i dokumentach biznesowych, a modelem “fabryki”, czyli złożonego mechanizmu wytwarzającego produkty. Tą fabryką steruje się komunikatami. Są one wysyłane z systemów informatycznych przetwarzających informacje z Zamówień na komunikaty sterujące realizacją zadań na maszynach (generalnie na gniazdach produkcyjnych).

Tu ma miejsce zamiana treści Zamówienia na sekwencję określonych w czasie zleceń produkcyjnych określonych produktów (indeksów). Są to niedobory. Pojawienie się niedoboru (w magazynie) jest wychwytywane w systemie ERP (magazyny, coraz częściej ERP sprawdza to w odrębnym systemie WMS, nie pokazano go tu). Niedobór jest zgłaszany do MOM (Manufacturing Operation Management), składający się z trzech kluczowych podsystemów: planowanie, sterowanie produkcją i zarzadzanie informacją o produktach. Realizacja uzupełnienia niedoboru to sekwencja jak poniżej:

Po prawej, wg, typowej obecnej nomenklatury są to odpowiednio systemy: APS (Advanced Planning & Scheduling), MES (Manufacturing Execution System), PLM (Product Lifecycle Management). Fabryką steruje bezpośrednio system MES, interfejsem jest tu system komunikatów przekazywanych np. na panele dotykowych operatorów stanowisk lub jako komunikaty NX do maszyn CNC sterowanych cyfrowo.

Maszyny, zasoby i produkty

W większości wdrożeń kluczowym systemem jest MES, gdyż tu powstają komunikaty sterujące “fabryką”. Na rynku mamy dość duży ich wybór, jedną z cech tych systemów jest ich branżowość, czyli branże dla których każdy z nich się szczególnie nadaje (patrz porównanie: https://www.gartner.com/reviews/market/manufacturing-execution-systems).

System MES to “wielki koordynator zadań”. Każde zadanie to także komunikat wysłany i zwrotny komunikat odebrany, innymi słowy MES zleca zdania i śledzi ich postęp. W tym miejscu technologia (opisana w PLM) jest zamieniana (przeliczana) na sekwencję zadań dla określonych stanowisk (cell) w fabryce.

Podstawową informacją dla MES jest technologia i wymagane zasoby (BOM, BOR). Poniżej poglądowy schemat:

Modelowanie struktury produktu, jako jego definicji, to modelowanie wraz z pracochłonnością jego wykonania (SysML). Innymi słowy model kosztowy lodów z perspektywy budki z lodami, to gałki lodów, rożek i praca wymagana do przygotowania i wydania loda. Poniżej ogólna struktura pojęć związanych z wytwarzaniem produktów.

Wytwarzanie ich wymaga zarzadzania pokaźną ilością danych:

Jak widać mamy do czynienia z dość poważną złożonością. I tu z pomocą przychodzi traktowanie fabryki wraz z tym co wytwarza jak systemu i notacja SysML bardzo pomaga tu w modelowaniu [zotpressInText item=”{5085975:ZXMTN7WR}”].

Zaczynamy od zapoznania się z dokumentacją opisująca fabrykę (zakład produkcyjny) i tworzymy bibliotekę typów komponentów systemu

Mając przygotowany “zestaw typów klocków” możemy przystąpić do modelowania konkretnego zakładu produkcyjnego i produktów. Można zbudować model ciągu produkcyjnego dla określonego produktu:

Np. stanowisko zbudowane z elementów których typy są na powyższym diagramie może wyglądać tak:

Jeżeli dla lepszego zrozumienia chcemy pokazać jakie zadania są realizowane na tym stanowisku używamy diagramu aktywności:

Nieco bardziej wyrafinowany przykład opisu stanowiska:

Powyżej cytowany model jest precyzyjny, gdyż może posłużyć do symulacji (ww. źródło zawiera komplet modeli opisujących pewną fabrykę). W przypadku typowego wdrożenia systemu MES celem zidentyfikowanie stanowisk, ich wyposażenia i etapów produkcji wraz z przezbrojeniami oraz strukturę opisu technologii wykonania produktu, czyli musimy zidentyfikować dane wymagane do parametryzacji systemu na etapie wdrożenia. Opisywany powyżej model to kolejny “digital twin” fabryki na poziomie abstrakcji pozwalającym bezbłędnie i za pierwszym razem przygotować informacje wymagane by skonfigurować i uruchomić system MES a później zarządzać zmianą.

Podsumowanie

Opisano krótko metody i notacje używane do modelowania systemu produkcji. Celem tych modeli jest skompletowanie danych potrzebnych do skonfigurowania systemów: CAD, CAM, MES, APS, PLM. Gdzie te dane? To atrybuty i ich wartości. Atrybuty elementów tych modeli (bloki funkcjonalne i ich instancje). Opis produktu to struktura treści składająca sie z elementów opisujących nie tylko listę składników BOM, ale także listę operacji wraz z ewentualnymi przezbrojeniami na stanowiskach realizujących kolejne operacje w toku wytwarzania. Kolejne stanowiska, ich wyposażenie, operacje jakie są realizowane na każdym z nich, pozwalają dokonać sprawdzenia, czy wszystko rozumiemy.

Kluczowe są także modele samych produktów, detale powstaję z pomocą aplikacji CAD, ale abstrakcje opisujące ich architekturę to SysML. Mając takie modele możemy upewnić się, że całość jest spójna, kompletna i niesprzeczna. Mamy też możliwość dokonania świadomych optymalizacji, które na modelach odbywają się to wielokrotnie niższym kosztem niż “na żywym ciele” w toku wdrożenia [zotpressInText item=”{5085975:FI9PGYD7},{5085975:LSFREFR4},{5085975:29NZ6BRG}”].

Całość jest nazywana Design Chain Management (DCM), czyli zarządzanie łańcuchem projektowym, rozumianym tu jako ciąg zdarzeń (prac, czynności) od zaprojektowania produktu, przez jego wytworzenie do dostarczenia zamawiającemu.

Jak widać musimy zarządzać zmiennością funkcjonalności, zmiennością struktury produktu, zmiennością procesów produkcji, zmiennością procesów w logistyce. To wszystko cechuje sie określonymi parametrami. Łańcuch projektowania i wytwarzania płynnie przechodzi w łańcuch dostaw. Jednak CAŁOŚĆ opiera sie na zarządzaniu informacją. Dlaczego? Bo systemy informatyczne nie produkują kół zębatych, one jedynie przechowują i przetwarzają informacje o całym tym procesie. WSZYSTKIE.

Dlaczego więc nie tylko BPMN? Dlaczego inne systemy notacyjne? A jak w BPMN opisać wszystko powyższe? Zakład produkcyjny to skomplikowany system, nie da się go skutecznie opisać używając jedynie nazw aktywności. Zresztą detaliczne prace wykonywane przy maszynach i ich kolejność, materialne elementy, które w toku produkcji nie są “wydaniem z magazynu i przyjęciem na magazyn”.

BPMN to tylko biznesowy model łańcucha pracy i jej produktów: informacji (dokumentów). To co wytwarzamy to systemy: od prostych sterowników klimatyzacji, przez sprzęt AGD, do samochodów i samolotów. To wszystko to mieszanka podzespołów mechanicznych, elektromechanicznych i komputerów (programator pralki i sterownik wtrysku silnia spalinowego to komputery) [zotpressInText item=”{5085975:8G9TUWIG}”]:

System informatyczny zarządzający tym wszystkim to informacje zarówno o produkowanych produktach jak i o samych same halach produkcyjnych i tym co sie tam dzieje. Model BPMN tu to tylko malutki wierzchołek góry lodowej, to czwarty poziom (Level4) hierarchii modeli.

Znane są próby wdrożenia produkcji jako sekwencji dokumentów MM między stanowiskami w fabryce, albo kastomizacja systemu ERP z prostej operacji kompletacji w obsługę produkcji. No nie są to sukcesy… świat tak nie robi. Jak? Zalecenia ANSI/ISA-95 to zbiór dobrych praktyk i modeli, który warto poznać i zrozumieć. Głównie dlatego, że oprogramowanie czołowych producentów na świecie jest budowane na bazie tych standardów. To zaś oznacza, że łamanie tych standardów w toku wdrożeń tych aplikacji, może się tylko źle skończyć, tak samo jak wciskanie kwadratowego korka w okrągła szyjkę butelki.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Cztery lata temu, na zakończenie pewnej polemiki, napisałem:

Takie podejście, dziedzinowe działy w firmach ? dziedzinowe podsystemy dla nich, w ogóle umożliwia sprawne działanie. Coraz powszechniejsze staje wydzielanie podmiotów zależnych lub ich wchłanianie. Mając jeden wielki System ERP niemożliwe jest ?proste? wydzielenie zależnej spółki logistycznej czy obsługi HR. Nie raz widywałem prawnicze łamanie głowy jako podzielić licencję ERP na kawałki w przypadku pączkowania lub połączyć przy fuzji spółek. Praktyka pokazuje, że oprogramowanie jest tym lepsze im lepiej odwzorowuje świat rzeczywisty organizacji i firm, a ten nie jest monolityczny. Po drugie sam fakt rosnącego znaczenia elektronicznej wymiany danych pomiędzy firmami powoduje, że już nic nie będzie jednym monolitycznym systemem, a na integrację jesteśmy skazani. Czy ona jest zła? Nie, cieszymy się, że można już kupić atrament czy toner innego producenta do posiadanej drukarki, że można użyć uniwersalnej ładowarki do telefonu komórkowego, cieszmy się, że można użyć np. innego HR niż ten od naszego ERP? (Źródło: RE: Duży ERP czy integracja | | Jarosław Żeliński IT-Consulting).

Dzisiaj co nieco o architekturze biznesowej i architekturze IT systemów ERP.

Na początek jednak coś z niedawnej publikacji w COMPUTERWORLD (źr. COMPUTERWORLD Wrzesień 2016, Budowa aplikacji z małą ilością kodu):

Oprogramowanie, które nie tworzy przewagi konkurencyjnej, można kupić. Aplikacje decydujące o satysfakcji klienta coraz częściej daje się stworzyć małym wysiłkiem, z gotowych klocków, dodając trochę własnych pomysłów i kodu. […]

Gartner przewiduje, że w 2020 r. 75% aplikacji będzie tworzonych, a nie kupowanych. Coraz więcej firm odchodzi od nabywania gotowych rozwiązań, idąc w kierunku tworzenia programów z wielu części składowych pochodzących z różnych źródeł. (źr. j.w.)

Na rynku pojawia się coraz więcej specjalizowanych podsystemów dziedzinowych, głównym powodem jest potrzeba dostosowania architektury IT nie tylko do specyfiki firmy ale także do taktyki działania i strategii. Prowadzi to do sytuacji, w której wdrażanie systemów monolitycznych staje trudne, gdyż systemy te cechuje integracja poprzez współdzielenie danych (dzięki czemu moduły są rozłączne). Kolejnym ograniczeniem jest oparcie działania serca całego ERP na dowodach księgowych (faktury, dokumenty magazynowe) co powoduje, że moduł rachunkowości zawsze musi być wdrożony jako pierwszy. To bardzo ogranicza możliwość wpływu na kolejność wdrażania modułów. Praktyka pokazuje, że integrowanie niezależnych podsystemów na poziomie wymiany danych (każdy zawiera specyficzną dla siebie logikę biznesową i inne struktury informacji) jest łatwiejsze niż  próby dostosowywania wielu modułów niewspółdzielonych te same dane zapisane w jednym znormalizowanym modelu. Wydzielanie dziedzinowych, własnych dedykowanych podsystemów, to także jedyny sposób na ochronę własnego know-how.

Poniżej podjąłem próbę uporządkowania obecnego stanu oferowanych na rynku aplikacji.

Model pojęciowy

Podstawowym narzędziem analizy biznesowej jest tworzenie modeli pojęciowych. Są to słowniki pojęć w formie graficznej. Zdefiniowane w słowniku pojęcia na diagramach takich łączy się z pomocą rzeczywistych faktów.

Powyższy diagram to uproszczony model pojęciowy firmy (opr. własne autora, diagram faktów notacji SBVR). Analiza pojęciowa ma dwa podstawowe cele: uporządkowanie pojęć i ich znaczeń oraz wykrycie i opracowanie podziału zakresu działania firmy na spójne dziedzinowe obszary. Powyższy diagram obrazuje  przykładowy produkt takiej analizy. Jest on uproszczony z uwagi na ograniczoną objętość tego artykułu, jednak pokazuje ogólną zasadę tworzenia takiego modelu. Pojęcia w słowniku pojęć biznesowych są odwzorowywane na diagramie (prostokąt) i łączone miedzy sobą kluczowymi dla siebie faktami (zdarzeniami). Na modelach takich pojawiają się skupiska gęsto połączonych ze sobą pojęć, między tymi skupiskami zaś liczba połączeń jest relatywnie mała.  Na diagramie wyróżniono typowe obszary w firmach (od lewej): Produkcja, Logistyka, Zarządzanie produktami, Rachunkowość, Obsługa kontaktów z klientami. Jest to oczywiście bardzo uproszczona wersja, ale pokazuje mechanizm prowadzenia samej analizy pojęciowej. Pojęcia te to nazwy, które opisują przedmioty, działania lub ich cechy. Są wykorzystywane w treści dokumentów np. nazwy pól formularzy, w ich tytułach itp..  Nie należy jednak takich modeli utożsamiać z modelami danych bo nimi nie są. Ten etap analizy pozwala wychwycić ewentualne specyficzne dla danej firmy obszary dziedzinowe a także granice między tymi obszarami, które nie muszą być typowe.

Analiza pojęciowa to przesłanka do opracowania architektury komponentów IT. Założenie podstawowe to uznanie, że każdy wewnętrznie silnie powiązany obszar pojęciowy to ?kandydat? na spójny (i niepodzielny) komponent zaś proste i rzadkie fakty między tymi skupiskami kandydują na miejsca podziału na komponenty i wymiany informacji (interfejsy między podsystemami lub aplikacjami). Praktyka takich analiz pokazuje, że czasem ma sens a czasem jednak nie, umieszczanie np. fakturowania w zakresie systemu CRM (obsługa kontaktów z klientem). Przykładów różnorodności jest znacznie więcej.

Typowe podsystemy IT oferowane na rynku

W tej części krótko opiszemy standardowe podsystemu IT oferowane na rynku. Definicje powstały na podstawie serwisu Encyklopedia Zarządzania mfiles.pl (opisane w kolejności alfabetycznej, patrz takżę: [zotpressInText item=”{5085975:GUF2RNXW}”]).

APS Advanced Planning and Scheduling to systemy, które rozwijają jak dotychczas przede wszystkim jako zakresy funkcji realizowanych w obrębie MRP II. Systemy klasy APS zapewniają bowiem szybszą reakcję całego łańcucha dostaw na zmieniające się potrzeby klientów lub w warunkach pojawiania się dodatkowych, niespodziewanych zamówień. Innym atutem systemów tej klasy jest także integrowanie planów produkcyjnych z planami dystrybucyjnymi (B. Tinham, 2000, s. 17). Jako natychmiastowe korzyści z zastosowania akcentowane są lepsza obsługa klienta oraz redukcja poziomu zapasów.

Specjaliści wdrażający systemy klasy APS podkreślają, że zastosowanie takiego modułu nie stanowi samo w sobie rozwiązania problemu reagowania na nagłe zmiany wielkości zapotrzebowania na oferowane produkty. W dalszym ciągu konieczne jest bowiem permanentne monitorowanie przebiegu procesów produkcyjnych oraz realizacji zadań w obrębie dziedzin wspomagających.

CAD (ang. Computer Aided Design) ? komputerowo wspomagane projektowanie, które ma zastosowanie głównie w inżynierii budowlanej, mechanicznej oraz elektrycznej [P. Nowakowski. 2006, s. 11].

Do głównych zadań systemu CAD należy odpowiednie opracowanie dokumentacji projektowej bazującej na stworzonym modelu trójwymiarowym oraz przygotowywaniu odpowiedniej prezentacji tworzonego obiektu w celu jego demonstracji potencjalnym odbiorcom. [P. Nowakowski. 2006, s. 12]. Na podstawie tak opracowanej dokumentacji projektowej, system CAD ma możliwość bezbłędnego generowania detalicznych list detali i podzespołów. Zarządzanie wersjami projektów pozwala nadzorować, partie i unikalne wykonania produktów.

CRM to system informatyczny umożliwiający implementację strategii CRM (strategię zarządzania kontaktami z klinetami). Najczęściej systemy tego typu mają budowę modułową oraz szereg dostępnych funkcji, a także współpracę z innymi systemami firmy. Ewidencja klientów, grupowanie kontaktów z klientem, zarządzanie projektami i inne, umożliwiają indywidualne podejście do klienta, a także wspomagają dalszą dobrą współpracę z klientem, nawet po odejściu pracownika, który się nim zajmował. System taki powinien współdziałać z pozostałymi systemami w przedsiębiorstwie. (E. Frąckiewicz, 2005, s. 56)

MES (źr. MESA International): “System MES (Manufacturing Execution System) ma na celu dostarczenie informacji, która pozwala na optymalizację operacji produkcyjnych począwszy od procesu zamówienia, aż do etapu dostarczenia produktów gotowych.” Jest to system udostępniający informacje o funkcjonowaniu linii produkcyjne w czasie rzeczywistym, lub quasi-rzeczywistym.

MRPII (ang. Manufacturing Resource Planning, rozwinięty system planowania zasobów wytwórczych przedsiębiorstwa) został opracowany w 1989 r. przez Amerykańskie Stowarzyszenie Sterowania Produkcją i Zapasami (APICS). Jest kontynuacją systemu MRP. Pozwala na planowanie zasobów produkcyjnych, obejmuje sterowanie zasobami i produktami przedsiębiorstwa oraz zarządzanie działalnością firmy także w aspekcie finansowym, uzupełnione o moduły planowania sprzedaży, zarządzania kadrami, stanowiskami roboczymi, gotówką itp. Umożliwiają planowanie działalności przedsiębiorstwa produkcyjnego i dystrybucyjnego (handlowego) [Klonowski, 2004, s. 66-87].

PLM (źr. www.controlengineering.pl) to strategiczne podejście biznesowe, stosujące konsekwentny zestaw rozwiązań do wspierania wspólnego tworzenia, zarządzania, rozpowszechniania oraz stosowania firmowych definicji dotyczących produktu i zakładu, które obejmują całość przedsięwzięcia ? od koncepcji produktu do końca jego ?życia?, integrując zasoby ludzkie, procesy, systemy firmowe oraz informacje. PLM tworzy i zarządza cyfrowo produktem lub całym zakładem, zapewniając firmie i realizowanym przez nią przedsięwzięciom spójną strukturę informacyjną.

Produkcja ogół działań zmierzających do dostarczenia dóbr i usług na rynek.

Rachunkowość finansowa (źr. coin.wne.uw.edu.pl/akocia/rach_fi/Rachunkowosc%20finansowa.ppt) Rejestr zdarzeń gospodarczych. Zdarzenie gospodarcze to fakt, który jest:

1. udokumentowany,
2. wyrażony w mierniku pieniężnym,
3. wywiera wpływ na aktywa, pasywa lub wyniki działalności jednostki gospodarczej,

Podlega rejestracji w księgach rachunkowych. Zdarzenie gospodarcze jest równoznaczne z operacją gospodarczą.

SCADA (źr. systemy-sterowania.pl) (Supervisory Control And Data Acquisition) należy do warstwy nadrzędnej systemu sterowania automatyki przemysłowej. Głównym zadaniem SCADA jest wizualizacja procesu w tzw. czasie rzeczywistym oraz umożliwienie ingerencji w proces ? sterowanie poszczególnymi elementami wykonawczymi, zadawanie parametrów, zmiana nastaw ? z poziomu operatora mającego do dyspozycji stację komputerową. SCADA zawiera najczęściej następujące elementy:

1. wizualizację procesu w postaci grafik synoptycznych,
2. archiwizację danych produkcyjnych,
3. moduł raportowy,
4. moduł podstawowej analizy i przeglądu danych historycznych,
5. moduł udostępniania danych wyższym warstwom struktury zarządzania przedsiębiorstwem w celu analizy szczegółowej (systemy MES, ERP, PLM).

WMS  (Warehouse Management System), stanowi kompleksowe rozwiązanie informatyczne (oprogramowanie, urządzenia, usługi i serwis) pozwalające na zarządzanie ruchem produktów na magazynie oraz optymalizujące wykorzystanie przestrzeni magazynowej. Szczególnym zadaniem realizowanym w ramach systemów WMS jest bezbłędna lokalizacja towarów w magazynie oraz kontrola przebiegu obrotu magazynowego. System dostarcza informacji dotyczących stanu magazynowego według wielu różnych kryteriów oraz umożliwia sprawną lokalizację każdej partii towaru i każdej pojedynczej przesyłki. W systemie WMS operator może wygenerować odpowiednią etykietę i oznaczyć nią jednostki towarowe lub w momencie przyjmowania towaru do magazynu przyjąć do systemu informacje zawarte na etykiecie nadanej jej wcześniej przez inny podmiot. 

System ten, składający się z wyżej wymienionych podsystemów, przedstawia diagram poniżej.

Na diagramie zobrazowano opisane podsystemy oraz podstawowe elementy komunikacji miedzy nimi. Komunikacja ta to głównie wzajemne ?użycie [danych]? (ich wymiana na  żądanie a nie współdzielenie). Podaż tych aplikacji na rynku potwierdza opisany na początku artykułu, podział na kluczowe podsystemy dziedzinowe. Mamy tu jednak pewne specjalizowane podsystemy, których nie wykazała analiza pojęciowa. Powodem jest to, że powyższa przykładowa i bardzo uproszczona analiza bazowała na standardowych pojęciach i faktach (czyli występujących w każdej firmie produkcyjnej), zaś na rynku mamy także do czynienia z firmami o bardziej rozbudowanej  złożoności działania lub mającej w swojej strategii większą szczegółowość kontroli i planowania w wybranych obszarach dziedzinowych (wymaga to precyzyjniejszej analizy niż ta przedstawiona). Np. podsystem APS to właśnie taki przypadek: jego wdrożenie jest uzasadnione tam, gdzie wymagane są (lub są możliwe) zarządzanie większą ilością szczegółów i większa automatyzacja zarządzania. Podobnie rozwiązania PLM.

Na diagramie tym mamy dość typową architekturę systemu ERP II, która pozwoli lepiej zrozumieć budowę takiego systemu. Sercem firmy produkcyjnej jest Linia produkcyjna. Linia ta jest obsługiwana przez ludzi jednak interfejsem dla pozostałych podsystemów jest MES, podsystem który zamienia wszystkie istotne fakty z ?życia linii produkcyjnej? (systemy czujników i podzespołów wykonawczych) w strumień danych zrozumiałych dla pozostałych podsystemów. Systemy MES w różnej formie, są coraz częściej dostarczane przez producentów maszyn i całych linii produkcyjnych wraz z nimi. Więcej o tym pisałem w niedawnym artykule o Internecie rzeczy (urządzenia elektromechaniczne wraz z oprogramowaniem zbierającym dane i komunikującym się ?ze światem?). Z danych dostarczanych przez MES korzystają systemy monitorowania i zobrazowania informacji SCADA. Z nich korzysta głównie załoga obsługująca linię produkcyjną oraz służby utrzymania ruchu. Elementy zarządzania i planowania zaopatrzenia pojawiają się w podsystemie MRPII, który z MES zbiera dane o bieżącym wykorzystaniu i zużyciu zasobów. Podsystem Produkcja zarządza realizacją zleceń produkcyjnych (zaspokajanie niedoboru produktów własnych w magazynach). Położeniem i ilością produktów w magazynach zarządza WMS. Rachunkowość finansowa zbiera i przetwarza wszelkie fakty księgowe związane z przyjęciami, wydaniami, przetworzeniem, kosztami oraz sprzedażą produktów i kosztami zakupu surowców. Wszelkie kontakty z klientami związane z ofertowaniem, przyjmowaniem zamówień, obsługą dostaw czy reklamacjami obsługuje CRM, który zawsze w większym lub mniejszym stopniu realizuje wewnętrzny obieg dokumentów.

Powyższy opis jest dość ogólny, to świadome gdyż po pierwsze firmy się między sobą różnią, nie raz bardzo istotnie, po drugie aplikacje dziedzinowe także są dość zróżnicowane.

Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować wg, własnej strategii. To między innymi powoduje, że każde wdrożenie jest inne i nie ma jednej jedynie-słusznej architektury IT.

[2021-09-04] Coraz częściej można sie spotkać z opisami systemów wspierających firmy produkcyjne, w których systemy te to odrębne dedykowane, dziedzinowe aplikacje, zintegrowane w jeden spójny system. Obecnie nie jest to trudne (szybko postępuje standaryzacja integracji). Wszędzie tam gdzie pojawia się specyfika danej firmy należy opracować jej model i stworzyć interfejs dostosowany do standardów obowiązujących standardów. Jednym że standardów jest modelowanie zorientowane na strukturę danych, które zawsze są przekazywane w postaci dokumentów (paczek danych) a nie odwołań do baz danych [zotpressInText item=”{5085975:K63WIBIW}”].

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]