Modele as-is i to-be, czy warto je robić?

Z zamia­rem napi­sa­nia tego tek­stu noszę się już od kil­ku lat i za każ­dym razem mówi­łem sobie: ok, jesz­cze tyl­ko skoń­czę ten jeden pro­jekt i zoba­czy­my czy fak­tycz­nie ma to sens”. I tak od kil­ku lat. W koń­cu jed­nak uda­ło się.

Wprowadzenie

Popularność podej­ścia do mode­li pro­ce­sów biz­ne­so­wych, pole­ga­ją­ce­go na poka­za­niu róż­ni­cy”, trwa od cza­sów popu­la­ry­za­cji re-inży­nie­rii pro­ce­sów biz­ne­so­wych (lata 90-te) . Umowy na usłu­gi, zawie­ra­ją­ce w zakre­sie opra­co­wa­nie mode­lu «as-is» i «to-be» nadal są pod­pi­sy­wa­ne. Zakładam, że decy­zje o zakre­sie pro­jek­tu to indy­wi­du­al­ne potrze­by zama­wia­ją­cych. Ja opi­szę swo­je doświad­cze­nia i wnioski.

Głównym dekla­ro­wa­nym celem two­rze­nia obu tych mode­li jest zawsze porów­na­nie sta­nu obec­ne­go i pla­no­wa­ne­go, a następ­nie zde­cy­do­wa­nie o tym «co dalej». Zakłada się, że te mode­le powin­ny poka­zać war­tość doda­ną pro­jek­to­wa­nych zmian. Pierwszy pro­blem to koniecz­ność stwo­rze­nia dwu­krot­nie więk­szej ilo­ści doku­men­ta­cji, to zaś prze­kła­da sie na czas i koszt. W kon­se­kwen­cji wdro­że­nie pla­no­wa­nej zmia­ny bar­dzo odsu­wa się w cza­sie. Wynik każ­dej pier­wot­nie wyko­na­nej ana­li­zy dez­ak­tu­ali­zu­je się wraz z upły­wem cza­su, tym szyb­ciej im wię­cej szcze­gó­łów ona zawie­ra. Wpadamy tu w «kwa­dra­tu­rę koła». W arty­ku­le Cykl życia… zapy­ta­łem: Czego ocze­ku­je biz­nes: efek­tu czy pro­duk­tu? Wyniki ana­liz i reko­men­da­cje to pro­duk­ty pra­cy ana­li­ty­ka, wdro­żo­ne zmia­ny orga­ni­za­cyj­ne czy opro­gra­mo­wa­nie to tak­że pro­duk­ty. Te zawsze moż­na kupić i mieć. A czym jest efekt? Np. zwięk­sze­niem efek­tyw­no­ści… A to ozna­cza, że etap ana­li­zy i potem wdra­ża­nia roz­wią­za­nia, tak­że powi­nien cecho­wać się efektywnością!

W cza­sach zmian ryn­ko­wych zacho­dzą­cych w okre­sie poni­żej roku, każ­da stra­ta cza­su jest szko­dą, dwu­krot­ne wydłu­że­nie pro­ce­su ana­li­zy i opra­co­wa­nia reko­men­da­cji szczególnie.

Więc jak, sko­ro nie dwa mode­le: «as-is» i «to-be»?

Metody

Tu posłu­żę się pro­sty­mi meto­da­mi czy­li sche­ma­ty blo­ko­we i rzad­ko sto­so­wa­na a bar­dzo sku­tecz­na: ide­ali­za­cja . Nawiążę tak­że do mało popu­lar­nej a cie­ka­wej i bar­dzo sku­tecz­nej meto­dy­ki uspraw­nia­nia orga­ni­za­cji, tak­że opar­tej na ide­ali­za­cji, opi­sa­nej przez Ackof’a .

Rezultaty

Kluczem sku­tecz­ne­go pla­no­wa­nia roz­wo­ju orga­ni­za­cji jest stu­dium wyko­nal­no­ści pla­no­wa­nych zmian, a do tego bar­dzo przy­dat­na jest ide­ali­za­cja jako metoda.

Wytyczenie kierunku działań

Każda orga­ni­za­cja kie­dyś powsta­ła i od tego momen­tu zaczy­na żyć (co – uwa­ga – nie jest toż­sa­me z jej roz­wo­jem). Jeżeli podej­mu­je­my decy­zję o wpro­wa­dza­niu zmia­ny (a na począt­ku raczej tyl­ko dekla­ru­je­my taki zamiar) pierw­szy­mi rze­cza­mi jakie nale­ży okre­ślić są: cel i kie­ru­nek zmian. Jak już to wie­my, kolej­nym kro­kiem jest okre­śle­nie tego co i w jakim cza­sie chce­my osią­gnąć. Pamiętajmy, że ide­ał może nie być osią­gal­ny, jest jed­nak zawsze dosko­na­łym wyznacz­ni­kiem kie­run­ku (podob­nie jak rekor­dy olim­pij­skie dla spor­tow­ców, któ­rzy wie­dzą, że nigdy ich nie prze­kro­czą, ale mimo to wie­dzą co i po co tre­no­wać). Dlaczego? Bo klu­czo­wą wie­dzą jest zawsze to, ile mnie dzie­li od ide­ału i czy jest sens go osią­gać, bo roz­wią­za­nia powin­ny być wystar­cza­ją­cą dobre, a nie zawsze naj­lep­sze (co naj­wy­żej moż­li­wie najlepsze). 

Projektowanie ide­ału jest takim spo­so­bem myśle­nia o zmia­nie, któ­ry moż­na przed­sta­wić w pro­sty spo­sób: w roz­wią­zy­wa­niu pro­ble­mów, prak­tycz­nie dowol­ne­go rodza­ju, moż­na uzy­skać naj­lep­sze wyni­ki dzię­ki wyobra­że­niu sobie ide­al­ne­go roz­wią­za­nia, a następ­nie cof­nię­ciu się aż do miej­sca, w któ­rym znaj­du­jesz się w chwi­li obec­nej. Dzięki temu unik­niesz uro­jo­nych przez sie­bie prze­szkód, zanim jesz­cze w ogó­le poj­miesz, jak osią­gnąć ideał.

Poniższy dia­gram poka­zu­je klu­czo­we punk­ty planu:

I teraz: Czy dokład­ny opis sta­nu aktu­al­ne­go jest potrzeb­ny, sko­ro klu­czo­we pyta­nie zawsze brzmi: co zmie­nić? Sprawdźmy. 

Wyobraźmy sobie, że robi­my porząd­ki w sta­rej piw­ni­cy a celem jest pozby­cie się rze­czy nie­po­trzeb­nych. Identyczną sytu­ację mamy z ple­ca­kiem, gdy dość regu­lar­nie wyjeż­dża­my np. w góry, nie chce­my jed­nak nosić zbęd­nych rze­czy. Są dwa moż­li­we podej­ścia do tego zadania:

  1. prze­glą­da­my wszyst­ko i zasta­na­wia­my się cze­go się pozbyć,
  2. odkła­da­my wszyst­ko na bok, i wybie­ra­my tyl­ko to o czym wie­my, że na pew­no nadal będzie potrzeb­ne i wie­my do cze­go, resz­ta zosta­je (z piw­ni­cy: wyrzucona). 

Można pró­bo­wać bro­nić każ­dej z tych metod, pro­blem w tym, że pierw­sza powo­du­je (prak­ty­ka to poka­zu­je), że zawsze zosta­je pra­wie wszyst­ko, a przy­by­wa nowego. 

Modelowanie organizacji

Natura czło­wie­ka to emo­cjo­nal­ne przy­wią­za­nie do tego co się już posia­da, a z natu­rą (emo­cje) trud­no wal­czyć. Dlatego war­to cza­sa­mi ją wspo­ma­gać (z tego same­go powo­du nie nale­ży same­mu nego­cjo­wać tego co jest dla nas bar­dzo waż­ne, a jak musi­my to robić sami, to nale­ży zre­zy­gno­wać z nego­cja­cji i z góry usta­lić korzyst­ne warun­ki lub zre­zy­gno­wać ).

Popatrzmy na zna­ny, nie tyl­ko moim czy­tel­ni­kom, od lat diagram:

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Pokazuje on trzy pod­sta­wo­we pozio­my opi­su (doku­men­to­wa­nia) orga­ni­za­cji. Najwyższy poziom to model biz­ne­so­wy, czy­li opis stra­te­gii (z regu­ły mie­ści się na jed­nej stro­nie maszy­no­pi­su). Najniższy to szcze­gó­ło­we opi­sy wyma­ga­nych kom­pe­ten­cji, zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry i zarzą­dze­nia, instruk­cje itp. Te dwa rodza­je opi­sów ma prak­tycz­nie każ­da orga­ni­za­cja bo nawet, jeże­li nie wyma­ga tego pra­wo, to wyma­ga­ją tego pod­sta­wy zarządzania. 

Środkowa war­stwa to coś, cze­go więk­szość orga­ni­za­cji nadal nie ma, bo uwa­ża­ją że nie jest to potrzeb­ne do bie­żą­ce­go, ope­ra­cyj­ne­go zarzą­dza­nia. Czym jest ten środ­ko­wy model? To jest tak zwa­ny wewnętrz­ny łań­cuch war­to­ści orga­ni­za­cji, czy­li opis tego jak powsta­ją jej pro­duk­ty i usłu­gi, i jaką poszcze­gól­ne pra­ce wno­szą war­tość doda­ną do cało­ści . Dokumentujemy go jako Model (mapa) Procesów Biznesowych, jest to abs­trak­cyj­ny model, pozba­wio­ny szcze­gó­łów, poka­zu­je to «co» robi­my i po co a nie «jak». Warto tu zwró­cić uwa­gę na waż­ną rzecz: 

Nie ma żad­ne­go sen­su odwzo­ro­wy­wa­nie na sche­ma­tach blo­ko­wych szcze­gó­łów trze­ciej naj­niż­szej war­stwy, bo powsta­ją mon­stru­al­ne licz­by dia­gra­mów, któ­re nicze­go nie wno­szą do pro­jek­tu, bo ich przy­dat­ność jest co naj­mniej wątpliwa.

To «jak» to robi­my zawie­ra posia­da­na już doku­men­ta­cja w war­stwie trze­ciej, naj­niż­szej; nie ma więc sen­su powtór­ne jej doku­men­to­wa­nie na dia­gra­mach, powo­łu­je­my się na nią mode­lu­jąc pro­ce­sy (wię­cej w arty­ku­le Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji).

Czy war­to mieć taki model pro­ce­sów? Owszem, bo podej­mo­wa­nie decy­zji o zmia­nach bez takie­go mode­lu to lote­ria. Jednak jeże­li model jest zbyt szcze­gó­ło­wy (patrz powyż­sza uwa­ga), to nie tyl­ko opra­co­wa­nie go jest kosz­tow­ne i trwa dłu­go, ale zapo­zna­nie się z nim zaj­mu­je zbyt dużo cza­su, więc nikt tego nie robi. W efek­cie decy­zje są podej­mo­wa­ne tak, jak by tego mode­lu nie było. Kiedyś decy­zje o zmia­nach podej­mo­wa­no rzad­ko i każ­do­ra­zo­we, poprze­dza­ją­ce te decy­zje dłu­gie ana­li­zy, mia­ły sens. Obecnie decy­zje takie podej­muj­my nie raz «znie­nac­ka”, i nawet jeże­li nie są czę­ste, to nie ma cza­su na poprze­dza­nie ich ana­li­za­mi, a bez ana­li­zy skut­ków decy­zje ope­ra­cyj­ne są lote­rią. W efek­cie utrzy­my­wa­nie aktu­al­ne­go, ale bez zbęd­nych deta­li, mode­lu orga­ni­za­cji jest moż­li­we, opła­cal­ne i ma ogrom­ne zna­cze­nie (patrz Audyt orga­ni­za­cji, model Architektury Korporacyjnej).

Poprawnie opra­co­wa­ne mode­le (mapy) pro­ce­sów biz­ne­so­wych pozwa­la­ją zro­zu­mieć orga­ni­za­cję i prze­wi­dy­wać efek­ty pla­no­wa­nych zmian. 

(patrz: Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści)

Wdrażanie zmian

Popatrzmy na poniż­szy diagram:

(J. Żeliński, 2012)

Rozwój orga­ni­za­cji, poza bar­dzo rzad­ki­mi przy­pad­ka­mi, nie jest (nie powi­nien być) rewo­lu­cją. Pisali o tym nie raz kry­ty­cy przy­wo­ły­wa­nej na począt­ku Radykalnej Reorganizacji Procesów Biznesowych (mało któ­ra orga­ni­za­cja ją prze­trwa­ła) . Więc co zmie­niać i jak? Powyższy dia­gram mówi, że gene­ral­nie zmia­ny doty­czą naj­niż­szej war­stwy, ale żeby wie­dzieć gdzie jest jej gra­ni­ca, trze­ba mieć udo­ku­men­to­wa­ną tak­że tę środ­ko­wą. Zmiany pro­ce­sów biz­ne­so­wych są rzad­kie, doty­czą poje­dyn­czych pro­ce­sów, i nie są to rewolucje.

Przejście od lewej do pra­wej stro­ny to nasz ple­cak w góry: albo prze­glą­da­my wszyst­ko i pró­bu­je­my odrzu­cać nad­miar, albo wybie­ra­my tyl­ko to, o czym wie­my że będzie potrzeb­ne. Skąd mamy wie­dzieć, co będzie potrzeb­ne? Jeżeli wyko­na­my model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści, to zna­czy, że dosko­na­le wie­my co i po co robi­my, pozo­sta­je jedy­nie okre­śle­nie tego jak. I tu wła­śnie poja­wia się moment, w któ­rym okre­śla­my jak coś zro­bić naj­le­piej, a potem patrzy­my czy to jak to teraz robi­my jest takie jak być powin­no. Jeżeli tak, kon­ty­nu­uje­my (zabie­ra­my to ze sobą w kolej­ną podróż), jeże­li nie – zarzu­ca­my i sta­je sie to wyma­ga­niem, wobec nowe­go roz­wią­za­nia (bez roz­pa­mię­ty­wa­nia histo­rii, sen­ty­men­ty nie­ste­ty znisz­czy­ły już nie­jed­ną firmę).

W pro­jek­cie ana­li­zy i uspraw­nie­nia powsta­ją więc:

  1. Dokumentacja ryn­ko­we­go mode­lu biz­ne­so­we­go, czy­li opis stra­te­gii (w tym tak­że misja i wizja organizacji).
  2. Model moty­wa­cji biz­ne­so­wej pla­no­wa­nych zmian (wyty­cza­my kierunek).
  3. Model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści (to jest kil­ka­na­ście dia­gra­mów a nie kilkaset!).
  4. Analiza prze­twa­rza­nych infor­ma­cji i jej stan­da­ry­za­cja (ana­li­za doku­men­tów, biz­ne­so­wy słow­nik pojęć, regu­ły biz­ne­so­we, stan­da­ry­za­cja tre­ści doku­men­tów, są to pro­duk­ty aktyw­no­ści na mode­lach procesów).
  5. Wymagania biz­ne­so­we (czym ma się cha­rak­te­ry­zo­wać nowe rozwiązanie).
  6. Opis (model) roz­wią­za­nia, sta­no­wią­cy sobą tak na praw­dę wyma­ga­nie dla jego dostaw­cy (wyko­naw­cy).

Jeżeli pozbę­dzie­my sie nad­mia­ro­wych, o wąt­pli­wej war­to­ści doda­nej dla tego pro­jek­tu, prac, to całość trwa od dwóch do sze­ściu mie­się­cy, zależ­nie od wiel­ko­ści orga­ni­za­cji. W dużych orga­ni­za­cjach łatwo jest podzie­lić mode­le na dzie­dzi­no­we obsza­ry, w któ­rych wdra­ża się lokal­ne samo­dziel­ne roz­wią­za­nia, wystar­czy zapla­no­wać ich inte­gra­cję. Mając model infor­ma­cyj­ny (doku­men­ty i ich wza­jem­ne zależ­no­ści) nie jest to trud­ne. Wbrew temu co mówią, dostaw­cy kom­plek­so­wych mono­li­tycz­nych sys­te­mów, nie jest żad­nym ryzy­kiem to że kil­ka dzia­łów prze­twa­rza te same dane, waż­ne jest zagwa­ran­to­wa­nie stan­da­ry­za­cji tych danych oraz ich nośni­ków czy­li doku­men­tów . Jeżeli bez pro­ble­mu mogą współ­pra­co­wać ze sobą dwie odręb­ne fir­my, to podob­nie mogą to robić wydzia­ły tej samej fir­my, tym bar­dziej że w dowol­nym momen­cie taki wydział może zostać wydzie­lo­ny jako osob­ny pod­miot, i po tej prze­mia­nie to wszyst­ko nadal dalej dzia­łać. Włączenie do wnę­trza orga­ni­za­cji innej fir­my podob­nie, nigdy nie powin­na to być rewo­lu­cja infor­ma­tycz­na i wymia­na wszystkiego. 

Podsumowanie

Praktyka poka­zu­je, że powyż­sze spraw­dza sie dosko­na­le. Rezygnacja z deta­licz­nych mode­li as-is nie przy­no­si stra­ty jako­ści pro­jek­tu, nie pod­no­si też jego ryzy­ka, a zna­ko­mi­cie skra­ca czas i tym samym obni­ża koszt tego eta­pu pra­cy (mode­lo­wa­nie pro­ce­sów). Owszem, nie raz na począt­ku sły­sza­łem od spon­so­ra pro­jek­tu: chce­my zoba­czyć te zmia­ny, chce­my widzieć róż­ni­ce”. Jednak ofer­ta wyko­na­nia takiej usłu­gi w dwóch warian­tach: zawie­ra­ją­ca model «as-is» i bez tego mode­lu (ofer­ta fixed-pri­ce bo innych niż umo­wa o dzie­ło na tym eta­pie od lat nie skła­dam: klien­ci chcą znać kosz­ty przed a nie po pro­jek­cie), od kil­ku lat w 100% przy­pad­ków koń­czy się rezy­gna­cją z doku­men­to­wa­nia deta­li i mode­li pro­ce­sów as-is”. Więcej w arty­ku­le Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści.

Uważam, że w cza­sach gdy czas to pie­niądz”, a czas ten liczy­my obec­nie w tygo­dniach a nie w latach, pro­jek­ty ana­li­tycz­ne trwa­ją­ce ponad kwar­tał (czy pół roku w bar­dzo dużej orga­ni­za­cji) są stra­tą cza­su i środków. 

Kluczowe pyta­nie na koniec: 

Kiedy powsta­ją szcze­gó­ły nowe­go roz­wią­za­nia? W toku pro­jek­to­wa­nia i wdrożenia…

…i jest to bar­dzo bez­piecz­ne i zara­zem efek­tyw­ne, bo mając archi­tek­tu­rę roz­wią­za­nia (wewnętrz­ny model łań­cu­cha war­to­ści i model archi­tek­tu­ry roz­wią­za­nia) wie­my «co» ma powstać, pozo­sta­je już tyl­ko na bie­żą­co podej­mo­wać decy­zje «jak» ma to wyglądać. 

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi?. ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Sprawując ze swo­jej stro­ny nad­zór nad dostaw­cą roz­wią­za­nia, jego nabyw­ca panu­je nad wszyst­kim. Mogę tyl­ko pod­su­mo­wać to tak: to co napi­sał Ackoff 15 lat temu i ponad 20 lat temu : podej­ście takie spraw­dza sie doskonale. 

(tak reali­zo­wa­ne były moje pro­jek­ty dla wie­lu małych firm, kil­ku insty­tu­cji publicz­nych, w tym Kancelarii Senatu i Żandarmerii Wojskowej, a tak­że dla KGHM SA)

Źródła

Cohen, H. (2006). Wynegocjuj to! (T. Misiorek, Trans.). Wydawnictwo Helion.
McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Rittel, H. W. J., & Webber, M. M. (2014). Dylematy ogól­nej teo­rii pla­no­wa­nia. Zarządzanie publicz­ne, 1, 13.
Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy, 104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a gene­ral the­ory of plan­ning. Policy Sciences, 4(2), 155 – 169. https://​doi​.org/​1​0​.​1​0​0​7​/​B​F​0​1​4​0​5​730
Coffey, B. (2017). Unpacking the impli­ca­tions of label­ling envi­ron­men­tal issu­es as wic­ked pro­blems.’ 16.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Ackoff, R. L. (1999). From data to wis­dom. In Ackoff’s Best (pp. 170 – 172). John Wiley & Sons.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji (Ł. Ludwicki, Trans.). Polskie Wydawnictwo Ekonomiczne.
Rupper, P., & Muler, R. (1996). Process Reengineering (T. Soróbka, Trans.). ASTRUM.

A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

Poziomy modelowania procesów

Kwestia licz­by pozio­mów mode­lo­wa­nia pro­ce­sów” poja­wia się na każ­dym moim szko­le­niu w posta­ci pytań uczest­ni­ków. Często tak­że spo­ty­kam się z tym zagad­nie­niem” w pro­jek­tach i w lite­ra­tu­rze. Można np. spo­tkać mode­le z pro­ce­sa­mi ponu­me­ro­wa­ny­mi pozio­ma­mi mode­lo­wa­nia: pro­ce­sy głów­ne 0.1; 0.2 itp., pro­ce­sy pierw­sze­go pozio­mu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?

Po pierw­sze: pro­ces np. archi­wi­za­cji doku­men­tu może się poja­wić na każ­dym z tych pozio­mów, jaki numer mu nadać? Po dru­gie pew­ne obsza­ry dzia­ła­nia są mało zło­żo­ne i moż­li­we, że wystar­czy jeden poziom”, inne zło­żo­ne i potrzeb­ne będą może czte­ry poziomy?

Elementarny pro­ces, podob­nie jak klo­cek LEGO, może się poja­wić wszę­dzie, nie­za­leż­nie od pozio­mu, np. reali­za­cja zobo­wią­za­nia finan­so­we­go, czy­li zapła­ta za coś, może się poja­wić jako zapła­ta za fak­tu­rę wysta­wio­ną przez kan­ce­la­rię praw­ną w pro­ce­sie nego­cjo­wa­nia umo­wy han­dlo­wej (czy­li bar­dzo wyso­ko”) jak i w pro­ce­sie regu­lo­wa­nia zobo­wią­zań za dziur­ka­cze (raczej nisko w takiej hierarchii).

Najpierw dwie klu­czo­we defi­ni­cje za nor­mą ter­mi­no­lo­gicz­ną ISO 9000 (jakość zarządzania):

Proces to: każ­de dzia­ła­nie, któ­re prze­kształ­ca wej­ście (dane wej­ścio­we) na wyj­ście (dane wyj­ścio­we). Proces może w swo­im wnę­trzu” zawie­rać zbiór róż­nych ope­ra­cji (dzia­łań) wza­jem­nie ze sobą powią­za­nych i na sie­bie oddziałujących.

Procedura to: okre­ślo­ny spo­sób reali­za­cji dzia­łań lub procesów.

Powyższa defi­ni­cja jest łatwa do przy­ję­cia i czę­sto sto­so­wa­na, jed­nak jest zbyt ubo­ga (poję­cie pro­ces jest tu dość pojem­ne) by sta­no­wi­ła pod­sta­wę do for­mal­ne­go mode­lo­wa­nia orga­ni­za­cji, dla­te­go dodat­ko­wo przy­to­czę tę, nie­co pełniejszą:

(cytat, str. 41) Proces biz­ne­so­wy jest chro­no­lo­gicz­nym i logicz­nym cią­giem funk­cji (zadań) wyko­ny­wa­nych w toku pra­cy nad okre­ślo­nym obiek­tem w ramach racjo­nal­ne­go dzia­ła­nia.

(cytat, str. 431) Proces biz­ne­so­wy sta­no­wi zbiór powią­za­nych ze sobą czyn­no­ści ukie­run­ko­wa­nych na reali­za­cję okre­ślo­ne­go celu biz­ne­so­we­go w opar­ciu o wyko­rzy­sty­wa­ne zaso­by. Proces biz­ne­so­wy jest ste­ro­wa­ny poprzez stra­te­gię orga­ni­za­cji defi­niu­ją­cą cele oraz pro­duk­ty two­rzo­ne przez pro­ce­sy.

Przeglądając lite­ra­tu­rę przed­mio­tu (w tym powyż­sze) moż­na dojść do nastę­pu­ją­cej defi­ni­cji pro­ce­su biznesowego:

Proces biz­ne­so­wy: czyn­ność, lub logicz­nie powią­za­ny chro­no­lo­gicz­ny łań­cuch czyn­no­ści, prze­kształ­ca­ją­cy stan wej­ścia pro­ce­su w stan jego wyj­ścia, mają­cy war­tość dla odbior­cy. Proces do wyko­na­nia, wyma­ga okre­ślo­nych zaso­bów, spo­sób jego reali­za­cji może być ogra­ni­czo­ny. (opr. własne)

Do mode­lo­wa­nia pro­ce­sów obec­nie uży­wa się naj­czę­ściej nota­cji BPMN (obec­nie tak zwa­ny stan­dard de’fac­to), spe­cy­fi­ka­cja tej nota­cji tak defi­niu­je proces:

A Process descri­bes a sequ­en­ce or flow of Activities in an orga­ni­za­tion with the objec­ti­ve of car­ry­ing out work. In BPMN a Process is depic­ted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that defi­ne fini­te exe­cu­tion seman­tics. Processes can be defi­ned at any level from enter­pri­se-wide Processes to Processes per­for­med by a sin­gle per­son. Low-level Processes can be gro­uped toge­ther to achie­ve a com­mon busi­ness goal. 

Warto zwró­cić uwa­gę na fakt, że z per­spek­ty­wy nota­cji, ta jest jedy­nie języ­kiem wyra­zu, pro­ces to sekwen­cja aktyw­no­ści w orga­ni­za­cji, któ­rej celem jest dostar­cze­nie okre­ślo­ne­go efek­tu”. Dalej: pro­ces jest obra­zo­wa­ny z pomo­cą gra­fu zło­żo­ne­go z ele­men­tów o okre­ślo­nej seman­ty­ce (mają­cych sztyw­no okre­ślo­ne zna­cze­nia). Proces może być defi­nio­wa­ny na dowol­nym pozio­mie. Procesy na naj­niż­szym pozio­mie mogą być gru­po­wa­ne np. wspól­nym celem. Tyle nota­cja. Definicja pro­ce­su w BPMN jest zgod­na z ISO.

Tak więc pro­ce­sem jest tu każ­dy prze­pływ pra­cy, zaś pro­ce­sem biz­ne­so­wym są te prze­pły­wy, któ­rych gra­ni­ce (począ­tek i koniec) wyzna­cza­ją pro­duk­ty biz­ne­so­we (okre­ślo­ne obiek­ty, cele biznesowe). 

Co to ozna­cza? Oznacza to, że sko­ro celem biz­ne­so­wym jest np. wysta­wie­nie fak­tu­ry za doko­na­ną sprze­daż, zaś przy­go­to­wa­nie samej tre­ści fak­tu­ry jest jedy­nie jed­nym z eta­pów jej two­rze­nia (krok), pro­ce­sem biz­ne­so­wym jest wysta­wie­nie fak­tu­ry, ale nie jest nim samo jej zre­da­go­wa­nie (krok, kolej­ne zada­nie) bo poza reda­go­wa­niem mamy tak­że czyn­no­ści spraw­dze­nia, księ­go­wa­nia i wydru­ku. Tak więc na naj­niż­szym pozio­mie hie­rar­chii mamy pro­ces Fakturowanie, dal­sze szcze­gó­ły wysta­wie­nia fak­tu­ry to pro­ce­du­ra jej two­rze­nia skła­da­ją­ca się z kolej­nych, usta­lo­nych kro­ków (zadań do wykonania).

Proces biz­ne­so­wy Fakturowanie może być (i z regu­ły jest) czę­ścią nad­rzęd­ne­go pro­ce­su Realizacja zamó­wie­nia. Pierwszym pro­duk­tem tego pro­ce­su jest Zamówienie goto­we do wyko­na­nia, pro­ces ten to np. sekwen­cja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały pro­ces Realizacji zamó­wie­nia ma więc dwa pod­pro­ce­sy: Rejestracja zamó­wie­nia oraz nastę­pu­ją­cy po nim pro­ces biz­ne­so­wy Fakturowanie. Produktem pierw­sze­go jest Zatwierdzone zamó­wie­nie a pro­duk­tem dru­gie­go Faktura sprzedaży.

Poszczególne wewnętrz­ne kro­ki obu pro­ce­sów, same z sie­bie, nie two­rzą pro­duk­tu (np. zare­je­stro­wa­ne ale nie­spraw­dzo­ne Zamówienie nie ma war­to­ści biz­ne­so­wej, to krok któ­ry nale­ży wyko­nać ale nie jest to samo­dziel­ny pro­ces biznesowy).

Popatrzmy na poniż­szy diagram:

(źr. http://www.bptrendsassociates.com/)

Pokazuje trzy klu­czo­we pozio­my pro­ce­so­we­go opi­su orga­ni­za­cji: na samym dole mamy zaso­by, ich umie­jęt­no­ści wspie­ra­ne pro­ce­du­ra­mi. To war­stwa reali­za­cji, ta któ­ra jest udo­ku­men­to­wa­na w każ­dej nie­mal­że orga­ni­za­cji jako zakre­sy obo­wiąz­ków, pro­ce­du­ry i zarzą­dze­nia. Najwyższa war­stwa to klu­czo­we ele­men­ty stra­te­gii, archi­tek­tu­ra klu­czo­wych pro­ce­sów. Na tym pozio­mie moż­na mówić o tak zwa­nych pro­ce­sach end-2-end czy­li o tym jak orga­ni­za­cja reagu­je na bodź­ce zewnętrz­ne (np. na każ­de zapy­ta­nie ofer­to­we odsy­ła­na jest ofer­ta). Ten poziom tak­że jest pra­wie zawsze udo­ku­men­to­wa­ny jako stra­te­gia i plan mar­ke­tin­go­wy. Warstwa środ­ko­wa, pro­ce­sy biz­ne­so­we, to abs­trak­cja opi­su­ją­ca (mode­lu­ją­ca) logi­kę dzia­ła­nia orga­ni­za­cji – jej wewnętrz­ny łań­cuch war­to­ści.

Popatrzmy teraz na jeden ze spo­so­bów usta­le­nia licz­by pozio­mów mode­lo­wa­nia, bar­dzo czę­sto spotykany:

  1. Level 1 ? End-to-end pro­ces­ses: Span across func­tions, e.g. market-to-cash.
  2. Level 2 ? Main pro­cess are­as: Typically func­tion-spe­ci­fic, e.g. acco­unts receivables.
  3. Level 3 ? Sub-pro­ces­ses: Sequence of rela­ted acti­vi­ties, e.g. goods invoicing.
  4. Level 4 ? Activities: Key steps within sub-pro­cess, e.g. prin­ting invoices.
  5. Level 5 ? Tasks: Specific user actions or sys­tem trans­ac­tions, e.g. send invo­ice to print. A step con­ta­ins a descrip­tion of how to per­form the task.

(źr. Process Improvement at Carlsberg powe­red by ARIS from Software AG).

Poziom ozna­czo­ny Level‑1 jak naj­bar­dziej mamy zawsze”. Różnica pomię­dzy pozio­ma­mi 4 i 5 jest dla mnie nie­zro­zu­mia­ła. Angielskie sło­wa aci­ti­vi­ty i task to odpo­wied­nio czyn­ność i zada­nie. Trudno mi sobie wyobra­zić dru­ko­wa­nie fak­tu­ry bez wysła­nia fak­tu­ry do dru­ku. Czy to dwa pozio­my szcze­gó­ło­wo­ści? To co tu widzę, i nie tyl­ko tu, to mie­sza­nie obsza­ru dzia­ła­nia orga­ni­za­cji (ludzi) z obsza­rem reali­zo­wa­nym przez zaso­by”. To trosz­kę (poda­ne przy­kła­dy) jak by ktoś uznał, że czyn­ność (poziom 4) to zmia­na bie­gu w samo­cho­dzie a zada­nie (poziom 5) to zazę­bie­nie się wła­ści­wych kół zęba­tych w skrzy­ni bie­gów. Ma to sens?

Poziomy 2 i 3 to mode­le pro­ce­sów, licz­ba tych pozio­mów może być róż­na o czym dalej.

Przykład

Poniżej pro­ce­sy end-2-end (celo­wo nie nada­łem im rze­czy­wi­stych nazw by nie suge­ro­wać się kon­kret­ną fir­mą czy branżą):

Procesy end-2-end

Pokazuje jak orga­ni­za­cja reagu­je na zda­rze­nia gene­ro­wa­ne przez jej oto­cze­nie biz­ne­so­we. Kolejny etap (poziom ?) to model (dia­gram) dla każ­de­go tego procesu:

- pro­ces A

Proces A

- pro­ces B

Proces B

Proces A zawie­ra (two­rzy) pośred­ni pro­dukt (Dane 5) oraz pro­dukt Dane4. Zgodnie z defi­ni­cją pro­ce­su, ozna­cza to, że A skła­da się dwóch pod­pro­ce­sów, pierw­szy two­rzy pro­dukt Dane5 a dru­gi Dane4. Proces two­rzą­cy Dane5 jest wyko­ny­wa­ny np. na bazie wie­dzy wyko­naw­cy (rola), któ­ry posia­da wyma­ga­ną umie­jęt­ność, ta jest opi­sa­na w dzia­le HR więc powie­la­nie zapi­sów z kar­ty obo­wiąz­ków jest zbęd­ne, wystar­czy się na nią powo­łać w doku­men­ta­cji pro­ce­su. Czynność two­rzą­ca Dane4 jest na tyle zło­żo­na”, że wie­dza wyko­naw­cy to za mało (albo jest ryzy­ko, że się pomy­li) dla­te­go doku­men­tu­je­my (for­ma­li­zu­je­my) spo­sób two­rze­nia pro­duk­tu Dane4 jako pro­ces C skła­da­ją­cy się z okre­ślo­nych czynności:

Proces C

Proszę zwró­cić uwa­gę, że pro­ces B i C to pro­ce­du­ry (wewnątrz nie powsta­ją pro­duk­ty biz­ne­so­we), to tyl­ko opis kro­ków jakie nale­ży wyko­nać by powstał pro­dukt pro­ce­su. Procedury z powo­dze­niem moż­na, zamiast two­rzyć takie dia­gra­my, opi­sać zna­nym z pro­jek­tów ISO struk­tu­ral­nym tek­stem, dia­gram raczej nie wno­si tu war­to­ści doda­nej. Tworzenie dia­gra­mów dla pro­ce­dur mia­ło by sens, gdy­by zre­zy­gno­wać z pro­ce­dur w for­mie tek­sto­wej, w prze­ciw­nym wypad­ku two­rzy­my redun­dant­ne opi­sy wyma­ga­ją­ce syn­chro­ni­za­cji. W prak­ty­ce robi się tak, doku­men­tu­je pro­ce­du­ry dia­gra­ma­mi, w przy­pad­kach gdy pro­ce­du­ra jest zło­żo­na i jej opis tek­sto­wy może być nie­czy­tel­ny lub trud­ny w zro­zu­mie­niu. Analogicznie ma się sytu­acja w przy­pad­kach gdy spo­sób two­rze­nia pro­duk­tu (pro­ces biz­ne­so­wy) w 100% jest efek­tem wie­dzy posia­da­nej przez wyko­naw­ce (rola): tu powo­łu­je­my się wyłącz­nie na sto­sow­ne zapi­sy w dzia­le HR, nie two­rzy­my ich kopii w posta­ci diagramu.

Zobrazowanie powyż­szych dia­gra­mów, ich powiązań:

Struktura modelu procesów

Tu mamy dia­gram obra­zu­ją­cy pod­le­głość”, czy­li to jak się one wza­jem­nie zagnież­dża­ją i to jak naj­bar­dziej obra­zu­je struk­tu­rę całe­go mode­lu. Jednak pró­ba ponu­me­ro­wa­nia kon­kret­nych pro­ce­sów i zbu­do­wa­nia ich hie­rar­chii zacho­wu­ją­cej drze­wia­stą logi­kę jest nie­re­al­na z powo­du wła­snie tego, że pro­ce­sy są ini­cjo­wa­ne zda­rze­nia­mi, te zaś nie są pozio­mo­we” (np. pro­ces opi­sa­ny na począt­ku archi­wi­za­cji doku­men­tu może się poja­wić na każ­dym poziomie/diagramie). Numerować hie­rar­chicz­nie jed­nak moż­na dia­gra­my, któ­re jak widać, mają struk­tu­rę podob­ną do sys­te­mu folderów.

Ile więc mamy pozio­mów mode­lo­wa­nia orga­ni­za­cji? Trzy (patrz poka­za­ny wcze­śniej dia­gram BPTrends): naj­wyż­szy czy­li stra­te­gia i pro­ce­sy end-2-end, naj­niż­szy czy­li pro­ce­du­ry i instruk­cje sta­no­wi­sko­we (imple­men­ta­cja) oraz środ­ko­wy czy­li abs­trak­cję – model pro­ce­so­wy – opi­su­ją­cą jak to się wszyst­ko do sie­bie ma (środ­ko­wy poziom ma struk­tu­rę zagnież­dża­nia się diagramów/modeli pro­ce­sów jak wyżej ale pro­ce­sy mają jedy­nie swo­je nazwy jako identyfikatory).

Proszę zwró­cić uwa­gę, że:

  1. w zasa­dzie każ­da orga­ni­za­cja ma udo­ku­men­to­wa­ny poziom naj­wyż­szy (stra­te­gia) i naj­niż­szy (pro­ce­du­ry, zarzą­dze­nia, instrukcje)
  2. war­stwa środ­ko­wa jest two­rzo­na wte­dy, gdy chce­my zro­zu­mieć wewnętrz­ne zależ­no­ści, któ­rych może być dużo, i mogą być zło­żo­ne (zawi­łe); to ile pozio­mów” powsta­nie w war­stwie środ­ko­wej, zale­ży wyłącz­nie od stop­nia zło­żo­no­ści danej orga­ni­za­cji i zawsze jest to indy­wi­du­al­na jej cecha, tyl­ko w czę­ści zależ­na od wiel­ko­ści organizacji.

Często moż­na się spo­tkać z nie­for­mal­ny­mi (o nie­zde­fi­nio­wa­nych gra­ni­cach pro­ce­sów) dia­gra­ma­mi w postaci:

Poziom naj­wyż­szy:

Procesy end-2-end v.2

i pozio­my niższe:

Model łańcucha wartości A

Czy taki dia­gram nam coś nam daje? Jest w zasa­dzie gra­ficz­ną for­mą tek­sto­we­go (nie­jed­no­znacz­ne­go) opisu. 

Modelowanie pro­ce­sów biz­ne­so­wych to nie ryso­wa­nie dia­gra­mów, to two­rze­nie mode­li, któ­re pod­da­ją się wali­da­cji i testo­wa­niu zgod­no­ści z rze­czy­wi­sto­ścią. Poprawne mode­le pozwa­la­ją prze­wi­dy­wać reak­cję orga­ni­za­cji na pla­no­wa­ne zmiany. 

Na zakończenie

Modne ostat­nio pro­jek­ty mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z regu­ły, jako pro­dukt, dostar­cza­ją nie­zli­czo­ne ilo­ści map pro­ce­sów”, któ­re koń­czą swój żywot na zaku­rzo­nych z cza­sem pół­kach, powsta­wa­ły zbyt dużym kosz­tem by je wyrzu­cić do kosza. Ich sta­łe utrzy­ma­nie (aktu­ali­za­cja) nie raz bywa kosz­tow­niej­sze od wytworzenia.

Po więc robi­my te mode­le? Przytoczę zno­wu cytat ini­cju­ją­cy pew­ną dys­ku­sję na forum: 

I think the only reason to con­duct any pro­ject is to impro­ve one or more pro­ces­ses. This means that if you don’t know which process(es) you are try­ing to impro­ve, you sho­uld not start the pro­ject. Comments? (Process befo­re pro­ject | LinkedIn).

W wol­nym tłumaczeniu ;):

jeże­li uzna­my, że jedy­nym powo­dem pro­wa­dze­nia pro­jek­tów jest uspraw­nia­nie okre­ślo­nych pro­ce­sów biz­ne­so­wych, to zna­czy, że uru­cha­mia­nie tych pro­jek­tów bez wie­dzy, któ­re to dokład­nie pro­ce­sy i bez peł­ne­go zro­zu­mie­nia ich wpły­wu na orga­ni­za­cję, pro­jek­tów tych nie nale­ży rozpoczynać.

Procesy mode­lu­je­my więc po to, by zro­zu­mieć jak dzia­ła orga­ni­za­cja oraz po to, by prze­wi­dzieć jak się ona zacho­wa, jeże­li jakiś pro­ces zmie­ni­my, bo może się nie raz oka­zać, że nie war­to się pew­nych pro­jek­tów podej­mo­wać z uwa­gi na skutki.

Modelowanie, jak widać, nie jest pro­ce­sem obraz­ko­we­go zapi­su tego co wie­my od pra­cow­ni­ków tej czy innej fir­my, to jest ste­no­ty­pia. Modelowanie to trud­ny pro­ces odkry­wa­nia praw­dzi­wej logi­ki dzia­ła­nia orga­ni­za­cji (i wypa­da mi teraz zapro­sić na moje szkolenia :)).

Polecam tak­że wcze­śniej­szy arty­kuł o mode­lo­wa­niu orga­ni­za­cji z per­spek­ty­wy sys­te­mów zarzą­dza­nia jako­ścią ISO, bo pro­jek­ty IT to nie jedy­ny przy­pa­dek gdy mode­lo­wa­nie orga­ni­za­cji bar­dzo pomaga.

Źródła

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
Skersys, T., Tutkute, L., Butleris, R., & Butkiene, R. (2012). Extending BPMN busi­ness pro­cess model with SBVR busi­ness voca­bu­la­ry and rules. Information Technology and Control, 41(4), 356 – 367.

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.

Pokazać więcej z sensem… ArchiMate

Analiza biz­ne­so­wa to dość duże wyzwa­nie. Nie pole­ga tyl­ko na zapi­sa­niu z pomo­cą wywia­dów tego, co fir­ma robi. Chodzi o zro­zu­mie­nie tego co dana fir­ma robi i po co to robi. Powoli coraz wię­cej się mówi o mode­lach i nota­cjach. Stały się wręcz mod­ne (bo, że poma­ga­ją to już wia­do­mo). Jednak celem ana­li­zy nie jest opra­co­wa­nie mode­li pro­ce­sów, te są tyl­ko narzę­dziem osią­ga­nia celu. Celem ana­li­zy jest odkry­cie i wska­za­nie tego, co i na co ma wpływ w mode­lo­wa­nej organizacji.

Niejako stan­dar­dem w pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, są ostat­nio nota­cje: BPMN na eta­pie two­rze­nia mode­li biz­ne­so­wych i nota­cja UML na eta­pie pro­jek­to­wa­nia opro­gra­mo­wa­nia (całe­go sys­te­mu). Od dłuż­sze­go cza­su spo­ty­kam się z pew­ny­mi ogra­ni­cze­nia­mi obu tych notacji.

W jed­nym z poprzed­nich arty­ku­łów napiałem:

Na pozio­mie pro­ce­sów biz­ne­so­wych, sto­su­ję zamien­nie BPMN albo ArchiMate. Z każ­dym kolej­nym pro­jek­tem skła­niam się jed­nak do uży­wa­nia na tym pozio­mie ArchiMate. Powodem jest to, że BPMN ofe­ru­je wyłącz­nie czy­ste poję­cia z defi­ni­cji wyko­naw­czej pro­ce­su (czyn­ność, dane, zda­rze­nie, rola, pula, bram­ki). Na tym pozio­mie jed­nak, nie raz nale­ży wyra­zić roz­dziel­nie takie poję­cia jak rola i aktor (np. klient i kon­tra­hent mogą peł­nić rolę zama­wia­ją­ce­go w pro­ce­sie) albo poję­cia takie jak funk­cje biz­ne­so­we (aktor wraz z zaso­ba­mi jakich uży­wa, peł­ni funk­cję admi­ni­stra­cji wewnętrz­nej) albo usłu­gi powią­za­nej z pro­ce­sa­mi (pro­ces sprze­da­ży powią­za­ny z usłu­gą obsłu­gi klien­ta). Przykłady moż­na mno­żyć. (Co jest wadą więk­szo­ści ana­liz biz­ne­so­wych?).

Od cza­su do cza­su jestem pyta­ny jak repre­zen­to­wać System (opro­gra­mo­wa­nie ana­li­zo­wa­ne lub pro­jek­to­wa­ne) na mode­lach BPMN. Niestety nota­cja ta nie ma takie­go odręb­ne­go poję­cia w swo­jej prze­strze­ni poję­cio­wej. Najczęściej spo­ty­ka­nym spo­so­bem zobra­zo­wa­nia sys­te­mu na mode­lu pro­ce­su jest uży­cie dedy­ko­wa­ne­go toru (lane) dla zobra­zo­wa­nia opro­gra­mo­wa­nia i umiesz­cza­nie w nim czyn­no­ści wyko­ny­wa­nych przez (z uży­ciem) opro­gra­mo­wa­nie (od tej meto­dy odsze­dłem kil­ka lat temu). Inna meto­da to ozna­cza­nie czyn­no­ści zwią­za­nych z uży­cie sys­te­mu ste­reo­ty­pem przy­pa­dek uży­cia (tę nadal sto­su­ję). Pierwsza meto­da moim zda­niem łamie defi­ni­cje roli w pro­ce­sie. Jeżeli jakaś czyn­ność jest reali­zo­wa­na przez oso­bę (akto­ra) uży­wa­ją­cą do pra­cy opro­gra­mo­wa­nia, poja­wia się pro­blem: co jest tu mode­lo­wa­ne i gdzie się podział aktor sko­ro tor to sys­tem. Drugi spo­sób to uży­cie moż­li­wo­ści pro­gra­mu CASE uży­te­go do ana­li­zy i nie­stan­dar­do­we­go wzbo­ga­ce­nia nota­cji o poję­cie ste­reo­ty­pu, któ­re­go for­mal­nie BPMN nie ma. Jedno i dru­gie kłó­ci się tak­że z mode­lo­wa­niem eta­pu CIM ([[Computation Independent Model]]).

Jak już nie raz pod­kre­śla­łem, siła for­mal­nych nota­cji leży w ich bar­dzo dobrze opra­co­wa­nym słow­ni­ku pojęć i rela­cji mię­dzy tymi poję­cia­mi. Łamanie tych zasad powo­du­je, że tak wyko­na­na ana­li­za sta­je się ryzy­kow­na, gdyż pozwa­la na wpro­wa­dza­nie nie­jed­no­znacz­no­ści w modelach.

Jednak pro­blem ist­nie­je… powsta­ła notacja

ArchiMate

Notacja powsta­ła w Telematica Institute, zyska­ła sobie wła­sną toż­sa­mość jako ArchiMate, zosta­ła wchło­nię­ta” pod skrzy­dła The Open Group. Specyfikacja 1.0 powsta­ła w 2004 roku więć nota­cja zosta­ła już dość dobrze prze­ćwi­czo­na”. Z niszo­wej sta­ła się stan­dar­dem. Obecnie sta­no­wi ofi­cjal­ne narzę­dzie mode­lo­wa­nia w pro­jek­tach na bazie meto­dy­ki TOGAF:

(źr. www​.archi​ma​te​.nl, obec­nie TOGAF 9 i Archimate v.2.0; poprzed­nia ArchiMate v.1.0 zawie­ra­ła tyl­ko poję­cia z zakre­su warstw biz­ne­so­wej, apli­ka­cji i tech­no­lo­gii, pola zakre­ślo­ne uko­śną linią to roz­sze­rze­nie wpro­wa­dzo­ne w wer­sji 2.0).

Ważne jest to, że nota­cja ta swo­imi poję­cia­mi biz­ne­so­wy­mi, opi­su­je (mode­lu­je) orga­ni­za­cje prze­kro­jo­wo. W ramach sys­te­mu poję­cio­we­go ArchiMate mamy trzy gru­py pojęć dla trzech warstw modeli:

Jak widać słow­nik pojęć w war­stwie biz­ne­so­wej jest znacz­nie bogat­szy niż w nota­cji BPMN. Każde poję­cie ma ści­śle zde­fi­nio­wa­ne zna­cze­nie a zna­cze­nia te (zasięg ich defi­ni­cji) oczy­wi­ście nie zacho­dzą na sie­bie. Co nam to daje? Możliwe jest prze­pro­wa­dze­nie bar­dzo wni­kli­wej ana­li­zy logi­ki pro­ce­sów biz­ne­so­wych, sko­ja­rze­nie jej z usłu­ga­mi sys­te­mu, jego funk­cjo­nal­no­ścią i meto­da­mi imple­men­ta­cji. Czy ArchiMate zastę­pu­je BPMN czy UML? Nie, ale pozwa­la unik­nąć ich nad­uży­wa­nia i nad­ra­bia ich bra­ki w sfe­rze biz­ne­so­wych mode­li abstrakcyjnych.

Jak już pisa­łem BPMN i UML to nota­cje, któ­re powsta­ły w celach inży­nier­skich” tu, w inży­nie­rii opro­gra­mo­wa­nia, są raczej bez­kon­ku­ren­cyj­ne. Jednak są, moim zda­niem, zbyt ubo­gie i mało zro­zu­mia­łe do mode­lo­wa­nia zło­żo­no­ści biz­ne­so­wej. Pokażę to na przy­kła­dzie mode­lu pro­ce­su sprze­da­ży. Załóżmy, że w toku ana­li­zy udo­ku­men­to­wa­li­śmy pro­ces fak­tu­ro­wa­nia wraz z tym kto fak­tu­ru­je, fak­tu­rą jako doku­men­tem i dany­mi. Chcemy następ­nie opra­co­wać spe­cy­fi­ka­cję usług, jakie pla­no­wa­ny sys­tem miał­by reali­zo­wać, przy­po­rząd­ko­wać logicz­nie poszcze­gól­ne usłu­gi do grup (funk­cjo­nal­ność sys­te­mu). Na koniec zapro­jek­to­wać archi­tek­tu­rę systemu.

Jak wspo­mnia­łem poprzed­nio, pro­blem roz­wią­zu­je sto­so­wa­nie języ­ka (nota­cji) ade­kwat­ne­go do pro­ble­mu. Tu poka­żę przy­kład jak nota­cja ArchiMate radzi sobie z pro­ble­mem łącze­nia biz­ne­su, opro­gra­mo­wa­nia i technologii:

A gdzie BPMN i UML? Ano każ­dy pro­ces (przy­ję­cie zamó­wie­nia, kom­ple­ta­cja, fak­tu­ro­wa­nie) w kon­tek­ście szcze­gó­łów prze­pły­wu pra­cy, mode­lo­wa­ny był­by w nota­cji BPMN (kon­kret­ne role, doku­men­ty, czyn­no­ści). Pozostałe war­stwy ope­ru­ją poję­cia­mi, któ­rych szcze­gó­ły moż­na (nale­ży jeże­li taki jest zakres pro­jek­tu) mode­lo­wać już w nota­cji UML. Usługi mapu­ją się na przy­pad­ki uży­cia, pozo­sta­łe to archi­tek­tu­ra: kom­po­nen­ty opro­gra­mo­wa­nia, dane, archi­tek­tu­ra techniczna.

Jak widać, ArchiMate pozwa­la na tym pozio­mie abs­trak­cji na wię­cej niż same BPMN czy UML, ale też nie zastę­pu­je ich. Wzbogaca tak­że sys­tem poję­cio­wy na potrze­by ana­li­zy biz­ne­so­wej co pozwa­la wier­nie odtwo­rzyć rze­czy­wi­stość biz­ne­so­wą w spo­sób zro­zu­mia­ły dla biz­ne­su”. Jako pod­su­mo­wa­nie przy­to­czę jesz­cze raz zna­ny już tu diagram:

(jak two­rzyć mode­le ArchiMate z pomo­cą narzę­dzia Agilian).

O archi­tek­tu­rze kor­po­ra­cyj­nej w kon­tek­ście ana­li­zy i pro­jek­to­wa­ni innym razem. Teraz tyl­ko kil­ka korzy­ści z posia­da­nia takie­go modelu:

  1. moż­li­wość wywo­dze­nia wyma­gań na opro­gra­mo­wa­nie w mode­lu biznesowego,
  2. moż­li­wość ana­li­zy wpły­wu i zależ­no­ści usług biz­ne­so­wych od infra­struk­tu­ry IT (pro­jek­ty zwią­za­ne z ana­li­zą cią­gło­ści dzia­ła­nia organizacji),
  3. moż­li­wość pro­wa­dze­nia prze­kro­jo­wych ana­liz ryzyka.

Więcej na temat samej Architekturze Korporacyjnej na stro­nie ArchitekturaKorporacyjna​.pl, któ­rą gorą­co polecam.

Zainteresowanym nota­cją ArchiMate i jej uży­wa­niem pole­cam stro­nę ArchiMate Good practices.

___

P.S. Z uwa­gi na wady seman­tycz­ne nota­cji ArchiMate i roz­po­czę­cie przez The Open Group jej licen­cjo­no­wa­nia zarzu­ci­łem sto­so­wa­nie tej nota­cji (2012).

Czym jest Piąty element – Audyt organizacji czyli analiza biznesowa

Większość mode­li (sys­te­mów map) pro­ce­sów biz­ne­so­wych posłu­gu­je się trzy­ele­men­to­wym wzor­cem (prag­ma­ty­ką) bazu­ją­cym na defi­ni­cji pro­ce­su brzmią­cej mniej wię­cej tak: pro­ces to czyn­ność lub ich sekwen­cja prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia. Czasami doda­je się, że źró­dłem wej­ścia jest dostaw­ca” a wyj­ścia klient” (tak­że tak zwa­ny klient wewnętrz­ny). Wada tej defi­ni­cji pole­ga na tym, że jest zbyt ?mecha­nicz­na?. Co to zna­czy? Że trak­tu­je wej­ście i wyj­ście pro­ce­su jak ?poje­dyn­cze sta­ny cze­goś? łącz­nie (wytłu­ma­cze­nie kil­ka lini­jek dalej).

Klasycznym przy­kła­dem tego podej­ścia jest Six Sigma i model SIPOC:

Model SIPOC zakła­da ist­nie­nie osob­nej doku­men­ta­cji dla same­go pro­ce­su, nie pre­cy­zu­jąc jak ma zostać ona wyko­na­na (nie narzu­ca meto­dy doku­men­to­wa­nia procesu).

Nieco szer­sza defi­ni­cja pro­ce­su, miesz­czą­ca się poję­cio­wo w powyż­szej, mogła by brzmieć: pro­ces prze­kształ­ca stan wej­ścia w stan wyj­ścia, prze­kształ­ce­nie to jest ogra­ni­czo­ne okre­ślo­ny­mi zaso­ba­mi i regu­ła­mi (zaka­za­mi). Tu mamy do czy­nie­nia z pię­cio­ma ele­men­ta­mi to jest: wej­ście, wyj­ście, pro­ces, zaso­by, regu­ły. Przykładem tego podej­ścia jest star­szy od Six Sigma model opar­ty na wzor­cu [[ICOM]] (powstał w latach 60tych!):

Tu już widać, że pro­ces na tym pozio­mie jest pew­ną abs­trak­cją, defi­nio­wa­ne są (ICOM) czte­ry sate­li­tar­ne” ele­men­ty defi­niu­ją­ce co, z cze­go i dla­cze­go się dzieje”.

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]) . Tu mamy:

Powyższy model bazu­je na uzna­niu, że pro­ces biznesowy:

  1. ma cel,
  2. ma spe­cy­ficz­ne dane na wejściu,
  3. ma spe­cy­ficz­ne dane na wyjściu,
  4. wyma­ga zasobów,
  5. sta­no­wi wie­le czyn­no­ści do wykonania”,
  6. anga­żu­je róż­ne depar­ta­men­ty” w fir­mie (pozio­my przepływ),
  7. two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrznego)

Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biznesowy(«goal»). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludzkie).

Od nie­daw­na UML for­mal­nie wpro­wa­dził nowy dia­gram Profile (jako wer­sji Beta uży­wam go od roku co naj­mniej) i zacho­wu­jąc seman­ty­kę tego dia­gra­mu trud­no było by taki pro­fil zbu­do­wać (mi nie wyszło). Jednak oce­nę przy­dat­no­ści tego sys­te­mu pozo­sta­wiam Państwu.

Definicja trzy­ele­men­to­wa trak­tu­je wszyst­kie dostęp­ne dane (infor­ma­cje) jako Wejście. Problem w tym, że prze­kształ­ca­na jest tyl­ko część z nich.

Jeżeli np. do reali­za­cji pro­ce­su fak­tu­ro­wa­nia, na jego wej­ściu potrzeb­ne są dane do fak­tu­ry oraz jej wzór i zna­jo­mość reguł nali­cze­nia podat­ku VAT (sto­sow­na Ustawa) to zwróć­my uwa­gę, że tak napraw­dę prze­kształ­ca­ne są (prze­twa­rza­ne) tyl­ko dane do fak­tu­ry, pozo­sta­łe dane to nie­mo­dy­fi­ko­wa­ne ogra­ni­cze­nia, wie­dza, któ­rą musi posia­dać Wykonawca. Tak wiec np. usta­wa o podat­ku VAT to nie prze­twa­rza­ne wej­ście tego procesu.

Aby pro­ces zaist­niał musi poja­wić się Osoba two­rzą­ca fak­tu­rę czy­li zaso­by, ów Wykonawca z jego wie­dzą i narzę­dzia­mi jaki­mi dys­po­nu­je. W efek­cie model nie­co się posze­rza: wej­ście, wyj­ście (dane do fak­tu­ry), pro­ces (jak powsta­je fak­tu­ra np. eta­py zatwier­dza­nia), zaso­by (oso­ba fak­tu­ru­ją­ca i narzę­dzia któ­rych uży­wa do tego), regu­ły (wewnętrz­ne pro­ce­du­ry oraz prawo).

Reguły roz­bi­ja­my na dwie czę­ści: regu­ły biz­ne­so­we (wewnętrz­ne pro­ce­du­ry i zarzą­dze­nia) oraz pra­wo czy­li ogra­ni­cze­nia zewnętrz­ne. Jaki cel przy­świe­ca takie­mu podzia­ło­wi? Wydzielenie spe­cy­fi­ki bada­nej orga­ni­za­cji. Jej spe­cy­fi­ka tkwi w wewnętrz­nych pro­ce­du­rach i zarzą­dze­niach a nie w mapie pro­ce­sów, ta jest raczej wewnętrz­nym łań­cu­chem war­to­ści (któ­ry nie powi­nien być zbyt skomplikowany).

Jeżeli chce­my ?odkryć? źró­dła prze­wa­gi ryn­ko­wej musi­my zde­fi­nio­wać to, co odróż­nia nas od kon­ku­ren­cji. Co to jest? Posiadane zaso­by i regu­ły biznesowe.

Tak opi­sa­ny model moż­na zobra­zo­wać w nota­cji BPMN:

Każdy pro­ces jest ini­cjo­wa­ny jakimś zda­rze­niem, w szcze­gól­no­ści poja­wie­niem się doku­men­tu do obsłu­że­nia np. Zamówieniem. Wyjście to pro­dukt tej pra­cy np. Faktura. I tyl­ko to pod­le­ga prze­twa­rza­niu. Reszta danych wyma­ga­nych” to nie wej­ście pro­ce­su a jego ogra­ni­cze­nia w posta­ci: aktów praw­nych, pro­ce­dur, zarzą­dzeń wewnętrz­nych (reguł biz­ne­so­wych). Proces koń­czy się zda­rze­niem: Dane wyj­ścio­we wytwo­rzo­no”, jest to mani­fe­sta­cja”. W czym rzecz? otóż jeże­li pro­ces się skoń­czył: fak­tu­ra VAT zosta­ła wytwo­rzo­na ale do cza­su gdy nikt się o tym nie dowie (pro­dukt pro­ce­su nie zosta­nie dostar­czo­ny klien­to­wi lub nie zosta­nie od o tym poin­for­mo­wa­ny), pro­ces for­mal­nie trwa. To dla­te­go mówi się o BPMN (i o natu­rze pro­ce­sów) że są ste­ro­wa­ne zda­rze­nia­mi. Aktów praw­nych defi­nio­wać nie trze­ba, pro­ce­du­ra to okre­ślo­ny, narzu­co­ny spo­sób wyko­na­nia kon­kret­nej czyn­no­ści, regu­ła biz­ne­so­wa to ogra­ni­cze­nie doty­czą­ce całej orga­ni­za­cji (wię­cej o regu­łach w poprzed­nich wpi­sach).

Jaki z tego wnio­sek? Skuteczne zarzą­dza­nie, z peł­nym zro­zu­mie­niem skut­ków, wyma­ga mode­lu, któ­ry poka­że nam czym dys­po­nu­je­my, w czym jeste­śmy (chce­my być) lep­si i na co nie mamy wpły­wu, czy­li z czym wal­czy­my i my i kon­ku­ren­cja jednakowo.

Na tym eta­pie Analityk Biznesowy może dać mene­dże­rom dobry model biz­ne­so­wy symu­lu­ją­cy mode­lo­wa­ną orga­ni­za­cję, pod­sta­wę do podej­mo­wa­nia decy­zji organizacyjnych.

Co jeszcze?

Zasoby to coś, bez cze­go żad­na orga­ni­za­cja nie jest w sta­nie funk­cjo­no­wać. Wśród nich są ludzie i narzę­dzia pra­cy, któ­rych uży­wa­ją. Model ICOM trak­tu­je zaso­by ogól­nie, w BPMN zosta­ły one ukry­te” w posta­ci abs­trak­cji jaką jest rola (lub wyko­naw­ca). Wykonawca gru­pu­je” w sobie nie­zbęd­ną wie­dzę, umie­jęt­no­ści, narzę­dzia i mate­ria­ły potrzeb­ne do wyko­na­nia Czynności (dla­te­go obec­nie jako poważ­ny błąd postrze­gam mode­lo­wa­nie opro­gra­mo­wa­nia (Systemu) jako toru w pro­ce­sie, System to nie rola a narzę­dzie pra­cy no chy­ba, że mowa o robotach ;)).

Wśród tych narzę­dzi mogą być kom­pu­te­ry, a kon­kret­nie opro­gra­mo­wa­nie, któ­re wspie­ra Wykonawcę w reali­za­cji wybra­nych Czynności. Skoro tak, to opro­gra­mo­wa­nie po pro­stu świad­czy usłu­gi swo­im użyt­kow­ni­kom ([[model usłu­go­wy sys­te­mu informatycznego]]).

Tak rozu­mia­ne ?usłu­gi? to nic inne­go jak wyma­ga­nia na opro­gra­mo­wa­nie. Z uwa­gi na to, że wyma­ga­nia te dzie­li­my na usłu­gi (reali­za­cja wspar­cia jakiejś logi­ki biz­ne­so­wej) oraz jakość jej reali­za­cji, wyma­ga­nia dzie­li­my na funk­cjo­nal­ne oraz jako­ścio­we (poza-funk­cjo­nal­ne).

Systemy i oprogramowanie

Dotykamy tu więc opro­gra­mo­wa­nia np. sys­te­mów ERP, CRM, EOD (elek­tro­nicz­ny obieg doku­men­tów) lub dedy­ko­wa­ne­go (w zasa­dzie zawsze mamy do czy­nie­nia z sys­te­ma­mi dedy­ko­wa­ny­mi jeże­li tyl­ko pla­no­wa­na jest jaka­kol­wiek ich kastomizacja).

Na tym eta­pie powi­nien powstać pro­jekt archi­tek­tu­ry sys­te­mu. Wystarczy się rozej­rzeć wokół sie­bie by prze­ko­nać się, że mamy wokół wie­le róż­ne­go opro­gra­mo­wa­nia. Między baj­ki moż­na wło­żyć tezę, o jed­nym wiel­kim pakie­cie zin­te­gro­wa­nym ? nikt takie­go nie ma (tyl­ko jed­ne­go). To co nazy­wa­my Systemem Informatycznym to tak na praw­dę pakiet opro­gra­mo­wa­nia od róż­nych, mniej lub bar­dziej wyspe­cja­li­zo­wa­nych dostaw­ców. Integracja poszcze­gól­nych ele­men­tów tego pakie­tu (lub brak tej inte­gra­cji) zale­ży od pier­wot­ne­go pla­nu (archi­tek­tu­ry).

Teraz dopie­ro rysu­je się obraz Systemu: wie­le róż­ne­go rodza­ju opro­gra­mo­wa­nia, któ­re wspie­ra róż­nych pra­cow­ni­ków na róż­nych eta­pach ich pra­cy. Czy da się to opi­sać nie mając opi­sa­ne­go wyżej mode­lu biznesowego?

Czym jest piąty element?

To abs­trak­cja jaką jest pro­ces biz­ne­so­wy. Mało któ­ra fir­ma ma mode­le pro­ce­sów a każ­da jakoś ist­nie­je! Można żyć bez map pro­ce­sów, strasz­ne! Co więc ofe­ru­ją fir­my dorad­cze sprze­da­ją­ce” mapo­wa­nie pro­ce­sów biz­ne­so­wych? Nie wiem.

Sedno spo­so­bu pra­cy orga­ni­za­cji to regu­ły biz­ne­so­we. One rzą­dzą tym, co jest wyko­ny­wa­ne i jak. Proces (to jak jest wyko­ny­wa­na pra­ca) to abs­trak­cja, efekt ist­nie­nia ogra­ni­czeń (w tym wła­śnie reguł biz­ne­so­wych). Tak wiec moż­na zarzą­dzać fir­mą nie mając mode­li pro­ce­sów podob­nie jak moż­na miesz­kać w mie­ście nie mając jego planu.

W czym pro­blem? Bez mapy” nie rozu­mie­my wie­lu zja­wisk mimo, że wystę­pu­ją. Jednak przy­dat­ny model biz­ne­so­wy to model pro­ce­sów powią­za­ny z pozo­sta­ły­mi czte­re­ma skład­ni­ka­mi opi­su orga­ni­za­cji (ludzie, pra­wo, wewnętrz­ne zarzą­dze­nia i procedury).

Model biz­ne­so­wy to nie są dzie­siąt­ki i set­ki nie­czy­ta­nych dia­gra­mów, poka­zu­ją­cych szcze­gó­ło­wo to co robią pra­cow­ni­cy, bo mogą to robić na nie­skoń­cze­nie wie­le spo­so­bów (tą meto­dą pro­jekt mapo­wa­nie pro­ce­sów nie ma koń­ca!). Istotne jest to co powsta­je, po co i dla­cze­go aku­rat tak.

Na zakoń­cze­nie: np. model pra­cy ope­ra­cyj­nej każ­de­go urzę­du moż­na kom­plet­nie opi­sać jed­nym dia­gra­mem. Jeżeli chcesz na praw­dę poznać swo­ją fir­mę, opra­cuj jej model. Ale nie w posta­ci setek dia­gra­mów będą­cych suchym zapi­sem wywiadu.

Rozłóż fir­mę na czyn­ni­ki pierw­sze i zro­zum ją. Bez tego nie zarzą­dzasz a pró­bu­jesz zarządzać!

Wykonaj sfor­ma­li­zo­wa­ny nota­cja­mi i słow­ni­kiem pojęć, audyt fir­my, spo­so­bu funk­cjo­no­wa­nia i zro­zum jak na praw­dę dzia­ła. O wspól­nym słow­ni­ku pojęć biz­ne­so­wych, pod­sta­wą budo­wy reguł biz­ne­so­wych, innym razem.