Co jakiś czas poja­wia­ją się w zapy­ta­niach ofer­to­wych lub dla odmia­ny w publi­ka­cjach róż­ne meto­dy mode­lo­wa­nia lub opi­su pro­ce­sów, w tym dość popu­lar­ne RACI i SIPOC. Kilka słów o tych meto­dach”, wyja­śnij­my na począ­tek owe skróty.

RACI

Akronim od angiel­skich słów: Responsible, Accountable, Consult, Inform. Oznaczają kolejno:

  • R?Responsible, to oso­ba odpo­wie­dzial­na za reali­za­cję (wyko­na­nie) zada­nia i jego produkt,
  • A?Accountable to oso­ba mają­ca obo­wią­zek zatwier­dze­nia powsta­łe­go pro­duk­tu, moż­li­we jest to tak­że wyko­naw­ca, np. doty­czy to czę­sto prac specjalistycznych, 
  • C?Consult, to oso­ba posia­da­ją­ca wie­dzę mery­to­rycz­ną o przed­mio­cie zada­nia, jest eks­per­tem dzie­dzi­no­wym, jest to oso­ba dostęp­na na żądanie, 
  • I?Informed, to oso­ba, któ­ra jest infor­mo­wa­na o wytwo­rze­niu pro­duk­tu zada­nia (ukoń­cze­niu zadania),

Powyższy sche­mat opi­su zada­nia (aktyw­no­ści) jest dość czę­sto spo­ty­ka­ny w pro­jek­tach powią­za­nych z pro­ce­so­wy­mi sys­te­ma­mi zarzą­dza­nia jako­ścią. Czy to jakiś model? Nie, pro­ce­sy (czyn­no­ści) musi­my wyspe­cy­fi­ko­wać jaką­kol­wiek meto­dą (model) by tę macierz RACI stwo­rzyć. Wygląda np. tak:

Problemem macie­rzy RACI jest ich czę­ste sto­so­wa­nie bez mode­lu pro­ce­sów. W efek­cie są one nie­we­ry­fi­ko­wal­ne (pozo­sta­ją jedy­nie dekla­ra­cją). Macierz RACI jest bar­dzo przy­dat­na jako wspar­cie np. dla mode­lu pro­ce­sów, gdyż poka­za­nie tych zależ­no­ści w posta­ci macie­rzy jest znacz­nie wygod­niej­sze niż na dia­gra­mie w posta­ci przepływów.

SIPOC

SIPOC to akro­nim od angiel­skich słów: Supplier, Input, Process, Output, Customer, kolej­no ozna­cza­ją one:

  • Supplier (S), czy­li Dostawca ? ozna­cza pod­miot, któ­ry dostar­cza infor­ma­cje, zaso­by do reali­zo­wa­ne­go procesu.
  • Input (I), czy­li zaso­by wej­ścio­we ? ozna­cza infor­ma­cje, zaso­by dostar­cza­ne przez Dostawcę.
  • Process ℗, czy­li pro­ces (defi­ni­cja wyżej)
  • Output (O), czy­li efekt wyj­ścio­wy ? ozna­cza infor­ma­cje, zaso­by dostar­cza­ne przez proces.
  • Customer ©, czy­li klient ? ozna­cza pod­miot, któ­ry otrzy­mu­je efekt wyjściowy.

Diagram SIPOC jest pro­stym w uży­ciu narzę­dziem słu­żą­cym do opi­su pro­ce­su wraz z jego oto­cze­niem biz­ne­so­wym. Diagram SIPOC opi­su­je dostaw­ców, wej­ścia, w stop­niu ogól­nym prze­bieg pro­ce­su, wyj­ścia (pro­duk­ty) oraz odbior­ców. Odpowiada to akro­ni­mo­wi od Supplier, Inputs, Process, Outputs, Customer.

Diagram SIPOC czę­sto roz­bu­do­wy­wa­ny jest o dwa kolej­ne obsza­ry: zaso­by nie­zbęd­ne do zre­ali­zo­wa­nia pro­ce­su oraz regu­ły (regu­la­cje praw­ne) rzą­dzą­ce pro­ce­sem czy­li Resources oraz Rules. Zasoby i regu­ły mogą być dzie­lo­ne w zależ­no­ści od potrzeb, np. regu­ły ? zewnętrz­ne i wewnętrz­ne regu­la­cje praw­ne, zaso­by ? np. pra­cow­ni­cy i sys­te­my IT. (źr. http://www.e‑sixsigma.pl/index.php?option=com_content&task=view&id=27&Itemid=1)

Przykład doku­men­tu:

Jak widać sam spis zawie­ra wie­le pozy­cji w kolum­nach (szcze­gól­nie wej­ście i wyj­ście), co nie nie uła­twia odtwo­rze­nia pro­ce­su i jego moż­li­wych sce­na­riu­szy, model pro­ce­su i tak musi powstać. Tu ana­lo­gicz­nie: sama lista SIPOC jest dekla­ra­cją, sama – dekla­ra­tyw­nie – stwo­rzo­na lista pro­ce­sów jest bar­dzo ryzy­kow­na. Lista pro­ce­sów end-2-end (po wstęp­nej ana­li­zie stra­te­gii) w posta­ci nap. tabe­li lub mode­li SIPOC ma już sens. (patrz tak­że )

Proces

Po raz kolej­ny posłuż­my się pod­sta­wo­wą defi­ni­cją pro­ce­su ICOM i jej gra­ficz­nym modelem:

Proces biz­ne­so­wy to czyn­ność lub łań­cuch powią­za­nych czyn­no­ści, prze­kształ­ca­ją­cych wej­ście (Inputs) w wyj­ście (Outputs). Proces wyma­ga okre­ślo­ne­go dzia­ła­nia i zaso­bów (Mechanism/Resources) a swo­bo­da jego reali­za­cji może być ste­ro­wa­na i/lub ogra­ni­czo­na (Controll/Constraints)”. Powyższy dia­gram obra­zu­je defi­ni­cję, nie jest ele­men­tem żad­nej nota­cji (sta­no­wi jed­nak pier­wo­wzór nota­cji [[IDEF0]]).

Jeżeli uznać, że dane wej­ścio­we ktoś dostar­cza a wyj­ścio­we ktoś odbie­ra oka­zu­je się, że SIPOC to nic inne­go, jak opi­so­wy (tabe­la­rycz­ny) spis pro­ce­sów, rodzaj inwen­ta­ry­za­cji. Lista taka nie daje żad­ne­go narzę­dzia pozwa­la­ją­ce­go na stwier­dze­nie (wery­fi­ka­tor), że nicze­go nie pomi­nię­to. Deklaracja auto­rów takiej listy pozo­sta­je nie­we­ry­fi­ko­wal­na. Sam pro­ces, dla wery­fi­ka­cji, i tak wyma­ga opi­sa­nia (mode­lo­wa­nia). Tak więc SIPOC jako narzę­dzie opi­su – tak, jako spo­sób mode­lo­wa­nia”, raczej nie.

Macierz RACI uży­ta jako meto­da opi­su wymu­sza­ją­ca czte­ry atry­bu­ty dla każ­de­go pro­ce­su ma pew­ną wadę: nie dla każ­de­go pro­ce­su lub czyn­no­ści da się (lub ma sens) defi­nio­wa­nie takiej czwór­ki atry­bu­tów” a robie­nie tego obli­ga­to­ryj­nie, pro­wa­dzi nie raz do powsta­nia znacz­ne­go nad­mia­ru w doku­men­ta­cji. Bardzo czę­sto two­rzo­ne są sztucz­ne, nie­ist­nie­ją­ce zależ­no­ści (one ist­nie­ją cza­sem warun­ko­wo np. kon­sul­ta­cje moż­na ale nie trze­ba pro­wa­dzić). Twierdzenie, że powin­ny być zde­fi­nio­wa­ne wszyst­kie dla każ­de­go pro­ce­su jest trud­ne do obro­ny. Jednak RACI jako uzu­peł­nie­nie wie­dzy o pro­ce­sie, bez obo­wiąz­ku dekla­ro­wa­nia wszyst­kich czte­rech ról dla każ­de­go pro­ce­su, jak naj­bar­dziej ma sens.

Popatrzmy teraz na ten model:

Obrazuje on czte­ry role RACI. Warto zwró­cić uwa­gę, na fakt, że mamy tu 12 moż­li­wych sce­na­riu­szy przej­ścia (pro­po­nu­ję zaba­wę w spraw­dze­nie tego :)). Uznanie, że przy­pad­ków kon­sul­ta­cji może być wię­cej niż jeden pro­wa­dzi do znacz­nie więk­szej ilo­ści sce­na­riu­szy a dia­gram ten urósł by do jakichś mon­stru­al­nych roz­mia­rów. (patrz tak­że )

Jak widać więc i tak nie opi­su­je wszyst­kie­go co może się wyda­rzyć a powi­nien, jeśli ma być nazwa­ny mode­lem jakiejś rzeczywistości.

To jest moment, któ­ry nazy­wam utra­tą pano­wa­nia nad zło­żo­no­ścią pro­ble­mu i pro­jek­tu mode­lo­wa­nie pro­ce­sów biz­ne­so­wych”. Jest to cecha wie­lu mode­li (doku­men­tów), któ­re otrzy­mu­ję do audy­tu. Powyższy dia­gram to tyl­ko jeden pro­sty pro­ces, a wyobraź­my sobie pró­bę opi­sa­nia w ten spo­sób nawet czę­ści np. Państwa orga­ni­za­cji. Będą to dzie­siąt­ki zło­żo­nych, ogrom­nych dia­gra­mów, prak­tycz­nie do nicze­go nie przy­dat­nych, gdyż spraw­ne posłu­gi­wa­nie się nimi jest nie­mal­że nie­moż­li­we. Do tego każ­da, nawet drob­na zmia­na spo­so­bu dzia­ła­nia, pocią­gnie za sobą potrze­bę zmo­dy­fi­ko­wa­nia znacz­nej czę­ści tej doku­men­ta­cji a to koszt porów­ny­wal­ny nie raz z jej wytworzeniem.

Przypomnę jesz­cze raz defi­ni­cję ICOM: wej­ście, ogra­ni­cze­nia, mecha­nizm i zaso­by, wyj­ście. W środ­ku jest to co i jak robią” zaso­by: pro­ces. Otóż zaso­by to ludzie i ich narzę­dzia, to co i jak robią to kom­pe­ten­cje. Są opi­sa­ne np. w opi­sie zaj­mo­wa­ne­go sta­no­wi­ska. Jeżeli coś musi się wyda­rzyć lub nie może się wyda­rzyć, to regu­lu­ją to ogra­ni­cze­nia, są nimi pro­ce­du­ry i regu­ły biz­ne­so­we. Są to osob­ne doku­men­ty, któ­re mogą się czę­sto zmieniać.

Proces biz­ne­so­wy w opi­sa­nej kon­wen­cji poję­cio­wej ICOM moż­na przed­sta­wić tak (nota­cja BPMN, sym­bol Reguły biz­ne­so­wej to notat­ka, nie jest ele­men­tem notacji):

Tak więc mamy: wej­ście i wyj­ście, tu treść ini­cju­ją­ca spra­wę i doku­men­ty koń­czą­ce. Mamy ogra­ni­cze­nie czy­li regu­łę biz­ne­so­wą. Dodatkowym ogra­ni­cze­niem może być pro­ce­du­ra, czy­li narzu­co­ny wyko­naw­cy spo­sób (recep­ta) postę­po­wa­nia. Mamy zaso­by w posta­ci Wykonawcy: oso­by odpo­wie­dzial­nej za wyko­na­nie i za pro­dukt pro­ce­su (Dokument koń­czą­cy). Rola repre­zen­tu­je wszel­kie wyma­ga­ne umie­jęt­no­ści, w tym umie­jęt­ność uży­cia narzę­dzi (tak­że opro­gra­mo­wa­nia), ewen­tu­al­ną zna­jo­mość pra­wa i wewnętrz­nych zarzą­dzeń regu­lu­ją­cych pra­cę, Czynność na dia­gra­mie może mieć przy­po­rząd­ko­wa­ne okre­ślo­ne atry­bu­ty RACI (nie zawsze wszyst­kie) . To opi­su­je zakres kom­pe­ten­cji Wykonawcy (nie poka­za­ny na dia­gra­mie, to osob­ny doku­ment kadro­wy). Powyższy dia­gram poka­zu­je sens pro­ce­su, czyn­no­ści może być oczy­wi­ście wię­cej na dia­gra­mie, jed­nak to będą czyn­no­ści wno­szą­ce war­tość w pro­ce­sie powią­za­ne z ewen­tu­al­ny­mi pro­ce­du­ra­mi i regu­ła­mi biz­ne­so­wy­mi. Ich ist­nie­nie lub nie oraz treść, to decy­zje zarząd­cze. Tak zde­fi­nio­wa­ny pro­ces opi­su­je w spo­sób kom­plet­ny spe­cy­fi­kę fir­my. Modelowanie kom­pe­ten­cji i pro­ce­dur na mode­lach (poprzed­ni dia­gram) trak­tu­ję jako poważ­ny błąd mode­lo­wa­nia pro­ce­sów biznesowych.

Ten model (powy­żej) jest odpor­ny na zmia­ny pro­ce­dur i reguł biz­ne­so­wych, są to odręb­ne, powią­za­ne z mode­lem doku­men­ty. Procedura i wyszko­lo­ny pra­cow­nik obsłu­ży sta­tu­sy spra­wy, reagu­je w ramach upraw­nień i kom­pe­ten­cji na stan Sprawy zgod­nie z pro­ce­du­rą. Konserwacja takiej doku­men­ta­cji nie sta­no­wi już dużej pra­co­chłon­no­ści. Jak widać model pro­ce­sów to doku­men­ta­cja opi­su­ją­ca stra­te­gię osią­ga­nia celów fir­my, tego w jaki spo­sób two­rzy pro­dukt ryn­ko­wy. Szczegóły to albo kom­pe­tent­ny pra­cow­nik i jego odpo­wie­dzial­ność albo mniej kom­pe­tent­ny pra­cow­nik i pro­ce­du­ry poka­zu­ją­ce mu jak ma pra­co­wać. Ten wybór to tak­że decy­zja zarządcza.

Na zakoń­cze­nie

Modelując jaką­kol­wiek fir­mę jaką­kol­wiek nota­cją war­to pro­jekt mode­lo­wa­nia uzu­peł­nić o jego prag­ma­ty­kę, to jest o spe­cy­fi­ka­cję wszel­kich warun­ków two­rze­nia mode­li. Opracowanie takiej doku­men­ta­cji wyma­ga usta­le­nia tych zasad, a tak­że zde­fi­nio­wa­nia słow­ni­ka, skoń­czo­nej prze­strze­ni nazw i defi­ni­cji, któ­ra pozwo­li jed­no­znacz­nie zakla­sy­fi­ko­wać każ­de poję­cie z życia fir­my do wła­ści­we­go, i tyl­ko jed­ne­go, ele­men­tu mode­lu. Projekt mode­lo­wa­nia pro­ce­sów to nie jest pro­ste ryso­wa­nie tego co się dzie­je. Tak powsta­ją naj­czę­ściej nie­przy­dat­ne i kosz­tow­ne zara­zem dokumenty.

Projekt mode­lo­wa­nia pro­ce­sów biz­ne­so­wych to wni­kli­wa ana­li­za całej orga­ni­za­cji, spo­so­bu zarzą­dza­nia nią i udo­ku­men­to­wa­nia tego jak fak­tycz­nie powsta­je w niej war­tość dla klien­ta. Nie raz nie­ste­ty odno­szę wra­że­nie, że w wie­lu pro­jek­tach tego rodza­ju duża war­tość ana­li­zy i mode­li biz­ne­so­wych zosta­je zastą­pio­na skom­pli­ko­wa­ny­mi i nic nie war­ty­mi diagramami.

RACI

Poniżej matry­ca RACI jako uzu­peł­nie­nie pro­ce­dur stwo­rzo­na na bazie powyż­szych diagramów:

Powyższa postać spe­cy­fi­ka­cji może być wygod­na dla osób nie­oswo­jo­nych z dia­gra­ma­mi a uży­tecz­na jako mate­riał do bie­żą­ce­go użyt­ku. Jeżeli jakaś pro­ce­du­ra mia­ła by zawie­rać tyl­ko takie dane (wyma­ga­nia) to takie zesta­wie­nie z powo­dze­niem może ja zastą­pić. Czynności i pro­ce­sy moż­na posor­to­wać alfa­be­tycz­nie dla uła­twie­nia korzy­sta­nia z dużej listy.

Analogiczną macierz moż­na opra­co­wać dla doku­men­tów. Tę wer­sję bar­dziej pole­cam gdyż, co do czyn­no­ści i pro­ce­sów to odpo­wie­dzial­ność może być wie­lo­po­zio­mo­wa (pod­le­głość służ­bo­wa), tak w przy­pad­ku doku­men­tów zależ­no­ści te są jed­no­znacz­ne (a nie w każ­dej orga­ni­za­cji doku­ment jest iden­ty­fi­ko­wa­ny jak pro­dukt procesu).

SIPOC

W prak­ty­ce ana­li­ty­ka czę­sto zaczy­nam pro­jek­ty od wyspe­cy­fi­ko­wa­nia klu­czo­wych pro­ce­sów end-to-end. Są to pro­ce­sy opi­su­ją­ce klu­czo­we dzia­ła­nia orga­ni­za­cji. W takiej sytu­acji SIPOC to nic inne­go jak abs­trak­cyj­ny opis (model) czar­nej skrzyn­ki jaką jest bada­ny pod­miot. Lista jest ogra­ni­czo­na wyłącz­nie do dostaw­ców fir­my i jej odbior­ców (klien­tów).

Diagram SIPOC

Ograniczając do tego pozio­mu tę meto­dę, moż­na opra­co­wać (fir­ma samo­dziel­nie lub z pomo­cą ana­li­ty­ka) listę klu­czo­wych pro­ce­sów i nie raz sam zale­cam taki począ­tek pro­jek­tu pole­ga­ją­ce­go na mapo­wa­niu pro­ce­sów. Zagłębianie się jed­nak do wnę­trza fir­my z takim mode­lem jest bar­dzo ryzy­kow­ne, gdyż nie ma tu meto­dy łączą­cej pro­ce­sy w łań­cu­chy wyj­ście-wej­ście wiec wery­fi­ka­cja mode­lu jest bar­dzo trud­na a w przy­pad­ku więk­szych orga­ni­za­cji prak­tycz­nie niemożliwa.

Podsumowanie

Nazywanie więc tych narzę­dzi (SIPOC i RACI) meto­da­mi jest moim zda­niem nad­uży­ciem. Niewątpliwie SIPOC jest przy­dat­ną tech­ni­ką pro­ste­go spe­cy­fi­ko­wa­nia pro­ce­sów. Jednak model pro­ce­sów jest tu i tak przy­dat­nym, bo wery­fi­ko­wal­nym, źró­dłem danych.

RACI jako narzę­dzie doku­men­to­wa­nia dodat­ko­wych powią­zań pomię­dzy czyn­no­ścia­mi a rola­mi może być przy­dat­ne jako uzu­peł­nie­nie spe­cy­fi­ka­cji SIPOC i kom­plet­nej mapy pro­ce­sów biz­ne­so­wych. Model w posta­ci dia­gra­mu BPMN to łań­cuch wartości.

Warto posia­dać tak opra­co­wa­ny model fir­my. Dokumentacja taka jest trud­na w wyko­na­niu ale szyb­ko pro­cen­tu­je, gdyż:

  1. porząd­ku­je dane w dzia­łach kadr (opi­sy kom­pe­ten­cji, opi­sy sta­no­wisk, eli­mi­nu­je zbęd­ne powtó­rze­nia, wykry­wa luki)
  2. porząd­ku­je zaso­by pro­ce­dur i zarzą­dzeń wewnętrz­nych (wychwy­ty­wa­nie mar­twych” czy­li z niczym nie powią­za­nych zarzą­dzeń i pro­ce­dur, wska­zu­je brakujące),
  3. pozwa­la na szyb­kie i pew­ne spe­cy­fi­ko­wa­nie wyma­gań na nowe lub roz­bu­do­wy­wa­ne opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie (wyma­ga jedy­nie okre­śle­nia zakre­su pro­jek­tu i opra­co­wa­nia wycią­gu” z posia­da­ne­go mode­lu procesów)
  4. pozwa­la na sta­łą obser­wa­cję i opty­ma­li­za­cję procesów.

Poniżej przy­kła­do­we zesta­wie­nie zakre­su obo­wiąz­ków na pod­sta­wie mode­lu procesowego:

(zesta­wie­nie dia­gra­mów z tego arty­ku­łu w posta­ci uprosz­czo­ne­go rapor­tu: Raport RACI SIPOC)

Źródła

Cabanillas, C., Resinas, M. and Ruiz-Cortés, A. (2012) Automated Resource Assignment in BPMN Models Using RACI Matrices’, in R. Meersman et al. (eds) On the Move to Meaningful Internet Systems: OTM 2012. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 56 – 73. Available at: https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 33606-5_5.

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 14 komentarzy

  1. Michał

    Moim zda­niem RACI nie jest mode­lem, ale spo­so­bem opi­su imple­men­ta­cji (wdro­że­nia) mode­lu. Modele pro­ce­so­we posłu­gu­ją się poję­ciem roli, któ­ra jest nie­za­leż­na od przy­ję­tej struk­tu­ry orga­ni­za­cyj­nej. Z kolei przy­po­rząd­ko­wa­nie RACI odwo­łu­je się do kon­kret­nych funk­cji w struk­tu­rze orga­ni­za­cyj­nej (co widać na załą­czo­nym obraz­ku). Czyli tak bym tego używał:
    1) Zaprojektować pro­ces (stwo­rzyć model)
    2) Wdrożyć pro­ces w orga­ni­za­cji opi­su­jąc go w ewen­tu­al­nych pro­ce­du­rach z pomo­cą RACI.
    przy czym pierw­sze leży zde­cy­do­wa­nie w gestii pro­jek­tan­ta / archi­tek­ta /analityka. Druga czyn­ność powin­na być wyko­na­na w ramach orga­ni­za­cji, a pro­jek­tant powi­nien ogra­ni­czyć się do konsultacji.

    1. Jarek Żeliński

      Do powyż­sze­go, z czym się zga­dzam, war­to dodać, że kom­plet­ny model orga­ni­za­cji powi­nien zawie­rać powią­za­nia obiek­tów na mode­lach z inny­mi, powią­za­ny­mi, doku­men­ta­mi w fir­mie. Dlatego arty­kuł uzu­peł­ni­łem o kolej­ny przy­kła­do­wy dia­gram z komen­ta­rzem. To jest tak­że powo­dem, dla któ­re­go war­to sto­so­wać zaawan­so­wa­ne narzę­dzia do mode­lo­wa­nia. Proste narzę­dzia, takie jak popu­lar­ny Visio, nie daje nawet szans na obję­cie w doku­men­ta­cji wszyst­kich rela­cji pomię­dzy doku­men­ta­mi powią­za­ny­mi w mode­lach, a ich ręcz­ne wery­fi­ko­wa­nie jest pra­co­chłon­ne. Niestety tego rodza­ju narzę­dzia są powszech­nie sto­so­wa­ne nawet a dużych fir­mach dorad­czych, co powo­du­je, że albo opra­co­wa­ne doku­men­ty są nie­kom­plet­ne i nie­spój­ne (czy­li prak­tycz­nie nie przy­dat­ne) albo są bar­dzo pra­co­chłon­ne czy­li kosz­tow­ne zarów­no w wytwo­rze­niu jak i w utrzymaniu.

  2. barbarossa1

    Witam, prze­brnę­łam przez tekst o RACI?.
    To praw­da, że nagmin­nie sto­so­wa­ne VISIO nie wszyst­ko opisze,
    ja bym jed­nak do RACI czy VISIO, czy cokol­wiek inne­go doda­ła jako obo­wiąz­ko­we w każ­dej orga­ni­za­cji sys­tem pro­wa­dze­nia projektów,
    gdzie dopa­so­wu­jąc cho­ciaż­by Prince 2 do spe­cy­fi­ki fir­my, może­my bar­dzo przej­rzy­ście stwo­rzyć regu­ły gry dla sta­rych i wszyst­kich nowych pra­cow­ni­ków, od któ­rych tak napraw­dę zale­ży powo­dze­nie pro­ce­su biznesowego.

    1. Jarek Żeliński

      To praw­da. Nie wspo­mnia­łem o tym ale fak­tycz­nie sfor­ma­li­zo­wa­ne meto­dy zarzą­dza­nia pro­jek­ta­mi, dosto­so­wa­ne do tre­ści i zakre­su pro­jek­tu, to bar­dzo sil­ne narzę­dzie zarząd­cze dla kie­row­ni­ka pro­jek­tu i dla spon­so­ra pro­jek­tu jako narzę­dzie nad­zo­ru nad projektem.

  3. fweewedfwefwefwe

    Nie zga­dzam się z klu­czo­wą myślą tego arty­ku­łu, że ist­nie­je prost­szy spo­sób mode­lo­wa­nia poprzez prze­nie­sie­nie zło­żo­ne­go mode­lu po pro­stu do war­stwy opi­so­wej (regu­ła biz­ne­so­we­go). Zwróćcie pro­szę uwa­gę, że dia­gra­my nie tyl­ko są two­rzo­ne na potrze­by biz­ne­su. Dla biz­ne­su zgo­da – zapro­po­no­wa­ne podej­ście jest spryt­ne i umoż­li­wia szyb­kie ukoń­cze­nie tema­tu. Notacja jed­nak zasto­so­wa­na w sil­ni­kach work­flow wyma­ga jed­nak­że bar­dziej deta­licz­ne­go zamo­de­lo­wa­nia niż tyl­ko w spo­sób łatwy do uchwy­ce­nia dla biz­ne­su, taki dzię­ki któ­re­mu CEO będzie mógł się cie­szyć że ma pro­ce­sy zop­ty­ma­li­zo­wa­ne”, odpor­ne”.

    1. Jaroslaw Zelinski

      Nie wiem o jakim sil­ni­ku mowa. Reguły biz­ne­so­we to logicz­ne, sfor­ma­li­zo­wa­ne stwier­dze­nia. W połą­cze­niu ze słow­ni­kiem pojęć (słow­nik danych) taki motor reguł” to odpo­wied­nik testów” w wie­lu apli­ka­cjach typu work­flow engi­ne”. Podejście typu case mana­ge­ment” (mode­lo­wa­nie wszel­kich pla­no­wa­nych sce­na­riu­szy) jest bar­dzo pra­co­chłon­ne i raczej nie zdo­by­wa sobie popu­lar­no­ści w apli­ka­cjach. Łatwiej jest zbu­do­wać sys­tem z uży­ciem listy reguł, czy­ha­ją­cych” na zacho­wa­nia użyt­kow­ni­ków i sta­nu danych, jakie prze­twa­rza­ją, niż pró­bo­wać opra­co­wać” wszyst­kie ścież­ki jakich się spo­dzie­wa­my. To jak sza­chy: albo budu­je­my grę z moto­rem reguł gry w sza­chy (zasa­dy gry to dwie kart­ki papie­ru), albo budu­je­my drze­wo skła­da­ją­ce się z moż­li­wych prze­bie­gów par­tii sza­chów. Masakra…

      Faktyczny prze­bieg pro­ce­su to kon­se­kwen­cja reguł a nie odwrot­nie: każ­da fir­ma ma regu­ły (zakre­sy obo­wiąz­ków, upraw­nie­nia itp.), tyl­ko kil­ka pro­cent firm ma mode­le pro­ce­sów, a mimo to wszyst­kie one jakoś funkcjonują. 

  4. Jaroslaw Zelinski

    Bardzo dobry tekst o tym jak złe jest zaszu­mia­nie” mode­li nad­mia­rem szczegółów:

  5. Marcin

    Jeśli cho­dzi o SIPOC to przy­znam, nie sto­so­wa­łem zaso­bów czy wyma­gan potrzeb­nych w pro­ce­sie. Wezmę to na pew­no pod uwa­gę. Co do samej mapy mam cza­sa­mi dyle­mat, czy two­rzyć to w taki spo­sób, jak opi­sa­ny w tek­ście czy może w taki spo­sób, że do każ­dej czyn­no­ści, każ­dej jed­nej doda­ję input out­put itd. Tutaj przy­kład https://​lep​szy​ma​na​ger​.pl/​s​i​p​o​c​-​o​g​o​l​n​a​-​m​a​p​a​-​p​r​o​c​e​su/ Czasami trud­no to zro­bić, choć ja tak byłem uczo­ny. Innym spo­so­bem jest oczy­wi­scie, jak przy­klad z tego tek­stu, wypi­sa­nie wszyst­kich kro­kow, a potem wszyst­kich inpu­tow, out­pu­tow itd. Ciekaw jestem jak inni pod­cho­dza do tego tematu

    1. Jarosław Żeliński

      Kluczem jest to, że SIPOC to pro­ce­sy a nie kro­ki pro­ce­du­ry, poję­cie kro­ku” w SIPOC nie wystę­pu­je, pro­ces to coś” co ma wej­ście (doku­ment od dostaw­cy) i wyj­ście (doku­ment dla klien­ta), wszyst­ko to co pomię­dzy to kro­ki pro­ce­du­ry (mówi­my o tak zwa­nym ele­men­tar­nym pro­ce­sie, czy­li już nie pod­le­ga­ją­cym dal­szej dekom­po­zy­cji). Typowym pro­ble­mem w pro­jek­tach zwią­za­nych z ana­li­zą pro­ce­sów jest utra­ta pano­wa­nia nad szcze­gó­ło­wo­ścią. Rzecz w tym, by usta­lić gra­ni­cę mię­dzy tym co jest pro­ce­sem a tym co jest kro­kiem pro­ce­du­ry opi­su­ją­cej pro­ces (a kon­kret­nie aktyw­ność w pro­ce­sie). Te gra­ni­cę wyzna­cza­ją pro­duk­ty pro­ce­su, de fac­to kon­kret­ne doku­men­ty lub ich statusy.

  6. Marek Kozłowski

    Uproszczony Raport z (zesta­wie­nie dia­gra­mów z tego arty­ku­łu w posta­ci uprosz­czo­ne­go rapor­tu: Raport RACI SIPOC) po wydru­ko­wa­niu, nie zawie­ra nume­ra­cji stron.

  7. Marek Kozłowski

    Wydruk Raport RACI SIPOC z lin­ku z 

    1. Jarosław Żeliński

      Faktycznie. Automat VP nie wsta­wia nume­ru stron do stop­ki, a ja zapo­mnia­łem to zro­bić. 😉 Ale gene­ral­nie stop­ki w VP mogą zawie­rać numer strony 😉

Dodaj komentarz

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