Ku moje­mu zasko­cze­niu dość czę­sto dosta­ję pyta­nia o moż­li­wość zaan­ga­żo­wa­nia się w roli ana­li­ty­ka np. na rok na warun­kach: 100% cza­su na miej­scu u klien­ta a wyni­kiem ma być spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, któ­re­go reali­za­cja jest pla­no­wa­na na np. kolej­ne 5 lat. Nie ma to moim zda­niem żad­ne­go sen­su i nie anga­żu­je się w takie pro­jek­ty. Ale po kolei.

Już w roku chy­ba 2003 robi­łem ana­li­zę ryzy­ka dużych i dłu­gich pro­jek­tów, celem była oce­na praw­do­po­do­bień­stwa i kosz­tów wpro­wa­dza­nia zmian do zakre­su pro­jek­tu. Jak nie trud­no się domy­śleć, jest to – zmia­ny zakre­su – naj­bar­dziej nie­chcia­na rzecz w każ­dym pro­jek­cie. Materiał ten był pre­zen­to­wa­ny na jed­nej z kon­fe­ren­cji doty­czą­cych wdra­ża­nia sys­te­mów ERP.

Co spo­wo­do­wa­ło moje zain­te­re­so­wa­nie tym pro­ble­mem? To co każ­dy w tej bran­ży widział chy­ba naj­mniej raz w życiu: róż­ni­ca pomię­dzy pier­wot­ną spe­cy­fi­ka­cją a osta­tecz­nym pro­duk­tem. W dużych pro­jek­tach czę­sto te dwa sta­ny nie mają z sobą zbyt wie­le wspól­ne­go! Więc poja­wia się pyta­nie: po co robić wiel­ką ana­li­zę i doku­men­ta­cję sko­ro więk­szość tej doku­men­ta­cji, roz­dział po roz­dzia­le, lądu­je w koszu za spra­wą zarzą­dza­nia zmianą”?

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? 70% to zmia­ny zakre­su pro­jek­tu, (Raport Jama Sofware ? O wyma­ga­niach).

Popatrzmy na to:

Ryzyko projektu 1

Analiza i spe­cy­fi­ko­wa­nie wyma­gań to tak na praw­dę pro­gno­za mówią­ca, że to co teraz pro­jek­tu­je­my będzie w przy­szło­ści, w dniu odda­nia do użyt­ku, potrzeb­ne w takiej for­mie w jakiej wła­śnie to pro­jek­tu­je­my. Jak wie­my, pro­gno­zy są tym więk­szym błę­dem obar­czo­ne i bar­dziej w przy­szłość wybie­ga­ją. Powyższy dia­gram to typo­wy mega­pro­jekt. Linia prze­ry­wa­na obra­zu­je pew­ną hipo­te­tycz­ną gra­ni­cę, powy­żej któ­rej ryzy­ko błęd­nej pro­gno­zy prze­kra­cza np. 50% (czy­li kla­sycz­ny rzut monetą).

Innymi sło­wy, roz­po­czy­na­jąc mega­pro­jekt mamy nie­mal­że pew­ność, że jego zakres ule­gnie zmia­nie czy­li cała pra­ca powy­żej tej linii prze­ry­wa­nej pój­dzie do kosza (na koszt spon­so­ra projektu ;)).

W natu­ral­ny spo­sób nasu­wa się wnio­sek: nie nale­ży robić nic ponad tę prze­ry­wa­ną linię. Wtedy otrzy­ma­my taki diagram:

Ryzyko projektu 2

Robimy tyl­ko to co z ryzy­kiem bli­skim zera zosta­nie zaim­ple­men­to­wa­ne bez zmian. Jak? Pierwszy etap to ana­li­za pro­ble­mu i pro­jek­to­wa­nie archi­tek­tu­ry cało­ści – model kom­po­nen­tów. Jest to jakaś logi­ka sys­te­mu na dość wyso­kim pozio­mie abs­trak­cji ale dają­ca się prze­te­sto­wać. Stanowi ona pod­sta­wę dal­szej pra­cy nad każ­dym kom­po­nen­tem osob­no (kolej­ne eta­py). Uszczegóławianie wyma­gań odkła­da­my na ostat­ni moment”. W ten spo­sób kwar­tał po kwar­ta­le” dopre­cy­zo­wu­je­my wyma­ga­nia na kolej­ny etap i reali­zu­je­my go. Co zysku­je­my? Nie wyrzu­ca­my do kosza nad­mier­nie szcze­gó­ło­wej i roz­le­głej doku­men­ta­cji wyma­gań, nie pono­si­my koszów pro­jek­to­wa­nia cze­goś co może wyle­cieć” z zakre­su za pół roku z powo­dów np. zmian na ryn­ku, może­my w dowol­nym momen­cie zmie­nić kolej­ne pla­no­wa­ne kom­po­nen­ty, usu­nąć jed­ne i opra­co­wać nowe bez ryzy­ka zbęd­nych kosztów.

Pierwszy etap ma pew­ną cechę: two­rzy (taki ma cel) jeden wspól­ny model wszyst­kich pro­jek­tów dla danej orga­ni­za­cji o wdzięcz­nej nazwie Architektura Korporacyjna. Kolejne kon­kret­ne kom­po­nen­ty archi­tek­tu­ry IT to kolej­ne pro­jek­ty, cechu­ją­ce się zro­zu­mia­nym umiej­sco­wie­niem w cało­ści orga­ni­za­cji i wia­ry­god­nym, spój­nym z cało­ścią zakresem.

Dlatego z regu­ły nie mają sensu:

  1. wdro­że­nia depar­ta­men­to­we ode­rwa­ne od resz­ty (np. Dział Handlowy sobie fun­du­je sam sys­tem CRM),
  2. pro­jek­ty trwa­ją­ce dłu­żej niż trzy kwar­ta­ły (ostat­ni kwar­tał to kolej­ne pla­no­wa­nie budże­tu na kolej­ny rok czy­li pla­no­wa­nie zmian),
  3. mega pro­jek­ty ERPII czy­li all in one” dla fir­my w ramach jed­ne­go projektu.

Więc jak zjeść sło­nia by się nie udła­wić? Powoli i po kawał­ku… I nie zapo­mi­naj­my, że wyzwa­niem może być nie tyle nowe opro­gra­mo­wa­nie co zmia­na nawy­ków ludzi… a nie ma nic gor­sze­go niż pla­no­wa­nie nowe­go opro­gra­mo­wa­nia dla sta­rych nawy­ków bo po co to robić?

Pamiętajmy, że zarzą­dza­nie zakre­sem pro­jek­tu jest tym kosz­tow­niej­sze im wię­cej szcze­gó­łów ten zakres posia­da. Projekt o 30 wyma­ga­niach vs. pro­jekt o 300 wyma­ga­niach to nie pro­jekt o 10-krot­nie więk­szym kosz­cie, ta róż­ni­ca będzie znacz­nie więk­sza (pomi­jam to jak w ogó­le zde­fi­niu­je­my wymaganie).

Tak więc prze­cięt­ny pro­jekt to dla ana­li­ty­ka pra­ca na nie wię­cej niż kwar­tał (mniej wię­cej). Jak ja opi­sać wyma­ga­nia na sys­te­my ERP? Nie są to set­ki szcze­gó­ło­wych wyma­gań, bo to nie ma sen­su. To opis archi­tek­tu­ry kor­po­ra­cyj­nej wraz z zesta­wem celów biz­ne­so­wych dla każ­de­go poten­cjal­nie kupo­wa­ne­go modu­łu (pod­sys­te­mu) oraz wyma­ga­nia jako testy poka­zu­ją­ce reali­za­cję tych celów. Tych testów (wyma­gań) będzie raczej 30 niż 300, zaś ewen­tu­al­ne dedy­ko­wa­ne funk­cjo­nal­no­ści są pro­jek­to­wa­ne na ostat­ni moment” jeże­li oka­że się, że żaden ryn­ko­wy pro­dukt ich nie ofe­ru­je a nam na praw­dę są one potrzebne.

P.S.

Stale mnie nur­tu­je pyta­nie: dla­cze­go tak czę­sto są ogła­sza­ne prze­tar­gi na mega­pro­jek­ty i są skła­da­ne ofer­ty na mega wdro­że­nia, sko­ro to co napi­sa­łem nie sta­no­wi żad­ne­go odkrycia? 🙂

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 7 komentarzy

  1. PLigner

    Podzielenie duże­go pro­jek­tu na mniej­sze czę­ści w two­im przy­kła­dzie kwar­ta­le i korek­ta kie­run­ku po każ­dym eta­pie to wprost podej­ście scrumowe.
    W mega­pro­jek­tach” jest też pro­blem z podej­ściem Klienta (spon­so­ra) i przy­szłe­go użyt­kow­ni­ka sys­te­mu któ­rzy chcie­li­by już na począt­ku wie­dzieć co dosta­ną na koniec z dokład­no­ścią do pozy­cji przy­ci­sku odśwież na for­mat­ce Nr45” co oczy­wi­ście nie ma wpły­wu na póź­niej­sze zmia­ny tych z taką skru­pu­lat­no­ścią doko­na­nych ustaleń ;]

    1. Jarek Żeliński

      SCRUM (chy­ba, że o czymś nie wiem) nie wyma­ga ist­nie­nia nad­rzęd­nej archi­tek­tu­ry cało­ści sys­te­mu (całej orga­ni­za­cji)… nie ram mam wra­że­nie, że to jed­nak roz­po­zna­nie bojem. 

      Ta całość” to kom­plet­ny model poję­cio­wy (nie jest to model danych!) i regu­ły biz­ne­so­we całej orga­ni­za­cji, bez cze­go żaden czę­ścio­wy pro­jekt nie ma ani kon­tek­stu ani zde­fi­nio­wa­nych punk­tów sty­ku z resz­tą”. Nie przy­pad­kiem napi­sa­łem o archi­tek­tu­rze kor­po­ra­cyj­nej, gdyż prak­ty­ka moich ostat­nich lat wska­zu­je na to, że dobry sys­tem IT w danej orga­ni­za­cji to jeden prze­my­śla­ny sys­tem podzie­lo­ny na dzie­dzi­no­we pod­sys­te­my (nie waż­ne czy od jed­ne­go dostaw­cy czy nie i nie koniecz­nie musi to być jeden wiel­ki zin­te­gro­wa­ny, to ostat­nie nawet jest chy­ba naj­gor­sze). Zaryzykuję tezę, że ten nad­rzęd­ny sys­tem to nic inne­go jak obiek­to­wy meta-meta model dzie­dzi­ny sys­te­mu jaką jest cała orga­ni­za­cja. Tu wła­śnie widzę korzy­ści z archi­tek­tu­ry kor­po­ra­cyj­nej ale chy­ba nie takiej jak TOGAF, któ­ra w moich oczach jest jed­nak prze­for­ma­li­zo­wa­na a wła­śnie jako Siatka Zachmana, któ­rą on sam teraz nazy­wa onto­lo­gią organizacji”. 

      To co napi­sa­łeś w dru­gim aka­pi­cie to nie­ste­ty praw­da. To sytu­acja, w któ­rej Klient sam zabi­ja wła­sny pro­jekt. Jest to efekt nad­mier­ne­go uzna­wa­nia życzeń przy­szłych użyt­kow­ni­ków i umy­wa­nie rąk od tego przez spon­so­rów pro­jek­tu (ja pła­cę Wy rób­cie). Bez nad­rzęd­ne­go mode­lu nie ma narzę­dzia do uci­na­nia takich idio­tycz­nych życzeń. Dodam jesz­cze, że pro­ble­mem wie­lu pro­jek­tów jest trak­to­wa­nie ana­li­ty­ków jak sekre­ta­rzy w rodza­ju jak klient mówi to ana­li­tyk zapi­su­je”. To tak­że dro­ga do poraż­ki ;), bywa, ze z tego powo­du (takie ocze­ki­wa­nie zama­wia­ją­ce­go) wypo­wia­dam umowę.

  2. Ewa

    Bardzo mi się podo­ba to podej­ście, jest takie ide­al­ne. Pytanie tyl­ko, jak nale­ża­ło­by do tego prze­ko­nać spon­so­rów i jak kon­stru­ować umo­wy na taką reali­za­cję. Nie mia­łam takiej przy­jem­no­ści, jed­nak to pod­po­wia­da roz­są­dek, tak powin­no być.
    Kluczowe jest na począt­ku zde­fi­nio­wa­nie architektury.

    1. Jarek Żeliński

      W zasa­dzie nie jest to takie trud­ne. Umowa ma kil­ka eta­pów, każ­dy ma swo­ją cenę, każ­da ze stron może bez kon­se­kwen­cji może wypo­wie­dzieć jej kon­ty­nu­ację. Kluczem jest pierw­szy etap, któ­re­go pro­duk­tem jest owa archi­tek­tu­ra cało­ści w jakiej­kol­wiek ale dobrze opra­co­wa­nej formie.

    2. Piotr

      Umowa z podzia­łem na eta­py i zapła­tą za każ­dy z osob­na jest ryzy­kow­na. Zapewne klu­czo­we jest tutaj jakie to eta­py i jakie pro­duk­ty one gene­ru­ją. Muszą być one od sie­bie mak­sy­mal­nie nie­za­leż­ne (powiedz­my jak usłu­gi w SOA), w prze­ciw­nym razie wyko­naw­ca po np wyko­na­niu 3 eta­pów z 4 (i zgar­nię­ciu kasy za nie) zigno­ru­je ten ostat­ni i nie będzie go to bar­dzo bola­ło. Jeśli koń­co­wy pro­dukt zbyt moc­no pole­gał by na dzia­ła­niu modu­łów wypro­du­ko­wa­nych po tych 4 eta­pach, to klient zosta­je z kale­kim sys­te­mem i pustym budżetem. 

      Bezpieczniej wte­dy usta­lić opła­tę na koniec za całość.
      P.

    3. Jaroslaw Zelinski

      Oczywiście, że klu­czem jest to co nazwie­my w umo­wie eta­pem :). SOA czy gene­ral­nie kom­po­nen­to­we podej­ście do archi­tek­tu­ry, to pierw­sze lekar­stwo, dru­gie to two­rze­nie (dobrej) doku­men­ta­cji, bez któ­rej sytu­acja, w któ­rej wyko­naw­ca prze­rwie pra­ce (a to zawsze jest moż­li­we) jest tragedią.

    4. Jarosław Żeliński

      Umowa z podzia­łem na eta­py i zapła­tą za każ­dy z osob­na jest ryzykowna.”

      Dlaczego i dla kogo?

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.