Jeśli histo­ria uczy cze­go­kol­wiek, to tyl­ko tego, że ludzie nigdy nicze­go się nie nauczy­li z historii.

Aleksander Krawczuk, Poczet cesa­rzy rzymskich

Szaleństwem jest robić wciąż to samo i ocze­ki­wać róż­nych rezultatów

Albert Einstein

Wprowadzenie

Duże pro­jek­ty tech­no­lo­gicz­ne naj­czę­ściej koń­czą się nie­po­wo­dze­niem. Czy ist­nie­je spo­sób na zmniej­sze­nie praw­do­po­do­bień­stwa nie­po­wo­dze­nia? Tak: nale­ży przyj­rzeć się pro­ble­mom zwią­za­nym z defi­ni­cją, zakre­sem i zarzą­dza­niem, ale nie nale­ży zbyt uważ­nie przy­glą­dać się pro­ble­mom zwią­za­nym z talen­ta­mi, wspar­ciem kadry kie­row­ni­czej i kul­tu­rą kor­po­ra­cyj­ną. Są one pra­wie nie­moż­li­we do rozwiązania.

https://www.forbes.com/sites/steveandriole/2021/03/25/3‑main-reasons-why-big-technology-projects-fail — why-many-companies-should-just-never-do-them/

Przyczyny pora­żek wdro­żeń sys­te­mów ERP są sta­le te same od lat: łama­nie zasad. Jakie to zasa­dy? Generalnie:

1. dostaw­ca ERP nie powi­nien zarzą­dzać całym pro­jek­tem ani zakre­sem pro­jek­tu (kon­flikt interesu),
2. nie nale­ży inge­ro­wać w struk­tu­rę kodu mono­li­tycz­ne­go sys­te­mu (kasto­mi­za­cja),
3. nie nale­ży udo­stęp­niać bazy danych innym apli­ka­cjom, inte­gra­cje nale­ży reali­zo­wac wyłącz­nie poprzez API,
4. nale­ży chro­nić swo­je know-how zapew­nia­jąc sobie pra­wa mająt­ko­we­go do każ­dej dedy­ko­wa­nej czę­ści systemu/kodu.

I nie­ste­ty za każ­dym razem wnio­sek jest ten sam: nie bra­ku­je dostę­pu do wie­dzy jak tego nie robić, a mimo to nabyw­cy sys­te­mów ERP (ich praw­ni­cy tak­że) popeł­nia­ją wszyst­kie klu­czo­we błę­dy .

Pierwszy punkt jest klu­czo­wy, dla­te­go na czas pro­jek­tu nale­ży zaan­ga­żo­wać eks­per­ta po swo­jej stro­nie. Często moż­na usły­szeć: zatrud­nij­cie ​„kon­sul­tan­ta ERP”, jed­nak poja­wia sie pyta­nie kto to taki? Pod poję­ciem ​„kon­sul­tant ERP” bar­dzo czę­sto spo­ty­ka się oso­by spe­cja­li­zu­ją­ce się we wdra­ża­niu jed­ne­go kon­kret­ne­go sys­te­mu. Taka oso­ba raczej sprze­da­je kon­kret­ny sys­tem, bo nie poma­ga w wybo­rze naj­wła­ściw­sze­go spo­śród wie­lu dostęp­nych na ryn­ku. Jeżeli ​„kon­sul­tan­ta ERP” zapew­nia od razu skła­da­ją­cy ofer­tę dostaw­ca okre­ślo­ne­go sys­te­mu ERP, jest to po pro­stu wdrożeniowiec. 

Wybór odpo­wied­nie­go sys­te­mu ERP i jego dostaw­cy jest kry­tycz­nym kro­kiem w każ­dym pro­jek­cie trans­for­ma­cji cyfro­wej. Powinien to jed­nak być dru­gi krok. Pierwszym jest ana­li­za biz­ne­so­wa i przy­go­to­wa­nie wymagań. 

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

W efek­cie pro­jekt taki sku­pia się od począt­ku na dopa­so­wy­wa­niu przed­wcze­śnie wybra­ne­go sys­te­mu, zamiast naj­pierw opra­co­wać wyma­ga­nia i przy­go­to­wać się wewnętrz­nie do wdro­że­nia. Kilka spo­strze­żeń na ten temat w arty­ku­le: Kto winien poraż­ki projektu?

Jeżeli wdrożenie jest w toku…

…kolej­ny raz prze­kro­czo­no ter­min i budżet, to masz pro­blem. Nadal coś nie dzia­ła tak jak powin­no, to masz problem. 

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­że­nia lub zmia­na sys­te­mu bo cza­sa­mi naj­lep­szym wyj­ściem oka­zu­je się wyj­ście z posiadanego/wdrażanego sys­te­mu ERP z mini­mal­ny­mi stratami. 

Co moż­na wte­dy zro­bić? Proponuję:

1. Zrewidowanie dotych­cza­so­we­go podej­ścia do wdro­że­nia i zarzą­dza­nia zmia­ną (jeden mono­li­tycz­ny ERP to myśle­nie życze­nio­we, uzna­nie, że jeden sys­tem nada­je sie do wszyst­kie­go w fir­mie, jest w obec­nych cza­sach jest uto­pią).
2. Przygotowanie cze­goś wię­cej niż tyl­ko jego luź­ny szkic sta­nu docelowego.

Na pyta­nie Co Pan pro­po­nu­je na począ­tek, zawsze odpowiadam:

Najogólniej trze­ba by oprzeć sie na doku­men­tach ope­ra­cyj­nych, na to nało­żyć ich treść (dane) i zma­po­wać na posia­da­ne apli­ka­cje (i ich dostaw­ców, to są ich obo­wiąz­ki). Być może wystar­czy tyl­ko upo­rząd­ko­wać aktu­al­ny stan wdro­że­nia i integracji.

Masz ochotę jeszcze czytać? Skąd te problemy…

Architektura opro­gra­mo­wa­nia, jej pro­jek­to­wa­nie, to doko­ny­wa­nie fun­da­men­tal­nych wybo­rów struk­tu­ral­nych, któ­rych zmia­na po wdro­że­niu jest kosz­tow­na. Wybory archi­tek­tu­ry opro­gra­mo­wa­nia obej­mu­ją okre­ślo­ne opcje struk­tu­ral­ne z moż­li­wo­ści w pro­jek­cie oprogramowania. 

Architektura sys­te­mu opro­gra­mo­wa­nia jest meta­fo­rą, ana­lo­gicz­ną do archi­tek­tu­ry budynku[3]. Funkcjonuje ona jako plan sys­te­mu i pro­jek­tu dewe­lo­per­skie­go, któ­ry kie­row­nic­two pro­jek­tu może póź­niej wyko­rzy­stać do eks­tra­po­la­cji zadań nie­zbęd­nych do wyko­na­nia przez zaan­ga­żo­wa­ne zespo­ły i ludzi.

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 pra­co­chłon­ność usu­wa­nia skut­ków tych ingerencji. 

Najbardziej zna­ne na ryn­ku sys­te­my ERP maja archi­tek­tu­rę z cza­sów gdy powsta­wa­ły (lata 80-te):

Są to sys­te­my budo­wa­ne w opar­ciu o cen­tral­ną bazę danych, bar­dzo skom­pli­ko­wa­ne, z sil­nie powią­za­ny­mi ze sobą kom­po­nen­ta­mi. Typowe pro­ble­my w toku wdro­żeń takich systemów:

• każ­da mody­fi­ka­cja kosz­tu­je kil­ka-kil­ka­na­ście tysię­cy zł,
• każ­da mody­fi­ka­cja to ryzy­ko naru­sze­nia inte­gral­no­ści całości,
• każ­da lokal­na mody­fi­ka­cja prze­no­si sie na resz­tę sys­te­mu (wspól­na baza danych),
• nie da się oddzie­lić od sie­bie modułów,
• mono­pol jed­ne­go dostaw­cy, któ­ry zacznie Ci dyk­to­wać ceny,
• wspól­na baza danych (model danych) jest kom­pro­mi­sem, dla­te­go bar­dzo czę­sto pew­nych funk­cjo­nal­no­ści jest po pro­stu niemożliwe.

Już od koń­ca lat 90-tych mówi się o odej­ściu od tej archi­tek­tu­ry, gdyż jaka­kol­wiek inge­ren­cja w taki sys­tem to ogrom­ne ryzy­ko jego desta­bi­li­za­cji. Na ryn­ku od lat powsta­ją dzie­dzi­no­we spe­cja­li­zo­wa­ne sys­te­my z wbu­do­wa­ny­mi opcja­mi inte­gra­cji (inter­fej­sy API: RPC, REST, SOAP itp.). Dlatego popu­lar­ną i sku­tecz­ną for­mą wdra­ża­nia ​„sta­rych” ERP jest wyko­rzy­sty­wa­nie ich tyl­ko w wąskim zakre­sie (cen­tral­ne ope­ra­cje admi­ni­stra­cyj­ne). Podobnie wyglą­da ​„rato­wa­nie” tych wdro­żeń: rezy­gnu­je­my z modu­łów wyma­ga­ją­cych kasto­mi­za­cji na rzecz wol­no­sto­ją­cych inte­gro­wa­nych spe­cja­li­zo­wa­nych, dzie­dzi­no­wych apli­ka­cji dobra­nych do naszych potrzeb. Architektura taka wyglą­da jak poniżej:

Najnowocześniejszym podej­ściem jest to, co dziś nazy­wa­my fede­ra­cyj­nym wdro­że­niem dzie­dzi­no­wych kom­po­nen­tów: zestaw zin­te­gro­wa­nych apli­ka­cji dobra­nych do potrzeb kon­kret­nej fir­my. Na ryn­ku jest obec­nie ogrom­ny wybór spe­cja­li­zo­wa­nych apli­ka­cji bar­dzo łatwych do inte­gra­cji. Architektura takie­go sys­tem wyglą­da jak poniżej:

Taki sys­tem moż­na wdra­żać stop­nio­wo, decy­zje o wybo­rze kolej­nych modu­łów podej­mo­wa­ne są ​„na ostat­ni moment”, czy­li wte­dy gdy mamy naj­więk­szą wie­dzę. Bardzo czę­sto oka­zu­je się też, że posia­da­ny i wdro­żo­ny sys­tem FK nie wyma­ga wymia­ny (jeden z moich klien­tów ma potęż­ny sys­tem pro­duk­cyj­ny MES-APS zin­te­gro­wa­ny z poczci­wą Comarch OPTIMA). 

Zawieranie umów

Kilka porad, któ­re ura­to­wa­ły pie­nią­dze i wdro­że­nia u wie­lu moich klientów:

1. nale­ży ści­śle prze­strze­gać sepa­ra­cji tre­ści umo­wy od opi­su przed­mio­tu umo­wy, któ­ry powi­nien być w 100% odręb­ną tre­ścią w posta­ci załącz­ni­ka do tej umowy,
2. opis przed­mio­tu umo­wy to opra­co­wa­nie inży­nier­skie a nie prawne.

Umowy na wdra­ża­nie opro­gra­mo­wa­nia są szcze­gól­nie trud­ne z dwóch klu­czo­wych powodów:

• pro­dukt jest uwa­ża­ny za nie­ma­te­rial­ny (a to nie jest prawda),
• z pro­duk­tem pra­wie zawsze wią­że się spe­cja­li­stycz­na usługa.

Nigdy nie pod­pi­suj umo­wy na ​„dosta­wę opro­gra­mo­wa­nia” czy ​„wdro­że­nie opro­gra­mo­wa­nia”. Powodem jest to, że tak na praw­dę celem jest kom­pu­ter wraz z tym do cze­go nam słu­ży: ludzie uży­wa­ją kom­pu­te­ra, a nie ​„opro­gra­mo­wa­nia” (ono się wyko­nu­je w kom­pu­te­rze bo jest jego częścią).

W kon­se­kwen­cji żaden kod źró­dło­wy nie jest Twoim celem, a posia­da­nie tego kodu np. na CD, NICZEGO Ci nie daje, bo opro­gra­mo­wa­nie się wyko­nu­je w okre­ślo­nym śro­do­wi­sku, to że masz ​„swój kod” nie ozna­cza, że ​„masz cze­go uży­wać”, bo uży­wać możesz kom­pu­te­ra (sprzęt, spe­cy­ficz­ne śro­do­wi­sko wyko­naw­cze itp.) a nie kodu.

Pisałem o tym 12 lat temu z inne­go powo­du w tek­ście Sprzedam Ci pra­wa do kodu czy­li wiel­ka ście­ma.

Praktycznie każ­dy zakup sys­te­mu (ERP, CRM itp..) to tak­że usłu­gi i warun­ki ich świad­cze­nia zwa­ne SLA (Service-Level Agreement). Ale to tak­że jest Przedmiot Umowy a nie Umowa.

Powyższe doty­czy oczy­wi­ście tak­że umów na wyko­na­nie dedy­ko­wa­ne­go oprogramowania.

Proszę pamię­tać, że rolą praw­ni­ka w pro­jek­cie jest bycie praw­ni­kiem, a nie pro­jek­tan­tem sys­te­mów i powią­za­nych z nimi spe­cja­li­stycz­nych usług. To co widu­ję w tre­ści umów: defi­ni­cje sys­te­mów, uste­rek (moje ulu­bio­ne to uszko­dze­nia nie­kry­tycz­ne i obej­ścia) bywa dra­ma­tem i przy­czy­ną kło­po­tów. Umowa powin­na okre­ślać Warunki płat­no­ści, ter­mi­ny dostaw, kary umow­ne itp. ale NIGDY tego co jest jej przed­mio­tem (nie licząc oczy­wi­ście para­gra­fu mówią­ce­go, że przed­miot umo­wy został opi­sa­ny w załączniku).

Nie pozwól by w Twojej umo­wie zna­la­zły się takie ​„klau­zu­le w umo­wach IT”.

Oferta

Polecam opis: Jak wyjść z dłu­gu tech­no­lo­gicz­ne­go jakim jest cen­tral­ny mono­li­tycz­ny sys­tem.

Umowa ze mną obejmuje:

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. jeże­li umo­wa jest w toku: 
   • 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),
   • 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).
4. jeże­li wdro­że­nie jest dopie­ro planowane: 
   • wyko­na­nie pkt. 1. i 2. i wybór dostawcy
5. może to być umo­wa z dowol­ną ze stron lub wyżej opi­sa­na umo­wa trójstronna.

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

Źródła