Artykuł jaki uka­zał się w COMPUTERWORLD skło­nił mnie do kon­fron­ta­cji moich doświad­czeń i obser­wa­cji z jego tre­ścią, uwa­ga­mi innych doświad­czo­nych spe­cja­li­stów. Być może war­to poku­sić się o pew­ne wnio­ski i sugestie…

Wina klienta

Według nie­go więk­szość firm nie jest przy­go­to­wa­na na wdro­że­nie sys­te­mu ERP. ​„Firmy gene­ral­nie nie radzą sobie ze zmia­na­mi. Tymczasem wdro­że­nie sys­te­mu ERP pocią­ga ich za sobą nad­zwy­czaj dużo. Poza tym wie­le orga­ni­za­cji ma pro­ble­my z odpo­wied­nim defi­nio­wa­niem pro­ce­sów biz­ne­so­wych. To wła­śnie te fir­my będą mia­ły naj­więk­sze pro­ble­my w uzy­ska­niu wymier­nych korzy­ści z posia­da­ne­go sys­te­mu” – mówi David Bergen, były szef infor­ma­ty­ki w fir­mie Levi Strauss, któ­ry uczest­ni­czył w reali­za­cji kil­ku pro­jek­tów wdro­że­nia sys­te­mu SAP. Na to nakła­da­ją się rów­nież pro­ble­my wyni­ka­ją­ce z nad­mier­nie roz­dmu­cha­nych wyobra­żeń doty­czą­cych wdra­ża­ne­go roz­wią­za­nia. Nierzadko han­dlow­cy – po stro­nie pro­du­cen­ta sys­te­mu lub bez­po­śred­nie­go dostaw­cy – kre­ślą przed przy­szły­mi użyt­kow­ni­ka­mi opro­gra­mo­wa­nia wizje trud­ne lub wręcz nie­moż­li­we do zre­ali­zo­wa­nia w prak­ty­ce. Ponadto takie dzia­ła­nia sprzy­ja­ją sztucz­ne­mu roz­dmu­chi­wa­niu zakre­su funk­cjo­nal­ne­go opro­gra­mo­wa­nia.¹

Zmiany w organizacji

Tu pew­na cie­ka­wost­ka, moim zda­niem pewien para­doks: spe­cja­li­ści od wdra­ża­nia zmian w orga­ni­za­cjach, psy­cho­lo­dzy biz­ne­su tak­że, zgod­nie twier­dzą, że zmia­na men­tal­no­ści pra­cow­ni­ków i tak zwa­na doj­rza­łość orga­ni­za­cji (pozio­mów doj­rza­ło­ści) to pro­ces na trzy do pię­ciu lat. Przeciętny zin­te­gro­wa­ny sys­tem ERP to set­ki funk­cjo­nal­no­ści, nauka na lata. Jak więc trak­to­wać obiet­ni­ce dostaw­ców opro­gra­mo­wa­nia, że wdro­żą cały sys­tem ERP w rok a nawet w kwar­tał? Gdy patrzę na nie­któ­re wdro­że­nia to nie raz mam wra­że­nie, że wdra­ża­ją­cym jest kie­row­nik pro­jek­tu i praw­nik per­swa­du­ją­cy zakres prac wyko­na­nych i zafak­tu­ro­wa­nych, a nie fak­tycz­ne ​„przy­ję­cie” nowych narzę­dzi przez kupu­ją­ce­go. Nie raz kolej­ny etap jest zre­ali­zo­wa­ny nie dla­te­go, że kolej­ne modu­ły są uży­wa­ne a raczej dla­te­go, że zosta­ły dostarczone.

Procesy biz­ne­so­we

To kolej­na cho­ro­ba wdro­że­nio­wa, nie­ste­ty zama­wia­ją­cych: wie­rzą, że to nie oni, jako odbior­cy będą cięż­ko pra­co­wać. Problem w tym, że ktoś musi wie­dzieć jak pra­cu­je fir­ma, bez tego nic się tak na praw­dę nie wdro­ży. Modelowanie pro­ce­sów biz­ne­so­wych to nic inne­go jak opi­sa­nie tego jak pra­cu­je fir­ma: co i po co się robi. Daleko temu do stwier­dze­nia ​„to jest nam potrzeb­ne”. Niestety model pro­ce­sów biz­ne­so­wych nie suchym obraz­ko­wym zapi­sem opo­wia­dań tego ​„co i jak robi­my”, to nie jest zapis sta­nu fak­tycz­ne­go, jed­ne­go (wie­lu) z nie­skoń­czo­nej ilo­ści warian­tów. Tak powsta­je ste­no­gram. Model pro­ce­sów biz­ne­so­wych to spe­cy­fi­ka­cja (mapy) tego co i po co powsta­je (pro­duk­ty). Opis taki (model) nale­ży uzu­peł­nić o regu­ły biz­ne­so­we, by uchwy­cić w tym gąsz­czu dzia­łań te istot­ne oraz fak­tycz­ny sens dzia­łań a nie tyl­ko ich aktu­al­ny spo­sób reali­za­cji (któ­ry raczej się zmie­ni po wdrożeniu).

Taki model powi­nien powstać dla całej fir­my przed wdro­że­niem jakie­go­kol­wiek opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie. Podstawowym powo­dem mode­lo­wa­nia jest zro­zu­mie­nie kon­tek­stu wdro­że­nia oraz moż­li­wość oce­ny jego wpły­wu na resz­tę firmy.

Oferta prze­ra­sta rzeczywistość

No cóż, czę­sto sły­szę od firm pro­gra­mi­stycz­nych narze­ka­nia, że klien­ci w ramach spe­cy­fi­ka­cji wyma­gań, ser­wu­ją im stek ​„poboż­nych życzeń”. Jak wobec tego nazwać ofer­tę dostaw­cy sys­te­mu ERP wysła­ną w odpo­wie­dzi na takie zapy­ta­nie? Po pro­stu tak samo: jako nad­uży­cie celo­we lub nie­za­mie­rzo­ne, wyni­ka­ją­ce z niewiedzy.

Wina inte­gra­to­ra

Większość prac bez­po­śred­nio zwią­za­nych z wdro­że­niem sys­te­mu biz­ne­so­we­go spa­da na fir­mę wdro­że­nio­wą. W nie­unik­nio­ny spo­sób od zaan­ga­żo­wa­nia i kom­pe­ten­cji kon­sul­tan­tów zale­ży powo­dze­nie całe­go pro­jek­tu. Tymczasem naj­waż­niej­sze zarzu­ty adre­so­wa­ne w ich kie­run­ku doty­czą: nie­zna­jo­mo­ści opro­gra­mo­wa­nia, któ­re mają wdra­żać, nie­zna­jo­mo­ści pod­staw funk­cjo­no­wa­nia sys­te­mów kla­sy ERP i sła­bej orga­ni­za­cji pra­cy. Ostatni zarzu­ty jest bez­po­śred­nio zwią­za­ny z kla­sycz­nym mode­lem zakła­da­ją­cym godzi­no­we roz­li­cza­nie pra­cy kon­sul­tan­tów. W rezul­ta­cie, z punk­tu widze­nia inte­gra­to­ra, naj­bar­dziej opła­cal­ne jest kie­ro­wa­nie do prac wdro­że­nio­wych naj­mniej doświad­czo­nych kon­sul­tan­tów. Ten kon­flikt inte­re­sów czę­sto odbi­ja się nega­tyw­nie na rela­cjach mię­dzy klien­tem, a dostaw­cą opro­gra­mo­wa­nia.¹

Niskie kom­pe­ten­cje wdra­ża­ją­cych kon­sul­tan­tów to nie­mal­że kla­sy­ka. To czę­sto czę­sty grzech dostaw­ców, uwa­ża­ją­cych, że zawar­ta umo­wa i sto­sow­na licz­ba dość dobrze opi­sa­nych ​„mil­sto­nów” do ​„zali­cze­nia” i zafak­tu­ro­wa­nia pozwa­la zaan­ga­żo­wać do pro­jek­tu począt­ku­ją­cych (tanich) kon­sul­tan­tów, potra­fią­cych jed­ny­nie pra­co­wi­cie reali­zo­wać te ​„mil­sto­ny”. To się nie­ste­ty nie udaje.

Kontrakty ​„czas i materiał”

To kolej­na cho­ro­ba pro­jek­tów IT: ​„pra­cu­je­my aż skoń­czy­my”. Często klient spra­wy sobie nawet nie zda­je, że zawie­ra­jąc taki kon­trakt w zasa­dzie tra­ci pano­wa­nie nad nim i jego budże­tem. Owszem, to ład­nie brzmi: ​„Państwo pozna­li nasze kom­pe­ten­cje i wie­rzą, że war­to za nie pła­cić”. Kolejnym, nale­ży powie­dzieć jasno kłam­stwem, jest teza: ​„Państwa wyma­ga­nia nie są moż­li­we do zde­fi­nio­wa­nia, dla­te­go będzie­my opra­co­wy­wa­li kolej­ne pro­to­ty­py aż wdro­ży­my potrzeb­ne oprogramowanie”.

Cóż, jeże­li nie są zna­ne wyma­ga­nia to sygnał, że nie­po­trzeb­ny jest ten pro­gram (sys­tem).

Na zakończenie

„Do wybo­ru fir­my wdro­że­nio­wej nale­ży pod­cho­dzić jak do pro­ce­su rekru­ta­cji nowych pra­cow­ni­ków. W ramach ana­li­zy ofert war­to choć­by poroz­ma­wiać z kadrą zarzą­dza­ją­ca i kie­row­ni­ka­mi zespo­łów wdro­że­nio­wych oraz prze­ana­li­zo­wać, a naj­le­piej tak­że potwier­dzić u źró­dła ich refe­ren­cje” – twier­dzi Greg Hatch z fir­my kon­sul­tin­go­wej Alvarez & Marsal Business Consulting.¹

Po pierw­sze: nale­ży dobrze poznać wła­sną fir­mę zanim cokol­wiek, nie tyl­ko wdro­ży­my, zanim podej­mie­my decy­zje by cokol­wiek wdrażać.

Po dru­gie: nale­ży wdra­żać (kupo­wać) sys­tem w ​„kawał­kach” po 20 – 50 funk­cjo­nal­no­ści zamy­ka­ją­cych się w kil­ku całych pro­ce­sach biz­ne­so­wych (a nie dzia­łach czy pio­nach), zamiast setek funk­cjo­nal­no­ści wraz z całym sys­te­mem ERP za jed­nym zamachem.

Po trze­cie: z czy­ste­go bez­pie­czeń­stwa pro­jek­tu i zarzą­dza­nie ryzy­kiem – wyma­ga­nia (a kon­kret­nie spe­cy­fi­ka­cja tego co ma zostać dostar­czo­ne) i nad­zór nad ich reali­za­cją, to nie jest pra­ca ani dla dostaw­cy ani dla kupu­ją­ce­go, pierw­szy naj­praw­do­po­dob­niej będzie kolo­ry­zo­wał swój pro­dukt a dru­gi posłu­ży się stereotypami.

W wie­lu orga­ni­za­cjach poja­wia się zja­wi­sko zwa­ne Citizen Developer. Jest to tak zwa­ny ​„Programista oby­wa­tel­ski”, pra­cow­nik, któ­ry two­rzy apli­ka­cje do użyt­ku przez sie­bie lub innych, korzy­sta­jąc z narzę­dzi, któ­re nie są aktyw­nie zabro­nio­ne przez dział IT lub jed­nost­ki biz­ne­so­we (bar­dzo czę­sto jest to MS Excel i MS Access, od pew­ne­go cza­su Pyton). Początkowo ich pra­ca może przy­no­sić drob­ne lokal­ne korzy­ści, jed­nak w dłuż­szej per­spek­ty­wie sta­no­wi poważ­ne zagro­że­nie dla bez­pie­czeń­stwa infor­ma­cji i spój­no­ści danych w orga­ni­za­cji. Takie oso­by czę­sto wno­szą swo­je pomy­sły jako wyma­ga­nia dla sys­te­mów ERP, kie­ru­jąc się emo­cja­mi, w efek­cie dopro­wa­dza­ją czę­sto do poważ­nych kłopotów. 

Co robić?

Tak jak w bran­ży budow­la­nej: podzie­lić pro­jekt na kil­ka eta­pów, każ­dy trak­to­wać jak ana­li­zę wyko­ny­wal­no­ści, dopu­ścić zarzu­ce­nie pro­jek­tu na każ­dym z tych eta­pów. Aha, i zle­cić pro­jekt zewnętrz­nej fir­mie (tu biu­ro pro­jek­to­we) nie­zwią­za­nej ani z przy­szłym (nie powi­nien być nawet zna­ny) dostaw­cą ani z pra­cow­ni­ka­mi zama­wia­ją­ce­go (z wie­lu powodów).