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).

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”.…