W 2005 roku napi­sa­łem dosyć radykalnie:

Jedną z pro­stych metod oce­ny wyko­na­nej mapy pro­ce­sów biz­ne­so­wych jest spraw­dze­nie czy dia­gram zawie­ra sym­bo­le decy­zyj­ne (z regu­ły są to rom­by z odno­śni­ka­mi tak/nie). Jeżeli są, to nie jest to model pro­ce­sów! Diagramy ze ścież­ka­mi decy­zyj­ny­mi to pro­ce­du­ry a nie pro­ce­sy. Cechą cha­rak­te­ry­stycz­ną pro­ce­su w biz­ne­sie jest jego obli­ga­to­ryj­ność i jed­no­znacz­ność. Czyli jeże­li uzna­je­my, że dany pro­ces w fir­mie jest to zna­czy, że jest a przed­mio­tem dys­ku­sji może być jego wewnętrz­na organizacja.

Przykład. Wykonujemy model Urzędu. Załóżmy, że jed­nym z celów funk­cjo­no­wa­nia tego Urzędu jest wyda­wa­nie decy­zji o malo­wa­niu tra­wy (Process). Na wej­ściu (Inputs) będzie proś­ba peten­ta (wraz z wyma­ga­ny­mi załącz­ni­ka­mi) o wyda­nie decy­zji a na wyj­ściu (Outputs) wyda­na decy­zja. Sposób podej­mo­wa­nia decy­zji okre­śla pro­ce­du­ra i aktu­al­ny stan praw­ny (Constraints). Zasobem nie­zbęd­nym jest kom­pe­tent­ny pra­cow­nik (Resources). Decyzja jest zawsze, może zaś być pozy­tyw­na lub nega­tyw­na. Nie ma tu mowy o tym czy decy­zja jest w ogó­le wyda­wa­na bo JEST. Tak więc pro­ces jest zawsze, jego wynik może być róż­ny. Na popraw­nej mapie pro­ce­sów dla tego urzę­du będzie więc mię­dzy inny­mi sym­bol tego pro­ce­su ale żad­nych ?rom­bów?. (pole­cam lek­tu­rę całe­go arty­ku­łu Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Nie raz spo­ty­ka­łem się kry­ty­ką tej tezy, no bo jak to, ma nie być rom­bów decy­zyj­nych w pro­ce­sie”? Otóż od daw­na jestem zwo­len­ni­kiem mode­lo­wa­nia z uży­ciem reguł biz­ne­so­wych i sepa­ro­wa­nie ich od mode­lu pro­ce­su. Na stro­nie Business Rules Group publi­ko­wa­ny jest mię­dzy inny­mi tak zwa­ny Business Rules Manifesto (Manifest Reguł Biznesowych, jest tak­że do pobra­nia wer­sja pol­ska), któ­ry zawie­ra mię­dzy inny­mi defi­ni­cję reguł biznesowych:

Artykuł 2. [regu­ły biz­ne­so­we są ] Oddzielone od pro­ce­sów, a nie zawie­ra­ją­ce się w nich. 2.1. Reguły są bez­po­śred­ni­mi ogra­ni­cze­nia­mi narzu­co­ny­mi na funk­cjo­no­wa­nie orga­ni­za­cji jak rów­nież mogą sta­no­wić wspar­cie dla jej funk­cjo­no­wa­nia. 2.2. Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi. Nie powin­ny być w nich zawar­te. 2.3. Reguły mają zasto­so­wa­nie ponad i pomię­dzy pro­ce­sa­mi i pro­ce­du­ra­mi. Powinny sta­no­wić jeden spój­ny orga­nizm, sto­so­wa­ny kon­se­kwent­nie w odpo­wied­nich obsza­rach aktyw­no­ści biznesowej.

Definicja pro­ce­su, któ­rą nie raz tu przytaczałem:

Proces to prze­kształ­ce­nie wej­ścia w wyj­ście, z uży­ciem pew­nych zaso­bów w obec­no­ści pew­nych ograniczeń.

Proces biz­ne­so­wy to powyż­sze, wzbo­ga­co­ne o „… gdzie wyj­ście (pro­dukt) pro­ce­su sta­no­wi dla odbior­cy więk­szą war­tość w sto­sun­ku do jego wejścia”.

Metod mode­lo­wa­nia pro­ce­sów jest wie­le, ja uży­wam nota­cji BPMN. Jest to dobrze opi­sa­ny sys­tem poję­cio­wy i wygod­ny w sto­so­wa­niu. Z pomo­cą nota­cji BPMN moż­na mode­lo­wać pro­ce­sy na dowol­nym pozio­mie abs­trak­cji. Notacja ta powsta­ła i jest roz­wi­ja w celu opi­su pro­ce­sów wyko­ny­wal­nych, jed­nak to zasto­so­wa­nie nazwał bym mimo wszyst­ko niszo­wym. System poję­cio­wy BPMN jed­nak dosko­na­le nada­je się do mode­lo­wa­nia na wyż­szym, niż wyko­na­nie, pozio­mie abstrakcji.

Zanim poka­żę przy­kład, przy­to­czę inny popu­lar­ny obra­zek”, a mia­no­wi­cie struk­tu­rę pira­mi­dy obra­zu­ją­cą trzy pozio­my mode­lo­wa­nia orga­ni­za­cji. Żeby nie było nud­no nie będzie to mój dia­gram, zna­ny z poprzed­nich moich wpi­sów na tym blo­gu, a model a zapo­ży­czo­ny ze stro­ny Business Process Trends. Robię to celo­wo, by zwró­cić uwa­gę na to, że to powszech­nie przy­ję­ty podział, spo­ty­ka­ny tak­że u kla­sy­ków reor­ga­ni­za­cji Rumllera i Brache’a i Rogera Burltona.

Model ze stron BPTrends ma nastę­pu­ją­cą postać:

źr. Busnes Process Trends 

Jak widać tu tak­że pro­ces biz­ne­so­wy to abs­trak­cja środ­ko­wej war­stwy. Modele wyko­naw­cze to cią­gi czyn­no­ści reali­zo­wa­nych przez ludzi (nie koniecz­nie z pomo­cą sys­te­mu kom­pu­te­ro­we­go, tak­że pro­ce­du­ral­ne). Na naj­niż­szym pozio­mie mamy ludzi, ich wie­dzę i umie­jęt­no­ści (pra­ca i szcze­gó­ło­wość jej opi­su zale­ży od wie­dzy i umie­jęt­no­ści wyko­naw­cy). Mamy tak­że IT bo pro­ce­sy wyko­ny­wal­ne (ich mode­le) mogą być imple­men­to­wa­ne w sys­te­mach workflow.

Proces biz­ne­so­wy, nie pro­ce­du­ra i nie opis prze­pły­wu pra­cy, to pro­sty ciąg czyn­no­ści, któ­rych celem jest kon­kret­ny rezul­tat: pro­dukt pro­ce­su (jego wyj­ście). Tu pomi­nę doku­men­ty (pro­duk­ty czyn­no­ści) by upro­ścić diagram.

Proces ma cel, sta­no­wi pro­sty łań­cuch pra­cy wyko­naw­cy (Rola), radzi sobie z wyda­rze­nia­mi utrud­nia­ją­cy­mi”. Główny ciąg (ocze­ki­wa­ny) zazna­czo­no sza­ra strzał­ką. Pozostałe atrak­cje” to czyn­no­ści wymu­szo­ne pew­ny­mi nie ocze­ki­wa­ny­mi (a raczej nie chcia­ny­mi), ale prze­wi­dzia­ny­mi zda­rze­nia­mi. Tu nie ma rom­bów”, bra­mek decy­zyj­nych bo one są cechą pro­ce­sów decy­zyj­nych”, pro­ce­dur, a te to regu­ły biz­ne­so­we i wie­dza o biz­ne­sie” a nie pro­ces biz­ne­so­wy. Pewne czyn­no­ści mogą być ogra­ni­czo­ne Procedurą, któ­ra mówi, że tyl­ko tak wol­no tę pra­cę wykonać”.

Kilka lat temu na jed­nej z kon­fe­ren­cji, opi­sy­wa­łem zakres pra­cy nad wdro­że­niem sys­te­mu ERP:

Analiza i zakres pro­jek­tu to opis stra­te­gii. Jest to głów­ny, sta­ły ele­ment pro­jek­tu: stra­te­gia fir­my musi być usta­lo­na przed jakim­kol­wiek pro­jek­tem wdra­ża­nia zmian. Procesy biz­ne­so­we opi­su­ją jak to robi­my. Tu jest miej­sce na ewen­tu­al­ne opty­ma­li­za­cje (mody­fi­ka­cje wewnątrz łań­cu­cha war­to­ści. I najważniejsze:

Opracowywanie wyma­gań to pla­no­wa­nie zmian. Nie ma sen­su spi­sy­wa­nie szcze­gó­łów tej pra­cy, jeże­li wdra­ża­ne zmian spo­wo­du­je powsta­nie np. nowych pro­ce­dur, wyni­ka­ją­cych z celu pro­jek­tu. Zupełnie wystar­czy posia­da­nie wie­dzy o pro­ce­sach i ich pro­duk­tach (co i po co robi­my). To jak one będą powsta­wa­ły (w jaki spo­sób) będzie efek­tem wdro­że­nia np. nowe­go sys­te­mu ERP i ist­nie­ją­cych ogra­ni­czeń, reguł biznesowych.

Kluczem jest posia­da­nie spe­cy­fi­ka­cji reguł biz­ne­so­wych i mode­lu pro­ce­sów na opi­sa­nym środ­ko­wym” poziomie.

Reguły biz­ne­so­we to wewnętrz­ne (np. zarzą­dze­nia) lub zewnętrz­ne (pra­wo) ogra­ni­cze­nia. Na poprzed­nim dia­gra­mie poja­wia się rola czy­li wyko­naw­ca (tu rola dzia­łu HR – opis kom­pe­ten­cji pra­cow­ni­ków czy­li spe­cy­fi­ka­cja ról), Wykonawca posia­da nie­zbęd­ną wie­dzą i umie­jęt­no­ści, potra­fi obsłu­gi­wać maszy­ny” (tak­że opro­gra­mo­wa­nie). Tak więc defi­ni­cja mówią­ca, że pro­ces wyko­nu­je się w śro­do­wi­sku ogra­ni­czeń i wyma­ga zaso­bów tak wła­śnie wyglą­da: zaso­by to ludzie (role), ich wie­dza i narzę­dzia pra­cy, ogra­ni­cze­nia to regu­ły biz­ne­so­we i procedury.

To, opi­sa­ne tu podej­ście, to jed­no z moż­li­wych podejść. Praktyka poka­zu­je, że rzad­ko sto­so­wa­ne (wyma­ga doświad­czo­nych kon­sul­tan­tów i zna­jo­mo­ści tych metod pra­cy) ale też naj­sku­tecz­niej­sze. Modele pro­ce­sów są rela­tyw­nie pro­ste, sztu­ką takiej ana­li­zy jest wyod­ręb­nie­nie reguł biz­ne­so­wych. Co otrzy­ma­my? Biznesowy know-how – naj­cen­niej­szą rzecz w fir­mie. I po to war­to wyko­nać ana­li­zą biz­ne­so­wą: poznać i udo­ku­men­to­wać swo­ją prze­wa­gę czy­li fir­mo­we know-how.

Jeżeli wple­cie­my regu­ły biz­ne­so­we i pro­ce­du­ry w model (mapy) pro­ce­sów, to po pierw­sze powsta­ną wiel­kie i trud­ne w odbio­rze dia­gra­my a po dru­gie zatra­ci­my (ukry­je­my w gąsz­czu obiek­tów na dia­gra­mie) całą war­tość fir­my czy­li jej nagro­ma­dzo­ną wie­dzę. Po trzecie…

… pro­jek­ty zwią­za­ne z wyma­ga­nia­mi na opro­gra­mo­wa­nie to defi­nio­wa­nie wyma­gań na narzę­dzie pra­cy. Jeżeli nie będzie moż­li­we, czy nawet łatwe, wyod­ręb­nie­nie tego co musi umieć czło­wiek a co powi­nien robić pro­gram, pro­jekt cze­ka­ją kło­po­ty bo będzie to odkry­wa­ne dopie­ro w trak­cie wdro­że­nia – a to bar­dzo kosz­tow­na metoda.

Jarosław Żeliński

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

Ten post ma 2 komentarzy

  1. Adam S

    Autorze,

    Notacja BPMN jed­no­znacz­nie iden­ty­fi­ku­je pro­cess jako zestaw/sekwencje Czynnosci (Activities) maja­cych na celu wyko­na­nie pra­cy. Graficzna repre­zen­ta­cja Procesu pbej­mu­je Elementy Przeplywu (Flow Objects), takie jak Czynnosci, Zdarzenia, Bramki Decyzyjne.

    W tym kon­tek­scie ogra­ni­cze­nie w posta­ci wyeli­mi­no­wa­nia bra­mek decy­zyj­nych z pro­ce­su jest chy­ba nad­mier­nym uproszczeniem?
    Osobiscie podo­ba mi sie bar­dzo Panskie podej­scie do pro­ble­mu – pro­cess ma wej­scie I wyj­scie, pomie­dzy kto­ry­mi naste­pu­je prze­ksztal­ce­nie, ogra­ni­cza­ne zaso­ba­mi I regu­la­mi, kto­re jes szcze­gol­nie przy­dat­ne w fir­mie o pro­fi­le dzia­lal­no­sci jak w kto­rej pra­cu­je. Ale stwa­rza tez problem…

    Pozwole sobie uzyc przy­kla­du (ogol­ne­go): w mojej fir­mie jeden z glow­nych pro­ce­sow biz­ne­so­wych – Obsluga klien­ta indy­wi­du­al­ne­go naby­wa­ja­ce­go okre­slo­ny pro­dukt – moze miec czte­ry roz­ne wyni­ki. Jeden z nich zale­zy od wyni­ku spraw­dze­nia GLOWNEGO AKTORA (Klienta, czy­li czy mozna z nim w ogo­le robic inte­res), pozo­sta­le zale­za od dostar­czo­nej infor­ma­cji LUB zda­rzen zewnetrz­nych (deter­mi­nu­ja czy klient zosta­nie obcia­zo­ny kon­co­wa plat­no­scia czy nie), oraz kaz­de z nich wyste­pu­je na innym eta­pie reali­zo­wa­nia uslugi.

    W uprosz­cze­niu wygla­da to tak: klient zama­wia uslu­ge, dosta­je wyce­ne i wpla­ca zalicz­ke. Tylko po wpla­cie zalicz­ki naste­pu­je jego wery­fi­ka­cja I jej wynik deter­mi­nu­je kon­ty­nu­owa­nie pro­ce­su lub zwrot zalicz­ki I ter­mi­na­cja uslu­gi. jesli jest pozy­tyw­na obslu­ga trwa dalej – I naste­pu­je pod­pi­sa­nie kon­trak­tu I dal­sza reali­za­cja uslu­gi. Jesli nega­tyw­na klient otrzy­mu­je zwrot I decy­zje odmowna.

    W kon­tek­scie pre­fe­ro­wa­nej defi­ni­cji pro­ces ten jest nie do opi­sa­nia. Chyba…

    Pozdrawiam.

    1. Jaroslaw Zelinski

      Pierwsza waż­na rzecz w ana­li­zie to odróż­nie­nie języ­ka mode­lo­wa­nia (opi­su) od kon­tek­stu tego co jest mode­lo­wa­ne (mode­lo­wa­nie z uży­ciem BPMN to nie opis). Język pol­ski jest bar­dzo boga­ty (jak każ­dy inny mówio­ny), jed­nak np. na spo­tka­niach biz­ne­so­wych nie prze­kli­na­my (ogra­ni­cze­nie swo­bo­dy uży­cia języ­ka), a na nie­któ­rych spo­tka­niach sku­pia­my się z zasa­dy tyl­ko na celu dzia­ła­nia, a nie na roz­wią­zy­wa­niu pro­ble­mów wsze­la­kich” (mimo, że wie­my iż ist­nie­ją). Eliminowanie bra­mek decy­zyj­nych to taki zabieg myślo­wy, któ­re­go celem jest sku­pie­nie się na celu (ścież­ka opty­mi­stycz­na czy­li praw­dzi­wy cel pro­ce­su) biz­ne­so­wym. Owszem jest to uprosz­cze­nie, jego celem jest sku­pie­nie się na pryn­cy­piach dane­go biznesu. 

      W Pana przy­kła­dzie pro­ces jest ini­cjo­wa­ny przez Klienta, wej­ściem jest to cze­go chce (klient mówi co chce, po co przy­szedł). Wyjściem (pro­duk­tem pro­ce­su) jest zapis tego jak się to skoń­czy­ło”, gdyż z natu­ry rze­czy chce­my znać efekt naszej pra­cy. Owe czte­ry zakoń­cze­nia to czte­ry sta­tu­sy jed­ne­go koń­ca pro­ce­su albo po pro­stu treść (infor­ma­cja) tego jak się ten kon­takt klien­ta z nami skoń­czył. Podam pro­sty przy­kład: pro­ces kształ­ce­nia zaczy­na się zaświad­cze­niem o przy­ję­ciu na stud­nia a koń­czy się dyplo­mem. Ten pro­ces ma jeden koniec (pro­dukt), jest nim dyplom, a nie pięć róż­nych koń­ców czy­li moż­li­wych ocen ukoń­cze­nia stu­diów. Owszem, wewnę­trze tego pro­ce­su może być nafa­sze­ro­wa­ne zło­żo­ną logi­ką, jed­nak war­to pamię­tać, że pro­ces biz­ne­so­wy, jego fak­tycz­ny prze­bieg, to efekt reguł biz­ne­so­wych oraz umie­jęt­no­ści wyko­naw­cy. Tak więc pro­ces jaki Pan opi­sał jest jak naj­bar­dziej do opi­sa­nia, wystar­czy nie zapo­mi­nać, że mamy moż­li­wość uży­cia kil­ka pozio­mów abs­trak­cji. Polecam mój nie­daw­ny wpis Sekwencje a pro­ce­sy”.

      Tak więc na ogól­nym pozio­mie każ­dy Pana przy­pa­dek poja­wie­nia się Klienta koń­czy się zawsze jakąś infor­ma­cją o tym jak się to skoń­czy­ło (a to czy pozy­tyw­nie czy nega­tyw­nie wyni­ka z tre­ści takiej infor­ma­cji). To jaki sce­na­riusz w danym przy­pad­ku miał miej­sce, zale­ży od tego w jakich warun­kach się to odby­wa­ło. Niech Pan teraz spoj­rzy na potrze­bę rapor­to­wa­nia sku­tecz­no­ści (jako­ści) obsłu­gi klien­tów: jakie infor­ma­cje będzie Pan agre­go­wał by to oce­nić? Zapewne zro­bi Pan raport (zesta­wie­nie) wszyst­kich infor­ma­cji o tym jak zakoń­czy­ła się każ­da spra­wa klien­ta, a każ­da ma jeden koniec, któ­ry może być albo rezy­gna­cją z obsłu­gi albo reali­za­cją zamó­wie­nia. To się nazy­wa jeden koniec i moż­li­we dwa jego sta­tu­sy. jeże­li uzna Pan, że ma Pan jed­nak czte­ry róż­ne zakoń­cze­nia, jak zro­bi Pan raport efek­tów sprze­da­ży? Co do szcze­gó­łów pole­cam tak­że ten wpis: Gdzie są szczegóły…

Dodaj komentarz

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