Krótka historia pewnego wymagania

Wprowadzenie

Zarówno w pro­jek­tach jak i w dys­ku­sjach np. na kon­fe­ren­cjach czy na LinkedIn, poja­wia się sta­le pew­ne nie­po­ro­zu­mie­nie: pro­jek­to­wa­nie to water­fall”. Myśli tak każ­dy, kto wyobra­ża sobie, że pro­jekt cze­goś to jakaś masa wszyst­kich moż­li­wych deta­li. Jednocześnie nie ja jeden widu­ję Dokumenty ana­li­zy biz­ne­so­wej” albo Dokumenty wyma­gań” zawie­ra­ją­ce set­ki pozy­cji o tre­ści sys­tem powi­nien…”, nie raz wyko­na­ne przez kry­ty­ków water fall”, któ­rzy repre­zen­tu­jąc deve­lo­pe­ra dekla­ru­ją­ce­go meto­dy agi­le”, zabez­pie­cza­ją się” przez odpo­wie­dzial­no­ścią za zakres projektu. 

Pierwsza waż­na uwa­ga: pro­jekt sys­te­mu to nie jest ani zestaw dzie­siąt­ków user sto­ry” ani deta­licz­na doku­men­ta­cja powy­ko­naw­cza! I o tym dzi­siaj będzie: abs­tra­ho­wa­nie od deta­li i jed­nak nadal zarzą­dza­nie logi­ką całości.

Poniżej wyma­ga­nie napi­sa­ne przez dział IT jed­ne­go z moich klientów:

1. System musi posia­dać wbu­do­wa­ne­go klien­ta pocz­ty elek­tro­nicz­nej obsłu­gu­ją­ce­go co naj­mniej pro­to­ko­ły IMAP i SMTP.
2. Wbudowany klient pocz­ty elek­tro­nicz­nej posia­da nastę­pu­ją­ce funkcje:
2.1. Utwórz wia­do­mość ? umoż­li­wia utwo­rze­nie nowej wiadomości,
2.2. Odpowiedz ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.3. Odpowiedz wszyst­kim ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy oraz z prze­sła­niem jej na pozo­sta­łe adre­sy ema­il wymie­nio­ne w polu Do, Do wia­do­mo­ści oraz Ukryty do wia­do­mo­ści wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.4. Prześlij dalej ? umoż­li­wia prze­sła­nie pocz­ty elek­tro­nicz­nej kolej­ne­mu odbiorcy,
2.5. Przenieś ? umoż­li­wia prze­no­sze­nie pocz­ty elek­tro­nicz­nej pomię­dzy fol­de­ra­mi na wybra­nym koncie,
2.6. Drukuj ? umoż­li­wia wydru­ko­wa­nie pocz­ty elektronicznej,
2.7. Dołącz ? umoż­li­wia dołą­cze­nie pocz­ty elek­tro­nicz­nej do spra­wy lub dokumentu,
2.8. Odbierz ? umoż­li­wia ręcz­ne ode­bra­nie pocz­ty elektronicznej,
2.9. Usuń ? umoż­li­wia usu­nię­cie wybra­nej pocz­ty elektronicznej,
2.10. Znajdź ? umoż­li­wia wyszu­ka­nie listu w fol­de­rach pocz­ty elektronicznej,
2.11. Rejestruj ? umoż­li­wia reje­stra­cję pocz­ty elek­tro­nicz­nej jako doku­men­tu w sys­te­mie w spo­sób ana­lo­gicz­ny do reje­stra­cji doku­men­tu zeskanowanego.
3. System musi udo­stęp­niać moż­li­wość kon­fi­gu­ra­cji kon­ta pocz­ty elek­tro­nicz­nej każ­de­mu użytkownikowi.
4. System zapew­nia moż­li­wość kon­fi­gu­ra­cji wie­lu kont pocz­ty elek­tro­nicz­nej dla każ­de­go użytkownika.
5. System musi umoż­li­wiać reje­stra­cję (przej­mo­wa­nie) pocz­ty elek­tro­nicz­nej przez użyt­kow­ni­ka, lub poprzez zde­fi­nio­wa­ną regu­łę (uwzględ­nia­ją­cą zapi­sa­ne­go wcze­śniej adre­sa­ta, oraz cią­głość kore­spon­den­cji w spra­wie), jako doku­men­tów w sys­te­mie z podzia­łem na treść, załącz­ni­ki i nagłówek.
6. W celu ogra­ni­cze­nia zbęd­nej dupli­ka­cji, nie­prze­ję­te maile muszą być odczy­ty­wa­ne z ser­we­ra pocz­to­we­go tyl­ko na żąda­nie użyt­kow­ni­ka (dostęp­ny listing nagłów­ków wia­do­mo­ści) i nie powin­ny być dodat­ko­wo prze­cho­wy­wa­ne w Systemie.
7. Dotyczy to rów­nież pocz­ty wysy­ła­nej przez klienta.
8. System musi umoż­li­wiać dołą­cza­nie pocz­ty elek­tro­nicz­nej do doku­men­tów lub spraw. Dołączenie musi być moż­li­we z pozio­mu klien­ta pocz­ty elek­tro­nicz­nej wbu­do­wa­ne­go w system.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę A

Inna oso­ba z tego same­go dzia­łu dodała:

1. Chcemy mieć klien­ta pocz­to­we­go w sys­te­mie, jest to wygod­ne rozwiązanie.
2. Chcemy aby klient pocz­to­wy miał moż­li­wość odczy­ta­nia i wysła­nia wia­do­mo­ści pocztowej.
3. Nie chce­my żeby EOD gro­ma­dzi­ło wszyst­kie wia­do­mo­ści syn­chro­ni­zo­wa­ne z ser­we­rem pocz­to­wym pro­to­ko­łem IMAP, a tyl­ko pobie­ra­ło nagłów­ki wiadomości.
4. Gdy użyt­kow­nik uzna, że wia­do­mość jest czę­ścią spra­wy ini­cju­je czyn­no­ści w EOD.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę B.

Świadomie poda­je źró­dło: dział IT tej instytucji.

Opublikowałem tyl­ko powyż­sze, bo resz­ta po ano­ni­mi­za­cji i tak była by pustą kart­ką (nie­ste­ty ten OPZ uka­że się dopie­ro za jakiś czas, a do tego momen­tu jest pouf­ny), ale mam nadzie­ję, że wyobra­że­nie sobie resz­ty jest dość pro­ste. I co z tym? Nic! Otóż nie jest pro­ble­mem taka for­ma wyra­że­nia wyma­gań przez Zamawiającego, bo on (biz­nes i nie tyl­ko jak widać) ina­czej nie potra­fi i nie jest to jego rola. Problemem jest uzna­nie tego za wyma­ga­nia wobec opro­gra­mo­wa­nia”. Powyższe jest raczej dopie­ro mate­ria­łem do ana­li­zy i projektowania. 

Wyobraźmy sobie teraz hipo­te­tycz­ny doku­ment wyni­ko­wy, czy­li kil­ku­na­stu (a może nawet kil­ku­dzie­się­ciu) nie­tech­nicz­nych pra­cow­ni­ków tej insty­tu­cji (księ­go­wość, admi­ni­stra­cja, itp.) z pomo­cą ana­li­ty­ka wyma­gań”, zebra­ło wyma­ga­nia, i pra­cu­jąc z edy­to­rem tek­stu w try­bie reje­stra­cji zmian, warsz­ta­to­wo, po iluś tam tygo­dniach wypra­co­wa­ło” osta­tecz­ną wer­sję wyma­gań” a potem nawet dzie­siąt­ki user sto­ry”. Ile stron będzie mia­ła taka Analiza Biznesowa Wymagań i co w niej będzie? 

Przykłady łatwo zna­leźć w Internecie:

przy­kład 1 (źr. https://​zamo​wie​nia​.mazo​via​.pl/​?​a​c​t​=​i​n​f​o​&​i​d​=​1​2​001):

Powyższe opra­co­wa­nie kosz­to­wa­ło 90 tys. zł. 

przy­kład 2 (źr. https://​plat​for​ma​za​ku​po​wa​.pl/​t​r​a​n​s​a​k​c​j​a​/​3​6​1​167):

Rozwiązanie

Od cza­su do cza­su przy­wo­łu­je tu na blo­gu podej­ście zwa­ne Model jako wyma­ga­nie” (popu­lar­ne skró­ty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisa­łem ).

Kluczem są mode­le struk­tur tre­ści (doku­men­tów i ekra­nów GUI) . Powyższe życze­nia” jako spi­sa­ne wyma­ga­nia to (w peł­nej wer­sji) ogrom­na lista życzeń, nie pod­da­ją­ca się żad­nej kon­tro­li spój­no­ści i kom­plet­no­ści. Proszę podej­rzeć wska­za­ne wyżej przy­kła­dy, doku­men­ty na ponad 200 stron nie pod­da­ją­ce się żad­nej kon­tro­li… (pomi­jam, że wadli­we for­mal­nie, jeśli cho­dzi o uży­cie deka­ro­wa­nej notacji). 

Poniżej zamien­nik wyłącz­nie powyż­sze­go o poczcie elek­tro­nicz­nej, wyra­żo­ny mode­lem struk­tu­ry tre­ści. Jaką ma to zale­tę? Tę, że mamy zamknię­tą struk­tu­rę tre­ści i może­my ją mapo­wać na inne doku­men­ty (ich sza­blo­ny w pro­jek­cie) w celi wery­fi­ka­cji logi­ki spójności. 

Zakresy danych nie reali­zu­ją­ce logi­ki biz­ne­so­wej (i mało ryzy­kow­ne jeśli cho­dzi o pra­co­chłon­ność) moż­na mar­ko­wać z dokład­no­ścią do roli dane­go zesta­wu danych (poni­żej obsza­ry ozna­czo­ne linia prze­ry­wa­ną). Zgodnie z defi­ni­cją, sys­te­my infor­ma­cyj­ne prze­twa­rza­ją dane, więc dowol­ny sys­tem infor­ma­cyj­ny jest spro­wa­dzal­ny do skoń­czo­nej licz­by infor­ma­cji wyra­ża­nej jako doku­ment gru­pu­ją­cy okre­ślo­ne dane i reguł ich prze­twa­rza­nia . Rzecz w tym, że nie jest to baza danych i rela­cyj­ny model” (nie­ste­ty mono­lit moż­li­wy do wypra­co­wa­nia meto­dą water­fall), a odręb­ne doku­men­ty i ich struk­tu­ry (oraz słow­ni­ki zna­czeń uży­tych nazw). Każdy z nich może być pod­sta­wą opra­co­wa­nia odręb­ne­go, moż­li­we­go do samo­dziel­ne­go wyko­na­nia, modułu. 

Warto wie­dzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzy­sta­ją­cych z moich opra­co­wań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej pro­sty model listy ode­bra­nych maili”:

Wymagania doty­czą­ce pra­cy z pocz­ta elek­tro­nicz­ną obra­zu­je ten oto – wery­fi­ko­wal­ny – model struk­tu­ry tre­ści otrzy­ma­nej mailem:

Aby poka­zać jak to dzia­ła” pisze­my sce­na­riusz (spe­cy­fi­ka­cja przy­pad­ku uży­cia) sta­no­wią­cy kon­tekst uży­cia tego doku­men­tu (for­mu­la­rza). Służy on tak­że jako test pro­jek­to­wa­nej logi­ki, a póź­niej jako test odbior­czy goto­we­go produktu: 

1. Pracownik wybie­ra opcję Poczta Elektroniczna
2. SYSTEM wyświe­tla Lista prze­sy­łek ema­il dla zalo­go­wa­ne­go użytkownika
3. Pracownik kli­ka wybra­na pozy­cje na liście ,
4. SYSTEM wyświe­tla Treść Poczty Elektronicznej
5. Pracownik dekre­tu­je ją lub ozna­cza do usu­nię­cia OK
6. if dekretacja
6.1. wska­za­nie punk­tu kan­ce­la­ryj­ne­go i OK
7. else if usuń
end if 
8. SYSTEM sys­tem potwier­dza operacje

W tym momen­cie będę koń­czył, bo kon­ty­nu­ację czy­tel­nik znaj­dzie w jed­nym z wcze­śniej­szych arty­ku­łów, frag­ment poniżej: 

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystar­cza­ją­ca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wie­lo­krot­nie. (źr. Modele infor­ma­cyj­ne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła

Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.

Warsztaty analityczne – czyli malowanie trawy

W koń­czą­cym się roku trzy razy mia­łem do czy­nie­nia z nie mały­mi (czy­taj kosz­tow­ny­mi) doku­men­ta­mi zawie­ra­ją­cy­mi mode­le pro­ce­sów biz­ne­so­wych” i spe­cy­fi­ka­cję wyma­gań”. Wszystkie trzy mia­ły pew­ne wspól­ne cechy:

  1. były pro­ble­my z przy­dat­no­ścią tych doku­men­tów, co było powo­dem popro­sze­nia mnie o oce­nę i reko­men­da­cje w kwe­stii ich naprawy,
  2. wszyst­kie były pro­duk­tem zbio­ro­wych warsz­ta­tów pro­ce­so­wych” i warsz­ta­tów wyma­gań” z pra­cow­ni­ka­mi mode­lo­wa­nej firmy,
  3. żaden nie nada­wał się do uży­cia jako mate­riał do stwo­rze­nia opro­gra­mo­wa­nia, mimo, że wszyst­kie one były pro­duk­tem pierw­sze­go eta­pu pro­jek­tu o nazwie ana­li­za przed-wdrożeniowa”,
  4. wszyst­kie cier­pia­ły na pro­blem nad­mia­ru szcze­gó­łów, nie­jed­no­znacz­no­ści i bra­ku spójności.

Jedenaście lat temu (tak jede­na­ście!) napisałem:

Często fir­my ofe­ru­ją usłu­gę i pro­dukt Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd. (Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Dlaczego tak jest? Dlaczego tak bar­dzo popu­lar­ne są tego typu warsz­ta­ty a nie rze­tel­ne, dają­ce wyso­kiej jako­ści pro­duk­ty, analizy?

Obserwacja gry vs. reguły gry

To co się dzie­je na sto­le bilar­do­wym (meta­fo­ra z książ­ki M.Fowlera) moż­na opi­sać z pomo­cą praw fizy­ki i reguł gry w bilar­da. To co obser­wu­je­my na sza­chow­ni­cy (meta­fo­ra z blo­ga Paula Harmona) to wynik reguł gry, doświad­cze­nia i kla­sycz­nych zagry­wek. W obu przy­pad­kach docho­dzą też do gło­su wie­dza i umie­jęt­no­ści gra­czy. Piłka noż­na to regu­ły gry, pra­wa fizy­ki (tor pił­ki po kop­nię­ciu pił­ki) i umie­jęt­no­ści zawod­ni­ków. Można tu podać wie­le innych przy­kła­dów efek­tów łącz­ne­go ist­nie­nia okre­ślo­nych reguł oraz umie­jęt­no­ści ludzi.

Każda orga­ni­za­cja (fir­ma, urząd, inne) to ludzie z ich wie­dzą i umie­jęt­no­ścia­mi oraz regu­ły gry” czy­li obo­wią­zu­ją­ce Prawo i wewnętrz­ne regu­la­cje. I teraz poja­wia się pyta­nie: czym jest model orga­ni­za­cji? Przede wszyst­kim model to uprosz­cze­nie rze­czy­wi­sto­ści, jed­nak sto­pień tego uprosz­cze­nia nie jest przy­pad­ko­wy. To co uprasz­cza­my (pomi­ja­ne szcze­gó­ły) zale­ży od kon­tek­stu w jakim ten model będzie uży­ty, bo two­rze­nie mode­lu na jeden cel: uży­cie go w kon­kret­nym celu. Tu nie­ste­ty” wkra­cza nauka, mam na myśli podej­ście (meto­da nauko­wa w ana­li­zie).

Spójrzmy na to od koń­ca. Aby powsta­ło jakie­kol­wiek narzę­dzie wspo­ma­ga­ją­ce pra­cę np. ludzi wyko­nu­ją­cych swo­je obo­wiąz­ki w orga­ni­za­cji, narzę­dziem taki jest tak­że opro­gra­mo­wa­nie (czy­li apli­ka­cje), musi powstać opis tego narzę­dzia. Aplikacje to takie narzę­dzia, two­rzy­my je głów­nie z dwóch powo­dów: two­rzy­my elek­tro­nicz­ne wer­sje kar­to­tek (reje­strów) oraz two­rzy­my elek­tro­nicz­ne wer­sje okre­ślo­nych umie­jęt­no­ści (np. wyli­cza­nie pier­wiast­ków w kal­ku­la­to­rze). Tak więc aby zamó­wić u deve­lo­pe­ra Kartotekę musi ją opi­sać i to jest rela­tyw­nie pro­ste: two­rzy­my wzór Kartoteki, np. kar­to­te­ki pra­cow­ni­ka, książ­ki w biblio­te­ce itp. Nieco trud­niej jest opi­sać (udo­ku­men­to­wać) umie­jęt­ność, zresz­tą naj­pierw trze­ba ja jakoś zde­fi­nio­wać. Umiejętności, tu wyma­ga­ne, mogą być róż­ne: od umie­jęt­no­ści wery­fi­ka­cji danych wpro­wa­dza­nych do kar­to­tek aż do umie­jęt­no­ści wytwa­rza­nia nowych infor­ma­cji na bazie tych dostęp­nych w kar­to­te­kach. Np. utwo­rze­nie fak­tu­ry sprze­da­ży wyma­ga sko­rzy­sta­nia z kar­to­te­ki klien­tów, z kar­to­te­ki ofe­ro­wa­nych towa­rów i usług, kar­to­te­ki towa­rów dostęp­nych w maga­zy­nie, trze­ba tak­że posia­dać umie­jęt­ność popraw­ne­go wyli­cze­nia war­to­ści podat­ków na for­mu­la­rzu fak­tu­ry, mogą do tego dojść upu­sty zależ­ne od wie­lu czyn­ni­ków: war­to­ści zaku­pu, aktu­al­nych pro­mo­cji, sta­tus kupu­ją­ce­go i wie­le innych. Inny przy­kład: zare­je­stro­wa­nie nowe­go doku­men­tu w archi­wum wyma­ga sko­rzy­sta­nia z kar­to­te­ki doku­men­tów oraz umie­jęt­no­ści nada­nia doku­men­to­wi spe­cjal­ne­go zna­ku, sygnatury.

workshopI tu wpa­da­my w efekt krę­ce­nia fil­mu”. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­je pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elektronicznym!).

Dokumenty, któ­re dosta­ję do recen­zji, to czę­sto wła­śnie zapi­sy, wręcz ste­no­gra­my z takich spo­tkań, i nie ma zna­cze­nia czy to zapi­sy pro­zą” czy zapi­sy w posta­ci obraz­ko­wej z uży­ciem nota­cji BPMN czy UML (gdzie nota­cja jest wyko­rzy­sty­wa­na raczej jako biblio­te­ka sym­bo­li a nie narzę­dzie z jego syn­tak­ty­ką i seman­ty­ką). To doku­men­ty, któ­re sta­no­wią rodzaj ste­no­gra­mu z roz­mów, są jak fil­my nakrę­co­ne pod­czas roz­gry­wa­nia par­tii sza­chów lub bilar­da: miłe w oglą­da­niu, dłu­gie, kosz­tow­ne i kom­plet­nie nie­przy­dat­ne do napi­sa­nia kom­pu­te­ro­wej gry.

Do opi­sa­nia każ­dej z tych gier, a tak­że do opi­sa­nia tego jak funk­cjo­nu­je orga­ni­za­cja, wystar­czy doku­ment opi­su­ją­cy zasa­dy gry (regu­ły biz­ne­so­we) oraz mini­mal­ną wie­dzę i umie­jęt­no­ści gra­czy oraz to jakie i w jakiej kolej­no­ści rze­czy maja powstać czy­li model pro­ce­sów biz­ne­so­wych. Model pro­ce­sów jed­nak to nie jest film” opi­su­ją­cy czy­jąś pra­cę a logicz­ny łań­cuch aktyw­no­ści two­rzą­cych, każ­da, przy­dat­ny biz­ne­so­wi produkt.

Jaki opis powsta­nie po prze­pro­wa­dze­niu kil­ku dni warsz­ta­tów z gra­cza­mi, któ­rzy gra­ją od lat, zasa­dy gry zna­ją na pamięć, bywa ze podej­mu­ją pró­by łama­nia zasad dla osią­gnię­cia doraź­nych efek­tów? To będą dłu­gie, nie raz nie­spój­ne wywo­dy. Każdą z wymie­nio­nych gier opi­su­ją jed­nak jed­no­znacz­nie dwa bar­dzo krót­kie doku­men­ty: regu­ły gry oraz mini­mal­ne umie­jęt­no­ści i wie­dza każ­de­go z gra­czy. Z takim doku­men­tem każ­dy pro­jek­tant opro­gra­mo­wa­nia sobie pora­dzi bez problemu.

Niestety wie­le pro­duk­tów eta­pu pro­jek­tu o nazwie ana­li­za przed-wdro­że­nio­wa to tak zwa­ne malo­wa­nie tra­wy: kawał kosz­tow­nej i niko­mu nie przy­dat­nej pra­cy. Jakiś temu pisa­łem z innej okazji:

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczywiste). […]

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że ?sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny?. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko per­spek­ty­wy). (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w pro­jek­tach IT).

Dlatego rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych partii.

klientsobiezyczyBardzo czę­sto sły­szę od deve­lo­pe­rów, ze więk­szość doku­men­tów jakie dosta­ją jest nie­przy­dat­na. Nie raz zasta­na­wiam się, dla­cze­go mimo to więk­szość usłu­go­daw­ców two­rzy tak nie­przy­dat­ne doku­men­ty? Najprawdopodobniej dla­te­go, że słu­cha­nie i ste­no­gra­fo­wa­nie jest łatwe… Z dru­giej stro­ny, nie raz nie­ste­ty sami zama­wia­ją­cy chcą takich wła­śnie doku­men­tów, Ci jed­nak są uspra­wie­dli­wie­ni, bo to nie oni są ana­li­ty­ka­mi. Ci ostat­ni sami decy­du­ją jaki­mi ana­li­ty­ka­mi są…

Drugim powo­dem jest dość powszech­ny brak umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Problem ten widać czę­sto na eta­pie mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: zamu­la­nie zbęd­ny­mi szcze­gó­ła­mi. Bardzo wie­lu ana­li­ty­ków ma skłon­no­ści do wgłę­bia­nia się w nie­istot­ne szcze­gó­ły, to wła­śnie objaw bra­ku umie­jęt­no­ści two­rze­nia abs­trak­cji. Do tego stop­nia, że powstał pomysł na sfor­ma­li­zo­wa­nie zaj­mo­wa­nie się tymi szcze­gó­ła­mi (Case Management). Ciekawa dys­ku­sja na ten temat poja­wi­ła się na LinkedIn. Ja ze swej stro­ny pole­cam arty­kuł (Case Managemet) oraz wypo­wie­dzi Paula Harmona w dyskusji:

At the pro­cess level, we want the abi­li­ty to descri­be and orga­ni­ze a gene­ric set of acti­vi­ties. We might be con­cer­ned, for exam­ple, with how we orga­ni­ze Hotel Guest Services. To be cle­ar what we mean by orga­ni­zing Hotel Guest Services, we might talk abo­ut a spe­ci­fic instan­ce in which a hotel orga­ni­zed guest servi­ces. One of the things we might deci­de, for exam­ple, was that the hotel wan­ted eve­ry­one to use the guest’s name. Thus, we might think of all of the acti­vi­ties in which employ­ees might inte­ract, and pon­der how we would pro­vi­de each set of employ­ees with each guest’s name. It obvio­usly would­n’t be a mat­ter of sim­ply noti­fy­ing one gro­up – like tho­se who take restau­rant rese­rva­tions of who is in what room – sin­ce, as Roger sug­ge­sts, a hotel guest could pro­ce­ed in any order, going to the pool, or to a con­fe­ren­ce ses­sion, or pro­ce­eding to make a restau­rant rese­rva­tion. In this case we are pro­ba­bly tal­king abo­ut put­ting infor­ma­tion into a data­ba­se from which vario­us employ­ees could easi­ly retrie­ve it. Processes are dyna­mic and com­plex, in part, becau­se the gene­ric pro­cess descrip­tion isn’t as pre­scrip­ti­ve as it would be in a pro­duc­tion line, whe­re the sta­tions are set and the beha­viors expec­ted at each sta­tion are well defi­ned. They are cases” becau­se each instan­ce of the pro­cess uses a dif­fe­rent set of acti­vi­ties in a dif­fe­rent order – as in the Rescue Hostage exam­ple. When we plan for a Rescue Hostage case or pro­ject if you pre­fer, we deve­lop a series of sce­na­rios, and prac­ti­ce a lar­ge set of acti­vi­ties. When the time comes to exe­cu­te the pro­cess, we begin by plan­ning for the spe­ci­fic instan­ce case. The idea that we start the pro­cess with a gene­ric: Plan for the Specific Rescue Effort, acti­vi­ty may be gene­ric, but any deta­iled exam­ple of it will be an instan­ce, sin­ce in the very natu­re of the plan­ning we are tailo­ring to the spe­ci­fic instan­ce. (Case Management Approaches | LinkedIn).

Gdzie są te cholerne szczegóły

Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola wali­da­cje”. Problem w tym, że:

  • mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
  • z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
  • typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

  1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
  2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
  3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym wali­da­cje”) jest wydzie­le­nie w dokumentacji:

  1. słow­ni­ka pojęć
  2. słow­ni­ka reguł biznesowych 
    1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

  1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
  2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
  3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
  4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Logika biznesowa

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.

Korzyści z Architektury Korporacyjnej

Temat tego czy i na ile nie­tech­nicz­ne kadry zarząd­cze, czy­li tak zwa­ny biz­nes, rozu­mie­ją nowe tech­no­lo­gie prze­wi­ja się regu­lar­nie przez zarów­no pra­sę jak i blo­gi. Po pierw­sze jest w tym wie­le praw­dy a po dru­gie niby dla­cze­go mia­ło by być ina­czej? Jeżeli jakaś treść jest napi­sa­na tak zwa­nym tech­nicz­nym języ­kiem, to odbior­ca, kim jest, sam się ujaw­ni, podob­nie jak w przy­pad­ku gdy np. w samo­lo­cie nie­miec­kich linii lot­ni­czych ste­war­de­sa zawo­ła do kogoś po pol­sku pod­nio­są się wyłącz­nie Polacy.

Z archi­tek­tu­rą kor­po­ra­cyj­ną jest podob­nie co potwier­dza niżej mój kole­ga dr. hab. Andrzej Sobczak:

Po pierw­sze TOGAF jest napi­sa­ny w bar­dzo nie­przy­stęp­ny spo­sób ? nawet dla osób dobrze zna­ją­cych angiel­ski (wystę­pu­je bar­dzo dużo pojęć, któ­re nie są intu­icyj­ne). Co wię­cej ?czuć?, że TOGAF został napi­sa­ny przez infor­ma­ty­ków dla infor­ma­ty­ków (nale­ży pamię­tać, że TOGAF wywo­dzi się z TAFIM ? tj. Technical Architecture Framework for Information Management, a do wer­sji 7.0 włącz­nie w TOGAF?ie mówio­no wyłącz­nie o archi­tek­tu­rze IT, dopie­ro od wer­sji 8.0 wpro­wa­dzo­no kon­cep­cję archi­tek­tu­ry kor­po­ra­cyj­nej). Po dru­gie jest nie­zwy­kle obszer­ny (spe­cy­fi­ka­cja stan­dar­du liczy oko­ło 700 stron) i nie zawsze jest podzie­lo­na w logicz­ny spo­sób. Po trze­cie wresz­cie spe­cy­fi­ka­cja TOGAF jest miej­sca­mi nie­spój­na (co do kon­cep­cji i ter­mi­no­lo­gii) i w nie­któ­rych obsza­rach moc­no prze­sta­rza­ła (wyni­ka to z histo­rii roz­wo­ju TOGAF?a jako stan­dar­du ? pierw­sza jego wer­sja poja­wi­ła się już w 1996 roku ? bez mała 20 lat temu).

To są minu­sy tego stan­dar­du. Jednak z roku na rok zysku­je on coraz więk­szą popu­lar­ność. Jeszcze 10 lat temu miał on 7% ?ryn­ku ram arch­tek­to­nicz­nych? na świe­cie?, obec­nie jego udział zwięk­szył się do bli­sko 60%. Nie moż­na go więc igno­ro­wać. Niezbędne jest odpo­wied­nie ?sprze­da­nie? tego podej­ścia biz­ne­so­wej czę­ści orga­ni­za­cji. (Jak roz­ma­wiać z biz­ne­sem nt. TOGAF?a? | Architektura Korporacyjna).

Powyżej zwró­co­no uwa­gę na trzy pro­ble­my stan­dar­du TOGAF, któ­ry jak zauwa­ża autor, ma obec­nie 60% udział w ryn­ku (stan­dar­dów tych jest wię­cej, prze­czy­taj mój arty­kuł i książ­kę How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework).

Niezrozumiałość to chy­ba fak­tycz­nie efekt tego, że auto­ra­mi są infor­ma­ty­cy. Jest to aku­rat uza­sad­nio­ne bo rodo­wód TOGAF to kon­ku­ren­cja” dla ITIL.

Obszerność. Hm, tu aku­rat nie uwa­żam by był to zarzut, spe­cy­fi­ka­cja nota­cji BPMN ma podob­ną obję­tość, a UML prze­kro­czył 1000 stron. Ramy archi­tek­to­nicz­ne to tak­że prze­strzeń poję­cio­wa, potęż­ny zestaw ter­mi­nów mają­cych defi­ni­cje i cel ist­nie­nia czy­li opi­sa­nie cze­goś w spój­ny spo­sób. Tu płyn­nie prze­cho­dzi­my do trze­ciej wady: nie­spój­ność. To nie­ste­ty w moich oczach prak­tycz­nie dys­kwa­li­fi­ku­je każ­dy sys­tem jeże­li jest niespójny.

Niespójność ozna­cza powsta­nie poten­cjal­nej nie­jed­no­znacz­no­ści w każ­dym doku­men­cie (mode­lu), w któ­rym zosta­nie uży­ta nie­spój­na prze­strzeń poję­cio­wa (przy­po­mnę, że popraw­na prze­strzeń poję­cio­wa to zestaw pojęć, któ­re cechu­ją: kom­plet­ność, nie­sprzecz­ność, wza­jem­na wyklu­czal­ność). A TOGAF i jego słow­nik ter­mi­nów to nic inne­go jak pew­na prze­strzeń pojęć.

Czy koniecznie musi to być TOGAF?

Ile razy szu­kam w sie­ci i książ­kach defi­ni­cji poję­cia archi­tek­tu­ra kor­po­ra­cyj­na” tyle razy prze­ko­nu­ję się, że jej nie ma bo w zasa­dzie każ­da zna­le­zio­na jest nie­co inna”. Można jed­nak, stu­diu­jąc lite­ra­tu­rę na ten temat, dojść do prze­ko­na­nia, że cho­dzi po pro­tu o tak zwa­ne cało­ścio­we (jak ktoś woli to holi­stycz­ne) sys­te­mo­we podej­ście do patrze­nia na orga­ni­za­cję (ana­li­za sys­te­mo­wa).

Popatrzmy na defi­ni­cje angiel­skie (w tym języ­ku powsta­ły pierw­sze spe­cy­fi­ka­cje AE, źr. Oxford Dictionaries):

ente­pri­se – a busi­ness or com­pa­ny: entre­pre­neu­rial eco­no­mic activity

archi­tec­tu­re – the art or prac­ti­ce of desi­gning and con­struc­ting buil­dings, the com­plex or care­ful­ly desi­gned struc­tu­re of something

Tak więc wypa­da przy­jąć, że archi­tek­tu­ra kor­po­ra­cyj­na to

(cało­ścio­wa) struk­tu­ra orga­ni­za­cji pro­wa­dzą­cej dzia­łal­ność o cha­rak­te­rze komer­cyj­nym”.

[[Jaap Schekkerman]] w swo­jej książ­ce [[How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Creating or cho­osing an Enteprice Architecture Framework]] tak defi­niu­je AK:

Enterprise Architecture in a com­ple­te expres­sion of the enter­pri­se (archi­tek­tu­ra kor­po­ra­cyj­na to kom­plet­ny opis organizacji)

Pozostaje odpo­wie­dzieć na pyta­nie, co zawie­ra ten kom­plet­ny opis? Schekkerman, jak i wie­lu innych, mówi wszyst­ko”:

Jaap Schekkerman Enterprise Architecture
źr. Jaap Schekkerman, How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework

Mamy więc stra­te­gię i tech­no­lo­gie oraz odpo­wia­da­ją­ce jej zdol­no­ści ope­ra­cyj­ne (zarząd­cze) i tech­no­lo­gicz­ne. Taki opis jest kom­pa­ty­bil­ny” z opi­sem pro­ce­su biz­ne­so­we­go w kon­wen­cji IGOE (Input, Guide, Output, Enablers, model w pro­jek­tach z obsza­ru [[Business Process Manamegent]]) któ­ry, poza swo­im wej­ściem i wyj­ściem, jest defi­nio­wa­ny przez regu­ły (guide) oraz zaso­by umoż­li­wia­ją­ce jego funk­cjo­no­wa­nie – enablers).

Tak więc mamy odpo­wiedź na pyta­nie Co to zna­czy wszyst­ko”. Znaczy to: kon­cep­cja biz­ne­so­wa (stra­te­gia) i spo­sób zarzą­dza­nia oraz wyma­ga­ne tech­no­lo­gie czy­li stra­te­gia ich wyko­rzy­sta­nia i zdol­ność uży­cia (ich absorp­cji). Szczególnie to osta­nie ma głę­bo­ki sens, gdyż sam fakt zaku­pu jakiej­kol­wiek tech­no­lo­gii nie jest rów­no­znacz­ny z jej ope­ra­cyj­nym wdro­że­niem (o czym prze­ko­nał się nie­je­den bene­fi­cjent sys­te­mu np. ERP, CRM czy BI).

Teraz prze­wrot­nie uży­ję frag­men­tu pod­ty­tu­łu ww. książki:

Creating an Enterprise Architecture Framework

Tworzenie ramy archi­tek­tu­ry kor­po­ra­cyj­nej. Jak? W sumie, o czym wspo­mi­na­łem w nie­jed­nym poprzed­nim arty­ku­le, mamy dar­mo­wy kom­plet narzę­dzi, czy­li sys­te­my poję­cio­we dla każ­de­go z powyż­szych czte­rech obsza­rów: stra­te­gię może­my opi­sać z uży­ciem nota­cji BMM, reguł biz­ne­so­wych oraz pro­ce­sów end-2-end i nota­cji BPMN. Technologię i spo­sób jej wyko­rzy­sta­nia z pomo­cą nota­cji UML. Odpowiednie mapo­wa­nia (powy­żej: pozio­me i pio­no­we) robi­my albo w macie­rzy, albo z pomo­cą Siatki Zachmana. Wybór zale­ży od przy­ję­tej meto­dy i narzę­dzia CASE jakim zamie­rza­my ten pro­jekt doku­men­to­wać (bez narzę­dzia odradzam).

Organizacja OMG dobrze zadba­ła o spój­ność tych nota­cji (Semantic Core), cze­go nie­ste­ty nie moż­na powie­dzieć o TOGAF i The Open Group (nota­cja ArchiMate nie­ste­ty, nie tyl­ko moim zda­niem, pozo­sta­wia nie­co do życze­nia, pomi­jam już jej licencjonowanie).

Teraz pole­cam zapo­zna­nie się arty­ku­łem Produkty w pro­ce­sie ana­li­zy wyma­gań. Proszę zwró­cić uwa­gę, że powyż­sze czte­ry obsza­ry wie­dzy o orga­ni­za­cji: stra­te­gia biz­ne­so­wa, spo­sób zarzą­dza­nia – model biz­ne­so­wy, stra­te­gia i zdol­ność wyko­rzy­sta­nia nowych tech­no­lo­gii, są obję­te opi­sa­ną ana­li­zą przed-wdro­że­nio­wą i ana­li­zą wyma­gań. Wzajemne mapo­wa­nie obiek­tów z tych czte­rech obsza­rów to nic inne­go jak tak zwa­ne śla­do­wa­nie i wali­da­cja: każ­dy ele­ment musi cze­muś słu­żyć i z cze­goś wyni­kać. Moim zdaniem:

Specyfikacja wyma­gań powin­na być pro­duk­tem (wyni­kać z) Architektury Korporacyjnej, a nie powsta­wać każ­do­ra­zo­wo od zera z pro­wa­dzo­nych setek wywia­dów i warsztatów. 

Tak więc projekt

Architektura Korporacyjna, moim zda­niem, nie ma sen­su sam dla sie­bie”. Tego typu doku­men­ta­cja słu­ży naj­pierw do zro­zu­mie­nia dzia­ła­nia zło­żo­nej orga­ni­za­cji a potem do podej­mo­wa­nia decy­zji o każ­dej reor­ga­ni­za­cji czy inwe­sty­cji w zasoby.

Wystarczy, że każ­da ana­li­za wyma­gań będzie pro­wa­dzo­na w ten sam, powta­rzal­ny spo­sób i jako efekt, będzie dawa­ła kom­pa­ty­bil­ne z poprzed­ni mode­le (i doku­men­ty). Narastająco two­rzo­na doku­men­ta­cja pro­stą dro­gą popro­wa­dzi nas do doku­men­tu o nazwie Nasza Architektura Korporacyjna. Zwróci się (kosz­ty stwo­rze­nia meto­dy­ki) naj­praw­do­po­dob­niej już przy dru­gim projekcie.

architektura korporacyjna rentowność
Koszty ana­liz i projektowania

(linia czer­wo­na obra­zu­je kolej­ne pro­jek­ty ana­li­tycz­ne i ich nara­sta­ją­cy koszt, linia nie­bie­ska to kolej­ne pro­jek­ty ana­li­tycz­ne zastą­pio­ne stwo­rze­niem i utrzy­ma­niem doku­men­ta­cji Architektury Korporacyjnej pod­czas pierw­sze­go pro­jek­tu, źr. Jarosław Żeliński, opra­co­wa­nie własne)

Od cze­go nale­ży zacząć? Od zbu­do­wa­nia wła­snej (lub wła­sne­go warian­tu) meto­dy­ki jej two­rze­nia oraz zatrud­nie­niu Architekta. Czy to powi­nien być wła­sny pra­cow­nik? Moim zda­niem nie, gdyż po pierw­sze nie będzie­my w sta­nie obcią­żyć go pra­cą na 100%. Po dru­gie powi­nien to być ktoś z zewnątrz, by nie był uwi­kła­ny w wewnątrz­or­ga­ni­za­cyj­ne zależ­no­ści – Architekt kor­po­ra­cyj­ny nigdy nie powi­nien być inte­re­sa­riu­szem w pro­jek­cie zwią­za­nym z reor­ga­ni­za­cją a jako pra­cow­nik zawsze nim będzie (podob­nie jak lekarz domo­wy to raczej nikt z domow­ni­ków). Kolega w innym swo­im arty­ku­le pisze:

Architektura kor­po­ra­cyj­na nie powin­na być utoż­sa­mia­na z for­mal­nym opi­sem orga­ni­za­cji (jak to defi­niu­je TOGAF) i nie powin­na być tak ?sprze­da­wa­na? wewnątrz organizacji.

Jeżeli nie tak ? to w jaki inny spo­sób? W tym miej­scu nale­ży koniecz­nie odwo­łać się do ?ojca? kon­cep­cji archi­tek­tu­ry kor­po­ra­cyj­nej ? czy­li J. Zachmana. Uważa on, że archi­tek­tu­ra kor­po­ra­cyj­na poma­ga roz­wią­zy­wać pro­ble­my orga­ni­za­cji w ite­ra­cyj­ny i przy­ro­sto­wy spo­sób. Przedstawiciele fir­my iCMG idą wręcz dalej ? nazy­wa­ją oni archi­tek­tu­rę kor­po­ra­cyj­ną dys­cy­pli­ną nauko­wą zaj­mu­ją­cą się two­rze­niem, dzia­ła­niem i roz­wo­jem orga­ni­za­cji. (Czy już pora wymy­ślić od nowa archi­tek­tu­rę kor­po­ra­cyj­ną? | Architektura Korporacyjna).

i wypa­da mi się z nim zgo­dzić 🙂 poza jed­nym: uwa­żam, że powi­nien być to opis for­mal­ny bo tyl­ko wte­dy będzie jed­no­znacz­ny i nauko­wy”. Tylko wte­dy będzie moż­li­we jego bada­nie” np. prze­pro­wa­dze­nie ana­li­zy skut­ków decy­zji o reor­ga­ni­za­cji zanim ją rozpoczniemy.

Teraz zapew­ne ktoś powie, że piszę tak tyl­ko dla­te­go, że świad­czę takie usłu­gi. Otóż jest dokład­nie odwrot­nie: świad­czę takie usłu­gi bo głę­bo­ko wie­rzę, że tak wła­śnie nale­ży postę­po­wać, bo – jeże­li orga­ni­za­cja ist­nie­je to ona, archi­tek­tu­ra, też jest, nale­ży ją tyl­ko prze­ana­li­zo­wać, zbu­do­wać jej model i korzy­stać z nie­go przy podej­mo­wa­niu każ­dej ryzy­kow­nej decy­zji. Dobry model powi­nien wol­no się zmie­niać, tak jak wol­no się zmie­nia orga­ni­za­cja. Jeżeli model jest zbyt szcze­gó­ło­wy i wyma­ga dużych nakła­dów na jego aktu­ali­za­cje jest złym modelem.

Projekt wykonany – co było robione

Ostatni arty­kuł o pro­ce­sie ana­li­zy i pro­jek­to­wa­nia koń­czył się tak:

Po wyko­na­niu powyż­sze­go, otrzy­ma­my kom­plet­ny model apli­ka­cji w nota­cji UML. Będzie to wła­śnie model PIM. Wszelkie nie­ja­sno­ści powin­ny zostać wyja­śnio­ne. Pozostaje reali­za­cja, model PSM, czy­li opa­ko­wa­nie pro­jek­tu ?tech­ni­ka­lia­mi? (w tym reali­za­cja wyma­gań poza­funk­cjo­na­lych) czy­li tym co dają nam np. fra­me­wor­ki MVC i podob­ne. Oczywiście nie jest to ?try­wial­ny pro­blem?, ale w takim pro­jek­cie deve­lo­per roz­wią­zu­je pro­ble­my jako­ści sys­te­mu a nie logi­ki biz­ne­so­wej sys­te­mu (podob­nie jak inży­nier budow­la­ny, któ­ry ma posta­wić moc­ny i bez­piecz­ny dom, bo jego funk­cjo­nal­ność to pro­blem miesz­kań­ca i zada­nie pro­jek­tan­ta archi­tek­ta). (UML Process czy­li od biz­ne­su do pro­jek­tu logi­ki sys­te­mu).

Często dosta­ję pyta­nia o ogól­ną, poglą­do­wą mapę takie­go pro­jek­tu by łatwo było oce­nić czym jest opi­sy­wa­ne śla­do­wa­nie, jaka jest kolej­ność pra­cy i jakie mode­le powsta­ją. Podjąłem pró­bę poka­za­nia tego:

Kolejność pra­cy (klik­nij by powiększyć):

  1. Określenie celu biz­ne­so­we­go, powsta­je doku­ment wyja­śnia­ją­cy jakie biz­ne­so­we” korzy­ści chce­my (orga­ni­za­cja) osią­gnąć, nie powin­no być celem samym w sobie kupie­nie cze­goś (np. sys­te­mu ERP), korzy­ści te powin­ny być wyra­żo­ne osta­tecz­nie w pie­nią­dzu (potrzeb­ne do ana­li­zy ren­tow­no­ści projektu).
  2. Kolejny etap to opra­co­wa­nie mode­lu moty­wa­cji biz­ne­so­wej, będzie to mate­riał do wypra­co­wa­nia Wymagań Biznesowych. Model ten zawie­ra prze­ło­że­nie celu biz­ne­so­we­go na wyma­ga­ne dzia­ła­nia: tak­ty­kę i stra­te­gię jego osią­gnię­cia: raz jest to reor­ga­ni­za­cja a raz nowy sys­tem ERP. Tu poja­wia­ją się takie ele­men­ty jak ana­li­za SWOT czy oddzia­ły­wa­nia, ana­li­za wyko­ny­wal­no­ści i oce­ny wpły­wu oto­cze­nia na pro­jekt. Powstają Wymagania Biznesowe (źró­dłem są stra­te­gia i tak­ty­ka osią­ga­nia celu biz­ne­so­we­go).
  3. Następnie kolej na opra­co­wa­nie mode­lu pro­ce­sów biz­ne­so­wych dla całej orga­ni­za­cji na pozio­mie opi­su­ją­cym klu­czo­we pro­duk­ty (doku­men­ty i fak­ty). Zaczyna powsta­wać słow­nik pojęć i reguł biznesowych.
  4. Kolejny etap to dekom­po­no­wa­nie pro­ce­sów biz­ne­so­wych odpo­wie­dzial­nych” (powią­za­nych) za reali­za­cje Wymagań Biznesowych, te pro­ce­sy dekom­po­nu­je­my (uszcze­gó­ło­wio­ne mode­le) do pozio­mu czyn­no­ści two­rzą­cych i zmie­nia­ją­cych doku­men­ty i fak­ty. Dodajemy kolej­ne ziden­ty­fi­ko­wa­ne poję­cia i regu­ły. Na tym eta­pie moż­li­wa jest opty­ma­li­za­cja procesów.
  5. Jeżeli opty­ma­li­za­cja reali­zu­je wyma­ga­nia biz­ne­so­we pro­jekt się koń­czy. Jeżeli oka­zu­je się, że wyma­ga­nia biz­ne­so­we wyma­ga­ją np. tech­no­lo­gii IT, pro­jekt ma dal­szy ciąg.
  6. Określenie wyma­gań na opro­gra­mo­wa­nie to wska­za­nie tych czyn­no­ści w pro­ce­sach, któ­rych wspar­cie tą tech­no­lo­gią pomo­że zre­ali­zo­wać wyma­ga­nia biz­ne­so­we. Po ana­li­zie powsta­je na jej pod­sta­wie lista ocze­ki­wa­nych usług opro­gra­mo­wa­nia, są to tak zwa­ne przy­pad­ki uży­cia sys­te­mu. Każdy przy­pa­dek uży­cia ma okre­ślo­ny stan począt­ko­wy, koń­co­wy (ewen­tu­al­nie doku­ment jaki ma powstać), cel biz­ne­so­wy (uza­sad­nie­nie) oraz akto­ra czy­li wska­za­nie użyt­kow­ni­ka (a kon­kret­nie roli jaką peł­ni w orga­ni­za­cji). Powstaje spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (jako­ścio­wych, np. takich jak wydaj­ność czy nie­za­wod­ność). Na tym eta­pie dys­po­nu­je­my spe­cy­fi­ka­cją pozwa­la­ją­cą na szu­ka­nie goto­we­go opro­gra­mo­wa­nia na ryn­ku ofe­ru­ją­ce­go tak opi­sa­ne funk­cjo­nal­no­ści. Elementem spe­cy­fi­ka­cji wyma­gań jest słow­nik pojęć i reguł biz­ne­so­wych. Można dołą­czyć mode­le procesów.
  7. Jeżeli nie znaj­du­je­my pro­duk­tu speł­nia­ją­ce­go wszyst­kie wyma­ga­nia w 100%, decy­du­je­my, któ­re bra­ku­ją­ce wyma­ga­nia funk­cjo­nal­ne jeste­śmy goto­wi wytwo­rzyć spe­cjal­nie dla nas. Wymaga to utwo­rze­nia dla każ­dej takiej funk­cjo­nal­no­ści (przy­pad­ku uży­cia, PU) spe­cy­fi­ka­cji w posta­ci opi­su jej reali­za­cji. Jest to pro­jekt (doku­ment) zawie­ra­ją­cy tak zwa­ny model dzie­dzi­ny sys­te­mu czy­li obiek­ty biz­ne­so­we i logi­kę ich współ­dzia­ła­nia. Dla każ­de­go PU powsta­je dia­gram opi­su­ją­cy jak obiek­ty mode­lu dzie­dzi­ny reali­zu­ją” (współ­dzia­ła­nie) każ­dy przy­pa­dek uży­cia (dia­gra­my sekwencji).

Projekt ma trzy klu­czo­we eta­py: audyt orga­ni­za­cji czy­li jej pozna­nie i opra­co­wa­nie mode­lu dzia­ła­nia. Kolejny to Specyfikowanie wyma­gań na opro­gra­mo­wa­nie. Ostatni etap ana­li­zy i pro­jek­to­wa­nia to opra­co­wa­nie mode­lu logi­ki jaką ma reali­zo­wać zama­wia­ne opro­gra­mo­wa­nie. Cała ta doku­men­ta­cja zawie­ra know-how orga­ni­za­cji war­ty ochrony.

Na dia­gra­mie poka­za­no tak zwa­ne śla­do­wa­nie” czy­li kolej­ne wywo­dze­nie ele­men­tów mode­li z poprze­dza­ją­cych je ogól­niej­szych eta­pów ana­li­zy. Taka doku­men­ta­cja pozwa­la unik­nąć kosz­tow­ne­go odkry­wa­nia potrzeb­nych funk­cjo­nal­no­ści pod­czas dostar­cza­nia kolej­nych wer­sji opro­gra­mo­wa­nia i prze­pro­jek­to­wy­wa­nia go. Specyfikacja logi­ki sys­te­mu pozwa­la dokład­nie spre­cy­zo­wać jakie opro­gra­mo­wa­nie jest zama­wia­ne (co ma ono reali­zo­wać i jak). Całość to opis know-how, któ­ry nadal zosta­je przy zama­wia­ją­cym (jest posia­da­czem praw do tej doku­men­ta­cji bo wyko­nał ja sam lub zle­cił nie­za­leż­ne­mu ana­li­ty­ko­wi a nie dostaw­cy oprogramowania).

Skąd się bio­rą problemy

Przytłaczająca więk­szość pro­jek­tów to roz­po­czę­cie pra­cy od pró­by zebra­nia wyma­gam funk­cjo­nal­nych z pomi­nię­ciem całej ana­li­zy biz­ne­so­wej. Jedynym więc ich źró­dłem są przy­szli użyt­kow­ni­cy, Ci jed­nak po pierw­sze nie mają wie­dzy o kon­tek­ście zaś ich cele są inne niż spon­so­ra pro­jek­tu. Nie mamy żad­ne­go narzę­dzia pozwa­la­ją­ce­go spraw­dzić zasad­ność każ­de­go z tak zebra­nych wyma­gań ani tego czy są spój­ne i kom­plet­ne”. W efek­cie nie­spój­no­ści i bra­ku­ją­ce wyma­ga­nia odkry­wa­ny dopie­ro w trak­cie projektu.

Metody zwa­ne zwin­ny­mi idą jesz­cze dalej: pra­ce dewe­lo­per­skie są roz­po­czy­na­ne są zanim powsta­nie kom­plet­na spe­cy­fi­ka­cja, poja­wia­ją­ce się wyma­ga­nia są natych­miast, z pomi­nię­ciem ich mode­lo­wa­nia i wery­fi­ka­cji pomy­słu, imple­men­to­wa­ne (kod to pierw­szy model i wery­fi­ka­cja). Ryzyko, że nowe, odkry­wa­ne w trak­cie tego pro­ce­su, wyma­ga­nia i meto­dy ich imple­men­ta­cji będą nie­spój­ne czy wręcz sprzecz­ne jest ogrom­ne co poka­zu­je prak­ty­ka: meto­dy zwin­ne dają pro­duk­ty nie raz po bar­dzo wie­lu ite­ra­cjach i naj­czę­ściej są kon­trak­to­wa­ne umo­wa­mi czas i mate­riał”, bo w zasa­dzie ina­czej się tym wypad­ku nie da. Deklarowanie ter­mi­nów i budże­tu wyma­ga­ło by ogrom­nych narzu­tów na nie­wie­dzę w momen­cie roz­po­czy­na­nia pra­cy (co jest tak­że powszech­na praktyką).

Na zakoń­cze­nie

Opisany pro­ces jest zgod­ny z zale­ce­nia­mi OMG​.org (http://​www​.omg​.org/​mda). Audyt to etap CIM (stan­dar­do­wo [[nota­cja BPMN]], sys­tem pojęć i [[nota­cja BMM]], hie­rar­chia struk­tu­ry orga­ni­za­cyj­nej, słow­nik reguł i pojęć) a pro­jek­to­wa­nie przy­pad­ków uży­ci i mode­lu dzie­dzi­ny to etap PIM (Platform Independent Model, [[nota­cja UML]]).

Wykonanie takiej ana­li­zy jest pra­co­chłon­ne i wyma­ga duże­go doświad­cze­nia, umie­jęt­no­ści ana­li­zy pro­ce­sów biz­ne­so­wych, pro­jek­to­wa­nia obiek­to­we­go i dobre­go narzę­dzia CASE, jed­nak mode­le te pozwa­la­ją tak­że prze­pro­wa­dzić ana­li­zy wpły­wu (zależ­no­ści pomię­dzy pro­ce­sa­mi, skut­ki i podat­ność na awa­rie opro­gra­mo­wa­nia itp.) oraz zre­du­ko­wać do mini­mum praw­do­po­do­bień­stwo prze­kro­cze­nia ter­mi­nu i kosz­tów (sta­ty­sty­ki wska­zu­ją na śred­nie prze­kro­cze­nie kosz­tów o 60% i ter­mi­nów o 200% pro­jek­tów z niskiej jako­ści spe­cy­fi­ka­cji wymagań).

Praktyka auto­ra wska­zu­je, że war­to taką ana­li­zę prze­pro­wa­dzić dla pro­jek­tów, któ­rych budżet prze­kra­cza 50 – 70 tys, zł i więk­szych, jej koszt jest zawsze znacz­nie niż­szy niż ryzy­ko­wa­ne 60% budże­tu. Paradoksalnie, w tych więk­szych pro­jek­tach, zbie­ra­nie wyma­gań i zarzą­dza­nie nimi meto­da­mi warsz­ta­tów i ankiet wyma­ga zaan­ga­żo­wa­nia wie­lu pra­cow­ni­ków po stro­nie zarów­no klien­ta jak i dostaw­cy (np. [[sesje JAD]]), z regu­ły jest to więk­szy koszt niż jeden ana­li­tyk z opi­sa­ny­mi kom­pe­ten­cja­mi i narzę­dzia­mi pra­cy, a otrzy­ma­ny pro­dukt – spe­cy­fi­ka­cja wyma­gań – niż­szej jako­ści (pro­ble­my spój­no­ści i kompletności).

(autor uży­wa pakie­tu CASE ana­li­tycz­no-pro­jek­to­we­go Agilian fir­my Visual Paradigm)

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Kolejne szko­le­nia za mną, pro­jek­ty tak­że. Od cza­su do cza­su audyt (lub ciche opi­nie) cudzych pro­jek­tów. Stale widzę dwa poważ­ne pro­ble­my w wie­lu tych dokumentach:

  1. utra­ta pano­wa­nia nad złożonością,
  2. algo­ryt­mi­za­cja.

W 2005 roku napi­sa­łem na zakoń­cze­nie arty­ku­łu dot. modelowania:

Artykuł ten napi­sa­łem głów­nie po to by mogli Państwo tak­że sami oce­nić pra­cę firm, któ­rym pła­ci­cie za tego typu usłu­gi. Na pew­no mode­lo­wa­nie wyma­ga dłu­gich stu­diów i doświad­cze­nia ale efek­ty muszą być zro­zu­mia­łe. Nie jest ono moż­li­we bez udzia­łu wyż­szej kadry fir­my. Bieganie z ankie­ta­mi po fir­mie to doku­men­to­wa­nie sta­nu obec­ne­go a nie mode­lo­wa­nie. Dokumentowanie pro­ce­dur jest przy­dat­ne jako kolej­ny etap przy­go­to­wań do napi­sa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia ale jest nie potrzeb­ne przed wdro­że­niem goto­we­go sys­te­mu, któ­ry tyl­ko pod­le­ga para­me­try­za­cji. Po dru­gie przed wdro­że­niem czy napi­sa­niem sys­te­mu koniecz­ne jest zbu­do­wa­nie mode­lu fir­my choć­by po to by upew­nić się, że jest on opty­mal­ny. W prze­ciw­nym wypad­ku może­my dopro­wa­dzić do utrwa­le­nia w sys­te­mie złych i nie­efek­tyw­nych pro­ce­sów a w skraj­nym przy­pad­ku panu­ją­ce­go w niej bała­ga­nu. ( Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

od tam­tej pory nie­ste­ty w zasa­dzie nic sie nie zmie­ni­ło na rynku.

Pierwszy pro­blem obja­wia się lawi­no­wo rosną­cą licz­bą deta­li na dia­gra­mach i licz­bą dia­gra­mów. Są nawet tacy, któ­rzy uwa­ża­ją, że popraw­ny model pro­ce­sów biz­ne­so­wych całej fir­my, to set­ki dia­gra­mów. Bzdura. Dlaczego?

Czym jest model?

Model [łac. modu­lus ?mia­ra?, ?wzór?], meto­dol. poję­cie ozna­cza­ją­ce zarów­no teo­re­tycz­ny, jak i fizycz­ny obiekt, któ­re­go ana­li­za lub obser­wa­cja umoż­li­wia pozna­wa­nie cech inne­go bada­ne­go (mode­lo­wa­ne­go) zja­wi­ska, pro­ce­su lub obiek­tu. (źr. słow­nik j.p. PWN).

Tak więc cechą dobre­go mode­lu jest moż­li­wość jego testo­wa­nia. Dobry model to uprosz­cze­nie rze­czy­wi­sto­ści odwzo­ro­wu­ją­ce jej ogra­ni­cze­nia w wybra­nym aspek­cie. Jeżeli więc testu­je­my np. współ­czyn­nik opo­ru powie­trza pro­jek­to­wa­ne­go samo­cho­du, wyma­ga­ny (i wystar­cza­ją­cy) model, to repre­zen­ta­cja kształ­tu karo­se­rii a nie kom­plet­na minia­tu­ra z sil­ni­kiem i siedzeniami.

Analizując orga­ni­za­cję, two­rzy­my model w celu… i tu powin­na paść nazwa kon­kret­ne­go aspek­tu, per­spek­ty­wy, któ­rą chce­my badać. Analiza orga­ni­za­cji to ele­ment np.:

  1. pla­nu budo­wy nowe­go sys­te­mu zarzą­dza­nia kosz­ta­mi (np. [[meto­da ABC t.j. zarzą­dza­nia kosz­ta­mi działań]]),
  2. pla­nu wdro­że­nia sys­te­mu Business Inteligence ([[model biz­ne­so­wy jako narzę­dzie pro­jek­to­wa­nia wie­lo­wy­mia­ro­we­go mode­lu hur­tow­ni danych]]),
  3. [[opra­co­wa­nia wyma­gań na opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie]] (ma dwa głów­ne aspek­ty: [[wybór goto­we­go opro­gra­mo­wa­nie]] oraz [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie dedykowane]]).

Podstawową decy­zją jaką nale­ży pod­jąć jest to, cze­go nie ujmo­wać na tych mode­lach, a każ­dy powy­żej ma inny kon­tekst. Każdy pro­jekt, zawie­ra­ją­cy etap mode­lo­wa­nia (mode­lo­wa­nie nie jest celem samym w sobie!) war­to roz­po­czy­nać od audy­tu. Jego celem jest spraw­dze­nie jaką wie­dzę o sobie samej posia­da orga­ni­za­cja czy­li ile z tego, co się dzie­je w orga­ni­za­cji, jest udo­ku­men­to­wa­ne. Nie musi to być wszyst­ko. Dobrze zarzą­dza­na orga­ni­za­cja panu­je nad swo­ją cią­gło­ścią dzia­ła­nia”, to jest rozu­mie jak dzia­ła i nie posia­da punk­tu, któ­ry jako jeden decy­du­je o być albo nie być fir­my. Typowym przy­kła­dem takie­go pun­ku jest jeden czło­wiek, sku­pia­ją­cy na sobie klu­czo­we dla funk­cjo­no­wa­nia fir­my, kom­pe­ten­cje (np. szef pro­duk­cji). Z natu­ry rze­czy ma to miej­sce w każ­dej małej fir­mie, jed­nak im więk­sza fir­ma tym ryzy­ko jej funk­cjo­no­wa­nia powin­no być mniej­sze. Podstawowym ele­men­tem zro­zu­mie­nia mecha­ni­zmu funk­cjo­no­wa­nia orga­ni­za­cji są regu­ły biz­ne­so­we i zdol­no­ści (wie­dza) posia­da­nych zaso­bów. Opisałem to tak­że w arty­ku­le Jak wyłu­skać isto­tę rze­czy.

Złożoność i algo­ryt­mi­za­cja. Typowy anty-przy­kład: pro­ces zawar­cia umo­wy, w któ­rym udział bie­rze mię­dzy inny­mi praw­nik oraz Zarząd. Celem jest (mię­dzy inny­mi) opi­nia praw­na o tre­ści umo­wy, uzgod­nie­nie jej tre­ści, na koń­cu pozy­ska­nie wła­ści­wych pod­pi­sów (np. wyma­ga­ne dwa a mamy pię­ciu człon­ków zarzą­du). W tym miej­scu poja­wia­ją się zawi­łe dia­gra­my opi­su­ją­ce jaki­mi to ścież­ka­mi prze­miesz­cza się doku­ment (nie ma uwag – OK, są uwa­gi, ode­ślij do praw­ni­ka, uzu­peł­nij, prze­ślij zno­wu do Zarządu, …, następ­nie pozy­skaj pod­pis Prezesa, jeże­li pre­zes jest nie­do­stęp­ny, to…). Nawet nie mam ambi­cji nary­so­wa­nia tego potwo­ra, jakim był­by taki dia­gram. Jak to mogło by wyglą­dać? Po pierw­sze potrzeb­na jest spe­cy­fi­ka­cja sta­no­wisk (ról w pro­ce­sach) i kom­pe­ten­cji tych ludzi. Po dru­gie lista reguł (pra­wo, zarzą­dza­nia wewnętrz­ne, pro­ce­du­ry itp.). W efek­cie powyż­szy pro­ces to pro­sty prze­pływ: kon­sul­ta­cja tre­ści umo­wy (praw­nik ma wie­dzę praw­ni­czą, w ramach swo­ich upraw­nień ma pra­wo do spo­tkań z Zarządem np. w celu skon­sul­to­wa­nia tre­ści umo­wy. Po uzgod­nie­niu tre­ści umo­wy, np. Asystent Zarządu, który(a) zna pro­ce­du­ry i pra­wo (kolej­na rola i kom­pe­ten­cje) zdo­by­wa wła­ści­we pod­pi­sy na umo­wie. Koniec! Gdzie szcze­gó­ły? Są! Proces jest, zakre­sy kom­pe­ten­cji są, pra­wo i zarzą­dze­nia są. Tą meto­dą, wte­dy jest to audyt, moż­na spraw­dzić spój­ność zakre­sów obo­wiąz­ków i zarzą­dzeń wewnętrz­nych z pra­wem oraz stra­te­gią firmy.

W wie­lu fir­mach sys­tem zarzą­dza­nia jest tak nie­spój­ny, że jedy­nym spo­so­bem funk­cjo­no­wa­nia tych firm, jest łama­nie zasad przez jej pra­cow­ni­ków. Niestety pierw­sza wpad­ka czę­sto powo­du­je zała­ma­nie się całe­go sys­te­mu (a nie raz i fir­my). Wiele Zarządów firm nie zda­je sobie nawet spra­wy z tego, jak duże jest ryzy­ko cią­gło­ści funk­cjo­no­wa­nia ich firm. 

Tak więc model pro­ce­su to nie algo­rytm dzia­ła­nia fir­my, wyka­za­no nie raz, że algo­ryt­mi­za­cja pra­cy ludzi jest nie­ce­lo­wa (wte­dy sto­su­je­my roboty).

Znaczna część tego co robią ludzie to efekt ich kom­pe­ten­cji, wie­dzy i doświad­cze­nia, a nie dyk­to­wa­nia im jak mają wyko­ny­wać swo­ja pracę.

Jeżeli wybie­rze­my dro­gę mode­lo­wa­nia tego wszyst­kie­go dia­gra­ma­mi, to ilość tych dia­gra­mów szyb­ko prze­kro­czy gra­ni­cę sen­sy całe­go pro­jek­tu: nie będą czy­ta­ne. Ich war­tość będzie żadna.

W pro­ce­sie dobrze przy­go­to­wa­nej ana­li­zy (jakiej­kol­wiek) mode­le two­rzy się by je badać, a nie tyl­ko po to by powsta­ły za pie­nią­dze spon­so­ra projektu.

Na koniec cie­ka­wy arty­kuł, opi­su­ją­cy jak sto­so­wać regu­ły biz­ne­so­we w mode­lo­wa­niu procesów.

In cre­ating a via­ble busi­ness solu­tion, you need both a busi­ness pro­cess model and busi­ness rules ? not just one or the other. The trick is not to get them entan­gled, to rema­in cle­ar abo­ut which is which. The good news is that by sepa­ra­ting them you can sim­pli­fy your busi­ness pro­cess models dra­ma­ti­cal­ly ? often by an order of magni­tu­de or more. This discus­sion expla­ins how. (za Business Processes: Better with Business Rules).

P.S.

Widzę pew­ną kore­la­cję: naj­czę­ściej obec­ni lub daw­ni pro­gra­mi­ści robią naj­gor­sze mode­le orga­ni­za­cji: mają ten­den­cje to tech­no­kra­tycz­nej algo­ryt­mi­za­cji opi­su pra­cy ludzi, igno­ru­ją czyn­nik ludz­ki w mode­lach, patrzą na pro­ce­sy w fir­mach przez pry­zmat ogra­ni­czeń roz­wią­zań i tech­no­lo­gii, któ­re ofe­ru­ją ich pra­co­daw­cy. Podobne ten­den­cje mają tak­że ci, któ­rzy pod­cho­dzą do two­rze­nia mode­li pro­ce­sów jak do spi­sa­nia meto­da­mi obraz­ko­wy­mi tego co mówią pra­cow­ni­cy pod­czas wywia­dów”. To tak­że bar­dzo złe mode­le, zary­zy­ku­ję tezę, że gor­sze od tych z rąk programistów.

Należy też nabrać poko­ry: więk­szość orga­ni­za­cji spraw­nie funk­cjo­nu­je nie mając żad­nych mode­li pro­ce­sów, więc teza, że ich brak szko­dzi jest nie do obro­ny. Po co więc te mode­le? Żeby zro­zu­mieć dla­cze­go tak jest i co się sta­nie, gdy zechce­my wpro­wa­dzać zmiany.