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:

• prze­ka­za­nie zarzą­dza­nia pro­jek­tem w ręce dostaw­cy ERP,
• inge­ro­wa­nie w struk­tu­rę mono­li­tycz­ne­go kod sys­te­mu (kasto­mi­za­cja),
• inte­gra­cja meto­dą współ­dzie­le­nia jed­nej bazy danych (to sta­ra i obec­nie nie­efek­tyw­na meto­da z cza­sów lokal­nych sys­te­mów i bra­ku komu­ni­ka­cji elektronicznej), 
• kon­se­kwen­cja kasto­mi­za­cji: pra­wa mająt­ko­we do know-how nabyw­cy zosta­wia­ją przy dostaw­cy kasto­mi­zo­wa­ne­go systemu.

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 . Dlatego nie nale­ży prze­ka­zy­wać zarzą­dza­nia pro­jek­tem dostaw­com sys­te­mów, dla prze­ciw­wa­gi nale­ży na czas pro­jek­tu zaan­ga­żo­wać eks­per­ta po swo­jej stro­nie. Większe fir­my, powin­ny w cza­sie pro­jek­tu budo­wać swój zespół kom­pe­ten­cyj­ny, by prze­jął projekt. 

Jak nale­ży rato­wać wadli­we wdro­że­nia? Autorzy jed­ne­go z rapor­tów Panorama Consulting zale­ca­ją mię­dzy innymi:

Praca z (wła­ści­wy­mi) kon­sul­tan­ta­mi zewnętrz­ny­mi
Projekty ERP mogą zakoń­czyć się nie­po­wo­dze­niem, ponie­waż zespo­ły pra­cu­ją­ce nad nimi są po pro­stu zbyt bli­sko pra­cy, aby dostrzec poja­wia­ją­ce się zagro­że­nia. Jednak nawet fir­my, któ­re anga­żu­ją zewnętrz­ny nad­zór, mogą doświad­czyć nie­po­wo­dze­nia. Niektórzy kon­sul­tan­ci ERP mogą nie być naj­le­piej dopa­so­wa­ni do Twojej orga­ni­za­cji. W rze­czy­wi­sto­ści ich ​„pomoc” może zaszko­dzić postę­pom, a nawet może być przy­czy­ną niepowodzenia.

źr.: https://​www​.pano​ra​ma​-con​sul​ting​.com/​h​o​w​-​t​o​-​r​e​c​o​v​e​r​-​f​r​o​m​-​a​-​f​a​i​l​e​d​-​s​o​f​t​w​a​r​e​-​i​m​p​l​e​m​e​n​t​a​t​i​o​n​-​g​e​t​-​b​a​c​k​-​o​n​-​t​r​a​ck/

Dlatego tak waż­ne jest spraw­dze­nie nie­za­leż­no­ści i dotych­cza­so­we­go dorob­ku takiej oso­by. Ale po kolei.

Gotowana żaba

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

Pewnego razu w pew­nej dys­ku­sji, pewien Pan napisał:

W teo­rii infor­ma­cji od dzie­siąt­ków lat zwra­ca się uwa­gę na feno­men pole­ga­ją­cy na tym, że naj­waż­niej­sze zmia­ny w rze­czy­wi­sto­ści publicz­nej nie mają wiel­kiej lub zgo­ła żad­nej publicz­nej nośno­ści, ponie­waż nie wią­żą się z żad­nym kon­kret­nym zda­rze­niem, któ­re moż­na dobrze sprzedać

Odpowiedziałem:

Zwrócił Pan uwa­gę na waż­ną rzecz i ma ona dość pro­ste wyja­śnie­nie, tak­że na grun­cie teo­rii informacji:

• infor­ma­cja to wia­do­mość o zaist­nie­niu faktu,
• war­tość (mia­ra) okre­ślo­nej infor­ma­cji jest odwrot­nie pro­por­cjo­nal­na do praw­do­po­do­bień­stwa wystą­pie­nia fak­tu jaki opi­su­je (teo­ria komunikacji),
• ludzie są wyczu­le­ni na infor­ma­cje dla nich ​„war­to­ścio­we”,
• powol­ne zmia­ny (infor­ma­cje o nich) nigdy nie są war­to­ścio­we i nośne bo nie są żad­nym zaskoczeniem,
• dla­te­go drob­ne zmia­ny nie są zauważane.

Powyższe ma tak­że zna­ną meta­fo­rę, jaką jest tak zwa­ne goto­wa­nie żaby: nie jest dla niej zasko­cze­niem powo­li nara­sta­ją­ca tem­pe­ra­tu­ra wody, zasko­cze­niem jest zbyt póź­ne odkry­cie że woda wrze (zasko­cze­niem było też by wrzu­ce­nie jej znie­nac­ka od razu do gorącej).

Tak samo dzia­ła powol­ne ​„doje­nie” Zamawiającego w toku wdro­że­nia i eks­plo­ata­cji sys­te­mu ERP, bo odby­wa sie na iden­tycz­nej zasa­dzie: mie­siąc po mie­sią­cu reali­zo­wa­ne są kolej­ne drob­ne popraw­ki i wyma­ga­nia, nadal nic nie dzia­ła jak powin­no, i nagle po kil­ku latach goto­wa­nia, żaba zwa­na Nabywcą Systemu ERP odkry­wa, że jest ugo­to­wa­na i chce iść do sądu, rzecz w tym, że czę­sto jest już za póź­no, ?.. bo jest już ugotowana. 

Przyczyny kłopotów

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

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 wcze­śniej przy­go­to­wa­ne, nie. To przy­go­to­wa­nie to audyt pro­ce­sów i ewen­tu­al­ne przy­go­to­wa­nie zale­ca­nych stan­da­ry­za­cji i opty­ma­li­za­cji. Zarząd (jego bez­po­śred­nie zaan­ga­żo­wa­nie) jest wyma­ga­ny tyl­ko do zatwier­dze­nia doku­men­tu audy­tu, ana­li­zy i pro­jek­tu roz­wią­za­nia, potem już tyl­ko obser­wu­je. Kogo stać na zaan­ga­żo­wa­nie Zarządu w bie­żą­ce pra­ce wdrożeniowe?

Jednak:

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. 

Bo jest to myśle­nie życze­nio­we. Uznanie zaś, że jeden sys­tem nada­je sie do wszyst­kie­go w fir­mie, jest w obec­nych cza­sach jest uto­pią.

Niestety pro­ble­ma­tycz­ne wdro­że­nia sys­te­mów ERP, jak już na począt­ku wspo­mnia­no, 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. 

Architektura systemów w XXI w.

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.

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

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 nie raz cał­kiem 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ę dzieje? 

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 .

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, to kil­ka­na­ście powią­za­nych ze sobą mode­li miesz­czą­cych się góra na kil­ku­dzie­się­ciu stro­nach wydru­ku A4 (model jako cyfro­wy bliź­niak orga­ni­za­cji). Każda zmia­na sys­te­mu infor­ma­tycz­ne­go to ryzy­kow­na decyzja. 

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 wie­dzy o orga­ni­za­cji”: 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 wdro­żeń mono­li­tycz­nych sys­te­mów ERP jest ich kasto­mi­za­cja (inge­ren­cja w kod): 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 dobrej mapy pro­ce­sów nie mamy poję­cia jak jeden dział fir­my (i moduł) wpły­wa na inny. Warto mieć świa­do­mość, że baza danych duże­go mono­li­tu ERP to ponad tysiąc połą­czo­nych ze sobą i sil­nie zależ­nych od sie­bie, tabel. Każde inge­ren­cja w taki sys­tem to pra­wie pew­ne kło­po­ty (u pro­du­cen­ta taki sys­tem prze­cho­dzi tysią­ce godzin testów). 

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 (opi­nia pry­wat­na). 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. 

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). Brakujące funk­cjo­nal­no­ści to obszar 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 pra­co­chłon­ność usu­wa­nia skut­ków tych ingerencji. 

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 pra­ca­mi dostaw­ców. 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, korzy­sta­nie z dużej licz­by drob­nych nie­zin­te­gro­wa­nych, 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 otwar­cia bez oce­nia­nia któ­rej­kol­wiek ze stron. 

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

A może inaczej: mediacje

Są dwa klu­czo­we momen­ty rato­wa­nia wdro­że­nia opro­gra­mo­wa­nia: 1. zarza­dza­nie ryzy­kiem na eta­pie pla­no­wa­nia pro­jek­tu oraz 2. media­cje na eta­pie kon­flik­tu stron umo­wy na wdro­że­nie. Mediacje są defi­nio­wa­ne jako: pośred­ni­cze­nie w spo­rze mają­ce na celu uła­twie­nie stro­nom doj­ście do poro­zu­mie­nia. Kolejny fakt: <10% pro­jek­tów śred­nich i dużych koń­czy się w pla­no­wa­nym ter­mi­nie i budże­cie .

To zna­czy, że ponad 90% wdro­żeń to spo­ry! W zna­ko­mi­tej więk­szo­ści jest to już spór o treść umo­wy na eta­pie jej zawie­ra­nia, mię­dzy Zamawiającym a Dostawcą oprogramowania. 

Celem wdro­że­nia opro­gra­mo­wa­nia jest (powin­na być) satys­fak­cja obu stron, a nie tyl­ko tej, któ­ra przy­ję­ła wyna­gro­dze­nie i nie ponie­sie skut­ków ewen­tu­al­nej poraż­ki (tu zawsze prze­gry­wa tyl­ko kupujący). 

Co to zna­czy? To zna­czy, że war­to już na samym począt­ku roz­wa­żyć umo­wę trój­stron­ną. Może ona nie mieć w nazwie sło­wa Mediacje, cel jest ten sam: obie stro­ny dążą do ugo­dy jaką jest spraw­ne i płyn­ne wdro­że­nie. Przedmiotem ​„spo­ru” jest kon­flikt inte­re­su, czy­li zakres pro­jek­tu i spo­sób jego reali­za­cji: kupu­ją­cy chce jak naj­wię­cej za jak naj­mniej zaś dostaw­ca chce dostar­czyć jak naj­mniej za jak najwięcej. 

Więc anga­żu­je­my trze­cią stro­nę i współ­pra­ca ta jest dobro­wol­nym zobo­wią­za­niem stron, w ramach któ­re­go zain­te­re­so­wa­ni zapew­nia­ją się nawza­jem, iż będą dąży­li do wypra­co­wa­nia kom­pro­mi­su zado­wa­la­ją­ce­go w rów­nym stop­niu obie stro­ny kon­flik­tu. Kto poma­ga ten kom­pro­mis osią­gnąć? Niezależny ana­li­tyk-pro­jek­tant roz­wią­za­nia, któ­re­go celem jest pogo­dze­nie stron mają­cych ww. kon­flikt inte­re­su: to on, wraz z Nabywcą opro­gra­mo­wa­nia opra­co­wu­je Wymagania czy­li Zakres Projektu, a potem bie­rze udział w oce­nie Koncepcji Wdrożenia jaka przed­sta­wia Dostawca. Od tego momen­tu pra­cu­je na rzecz suk­ce­su wdro­że­nia czy­li na rzecz obu stron.

Wdrożenie tego podej­ścia pole­ga na opra­co­wa­niu wyma­gań (tu jest to pro­jekt roz­wią­za­nia) jako załącz­ni­ka do umo­wy na wdro­że­nie, a potem na wpi­sa­niu pro­jek­tan­ta jako ​„media­to­ra”, do umo­wy na wdro­że­nie jako człon­ka zespo­łu po stro­nie zespo­łu Zamawiającego. 

Jeżeli pro­ble­ma­tycz­ne wdro­że­nie jest już w toku, to po audy­cie i ​„bilan­sie otwar­cia”, reali­zo­wa­ne są wyżej opi­sa­ne dzia­ła­nia po stro­nie Zamawiającego. Albo cza­sa­mi wła­śnie zawie­ra­na jest umo­wa trój­stron­na: Zamawiający, Dostawca i Mediator. Tu czę­sto kosz­ty media­to­ra dzie­lo­ne są po poło­wie mie­dzy Zamawiającego a Dostawcę: Mediator tu to pro­jek­tant sys­te­mu mają­cy nad­zór autorski. 

W swo­jej karie­rze mia­łem trzy takie umo­wy: dwie zawar­te na eta­pie poważ­ne­go spo­ru o jakość wdro­że­nia, jed­na zawar­ta już na eta­pie pro­ble­mów z pod­pi­sa­niem umo­wy na wdro­że­nie, co cie­ka­we na wnio­sek dostaw­cy opro­gra­mo­wa­nia. Wszystkie trzy pro­jek­ty skoń­czy­ły się suk­ce­sem wdro­że­nia. Polecam!

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ą 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).
5. może to być umo­wa z dowol­ne ze stron lub wyżej opi­sa­na umo­wa trójstronna. 

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 (rolą 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, jako trze­cia stro­na wdro­że­nia. Nie jest praw­dą, że mają oni niż­sze kom­pe­ten­cje od dostaw­ców, jest dokład­nie odwrot­nie (10 lat wdra­ża­łem sys­te­mu ERP pra­cu­jąc u jed­ne­go z naj­więk­szych inte­gra­to­rów sys­te­mów ERP, od 20 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).

Patrz tak­że Ekspertyzy, rola bie­głe­go.

Rzecz w tym, że w bran­ży IT narzę­dzia pro­gra­mi­stycz­ne nigdy nie były pro­ble­mem, pro­ble­mem zawsze są źle zapro­jek­to­wa­ne aplikacje ?

Źródła

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 (media­cje), 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 systemó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