Modelowanie biznesowe czyli sterowanie i mechanizmy

Równo 10 lat temu napisałem:

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla pra­cow­ni­ków fir­my opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej wewnętrz­ne i zewnętrz­ne zacho­wa­nia oraz reak­cje. Poza tym, jest nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my w tym tak­że do przy­go­to­wa­nia jej do wdro­że­nia sys­te­mów infor­ma­cyj­nych. Wiele firm dorad­czych i infor­ma­tycz­nych pod poję­ciem mapy i mode­lu pro­ce­sów biz­ne­so­wych dostar­cza nie­przy­dat­ne, utrwa­lo­ne na dzie­siąt­kach dia­gra­mów opi­sy czyn­no­ści reali­zo­wa­nych przez ankie­to­wa­nych pra­cow­ni­ków, któ­re nie wie­le mają wspól­ne­go z pla­no­wa­ny­mi zmia­na­mi na lepsze.Większość mode­li firm jakie widzia­łem to obraz­ki nie mają­ce wie­le wspól­ne­go z pro­ce­sa­mi. Zdarza mi się otrzy­my­wać zle­ce­nia, któ­rych głów­nym celem jest oce­na cudzej doku­men­ta­cji przed­wdro­że­nio­wej. Bardzo czę­sto jest to siecz­ka w posta­ci udo­ku­men­to­wa­nych życzeń i wyobra­żeń ankie­to­wa­nych pra­cow­ni­ków fir­my… (Źródło: Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsztaplerów)

I nie­ste­ty nie wie­le w tym wzglę­dzie się zmie­ni­ło od tam­te­go cza­su. Zmieniło się jed­nak to, że funk­cyj­na idea mode­lo­wa­nia orga­ni­za­cji w posta­ci mode­lu pro­ce­sów biz­ne­so­wych ma już ugrun­to­wa­ną pozy­cję, i mamy postęp w posta­ci powsta­nia, i ugrun­to­wa­nia sobie pozy­cji jako stan­dar­du de» fac­to, nota­cji B.

Wtedy powo­ły­wa­łem się na nota­cje IDEF0, w któ­rej fun­da­men­tem jest funk­cyj­ny blok konstrukcyjny:

IDEF0
Draft Federal Information Processing Standards Publication 183 1993 December 21 Announcing the Standard for INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

Powyższy dia­gram to wyko­na­ny w nota­cji [[IDEF0]] model pro­ce­su jako funk­cji, jej wej­ścia, wyj­ścia, ste­ro­wa­nia i mecha­ni­zmu dzia­ła­nia. Systemowe (nauko­we, czy­li pozwa­la­ją­ce na testo­wa­nie mode­lu i jego fal­sy­fi­ka­cje) mode­lo­wa­nie orga­ni­za­cji nadal bazu­je na poję­ciach z tej (IDEF0) nota­cji i mode­lu pro­ce­su ICOM (ang. Input, Output, Controll, Mechanizm):

Model ICOM

Idea ta bazu­je na uzna­niu, że każ­dy pro­ces biz­ne­so­wy to wno­szą­ce war­tość doda­ną funk­cja prze­kształ­ca­ją­ca wej­ście w wyj­ście pro­ce­su, prze­kształ­ce­nie to, spo­sób jego reali­za­cji, jest ogra­ni­czo­ne a dzia­ła­nia, ich mecha­nizm, mogą być defi­nio­wal­ne jako deter­mi­ni­stycz­ne. Notacja IDEF0 była dłu­go sto­so­wa­na jed­nak mia­ła pod­sta­wo­wą wadę: znacz­nie strza­łek (seman­ty­ka nota­cji) było uza­leż­nio­ne od ich poło­że­nia, co utrud­nia­ło wery­fi­ka­cję mode­li, utrud­nia­ło ich two­rze­nie i nara­ża­ło te mode­le na nie­jed­no­znacz­ność przy ich czy­ta­niu (pamię­ta­my, że model to tak­że treść czy­li komunikacja).

Notacja BPMN nie ma tej wady ale też nie zawie­ra takich pojęć jak Controll i Mechanizm. BPMN to przede wszyst­kim prze­pływ pra­cy oraz dane wej­ścio­we i wyj­ścio­we (dia­gram powy­żej). Jednak nota­cja ta pozwa­la na roz­sze­rza­nie seman­ty­ki o nowe sym­bo­le. Bardzo złą prak­ty­ką jest nano­sze­nie na mode­le pro­ce­sów (dia­gra­my BPMN dla tych pro­ce­sów) deta­li zwią­za­nych ze spo­so­bem dzia­ła­nia czy­li logi­ką biz­ne­so­wą i mecha­ni­zmem podej­mo­wa­nia decy­zji. Modele takie sta­ją się bar­dzo szcze­gó­ło­we a utrzy­ma­nie ich aktu­al­no­ści (sta­no­wią doku­men­ta­cję pro­ce­sów) prak­tycz­nie nie jest moż­li­we (każ­da zmia­na spo­so­bu dzia­ła­nia wyma­ga korek­ty tych dia­gra­mów). Tworzenie takich, zbyt szcze­gó­ło­wych, mode­li okre­śla­ne jest w lite­ra­tu­rze okre­śla­ne wręcz jako utra­ta pano­wa­nia nad szcze­gó­ło­wo­ścią projektu”.

Od lat sto­so­wa­ne są, jako uzu­peł­nie­nie mode­lo­wa­nia orga­ni­za­cji, macie­rze [[RACI]], pozwa­la­ją one, jako uzu­peł­nie­nie np. mode­li BPMN, osob­no udo­ku­men­to­wać zło­żo­ne zależ­no­ści pomię­dzy rola­mi w pro­ce­sie (wię­cej o RACI.….). Takie ele­men­ty poję­cio­we ICOM jak Controll i Mechanizm moż­na (zale­ca się) mode­lo­wać jako sys­tem reguł biz­ne­so­wych i tabel decyzyjnych.

Model pro­ce­su wyko­na­ny w nota­cji BPMN, uzu­peł­nio­ny o ste­ro­wa­nie i mecha­nizm podej­mo­wa­nia decy­zji, wyglą­da tak:

Model procesów biznesowych

Zadanie 1 zosta­ło tu sko­ja­rzo­ne z Reguła biz­ne­so­wą (Controll) i Tablicą decy­zyj­ną (mecha­nizm). Reguły biz­ne­so­we to sfor­ma­li­zo­wa­ne zapi­sy okre­śla­ją­ce panu­ją­ce pra­wo” w orga­ni­za­cji (np. zarzą­dze­nia i regu­la­mi­ny). Tablice decy­zyj­ne to sfor­ma­li­zo­wa­ne macie­rze opi­su­ją­ce deter­mi­ni­stycz­ne decy­zje (kon­kret­na odpo­wiedź sys­te­mu w odpo­wie­dzi na kon­kret­ny zestaw bodź­ców). Wejście i wyj­ście to nic inne­go jak odpo­wied­nio ozna­czo­ne Dane (Obiekt danych w BPMN). Szczegóły wyko­na­nia Zadania to albo wie­dza i umie­jęt­no­ści wyko­naw­cy albo pro­ce­du­ra (np. ISO). W doku­men­ta­cji pro­jek­to­wej powo­łu­je­my się na (załą­cza­my) wyma­ga­ny zakres kom­pe­ten­cji wyko­naw­cy (rola na dia­gra­mie pro­ce­su) lub załą­cza­my sto­sow­ną pro­ce­du­rę (doku­ment, nie nano­si­my na dia­gram BPMN). Takie nie­po­dziel­ne już zada­nie, wraz z jego wej­ściem, wyj­ściem i ewen­tu­al­ny­mi regu­ła­mi to ele­men­tar­ny pro­ces biznesowy.

Tak więc zasa­dy nauko­we­go mode­lo­wa­nia (a wcze­śniej ana­li­zy) nie zmie­nia­ją się:

  1. zde­fi­nio­wa­nie i okre­śle­nie problemu,
  2. ana­li­za i opra­co­wa­nie hipo­te­zy (mode­lu, tu bada­nej orga­ni­za­cji czy­li jej mode­lu pro­ce­so­we­go: tak orga­ni­za­cja reali­zu­je swo­je cele),
  3. testo­wa­nie (pró­ba fal­sy­fi­ka­cji mode­lu) w posta­ci spraw­dza­nia czy są w orga­ni­za­cji dane prze­twa­rza­ne ina­czej niż na modelu,
  4. opra­co­wa­nie wyni­ków, lub korek­ta mode­lu w przy­pad­ku jego uda­nej fal­sy­fi­ka­cji (wte­dy powta­rza­my pkt 2. i 3.)
  5. opra­co­wa­nie reko­men­da­cji czy­li odpo­wiedź na pyta­nie zada­ne w pkt. 1.

Notacja BPMN do duży krok do przo­du, bo narzę­dzie to ma pre­cy­zyj­ną (pod­da­ją­cą się wali­da­cji), seman­ty­kę i syn­tak­ty­kę, a moż­li­wość nada­nia mode­lom kon­tek­stu poprzez dodat­ko­we uży­cie macie­rzy RACI, reguł biz­ne­so­wych i tablic decy­zyj­nych, pozwa­la two­rzyć bar­dzo pre­cy­zyj­ne mode­le biz­ne­so­we moż­li­we do zarzą­dza­nia (nie obar­czo­ne nad­mia­rem szcze­gó­łów). Wydzielenie pozio­mu szcze­gó­ło­wo­ści zwią­za­ne­go z podej­mo­wa­niem decy­zji, poza dia­gra­my (jako załą­czo­ne ele­men­ty), pozwa­la po pierw­sze utrzy­mać roz­sąd­ny poziom szcze­gó­ło­wo­ści samych dia­gra­mów, ich czy­tel­ność i zarzą­dzal­ność, np. zmia­na mecha­ni­zmu podej­mo­wa­nia decy­zji nie wyma­ga aktu­ali­za­cji dia­gra­mów, bo prze­pływ pra­cy nie zmie­nia się. Poniżej wie­lo­krot­nie tu przy­ta­cza­ny model warstwowy;

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

Najwyższa war­stwa to wskaź­ni­ki (np KPI), archi­tek­tu­ra pro­ce­sów, stra­te­gie itp. Najniższa war­stwa to wszel­kie szcze­gó­ły takie jak instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zakre­sy obo­wiąz­ków, opi­sy wyma­ga­nych umie­jęt­no­ści, instruk­cje dla użyt­kow­ni­ków urzą­dzeń i opro­gra­mo­wa­nia, wszel­kie inne szcze­gó­ły opi­su­ją­ce spo­sób pra­cy (nie raz mecha­nizm jej wyko­ny­wa­nia). Środkowa war­stwa to wła­śnie abs­trak­cja, jaką jest model pro­ce­sów biz­ne­so­wych, jest on opi­sem prze­pły­wu pra­cy. Na tym pozio­mie opra­co­wu­je­my model, któ­ry w lite­ra­tu­rze z zakre­su stra­te­gii i zarzą­dza­nia jest nazy­wa­ny wewnętrz­nym łań­cu­chem war­to­ści w orga­ni­za­cji. Na tym pozio­mie nie doku­men­tu­je­my żad­nych szcze­gó­łów (powo­łu­je­my się na nie, załą­cza­my je), na tym pozio­mie poka­zu­je­my wyłącz­nie CO i PO CO się dzie­je a nie JAK. Opis tego jak JAK to się dzie­je to wła­śnie owe Controll Mechanizm.

Owszem wyma­ga to uży­cia dodat­ko­wych ele­men­tów na dia­gra­mach BPMN, wyma­ga tak­że tak­że odpo­wied­nie­go narzę­dzia CASE, któ­re na to pozwa­la, ale war­to bo doku­men­ta­cja taka sta­je się łatwa w korzy­sta­niu z niej, mamy zapew­nio­ny odpo­wied­ni poziom abs­trak­cji samych mode­li pro­ce­sów, mamy tak­że osob­no udo­ku­men­to­wa­ne szcze­gó­ły logi­ki biz­ne­so­wej, co bar­dzo uła­twia (w zasa­dzie prze­ka­zu­je­my jej bez mody­fi­ka­cji) posta­wie­nie wyma­gań przed opro­gra­mo­wa­niem, któ­re mia­ło by je imple­men­to­wać (regu­ły biz­ne­so­we i tabli­ce decy­zyj­ne sta­ją się w takim wypad­ku wymaganiem).

Modelowanie biznesowe, czy to już dojrzała dyscyplina?

Na razie widzę, że kla­ru­ją się dwa podejścia:

- IDEF0 lub ICOM i pochod­ne (w tym EPC i eEPC)

- inne idą w kie­run­ku UML

IDEF0 to kom­plet­ny model logicz­ny uwzględ­nia­ją­cy zaso­by i cele biz­ne­so­we (któ­re nie­ste­ty czę­sto zatra­ca się w pro­ce­sie mode­lo­wa­nia!). UML to dro­ga do zapro­jek­to­wa­nia apli­ka­cji. Myślę, że tą dro­gą w środ­ku spo­tka­ją się ana­li­ty­cy i pro­gra­mi­ści. W miej­scu gdzie mamy model pro­ce­so­wy i pro­ce­du­ry (work­flow) na naj­niż­szym pozio­mie dekom­po­zy­cji pro­gra­mi­sta obiek­to­wy ma wszyst­kie infor­ma­cje by z pomo­cą UML zapro­jek­to­wać i napi­sać kod apli­ka­cji. Każdy pro­sty ?blo­czek? mode­lu oraz inter­fej­sy (for­mat­ki doku­men­tów) mogą teraz zostać zaim­ple­men­to­wa­ne w sys­te­mie. Być może od stro­ny mode­lo­wa­nia BPMN (Business Process Modeling Notation) a od stro­ny kodo­wa­nia BPEL wnio­są uła­twie­nie pole­ga­ją­ce na umoż­li­wie­niu pew­nej auto­ma­ty­za­cji two­rze­nia pro­gra­mów jed­nak w moim prze­ko­na­niu waż­niej­sze jest by pre­cy­zyj­nie wska­zać gra­ni­ce kom­pe­ten­cji pomię­dzy ana­li­ty­kiem a inży­nie­rem i dokład­nie na tej gra­ni­cy umie­ścić styk narzę­dzi ana­li­tycz­nych i inżynierskich.

Modelowanie to dzie­dzi­na pra­wie tak sta­ra jak sys­te­my infor­ma­tycz­ne dla biz­ne­su. Podstawowym celem mode­lo­wa­nia pro­ce­sów jest opi­sa­nie fir­my, okre­śle­nie celu pro­jek­tu reor­ga­ni­za­cyj­ne­go i jego zakre­su, okre­śle­nie wyma­gań na two­rzo­ne opro­gra­mo­wa­nia a wcze­śniej opty­ma­li­za­cji orga­ni­za­cji i przy­go­to­wa­nie jej do wdro­że­nia. Stworzenie opi­su funk­cjo­nal­ne­go tego co będzie­my opro­gra­mo­wy­wać zawsze było wyzwa­niem trud­nym. Drugim, być może jesz­cze trud­niej­szym jest (do dzi­siaj) nawią­za­nie nici poro­zu­mie­nia i zro­zu­mie­nia pomię­dzy sfe­rą biz­ne­su a inży­nie­ra­mi i programistami.

Jedna z ról jaką ma do ode­gra­nia wyko­na­ny przez ana­li­ty­ków model jest stwo­rze­nie szkie­le­tu apli­ka­cji lub przy­naj­mniej opi­su tego szkie­le­tu. Naturalnym dąże­niem jest tak­że pró­ba unik­nię­cia ręcz­ne­go prze­pi­sy­wa­nia” pra­cy ana­li­ty­ków biz­ne­so­wych mode­lu i wyge­ne­ro­wa­nie na jego pod­sta­wie kodu apli­ka­cji lub przy­naj­mniej jej mode­lu np. w posta­ci UML.

Notacje i meto­dy­ki mode­lo­wa­nia moż­na podzie­lić na dwie grupy:

  1. mode­lo­wa­nie do pro­wa­dze­nia ana­liz i opty­ma­li­za­cji pro­ce­sów i zda­rzeń gospo­dar­czych (pro­ce­sów biznesowych)
  2. mode­lo­wa­nie do celów two­rze­nia oprogramowania

Na świe­cie nadal naj­po­pu­lar­niej­sze są: IDEF wśród ana­li­ty­ków i UML wśród programistów.

Modele analityczne

Tu się nie­wie­le zmie­ni­ło. Nadal w uży­ciu jest IDEF0 i jego odmia­ny a raczej warian­ty czy­li ICOM i mniej zna­ny IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czy­li Wejście, Sterowanie, Wyjście, Mechanizm (tu cho­dzi o zaso­by). Skrót IGOE ma roz­wi­nie­cie: Input, Guide (odpo­wied­nik ste­ro­wa­nia), Output, Enabler (tu cho­dzi o zaso­by w kon­tek­ście ini­cja­to­ra reali­za­cji danej funk­cji). W obu przy­pad­kach ogól­ny sche­mat pro­ce­su w tych kon­wen­cjach przed­sta­wia­ny jest za pomo­cą pro­sto­ką­ta sym­bo­li­zu­ją­ce­go funk­cję reali­zo­wa­ną przez pro­ces oraz strzał­ki obra­zu­ją­ce wymie­nio­ne czte­ry jego atrybuty :

Na tym pozio­mie powsta­ło wie­le pro­duk­tów, któ­re nie­ste­ty zawie­ra­ją swo­je uni­kal­ne roz­sze­rze­nia sym­bo­li i reguł. Doprowadziło to powsta­nia wie­lu narzę­dzi do mode­lo­wa­nia, któ­rych pro­duk­ty są ze sobą nie­kom­pa­ty­bil­ne już na pozio­mie uży­tych sym­bo­li. Nie wymie­nia­jąc ich tu napi­sze, tyl­ko, że w dość powszech­nym uży­ciu jest ich pra­wie dzie­sięć a Gartner ziden­ty­fi­ko­wał ich na ryn­ku trzy­dzie­ści sześć. Z tego też powo­du uży­wam w pra­cy sym­bo­li ICOM pro­stych i zro­zu­mia­łych dla biz­ne­su zaś w przy­pad­kach bar­dziej sfor­ma­li­zo­wa­nych” uży­wam IDEF0. Z uwa­gi na sta­ły roz­wój tak­że tych metod osta­nio zain­te­re­so­wą­łem się nota­cją BPMN.

Modelowanie do celów tworzenia oprogramowania

Ten temat jest dużo trud­niej­szy, gdyż dąże­nie do reali­za­cji sprzę­gu” pomię­dzy ana­li­ty­kiem a infor­ma­ty­kiem to temat ist­nie­ją­cy od począt­ku cza­sów two­rze­nia opro­gra­mo­wa­nia do celów biz­ne­so­wych. Krótka histo­ria narzę­dzi do mode­lo­wa­nia na potrze­by two­rze­nia opro­gra­mo­wa­nia (rok powsta­nia i nazwa metody):

  • 1962: sie­ci Petriego (Carl Petri Network)
  • 1970: ANSI Flow charts
  • 1979: DFD (Data Flow Diagram)
  • 1982: ISO TC87 (ISO Conceptual Schema Model)
  • 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
  • 1992; EPC (Eventdriven Process Chains)
  • 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
  • 2001: ebXML v.1.1 (elec­tro­nic busi­ness using eXtesible Markup Language)
  • 2002: BPML v.1.1 (Busines Process Modeling Language)
  • 2002: WSCi v.1.0
  • 2003: BPEL4WS (Business Process Execution Language for Web Services)
  • 2004: BPMN (Business Process Modeling Notation)

(na pod­sta­wie Process mode­ling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of tech­no­lo­gy Information).

Sieci Petriego są nadal uwa­ża­ne za jed­no z naj­sku­tecz­niej­szych narzę­dzi do mode­lo­wa­nia jed­nak ich głów­nym ogra­ni­cze­niem jest dość skom­pli­ko­wa­ny model mate­ma­tycz­ny oraz brak hie­rar­chi­za­cji funk­cji jak to ma miej­sce w real­nych orga­ni­za­cjach. Nie zawie­ra też w sobie narzę­dzi do opi­su archi­tek­tu­ry obiek­to­wej opro­gra­mo­wa­nia. Metody two­rze­nia opro­gra­mo­wa­nia zorien­to­wa­ne obiek­to­wo dopro­wa­dzi­ły do powsta­nia narzę­dzi typu UML jed­nak są one bar­dzo trud­ne do zasto­so­wa­nia w mode­lo­wa­niu biz­ne­so­wym gdyż natu­ra orga­ni­za­cji jest hie­rar­chicz­na a nie obiek­to­wa. Modele obiek­to­we są po pierw­sze prak­tycz­nie nie­zro­zu­mia­łe dla biz­ne­su po dru­gie nie spraw­dza­ją się jako narzę­dzie do opi­su orga­ni­za­cji, któ­ra żyje i ewo­lu­uje. Stale roz­wi­ja­ją­ce się meto­dy zarzą­dza­nia ewo­lu­ują w stro­nę pro­ce­sów biz­ne­so­wych ich natu­ra zaś jest jest hie­rar­chicz­na. Kolejną pró­bą roz­wią­za­nia pro­ble­mu jest powsta­nie BPMN.

BPMN – Business Process Modeling Notation

Ideą twór­ców BPMN jest stwo­rze­nie narzę­dzia dla ana­li­ty­ków ale takie­go, któ­re­go pro­duk­ty da się tłu­ma­czyć” na BPEL4WS. Bazą dla BPMN są sie­ci Petriego i EPC. Dla tego z jed­nej stro­ny kom­plet­na lista sym­bo­li BPMN to 38 sym­bo­li obra­zu­ją­cych typo­we zda­rze­nia biz­ne­so­we dają­ce się odwzo­ro­wać za pomo­cą BPEL4WS, mode­lo­wać zaś moż­na już za pomo­cą sze­ściu pod­sta­wo­wych, któ­re pozwa­la­ją na zbu­do­wa­nie peł­ne­go mode­lu pro­ce­sów biz­ne­so­wych. Pozostałe sym­bo­le słu­żą do dodat­ko­we­go defi­nio­wa­nia zda­rzeń koniecz­nych z punk­tu widze­nia inży­nie­rii opro­gra­mo­wa­nia. Dlatego np. model wyko­na­ny za pomo­cą pod­sta­wo­we­go zesta­wu sym­bo­li przez ana­li­ty­ka da się łatwo uzu­peł­nić jako kon­ty­nu­acja pro­jek­tu o bra­ku­ją­ce ele­men­ty w celu wyge­ne­ro­wa­nia kodu dla BPEL. ten zaś być może będzie stan­dar­dem słu­żą­cych do gene­ro­wa­nia kodu apli­ka­cji jak daw­ne sys­te­mu typu CASE.

Notatka: W tym roku (2005) opu­bli­ko­wa­no wer­sję 1.0 nota­cji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odby­ła się kon­fe­ren­cja BPMN Foundation na któ­rej mię­dzy inny­mi ogło­szo­no połą­cze­nie Notation Working Group z OMG i spe­cy­fi­ka­cję BPMN v.1.0. W pla­nie jest RFC.

Modelowanie biznesowe czyli pilnowanie hochsztaplerów

Jeżeli cze­goś nie moż­na nary­so­wać to zna­czy, że to nie ist­nie­je! To dewi­za, któ­ra przy­świe­ca mi w pra­cy jako doradcy.

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla pra­cow­ni­ków fir­my opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej wewnętrz­ne i zewnętrz­ne zacho­wa­nia oraz reak­cje. Poza tym, jest nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my w tym tak­że do przy­go­to­wa­nia jej do wdro­że­nia sys­te­mów infor­ma­cyj­nych. Wiele firm dorad­czych i infor­ma­tycz­nych pod poję­ciem mapy i mode­lu pro­ce­sów biz­ne­so­wych dostar­cza nie­przy­dat­ne, utrwa­lo­ne na dzie­siąt­kach dia­gra­mów opi­sy czyn­no­ści reali­zo­wa­nych przez ankie­to­wa­nych pra­cow­ni­ków, któ­re nie wie­le mają wspól­ne­go z pla­no­wa­ny­mi zmia­na­mi na lepsze.

Większość mode­li firm jakie widzia­łem to obraz­ki nie mają­ce wie­le wspól­ne­go z pro­ce­sa­mi. Zdarza mi się otrzy­my­wać zle­ce­nia, któ­rych głów­nym celem jest oce­na cudzej doku­men­ta­cji przed­wdro­że­nio­wej. Bardzo czę­sto jest to siecz­ka w posta­ci udo­ku­men­to­wa­nych życzeń i wyobra­żeń ankie­to­wa­nych pra­cow­ni­ków fir­my, w któ­rej to wdro­że­nie ma nastą­pić. Jeżeli ktoś potem nazy­wa to mapą pro­ce­sów biz­ne­so­wych to krę­ci sznur na wła­sny kark bo jest to tyl­ko opis tego co się w fir­mie aktu­al­nie dzie­je. Czemu to jest złe? Wyobraźmy sobie, że chce­my zapro­jek­to­wać sku­tecz­ny sys­tem wyna­gro­dzeń a zacna fir­ma, któ­ra ma go wdro­żyć ankie­tu­je w tym celu pra­cow­ni­ków fir­my pyta­jąc jak są wyna­gra­dza­ni i jak chcą być wyna­gra­dza­ni. Życzę powo­dze­nia tak przy­go­to­wy­wa­ne­mu projektowi.

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

Procesy

Proces: zbiór dzia­łań wza­jem­nie powią­za­nych lub wza­jem­nie oddzia­łu­ją­cych, któ­re prze­kształ­ca­ją wej­ścia w wyj­ścia (wg. PN-EN ISO 9000:2000, p.3.4.1). Rozszerzając to na pro­ce­sy biz­ne­so­we moż­na powiedzieć:

Proces (defi­ni­cja ICOM): zespół czyn­no­ści lub dzia­łań, któ­rych celem jest osią­gnię­cie ocze­ki­wa­ne­go rezul­ta­tu. Rezultat ten jest osią­ga­ny poprzez prze­two­rze­nie sta­nu wej­ścia pro­ce­su w stan wyj­ścio­wy. Przetworzenie to ste­ro­wa­ne jest za pomo­cą z góry usta­lo­nych reguł. Do osią­gnię­cia tak okre­ślo­ne­go rezul­ta­tu wyma­ga­ne okre­ślo­ne zaso­by. (ICOM: Input,Controll, Output, Mecha­nizm).

Proces biz­ne­so­wy: spój­ny zespół dzia­łań, któ­rych celem jest osią­gnię­cie okre­ślo­nej war­to­ści w posta­ci pro­duk­tu. Do wytwo­rze­nia pro­duk­tu wyma­ga­ne są: zaso­by, inne pro­duk­ty lub pół­pro­duk­ty (surow­ce) oraz regu­ły (zasa­dy) według któ­rych two­rzo­ny jest pro­dukt. Produkt musi dać się opi­sać (zde­fi­nio­wać) i być mierzalny.

Powyżej poka­za­no pod­sta­wo­wą gra­ficz­ną repre­zen­ta­cje pro­ce­su na bazie defi­ni­cji ICOM. Symbol ten wystar­czy do wyko­na­nia kom­plet­nej, popraw­nej mapy pro­ce­sów biz­ne­so­wych. 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 (Control). 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”.

Romby są cechą opi­su prze­pły­wu pra­cy (pro­ce­dur). Znamy je mię­dzy inny­mi z doku­men­ta­cji pro­ce­dur ISO. Często spo­ty­ka­ne sche­ma­ty, na któ­rych pozio­me pasy ozna­cza­ją zaso­by a sym­bo­le podej­mo­wa­ne dzia­ła­nia wraz z warian­ta­mi. To nie są pro­ce­sy a pro­ce­du­ry! (work­flow). A to wła­śnie czę­sto oglą­dam na dzie­siąt­kach stron kosz­tow­nych opra­co­wań wie­lu zacnych lide­rów ryn­ku IT i kon­sul­tin­gu nazy­wa­nych model pro­ce­sów biznesowych”.

[przyp. auto­ra: cze­to mylo­ne są mapy pro­ce­sów z mode­la­mi pro­ce­sów, sto­su­je się poję­cie mapy pro­ce­sów dla dia­gra­mów poka­zu­ją­cych wza­jem­ne poło­że­nie pro­ce­sów wzglę­dem sie­bie, to jest ich ewen­tu­al­ne lub domnie­ma­ne następ­stwa, na tych dia­gra­mach raczej” nie sto­su­je się rom­bów” czy­li bra­mek decy­zyj­nych; nota­cja BPMN jako narzę­dzie do mode­lo­wa­nia i doku­men­to­wa­nia pro­ce­sów biz­ne­so­wych nie ope­ru­ję poję­cie mapy procesów”].

Jak zbu­do­wać peł­ny model firmy

Należy roz­róż­nić trzy głów­ne ele­men­ty mode­lo­wa­nia organizacji:

  1. model biz­ne­so­wy
  2. mapa pro­ce­sów biznesowych
  3. mapa prze­pły­wu pra­cy (pro­ce­du­ry, work­flow) dla poszcze­gól­nych procesów

Model biz­ne­so­wy

Model biz­ne­so­wy okre­śla inte­rak­cje z oto­cze­niem ryn­ko­wym. Jest to zwię­zły opis tego na czym i jak fir­ma zara­bia. Diagram powi­nien obra­zo­wać klu­czo­we pod­mio­ty na ryn­ku bio­rą­ce udział w two­rze­niu war­to­ści przez fir­mę, prze­pły­wy war­to­ści i prze­pły­wy pie­nię­dzy. Mówiąc ina­czej powi­nien obra­zo­wać kto, co i komu daje”. Dotyczy to zarów­no pro­duk­tów i pie­nię­dzy ale tak­że prze­ka­zy­wa­nych infor­ma­cji. Inaczej mówiąc model biz­ne­so­wy musi obra­zo­wać peł­ny prze­pływ korzy­ści. Korzyścią dla sprze­da­ją­ce­go jest zysk a korzy­ścią dla nabyw­cy jest pozy­ska­na funk­cjo­nal­ność lub inna cecha pro­duk­tu (nale­ży ją jasno okre­ślić). Jeżeli w tym obro­cie poja­wia się pośred­nik lub inny pod­miot mają­cy wpływ na ten obieg nale­ży go poka­zać i opi­sać jego rolę. Np. model biz­ne­so­wy pro­du­cen­ta sprzę­tu sie­cio­we­go powi­nien zawie­rać poza deale­ra­mi tak­że kanał infor­ma­cyj­ny, któ­rym prze­ka­zu­je­my spe­cjal­nie wyko­na­ne biblio­te­ki sym­bo­li dla pro­jek­tan­tów sie­ci, któ­rzy nie­ja­ko naga­nia­ją” popyt na nasze pro­duk­ty. Nie zapo­mi­naj­my też, że obsłu­ga ser­wi­so­wa to tak­że nasz produkt.

Mapa pro­ce­sów biznesowych

To obraz przed­sta­wia­ją­cy wszyst­kie funk­cje jakie wewnątrz orga­ni­za­cji są reali­zo­wa­ne w celu wytwo­rze­nia final­ne­go pro­duk­tu (lub pro­duk­tów). Do zobra­zo­wa­nia mapy pro­ce­sów powin­na wystar­czyć sym­bo­li­ka ICOM. Bardziej roz­bu­do­wa­ne sys­te­my mode­lo­wa­nia pozwa­la­ją dodat­ko­wo na zarzą­dza­nie takim pro­jek­tem, defi­nio­wa­nie szcze­gó­łów zaso­bów i opi­sa­nie ich kore­la­cji z procedurami.

Produktem może być przed­miot ale tak­że usłu­ga. Wszystko co ma cechy i cenę oraz przed­sta­wia jakąś war­tość dla kupu­ją­ce­go jest pro­duk­tem. Cechą funk­cji na mapie pro­ce­sów jest jej ist­nie­nie i brak moż­li­wo­ści pomi­nię­cia. Np. pro­ces wyda­wa­nia decy­zji w Urzędzie jest reali­zo­wa­ny bo decy­zja zawsze musi się poja­wić w odpo­wie­dzi na zło­że­nie poda­nie o jej wyda­nie. Może ona być pozy­tyw­na lub nega­tyw­na, może wyma­gać opi­nii bie­głe­go lub nie, może wyma­gać spraw­dze­nia wcze­śniej­szych innych decy­zji itp. To jed­nak okre­śla pro­ce­du­ra wyda­wa­nia decy­zji. Proces jest niezmienny.

Mapa prze­pły­wu pracy

Procedury to wła­śnie opi­sy spo­so­bu reali­za­cji funk­cji opi­sa­nych przez pro­ce­sy. Tu dopie­ro jest miej­sce na rom­by”. Procedurami defi­niu­je się np. spo­sób pra­cy sys­te­mów obie­gu doku­men­tów (infor­ma­cji) w fir­mach. Procedura to jeden z ele­men­tów nazy­wa­nych Controll w defi­ni­cji pro­ce­su. Procedury są opi­sy­wa­ne za pomo­cą sym­bo­li takich jak czyn­ność, decy­zja, doku­ment, inter­fejs itp.

Na zakoń­cze­nie

Ten krót­ki arty­kuł to przede wszyst­kim prze­stro­ga przed nad­mier­nym zaufa­niem dla nie­któ­rych firm ofe­ru­ją­cych usłu­gi wdro­że­nio­we i dorad­cze. Niestety na ryn­ku tym, jak na każ­dym innym, jest dużo niskiej jako­ści” a przede wszyst­kim chęć zara­bia­nia a nie­chęć do ucze­nia się i stu­dio­wa­nia. Modelowanie to dość trud­na dzie­dzi­na wie­dzy. Porównał bym ja do pra­cy copyw­ri­te­ra. Nie ma zna­cze­nia ile cza­su nad tym spę­dził zna­cze­nie ma jakiej jako­ści tekst napi­sał. Bywa, że po mie­sią­cu otrzy­ma­my rewe­la­cyj­ne jed­noz­da­nio­we hasło rekla­mo­we. W mode­lo­wa­niu biz­ne­so­wym mamy do czy­nie­nia z podob­nym zja­wi­skiem. Czasami wie­le dni cięż­kiej pra­cy owo­cu­je kil­ko­ma stro­na­mi kom­plet­ne­go, spój­ne­go i zro­zu­mia­łe­go dla kadry opi­su firmy.

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łaganu.

W przy­go­to­wa­niu mam dla Państwa bogat­sze opra­co­wa­nie na temat mode­lo­wa­nia i metod sto­so­wa­nych do tego celu. Dodatkowe mate­ria­ły zgro­ma­dzi­łem dla Państwa tu: https://​it​-con​sul​ting​.pl/​p​u​b​/​C​a​s​e​S​t​u​dy/

Dostępne na ryn­ku narzę­dzia do modelowania

Na ryn­ku jest wie­le dobrych narzę­dzi wspie­ra­ją­cych two­rze­nie dia­gra­mów i mode­lo­wa­nie. W prost­szych przy­pad­kach z powo­dze­niem moż­na sto­so­wać np. pakiet MS Visio i biblio­te­kę IDEF0 lub audit dia­gram. Jednak do poważ­niej­szych pro­jek­tów dla dużych orga­ni­za­cji pro­wa­dzo­nych w gru­pach zada­nio­wych i wyma­ga­ją­cych kon­tro­li spój­no­ści dia­gra­mów wyma­ga­ne jest zasto­so­wa­nie narzę­dzi wspie­ra­ją­cych dodat­ko­wo pra­ce w gru­pie, wer­sjo­no­wa­nie, symu­la­cje oraz moż­li­wość inte­gra­cji w mode­lu tak­że pro­jek­tów zwią­za­nych z zarzą­dza­niem kosz­ta­mi pro­ce­sów. Cechą wie­lu sys­te­mów do wspo­ma­ga­nia mode­lo­wa­nia jest moż­li­wość ich inte­gra­cji z apli­ka­cja­mi ERP. Nowoczesne sys­te­mu kla­sy ERP to sys­te­my o pro­ce­so­wej orga­ni­za­cji. Pozwalają one na import wyko­na­nej mapy pro­ce­sów co zna­ko­mi­cie uspraw­nia i skra­ca wdro­że­nie sys­te­mu oraz obni­ża jego koszt. Można tu pole­cić pakiet ARIS opra­co­wa­ny i ofe­ro­wa­ny przez IDS Scheer.

Jako kon­sul­tant pro­wa­dzę tak­że pro­jek­ty zwią­za­ne z wybo­rem sys­te­mu infor­ma­tycz­ne­go nie wią­że się jed­nak z żad­nym z jego dostaw­ców na ryn­ku. Narzędzia słu­żą­ce do mode­lo­wa­nia wspie­ra­ją te dzia­ła­nia dla­te­go wymie­niam tu te, któ­rych uży­wam. Ich wybór jest podyk­to­wa­ny sku­tecz­no­ścią z jaką wspie­ra­ją pra­cę np. moją. Nie deter­mi­nu­ją one tego jakie­go sys­te­mu wspie­ra­ją­ce­go zarzą­dza­nie uży­je­my w przy­szło­ści po wyko­na­niu ana­li­zy i czy w ogó­le. Jako prak­tyk jed­nak spo­koj­nie mogę pole­cić pro­gra­my, któ­rych sam używam.

Na rynek wcho­dzi [[nota­cja BPMN]], wyglą­da na to, że sta­nie się standardem.

Zasoby IT a procesy przetwarzania informacji

Wielu moich klien­tów pyta o pro­ce­sy biz­ne­so­we i miej­sce infor­ma­ty­ki w zarzą­dza­niu fir­mą. Otóż infor­ma­ty­ka słu­ży tyl­ko do obsłu­gi pro­ce­su prze­twa­rza­nia infor­ma­cji w fir­mie. Nie jest sama w sobie procesem.

Zarządzanie fir­mą

to podej­mo­wa­ne decy­zji i wybo­rów. Ale czy zawsze są one zwią­za­ne z bran­żą i ryn­kiem na jakim fir­ma wal­czy o życie?

Dobry mene­dżer radzi sobie z pro­ble­ma­mi zwią­za­ny­mi z zarzą­dza­niem a jeśli pro­blem doty­czy innej dziedziny?

W obec­nych cza­sach infor­ma­cja to towar tak potrzeb­ny jak pie­niądz a bywa, że bar­dziej. Narzędzia i wie­dza uży­wa­ne do pra­cy z infor­ma­cją powin­ny być ade­kwat­ne do jej zna­cze­nia i war­to­ści dla fir­my. Informacja to zawar­ta danych war­tość koniecz­na do pra­cy każ­dej fir­my. Dane takie jak lista pra­cow­ni­ków wraz z fak­tam­ni z okre­su ich pra­cy zawie­ra­ją infor­ma­cje potrzeb­ne do pra­wi­dło­wej ich oce­ny i wypła­ty wyna­gro­dze­nia. Dane o sprze­da­ży zawie­ra­ją infor­ma­cje o kon­tra­hen­tach, ich pre­fe­ren­cjach, ich war­to­ści dla fir­my. Przykłady moż­na mno­żyć w nie­skoń­czo­ność. Ale co tak na praw­dę jest potrzeb­ne fir­mie? Dane, infor­ma­cje, może coś innego…Po co prze­twa­rza­my te informacje?

Zarządzanie infor­ma­cją

Często prze­twa­rza­nie infor­ma­cji koja­rzo­ne jest tyl­ko z kom­pu­te­ra­mi i wybra­nym opro­gra­mo­wa­niem. Nic bar­dziej myl­ne­go! To tyl­ko jeden z pro­ce­sów w fir­mie. Podobnie rzecz się ma z inny­mi. Ale jak je ziden­ty­fi­ko­wać? Jak ocenić?

Dokładnie przyj­rzeć się firmie

Jak? Narysuje Państwu fir­mę w spo­sób spraw­dzo­ny na świe­cie. Posługuję się meto­do­lo­gią, któ­ra powsta­ła w USA do celów mode­lo­wa­nia pro­ce­sów, sys­te­mów lub obiek­tów orga­ni­za­cyj­nych. Metodyka nazy­wa się IDEF0, zosta­ła opi­sa­na i zde­fi­nio­wa­na przez U.S Air Force i od 1981 powszech­nie sto­so­wa­na jako meto­da mode­lo­wa­nia. W tej meto­dzie two­rzo­ny jest bar­dzo ogól­ny model fir­my a następ­nie jest on dekom­po­no­wa­ny na kolej­ne pro­ce­sy skła­do­we. Zasadą tej spraw­dzo­nej na świe­cie meto­dy jest pro­ce­so­we podej­ście do opi­su przed­się­bior­stwa (pro­jek­tu). Podstawową zasa­dą jest zało­że­nie, że przed­się­bior­stwo jest pro­ce­sem. Proces ten prze­kształ­ca (prze­twa­rza) pobie­ra­ne dobra tak by prze­two­rzyć, pod­nieść ich war­tość i prze­ka­zać do następ­ne­go pro­ce­su jakim może być np. inna fir­ma lub koń­co­wy odbior­ca przed­mio­tu na rynku.

W powyż­szy spo­sób moż­na przed­sta­wić prak­tycz­nie każ­dą fir­mę. A co dalej? Kolejny krok to dekom­po­zy­cja do posta­ci np. takiej:

Tego typu mode­lo­wa­nie jest pod­sta­wą pro­ce­su zwa­ne­go rein­ży­nie­rią. Na bazie dobrze wyko­na­ne­go mode­lu fir­my sto­sun­ko­wo łatwo jest np. okre­ślić zakres przy­szłe­go pro­jek­tu infor­ma­tycz­ne­go albo wska­zać źró­dła danych do okre­śle­nia ren­tow­no­ści pro­jek­tu infor­ma­tycz­ne­go czy­li ROI (sto­py zwro­tu z inwestycji).

Są tacy, któ­rzy uwa­ża­ją, że inwe­sty­cji w tech­no­lo­gie IT nie da sie oce­niać w kate­go­riach zwro­tu inwe­sty­cji a ja pytam sko­ro nie to po co w nie inwestować?

System infor­ma­tycz­ny: czym jest

Najwięcej błę­dów w postrze­ga­niu roli sys­te­mu infor­ma­tycz­ne­go bie­rze się z trak­to­wa­nia go jako cze­goś z poza biz­ne­su fir­my bo jak ina­czej wytłu­ma­czyć twier­dze­nia nie­któ­rych ludzi, że sys­tem IT nie powi­nien pod­le­gać oce­nom zwro­tu z inwe­sty­cji? Posługując się powyż­szą meto­dą błąd ten moż­na zobra­zo­wać tak:

Poprawne spoj­rze­nie na fir­mę każe nam trak­to­wać tech­no­lo­gie IT na rów­ni z każ­dym innym kosz­tem i zaso­ba­mi a wte­dy wyglą­da to tak:

Różnicę widać od razu: pro­ce­so­we spoj­rze­nie na fir­mę jasno tłu­ma­czy, że zaso­by IT słu­żą tyl­ko do obsłu­gi pro­ce­su prze­twa­rza­nia infor­ma­cji w firmie.

Za zakoń­cze­nie

Ten krót­ki arty­kuł powstał na bazie kil­ku pytań jakie otrz­ma­łem od czy­tel­ni­ków ser­wi­su. Pytali o role sys­te­mu infor­ma­tycz­ne­go w fir­mie, o to jak oce­nić jego przy­dat­ność. Bez powyż­sze­go ana­li­tycz­ne­go podej­scia do roli IT w fir­mie trud­no jest wła­ści­wie wska­zać źró­dła kosz­tów i powią­zać je z przy­no­szo­ny­mi korzy­ścia­mi tak moż­łi­we było w ogó­le licze­nie takich wskaź­ni­kow jak ROI.

Mam nadzie­ję, że art­kuł ten wzbu­dzi u Państwa nie­po­kój służ­bo­wy” i spro­wo­ku­je do oce­ny zaso­bów wła­snej fir­my. Pokazana tu meto­dy­ka IDEF0 do mode­lo­wa­nia pro­ce­sów jest bar­dzo przy­dat­na. Szczególna jej zale­tą jest to, ze w zasa­dzie nie pozwa­la na błe­dy w iden­ty­fi­ka­cji pro­ce­sów i zaso­bów, któ­re wbrew pozo­rom są cze­sto mylo­ne. Pomyłki takie pro­wa­dzą do myl­nej iden­ty­fi­kaj­ci cen­trów kosz­tów, ich wpły­wu na pro­ce­sy funk­cjo­no­wa­nia fir­my i w kon­se­kwen­cji do dużych błe­dów pod­czas wdro­żeń a nawet do ich krachów.

Na temat meto­dy­ki IDEF0 oraz innej bar­dzo przy­dat­nej meto­dy rybich ości” (dia­gram Ishikawy) iden­ty­fi­ka­cji czyn­ni­ków wpły­wa­ją­cych na jakość poja­wi sięw nie­dłu­gim cza­sie kolej­ny arty­kuł. meto­dy­ki te bar­dzo poma­ga­ją w pro­ce­ach restruk­tu­ry­za­cji i uzdra­wia­nia pro­ce­sów zacho­dzą­cych w fir­mach. To pro­ce­sy a nie zaso­by będą­ce tyl­ko środ­ka­mi pro­duk­cji two­rzą war­tosć doda­ną. A na ryn­ku sprze­dać moż­na już tyl­ko war­tość dodaną.

Zainteresowanych tymi meto­da­mi mapo­wa­nia pro­ce­sów w fir­mie zapra­szam do pisa­nia listów do mnie.

Notatka: J.Ż. Styczeń 2003