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. 

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

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.