Kluczowe błę­dy jakie obser­wu­ję w pre­zen­to­wa­nych mi nie raz przez klien­tów do audy­tu cudzych opra­co­wa­niach i mode­lach to moim zda­niem zupeł­nie zbęd­ne opi­sy i mode­le czyn­no­ści oczy­wi­stych, będą­cych kom­pe­ten­cją pra­cow­ni­ka lub po pro­stu zwy­cza­jo­wych lub co gor­sza są to nie­po­trzeb­ne mode­le posia­da­nych instruk­cji obsłu­gi i pod­ręcz­ni­ków użyt­kow­ni­ka sprzę­tu lub uży­wa­ne­go opro­gra­mo­wa­nia. Drugim czę­sto spo­ty­ka­nym błę­dem jest zupeł­ny brak meto­dy­ki two­rze­nia mode­lu czy­li brak tego o czym już nie raz wspo­mi­na­łem: seman­ty­ki i syn­tak­ty­ki mode­lu. Inaczej mówiąc model musi mieć okre­ślo­ny słow­nik sym­bo­li i zasa­dy ich łącze­nia. Rozumiem, że błęd­ne mode­le wyko­nu­ją nie­do­świad­cze­ni ana­li­ty­cy. Jednak szkol­ne błę­dy obser­wu­ję w pra­cach ludzi i firm bio­rą­cych za to pie­nią­dze, nie raz bar­dzo duże. Nie raz są to nie­ste­ty posia­da­ją­ce świa­to­wą mar­kę fir­my doradcze.

Uważam, że naj­pro­ściej jest sto­so­wać stan­dar­dy. Np. do mode­lo­wa­nia pro­ce­sów uży­wać nota­cji BPMN a do ana­li­zy obiek­to­wej nota­cji UML, obie z okre­ślo­ną i dostęp­ną w sie­ci WWW meto­dy­ką mode­lo­wa­nia (http://​www​.omg​.org). Jeszcze sto­sun­ko­wo popu­lar­na jest w nie­któ­rych zasto­so­wa­niach nota­cja eEPC rodem z fir­my IDS Scheer. W uza­sad­nio­nych przy­pad­kach moż­na stwo­rzyć wła­sną pro­stą nota­cję. Sama nota­cja jed­nak nie chro­ni nas przed popeł­nia­niem błę­dów ana­li­tycz­nych podob­nie jak sama nor­ma opi­su­ją­ca wymia­ry i zasto­so­wa­nie gniazd­ka elek­trycz­ne­go w ścia­nie nie chro­ni niko­go przed wetknię­ciem tam goły­mi ręka­mi gwoź­dzia.

Jak, co i po co modelować

Poprawny model orga­ni­za­cji, w szcze­gól­no­ści mapa pro­ce­sów biz­ne­so­wych, powi­nien opi­sy­wać tyl­ko przed­miot ana­li­zy np. spe­cy­fi­kę orga­ni­za­cji będą­ca np. źró­dłem jej prze­wa­gi kon­ku­ren­cyj­nej i to jak orga­ni­za­cja tę spe­cy­fi­kę two­rzy. Model powi­nien się odwo­ły­wać do innych ist­nie­ją­cych już doku­men­tów, np. zakre­su kom­pe­ten­cji pra­cow­ni­ka czy instruk­cji sta­no­wi­sko­wej. Model zawsze powi­nien mieć jakiś cel swo­je­go powsta­nia i kontekst.

Poniżej ogól­na zasa­da mode­lo­wa­nia organizacji:

Diagram powyż­szy poka­zu­je trzy war­stwy, pozio­my szcze­gó­ło­wo­ści, mode­lo­wa­nia sta­no­wią­ce osob­ne eta­py pro­jek­tu mode­lo­wa­nia orga­ni­za­cji. Sam model nie powi­nien jed­nak być przed­mio­tem pro­jek­tu bo sam z sie­bie moim zda­niem prak­tycz­nie do nicze­go nie słu­ży poza poło­że­niem go na pół­ce. Model to narzę­dzie ana­li­tycz­ne wspo­ma­ga­ją­ce pra­ce nad reor­ga­ni­za­cją, oce­ną ren­tow­no­ści inwe­sty­cji, ana­li­zą wyma­gań na sys­te­my IT itp. Głównym celem jego wyko­na­nia jest zro­zu­mie­nie ana­li­zo­wa­ne­go przed­mio­tu i wypra­co­wa­nie rekomendacji.

Celowość każ­de­go mode­lu zale­ży od rodza­ju pro­jek­tu. Jeżeli two­rzy­my biz­ne­splan lub to wystar­czy model biz­ne­so­wy. Jeżeli pla­nu­je­my opty­ma­li­za­cję fir­my, ana­li­zę ren­tow­no­ści inwe­sty­cji lub wdro­że­nie Zrównoważonej Karty Wyników to nale­ży wyko­nać model pro­ce­sów biz­ne­so­wych. Jeżeli zaś inte­re­su­ją nas szcze­gó­ły anga­żo­wa­nych zaso­bów w pro­ce­sach, sce­na­riu­sze reali­za­cji poszcze­gól­nych pro­ce­sów itp. wyko­nu­je­my opi­sy wnę­trza pro­ce­sów czy­li doku­men­tu­je­my ich sce­na­riu­sze lub two­rzy­my tak zwa­ne procedury.

Jak nie trud­no sie domy­ślić w mia­rę prze­miesz­cza­nia się w dół pira­mi­dy pra­co­chłon­ność, a co za tym idzie i koszt, wyko­na­nia tych mode­li szyb­ko rośnie­dla­te­go nale­ży bar­dzo ostroż­nie decy­do­wać się na podej­mo­wa­nie sie ich reali­za­cji. Sugeruję przy­ję­cie zało­że­nia w któ­rym taka ana­li­za i model słu­żą obni­że­niu ryzy­ka podej­mo­wa­nych decy­zji. Przy takim podej­ściu moż­li­wa sta­je sie oce­na ren­tow­no­ści pro­jek­tu ana­li­tycz­ne­go i łatwiej jest okre­ślić budżet na taki pro­jekt. Konsultant powi­nien umieć taka oce­nę przeprowadzić.

W rapor­tach z ana­liz powin­na być utrzy­my­wa­na zasa­da, że dla jed­nej oso­by doku­men­ta­cja (lub jej część adre­so­wa­na do oso­by peł­nią­cej w fir­mie kon­kret­ną funk­cję) nie powin­na prze­kra­czać kil­ku­dzie­się­ciu stron łącz­nie z dia­gra­ma­mi (bez załącz­ni­ków). Dokumenty dłuż­sze z regu­ły nie są czy­ta­ne i moim zda­niem nicze­mu nie słu­żą, są kosz­tow­ne i nie­przy­dat­ne. Dokumentacja ana­li­zy, to sko­men­to­wa­ne dia­gra­my opi­su­ją­ce pro­blem i jego roz­wią­za­nie. Tekst sta­no­wi stresz­cze­nie i ewen­tu­al­ny opis tego co wyma­ga­ło by słow­ne­go prze­ka­zu. Wybrane dia­gra­my umiesz­cza­ne w tek­ście powin­ny sta­no­wić ilu­stra­cję jego tre­ści. Dokładne ich wer­sje nale­ży umiesz­czać w załącz­ni­kach do któ­rych zain­te­re­so­wa­na oso­ba zawsze może zaj­rzeć. Każdy raport powi­nien mieć na począt­ku jed­no­stro­ni­co­we stresz­cze­nie, pod­kre­ślam: JEDNOSTRONICOWE.Konieczność zamknię­cia stresz­cze­nia na jed­nej stro­nie zmu­sza do sku­pie­nia się na klu­czo­wym ele­men­cie pro­jek­tu bo tyl­ko ten jest istot­ny dla naj­wyż­szych władz w firmie.

O analizie wymagań na system IT

Projekt, któ­re­go celem jest okre­śle­nie wyma­gań na sys­tem infor­ma­tycz­ny wymaga:

• ana­li­zy oto­cze­nia ryn­ko­we­go orga­ni­za­cji, w któ­rej ma być pro­wa­dzo­ne wdrożenie,
• mode­lu wewnętrz­ne­go funk­cjo­no­wa­nia czy­li map pro­ce­sów biznesowych,
• okre­śle­nia, któ­re pro­ce­sy biz­ne­so­we będą wspie­ra­ne nowym sys­te­mem czy­li okre­śle­nia zakre­su projektu
• opi­sa­nia danych, któ­re sys­tem będzie prze­twa­rzał i wyko­na­nie ich modelu,

Celem ana­li­zy oto­cze­nia ryn­ko­we­go orga­ni­za­cji jest upew­nie­nie się, że rozu­mie­my spo­sób jej funk­cjo­no­wa­nia. Analiza powin­na poka­zać co jest głów­nym przed­mio­tem dzia­łal­no­ści orga­ni­za­cji. Wiedza ta umoż­li­wia okre­śle­nie prio­ry­te­tu każ­dej ocze­ki­wa­nej od nowe­go sys­te­mu funk­cjo­nal­no­ści i ewen­tu­al­ne świa­do­me ich mody­fi­ka­cje w przy­pad­ku gdy budżet pro­jek­tu nie pozwo­li zre­ali­zo­wać wszyst­kich ocze­ki­wań. Pozwala tak­że na wza­jem­ne zro­zu­mie­nie dzia­łal­no­ści Firmy przez wyko­naw­cę i zle­ce­nio­daw­cę, bez któ­re­go nie wyobra­żam sobie żad­ne­go sku­tecz­ne­go wdro­że­nia i analizy.

Wykonanie mode­lu funk­cjo­no­wa­nia orga­ni­za­cji to zbu­do­wa­nie mapy jej pro­ce­sów biz­ne­so­wych. Celem jest opi­sa­nie jak orga­ni­za­cja pra­cu­je (two­rzy war­tość ryn­ko­wą) i doko­na­nie ewen­tu­al­nych zmian w celu jej ulep­sze­nia. Jest to opis tego jak w fir­mie powsta­je war­tość dodana.

Kolejnym eta­pem jest okre­śle­nie, któ­re pro­ce­sy biz­ne­so­we chce­my wes­przeć nowym sys­te­mem i czy jest to ren­tow­ne. Uzyskujemy tą meto­dą defi­ni­cję zakre­su pro­jek­tu i jego ocze­ki­wa­ny gra­nicz­ny budżet. Metoda ta jest zgod­na z archi­tek­tu­ra SOA (Service Oriented Architekcture, ang. Architektura [sys­te­mu IT] Zorientowana na Usługi).

Jednocześnie ana­li­zu­je­my infor­ma­cje prze­twa­rza­ne w orga­ni­za­cji i two­rzy­my ich model (model danych). Stanie się on pod­sta­wą wyma­gań na bazę danych, któ­ra jest fun­da­men­tem każ­de­go sys­te­mu infor­ma­tycz­ne­go. Ten opis jest klu­czo­wym ele­men­tem spe­cy­fi­ka­cji wyma­gań. Błędy i nie­do­pa­trze­nia powsta­łe na tym eta­pie (zły opis prze­twa­rza­nych danych) powo­du­ją bar­dzo kosz­tow­ne mody­fi­ka­cje w trak­cie reali­za­cji i wdro­że­nia systemu.

Model pro­duk­tów takiej ana­li­zy moż­na zilu­stro­wać w nastę­pu­ją­cy sposób:

Projekt dla fikcyjnej firmy.

W odpo­wie­dzi na licz­ne pyta­nia opra­co­wa­łem przy­kład takiej ana­li­zy. Analiza ta pre­zen­to­wa­na jest w for­mie uprosz­czo­nej w celu zade­mon­stro­wa­nia jej tre­ści a nie obję­to­ści. Treść i sto­pień szcze­gó­ło­wo­ści każ­do­ra­zo­wo są usta­la­ne zależ­nie od kon­tek­stu i celu pro­jek­tu. Osoby zain­te­re­so­wa­ne tym doku­men­tem zapra­szam na kurs mode­lo­wa­nia: Projekt