Przypomnę na począ­tek co pra­wie dwa lata temu napisałem:

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża).

software

Tak więc jed­nak pole­cam: zasta­no­wić się nad potrze­ba­mi, zamó­wić wyko­na­nie ana­li­zy i doku­men­ta­cji wyma­gań i z tym doku­men­tem szu­kać dostaw­cy i nie dać wci­snąć sobie teo­rii, że duży może wię­cej?. Możliwe ale nie zapo­mi­naj­my, że duży to tak­że bez­wład­ny (pole­cam cały arty­kuł: Nigdy wię­cej ERP w jed­nym kawał­ku!)

No i mamy obecnie:

Przedstawiciele co trze­ciej bry­tyj­skiej fir­my (35 proc.) przy­zna­ją, że byli­by skłon­ni zastą­pić wyko­rzy­sty­wa­ny obec­nie sys­tem kla­sy ERP bar­dziej ela­stycz­nym roz­wią­za­niem o podob­nej funk­cjo­nal­no­ści. (źr. Czego naj­bar­dziej bra­ku­je sys­te­mom kla­sy ERP?)

Nasuwa się pyta­nie: czym je zastą­pić? Leży wła­śnie na moim sto­le książ­ka ([[Large-Scale Software Architecture. A prac­ti­cal guide using UML. Jeff Garland, Richard Anthony]]). I co my tu mamy? Przede wszyst­kim opi­nię i wska­zów­ki doświad­czo­nych pro­jek­tan­tów i developerów.

Książka jest tak dobra”, że w zasa­dzie moż­na ją w kawał­kach zacy­to­wać od dechy do dechy. Jednak i nie chce i nie moż­na tego robić :). W czym rzecz?

Duże oprogramowanie to nie jeden system

I tu leży pies pogrze­ba­ny. Kolejność zale­ca­na przez auto­rów książ­ki za każ­dym razem, nie­za­leż­nie od wiel­ko­ści projektu:

  1. ana­li­za i okre­śle­nie celu projektu
  2. ana­li­za biz­ne­so­wa, opra­co­wa­nie wymagań
  3. pro­jekt archi­tek­tu­ry roz­wią­za­nia (ogól­ny model dzie­dzi­no­wy), podział na kom­po­nen­ty (obsza­ry dziedzinowe)
  4. okre­sle­nie, któ­re kom­po­nen­ty (pod­sys­te­my) nale­ży wytwo­rzyć, a któ­re moż­na kupić na ryn­ku (tak zwa­ne COTS, ang. [[Commercial off-the-shelf]])
  5. spraw­dze­nie dostęp­no­ści i kosztów
  6. opra­co­wa­nie wyni­ko­we­go pro­jek­tu i wyma­gań na pod­sys­te­my dedykowane.

Praktyka poka­zu­je, że jed­nym z takich dużych COTS może być (i czę­sto jest) sys­tem ERP (jego wybra­na część). Najczęściej modu­ły pro­duk­cji, księ­gi głów­nej, kadro­we itp. Jednak zarzą­dza­nie sprze­da­żą czy spe­cy­fi­ka pro­ce­sów wewnątrz orga­ni­za­cji to coś co spę­dza sen z powiek dostaw­ców ERP bo to zawsze nie pasu­je”. Największym zaś, w moich oczach, nad­uży­ciem ofert na ERP jest twier­dze­nie, że wspo­ma­ga­ją zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi. Bo jeśli poma­ga­ją zarzą­dzać doku­men­ta­mi, co jest praw­dą, to raczej nie są w sta­nie kon­ku­ro­wać z sys­te­ma­mi work-flow bo to zupeł­nie inne­go rodza­ju sys­te­my i nie przy­pad­kiem powsta­ły jako oddziel­ne roz­wią­za­nia. Do tego doku­men­ty finan­so­wo-maga­zy­no­we to mniej­sza część wszyst­kich doku­men­tów w fir­mie, więc dla­cze­go ERP miał by być tu dobry”? A hur­tow­nie danych? To tak­że nie przy­pa­dek, że są osob­ny­mi sys­te­ma­mi. Dostawcy ERP per­ma­nent­nie uży­wa­ją akro­ni­mu Moduł BI w swo­ich ofer­tach zaś cicha­czem ofe­ru­ją dedy­ko­wa­ne sys­te­my BI i inte­gru­ją je.

Tak więc naj­czę­ściej oka­zu­je się, że nie­ste­ty głów­ną wadą sys­te­mów zin­te­gro­wa­nych ERP jest to, że są zin­te­gro­wa­ne (czy­taj nie­po­dziel­ne) co już nie raz tu pisa­łem i wycho­dzi, że nie ja jeden.

W ubie­głym roku skoń­czy­łem pro­jekt dla fir­my [[Galeco Sp. z o.o.]]. W dużym uprosz­cze­niu pro­jekt wyglą­dał tak:

  1. Analiza biz­ne­so­wa: model biz­ne­so­wy, opty­ma­li­za­cja pro­ce­sów, okre­śle­nie klu­czo­wych czyn­ni­ków sukcesu,
  2. Określenie wyma­gań na opro­gra­mo­wa­nia w kon­tek­ście klu­czo­wych czyn­ni­ków sukcesu.
  3. Opracowanie archi­tek­tu­ry sys­te­mu infor­ma­cyj­ne­go Galeco.
  4. Wskazanie miejsc, w któ­rych moż­na użyć goto­we­go oprogramowania
  5. Zaprojektowanie wyma­gań na opro­gra­mo­wa­nie (pod­sys­te­my itp.), któ­re są potrzeb­ne Galeco a nie są dostęp­ne jako goto­we na rynku.

I ta wła­snie kolej­ność jest lep­sza. Pozornie to samo osią­gnie­my gdy wpu­ści­my dostaw­cę sys­te­mu ERP i on po ana­li­zie powie cze­go (jakich wyma­gań) jego sys­tem nie reali­zu­je. Jednak:

  1. Dostawca goto­we­go sys­te­mu nie ma żad­nej moty­wa­cji (wręcz prze­ciw­nie) do wska­zy­wa­nia innych niż swo­je roz­wią­zań (stąd per­ma­nent­nie poja­wia­ją się w ofer­tach i pro­jek­tach tak zwa­ne kasto­mi­za­cje, któ­re są powszech­nie ofe­ro­wa­ne przez sprze­daw­ców a odra­dza­ne przez pro­du­cen­tów tego opro­gra­mo­wa­nia ERP).
  2. U dostaw­cy ERP natych­miast poja­wia się syn­drom młot­ko­we­go: jak ktoś ma w ręku mło­tek natych­miast wszyst­ko co zoba­czy koja­rzy mu się z gwoździem.

Wystarczy odwró­cić kolej­ność dzia­łań: zamiast wybie­rać dostaw­cę ERP, któ­ry powie na czym wymię­ka jego sys­tem, war­to naj­pierw zapro­jek­to­wać całość a potem popy­tać kto i w czym czu­je się świet­nie. Tu jed­nak poja­wia się pro­blem: dostaw­ca goto­we­go sys­te­mu nie zaro­bi na kasto­mi­za­cji ale chy­ba o to cho­dzi by było od razu dobre a nie w nie­skoń­czo­ność dostosowywane.

Dlaczego pro­du­cen­ci odra­dza­ją (meto­dy­ki zale­ca­ne przez pro­du­cen­tów nie sto­so­wa­ne w Polsce!) inge­ren­cje w ich goto­we opro­gra­mo­wa­nie? Bo taka inge­ren­cja odci­na natych­miast użyt­kow­ni­ka od moż­li­wo­ści wyko­na­nia pro­ste­go upgra­de­’u! Kolejna, nowa wer­sja sys­te­mu wdro­żo­ne­go z tak dużym tru­dem (i kosz­tem) kasto­mi­za­cji wyma­ga kom­plet­ne­go pro­jek­tu od zera, powtó­rze­nia od począt­ku całej pier­wot­nej pra­cy nad wdrożeniem.

Jak tego unik­nąć? To pro­ste, posłu­chać pro­du­cen­tów opro­gra­mo­waw­szy ERP:

  1. Opracować wła­sne wymagania.
  2. Dać dostaw­com sys­te­mów ERP by wyko­na­li tak zwa­ną ana­li­zę gap/fit (co nasz sys­tem ma a cze­go nie ma).
  3. Wybrać naj­ko­rzyst­niej­szą ofer­tę, wdro­żyć sys­tem szyb­ko (bo bez kastomizacji).
  4. Zaprojektować bra­ku­ją­ce funk­cjo­nal­no­ści i zamó­wić ich imple­men­ta­cję, zin­te­gro­wać z dostar­czo­nym ERP.

Teraz upgra­de ERP to pro­ste wgra­nie nowej wer­sji (no pra­wie ale o nie­bo łatwiej i taniej!) Po dru­gie nie nara­ża­my się na pre­sję dostaw­cy ERP i nie uza­leż­nia­my od nie­go w 100% (zja­wi­sko okre­śla­ne jako «ven­dor lock-in». Tak zapro­jek­to­wa­ny sys­tem sta­je się sys­te­mem otwar­tym, pozwa­la­ją­cym wymie­nić lub dodać funk­cjo­nal­no­ści bez inge­ren­cji w pozo­sta­łe. I nie­za­leż­nie od tego jak uni­wer­sal­ny” jest sys­tem ERP zawsze będzie gor­szy od kil­ku dobrze dobra­nych ale nie­za­leż­nych kom­po­nen­tów. Gorszy nie dla­te­go, że brzyd­szy” ale dla­te­go, że będzie kulą u nogi fir­my, któ­ra powin­na jed­nak reago­wać na zmia­ny na ryn­ku w cią­gu tygo­dni a nie lat… Po dru­gie mody­fi­ka­cja jakie­go­kol­wiek opro­gra­mo­wa­nia zawsze wyma­ga testo­wa­nia cało­ści, tak więc im mniej­sze kawał­ki mamy tym szyb­ciej i taniej wpro­wa­dza się do nich zmia­ny bo ich odda­nie do użyt­ku po mody­fi­ka­cji jest łatwiej­sze i szyb­sze zarazem.

Pamiętajmy pew­ną sta­rą rekla­mę: Banki od wszyst­kie­go są do niczego”.…

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.

Ten post ma 3 komentarzy

    1. Jarek Żeliński

      Faktycznie APS to kolej­ny klo­cek ERP (zapew­ne jako COTS) i war­to o nim napi­sać. Pojawia się jed­nak dodat­ko­wa potrze­ba: oddzie­le­nie ser­wi­sów biz­ne­so­wych jako takich od ich zło­żo­no­ści bo pomie­sza­nie tych dwóch obsza­rów pro­wa­dzi do błęd­nych wnio­sków, że dwa sys­te­mu o porów­ny­wal­nej licz­bie linii kodu są porów­ny­wal­nie zło­żo­ne z per­spek­ty­wy biz­ne­so­wej a to nie praw­da. Prosty przy­kład: sys­tem BI (Business Inteligence i w tym hur­tow­nia danych) do pro­gno­zo­wa­nia obro­tów ma jed­ną głów­ną funk­cjo­nal­ność: wyli­czyć pro­gno­zę sprze­da­ży za dany okres i będzie miał jed­ne­go użyt­kow­ni­ka (akto­ra): ana­li­ty­ka. System zarzą­dza­ją­cy repo­zy­to­rium doku­men­tów i ich prze­pły­wem w zasa­dzie nicze­go nie liczy za to ma dzie­siąt­ki akto­rów i dzie­siąt­ki funk­cjo­nal­no­ści. Złożoność każ­de­go z nich jest duża ale leży w zupeł­nie innych obsza­rach. W przy­pad­ku porów­na­nia ERP i APS widzę to podob­nie. ERP to zarzą­dza­nie zaso­ba­mi, APS to jeden (waż­ny ale jed­nak jeden) z aspek­tów zarzą­dza­nia nimi.

    2. Wit Jakuczun

      Problem z APS jest taki, że jest to jed­nak szcze­gól­ny typ pro­duk­tów gdyż wyma­ga dość spe­cja­li­zo­wa­nej wie­dzy (mate­ma­tycz­nej) od stro­ny dostaw­cy. Prace pro­gra­mi­stycz­ne są dość małej zło­żo­no­ści. Mi wycho­dzi, że oko­ło 10% całe­go pro­jek­tu sta­no­wią pra­ce zespo­łu robią­ce­go moduł ana­li­tycz­ny. Mówię oczy­wi­ście o programowaniu. 

      Nie mniej jed­nak, moje doświad­cze­nie jest takie, że prze­cięt­na fir­ma infor­ma­tycz­na nie dys­po­nu­je odpo­wied­ni­mi kom­pe­ten­cja­mi aby z suk­ce­sem wyko­nać pro­jekt, któ­ry wyma­ga roz­wią­za­nia zło­żo­nych pro­ble­mów obli­cze­nio­wych (sło­wo klucz: NP-trud­ne). Co nie dzi­wi bo tego się nigdzie nie uczy… 

      Jest takie poję­cie jak LSCO (Large Scale Combinatorial Optimization). Powstała nawet meto­dy­ka wdra­ża­nia roz­wią­zań zawie­ra­ją­cych takie ele­men­ty. Na google moż­na zna­leźć tro­chę mate­ria­łów jak to kogoś interesuje.

      W ogól­no­ści APS nale­żą do szer­szej kla­sy sys­te­mów wspo­ma­ga­nia decy­zji. I w peł­ni się zga­dzam, że to po pro­stu kolej­ny klo­cek obu­do­wu­ją­cy ERPa. Ja zawsze zaczy­nam roz­mo­wę z klien­tem od pyta­nia czy ma ERPa i jak nie ma to pro­szę o zakup a dopie­ro potem o powrót do roz­mów o bar­dziej zaawan­so­wa­nych rozwiązaniach.

Dodaj komentarz

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