Pojawia się wie­le nie­po­ro­zu­mień na temat zakre­sów pro­jek­tów ana­liz przed-wdro­że­nio­wych, sam padłem ofia­rą jed­ne­go z nich. W czym pro­blem? Koszty i czas trwa­nia takiej ana­li­zy. Do napi­sa­nia tego arty­ku­łu natchnął mnie kole­ga (Jacek Mamot, pre­zes K2 Consulting) pod­czas swo­jej pre­zen­ta­cji na dzi­siej­szym CRM GigaCon.

Co analizować

Okazuje się, że nie nale­ży zapo­mi­nać zada­wać dodat­ko­wych pytań. Na pyta­nie ​„ile to kosz­tu­je i trwa” odpo­wie­dzia­łem enig­ma­tycz­nie (w tym blo­gu poja­wia się to nie raz), że koszt ana­li­zy wyma­gań to ok. 10 – 20% budże­tu pro­jek­tu, a czas jej trwa­nia to ok, 50% cza­su całe­go projektu.

O czym zapo­mnia­łem? O roz­dzie­le­niu wyma­gań funk­cjo­nal­nych od ogra­ni­czeń (wyma­gań poza funk­cjo­nal­nych) i tak zwa­ne­go przej­ścia. Oprogramowanie ma dwa aspekty:

1. funk­cjo­nal­no­ści,
2. ska­la (skut­ki ograniczeń).

Ile i co kosztuje

Koszt każ­de­go pro­jek­tu pro­gra­mi­stycz­ne­go to trzy eta­py i zara­zem składniki:

1. ana­li­za i opra­co­wa­nie wyma­gań (pro­jek­to­wa­nie)
2. wytwo­rze­nie, dostar­cze­nie produktu
3. wdro­że­nie (przej­ście)

Uwaga: logi­ka biz­ne­so­wa nie zale­ży od licz­by użyt­kow­ni­ków (zakła­dam mil­czą­co, że dobry pro­jekt to i tak licz­ba mno­ga poten­cjal­nych użyt­kow­ni­ków, więc współ­dzie­lo­ny dostęp do danych jest moż­li­wy zawsze) i rygo­rów ich pra­cy. Tak więc war­to pamię­tać, że nale­ży stwo­rzyć dwa dokumenty:

1. Specyfikację tego jakie opro­gra­mo­wa­nie ma zostać dostar­czo­ne – Analityk Biznesowy,
2. Plan i wyce­na pro­jek­tu, w tym przej­ście – Dostawca, tu skład­ni­ki: koszt i ter­min wytwo­rze­nia opro­gra­mo­wa­nia, koszt nie­zbęd­nej infra­struk­tu­ry, koszt wdro­że­nia (tak zwa­ne przejście)

Tak więc koszt eta­pu Analityka Biznesowego to ok. 20% budże­tu i 50% har­mo­no­gra­mu ale wytwo­rze­nia i/lub dostar­cze­nia opro­gra­mo­wa­nia. Nie obej­mu­je on eta­pu przej­ścia, któ­ry ma wymiar wyłącz­nie orga­ni­za­cyj­ny (szko­le­nia, zmia­ny kom­pe­ten­cji, eta­py zmian zakre­sów obo­wiąz­ków itp.) i zaso­bo­wy (nowi pra­cow­ni­cy, koszt licen­cji na opro­gra­mo­wa­nie, plat­for­ma sys­te­mo­wa i jej wydaj­ność i pojemność).

Jeżeli więc pro­jekt obej­mu­je wię­cej niż kil­ka­dzie­siąt osób (pra­cow­ni­ków) war­to zacząć wyróż­niać pro­jekt ​„przej­ścia” jako odręb­ny etap. W jakim momen­cie ja się ​„pomy­li­łem”? Przemilczałem przej­ście. Ja nigdy go nie doty­kam, bo to robi dostawca.

Dostawca opro­gra­mo­wa­nia zawsze musi prze­pro­wa­dzić ana­li­zę przed-wdro­że­nio­wą, któ­rej celem nie jest ana­li­za wyma­gań (te już są) a ana­li­za kosz­tów wdro­że­nia a wcze­śniej tak zwa­na ana­li­za gap/fit (ana­li­za tego, któ­re wyma­ga­nia sys­tem speł­nia, a któ­rych nie).

Tak więc na zakoń­cze­nie zwró­cę uwa­gę: ana­li­za wyma­gań i pro­jekt opro­gra­mo­wa­nia jest zło­żo­na, nie­za­leż­nie od tego ilu użyt­kow­ni­ków go będzie uży­wa­ło. Jednak koszt wdro­że­nia opro­gra­mo­wa­nia w fir­mie 10 oso­bo­wej będzie nie­po­rów­ny­wal­nie mniej­szy niż w kor­po­ra­cji zatrud­nia­ją­cej 10000 osób. Tu jed­nak pro­ble­my leżą już gdzie indziej.

Ale ktoś powie: duży ERP wyma­ga prze­wi­dze­nia wie­lu ról w sys­te­mie i w związ­ku z tym obsłu­gi wie­lu eta­pów jakie poko­nu­ją tam doku­men­ty. Owszem, dla­te­go uwa­żam, że nale­ży osob­no wybrać sys­tem, któ­ry wchło­nie te doku­men­ty (np. finan­se itp.) i osob­no sys­tem, któ­re je tam dopro­wa­dzi czy­li ​„jakiś work­flow”. To dużo bez­piecz­niej­sze i mniej ryzy­kow­ne. Na dia­gra­mie poni­żej (dane z IBM) wdro­że­nie to etap insta­la­cji i odda­nia do użytku.

Prawo autorskie do treści

Na zakoń­cze­nie war­to zwró­cić uwa­gę na pra­wo do tre­ści doku­men­tu rapor­tu z ana­li­zy. Bardzo czę­sto zawie­ra on pro­jekt roz­wią­za­nia, pomysł na roz­wią­za­nie pro­ble­mu. Proszę zwró­cić uwa­gę, że pro­jekt zawie­ra­ją­cy doce­lo­wy model pro­ce­sów, pro­ce­du­ry, sce­na­riu­sze pra­cy, spe­cy­fi­ka­cje reguł biz­ne­so­wych, wzo­ry doku­men­tów i wie­le innych ele­men­tów takiej doku­men­ta­cji to ​„pra­ce o indy­wi­du­al­nym charakterze”.

Jeżeli w ramach ana­li­zy wyma­gań powsta­je tak­że pro­jekt opro­gra­mo­wa­nia dedy­ko­wa­ne­go, w zasa­dzie cały on jest dzie­łem w rozu­mie­niu pra­wa autorskiego.

Analiza biz­ne­so­wa i i doku­men­ta­cja pomy­słu (bo czym innym jest spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, to zapis nasze­go pomy­słu na sys­tem) pro­jek­tu, efekt naszej cięż­kiej pra­cy, wypra­co­wy­wa­nia lata­mi mode­lu biz­ne­so­we­go, wła­snych meto­da zarzą­dza­nia, tego co nie raz sta­no­wi klucz prze­wa­gi konkurencyjnej.

Jeżeli pra­ce te wyko­na dostaw­ca opro­gra­mo­wa­nia z zasa­dy sta­je się posia­da­czem tego pomy­słu. Nie raz pew­nie sły­sze­li Państwo w ofer­tach i na kon­fe­ren­cjach stwier­dze­nia w rodza­ju: ​„zgro­ma­dzi­li­śmy doświad­cze­nie z bran­ży …”, ​„ofe­ru­je­my refe­ren­cyj­ne mode­le biz­ne­so­we, naj­lep­sze prak­ty­ki bran­żo­we…”. Czym one są?

Dlatego dobrą prak­ty­ką jest raczej oddzie­le­nie pro­jek­to­wa­nia od wyko­na­nia. Zlecenie ana­li­zy i opra­co­wa­nia roz­wią­za­nia i prze­ję­cie praw mająt­ko­wych do opra­co­wa­nia (pro­jek­tu sys­te­mu) i na tej pod­sta­wie dopie­ro wska­za­nie wyko­naw­cy daje gwa­ran­cje, że dostaw­ca opro­gra­mo­wa­nia nie nabę­dzie żad­nych praw do Państwa pomy­słu. Daje gwa­ran­cję, że Wasz uni­kal­ny pomysł nie sta­nie się ​„mode­lem refe­ren­cyj­nym dla bran­ży…” lub co gor­sza ​„goto­wym pro­duk­tem z pudeł­ka”… bar­dzo czę­sto są to powie­lo­ne, nie raz nie­le­gal­nie lub co naj­mniej nie­etycz­nie, cudze rozwiązania.