Zapytania o pro­dukt mają­cy wdzięcz­ną nazwę ​„Analiza potrzeb i opra­co­wa­nie wyma­gań na sys­tem ERP” (w miej­sce ERP moż­na wsta­wić dowol­ny innych skrót w rodza­ju CRM, BI, SCM, work­flow itp..) naj­czę­ściej rodzą ocze­ki­wa­nia w posta­ci ​„lista wyma­gań funk­cjo­nal­nych i poza-funkcjonalnych”.

Lista taka jest zna­na z inży­nie­rii opro­gra­mo­wa­nia i jest powszech­nie sto­so­wa­na do pro­jek­to­wa­nia i wytwa­rza­nia tego opro­gra­mo­wa­nia. Ale jest pewien pro­blem gdy celem jest zakup goto­we­go opro­gra­mo­wa­nia, bo w koń­cu goto­we­go nie pro­jek­tu­je­my, bo podob­no ma być tań­sze niż pisa­nie od początku.

Niedawno napi­sa­łem:

Duży sys­tem ERP to set­ki i tysią­ce jego przy­pad­ków uży­cia, nie ma sen­su ich spe­cy­fi­ko­wa­nie podob­nie jak nie ma sen­su pyta­nie o nie przy­szłych użyt­kow­ni­ków tego sys­te­mu, bo nie są w sta­nie ich wyli­czyć. Ma jed­nak sens zro­zu­mie­nie tego jak fir­ma dzia­ła. Po raz kolej­ny posłu­żę się meta­fo­rą Martina Fowlera: grę w sno­oke­ra moż­na opi­sać rela­cjo­nu­jąc (zapi­su­jąc) set­ki kolej­nych par­tii, ale i tak nigdy nie wyspe­cy­fi­ku­je­my nawet ułam­ka moż­li­wych zagrań. Zdecydowanie lep­szą meto­dą jest przyj­rze­nie się kil­ku par­tiom i wychwy­ce­nie cech bili, ich ilo­ści, wymia­rów sto­łu oraz reguł gry, bo to będzie zgod­ne nie tyl­ko z histo­rią ode­gra­nych par­tii sno­oke­ra ale z każ­dą przy­szłą partią.

Dlatego zamiast pro­wa­dze­nia żmud­nych wywia­dów i two­rze­nie nie­sku­tecz­nej listy setek szcze­gó­ło­wych opi­sów moż­li­we­go uży­cia opro­gra­mo­wa­nia, lepiej jest zro­zu­mieć orga­ni­za­cję, stwo­rzyć jej model (dzie­dzi­ny) i wyspe­cy­fi­ko­wać jakie usłu­gi ma to opro­gra­mo­wa­nie świad­czyć dla użyt­kow­ni­ków teraz (bo tak nale­ży rozu­mieć poję­cie przy­pad­ku uży­cia sys­te­mu). Poprawny model dzie­dzi­ny pozwo­li tak­że na obsłu­gę przy­szłych wyma­gań mimo, że nie zna­my ich teraz. Podobnie jak stół bilar­do­wy: nie zna przy­szłych ude­rzeń ale wie­my, że na pew­no zosta­ną ?obsłu­żo­ne?. (Czym jest to co mode­lu­jesz w opro­gra­mo­wa­niu? Model dzie­dzi­ny sys­te­mu jako wyma­ga­nie.).

Wydawało by się, że wszyst­ko jasne. Ale? Popatrzmy na poniż­szy diagram:

Czas trwa­nia ana­li­zy i spe­cy­fi­ko­wa­nia (pra­co­chłon­ność, więc tak­że koszt) rośnie linio­wo w takt kolej­nych dni pra­cy nad ana­li­zą. W mia­rę powsta­wa­nia kolej­nych udo­ku­men­to­wa­nych szcze­gó­łów, ryzy­ko, że wybie­rze­my zły (nie­pa­su­ją­cy nam) pro­dukt male­je. Jednak ryzy­ko jest, jak widać, funk­cją nie­li­nio­wą (jest to praw­do­po­do­bień­stwo złe­go wybo­ru, któ­re nigdy nie doj­dzie do zera) zaś wzrost kosz­tów jest linio­wy. W efek­cie od pew­ne­go momen­tu, dość bli­skie­go począt­ko­wi tej pra­cy, kosz­ty takiej ana­li­zy rosną szyb­ciej niż korzy­ści z jej szcze­gó­ło­wo­ści. Tak więc w typo­wym pro­jek­cie w zasa­dzie ska­za­ni jeste­śmy na kom­pro­mis i uzna­nie pew­ne­go (nie tak małe­go) ryzy­ka, że jed­nak wybór będzie zły (mimo, że pro­dukt speł­ni skoń­czo­ną listę wymagań).

Przekroczenie pew­nej umow­nej gra­ni­cy ​„roz­sąd­ku” – ana­li­zy i spi­sy­wa­nia szcze­gó­łów – popy­cha taki pro­jekt w kie­run­ku pro­jek­to­wa­nia nowe­go sys­te­mu, a mia­ło być tanio, bo chce­my kupić sys­tem goto­wy. Krótkie wyli­cze­nie: typo­wy sys­tem ERPII to ok. 6 tys. cech. Samo ich spi­sa­nie ze zro­zu­mie­niem to:

• opis jed­ne­go wyma­ga­nia to 500 zna­ków (śred­ni wynik z kil­ku zna­nych mi dokumentów)
• jed­na stro­na maszy­no­pi­su to 1800 znaków
• 6 tys cech to 6000 x 500 zna­ków / 1800 stro­na = 1667 stron tekstu
• z roz­mów z wyko­naw­ca­mi ana­li­ty­ka­mi wiem, że efek­tyw­nie piszą ok. 7 mery­to­rycz­nych stron dzien­nie (to dość opty­mi­stycz­ne założenie)
• w efek­cie 1667 stron / 7 dzien­nie = 238 dni robo­czych, staw­ka bar­dzo tanie­go kon­sul­tan­ta to np. 1000zł/dzień, otrzy­mu­je­my: 238 tys. zło­tych i ponad rocz­ny projekt.
• Jeżeli uzna­my, że jed­nak spe­cy­fi­ko­wa­nie jest poprze­dza­ne ana­li­zą, dla uprosz­cze­nia (zno­wu bar­dzo opty­mi­stycz­nie) przyj­mę, trwa­ją­ca tyle co spi­sy­wa­nie jej wyni­ków, mamy dwa lata pra­cy i pół milio­na złotych.
• Skrócenie tego poprzez zatrud­nie­nie nie jed­ne­go a np. czte­rech ana­li­ty­ków pod­nie­sie kosz­ty o ok. 30% (znam takich, któ­rzy by tu doda­li 50% i pew­nie mają nie raz rację) na koor­dy­na­cję, kon­tro­lę zgod­no­ści, popraw­ki wyni­ka­ją­ce z ​„uspój­nia­nia pra­cy róż­nych autorów”.

Urealnienie tych wyli­czeń (choć­by staw­ki ana­li­ty­ków) wywin­du­je ten budżet na kwo­tę znacz­nie ponad milion zło­tych! Na to sobie mało kto sobie pozwo­li. W więk­szo­ści przy­pad­ków nie jest robio­na tak dłu­go trwa­ją­ca ana­li­za i za nie takie pie­nią­dze. Zaryzykuje tezę, że – obser­wu­jąc sta­ty­sty­ki pro­jek­tów IT – nie ma to, takie podej­ście, żad­ne­go sen­su. Tak więc tak opra­co­wa­ne spe­cy­fi­ka­cje, są jed­nak uprasz­cza­ne z uwa­gi na kosz­ty, są z zasa­dy niekompletne!

Teraz przy­szła pora na moje­go ser­decz­ne­go przy­ja­cie­la, któ­ry zjadł zęby na kor­po­ra­cyj­nym ryn­ku IT (wyba­czy­cie mi Państwo, że dane jego zacho­wam dla sie­bie). Oto co mi nie­daw­no powie­dział pod­czas podob­nej dyskusji:

Nawet przy kup­nie kon­kret­nej kieł­ba­sy kry­te­riów wybo­ru skle­pu może być wie­le i zakła­da­my, że ktoś ma czas/pieniądze aby je wszyt­kie zasto­so­wać, by pod­jąć decy­zję. Przy kup­nie samo­cho­du czy komór­ki ilość funk­cji, któ­re trze­ba porów­nać jest tak duża, że porów­ny­wa­nie to już spo­ra pra­ca. Nie zawsze ma się zaso­by, aby ją wyko­nać. Nabywca z dobrym dzia­łem zaku­pów ma sche­ma­ty oce­ny wie­lo­kry­te­rial­nej skom­pli­ko­wa­nych towa­rów i usług, Ale kto poświę­ci 2 godzi­ny na decy­zję, jaki kupić sobie dłu­go­pis? Pewnie nikt, ale na pod­ję­cie decy­zji kup­na komór­ki 2 godzi­ny to sta­now­czo za mało, choć błęd­na decy­zja jest kosz­tow­na lub wią­że nas na 2 lata z mode­lem, któ­ry nie speł­nia oczekiwań.

Producenci róż­nych rze­czy zda­ją sobie spra­wę, że kosz­ty pod­ję­cia wła­ści­wej decy­zji przy skom­pli­ko­wa­nych pro­duk­tach są spo­re i ludzie będą podej­mo­wać decy­zje błęd­ne, to pozwa­la dzia­łać na ryn­ku fir­mom, któ­re w prze­ciw­nym wypad­ku by upadły.

I jak teraz wyglą­da­ją w Państwa oczach zaku­py i wdro­że­nia dużych goto­wych sys­te­mów? Czy to zna­czy, że kup­no goto­we­go sys­te­mu nigdy nie ma sen­su? Ależ ma ale…

Gotowe opro­gra­mo­wa­nie jest adre­so­wa­ne z zasa­dy do wie­lu róż­nych odbio­rów, ska­za­ne jest więc na znacz­ny nad­miar funk­cjo­nal­no­ści ​„na zapas” (popa­trz­my z jakiej czę­ści cech tele­fo­nów czy pakie­tów biu­ro­wych korzy­sta­my). Skoro więc potrze­bu­je­my cze­goś co ma 100 potrzeb­nych nam cech a wybie­ra­my coś goto­we­go na ryn­ku co ma ich 1000, ale zawie­ra te potrzeb­nych nam 100, to sama nasu­wa się teza, że powy­żej pew­ne­go pro­gu uni­wer­sal­ne roz­wią­za­nie kosz­tu­je wię­cej (uwzględ­nia­jąc kosz­ty decy­zji) niż korzy­ści z cech wyma­ga­nych i zapew­ne nie raz war­to wyko­nać coś ​„pod nasze potrze­by”. I tu poja­wia się haczyk: nale­ży te potrze­by bar­dzo dobrze – z mini­mal­nym ryzy­kiem – opi­sać. Bo wszy­scy wie­my jak się koń­czą pro­jek­ty pro­gra­mi­stycz­ne, w któ­rych ​„klient nie wie cze­go chce”.

Jak to robić lepiej? Po pierw­sze nie kupo­wać ​„dużych i dro­gich zin­te­gro­wa­nych sys­te­mów” bo to duże ryzy­ko, kupo­wać mniej­sze, łatwiej­sze do opi­sa­nia, pro­jek­to­wać i two­rzyć te, któ­re są zbyt dużym ryzy­kiem w przy­pad­ku złe­go wybo­ru. Jeżeli już z powo­du ryzy­ka mamy poświę­cić duży budżet na kosz­tow­ne spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia to sygnał, że nale­ży je za te pie­nią­dze po pro­stu zapro­jek­to­wać i wykonać.

Niestety nie ma pro­stej odpo­wie­dzi na pyta­nie jak to robić ​„dobrze”. Chyba, że będzie to pro­po­zy­cja nastę­pu­ją­ce­go procesu:

1. ana­li­za biznesowa,
2. zde­fi­nio­wa­nie celu,
3. zapro­jek­to­wa­nie archi­tek­tu­ry sys­te­mu (to jako sys­tem nale­ży rozu­mieć orga­ni­za­cję wraz z wspie­ra­ją­ca ją infor­ma­ty­ką), tu zmie­rza­my w kie­run­ku tak zwa­nej [[archi­tek­tu­ry korporacyjnej]],
4. ziden­ty­fi­ko­wa­nie ocze­ki­wa­nych od opro­gra­mo­wa­nia usług (wyma­ga­nia), podzie­lić je na odręb­ne ale spój­ne obsza­ry dzie­dzi­no­we,
5. dla każ­de­go obsza­ru dzie­dzi­no­we­go opra­co­wać wyma­ga­nia na oprogramowanie,
6. wybrać roz­wią­za­nia.

Zwracam uwa­gę na drob­ny szcze­gół: wybo­ru pro­duk­tu i jego dostaw­cy doko­nu­je­my na koń­cu, nigdy na począt­ku! A kto i dla­cze­go nas prze­ko­nu­je, że nale­ży naj­pierw kupić a potem analizować?

(arty­kuł uka­zał się tak­że w ERP​-Viev​.pl)