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”

Ratowanie wdrożeń systemów ERP

Bardzo czę­sto mówi się, że przy­czy­ną pora­żek jest brak codzien­ne­go zaan­ga­żo­wa­nia ze stro­ny osób decy­zyj­nych. Jeżeli wdro­że­nie odby­wa się zwin­nie” i bez przy­go­to­wa­nia, fak­tycz­nie sta­łe zaan­ga­żo­wa­nie osób decy­zyj­nych jest nie­zbęd­ne. Jeżeli wdro­że­nie jest przy­go­to­wa­ne, nie. Zarząd jest wyma­ga­ny tyl­ko do zatwier­dze­nia doku­men­tu audy­tu, ana­li­zy i pro­jek­tu, potem już tyl­ko obser­wu­je. Kogo stać na zaan­ga­żo­wa­nie Zarządu w bie­żą­ce pra­ce wdrożeniowe?

Wstęp

Najczęstszą przy­czy­ną kło­po­tów jest uzna­nie, że dostaw­ca opro­gra­mo­wa­nia sam wyko­na ana­li­zę przed­wdro­że­nio­wą, opra­cu­je wyma­ga­nia i potem wdro­ży sys­tem. Uznanie zaś, że jeden sys­tem nada­je sie do wszyst­kie­go w fir­mie jest w obec­nych cza­sach nie do obro­ny.

Niestety pro­ble­ma­tycz­ne wdro­że­nia sys­te­mów ERP nie są rzad­ko­ścią. Wiele moich zle­ceń od klien­tów to wypro­wa­dza­nie ich z impa­su spo­ru z dostaw­cą a potem kon­ty­nu­acja wdrożenia. 

Jak wyglądają typowe” wdrożenia

Naturalnym sta­nem więk­szo­ści firm jest sta­bil­na pra­ca bez poża­rów” pole­ga­ją­ca na tym, że po latach drob­nych, ewo­lu­cyj­nych zmian fir­ma, jako sys­tem naczyń połą­czo­nych”, jakoś dzia­ła i to nawet nieźle.

Problem w tym, że taką fir­mę potra­fi zabić nawet dro­biazg wywo­łu­ją­cy efekt moty­la” w fir­mie. Niejedna fir­ma upa­dła, z powo­du drob­nej złej decy­zji”, złej bo pod­ję­tej bez ana­li­zy jej wpły­wu na resz­tę orga­ni­za­cji. Dlaczego tak się dzie­je? Bo do bez­piecz­ne­go podej­mo­wa­nia decy­zji o zmia­nach trze­ba mieć model fir­my, i nie są to set­ki stron zapi­su wywia­dów z pra­cow­ni­ka­mi. Każda zmia­na sys­te­mu infor­ma­tycz­ne­go to tak­że taka zmia­na, i to nie mała. 

Powszechnie uwa­ża się, że wyma­ga­nia na opro­gra­mo­wa­nie to efekt spi­sa­nych wywia­dów i wyma­gań z pra­cow­ni­ka­mi. Niestety wyka­za­no, że nic bar­dziej błęd­ne­go! Takie doku­men­ty są nie­kom­plet­ne, wewnętrz­nie sprzecz­ne i nie­spój­ne, są jed­ną z klu­czo­wych przy­czyn pora­żek pro­jek­tów w bran­ży infor­ma­tycz­nej .

Model pro­ce­so­wy orga­ni­za­cji to kil­ka­na­ście, rza­dziej kil­ka­dzie­siąt, sche­ma­tów blo­ko­wych na odpo­wied­nio dobra­nym pozio­mie ogól­no­ści (abs­trak­cji). Taki doku­ment albo da się prze­czy­tać w jeden dzień w dniu jego zatwier­dza­nia, albo jest nie­przy­dat­ny. Później powi­nien słu­żyć jak ency­klo­pe­dia: zaglą­da­my w okre­ślo­ne miej­sce, mając zaufa­nie, że całość jest spój­na, kom­plet­na i nie­sprzecz­na (a jest, jeże­li doku­ment jest, po jego powsta­niu, aktu­ali­zo­wa­ny) .

Jednym z głów­nych powo­dów powsta­wia­nia pro­ble­mów jest kasto­mi­za­cja mono­li­tycz­nych sys­te­mów: czę­sto jed­na zmia­na powo­du­je nega­tyw­ne skut­ki w kil­ku innych miej­scach, powo­dem jest to, że nikt (czę­sto nawet fir­ma wdra­ża­ją­ca!) nie rozu­mie w peł­ni dzia­ła­nia tego sys­te­mu, bo jego archi­tek­tu­ra jest tajem­ni­cą pro­du­cen­ta”, zaś bez mapy pro­ce­sów nie mamy poję­cia jak jeden dział fir­my (i moduł) wpły­wa na inny. 

Nie raz jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów na eta­pie spo­rów przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Często bywa, że wdro­że­nie trze­ba zarzu­cić, a zdo­by­te doświad­cze­nie wyko­rzy­stać w pro­wa­dzo­nym od nowa pro­jek­cie. Kilka spo­strze­żeń na ten temat w arty­ku­le: Kto winien poraż­ki projektu?

Jak skutecznie zaplanować i przeprowadzić wdrożenie oprogramowania – idealizacja

Szkielet każ­dej sku­tecz­nej meto­dy­ki pro­wa­dze­nia ana­liz przed­wdro­że­nio­wych i wdro­żeń, zarów­no goto­wych sys­te­mów ERP, już dostęp­nych na ryn­ku, jak i pro­jek­to­wa­nia i wdra­ża­nia roz­wią­zań dedy­ko­wa­nych to: prze­pro­wa­dzić audyt, opra­co­wać model pro­ce­sów biz­ne­so­wych i zapla­no­wać ewen­tu­al­ne ich uspraw­nie­nia, okre­ślić tak zwa­ną lukę czy­li wska­zać obszar, któ­re­go stan­dar­do­wa wer­sja pla­no­wa­ne­go do wdro­że­nia opro­gra­mo­wa­nia nie obsłu­gu­je. Typowy, zale­ca­ny spo­sób postę­po­wa­nia przy two­rze­niu mode­li pro­ce­sów :

  1. Zebranie arte­fak­tów (doku­men­ty operacyjne),
  2. Zidentyfikowanie i opi­sa­nie mecha­ni­zmów ich powstania,
  3. Umiejscowienie (mapo­wa­nie) tych mecha­ni­zmów w archi­tek­tu­rze orga­ni­za­cji i sys­te­mu IT,
  4. Zidentyfikowanie skut­ków nie­ty­po­wych przypadków,
  5. Ocena speł­nie­nia wyma­gań przez pro­jek­to­wa­ną archi­tek­tu­rę systemu,
  6. Ocena wza­jem­ne­go wpły­wu wymagań,
  7. Ocena kosztów/korzyści pla­no­wa­nej nowej architektury.

Mając już taki model nale­ży wska­zać na nim wszyst­kie miej­sca, któ­re mają być wspie­ra­ne przy­szłym opro­gra­mo­wa­niem: to zakres pro­jek­tu wdro­że­nio­we­go. Pozostaje już tyl­ko zapro­jek­to­wa­nie tego sys­te­mu, zna­le­zie­nie dostaw­cy i wdro­że­nie pod wła­snym nadzorem. 

Współbieżność dzia­ła­nia pro­ce­sów biz­ne­so­wych i opro­gra­mo­wa­nia je wspie­ra­ją­ce­go: u góry pro­ce­sy biz­ne­so­we, u dołu opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie, Łączą je punk­ty, w któ­rych czyn­no­ści w pro­ce­sach wyma­ga­ją uży­cia (będą wspie­ra­ne przez) oprogramowania. 

Innymi sło­wy każ­dy taki pro­jekt wyma­ga: (1) ana­li­zy i opra­co­wa­nia mode­lu pro­ce­sów biz­ne­so­wych orga­ni­za­cji w celu zro­zu­mie­nia mecha­ni­zmu jej dzia­ła­nia (wię­cej w arty­ku­le: Audyt orga­ni­za­cji i opty­ma­li­za­cja pro­ce­sów biz­ne­so­wych), (2) odwzo­ro­wa­nie tego mecha­ni­zmu w posta­ci pro­jek­tu tech­nicz­ne­go opro­gra­mo­wa­nia (wię­cej w arty­ku­le: Analiza i Opracowanie Wymagań na Oprogramowanie).

Projekty takie obec­nie reali­zu­je się meto­dą ite­ra­cyj­no-przy­ro­sto­wą („od ogó­łu do szcze­gó­łu”), dla­te­go każ­dy z ww. dwóch klu­czo­wych eta­pów, nie powi­nien trwać dłu­żej niż trzy mie­sią­ce, deta­le są opra­co­wy­wa­ne na bie­żą­co w toku wdro­że­nia (nad­zór autor­ski). Co do zasa­dy nale­ży uni­kać kasto­mi­za­cji goto­we­go kodu (to nisz­czy inte­gral­ność goto­we­go już opro­gra­mo­wa­nia i powo­du­je, że przy­szłe upgra­de­’y będą wyma­ga­ły powtó­rze­nia prac wdro­że­nio­wych), na rzecz two­rze­nia dedy­ko­wa­nych modu­łów tam gdzie to oka­że sie wyma­ga­ne (patrz: Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji). Znakomita więk­szość potrzeb może zostać obsłu­żo­na goto­wy­mi, dostęp­ny­mi na ryn­ku, roz­wią­za­nia­mi a ich inte­gra­cja, przy obec­nym pozio­mie tech­no­lo­gii i stan­da­ry­za­cji, nie sta­no­wi żad­ne­go pro­ble­mu – jest wie­lo­krot­nie tań­sza niż kasto­mi­za­cja dużych systemów. 

Kluczowe przyczyny problemów wdrożeniowych

Praktyka poka­zu­je (patrz Chaos Report), że klu­czo­wą przy­czy­ną jest łama­nie powyż­szych zasad i pró­by reali­za­cji wdro­że­nia dro­gą na skró­ty”, czy­li bez przy­go­to­wa­nia (patrz: słyn­ne poraż­ki wdro­żeń ERP).

Typowy sys­tem ERP to milio­ny linii kodu pro­gra­mu i set­ki sko­ja­rzo­nych wza­jem­nie tabel baz danych. Takie sys­te­my powsta­ją lata­mi, testo­wa­nie ich u pro­du­cen­ta trwa mie­sią­ca­mi. Każda inge­ren­cja w struk­tu­rę tego kodu i tabel baz danych to ryzy­ko zabu­rze­nia sta­bil­no­ści sys­te­mu i ogrom­na pracochłonność. 

Bardzo czę­sto przy­ta­cza­ną przy­czy­ną nie­uda­ne­go wdro­że­nia, poza niskiej jako­ści spe­cy­fi­ka­cją wyma­gań, jest brak mery­to­rycz­ne­go nad­zo­ru nad wdro­że­niem po stro­nie Zamawiającego. Dostawca opro­gra­mo­wa­nia ma ogrom­ną prze­wa­gę kom­pe­ten­cyj­ną nad użyt­kow­ni­ka­mi swo­ich pro­duk­tów (doty­czy to zresz­tą każ­de­go zaawan­so­wa­ne­go tech­no­lo­gicz­nie pro­duk­tu). Oznacza to, że nabyw­ca, bez wspar­cia, nie jest w sta­nie mery­to­rycz­nie nad­zo­ro­wać prac dostaw­cy (patrz: Kto win­ny poraż­ki pro­jek­tu) .

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem

Warto tak­że wska­zać przy­czy­nę poza mery­to­rycz­ną, jaką jest komu­ni­ka­cja w pro­jek­cie: korzy­sta­nie z pocz­ty elek­tro­nicz­nej i pro­stych narzę­dzi biu­ro­wych to zmo­ra zarzą­dza­nia pro­jek­ta­mi: roz­pro­szo­ne i nie­kon­tro­lo­wa­ne doku­men­ty, brak jed­no­li­te­go i kon­tro­lo­wa­ne­go dostę­pu do nich, powo­du­je, że bar­dzo szyb­ko zarzą­dza­nie pro­jek­tem sta­je się serią przy­pad­ko­wych kon­tak­tów. Niekontrolowany wspól­ny dysk sie­cio­wy (jeże­li jest) szyb­ko sta­je się śmiet­ni­kiem”.

Jak wyjść z impasu w projekcie?

Typowym ele­men­tem spo­rów z dostaw­ca­mi sys­te­mów jest kwe­stia pra­co­chłon­no­ści i roz­li­czeń. Dlatego pierw­szym eta­pem rato­wa­nia” jest zawsze audyt doku­men­tów pro­jek­to­wych (umo­wa, bie­żą­ce zle­ce­nia i ich roz­li­cze­nia). Ten etap ma na celu usta­le­nie sta­nu fak­tycz­ne­go i wypra­co­wa­nie tak zwa­ne­go bilan­su otwarcia. 

Kolejny etap to opra­co­wa­nie klu­czo­wych zale­głych doku­men­tów (patrz począ­tek tego arty­ku­łu). Ich szcze­gó­ło­wość zale­ży od aktu­al­ne­go sta­nu doku­men­ta­cji pro­jek­to­wej. Tu powsta­je tak­że tak zwa­na ana­li­za luki (ana­li­za fit-gap”), czy­li okre­śle­nie na ile aktu­al­ny stan odbie­ga od sta­nu pożą­da­ne­go. Ten etap koń­czą reko­men­da­cje do dal­sze­go toku prac, jest to opra­co­wa­nie nowe­go har­mo­no­gra­mu i zasad współ­pra­cy (aneks do aktu­al­nej umo­wy lub nowa umo­wa na wdro­że­nie). W skraj­nym przy­pad­ku nale­ży się liczyć z zanie­cha­niem kon­ty­nu­acji pro­jek­tu, ponow­nym roz­po­czę­ciem wdro­że­nia tego same­go pro­duk­tu lub wybo­rem i wdro­że­niem inne­go (patrz: LIDL, PUE, HERTZ).

Oferta

Umowa ze mną obej­mu­je w takich przy­pad­kach najczęściej:

  1. audyt: opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych fir­my i wska­za­nie na nich wyma­gań biz­ne­so­wych i zakre­su wdrożenia,
  2. ana­li­za fit-gap: oce­nić róż­ni­cę pomię­dzy pla­no­wa­nym sta­nem, ide­al­nym” a aktu­al­nym fak­tycz­nym, opra­co­wa­nie pro­jek­tu rozwiązania,
  3. usta­le­nie z dostaw­cą for­my zamknię­cia aktu­al­ne­go sta­nu: anek­su lub nowej umo­wy na dal­sze pra­ce (załącz­ni­kiem jest co do zasa­dy pro­dukt pierw­sze­go i dru­gie­go eta­pu powy­żej: model pro­ce­sów biz­ne­so­wych i pro­jekt roz­wią­za­nia jako wymaganie),
  4. prze­ję­cie zarzą­dza­nia zakre­sem pro­jek­tu (wyma­ga­nia i pro­jek­to­wa­nie ich reali­za­cji): (mój) nad­zór autor­ski na bazie opra­co­wa­nej mapy pro­ce­sów i wyma­gań, dostaw­ca reali­zu­je wyłącz­nie imple­men­ta­cję i wdro­że­nie pod dyk­tan­do Zamawiającego (czy­li tak­że moje).

Praktycznie każ­dy dostaw­ca opro­gra­mo­wa­nia bro­ni tezy, że tyl­ko on jest w sta­nie mery­to­rycz­nie nad­zo­ro­wać wdro­że­nie swo­ich pro­duk­tów. Teza ta jest nie do obro­ny z kil­ku powodów:

  1. dostaw­ca ma wie­dzę o tym co wdra­ża, ale wie­dzę o klien­cie też musi zdobyć,
  2. dostaw­ca, reali­zu­jąc sam ana­li­zę wyma­gań, ma ogrom­ny kon­flikt inte­re­su: z zasa­dy pre­fe­ru­je swo­je meto­dy, tech­no­lo­gie i roz­wią­za­nia, dają­ce mu naj­wyż­szą mar­że (rola Dostawcy jest opra­co­wa­nie dopie­ro kon­cep­cji wdro­że­nia w odpo­wie­dzi na wyma­ga­nie przed­sta­wio­ne przez Zamawiającego)
  3. po trze­cie pozo­sta­je pro­blem autor­skich praw mająt­ko­wych do wszel­kich nowo­pow­sta­łych funk­cjo­nal­no­ści, któ­re czę­sto sta­no­wią know-how zama­wia­ją­ce­go i nie­ste­ty, jeże­li ich auto­rem jest dostaw­ca, pra­wa te pozo­sta­ją przy nim. 

Dlatego na całym świe­cie poja­wia­ją się zale­ce­nia, by do pro­jek­tów anga­żo­wać ana­li­ty­ków-pro­jek­tan­tów nie­za­leż­nych od dostaw­ców. Nie jest praw­dą, że mają niż­sze kom­pe­ten­cje od dostaw­ców, jest dokład­nie odwrot­nie (od 30 lat mam kon­takt z kil­ko­ma fir­ma­mi, wdro­że­nia­mi i sys­te­ma­mi ERP rocz­nie, dostaw­ca sys­te­mu prak­tycz­nie zna tyl­ko swo­je rozwiązanie).

Źródła

Bass, L., Clements, P., & Kazman, R. (2013). Software archi­tec­tu­re in prac­ti­ce (3rd ed). Addison-Wesley.
Clemens, P., Kazman, R., & Klein, M. (2003). Architektura opro­gra­mo­wa­nia. Metody oce­ny i ana­li­za przy­pad­ków. Helion.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Sońta-Drączkowska, E. (2012). Problemy zarzą­dza­nia dostaw­ca­mi w pro­jek­tach infor­ma­tycz­nych. Organization and Management, 152.

Na zakończenie

Spory w pro­jek­tach wdro­że­nio­wych opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dze­nie są nie­ste­ty nadal nor­mą. Większość uda­je są roz­wią­zać polu­bow­nie mię­dzy stro­na­mi, czę­sto jed­nak stra­ty i opóź­nie­nia są tak duże, że anga­żo­wa­ni są eks­per­ci z zewnątrz w celu ich minimalizowania. 

Jeżeli więc Państwo uzna­cie, że potrzeb­ne Wam jest mery­to­rycz­ne wspar­cie, chęt­nie pomo­gę ofe­ru­jąc doświad­cze­nie zdo­by­te w cią­gu 30 lat pra­cy nad pro­jek­to­wa­niem i wdra­ża­niem takich sys­te­mów, jak i kil­ku­na­stu lat pra­cy nauko­wej w obsza­rze inży­nie­rii sys­te­mów. Poniżej pro­sty for­mu­larz, któ­ry pomo­że sfor­mu­ło­wać Wasze ocze­ki­wa­nia i pyta­nie do mnie.

    Zapytanie Ofertowe

    Chcę być infor­mo­wa­ny o nowo­ściach na stro­nie fir­my IT​-Consulting​.pl

    Model referencyjny systemu ERPII czyli co?

    Generalnie mode­le refe­ren­cyj­ne mają i dobrą i złą sła­wę. Nie są to wzor­ce pro­jek­to­we, czy­li dobre prak­ty­ki w posta­ci uni­wer­sal­nych abs­trak­cyj­nych meta-mode­li, są to naj­czę­ściej narzu­ca­ne goto­we archi­tek­tu­ry, pozo­sta­je pyta­nie: kto narzuca?. 

    Procesy refe­ren­cyj­ne kry­ty­ko­wa­łem nie raz (Procesy refe­ren­cyj­ne czy­li kto żyw niech ucie­ka), refe­ren­cyj­ny model ERP ozna­czał­by, że ist­nie­je jakaś jedy­nie słusz­na archi­tek­tu­ra sys­te­mu ERPII. I wła­śnie dostaw­cy wie­lu sys­te­mów ERPII (szcze­gól­nie ci duzi, któ­rych pro­duk­ty mają wie­le lat) pro­mu­ją model opar­ty o jed­ną wspól­ną rela­cyj­ną bazę danych, wokół któ­rej są osa­dzo­ne dzie­dzi­no­we modu­ły, nazy­wa­ją taki model mode­lem refe­ren­cyj­nym. Biorąc pod uwa­gę fakt, że sys­te­my te wszyst­kie tak dzia­ła­ją, moż­na taki model nazwać refe­ren­cyj­nym w tej kate­go­rii. Promowana jest tu inte­gra­cja poprzez współ­dzie­le­nie danych. Taka inte­gra­cja jest nie­ste­ty kry­ty­ko­wa­nym od lat mono­li­tem, któ­ry jest też przy­czy­ną wie­lu nie­po­wo­dzeń wdro­żeń: wpro­wa­dza­nie jakich­kol­wiek zmian do takie­go sys­te­mu jest zawsze inge­ren­cją w cały sys­tem. Zarówno na moim blo­gu jak i w sie­ci zna­leźć moż­na wie­le mate­ria­łów na ten temat (np. Monolity vs. …).

    Więc jak inaczej?

    Wewnętrzny łańcuch wartości

    Zacznijmy od przy­po­mnie­nia, uzna­wa­ne­go nadal za stan­dard, mode­lu wewnętrz­ne­go łań­cu­cha war­to­ści M.E.Portera :

    Łańcuch wartości M.E.Porter
    Łańcuch war­to­ści M.E.Porter (Competitive Advantage, 1985)

    Model ten dzie­li pro­ce­sy wewnątrz orga­ni­za­cji na dwie gru­py: wspie­ra­ją­ce i ope­ra­cyj­ne. Procesy wspie­ra­ją­ce to pro­ce­sy zapew­nia­ją­ce orga­ni­za­cji zaso­by nie­zbęd­ne do dzia­ła­nia. Procesy ope­ra­cyj­ne, to pro­ce­sy two­rzą­ce war­tość doda­ną pro­duk­tów i usług w ryn­ko­wym łań­cu­chu war­to­ści (to jaką war­tość doda­ną wno­si dana orga­ni­za­cja na ryn­ku). Schematycznie przed­sta­wio­no to poniżej: 

    Rynkowy łań­cuch war­to­ści (źr. Model biz­ne­so­wy czy­li po co mi te pro­ce­sy przed wdro­że­niem ERP czy CRM?)

    Marża budo­wa­na jest zarów­no w obsza­rze pro­ce­sów wspie­ra­ją­cych (mini­ma­li­zu­jąc kosz­ty sta­łe) jak i w obsza­rze pro­ce­sów ope­ra­cyj­nych (mar­ża na pro­duk­tach i usłu­gach czy­li wła­snej inwen­cji two­rzą­cej war­tość doda­ną na ryn­ku). W obsza­rze pro­ce­sów wspie­ra­ją­cych może­my kon­ku­ro­wać prak­tycz­nie tyl­ko w wewnętrz­nej efek­tyw­no­ści. W tym obsza­rze pro­ce­sy biz­ne­so­we i infor­ma­cje są dość ści­śle regu­lo­wa­ne pra­wem (księ­go­wość i finan­se, zatrud­nie­nie i wyna­gro­dze­nia, itp.). Zbudowanie tu prze­wa­gi ryn­ko­wej jest bar­dzo trud­ne, gdyż pra­wo doty­czy wszyst­kich pod­mio­tów – czy­li kon­ku­ren­tów tak­że – w jed­na­ko­wym stopniu. 

    W obsza­rze pro­ce­sów ope­ra­cyj­nych mamy jed­nak nie­mal­że peł­ną swo­bo­dę. To tu budu­je­my war­tość doda­ną jaką jest ofe­ro­wa­ny pro­dukt lub usłu­ga (być może są one uni­kal­ne, chro­nio­ne pra­wem autor­skim lub paten­tem). Na pod­sta­wie powyż­sze­go moż­na stwo­rzyć pewien wzo­rzec: meta-model pro­ce­sów biz­ne­so­wych organizacji. 

    Mapa pro­ce­sów: meta-model pro­ce­sów biz­ne­so­wych orga­ni­za­cji (opra­co­wa­nie własne).

    Meta-model ten zbu­do­wa­ny został jako sys­tem pro­ce­sów end-2-end, czy­li pro­ce­sów, gdzie wej­ścia i wyj­ścia to zda­rze­nia na sty­ku orga­ni­za­cji z jej oto­cze­niem. W tej lub podob­nej posta­ci, dia­gram ten był nie raz oma­wia­ny na tym blo­gu, dla­te­go tu tyl­ko kil­ka ogól­nych uwag. 

    W zależ­no­ści od spe­cy­fi­ki danej orga­ni­za­cji, poka­za­ne tu pro­ce­sy mogą wystę­po­wać jako mniej lub bar­dziej wewnętrz­nie roz­bu­do­wa­ne (mode­lu­je­my je pre­cy­zyj­nie z uży­ciem nota­cji BPMN), nie­któ­re mogą nie wystą­pić (np. fir­ma usłu­go­wa nie ma pro­duk­cji). Gdyby był to urząd, w miej­scu Obsługi zamó­wień poja­wi się obsłu­ga podań i decy­zje admi­ni­stra­cyj­ne (i podob­ne). To pro­ce­sy ope­ra­cyj­ne. Procesy wspie­ra­ją­ce, w tym obsłu­ga rachun­ko­wo­ści i zaso­by oso­bo­we, to cecha każ­dej orga­ni­za­cji czy urzę­du. Nawiązując do archi­tek­tu­ry biz­ne­so­wej, powyż­szy model to war­stwa środ­ko­wa na poniż­szym dia­gra­mie obra­zu­ją­cym pozio­my opi­su orga­ni­za­cji .

    (źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

    System informacyjny

    Pewnym zasko­cze­niem dla czy­tel­ni­ka naj­praw­do­po­dob­niej będzie to, że archi­tek­tu­ra opro­gra­mo­wa­nia wca­le nie musi odwzo­ro­wy­wać powyż­szej mapy pro­ce­sów. Zaryzykuje tezę, że nie mia­ło by to sen­su. Dlaczego? Bo apli­ka­cje to narzę­dzia prze­twa­rza­ją­ce dane a nie uczest­ni­cy pro­ce­sów. pro­ce­sy biz­ne­so­we są nie­za­leż­ne od sys­te­mów IT .

    Modelowanie sys­te­mów IT jako torów w mode­lach pro­ce­sów to jeden z naj­częst­szych błę­dów w analizach!

    Po dru­gie pro­ce­sy biz­ne­so­we sku­pia­ją się na tre­ści doku­men­tów i celu ich two­rze­nia, apli­ka­cje trak­tu­ją je ina­czej: ich deta­licz­na treść ma zna­cze­nie tyl­ko cza­sa­mi i rzad­ko kie­dy cała. Dokumenty two­rzo­ne są w apli­ka­cjach dzie­dzi­no­wych, bar­dzo czę­sto, po powsta­niu, ich treść prze­twa­rza­na jest w innym pro­ce­sie i w innym celu. Nie każ­dy doku­ment ma ści­słą struk­tu­rę. Np. dowo­dy księ­go­we to ści­śle struk­tu­ral­ne doku­men­ty i powsta­ją w dedy­ko­wa­nych apli­ka­cjach, jed­nak zarów­no zapy­ta­nia, ofer­ty czy rekla­ma­cje, tak­że np. umo­wy (w tym umo­wy o pra­cę), to doku­men­ty o dość swo­bod­nej struk­tu­rze i zarzą­dza­my nimi raczej z pomo­cą wybra­nych ich cech (meta­da­ne), bar­dzo rzad­ko ktoś poza czło­wie­kiem wczy­tu­je się w ich treść (maszy­na nie). W efek­cie archi­tek­tu­ra sys­te­mu infor­ma­tycz­ne­go nie będzie odwzo­ro­wy­wa­ła mapy pro­ce­sów, mimo tego, że intu­icyj­nie takie są ocze­ki­wa­nia od dostaw­ców analiz

    Narzędzia w skrzyn­ce narzę­dzio­wej sto­la­rza nie noszą nazw eta­pów pro­duk­cji mebli! Aplikacje to dzie­dzi­no­we narzę­dzia pra­cy, przy czym dzie­dzi­ną nie są tu pro­ce­sy biz­ne­so­we (cel biz­ne­so­wy) a struk­tu­ra danych i ich zna­cze­nie. Innymi sło­wy zarów­no wnio­ski urlo­po­we jak i zapy­ta­nia od klien­tów, to prze­pływ pra­cy i archi­wum doku­men­tów. Wystawienie fak­tu­ry czy doku­men­tu maga­zy­no­we­go, to two­rze­nie spe­cja­li­stycz­nych for­mu­la­rzy, jed­nak ich dal­sze prze­ka­zy­wa­nie (albo przyj­mo­wa­nie np. fak­tur kosz­to­wych) to już tak­że prze­pływ pra­cy i zarzą­dza­nie doku­men­ta­mi jako byta­mi archi­wal­ny­mi. Tu dzie­dzi­no­wość nie pole­ga na tym co i po co robi­my (pro­ce­sy biz­ne­so­we) a na tym, jakie­go rodza­ju dane prze­cho­wu­je­my i prze­twa­rza­my (meta­da­ne). Np. Faktura dla klien­ta, ramo­wa umo­wa na raba­ty z nim, jego rekla­ma­cje, to histo­ria kon­tak­tów z tym klien­tem. Detale struk­tur tych doku­men­tów nie maja tu zna­cze­nia (nie są po raz dru­gi ani zmie­nia­ne ani wery­fi­ko­wa­ne, te doku­men­ty już powsta­ły w apli­ka­cjach im dedy­ko­wa­nych). Dlatego pew­nym ogól­nym wzor­cem archi­tek­tu­ry sys­te­mu IT orga­ni­za­cji, będzie poniż­szy dia­gram :

    Ogólna archi­tec­tu­re sys­te­mu IT orga­ni­za­cji (opra­co­wa­nie własne)

    Można to z powo­dze­niem nazwać: System ERP II. Nie jest to mono­lit, wdra­żać moż­na te modu­ły prak­tycz­nie w dowol­nej kolej­no­ści, są zin­te­gro­wa­ne, dane wpro­wa­dza­my tyl­ko raz. Obecna na ryn­ku stan­da­ry­za­cja powo­du­je, że inte­gra­cja nie sta­no­wi pro­ble­mu. Modułów tych może być wię­cej, a wdro­że­nie takie na pew­no moż­na nazwać zwinnym. 

    Na zakończenie

    Obserwacja ryn­ku poka­zu­je, że podaż dedy­ko­wa­nych modu­łów jest bar­dzo duża, wybór jed­ne­go mono­li­tycz­ne­go sys­te­mu – mimo, że nadal popu­lar­ny – jest dzi­siaj nie­ra­cjo­nal­ny, choć­by z uwa­gi na zmien­ność i ryn­ku i pro­fi­li dzia­ła­nia firm oraz zmien­ność pra­wa. Drugim powo­dem, dla któ­re­go decy­do­wa­nie się na mono­li­tycz­ne sys­te­my jest dużym ryzy­kiem, jest to, że jest to tak­że decy­zja o wdra­ża­niu wszyst­kie­go naraz i z jed­ne­go źró­dła”, co bar­dzo rzad­ko ma obec­nie sens i sta­no­wi ogrom­ne ryzy­ko .

    Źródła

    OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
    Street, K. (2006). Building a Service Oriented Architecture with BPM and MDA. 2(1), 8.
    D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
    BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
    Fill, H.-G. (2020). Enterprise Modeling: From Digital Transformation to Digital Ubiquity. 1 – 4. https://​doi​.org/​1​0​.​1​5​4​3​9​/​2​0​2​0​F​001
    Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.

    Systemy ERP – 2019

    Właśnie MSI opu­bli­ko­wa­ła raport z bada­nia na temat ryn­ku ERP w Polsce. Systemy ERP autor rapor­tu defi­niu­je jako:

    ERP (Enterprise Resource Planning) to infor­ma­tycz­ny sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie zaso­ba­mi przed­się­bior­stwa. Pozwala na reali­za­cję funk­cji kie­row­ni­czych we wszyst­kich obsza­rach funk­cjo­nal­nych fir­my (pro­duk­cja, sprze­daż itd.).?(Abramczyk, 2019)?

    87% respon­den­tów korzy­sta z sys­te­mu ERP, 7% pla­nu­je zakup takie­go, 6% nie pla­nu­je. Ciekawostką jest jed­nak poniż­szy wykres:

    Ciekawe jest pew­na nie­kon­se­kwen­cja u ankie­to­wa­nych: a mia­no­wi­cie zna­jąc powyż­szą defi­ni­cję (była poda­na w ankie­cie): reali­za­cję funk­cji kie­row­ni­czych we wszyst­kich obsza­rach funk­cjo­nal­nych fir­my” 48% ankie­to­wa­nych, czy­li nie­mal­że poło­wa, wska­zu­je jed­no­cze­śnie, że przy wybo­rze istot­ne są moż­li­wo­ści inte­gra­cji z inny­mi sys­te­ma­mi, co prze­czy nie­co tezie, że ERP obsłu­gu­je wszyst­kie obsza­ry zarzą­dza­nia. Słusznie uwa­gę zwra­ca cyto­wa­ny Robert Stiller (Associated Partner w fir­mie Hicron), że istot­ne jest dzi­siaj inte­gro­wa­nie sys­te­mów ERP z nowo­cze­sny­mi roz­wią­za­nia­mi (sze­ro­ko poję­te wypo­sa­że­nie tech­nicz­ne), któ­re w obec­nych cza­sach nie­mal­że w 100% zawie­ra, nie raz bar­dzo zaawan­so­wa­ne, opro­gra­mo­wa­nie, reali­zu­ją­ce funk­cje, któ­re kie­dyś były modu­ła­mi sys­te­mów ERP (np. MES, ASP, inne). 

    Dalej autor­ka zwra­ca uwa­gę na fakt, że 

    … jeśli cho­dzi o naj­waż­niej­sze czyn­ni­ki, któ­re nale­ży uwzględ­nić pod­czas wybo­ru dostaw­cy sys­te­mu ERP, za naj­bar­dziej istot­ne zosta­ły uzna­ne: doświad­cze­nie dostaw­cy (72%), ogól­ne warun­ki współ­pra­cy (68%) oraz warun­ki finan­so­we (48%). Mniejszą uwa­gę klien­ci zwra­ca­ją na pozy­cję dostaw­cy na ryn­ku (26%) oraz mar­kę dostaw­cy (12%).?(Abramczyk, 2019)?

    Tu widać, że sama mar­ka jako taka już nie sta­no­wi aż tak o prze­wa­dze ryn­ko­wej. Myślę, że opi­nia ta to kon­se­kwen­cja pora­żek, od któ­rych nie są wol­ne te mar­ki (np. gło­śna ostat­nio poraż­ka SAP w LIDL).

    Kolejna waż­na kwe­stia to wyar­ty­ku­ło­wa­nie swo­ich potrzeb: 

    Okazuje się, że naj­więk­szy­mi trud­no­ścia­mi, z któ­ry­mi trze­ba się zmie­rzyć pod­czas wdra­ża­nia sys­te­mu ERP, są przede wszyst­kim: zde­fi­nio­wa­nie wyma­gań funk­cjo­nal­nych (71%), inte­gra­cja sys­te­mu ERP z inny­mi sys­te­ma­mi (65%), dosto­so­wa­nie i para­me­try­za­cja sys­te­mu (58%), migra­cja danych (54%) oraz szko­le­nie użyt­kow­ni­ków (45%). Pewne trud­no­ści spra­wia­ją rów­nież wybór dostaw­cy (19%) oraz uru­cho­mie­nie sys­te­mu (16%).?(Abramczyk, 2019)?

    Powyższe jasno poka­zu­je, że klu­czem do suk­ce­su jest opi­sa­nie potrzeb i uzna­nie fak­tu, że poza sys­te­mem ERP są i będą inne (inte­gra­cja). Tu zakoń­czę, nama­wia­jąc do lek­tu­ry cało­ści tego inte­re­su­ją­ce­go tek­stu. Proszę zwró­cić uwa­gę na cie­ka­wy fakt: 71% uwa­ża, że trud­no jest opi­sać wyma­ga­nia a jed­no­cze­śnie tyl­ko 19% uwa­ża, że trud­ny jest wybór dostaw­cy. Zestawiając to z fak­tem, że w więk­szo­ści przy­pad­ków ana­li­zę wyma­gań zle­ca się wybra­ne­mu wyko­naw­cy, widzę tu kolej­ną nie­kon­se­kwen­cję u ankietowanych. 

    Tak więc pole­cam raport, zachę­cam do wła­snych prze­my­śleń, i zapra­szam do dys­ku­sji pod tym artykułem… 

    Źródła:

    1. Abramczyk, A. (2019, June 5). Raport: Systemy ERP. Retrieved June 5, 2019, from MSI Portal website: 

    Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

    Krótki wstęp

    Od cza­su do cza­su są takie momen­ty, że świat pod­su­wa mi goto­we tek­sty do publi­ka­cji. Każdy kto mnie zna i czy­ta wie, że od lat odra­dzam wdra­ża­nie wiel­kich mono­li­tów ERP, uza­sad­nie­nie tego z moich ust naj­czę­ściej jest jed­nak odbie­ra­ne jako moje spe­ku­la­cje (mimo, że zawsze uza­sad­niam swo­je zda­nie a przy­kła­dów nie bra­ku­je). A o tym sądzą dyrek­to­rzy firm?

    Czytaj dalej… Dyrektorzy mówią Dość! Biznes wycho­dzi z objęć mono­li­tycz­ne­go sys­te­mu ERP”

    PERSPEKTYWY 2018 – ERP, CRM, ECM, MRP, Business Intelligence, MRP

    Jako part­ner mery­to­rycz­ny rapor­tu zapra­szam do lektury:

    Rynek jest prak­tycz­nie nasy­co­ny w tym sen­sie, że prak­tycz­nie nie ma już firm nie mają­cych opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie. Tu war­to pod­kre­ślić, że skrót ERP (ang. Enterprise Resource Planning) rozu­mia­ny sze­rzej to nie tyl­ko jeden uni­wer­sal­ny i zin­te­gro­wa­ny pakiet opro­gra­mo­wa­nia jed­ne­go pro­du­cen­ta, to każ­dy sys­tem, mono­li­tycz­ny lub zło­żo­ny z kil­ku zin­te­gro­wa­nych apli­ka­cji, obej­mu­ją­cy swo­im zasię­giem dzia­ła­nia wszyst­kie obsza­ry dzia­ła­nia orga­ni­za­cji. (Jarosław Żeliński IT​-Consulting​.pl) […]
    Trzeba sobie szcze­rze powie­dzieć, że sko­ro peł­na 100% iden­ty­fi­ka­cja potrzeb infor­ma­tycz­nych na wcze­snym eta­pie pro­jek­tu, czy­li szcze­gó­łów gra­ni­czy z cudem, więc meto­dy­ki kla­sycz­ne zwa­ne potocz­nie water­fal­l’o­wy­mi nie pro­wa­dzą nas do suk­ce­su. (Janusz Pieklik, Business Global Consulting Polska, www​.bgc​.com​.pl)

    Polecam cały raport, infor­ma­cje od dostaw­ców opro­gra­mo­wa­nia i dwa duże opra­co­wa­nia o wdro­że­nia dwóch nie­za­leż­nych i doświad­czo­nych eks­per­tów: PERSPEKTYWY 2018 – ERP​-view​.pl – ERP, CRM, ECM, MRP, Business Intelligence, MRP