Proces to strategia nie taktyka

Niekończące się dys­ku­sje o licz­bie pozio­mów dekom­po­zy­cji pro­ce­sów, ich zmien­no­ści, adap­ta­cyj­no­ści itp. zale­wa­ją fora inter­ne­to­we. Wydaje mi się, że nie­po­trzeb­nie – o ile wysi­li­my się na pew­ną małą analizę…

Niedawno pisa­łem o tym, czym jest stra­te­gia (Startegia krót­ko­ter­mio­wa). Ogólnie stra­te­gia to plan dłu­go­ter­mi­no­wy mówią­cy o tym jak reali­zu­je­my (pla­nu­je­my reali­zo­wać) wizje fir­my. Taktyka to pla­ny opi­su­ją­ce kon­kret­ne kam­pa­nie, krót­ko­ter­mi­no­we cele. Strategia jest usta­la­niem raz a dobrze”, tak­ty­ka to raczej coś, co w przy­pad­ku bra­ku sku­tecz­no­ści szyb­ko wymie­nia­my lub mody­fi­ku­je­my. Poniżej zna­ny już moim czy­tel­ni­kom model organizacji:

źr. Busnes Process Trends http://www.bptrendsassociates.com/
źr. Busnes Process Trends http://​www​.bptrend​sas​so​cia​tes​.com/

Strategia ryn­ko­wa orga­ni­za­cji to gene­ral­nie sens jej ist­nie­nia, reali­za­cja mode­lu biz­ne­so­we­go. Organizacja ma stra­te­gię wewnętrz­ną: jak jest wewnętrz­nie zor­ga­ni­zo­wa­na, by stra­te­gia ryn­ko­wa była sku­tecz­nie reali­zo­wa­na. Teraz dopie­ro pora na tak­ty­kę, doraź­nie usta­la­ne meto­dy reali­za­cji wewnętrz­nych pro­duk­tów, jaki­mi siła­mi, kompetencjami.

Trzy poziomy modelowania organizacji

Tak więc stra­te­gia ryn­ko­wa opi­su­je miej­sce orga­ni­za­cji w ryn­ko­wym łań­cu­chu war­to­ści, to jak orga­ni­za­cja reali­zu­je model biz­ne­so­wy (pro­ce­sy and-2-end, archi­tek­tu­ra pro­ce­sów). Każdy z tych pro­ce­sów biz­ne­so­wych wyso­kie­go pozio­mu” ma swój model (w więk­szych orga­ni­za­cjach czę­sto powsta­ją dodat­ko­wo tak zwa­ne pod-pro­ce­sy czy­li dekom­po­zy­cje pro­ce­sów). Pod tym wszyst­kim mamy ope­ra­cyj­ne zarzą­dza­nie, to czym zaj­mu­ją się bez­po­śred­nio kadry kie­row­ni­cze: zakre­sy obo­wiąz­ków, pro­ce­du­ry, instruk­cje sta­no­wi­sko­we, dobór narzę­dzi (w tym oprogramowanie).

Z lite­ra­tu­rze moż­na spo­tkać poniż­szy podział na pozio­my modelowania:

Poziomy modelowania_1

Tu widać, że pro­ce­sy biz­ne­so­we to wewnę­trzy, orga­ni­za­cyj­ny sys­tem dzia­ła­nia. Szczegółowe opi­sy kon­kret­nych aktyw­no­ści w posta­ci czyn­no­ści (task) i ich pro­ce­dur (work instruc­tion) to dopie­ro mate­riał” na ewen­tu­al­ną auto­ma­ty­za­cję, zbu­do­wa­nie pla­no­wa­nej usłu­gi apli­ka­cyj­nej” (przy­pad­ku użycia).

Chce tu zwró­cić uwa­gę na waż­ną rzecz: za wyjąt­kiem naj­niż­sze­go pozio­mu, pozo­sta­łe to abs­trak­cyj­ne mode­le. W więk­szo­ści orga­ni­za­cji ich nie ma (ludzie na co dzień raczej nie myślą abs­trak­cyj­nie). Czy są potrzeb­ne? Dopiero wte­dy gdy pad­nie pyta­nie Dlaczego tak się dzie­je jak się dzie­je?”. Organizacja, któ­ra wyewo­lu­owa­ła np. z małej rodzin­nej fir­my, może się roz­wi­jać i wpro­wa­dzać zmia­ny wewnętrz­ne na czu­ja”, może naśla­do­wać inne (z regu­ły tak jest – kon­for­mizm), ale może też sobie zadać pyta­nie dla­cze­go jest tak jak jest?” Dotyczy to zresz­tą każ­dej organizacji.

Powyższe ana­li­zy i mode­le mają za zada­nie tyl­ko jed­no: pro­of of con­cept”. Zanim coś zmie­ni­my prze­te­stuj­my ten pomysł. Wcześniej pad­nie pyta­nie: Czy my zna­my przy­czy­ny sta­nu obec­ne­go?” Bez tego nie da się wpro­wa­dzać zmian i mieć przy tym świa­do­mo­ści ryzy­ka poten­cjal­nych skutków.

Padło powy­żej sło­wo narzę­dzia pra­cy”, i że wśród nich jest tak­że opro­gra­mo­wa­nie. Tak, ale dobie­ra­jąc lub zmie­nia­jąc narzę­dzia pra­cy, nale­ży naj­pierw okre­ślić wyma­ga­nia jakie powin­ny speł­niać… bo to obni­ża ryzy­ko złe­go wyboru.

Jednym z naj­więk­szych błę­dów popeł­nia­nych w pro­jek­tach zwią­za­nych z mode­lo­wa­niem pro­ce­sów biz­ne­so­wych jest zapo­mi­na­nie o tym, że model pro­ce­su to model orga­ni­za­cji a nie tyl­ko doku­ment, i o tym, że pomię­dzy pro­ce­sa­mi a pro­ce­du­ra­mi, umie­jęt­no­ścia­mi, instruk­cja­mi obsłu­gi narzę­dzi, jest gra­ni­ca. To się nazy­wa utra­ta pano­wa­nia nad zło­żo­no­ścią pro­jek­tu. Kolejny pro­blem to powszech­ne trak­to­wa­nie nota­cji (np. BPMN) jako biblio­te­ki sym­bo­li, co jest klu­czo­wym błę­dem: nota­cja to model poję­cio­wy – pod­sta­wo­we narzę­dzie ana­li­zy i modelowania.

Agilian nowa wersja. Burza mózgów sformalizowana …

Niedawno napi­sa­łem:

Burze mózgów mają sens, jak naj­bar­dziej, ale w przy­pad­ku zespo­łu spe­cja­li­stów. Jeżeli zacho­dzi ryzy­ko, że jeden spe­cja­li­sta w danej dzie­dzi­nie, będzie pra­co­wał nad uzy­ska­niem roz­wią­za­nia zbyt dłu­go na co nie ma cza­su, zamiast jed­ne­go spe­cja­li­sty ?sadza­my? kil­ku (słyn­na sce­na w Apollo 13). Jest bar­dzo praw­do­po­dob­ne, że któ­ryś z nich wpad­nie na wła­ści­wy pomysł szyb­kiej niż kole­dzy. (Burza mózgów ? home­opa­tia w ana­li­zie).

I pro­szę pisze­my i roz­ma­wia­my o tym, z dru­giej stro­ny mamy for­mal­ne UML, BPMN itp. i jakoś sta­le bra­ku­je łącz­ni­ka”. Z zasa­dy nie rekla­mu­ję opro­gra­mo­wa­nia. Uważam, że jego sprze­da­wa­nie to inna kom­pe­ten­cja. Jednak nie da się ukryć, że jestem użyt­kow­ni­kiem cze­goś”. Czym to jest? Pakiet typu CASE ([[Computer-Aided Software Engineering, Computer-Aided Systems Engineering]]) jakim jest [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgra­de i… mamy burzę mózgów :):

Narzędzie przy­dat­ne bo mając rzut­nik moż­na spo­koj­nie zarzu­cić tabli­cę i jej fotografowanie :).

Od pew­ne­go już cza­su pakiet ten pozwa­la na two­rze­nie dia­gra­mów [[ArchiMate]]. Notacja ta, to narzę­dzie do mode­lo­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. Co to? Ogólnie jest to odpo­wiedź na pyta­nie: jak zarzą­dzać zależ­no­ścia­mi pomię­dzy biz­ne­sem, pro­ce­sa­mi i infra­struk­tu­rą IT. Można np. tak:

Diagram ArchiMate Sprzedaż

Swego cza­su pisa­łem już o mode­lach BMM uży­wa­nych na eta­pie ana­li­zy biz­ne­so­wej i doku­men­to­wa­nia jej efektów:

BMMOvierwiev

Ktoś może zapy­tać po co to wszyst­ko w pakie­cie do ana­li­zy i mode­lo­wa­nia? Bo klu­czo­wym mier­ni­kiem jako­ści ana­li­zy, jej doku­men­ta­cji i mode­li jest spój­ność i pano­wa­nie nad cało­ścią. Jedynym spo­so­bem osią­gnię­cia tego, rela­tyw­nie niskim nakła­dem pra­cy, jest zbio­ro­we, spój­ne zarzą­dza­nie każ­dym ele­men­tem doku­men­ta­cji. Wtedy może­my zwe­ry­fi­ko­wać doku­men­ta­cję i zba­dać wpływ każ­de­go obiek­tu na inne w ramach całej dokumentacji:

Macierz procesu zadnia-role

Można tak­że zbu­do­wać macierz powią­zań pomię­dzy dowol­nie wybra­nym zesta­wem obiek­tów w całej dokumentacji.

To pozwa­la owe kar­tecz­ki powią­zać z mode­la­mi pro­ce­sów i dzie­dzi­ny, spraw­dzić czy potra­fi­my uza­sad­nić każ­dy ele­ment w wyma­ga­niach i wychwy­cić te nie­ob­słu­żo­ne. Do tego ana­li­za ryzyk (ana­li­zy wpły­wu) sta­ja wręcz banal­ne”, bo sta­no­wią po pro­tu raport z tak opra­co­wa­nej doku­men­ta­cji i mode­li. Jeżeli jest ona kom­plet­na i spój­na to mamy te dane na tacy”.

Po co nam CASE?

Bo

Dzięki narzę­dziom CASE pro­jek­ty two­rzy się dokład­niej, a pra­ca nad dia­gra­ma­mi, spraw­dza­nie ich popraw­no­ści oraz śle­dze­nie wyko­na­nych testów jest prost­sze i szyb­sze. (wie­cej: http://​www​.eio​ba​.pl)

Tak więc gorą­co pole­cam sto­so­wa­nie narzę­dzi (lista narzę­dzi CASE). Zaryzykował bym nawet tezę, że brak takich narzę­dzi u ana­li­ty­ka to jak by sto­larz pra­cu­ją­cy wyłącz­nie siekierą…

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

dashboard

W arty­ku­le o szko­le­niu i ana­li­zie na bazie stan­dar­du IIBA i BABoK napi­sa­łem, że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać, bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być lote­rią.” (źr. IIBA czy­li ?jak to nie­któ­rzy robią w Ameryce? | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów.)

Pisząc to mam świa­do­mość tego, że przy­tła­cza­ją­ca więk­szość dostaw­ców opro­gra­mo­wa­nia wma­wia swo­im klien­tom, że oce­na ren­tow­no­ści jest nie­moż­li­wa w pro­jek­tach IT i nale­ży kupić co dają a nie jęczeć. Niestety wie­lu kupu­ją­cych w to wie­rzy i inwe­stu­je nie raz wie­lo­krot­nie wię­cej niż mia­ło by to eko­no­micz­ny sens.

(moja uwa­ga rok 2019: teraz mogę oce­nić, że więk­szość opro­gra­mo­wa­nia jakie audy­to­wa­łem, mia­ła nawet o rząd wiel­ko­ści wię­cej kodu niż mogła­by mieć!) 

Popatrzmy więc na pierw­szy etap ana­li­zy biz­ne­so­wej, budo­wę wizji pro­jek­tu i oce­nę wyko­ny­wal­no­ści. Pierwszy etap to ana­li­za strategiczna.

Analiza stra­te­gicz­na dzia­łal­no­ści to ana­li­za rela­cji pomię­dzy cela­mi biz­ne­so­wy­mi a biz­ne­so­wy­mi funk­cja­mi wspie­ra­ją­cy­mi je. Wizja roz­wią­za­nia powin­na odno­sić się do szan­sy biz­ne­so­wej i celu biz­ne­so­we­go. Tak więc powin­na powstać wizja reali­za­cji celu biz­ne­so­we­go (a naj­pierw sam cel oczy­wi­ście). Wizja ta naj­czę­ściej jest pew­nym ide­ałem, któ­ry nie zawsze jeste­śmy w sta­nie zre­ali­zo­wać (i czę­sto tak jest). Jednak ide­ał ten nale­ży zde­fi­nio­wać bo sta­no­wi on nasze zro­zu­mie­nie celu biz­ne­so­we­go, celu do któ­re­go fir­ma dąży.

Jak zapew­ne pamię­ta­my z pod­staw mar­ke­tin­gu: wizja fir­my do stan (swój lub swo­je­go oto­cze­nia ryn­ko­we­go), któ­ry postrze­ga­my jako ide­al­ny, misja fir­my to spo­sób dąże­nia do osią­gnię­cia tego celu.

Projekt roz­wo­ju ana­lo­gicz­nie, powi­nien mieć wizję (ide­al­ne roz­wią­za­nie), plan (osią­gal­ne roz­wią­za­nie) i stra­te­gię osią­gnię­cia tego pla­nu. Całość powin­na być osa­dzo­na w budże­cie fir­my i jej rachun­ku prze­pły­wów gotów­ko­wych. I nie cho­dzi jedy­nie o umiesz­cze­nie kosz­tów pro­jek­tu w budże­cie i oce­nę czy fir­ma to wytrzy­ma (meto­da bar­dzo czę­sto for­so­wa­na przez sprze­daw­ców roz­wią­zań IT). Chodzi o to by powią­zać te kosz­ty z odpo­wia­da­ją­cy­mi im przy­cho­da­mi oce­nić zasad­ność ich ponoszenia.

Tak więc mamy trzy ele­men­ty projektu:

  1. stan obec­ny,
  2. wizję
  3. oraz pla­no­wa­ny zakres projektu

W ramach ana­li­zy biz­ne­so­wej powi­nien naj­pierw powstać opis sta­nu obec­ne­go. Opis ten nie musi być kosz­tow­nym mode­lem pro­ce­sów biz­ne­so­wych na stan dzi­siej­szy”. Opracowanie szcze­gó­ło­we­go i kosz­tow­ne­go opi­su sta­nu obec­ne­go nie wie­le wno­si do pro­jek­tu a jest bar­dzo kosz­tow­ne. Stan obec­ny, tak zwa­ny opis as-is, to efekt tego jak poszcze­gól­ni mene­dże­ro­wie zarzą­dza­ją swo­imi zaso­ba­mi, a to zaś jest efek­tem zadań jakie im posta­wio­no. Pastwienie się nad tym bar­dzo rzad­ko wno­si war­to­ści do projektu.

Ważnym ele­men­tem pro­jek­tu jest zde­fi­nio­wa­nie po co to robi­my” i nie powi­nien to być argu­ment bo inni mają”. Benchmarking na tym eta­pie, pole­ga­ją­cy na porów­na­niu zaso­bów jest złym pomy­słem. Porównanie wskaź­ni­ków (czy­li wła­śnie bench­mar­king) nie jest porów­na­niem zaso­bów! Porównując się np. z kon­ku­ren­cją porów­nu­je­my cudze osią­gi z wła­sny­mi, jeże­li mamy taką moż­li­wość, to poza przy­cho­da­mi tak­że kosz­ty itp. Ale porów­na­nie takie to nie jest oce­na czym oni jeż­dżą” a oce­na jak oni jeżdżą”.

Po dru­gie kolej­na mar­ke­tin­go­wa zasada: 

nie da się sko­pio­wać cudze­go biz­ne­su, moż­na co naj­wy­żej usta­wić się obok. To jak w spo­rcie, goniąc kogoś może­my co naj­wy­żej iść po cudzych śla­dach za kimś, ale to nie to samo co zaję­cie cudzej pozy­cji bo to nie moż­li­we tą meto­dą. Wyprzedzanie pole­ga na zmia­nie toru ruchu by obejść konkurenta!

Tak więc pierw­szy krok to wizja. Drugi krok to ana­li­za wyma­gań, trze­ci to usta­le­nie zakre­su pro­jek­tu czy­li opra­co­wa­nie stu­dium wyko­ny­wal­no­ści. Dalej ma miej­sce uszcze­gó­ło­wie­nie pla­nu w zakre­sie projektu.

Określenie obsza­ru ren­tow­no­ści pro­jek­tu. Należy to zro­bić na samym począt­ku przy oka­zji budże­to­wa­nia i ana­li­zy prze­pły­wów gotów­ko­wych. To tu są dane o tym jakim kosz­tem i jakie korzy­ści chce­my osiągnąć.

Gdybyśmy mie­li wstęp­ną spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych, to z każ­dym kolej­nym wyma­ga­niem przy­ra­sta łącz­ny koszt imple­men­ta­cji cało­ści. Korzyści poja­wia­ją się dopie­ro od pew­ne­go miej­sca, pew­ne mini­mum musi być zaim­ple­men­to­wa­ne, żeby sys­tem w ogó­le był przy­dat­ny. Idąc dalej osią­ga­my próg mini­mal­ny: korzy­ści zre­kom­pen­so­wa­ły nakła­dy. W mia­rę imple­men­ta­cji kolej­nych wyma­gań rosną korzy­ści jed­nak od pew­ne­go momen­tu ten wzrost się zała­mu­je. Dalsze ulep­sze­nia powo­du­ją, że koszt ulep­szeń zja­da” powsta­ją­ce korzy­ści. Osiągamy gór­ny próg rentowności.

Po wyko­na­niu takiej ana­li­zy wska­zu­je­my opty­mal­ny zakres pro­jek­tu: miej­sce gdzie bilans korzy­ści jest naj­ko­rzyst­niej­szy. Jest to stan to-be czy­li zapla­no­wa­ny świa­do­mie zakres projektu.

Jak prowadzić taką analizę?

Po pierw­sze nale­ży opra­co­wać spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych. Każde z tych wyma­gań powin­no uzy­skać prio­ry­tet, np.:

  1. Bez nie­go potrze­by biz­ne­so­we nie zosta­ną zrealizowane
  2. Bez nie­go roz­wią­za­nie będzie mia­ło ogra­ni­czo­ną użyteczność
  3. Bez nie­go roz­wią­za­nie zre­ali­zu­je potrzeb­ny w pod­sta­wo­wej, pro­stej formie

To pozwo­li odrzu­cić wyma­ga­nia, któ­re powo­du­ją prze­kro­cze­nie budże­tu ren­tow­no­ści, a któ­re nie powo­du­ją zbyt duże­go pomniej­sze­nia osią­ga­nych korzyści.

Proces ten jest ite­ra­cyj­ny, mając jako model finan­so­wy rachu­nek prze­pły­wów gotów­ko­wych, może­my testo­wać wpływ wyma­gań na koszt pro­jek­tu i jego ren­tow­ność. Aby było to moż­li­we nale­ży w całym pro­ce­sie ana­li­zy wyma­gań pro­wa­dzić testy pro­jek­tu. Polegają one na tak zwa­nym śla­do­wa­niu. Cechy użyt­ko­we roz­wią­za­nia muszą się mapo­wać na potrze­by (cele) biz­ne­so­we. Stałe testo­wa­nie tego mapo­wa­nia to wła­śnie śla­do­wa­nie”. Zakres pro­jek­tu to w efek­cie lista cech pla­no­wa­nych do reali­za­cji w pro­jek­cie (wyma­ga­nych do reali­za­cji wizji). Śladowanie to, w całej doku­men­ta­cji obej­mu­je spraw­dza­nie mapowania:

Potrzeby biz­ne­so­we <?> Cechy użyt­ko­we wizji i zakre­su <?> Wymagania <?> Specyfikacja

Projekt ana­li­zy wyma­gań na każ­dym eta­pie jest testo­wa­ny, wali­do­wa­ny. Walidacja to spraw­dze­nie czy wyma­ga­nia są wła­ści­we. Kolejnym kro­kiem jest wyspe­cy­fi­ko­wa­nie roz­wią­za­nia. Zależnie od pro­jek­tu (może to być pro­jekt zmian orga­ni­za­cyj­nych, pro­jekt wdro­że­nia nowe­go opro­gra­mo­wa­nia) wali­do­wa­ne są wyma­ga­nia np. na nowy, pro­ce­so­wy sys­tem zarzą­dza­nia fir­mą (np. wyma­ga­nia w sto­sun­ku do nowej struk­tu­ry orga­ni­za­cyj­nej) albo na nowe opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie (np. ERP). Weryfikacja to testo­wa­nie roz­wią­za­nia, okre­śle­nie czy roz­wią­za­nie speł­nia wymagania.

Walidacja wymagań

Walidacja pole­ga na prze­te­sto­wa­niu czy nasze wyma­ga­nia zaspo­ka­ja­ją reali­za­cję celu biz­ne­so­we­go. Aby taki test prze­pro­wa­dzić, nale­ży zbu­do­wać model fir­my, któ­ry będzie­my testo­wa­li (raczej nie ma sen­su robie­nie tego na żywym cie­le”, było by to bar­dzo kosz­tow­ne). Te mode­le tu, to nic inne­go jak mode­le pro­ce­sów biz­ne­so­wych. Jednak model pro­ce­su to nie model wszyst­kie­go co się dzie­je”. Model pro­ce­su do testów to wewnętrz­ny model prze­pły­wu wartości”.

Modelujemy wyłącz­nie pro­ce­sy (prze­pływ pra­cy), nie pro­ce­du­ry, nie zakre­sy obo­wiąz­ków i nie kom­pe­ten­cje czy regu­ły biz­ne­so­we. Pozostałe szcze­gó­ły to obszar zarzą­dza­nia zaso­ba­mi czy zakre­sa­mi kom­pe­ten­cji (tu wię­cej o mode­lo­wa­niu). Mając popraw­ny model pro­ce­sów, może­my prze­te­sto­wać każ­de wyma­ga­nie i jego wpływ na procesy.

Biznesowa spe­cy­fi­ka­cja wyma­gań opi­su­je tak zwa­ną czar­ną skrzyn­kę”, czy­li nie zna­ne nam od środ­ka roz­wią­za­nie. Wymagania na tym eta­pie to tak zwa­ne przy­pad­ki uży­cia. Walidacja pole­ga wyłącz­nie na mapo­wa­niu (śla­do­wa­niu) celów biz­ne­so­wych na te wymagania.

Weryfikacja roz­wią­za­nia

Kolejny, ostat­ni etap ana­li­zy biz­ne­so­wej to wer­sy­fi­ka­cja roz­wią­za­nia. Mając tak zwa­li­do­wa­ną listę wyma­gań (tak zwa­ną Specyfikację Wymagań Biznesowych) może­my zabrać się za wery­fi­ka­cję roz­wią­za­nia. Tu sce­na­riusz wyglą­da tak:

  1. zapra­sza­my do skła­da­nia ofert dostaw­ców goto­we­go opro­gra­mo­wa­nia prze­ka­zu­jąc im spe­cy­fi­ka­cje wymagań,
  2. dostaw­ca pra­cu­jąc nad ofer­tą wery­fi­ku­je na ile jego roz­wią­za­nie speł­nia wyma­ga­nia (wyko­nu­je tak zwa­ną [[ana­li­zę gap/fit]]), powi­nien przed­sta­wić listę tak lub nie speł­nia­nia wyma­gań i swo­ją wycenę,
  3. jeże­li na tym eta­pie, ofer­ty są nie­sa­tys­fak­cjo­nu­ją­ce, opra­co­wu­je­my spe­cy­fi­ka­cję każ­dej funk­cjo­nal­no­ści (każ­de­go wyma­ga­nia) czy­li pro­jek­tu­je­my roz­wią­za­nie, któ­re­go nie zna­leź­li­śmy na rynku.

Na tym eta­pie zapa­da decy­zja o archi­tek­tu­rze roz­wią­za­nia: podział na ele­men­ty (pod­sys­te­my) goto­we i dedy­ko­wa­ne. Dedykowane muszą zostać zapro­jek­to­wa­ne. Projekty te (mode­le) są tak­że wery­fi­ko­wa­ne.

Kolejny etap to zapy­ta­nie o ofer­ty na reali­za­cję zapro­jek­to­wa­nych pod­sys­te­mów. W przy­pad­ku pro­jek­tów IT kom­plet­ne wyma­ga­nia to: przy­pad­ki uży­cia, regu­ły biz­ne­so­we, ogra­ni­cze­nia (wyma­ga­nia poza­funk­cjon­la­ne). Zaleca się (nie umiesz­czo­no na dia­gra­mie) uzu­peł­nie­nie mode­lu pro­ce­sów o tak zwa­ną taksonomię.

Jeżeli poja­wi się potrze­ba zapro­jek­to­wa­nia dedy­ko­wa­ne­go roz­wią­za­nia, poja­wi się model dzie­dzi­no­wy sys­te­mu wraz z uszcze­gó­ła­wia­ją­cy­mi go dia­gra­ma­mi sta­nów. Weryfikacja tej czę­ści spe­cy­fi­ka­cji pole­ga na tak zwa­nym testo­wa­niu bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia. Tu są to dia­gra­mu sekwen­cji UML.

Całość pro­ce­su ana­li­zy i wery­fi­ka­cji bazu­je na opi­sa­nej już wcze­śniej Analizie Systemowej. Jeżeli zaś ktoś pro­po­nu­je jako wynik ana­li­zy wyma­gań, nie­we­ry­fi­ko­wal­ne wie­lo­stro­ni­co­we opi­sy w rodza­ju user sto­ry lub wypunk­to­wa­ne listy jako wyni­ki wywia­dów, burzy mózgów czy sesji JAD, to war­to mieć świa­do­mość, że to bar­dzo ryzy­kow­ne, bo nie­we­ry­fi­ko­wal­ne i nie­te­sto­wal­ne dokumenty.

Specyfikacja zawie­ra­ją­ca set­ki wypunk­to­wa­nych szcze­gó­ło­wo wyma­gań to nic inne­go jak nie­zro­zu­mie­nie fak­tu, że lista taka nie pod­da­je się żad­nym wali­da­cjom, a dla dostaw­cy goto­we­go opro­gra­mo­wa­nia jest bez­war­to­ścio­wa z uwa­gi na zbyt­nią szcze­gó­ło­wość. Z taka listą ana­li­za gap/fit wyka­że pra­wie cał­ko­wi­tą nie­zgod­ność z tym co ma w ofer­cie i u zde­spe­ro­wa­ne­go dostaw­cy wyge­ne­ru­je ofer­tę na tak zwa­ne kasto­mi­za­cje, te zaś zabi­ją budżet projektu.

Czy to warte zachodu

Praktyka takich ana­liz poka­zu­je, że pro­por­cje pro­jek­tów: ana­li­za i pro­jek­to­wa­nie vs. reali­za­cja, mają nastę­pu­ją­cą postać (dane sko­ry­go­wa­ne dla pro­jek­tów zna­nych auto­ro­wi w Polsce):

1. Czasowo: 50/50% (dane z USA: 75/25),

2. Kosztowo: 20 – 30/80 – 70% (dane z USA: 50/50, roz­rzut zale­ży od stop­nia zło­żo­no­ści dzie­dzi­ny systemu),

(zależ­nie od spe­cy­fi­ki pro­jek­tu i jego zło­żo­no­ści mogą poja­wić się pew­ne odstęp­stwa). Tak więc jak bume­rang wra­ca ta sama war­tość pro­go­wa pro­jek­tów, dla któ­rych war­to takie ana­li­zy robić. Jeżeli uzna­my, że opi­sa­na tu ana­li­za wyma­ga pew­nych nie­ma­łych kom­pe­ten­cji i doświad­cze­nia oraz pew­ne­go mini­mal­ne­go cza­su jaki nale­ży poświę­cić na zba­da­nie i opra­co­wa­nie mode­lu fir­my to jej koszt zaczy­na się od kil­ku­na­stu tysię­cy, daj­my na to 15 tys. W takim razie budżet całe­go pro­jek­tu powi­nien wymo­ści co naj­mniej 5 x 15 = 75 tys. zł. (pamię­ta­my, że koszt ana­li­zy to 20% war­to­ści pro­jek­tu). Analiza taka (dla tego nie­skom­pli­ko­wa­ne­go przy­pad­ku) wraz z pro­jek­to­wa­niem trwa, bio­rąc pod uwa­gę czas ocze­ki­wa­nia na przy­go­to­wy­wa­nie danych przez fir­mę ana­li­zo­wa­ną, ok. jed­ne­go miesiąca.

Ktoś może zarzu­cić powyż­szej kal­ku­la­cji nie­re­ali­zo­wal­ność wdro­że­nia w takim cza­sie. Odpowiem z prak­ty­ki tak: wdro­że­nia sys­te­mów ERP pozba­wio­ne eta­pu tak zwa­nej kasto­mi­za­cji” są bar­dzo spraw­ne. Koszty kasto­mi­za­cji zaś to nawet 75% kosz­tów całe­go wdro­że­nia (war­to popa­trzeć na ofer­ty, a moż­na tych kosz­tów uniknąć!).

Firmy pro­gra­mi­stycz­ne mają­ce dobry pro­jekt reali­zu­ją go i odda­ją do użyt­ku z regu­ły już w pierw­szym podej­ściu. Tak zwa­ne pro­to­ty­py, testy, odkry­wa­nie wyma­gań itp. to cechy pra­cy na źle, zbyt ogól­nie i bez testo­wa­nia (np. tak zwa­ne user sto­ry) okre­ślo­nych wyma­ga­niach. Jeżeli pro­jekt jest już wyko­na­ny i prze­te­sto­wa­ny na eta­pie ana­li­zy i wery­fi­ka­cji, fir­ma pro­gra­mi­stycz­na musi tyl­ko wyko­nać implementacje.

Jeżeli ktoś mimo to zaprze­cza powyż­sze­mu to musi mieć świa­do­mość, że negu­je potwier­dzo­ne doko­na­nia ostat­nich 20 lat wie­lu dobrych firm ana­li­tycz­nych na świe­cie, a od nie­daw­na tak­że w Polsce. Działalność IIBA i jej człon­ko­wie są na to żywym dowo­dem (na dowód mam tak­że swo­je referencje).

Dlaczego takich ana­liz wyko­nu­je się mało? No cóż, nie są one w inte­re­sie dostaw­cy, któ­ry twier­dzi, że jego sys­tem np. ERP jest na pew­no dobry”. Po dru­gie wie­le firm kupu­ją­cych opro­gra­mo­wa­nie uzna­je, że ich nie doty­czy ryzy­ko pro­jek­to­we i pomi­ja­ją ana­li­zy, a te są prze­cież niczym innym jak obni­że­niem ryzy­ka nie­po­wo­dze­nia takich pro­jek­tów. Pamiętajmy, że ponad 80% pro­jek­tów wdro­że­nio­wych w IT to pro­jek­ty z sil­nie prze­kro­czo­ny­mi budże­ta­mi i ter­mi­na­mi, część z nich (sza­cu­je się je na ok. 16%) to pro­jek­ty zanie­cha­ne z tego powodu.

Każdy z Państwa sam musi sobie odpo­wie­dzieć na pyta­nie: czy 20% budże­tu jest war­te tego by chro­nić pozo­sta­łe 80%.

(źr. bada­nia Cortex), dostęp 2011)