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.

Inne artykuły na podobny temat

Komentarze

  1. jacek.wojtkowski 15 maja 2012 at 10:19

    ..cze­go nie ujmo­wać na tych modelach”
    Dobrze powie­dzia­ne. Znajduję tu zbież­ność z poglą­da­mi św.p. Steve J.: Jestem tak samo dum­ny z tego, cze­go nie robi­my, jak z tego, co robimy” 🙂
    „… algo­ryt­mi­za­cja pra­cy ludzi jest nie­ce­lo­wa (wte­dy sto­su­je­my roboty)”
    No cóż… TRUE 🙂

    Pozdrawiam

  2. Marek Kuszneruk 15 maja 2012 at 13:47

    Tak dale­ko posu­nię­te gene­ra­li­zo­wa­nie poję­cia algo­ryt­mi­za­cji pra­cy” uwa­żam za nie­ce­lo­we. Ma to taki sam sens jak powie­dze­nie, że w Europie jest brudno 🙂 .

    • Jarek Żeliński 15 maja 2012 at 13:53

      Hm… przy­znasz chy­ba jed­nak, że gdy samo­dziel­ność pra­cow­ni­ka zmie­rza do zera zakres jego obo­wiąz­ków zbli­ża się do algo­ryt­mu, czy­li algo­ryt­mi­za­cja pra­cy ludzi na swój spo­sób odczło­wie­cza ich. Ja powy­żej chcia­łem zwró­cić uwa­gę na fakt, że tak jest bar­dzo rzad­ko, na tyle rzad­ko, by uznać, że więk­szość mode­li pro­ce­sów, gdzie czło­wiek jest wyko­naw­cą, to mode­le zbyt szcze­gó­ło­we. Model pro­ce­su” na uży­tek pro­jek­to­wa­ne­go opro­gra­mo­wa­nia to co inne­go: to sce­na­riusz reali­za­cji kon­kret­nej usłu­gi dane­go sys­te­mu a to nie to samo.

      Proces biz­ne­so­wy i sce­na­riusz obsłu­gi opro­gra­mo­wa­nia to skraj­nie odręb­ne rzeczy.

  3. Marek Kuszneruk 15 maja 2012 at 14:57

    Jeśli mówi­my o algo­ryt­mi­za­cji to raczej potrak­to­wał­bym ją jako kom­po­nent, któ­ry każ­da fir­ma powin­na zop­ty­ma­li­zo­wać w odnie­sie­niu do wiel­ko­ści, bran­ży czy roli, któ­rej ma doty­czyć. Nie moż­na sto­so­wać jed­na­ko­wej mia­ry do wszyst­kich. Weźmy przy­kład zna­ne­go dostaw­cy ham­bur­ge­rów 😉 . Algorytmizacja zakre­su obo­wiąz­ków w obsłu­dze klien­ta i wśród mena­dże­rów pomi­mo, że to jed­na i ta sama fir­ma, to dwie róż­ne historie.

    • Jarek Żeliński 15 maja 2012 at 21:04

      Osobiście w pro­jek­tach ana­li­tycz­nych roz­róż­niam algo­rytm” imple­men­to­wa­ny w sys­te­mie od pro­ce­du­ry dla pra­cow­ni­ka. To poma­ga oddzie­lić wyma­ga­ne kom­pe­ten­cje pra­cow­ni­ka (nawet bar­dzo niskie) od wyma­gań na opro­gra­mo­wa­nie czy treść zarzą­dze­nia pre­ze­sa, któ­re­go celem jest unik­nię­cie błę­dów. W przy­pad­ku algo­ryt­mu zaim­ple­men­to­wa­ne­go” w sys­tem ERP masz rację. Algorytm wyko­ny­wa­ny przez System ERP a pro­ce­du­ra” powstę­po­wa­nia dla pra­cow­ni­ka to inne algorytmy”. 

  4. Marek Kuszneruk 16 maja 2012 at 08:50

    Zatem jeste­śmy w domu. 

    Swoją dro­gą ile to się cza­sem trze­ba nasta­rać żeby się prze­bić przez nie­jed­no­znacz­ność pojęć. Bardzo cenię ludzi, z któ­ry­mi moż­na swo­bod­nie wejść na ten poziom dys­ku­sji. Dzięki Jarek 🙂 .

  5. Łukasz Mozalewski 17 maja 2012 at 20:40

    Po prze­czy­ta­niu arty­ku­łu, stwier­dzi­łem, że rysu­nek z drzwia­mi ide­al­nie odda­je jego ideę. Znam oso­by, któ­re pod­cho­dzą do tema­tu, na zasa­dzie, zro­bi­my wszyst­ko albo nic. A cza­sa­mi po pro­stu war­to zacząć od cze­goś – ana­li­zy, pozna­nia opi­nii, obser­wa­cji itd. Jednym z naj­częst­szych błę­dów przy wpro­wa­dza­niu zmian jest zakła­da­nie, że orga­ni­za­cja jest goto­wa na zmia­nę, bez uprzed­nie­go spraw­dze­nia jej sta­nu, co zosta­ło ide­al­nie wska­za­ne rów­nież powy­żej. Wszyscy rzu­ca­ją się do opi­su zmia­ny, two­rzą pomy­sły, regu­ły, ale bez zasta­no­wie­nia, czy ta zmia­na rze­czy­wi­ście jest potrzeb­na, czy nie będzie gorzej.

    • Jacek Ledworowski 24 maja 2012 at 09:16

      (…) Jednym z naj­częst­szych błę­dów przy wpro­wa­dza­niu zmian jest zakła­da­nie, że orga­ni­za­cja jest goto­wa na zmia­nę, bez uprzed­nie­go spraw­dze­nia jej sta­nu, co zosta­ło ide­al­nie wska­za­ne rów­nież powy­żej. Wszyscy rzu­ca­ją się do opi­su zmia­ny, two­rzą pomy­sły, regu­ły, ale bez zasta­no­wie­nia, czy ta zmia­na rze­czy­wi­ście jest potrzeb­na, czy nie będzie gorzej.”

      Prawda.
      Również fatal­nym przy­pad­kiem jest taki stan fir­my, w któ­rym doj­rza­łość do zmian i poko­rę osią­ga z chwi­lą upad­ku, gdy już jest za późno.

  6. Porady Prawne 6 czerwca 2012 at 15:28

    Procesy biz­ne­so­we w fir­mie to cięż­kie zagad­nie­nie dla wie­lu przed­się­bior­ców to jedy­nie sytu­acja two­rzą­ca pro­blem, któ­ry wdra­żać nie bar­dzo są skłonni

    • Jarek Żeliński 6 czerwca 2012 at 15:44

      Być może dla­te­go wie­lu z nich ma pro­ble­my ze zro­zu­mie­niem swo­ich wła­snych firm, jak ban­kru­tu­ją to nawet nie rozu­mie­ją dla­cze­go… (poza obwi­nia­niem sytu­acji ryn­ko­wej i polityki”.

  7. Sławomir Niemiec 25 czerwca 2012 at 10:10

    Czytając arty­kuł przy­szedł mi na myśl jeden z wykła­dów Profesora Ryszarda Tadeusiewicza z AGH, zawie­ra­ją­cy nastę­pu­ją­cą pora­dę: Należy pamię­tać mak­sy­mę sta­rych i doświad­czo­nych infor­ma­ty­ków: Komputer nie zmie­nia zna­ku”. Jeśli coś w dzia­ła­niu fir­my i w jej orga­ni­za­cji jest pozy­tyw­ne, to po wpro­wa­dze­niu infor­ma­ty­ki będzie jesz­cze lep­sze. Jeśli jed­nak coś jest nega­tyw­ne, to wpro­wa­dze­nie infor­ma­ty­ki spo­wo­du­je, że te minu­sy uro­sną do mon­stru­al­nych rozmiarów!”

    • Jarek Żeliński 25 czerwca 2012 at 11:45

      Zapewne coś w tym jest jed­nak nie wiem kie­dy ta mak­sy­ma się uro­dzi­ła. Mnie sło­wo kom­pu­ter” abso­lut­nie nie koja­rzy się ze sło­wem sta­bil­ność”, nie licząc może jego mate­rial­nej posta­ci. teza Jeśli coś w dzia­ła­niu fir­my i w jej orga­ni­za­cji jest pozy­tyw­ne, to po wpro­wa­dze­niu infor­ma­ty­ki będzie jesz­cze lep­sze” zakła­da z góry wdro­że­nie popraw­ne­go roz­wią­za­nia” co by to nie mia­ło zna­czyć. Ja nie­ste­ty sys­te­ma­tycz­nie spo­ty­kam przy­pad­ki, gdzie dobrze dzia­ła­ją­ca orga­ni­za­cja po wdro­że­niu infor­ma­ty­ki zaczy­na kuleć.… to by zna­czy­ło, że zain­we­sto­wa­li w nie­po­praw­ne rozwiązanie”…

      A jakie jest poprawne? 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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