Ratowanie wdrożeń

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?

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. 

Wstęp

Od cza­su do cza­su jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów. Ma to miej­sce, gdy jestem anga­żo­wa­ny do pro­jek­tu będą­ce­go kolej­nym podej­ściem do wdro­że­nia, czę­sto też na eta­pie spo­rów przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Kilka spo­strze­żeń na ten temat w arty­ku­le: Kto winien poraż­ki projektu?

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

Opisy sku­tecz­nych metod pra­cy i stan­dar­dów, wraz z lite­ra­tu­rą źró­dło­wą, znaj­dzie­cie Państwo na tych stro­nach bez pro­ble­mu. Tu sku­pię sie na krót­kim opi­sie spo­so­bu postę­po­wa­nia w przy­pad­ku ​„rato­wa­nia” wdro­żeń sys­te­mów informacyjnych. 

Jak skutecznie zaplanować i przeprowadzić wdrożenie oprogramowania

Podstawą roz­po­czę­cia pra­cy jest sche­mat sta­no­wią­cy fun­da­ment każ­de­go wdro­że­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzadzanie:

Powyższy dia­gram to szkie­let 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: nale­ży 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. 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 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).

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. Drugą głów­ną przy­czy­ną pro­ble­mów jest inge­ro­wa­nie w dostar­czo­ne goto­we opro­gra­mo­wa­nie. 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ść. 

Kolejną przy­czy­ną 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ć pra­ce 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?

Bardzo czę­sto ele­men­tem spo­ru jest kwe­stia pra­co­chłon­no­ści i roz­li­czeń. Dlatego pierw­szym eta­pem 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 ​„gap-fit”), 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).

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. 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: for­mą 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).

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