Nie uży­wa­my nota­cji BPMN do mode­lo­wa­nia tego co się dzie­je na pro­duk­cji. Skoro nie BPMN to cze­go używamy?

Wprowadzenie

Analityczne mode­le BPMN to łań­cu­chy aktyw­no­ści repre­zen­tu­ją­cych pro­ce­du­ry oraz ich pro­duk­ty czy­li doku­men­ty (dane). Na tych mode­lach aktyw­ność to abs­trak­cja repre­zen­tu­ją­ca (całą) pra­cę, któ­rej efekt (wynik) jest pre­zen­to­wa­ny jako treść (DataObject), czy­li aktyw­ność kopa­nia rowu koń­czy się pisem­nych stwier­dze­niem, że rów wyko­pa­no, z ewen­tu­al­nym opi­sem para­me­trów tego rowu (patrz spe­cy­fi­ka­cja BPMN i defi­ni­cja ato­mo­wej aktyw­no­ści w pro­ce­sach ).

A gdzie dokład­ny opis macha­nia łopa­tą albo obsłu­gi kopar­ki? Ten opis to pro­ce­du­ra, instruk­cja sta­no­wi­sko­wa lub instruk­cja obsłu­gi urzą­dze­nia (patrz Procesy a pro­ce­du­ry).

Do mode­lo­wa­nia pro­duk­cji uży­wa­my nota­cji SysML i korzy­sta­my z tego, że zna­ko­mi­ta więk­szość dzi­siej­sze­go opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go pro­duk­cję zosta­ła zbu­do­wa­na w opar­ciu o nor­mę ANSI ISA-95. Struktura inte­gra­cji w sys­te­mach tego typu wyglą­da tak:

ERP MES SCADA PLC

Niedawno cyto­wa­ł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ęściami…

Source: Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka – Jarosław Żeliński IT-Consulting

W czym rzecz? W tym, że pro­duk­cja to zło­żo­ny sys­tem powią­za­nych ze sobą maszyn, obsłu­gu­ją­cych je ludzi (ale nie zawsze, bo są robo­ty) oraz pro­duk­tów jakie powsta­ją z ich uży­ciem. To co się dzie­je na takiej hali to nie pro­ce­sy biz­ne­so­we, hala pro­duk­cyj­na to pewien zło­żo­ny mecha­nizm wytwa­rza­nia lub prze­twa­rza­nia okre­ślo­nych rze­czy. Wyzwaniem jest tu stwo­rze­nie mode­lu tej hali i tych rze­czy . Opisuje to mię­dzy inny­mi spe­cy­fi­ka­cja ANSI/ISA-95 . Na jej pod­sta­wie moż­na tak­że opi­sać jaki­mi dany­mi zarzą­dza­my i jak inte­gru­je­my dzie­dzi­no­we pod­sys­te­my zarzą­dza­ją­ce pro­duk­cją .

Norma ANSI/ISA-95

Kluczem do napi­sa­nia tego arty­ku­łu jest war­stwo­wa struk­tu­ra zarzą­dza­nia pro­duk­cją opi­sa­na w nor­mie ANSI/ISA-95:

Dlatego gra­ni­ca mię­dzy mode­lem pro­ce­sów biz­ne­so­wych (tu uży­wa­my nota­cji BPMN) a mode­lem sys­te­mu pro­duk­cji (tu uży­wa­my nota­cji SysML) jest gra­ni­ca mie­dzy Level 4 a Level e3. Systemy MES ope­ru­ją w war­stwie Level 3. Śledzenie i kolek­cjo­no­wa­nie danych to Levels 2, 1,0. (patrz tak­że: OPC Foundation. (2024). ISA-95 Common Object Model — 4 Concept [Organisation]. OPC Foundation. https://​refe​ren​ce​.opc​fo​un​da​tion​.org/​I​S​A​-​9​5​/​v​1​0​0​/​d​o​c​s/4)

Proces biznesowy

Zgodnie z defi­ni­cją BPMN pro­ces biz­ne­so­wy to aktyw­ność i jej pro­dukt, zło­żo­ność aktyw­no­ści nie ma zna­cze­nia, ten sym­bol to abs­trak­cja dowol­nej pra­cy ogra­ni­czo­nej mate­rial­nym (doku­ment) wej­ściem i wyj­ściem (wię­cej na stro­nie Notacja BPMN…).

Poniżej dwa klu­czo­we dla pro­duk­cji pro­ce­sy biz­ne­so­we: przy­ję­cie zamó­wie­nia i uzu­peł­nie­nie niedoboru. 

Procesy biz­ne­so­we pro­duk­cji: Rejestracja zamó­wie­nia i uzu­peł­nie­nie nie­do­bo­ru (nota­cja BPMN, model analityczny) 

Co do zasa­dy nie łączy­my tych pro­ce­sów w jeden, bo licz­ba zamó­wień nie musi być rów­na licz­bie zle­ceń pro­duk­cyj­nych: może­my mieć pro­duk­cję na zapas, łącze­nie zamó­wień w jed­no zle­ce­nie pro­duk­cji itp.. Na to nakła­da się zarzą­dza­nie par­tia­mi produkcyjnymi. 

Powyższe dia­gra­my to typo­we mode­le ana­li­tycz­ne pro­ce­sów. Liczba aktyw­no­ści nie może być więk­sza niż licz­ba doku­men­tów lub zmia­ny ich sta­tu­sów (zgod­nie z defi­ni­cją BPMN ele­men­tar­ny pro­ces to aktyw­ność i jej pro­dukt, mogą nim dwa doku­men­ty, ale ana­li­tycz­nym mode­lu nie dopusz­cza­my aktyw­no­ści bez produktu).

Proces reje­stra­cji i wery­fi­ka­cji Zamówień jest z regu­ły reali­zo­wa­ny przez sys­tem ERP/MRPII: oso­ba odpo­wie­dzial­na za przyj­mo­wa­nie zamó­wień reje­stru­je je i wery­fi­ku­je. Wadliwe zamó­wie­nia są anon­so­wa­ne zama­wia­ją­ce­mu, pozo­sta­łe są reje­stro­wa­ne ze sta­tu­sem [przy­ję­te] (patrz stan vs sta­tus doku­men­tu).

A gdzie są te wszyst­kie potrzeb­ne detale?

Integracja systemów

Proces uru­cha­mia­ją­cy zle­ce­nia pro­duk­cyj­ne jest ste­ro­wa­ny nie­do­bo­rem pro­duk­tów a nie zamó­wie­niem od klien­ta, gdyż na takim zamó­wie­niu może być wie­le pro­duk­tów, każ­dy o innym cyklu życia i produkcji. 

Tu poja­wia się magicz­na” gra­ni­ca mię­dzy mode­la­mi pro­ce­sów biz­ne­so­wych, opar­tych na zada­niach i doku­men­tach biz­ne­so­wych, a mode­lem fabry­ki”, czy­li zło­żo­ne­go mecha­ni­zmu wytwa­rza­ją­ce­go pro­duk­ty. Tą fabry­ką ste­ru­je się komu­ni­ka­ta­mi. Są one wysy­ła­ne z sys­te­mów infor­ma­tycz­nych prze­twa­rza­ją­cych infor­ma­cje z Zamówień na komu­ni­ka­ty ste­ru­ją­ce reali­za­cją zadań na maszy­nach (gene­ral­nie na gniaz­dach produkcyjnych). 

Tu ma miej­sce zamia­na tre­ści Zamówienia na sekwen­cję okre­ślo­nych w cza­sie zle­ceń pro­duk­cyj­nych okre­ślo­nych pro­duk­tów (indek­sów). Są to nie­do­bo­ry. Pojawienie się nie­do­bo­ru (w maga­zy­nie) jest wychwy­ty­wa­ne w sys­te­mie ERP (maga­zy­ny, coraz czę­ściej ERP spraw­dza to w odręb­nym sys­te­mie WMS, nie poka­za­no go tu). Niedobór jest zgła­sza­ny do MOM (Manufacturing Operation Management), skła­da­ją­cy się z trzech klu­czo­wych pod­sys­te­mów: pla­no­wa­nie, ste­ro­wa­nie pro­duk­cją i zarza­dza­nie infor­ma­cją o pro­duk­tach. Realizacja uzu­peł­nie­nia nie­do­bo­ru to sekwen­cja jak poniżej:

Standardowa sekwen­cja (dia­gram sekwen­cji UML) reali­za­cji zle­ceń pro­duk­cyj­nych wg. ISA-95 

Po pra­wej, wg, typo­wej obec­nej nomen­kla­tu­ry są to odpo­wied­nio sys­te­my: APS (Advanced Planning & Scheduling), MES (Manufacturing Execution System), PLM (Product Lifecycle Management). Fabryką ste­ru­je bez­po­śred­nio sys­tem MES, inter­fej­sem jest tu sys­tem komu­ni­ka­tów prze­ka­zy­wa­nych np. na pane­le doty­ko­wych ope­ra­to­rów sta­no­wisk lub jako komu­ni­ka­ty NX do maszyn CNC ste­ro­wa­nych cyfrowo. 

Maszyny, zasoby i produkty

W więk­szo­ści wdro­żeń klu­czo­wym sys­te­mem jest MES, gdyż tu powsta­ją komu­ni­ka­ty ste­ru­ją­ce fabry­ką”. Na ryn­ku mamy dość duży ich wybór, jed­ną z cech tych sys­te­mów jest ich bran­żo­wość, czy­li bran­że dla któ­rych każ­dy z nich się szcze­gól­nie nada­je (patrz porów­na­nie: https://​www​.gart​ner​.com/​r​e​v​i​e​w​s​/​m​a​r​k​e​t​/​m​a​n​u​f​a​c​t​u​r​i​n​g​-​e​x​e​c​u​t​i​o​n​-​s​y​s​t​ems).

Hierarchia mode­li i aktyw­no­ści, nota­cji BPMN uży­wa­my tyl­ko na pozio­mie Level 4 

System MES to wiel­ki koor­dy­na­tor zadań”. Każde zada­nie to tak­że komu­ni­kat wysła­ny i zwrot­ny komu­ni­kat ode­bra­ny, inny­mi sło­wy MES zle­ca zda­nia i śle­dzi ich postęp. W tym miej­scu tech­no­lo­gia (opi­sa­na w PLM) jest zamie­nia­na (prze­li­cza­na) na sekwen­cję zadań dla okre­ślo­nych sta­no­wisk (cell) w fabryce.

Podstawową infor­ma­cją dla MES jest tech­no­lo­gia i wyma­ga­ne zaso­by (BOM, BOR). Poniżej poglą­do­wy schemat:

Notacji SysML (dia­gra­my defi­ni­cji blo­ków, dia­gram struk­tur wewnętrz­nych) uży­wa­my do zde­fi­nio­wa­nia struk­tu­ry pro­duk­tu (Product defi­ni­tion segment) 

Modelowanie struk­tu­ry pro­duk­tu, jako jego defi­ni­cji, to mode­lo­wa­nie wraz z pra­co­chłon­no­ścią jego wyko­na­nia (SysML). Innymi sło­wy model kosz­to­wy lodów z per­spek­ty­wy bud­ki z loda­mi, to gał­ki lodów, rożek i pra­ca wyma­ga­na do przy­go­to­wa­nia i wyda­nia loda. Poniżej ogól­na struk­tu­ra pojęć zwią­za­nych z wytwa­rza­niem produktów.

Wytwarzanie ich wyma­ga zarza­dza­nia pokaź­ną ilo­ścią danych:

Jak widać mamy do czy­nie­nia z dość poważ­ną zło­żo­no­ścią. I tu z pomo­cą przy­cho­dzi trak­to­wa­nie fabry­ki wraz z tym co wytwa­rza jak sys­te­mu i nota­cja SysML bar­dzo poma­ga tu w mode­lo­wa­niu .

Zaczynamy od zapo­zna­nia się z doku­men­ta­cją opi­su­ją­ca fabry­kę (zakład pro­duk­cyj­ny) i two­rzy­my biblio­te­kę typów kom­po­nen­tów systemu 

Prosty przy­kład defi­ni­cji typów blo­ków skła­do­wych sys­te­mu jakim jest zakład pro­duk­cyj­ny (Block Definition Diagram SysML)

Mając przy­go­to­wa­ny zestaw typów kloc­ków” może­my przy­stą­pić do mode­lo­wa­nia kon­kret­ne­go zakła­du pro­duk­cyj­ne­go i pro­duk­tów. Można zbu­do­wać model cią­gu pro­duk­cyj­ne­go dla okre­ślo­ne­go produktu:

Marszruta czy­li sta­no­wi­ska pro­duk­cyj­ne cią­gu tech­no­lo­gicz­ne­go (dia­gram blo­ków wewnętrz­nych SysML). Marszruta to pro­ce­du­ra (kolej­ne kro­ki do wykonania). 

Np. sta­no­wi­sko zbu­do­wa­ne z ele­men­tów któ­rych typy są na powyż­szym dia­gra­mie może wyglą­dać tak:

Model sta­no­wi­ska (work cell, dia­gram blo­ków wewnętrz­nych SysML). Tu powin­na być dostęp­na instruk­cja stanowiskowa.

Jeżeli dla lep­sze­go zro­zu­mie­nia chce­my poka­zać jakie zada­nia są reali­zo­wa­ne na tym sta­no­wi­sku uży­wa­my dia­gra­mu aktywności:

Operacje na sta­no­wi­sku (dia­gram aktyw­no­ści SysML), gra­ficz­na for­ma wyra­że­nia instruk­cji sta­no­wi­sko­wej (sce­na­riu­sza).

Nieco bar­dziej wyra­fi­no­wa­ny przy­kład opi­su stanowiska:

Powyżej cyto­wa­ny model jest pre­cy­zyj­ny, gdyż może posłu­żyć do symu­la­cji (ww. źró­dło zawie­ra kom­plet mode­li opi­su­ją­cych pew­ną fabry­kę). W przy­pad­ku typo­we­go wdro­że­nia sys­te­mu MES celem ziden­ty­fi­ko­wa­nie sta­no­wisk, ich wypo­sa­że­nia i eta­pów pro­duk­cji wraz z prze­zbro­je­nia­mi oraz struk­tu­rę opi­su tech­no­lo­gii wyko­na­nia pro­duk­tu, czy­li musi­my ziden­ty­fi­ko­wać dane wyma­ga­ne do para­me­try­za­cji sys­te­mu na eta­pie wdro­że­nia. Opisywany powy­żej model to kolej­ny digi­tal twin” fabry­ki na pozio­mie abs­trak­cji pozwa­la­ją­cym bez­błęd­nie i za pierw­szym razem przy­go­to­wać infor­ma­cje wyma­ga­ne by skon­fi­gu­ro­wać i uru­cho­mić sys­tem MES a póź­niej zarzą­dzać zmianą. 

Podsumowanie

Opisano krót­ko meto­dy i nota­cje uży­wa­ne do mode­lo­wa­nia sys­te­mu pro­duk­cji. Celem tych mode­li jest skom­ple­to­wa­nie danych potrzeb­nych do skon­fi­gu­ro­wa­nia sys­te­mów: CAD, CAM, MES, APS, PLM. Gdzie te dane? To atry­bu­ty i ich war­to­ści. Atrybuty ele­men­tów tych mode­li (blo­ki funk­cjo­nal­ne i ich instan­cje). Opis pro­duk­tu to struk­tu­ra tre­ści skła­da­ją­ca sie z ele­men­tów opi­su­ją­cych nie tyl­ko listę skład­ni­ków BOM, ale tak­że listę ope­ra­cji wraz z ewen­tu­al­ny­mi prze­zbro­je­nia­mi na sta­no­wi­skach reali­zu­ją­cych kolej­ne ope­ra­cje w toku wytwa­rza­nia. Kolejne sta­no­wi­ska, ich wypo­sa­że­nie, ope­ra­cje jakie są reali­zo­wa­ne na każ­dym z nich, pozwa­la­ją doko­nać spraw­dze­nia, czy wszyst­ko rozumiemy. 

Kluczowe są tak­że mode­le samych pro­duk­tów, deta­le powsta­ję z pomo­cą apli­ka­cji CAD, ale abs­trak­cje opi­su­ją­ce ich archi­tek­tu­rę to SysML. Mając takie mode­le może­my upew­nić się, że całość jest spój­na, kom­plet­na i nie­sprzecz­na. Mamy też moż­li­wość doko­na­nia świa­do­mych opty­ma­li­za­cji, któ­re na mode­lach odby­wa­ją się to wie­lo­krot­nie niż­szym kosz­tem niż na żywym cie­le” w toku wdro­że­nia .

Całość jest nazy­wa­na Design Chain Management (DCM), czy­li zarzą­dza­nie łań­cu­chem pro­jek­to­wym, rozu­mia­nym tu jako ciąg zda­rzeń (prac, czyn­no­ści) od zapro­jek­to­wa­nia pro­duk­tu, przez jego wytwo­rze­nie do dostar­cze­nia zamawiającemu.

Jak widać musi­my zarzą­dzać zmien­no­ścią funk­cjo­nal­no­ści, zmien­no­ścią struk­tu­ry pro­duk­tu, zmien­no­ścią pro­ce­sów pro­duk­cji, zmien­no­ścią pro­ce­sów w logi­sty­ce. To wszyst­ko cechu­je sie okre­ślo­ny­mi para­me­tra­mi. Łańcuch pro­jek­to­wa­nia i wytwa­rza­nia płyn­nie prze­cho­dzi w łań­cuch dostaw. Jednak CAŁOŚĆ opie­ra sie na zarzą­dza­niu infor­ma­cją. Dlaczego? Bo sys­te­my infor­ma­tycz­ne nie pro­du­ku­ją kół zęba­tych, one jedy­nie prze­cho­wu­ją i prze­twa­rza­ją infor­ma­cje o całym tym pro­ce­sie. WSZYSTKIE. 

Dlaczego więc nie tyl­ko BPMN? Dlaczego inne sys­te­my nota­cyj­ne? A jak w BPMN opi­sać wszyst­ko powyż­sze? Zakład pro­duk­cyj­ny to skom­pli­ko­wa­ny sys­tem, nie da się go sku­tecz­nie opi­sać uży­wa­jąc jedy­nie nazw aktyw­no­ści. Zresztą deta­licz­ne pra­ce wyko­ny­wa­ne przy maszy­nach i ich kolej­ność, mate­rial­ne ele­men­ty, któ­re w toku pro­duk­cji nie są wyda­niem z maga­zy­nu i przy­ję­ciem na magazyn”. 

BPMN to tyl­ko biz­ne­so­wy model łań­cu­cha pra­cy i jej pro­duk­tów: infor­ma­cji (doku­men­tów). To co wytwa­rza­my to sys­te­my: od pro­stych ste­row­ni­ków kli­ma­ty­za­cji, przez sprzęt AGD, do samo­cho­dów i samo­lo­tów. To wszyst­ko to mie­szan­ka pod­ze­spo­łów mecha­nicz­nych, elek­tro­me­cha­nicz­nych i kom­pu­te­rów (pro­gra­ma­tor pral­ki i ste­row­nik wtry­sku sil­nia spa­li­no­we­go to kom­pu­te­ry) :

Model systemu służy do określenia składników systemu.
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

System infor­ma­tycz­ny zarzą­dza­ją­cy tym wszyst­kim to infor­ma­cje zarów­no o pro­du­ko­wa­nych pro­duk­tach jak i o samych same halach pro­duk­cyj­nych i tym co sie tam dzie­je. Model BPMN tu to tyl­ko malut­ki wierz­cho­łek góry lodo­wej, to czwar­ty poziom (Level4) hie­rar­chii mode­li.

Znane są pró­by wdro­że­nia pro­duk­cji jako sekwen­cji doku­men­tów MM mię­dzy sta­no­wi­ska­mi w fabry­ce, albo kasto­mi­za­cja sys­te­mu ERP z pro­stej ope­ra­cji kom­ple­ta­cji w obsłu­gę pro­duk­cji. No nie są to suk­ce­sy… świat tak nie robi. Jak? Zalecenia ANSI/ISA-95 to zbiór dobrych prak­tyk i mode­li, któ­ry war­to poznać i zro­zu­mieć. Głównie dla­te­go, że opro­gra­mo­wa­nie czo­ło­wych pro­du­cen­tów na świe­cie jest budo­wa­ne na bazie tych stan­dar­dów. To zaś ozna­cza, że łama­nie tych stan­dar­dów w toku wdro­żeń tych apli­ka­cji, może się tyl­ko źle skoń­czyć, tak samo jak wci­ska­nie kwa­dra­to­we­go kor­ka w okrą­gła szyj­kę butelki.

Źródła

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: 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 bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Krzysztof

    Jak zwy­kle super mate­riał. Pozdrawiam.

Dodaj komentarz

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