Notacja EPC

Wprowadzenie

Notacja EPC (Event-dri­ven Process Chain) zosta­ła opra­co­wa­na w 1992 roku w ramach pro­jek­tu badaw­czo-roz­wo­jo­we­go z udzia­łem SAP AG na University of Saarland w Niemczech, a jej twór­cą jest dr August-Wilhelm Scheer. Stanowi ona klu­czo­wy ele­ment kon­cep­cji mode­lo­wa­nia SAP R/3 w zakre­sie inży­nie­rii biz­ne­so­wej i dosto­so­wa­nia tego sys­te­mu do potrzeb klien­ta, zosta­ła włą­czo­na tak­że do sys­te­mu NetWeaver fir­my SAP. 

Ostatni duży pro­jekt z jej uży­ciem reali­zo­wa­łem w 2008 roku dla pol­skie­go oddzia­łu nie­miec­kie­go ban­ku WestLB Bank Polska SA. Później już jedy­nie oka­zjo­nal­ne wspar­cie mery­to­rycz­ne i audy­ty, nadal się zdarzają. 

EPC to nota­cja mode­lo­wa­nia wspie­ra­na przez narzę­dzie ARIS Process Platform, któ­re zapew­nia zin­te­gro­wa­ny zestaw narzę­dzi do pro­jek­to­wa­nia, wdra­ża­nia i kon­tro­lo­wa­nia pro­ce­sów biz­ne­so­wych. EPC opie­ra się na kon­cep­cjach sie­ci sto­cha­stycz­nych i sie­ci Petriego, jed­nak sto­so­wa­nie nota­cji EPC nie wyma­ga zbyt­nie­go for­ma­li­zmu, nota­cja ta nie roz­róż­nia np. poję­cia pro­duk­tu aktyw­no­ści i ele­men­tu ste­ro­wa­nia prze­pły­wem pro­ce­su, ponie­waż wystę­pu­ją one jako skon­so­li­do­wa­ne Zdarzenie. .

Moim zda­niem jest to nie­ste­ty powód, dla któ­re­go nota­cja ta nie pozwa­la na poka­za­nie np. tego, że pro­duk­tem danej pra­cy (aktyw­ność) jest fak­tu­ra a ele­men­tem ste­ru­ją­cym pro­ce­sem jest jej war­tość brut­to. Wady tej nie ma opra­co­wa­na póź­niej, otwar­ta nota­cja BPMN, gdzie ope­ru­je­my i poję­ciem obiek­tu danych i poję­ciem zda­rze­nia, fak­tu, lub warunku.

Notacja EPC nie nakła­da tak­że sztyw­nych ogra­ni­czeń syn­tak­tycz­nych, poza gene­ral­ną zasa­dą, że na linii ste­ro­wa­nia pro­ce­sem funk­cje muszą wystę­po­wać naprze­mien­nie ze zda­rze­nia­mi. W efek­cie wali­da­cja dia­gra­mów zawie­ra­ją­cych takie dodat­ko­we ele­men­ty jak: role, komór­ki orga­ni­za­cyj­ne, sys­te­my i infor­ma­cje, jest czę­sto uznaniowa.

Notacja EPC jest nadal spo­ty­ka­na w pro­jek­tach, w któ­rych sto­so­wa­ne są sys­tem SAP ERP i narzę­dzie ARIS Toolset (ofe­ru­je ono obec­nie tak­że moż­li­wość korzy­sta­nia z innych nota­cji, mie­dzy inny­mi BPMN i UML). Notację EPC moż­na też nadal spo­tkać na nie­któ­rych uczel­niach, opro­gra­mo­wa­nie ARIS jest nadal dostęp­ne na ryn­ku. Notacja EPC to war­tość inte­lek­tu­al­na nadal chro­nio­na jako wła­sność fir­my IDS Scheer.

Semantyka i syntaktyka eEPC

Legenda sym­bo­li nota­cji EPC (eEPC)

Notacja EPC pier­wot­nie zawie­ra­ła tyl­ko ele­men­ty prze­pły­wu (bram­ki logicz­ne, funk­cje i zda­rze­nia) oraz sztyw­ną syn­tak­ty­kę (obli­ga­to­ryj­ną prze­mien­ność funk­cji i zda­rzeń na linii prze­pły­wu ste­ro­wa­nia i zda­rze­nie jako począ­tek i koniec pro­ce­su). Szybko zosta­ła wzbo­ga­co­na o sym­bo­le pozwa­la­ją­ce na mode­lo­wa­nie ele­men­tów orga­ni­za­cji (sys­te­my, infor­ma­cje, role, komór­ki orga­ni­za­cyj­ne). Dlatego obec­nie moż­na spo­tkać tak­że skrót eEPC (exten­ded EPC).

Przepływ ste­ro­wa­nia jest mode­lo­wa­ny jako linia kre­sko­wa skie­ro­wa­na, przy­po­rząd­ko­wa­nie funk­cji jako zada­nia komór­ki orga­ni­za­cyj­nej (linia cią­gła nie­skie­ro­wa­na) oraz prze­pływ infor­ma­cji (linia cią­gła skie­ro­wa­na). Symbol Ścieżka Procesu to wska­za­nie (link) na kolej­ny dia­gram sta­no­wią­cy kon­ty­nu­ację pro­ce­su. Można tą meto­dą agre­go­wać dia­gram do sym­bo­lu na dia­gra­mie nad­rzęd­nym, zacho­wu­jąc jed­nak zasa­dę prze­mien­no­ści funk­cji i zda­rzeń (sym­bol Ścieżka Procesu na dia­gra­mie ma wte­dy taką samą syn­tak­ty­kę jak funk­cja na dia­gra­mie pod­rzęd­nym). Symbol Ścieżka Procesu bywa uży­wa­ny tak­że jako przeniesienie/kontynuacja pro­ce­su na kolej­nym dia­gra­mie, wte­dy jest uzna­wa­ny za zda­rze­nie (dla­te­go iko­na ta, to wła­śnie zło­że­nie funk­cji i zda­rze­nia). Poniżej opi­sa­ne sym­bo­le na przy­kła­do­wym dia­gra­mie pro­ce­su (frag­ment diagramu):

Syntaktyka eEPC (opr. własne)

Notacja pozwa­la na dość pre­cy­zyj­ne mode­lo­wa­nie pro­ce­sów biz­ne­so­wych co jed­nak wyma­ga pew­nej dys­cy­pli­ny. Notacja eEPC nie ma sfor­ma­li­zo­wa­nej spe­cy­fi­ka­cji, nale­ży korzy­stać z opra­co­wań fir­mo­wa­nych przez auto­ra (AW. Scheer), któ­ry podej­mu­je pró­by porząd­ko­wa­nia seman­ty­ki i syn­tak­ty­ki :

Każdy model EPC musi od same­go począt­ku prze­strze­gać pew­nych pro­stych zasad pro­jek­to­wa­nia, aby unik­nąć lub ogra­ni­czyć nie­po­żą­da­ne zacho­wa­nia, takie jak np. mar­twe punk­ty. Dlatego nie pro­po­nu­je się rygo­ry­stycz­ne­go i zło­żo­ne­go sys­te­mu reguł i wzor­ców pro­jek­to­wych, ponie­waż uni­ka­nie wszyst­kich moż­li­wych kon­flik­tów zbyt­nio ogra­ni­cza­ło­by użyt­kow­ni­ka. Reguły te są następujące:

  1. Trzema pod­sta­wo­wy­mi węzła­mi w mode­lach EPC są aktyw­no­ści (funk­cje), zda­rze­nia i łącz­ni­ki [bram­ki logiczne].
  2. Nazwa zda­rze­nia powin­na odzwier­cie­dlać jego cha­rak­te­ry­sty­kę jako punk­tu w cza­sie, na przy­kład: ele­ment ukoń­czo­ny”. Jest ono repre­zen­to­wa­ne przez sześciokąt.
  3. Nazwa aktyw­no­ści powin­na uwzględ­niać kon­sump­cje cza­su, na przy­kład: pro­du­ko­wa­nie przed­mio­tu”. Czynność jest przed­sta­wio­na w posta­ci pro­sto­ką­ta o zaokrą­glo­nych rogach.
  4. Łączniki [bram­ki logicz­ne] są repre­zen­to­wa­ne przez okrąg. Wewnątrz okrę­gu typ łącz­ni­ka [logi­ka OR, XOR, AND] jest okre­ślo­ny za pomo­cą odpo­wied­nie­go sym­bo­lu. Łącznik może być podzie­lo­ny na część gór­ną i dol­ną, by odzwier­cie­dlić róż­ni­ce mię­dzy regu­ła­mi połą­czeń przy­cho­dzą­cych i wycho­dzą­cych [lub łączy­my kaska­do­wo pro­ste poje­dyn­cze bramki].
  5. Aby jasno okre­ślić, kie­dy pro­ces biz­ne­so­wy ma się roz­po­cząć i jaki jest jego wynik koń­co­wy, każ­dy dia­gram EPC roz­po­czy­na się i koń­czy jed­nym lub kil­ko­ma zdarzeniami.
  6. Diagram EPC zawie­ra co naj­mniej jed­ną czynność.
  7. Model EPC może skła­dać się z kil­ku dia­gra­mów EPC.
  8. Krawędzie [linie prze­pły­wu ste­ro­wa­nia] są skie­ro­wa­ne i zawsze łączą dwa ele­men­ty odpo­wia­da­ją­ce sekwen­cji aktywacji.
  9. Zdarzenie nie może być poprzed­ni­kiem ani następ­ni­kiem inne­go zdarzenia.
  10. Czynność nie może być poprzed­ni­kiem ani następ­ni­kiem innej czynności.
  11. Każde zda­rze­nie i każ­da czyn­ność mają tyl­ko jed­ną kra­wędź [linia prze­pły­wu ste­ro­wa­nia] przy­cho­dzą­cą i/lub jed­ną kra­wędź wychodzącą.”

Przykłady modeli

Poniżej przy­kła­do­wy model pro­ce­su reje­stra­cji fak­tur kosztowych. 

Proces księ­go­wa­nia fak­tur kosz­to­wych (opr. własne)

Używanie ele­men­tów roz­sze­rza­ją­cych nie jest obli­ga­to­ryj­ne, dla­te­go wystę­pu­ją na dia­gra­mach tam gdzie autor mode­lu uzna, że chce je zobra­zo­wać. Notacja eEPC nie ope­ru­je poję­ciem sta­tu­su więc fak­tu­ra zaak­cep­to­wa­na i zaksię­go­wa­na to dwa osob­ne ele­men­ty infor­ma­cyj­ne. Powyższy model pro­ce­su Księgowania fak­tur kosz­to­wych może być pod­pro­ce­sem w pro­ce­sie Obsługi płatności:

Proces biz­ne­so­wy nad­rzęd­ny Obsługa płat­no­ści: tu sym­bol Ścieżka Procesu peł­ni rolę funk­cji dekom­po­no­wa­nej (opr. własne) 

Symboli eEPC moż­na for­mal­nie użyć w innym kon­tek­ście, np. budu­jąc dodat­ko­wy model struk­tu­ry organizacyjnej;

Struktura orga­ni­za­cyj­na wyra­żo­na z uży­ciem nota­cji eEPC (opr. autora)

Autor nota­cji pro­po­nu­je wie­le form sto­so­wa­nia swo­jej nota­cji, łącz­nie z warian­ta­mi nie­uwzględ­nia­ją­cy­mi zasa­dy prze­mien­no­ści funk­cja-zda­rze­nie” (łamiąc wła­sne zasa­dy), co poka­zu­je dość swo­bod­ne podej­ście twór­cy nota­cji do mode­lo­wa­nia, jak np. na poniż­szym diagramie:

Podsumowanie

Notacja eEPC i meto­da ARIS zdo­by­ły sobie szyb­ko dużą popu­lar­ność w obsza­rze ana­liz i wdro­żeń sys­te­mów ERP, za spra­wą związ­ków fir­my IDS Scheer z fir­mą SAP AG. Jednak po ok. 10 latach ist­nie­nia EPC oka­za­ło się, że jej nie­do­stat­ki for­ma­li­za­cyj­ne powo­do­wa­ły dość niską jakość mode­li za spra­wą ich nie­jed­no­znacz­no­ści (ww. brak formalizmu). 

W odpo­wie­dzi na powyż­sze powsta­ła znacz­nie lepiej dopra­co­wa­na nota­cja BPMN. Notacja BPMN zosta­ła pier­wot­nie opra­co­wa­ny przez orga­ni­za­cję Business Process Management Initiative (BPMI). Wersja 1.0 zosta­ła udo­stęp­nio­na publicz­nie w maju 2004 roku. W czerw­cu 2005 r. BPMI połą­czy­ło się z OMG (Object Management Group). Formalna spe­cy­fi­ka­cja BPMN zosta­ła wyda­na przez OMG w lutym 2006 roku (https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/). Co cie­ka­we, w pra­cach nad BPMN bra­ły udział, mię­dzy inny­mi, fir­my IDS Scheer, Software AG i SAP AG.

Moim zda­niem roz­po­czy­na­nie pro­jek­tów z jej uży­ciem w obec­nych cza­sach ma uza­sad­nie­nie tyl­ko tam, gdzie wie­le zain­we­sto­wa­no w zaso­by i gro­ma­dzo­no kom­pe­ten­cje wokół narzę­dzi ARIS. Co jed­nak nie zmia­nia fak­tu, że pozo­sta­wa­nie w tej niszy rodzi poważ­ne ryzy­ko budo­wa­nia dłu­gu tech­no­lo­gicz­ne­go i tak zwa­ne­go ven­dor lock-in. 

Repozytoria ARIS budo­wa­ne są w mode­lu rela­cyj­nym a struk­tu­ra bazy jest obję­ta tajem­ni­cą pro­du­cen­ta, do tego nie ma spe­cy­fi­ka­cji XMI dla eEPC (XML Metadata Interchange) więc migra­cja mode­li do innych narzę­dzi jest prak­tycz­nie nie­moż­li­wa (moż­na je prze­ry­so­wać” w nowym narzę­dziu). Do tego wer­sje same­go ARIS’a bywa­ją nie­kom­pa­ty­bil­ne mię­dzy sobą (prze­cho­dze­nie na now­szą wer­sję wyma­ga­ło już w histo­rii sto­so­wa­nia skom­pli­ko­wa­nych pro­ce­dur). Nadal, od cza­su do cza­su podej­mo­wa­ne są pró­by napra­wy tej sytuacji: 

Mimo tego, że w ostat­nich deka­dach do mode­lo­wa­nia pro­ce­sów powszech­nie sto­su­je się język EPC, brak ofi­cjal­ne­go stan­dar­du pro­wa­dzi do coraz częst­sze­go jego pomi­ja­nia. Spójny meta­mo­del jest pod­sta­wą do okre­śle­nia języ­ków mode­lo­wa­nia pro­ce­sów. W związ­ku z tym, niniej­sza pra­ca budu­je pod­sta­wy dla dal­szej stan­da­ry­za­cji poprzez dostar­cze­nie zin­te­gro­wa­ne­go meta­mo­de­lu dla EPC. Uzyskany w ten spo­sób meta­mo­del wspie­ra oży­wie­nie EPC poprzez uła­twie­nie przy­szłych wysił­ków standaryzacyjnych.

Narzędzie ARIS to obec­nie roz­bu­do­wa­ny pakiet CASE, nadal obec­ny na ryn­ku, mię­dzy inny­mi jako kon­ty­nu­acja wie­lu pro­jek­tów zapo­cząt­ko­wa­nych przed powsta­niem nota­cji BPMN (z pomo­cą tego narzę­dzia powsta­ło wie­le doku­men­ta­cji pro­jek­to­wych, nadal utrzy­my­wa­nych). Jednak, z uwa­gi na to, że nota­cja BPMN, jako znacz­nie lepiej dopra­co­wa­na i funk­cjo­nu­ją­ca jako otwar­ty stan­dard public doma­in, sta­ła się szyb­ko stan­dar­dem de fac­to, eEPC to obec­nie mała nisza i chy­ba już nic tego nie zmieni. 

Notacja EPC jest dostęp­na nie tyl­ko w narzę­dziu ARIS, powyż­sze dia­gra­my powsta­ły z uży­ciem Visual Paradigm, udo­stęp­nia­ją­cym tak­że (nie­stan­dar­do­wą) moż­li­wość ich expor­tu do for­ma­tu XMI. Możliwe jest tu tak­że auto­ma­tycz­ne wyge­ne­ro­wa­nie dia­gra­mów BPMN z dia­gra­mów EPC.

Notacja eEPC, obok BPMN i UML, nadal jest przed­mio­tem naucza­nia na nie­któ­rych uczel­niach w Polsce. 

Źródła

Jannaber, S., Karhof, A., Riehle, D. M., Thomas, O., Delfmann, P., & Becker, J. (2016). Invigorating Event-dri­ven Process Chains – Towards an inte­gra­ted meta model for EPC stan­dar­di­za­tion. 10.
Scheer, A.-W., & Emminghaus, F. (1994). ARIS-tool­set. IDS Prof. Scheer.
Scheer, A.-W., Thomas, O., & Adam, O. (2005). Process Modeling Using Event-Driven Process Chains.

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu infor­ma­tycz­ne­go. Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat już nigdy nie będzie tak pro­sty jak 40 lat temu jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji też ode­szły do lamu­sa. Czym jest inte­gra­cja? To wymia­na danych a nie współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne, nie­udo­stęp­nia­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę inte­gra­cji. Być może autor tego okre­śle­nia ma na myśli naj­gor­sze prak­ty­ki inte­gra­cji czy­li się­ga­nie do cudzej bazy” lub współ­dzie­le­nie pli­ków na wspól­nym zaso­bie dys­ko­wym”, opi­sa­łem je w dru­giej czę­ści. Pokazałem też jak to robić dobrze czy­li tanio, sku­tecz­nie i niezawodnie… 

Czytaj dalej… Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­wej. Projektowanie REST API i sce­na­riu­szy”

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

Czytaj dalej… Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje”

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

Czytaj dalej… Analiza nie musi być przed­wdro­że­nio­wa”

Bazy NoSQL jako implementacje wzorców struktur informacji

Dane nie­struk­tu­ral­ne sta­no­wią ponad 80% skła­do­wa­nych danych, to ozna­cza, że model rela­cyj­ny pozwa­la opi­sać i prze­twa­rzać tyl­ko uła­mek posia­da­nej infor­ma­cji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W pod­su­mo­wa­niu nie­daw­ne­go arty­ku­łu o NoSQL w chmu­rze, napisałem: 

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmu­rze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie wła­śnie uka­zał. We wstę­pie napisałem:

Dokumenty czę­sto zawie­ra­ją dużą ilość róż­nych danych two­rzą­cych wspól­nie wie­le kon­tek­sto­wych zbio­rów danych (agre­ga­tów). Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­za­cji takich danych pro­wa­dzi do wyge­ne­ro­wa­nia roz­bu­do­wa­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel, przy czym usu­nię­cie redun­dan­cji czę­sto powo­du­je utra­tę kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. Rodzi to koniecz­ność sto­so­wa­nia wyso­ce zło­żo­nych zapy­tań SQL, aby doku­men­ty te mogły być zapi­sy­wa­ne w tej bazie danych i z niej pobie­ra­ne. W ten spo­sób sama baza danych zawie­ra wyłącz­nie dane pozba­wio­ne kon­tek­stu obec­ne­go w tabe­lach, a nie dokumenty.

Wielu auto­rów zwra­ca­ło uwa­gę na pro­blem zło­żo­no­ści i utra­ty jed­no­li­te­go kon­tek­stu mode­lu rela­cyj­ne­go (Ślęzak i in., 2018). Autorzy ci suge­ro­wa­li, że kon­tek­sty powin­ny być sepa­ro­wa­ne w dużych rela­cyj­nych mode­lach danych. Jednak zale­ce­nie sepa­ra­cji kon­tek­stów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zacho­wa­niu mode­lu rela­cyj­ne­go, nie poma­ga w cał­ko­wi­tym roz­wią­za­niu pro­ble­mu (Awang et al., 2012, 2012, 2012).

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych (Danesi, 2004). Podejmowane pró­by zacho­wa­nia zna­cze­nia danych czę­sto pro­wa­dzą do two­rze­nia roz­bu­do­wa­nych rela­cyj­nych mode­li danych, gene­ru­jąc tym samym dodat­ko­we kosz­ty. Dlatego też wyko­rzy­sta­nie jed­ne­go rela­cyj­ne­go mode­lu danych do zapi­su zawar­to­ści wie­lu róż­nych doku­men­tów może uczy­nić z takie­go sys­te­mu ogrom­ny i nie­po­dziel­ny mono­lit, któ­ry jest kosz­tow­ny zarów­no w roz­wo­ju, jak i w utrzy­ma­niu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Rodzaje baz danych NoSQL na rynku

Praktyka poka­zu­je, że bazy te to odpo­wiedź na stan­dar­do­we obec­nie wyma­ga­nia wobec sys­te­mów infor­ma­cyj­nych, jaki­mi są zmien­ność struk­tur danych, ich ogra­ni­czo­na struk­tu­ra­li­za­cja lub nawet jej cał­ko­wi­ty brak .

Akronim NoSQL został po raz pierw­szy uży­ty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lek­kiej, open­so­ur­ce rela­cyj­nej” bazy danych, któ­ra nie uży­wa­ła SQL. Nazwa ta poja­wi­ła się ponow­nie w 2009 roku, kie­dy Eric Evans i Johan Oskarsson uży­li jej do opi­sa­nia nie­re­la­cyj­nych baz danych. Relacyjne bazy danych są czę­sto okre­śla­ne jako sys­te­my SQL. Termin NoSQL może ozna­czać zarów­no Nierelacyjna SQL” lub bar­dziej popu­lar­ne tłu­ma­cze­nie Nie tyl­ko SQL” (Not only SQL), aby pod­kre­ślić fakt, że nie­któ­re sys­te­my mogą obsłu­gi­wać języ­ki zapy­tań podob­ne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zda­niem cie­kaw­szych arty­ku­łów o NoSQL napi­sał Fowler 10 lat temu .

Bazy danych «key-value».

Bazy te są naj­prost­szym typem bazy NoSQL. Każdy ele­ment (wiersz) w takiej bazie to para klucz i war­tość (dane prze­cho­wy­wa­ne), tu zawar­tość (dane prze­cho­wy­wa­ne) to zawsze jakiś plik” (podob­nie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobra­na wyłącz­nie poprzez odwo­ła­nie się do jej iden­ty­fi­ka­to­ra (klu­cza) . Bazy te są dosko­na­łe do prze­cho­wy­wa­nia dużych ilo­ści róż­no­rod­nych danych, gdzie nie trze­ba prze­twa­rzać tre­ści tych danych w samej bazie (np. wyszu­ki­wa­nie zawar­to­ści na pod­sta­wie jej okre­ślo­nych cech). Służą one wyłącz­nie do zacho­wy­wa­nia i odzy­ski­wa­nia pli­ków. Praktycznie jest to pła­ski sys­tem plików. 

model repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 
meto­da zapi­su w repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 

Dokumentowe bazy danych. 

To odmia­na bazy key-value. Przechowuje dane w posta­ci okre­ślo­nej struk­tu­ral­nej tre­ści: doku­men­tów (np. JSON czy XML). Struktury te mają swo­je defi­ni­cje, a ich typów może być dowol­na licz­ba . Jedna baza może więc zawie­rać doku­men­ty o dowol­nie wybra­nej, okre­ślo­nej struk­tu­rze. Dostępne na ryn­ku bazy tego typu maja tak­że bar­dzo dobre i szyb­kie moto­ry zapy­tań, są coraz czę­ściej sto­so­wa­ne jako bazy danych ogól­ne­go przeznaczenia. 

Baza doku­men­to­wa. Dokument to czy­tel­na dla czło­wie­ka treść, w bazach doku­men­to­wych ma on okre­ślo­na ale nie sztyw­ną struk­tu­rę: może to być JSON, XML. Dokument (jego treść) jest prze­twa­rza­ny poza bazą danych (kom­po­nent Logika biz­ne­so­wa). (opra­co­wa­nie wła­sne autora) 

Bazy zmieno-kolumnowe.

Przechowują dane w posta­ci agre­ga­tów o zmien­nych liściach”. Bazy tego typu zapew­nia­ją dużą ela­stycz­ność w sto­sun­ku do rela­cyj­nych baz danych, ponie­waż nie jest wyma­ga­ne, aby każ­dy wiersz agre­gat posia­dał tyle samo i te same ele­men­ty (kolum­ny) . Bazy tego typu są powszech­nie sto­so­wa­ne do prze­cho­wy­wa­nia danych np. danych pro­fi­lo­wych użyt­kow­ni­ków. Są czę­sto opi­sy­wa­ne w poniż­szy sposób:

Diagram of a column family in a wide column store database.
Model archi­tek­tu­ry kom­po­nen­tu z bazą zmien­no-kolum­no­wą (powyż­sze wyra­żo­ne jako model dzie­dzi­ny kom­po­nen­tu z uży­ciem UML)

Jak widać, bazy te prze­cho­wu­ją agre­ga­ty. Nazwanie agre­ga­tu wier­szem” jest nie­for­tun­ne bo to jed­nak nie są pła­skie tabe­le, jed­nak poję­cia wier­szy i kolumn zrzu­cam tu jed­nak na karb ste­reo­ty­pu zaczerp­nię­te­go z mode­lu relacyjnego.

Grafowe bazy danych. 

Przechowują dane w posta­ci węzłów i kra­wę­dzi (aso­cja­cje mię­dzy węzła­mi). Węzły zazwy­czaj prze­cho­wu­ją infor­ma­cje o obiek­tach (ludzie, miej­sca, przed­mio­ty) kra­wę­dzie zaś prze­cho­wu­ją infor­ma­cje o moż­li­wych związ­kach mię­dzy węzła­mi . Grafowe bazy danych dosko­na­le spraw­dza­ją się w przy­pad­kach gdy trze­ba zapi­sy­wać i śle­dzić związ­ki mię­dzy obiek­ta­mi i ana­li­zo­wać je, np. sie­ci spo­łecz­no­ścio­we czy wykry­wa­nie oszustw. Tak są naj­czę­ściej opi­sy­wa­ne gra­fo­we bazy danych, a przed­sta­wia­ne są np. tak:

Uważam, że powyż­sze to try­wial­na i naiw­na meto­da przed­sta­wia­nia baz tego typu. Istotą sys­te­mu prze­twa­rza­nia infor­ma­cji jest tu (w takim mode­lu) jest prze­cho­wy­wa­nie infor­ma­cji o obiek­tach i o fak­tach je łączą­cych takich jak zda­rze­nia doty­czą­ce pary obiek­tów . Mogą to być typo­we fak­ty, np. Samochód miał koli­zje w Mieście, gdzie Samochód i Miasto to węzły, a koli­zja to zda­rze­nie. Ważne jest to, że Samochód i Miasto moż­na opi­sać okre­ślo­nym cech, sama koli­zje tak­że, waż­ne jest to, że fak­tów łączą­cych dwa obiek­ty może być wie­le (w czasie). 

Związki mię­dzy obiek­ta­mi opi­sy­wa­ne są też meto­dą RDF (Resource Description Framework) jako zda­nia: Subject – Predicate – Object .

O każ­dym obiek­cie będzie jeden rekord w bazie danych, o każ­dym fak­cie też, ale róż­nych fak­tów, któ­rych cecha­mi są te obiek­ty może być wie­le (cechą stłucz­ki jest mię­dzy inny­mi miej­sce stłucz­ki i samo­chód, któ­ry miał tę stłucz­kę). Cechami obiek­tów są nazwa, data powsta­nia i ewen­tu­al­na data usu­nię­cia (znisz­cze­nia), tak­że cechy defi­niu­ją­ce takie jak np. kolor, typ czy wyda­wa­ne dźwię­ki. Cechami fak­ty są czas zaist­nie­nia oraz obiek­ty (ich nazwy), któ­rych okre­ślo­ny fakt doty­czy. Ważne jest to, że poło­że­nie obiek­tu nie jest jego cechą defi­niu­ją­cą. Graf jest defi­nio­wa­ny jako nazwa­ne związ­ki mię­dzy obiek­ta­mi, są nimi wła­śnie fak­ty (a sze­rzej: pre­dy­ka­ty). Warto też zazna­czyć, że w kon­tek­ście np. zda­rzeń gospo­dar­czych, fak­tem jest fak­tu­ra opi­su­ją­ca trans­ak­cje do jakiej doszło. Jednak w archi­wum doku­men­tów fak­tu­ra jest obiek­tem archi­wal­nym .

Tak więc bar­dziej sfor­ma­li­zo­wa­na struk­tu­ra danych w bazie gra­fo­wej mogła by wyglą­dać tak:

Struktura infor­ma­cyj­na gra­fo­wej bazy danych: obiek­ty (nie­bie­skie) i związ­ki (żół­te) (opra­co­wa­nie wła­sne autora)

Diagram powyż­szy jest kolo­ro­wa­ny dla popra­wy czy­tel­no­ści. W tej posta­ci widać obiek­ty i łączą­ce je fak­ty: w bazach gra­fo­wych są to for­mal­nie tak zwa­ne związ­ki seman­tycz­ne (zna­cze­nio­we), ale jest to jed­nak duże uprosz­cze­nie. Systemy zapi­su infor­ma­cji w posta­ci tró­jek: poję­cie-pre­dy­kat-poję­cie mają szer­sze uza­sad­nie­nie (pla­nu­ję publi­ka­cję z wyni­ka­mi szer­szych badań). Metamodel sys­te­mu zapi­su infor­ma­cji o obiek­tach i związ­kach mię­dzy nimi wyglą­da tak:

Metamodel gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora) 

Warto zauwa­żyć, że zarów­no Obiekt jak i Związek seman­tycz­ny mogą być prze­cho­wy­wa­ne w bazie doku­men­to­wej lub kolumnowej…

Podsumowanie

To co dzi­siaj nazy­wa­my baza­mi danych NoSQL to tyl­ko natu­ral­ne mode­le infor­ma­cyj­ne. Kiedy odkry­te? Nie wiem, ale wiem, że w tym wszyst­kim naj­bar­dziej nie­na­tu­ral­ny jest model rela­cyj­ny. Dlaczego? Bo nie wystę­pu­je w natu­rze i spra­wia same pro­ble­my. Celowo zapre­zen­to­wa­łem sfor­ma­li­zo­wa­ne dia­gra­my UML dla każ­de­go typu, by poka­zać, że NoSQL to tyl­ko i aż mode­le infor­ma­cyj­ne spo­ty­ka­ne w rze­czy­wi­sto­ści życia czło­wie­ka. Konstrukcje jak te wyżej opi­sa­ne, to tak na praw­dę mode­le infor­ma­cji wyni­ka­ją­ce z dzie­dzi­ny pro­ble­mu, nie jest tak że są uży­wa­ne z powo­du wyna­le­zie­nia” baz NoSQL, jest dokład­nie odwrotnie. 

Obecne bazy NoSQL rozu­mia­ne jako moto­ry baz danych”, to imple­men­ta­cje infor­ma­cyj­nych wzor­ców pro­jek­to­wych. Diagramy UML powy­żej to meta­mo­de­le tych wzorców. 

Na temat baz danych i baz NoSQL pole­cam kom­plek­so­we opra­co­wa­nie Joe Celko: Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses .

Podsumowanie 2

Pojawiają się tezy że to się nie nada­je do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budo­wa­ne w opar­ciu o cen­tral­ne bazy danych RDBMS ewo­lu­ują­ce do chmu­ry są nie­ja­ko ska­za­ne na bazy NoSQL (zna­ko­mi­ta więk­szość chmu­ro­wych repo­zy­to­riów chmu­ro­wych to bazy NoSQL).

Ewolucja Architektury tak zwa­nych stan­dar­do­wych ERP 

Podstawowym pro­ble­mem sys­te­mów zbu­do­wa­nych w opar­ciu o bazy RDBMS/SQL jest to, że nie ma w nich doku­men­tów, a jedy­nie dane roz­ło­żo­ne w tabe­lach. Uzyskanie doku­men­tu (np. fak­tu­ry) wyma­ga każ­do­ra­zo­wo dyna­micz­ne­go zebra­nia danych z wie­lu tabel, ich złą­cze­nia i sfor­ma­to­wa­nia, czy­li uży­cia języ­ka SQL. Dlatego ewo­lu­cja nowo­cze­snych sys­te­mów ERP idzie w kie­run­ku sys­te­mów, w któ­rych funk­cje kal­ku­la­cyj­ne oraz doku­men­ty są roz­dzie­lo­ne, a doku­men­ty są prze­cho­wy­wa­ne w posta­ci zmaterializowanej: 

Zarządzanie doku­men­ta­mi w sys­te­mach ERP 

Podsumowanie 3

Od dłuż­sze­go cza­su sto­su­je w pro­jek­tach struk­tu­ry infor­ma­cyj­ne nazy­wa­ne NoSQL. Sa to prak­tycz­nie wszyst­kie opi­sa­ne wyżej struk­tu­ry. Projekt dla agen­cji foto­gra­ficz­nej BE&W (archi­wum zdjęć), pro­jekt dla Biura Polonii Kancelarii Senatu (obsłu­ga wnio­sków o dofi­nan­so­wa­nie o zmien­nej struk­tu­rze), pro­jekt dla Żandarmerii Wojskowej (zarzą­dza­nie spra­wa­mi docho­dze­nio­wo-śled­czy­mi w całej Polsce), pro­jekt dla KGHM (stan­da­ry­za­cja sys­te­mu utrzy­ma­nia ruchu, zarzą­dza­nie infra­struk­tu­rą produkcyjną).

Więcej już nie­dłu­go… Zachęcam do zada­wa­nia pytań o NoSQL pod tym wpisem. 

Źródła

Bouhali, R., & Laurent, A. (2015). Exploiting RDF Open Data Using NoSQL Graph Databases. In R. Chbeir, Y. Manolopoulos, I. Maglogiannis, & R. Alhajj (Eds.), Artificial Intelligence Applications and Innovations (Vol. 458, pp. 177 – 190). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 23868-5_13
Besta, M., Peter, E., Gerstenberger, R., Fischer, M., Podstawski, M., Barthels, C., Alonso, G., & Hoefler, T. (2020). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ArXiv:1910.09017 [Cs]. http://​arxiv​.org/​a​b​s​/​1​9​1​0​.​0​9​017
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902

Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?

Jak dobrze przy­go­to­wać się do pro­jek­tu aby nie wpaść w spi­ra­le kosztów?

WPROWADZENIE

Każdy kolej­ny rok to kolej­ne roz­po­czy­na­ne pro­jek­ty wdro­że­nio­we, ale tak­że i kolej­ne zakoń­czo­ne wdro­że­nia sys­te­mów infor­ma­tycz­nych (sys­tem). Warto pod­kre­ślić, że zakoń­czo­ne wdro­że­nie nie zawsze ozna­cza zre­ali­zo­wa­ny pla­no­wa­ny zakres wdro­że­nia (31% pro­jek­tów tak się koń­czy). Zakończone wdro­że­nie to tak­że bar­dzo czę­sto prze­rwa­ne wdro­że­nie (19% pro­jek­tów) [patrz: Henry Portman, Review Standish Group ? CHAOS 2020: Beyond Infinity, Henny Portman’s Blog – On Portfolio, Programme and Project Management, 06.01. 2021]. Uważam, że wła­śnie te prze­rwa­ne pro­jek­ty powin­ny być pod­sta­wo­wym wyznacz­ni­kiem pla­no­wa­nia kolej­nych projektów. 

Najczęściej, jako głów­ne powo­dy pora­żek pro­jek­tów wdro­że­nio­wych poda­je się brak zain­te­re­so­wa­nia ze stro­ny spon­so­ra oraz źle okre­ślo­ne wyma­ga­nia. Kluczem jed­nak wyda­je się to ostat­nie. Słownik Języka Polskiego tak defi­niu­je to poję­cie wyma­ga­nie: waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpo­wia­dać. Pojęcie waru­nek zaś jako: (we wnio­sko­wa­niu impli­ka­cyj­nym) stan rze­czy, któ­ry musi zajść, aby mógł zaist­nieć inny stan rze­czy. Innymi sło­wy moż­na powie­dzieć, że wyma­ga­nia to zda­nia okre­śla­ją­ce co się powin­no stać aby stać mogło się coś.

I teraz klu­czo­we pyta­nie: pisząc o źle okre­ślo­nych wyma­ga­niach, mamy na myśli wyma­ga­nia wobec narzę­dzia pra­cy (sys­tem) czy wyma­ga­nia wobec orga­ni­za­cji? Poprawnym wyma­ga­niem jest System powi­nien wysta­wiać fak­tu­ry VAT” czy może Nasza orga­ni­za­cja powin­na pod­nieść efek­tyw­ność i jakość wysta­wia­nia fak­tur sprze­da­ży”? Pojęcie POWINNA jest tyl­ko reko­men­da­cją, więc nie jest to waru­nek! Warunek brzmi raczej „„Nasza orga­ni­za­cja MUSI pod­nieść efek­tyw­ność i jakość wysta­wia­nia fak­tur sprze­da­ży”, oczy­wi­ście o ile ktoś wcze­śniej uznał, że od tego coś zależy. 

Wymieniono poję­cia sys­tem i orga­ni­za­cja. Oznacza to, że mamy wyma­ga­nia wobec orga­ni­za­cji i wyma­ga­nia wobec sys­te­mu (tu rozu­mia­ne­go jako narzę­dzie – infor­ma­tycz­ne – wspo­ma­ga­ją­ce zarzą­dza­nie). To są dwa róż­ne zesta­wy wyma­gań. Oznacza to, że tak na praw­dę mamy dwa pro­jek­ty: ana­li­za orga­ni­za­cji i wyma­gań biz­ne­so­wych, koń­czą­cą się Specyfikacją Wymagań Biznesowych, oraz Analiza Wymagań Wobec Rozwiązania koń­czą­ca się Specyfikacją Wymagań Wobec Rozwiązania. Na koń­cu poja­wia się Projekt Rozwiązania. Jest nim tu nasz sys­tem. Kluczowe pyta­nie: kto ma zapro­jek­to­wać rozwiązanie? 

ZWINNA ORGANIZACJA

Kto powi­nien być agi­le czy­li zwin­ny i co to zna­czy? Podstawowe zna­cze­nie sło­wa zwin­ny (s.j.p.) to: wyko­nu­ją­cy szyb­kie, zręcz­ne ruchy. Jeżeli użyć tego sło­wa wobec pod­mio­tów na ryn­ku, to moż­na się domy­ślać, że cho­dzi o zacho­wa­nia rynkowe. 

Andrzej Olak w pod­su­mo­wa­niu swo­jej publi­ka­cji [patrz: Organizacja zwin­na – wyznacz­ni­ki oraz kie­run­ki stra­te­gii pro­wa­dzą­ce do zwin­no­ści przed­się­bior­stwa, E‑mentor nr 1 (68) / 2017] pisze: Zwinność moż­na okre­ślić jako zdol­ność orga­ni­za­cji do szyb­kiej odpo­wie­dzi na zmia­ny zacho­dzą­ce w śro­do­wi­sku biz­ne­so­wym oraz do pro­ak­tyw­nych dzia­łań pro­wa­dzą­cych do wyko­rzy­sta­nia oka­zji pły­ną­cych z ryn­ku. Analiza lite­ra­tu­ry nauko­wej upraw­nia do sfor­mu­ło­wa­nia nastę­pu­ją­cych wniosków: 

  • bada­cze piszą o róż­nych wyznacz­ni­kach zwin­nej orga­ni­za­cji, jed­nak każ­de z tych ujęć akcen­tu­je takie atry­bu­ty orga­ni­za­cji, jak szyb­kość i elastyczność, 
  • naukow­cy są zgod­ni, że przed­sta­wio­ne przez nich wyznacz­ni­ki zwin­no­ści powin­ny pozo­sta­wać we wza­jem­nym sprzężeniu, 
  • tyl­ko wszyst­kie razem zin­te­gro­wa­ne skła­do­we pro­wa­dzą do zwinności, 
  • nie moż­na mówić o zwin­no­ści bez nawią­zy­wa­nia rela­cji mię­dzy­or­ga­ni­za­cyj­nych przez przedsiębiorstwo.” 

Jednym zda­niem: zwin­na orga­ni­za­cja to taka, któ­ra potra­fi natych­miast reago­wać na zmia­ny oto­cze­nia ryn­ko­we­go. Pojawia się kolej­ne pyta­nie: co tu zna­czy natych­miast? Jeszcze kil­ka lat temu dyrek­to­rzy finan­so­wi moich klien­tów mówi­li, że na rynek reagu­ją w kolej­nych budże­tach, czy­li w cyklu rocz­nym. Następnie, że kory­gu­ją budże­ty w cyklu kwar­tal­nym. Niedawno jeden z klien­tów zażą­dał pro­duk­tu (opro­gra­mo­wa­nie dla nowej usłu­gi) w trzy tygo­dnie! (uda­ło się). System w trzy tygodnie? 

W 2012 roku pisa­łem: Podstawowym błę­dem, moim zda­niem, jest trak­to­wa­nie zaku­pu lub wytwo­rze­nia opro­gra­mo­wa­nia pla­no­wa­ne­go na ?dłu­gie uży­wa­nie? jako pro­jek­tu pro­gra­mi­stycz­ne­go. To nie pro­jekt, to pro­gram! Projektem jest wytwo­rze­nie pier­wot­nej wer­sji, potem pro­jek­ta­mi są kolej­no wpro­wa­dza­ne nowe funk­cjo­nal­no­ści lub zmia­ny. Całość to pro­gram.” [patrz: Jarosław Żeliński, ?Znaczenie ma nie wiel­kość pro­jek­tu, a cykl jego życia?,? 5 mar­ca 2012]. Cóż to zna­czy? To zna­czy, że 

sys­tem nie może ogra­ni­czać zwin­no­ści orga­ni­za­cji. To w kon­se­kwen­cji ozna­cza, że sys­tem powi­nien pozwa­lać na wpro­wa­dza­nie do nie­go zmian w ter­mi­nach rzę­du poje­dyn­czych miesięcy! 

Cztery lata temu pisa­łem: Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ?water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­ra­cyj­no-przy­ro­sto­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.” [patrz: Jarosław Żeliński, ?Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu,? 13 stycz­nia 2017,]. Tak więc pro­ble­mem, jest roz­wią­za­nie (tu sys­tem) i jego archi­tek­tu­ra. Kluczową jego cechą musi być moż­li­wość wpro­wa­dza­nia zmian, czy­li tak­że roz­bu­do­wy, w cią­gu mie­sią­ca, a nie raz poje­dyn­czych tygodni. 

KOSZTY CZYLI CO I JAK CIĄĆ

Oprogramowanie ma trzy pod­sta­wo­we skład­ni­ki kosztowe: 

  1. śro­do­wi­sko czy­li plat­for­ma sprzę­to­wo-sys­te­mo­wa: nie­zbęd­ne licen­cje i ich utrzymanie, 
  2. bie­żą­ce kosz­ty pra­cy ludz­kiej zwią­za­nej z admi­ni­stra­cją platformy, 
  3. kosz­ty pra­cy zwią­za­nej z roz­bu­do­wą funkcjonalności. 

Oprogramowanie, jako kon­kret­ne apli­ka­cje, to albo tak zwa­ne pro­duk­ty seryj­ne z pół­ki” (ang. com­mer­cial off the shelf, COF) albo dedy­ko­wa­ne, czy­li wytwo­rzo­ne dla kon­kret­nej orga­ni­za­cji w celu roz­wią­za­nia okre­ślo­ne­go pro­ble­mu (speł­nie­nia okre­ślo­nych wymagań). 

Jak zapew­ne czy­tel­nik nie raz sły­szał, ceny opro­gra­mo­wa­nia COF są niskie” z powo­du efek­tu ska­li (maso­wa pro­duk­cja). Słowo niskie świa­do­mie umie­ści­łem w cudzy­sło­wie, gdyż wie­lu pro­du­cen­tów opro­gra­mo­wa­nie sto­su­je meto­dy wyce­ny opar­ta na suc­cess fee” czy­li udzia­łu w korzy­ściach” (ceny na ryn­ku usług to mate­riał na osob­ny arty­kuł). Tu ogra­ni­czy­my się jedy­nie do fak­tu, że kosz­ty wytwo­rze­nia i roz­wo­ju opro­gra­mo­wa­nia COF roz­kła­da­ją się na wszyst­kich jego użyt­kow­ni­ków (z regu­ły są ich są co naj­mniej set­ki), kosz­ty wytwo­rze­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia pono­si w cało­ści jeden zamawiający. 

Jakie wnio­ski pły­ną z powyż­sze­go? Ideałem jest sytu­acja, w któ­rej wyma­ga­nia speł­ni dostęp­ne na ryn­ku opro­gra­mo­wa­nie. Jednak dorob­kiem wie­lu firm jest wła­sny, wypra­co­wa­ny mecha­nizm funk­cjo­no­wa­nia, dają­cy prze­wa­gę nad kon­ku­ren­cją, a to (roz­wią­za­nie speł­nia­ją­ce wyma­ga­nia) wyma­ga dedy­ko­wa­ne­go komponentu. 

Mamy więc sytu­ację, w której: 

  1. oto­cze­nie ryn­ko­we zmie­nia się nawet w cyklach kwartalnych, 
  2. w tak krót­kim okre­sie moż­li­we jest opra­co­wa­nie jed­nej, tak zwa­nej usłu­gi apli­ka­cyj­nej lub zmia­na istniejącej, 
  3. im więk­sza, reali­zu­ją­ca wię­cej usług, apli­ka­cja tym wię­cej cza­su i pra­cy wyma­ga wpro­wa­dza­nie do niej zmian (czy­li koszt mody­fi­ka­cji opro­gra­mo­wa­nia jest pro­por­cjo­nal­ny do jego wielkości). 

Wnioski do co kosz­tów nasu­wa­ją się takie: 

  1. jeże­li to tyl­ko moż­li­we, nale­ży uni­kać jakich­kol­wiek dedy­ko­wa­nych roz­wią­zań, sto­so­wać je tyl­ko gdy na praw­dę jest to konieczne,
  2. żad­ne wdro­że­nie nie powin­no trwać dłu­żej niż rok, ide­ałem jest kwar­tał (to jest możliwe), 
  3. krót­kie wdro­że­nia to mały ich zakres, nale­ży więc wdra­żać małe zesta­wy dzie­dzi­no­wych funk­cji (usług aplikacyjnych), 
  4. duże sys­te­my, czy­li obej­mu­ją­ce znacz­ne obsza­ry orga­ni­za­cji, nale­ży pla­no­wać jako wie­lo­eta­po­we pro­jek­ty (pro­gra­my), wte­dy jed­nak nale­ży opra­co­wać stra­te­gię infor­ma­ty­za­cji cało­ści orga­ni­za­cji, stan­da­ry­za­cję infor­ma­cji i tak zwa­ną archi­tek­tu­rę wyso­kie­go pozio­mu”, takie wdro­że­nia powin­ny się jed­nak mie­ścić w okre­sie 3 lat.

Warto tu zwró­cić uwa­gę na to, że audyt koń­czą­cy się listą wyma­gań biz­ne­so­wych to kwar­tał. Opracowanie pro­jek­tu tech­nicz­ne­go roz­wią­za­nia, to prak­tycz­nie zawsze w ok. 20% dedy­ko­wa­ne roz­wią­za­nie, łącz­na pra­co­chłon­ność to też kwar­tał. Te okre­sy nie wyni­ka­ją jed­nak z wiel­ko­ści orga­ni­za­cji. Te kwar­tal­ne okre­sy to dopa­so­wa­nie się do zmian na ryn­ku. Innymi sło­wy zakła­da­my np. kwar­tał na ana­li­zę biz­ne­so­wą, a dopie­ro w dru­giej kolej­no­ści dosto­so­wu­je­my jej szcze­gó­ło­wość tak, by był to tyl­ko kwartał. 

Czy to wodo­spa­do­we podej­ście? Nie, to jest podej­ście ite­ra­cyj­no-przy­ro­sto­we. Poprzedzanie zaś każ­de­go eta­pu imple­men­ta­cji pro­jek­to­wa­niem, chro­ni przed znacz­nie kosz­tow­niej­szym pro­to­ty­po­wa­niem (kosz­ty pra­cy zespo­łu deve­lo­per­skie­go są wyż­sze niż koszt pra­cy jed­ne­go projektanta). 

Kolejne pyta­nie: mono­li­tycz­ny sys­tem od jed­ne­go dostaw­cy, wdra­ża­ny eta­pa­mi, czy dzie­dzi­no­we dedy­ko­wa­ne pod­sys­te­my kupo­wa­ne i ich inte­gra­cja? Wdrożenia kom­plek­so­we (znacz­na część orga­ni­za­cji) trwa­ją znacz­nie ponad rok, a jak wspo­mnia­no na począt­ku, naj­dłuż­szym okre­sem względ­nej sta­bil­no­ści pla­nów jest rok budżetowy. 

PODSUMOWANIE

Patrząc na opis sytu­acji we Wprowadzeniu, opis warun­ków funk­cjo­no­wa­nia orga­ni­za­cji Zwinnej oraz na Koszty, wnio­sek nasu­wa się dość oczy­wi­sty: nale­ży dzie­lić duże pro­jek­ty na mniej­sze. W zna­ko­mi­tej więk­szo­ści przy­pad­ków rok budże­to­wy to zbyt krót­ko na duży mono­lit. W efek­cie pyta­nie nie brzmi czy dzie­lić, ale jak dzie­lić zakres pro­jek­tu. Przypominam, że wyma­ga­nia to warun­ki a te się zmie­nia­ją, więc w świe­tle tego napi­sa­no, nie mamy moż­li­wo­ści spi­sa­nia spe­cy­fi­ka­cji wyma­gań na duże pro­jekt. Co nam pozo­sta­je? Skupić się na stra­te­gii i uznać, że to jed­nak cykl życia sys­te­mu jest klu­czem, a nie jego – nie­moż­li­wa do opra­co­wa­nia – dokład­na specyfikacja. 

Każda zła decy­zja to dodat­ko­wy koszt. Co może­my więc zro­bić? Odkładać decy­zje na ostat­ni moment”. Jaki więc sys­tem wybrać? taki, któ­ry na to pozwa­la. Bo to co opi­sa­łem to tak­że wyma­ga­nie: sys­tem powi­nien pozwa­lać na eta­po­we wdro­że­nie bez narzu­ca­nia z góry kolej­no­ści wdro­że­nia poszcze­gól­nych modu­łów oraz bez obo­wiąz­ku wdro­że­nia wszyst­kich, pla­no­wa­nych na począt­ku pro­jek­tu modułów. 

(Artykuł uka­zał się w rapor­cie Perspektywy ERP 2021 na por­ta­lu ERP-View, w lutym 2021, zawie­ra­ją­cym tak­że pro­gno­zy pre­zen­to­wa­ne przez mene­dże­rów czo­ło­wych dostaw­ców sys­te­mów ERP. )