Wiele firm mówi o mapo­wa­niu pro­ce­sów a opi­su­je tyl­ko pro­ce­du­ry i zaso­by. Nie chcą czy może nie potrafią? 

Wiele firm ofe­ru­ją­cych usłu­gi dorad­cze, nawet te uzna­ne na ryn­ku, myli mapo­wa­nie i mode­lo­wa­nie pro­ce­sów biz­ne­so­wych z odzwier­cie­dla­niem sta­nu orga­ni­za­cji pra­cy fir­my w posta­ci pro­ce­dur i opi­su prze­pły­wu pra­cy. Pominięcie eta­pu opi­su mode­lu fir­my jesz­cze w ode­rwa­niu od sys­te­mu infor­ma­tycz­ne­go jest moim zda­niem głów­nym powo­dem nie­po­wo­dzeń wie­lu projektów. 

Obecnie sta­le spo­ty­kam się z mode­la­mi wyko­ny­wa­ny­mi przez inży­nie­rów sys­te­mo­wych zamiast ana­li­ty­ków biz­ne­so­wych. Używają oni do tego celu narzę­dzi do obiek­to­we­go mode­lo­wa­nia ele­men­tów sys­te­mów infor­ma­tycz­nych, któ­re nie nada­ją się do mode­lo­wa­nia zja­wisk biz­ne­so­wych w spo­sób zro­zu­mia­ły dla mene­dże­rów. DIAGRAMY UML i Use Case tak na praw­dę opi­su­ją pro­jek­to­wa­ny sys­tem a nie fir­mę, dla któ­rej on powstaje! 

Nie jest moim celem nega­cja uży­wa­nia UML czy Use Case ani tech­no­lo­gii obiek­to­wych. W tym arty­ku­le przed­sta­wię cele i korzy­ści z mode­lo­wa­nia oraz gra­ni­cę pomię­dzy obsza­ra­mi gdzie uza­sad­nio­ne jest uży­wa­nie UML a gdzie już ono uza­sad­nie­nia nie ma. 

Proces a procedura

Proces: 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 zasoby. 

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 (pół­pro­duk­ty) 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. 

W szcze­gól­no­ści nie jest pro­ce­sem to co ludzie robią a to co się dzie­je, czy­li seria dzia­łań zmie­rza­ją­cych do wytwo­rze­nia nowej war­to­ści (pro­duk­tu). Np. w urzę­dzie pro­ce­sem będzie wyda­nie decy­zji na wnio­sek peten­ta. Wymagana seria czyn­no­ści do tego potrzeb­na takich jak oce­na for­mal­na wnio­sku, jego ewen­tu­al­ne zwró­ce­nie do popra­wie­nia, opi­nia praw­na oraz pod­ję­cie decy­zji zarów­no pozy­tyw­nej jak i nega­tyw­nej to jest tyl­ko prze­pływ pra­cy (pro­ce­du­ry). Na wyj­ściu pro­ce­su poja­wia się decy­zja, wyma­ga­ne zaso­by to urzęd­ni­cy, pocz­ta elek­tro­nicz­na itp. regu­ły to prze­pi­sy pra­wa i regulaminy. 

Procesy łączą się w łań­cu­chy. Zawsze jed­nak dla jed­ne­go pro­ce­su na wej­ściu znaj­du­je się pro­dukt będą­ce efek­tem dzia­ła­nia inne­go pro­ce­su. Mapa pro­ce­sów zawie­ra tyl­ko sym­bo­le pro­ce­sów oraz inter­fej­sy. Nie zawie­ra żad­nych innych sym­bo­li w szcze­gól­no­ści ele­men­tów decyzyjnych. 

UWAGA! Specyfiką mapy pro­ce­sów jest to, że pro­dukt musi powstać. Dlatego mapa pro­ce­sów nie zawie­ra sym­bo­li decy­zji jak to ma miej­scy przy opi­sie pro­ce­dur czy prze­pły­wów pracy. 

Mapa procesów

Jednym z prost­szych i sku­tecz­niej­szych narzę­dzi do mode­lo­wa­nia pro­ce­sów jest wła­śnie stan­dard IDEF0, odpo­wia­da on dokład­nie powyż­szym defi­ni­cjom. Standard ma dodat­ko­wo zde­fi­nio­wa­ne spo­so­by doku­men­to­wa­nia map pro­ce­sów w tym: spo­sób nume­ro­wa­nia dia­gra­mów i stron, spo­sób pro­wa­dze­nia i opi­su inter­fej­sów, spo­sób łącze­nia dia­gra­mów dekompozycji. 

IDEF0 w swej kon­struk­cji bazu­je na meto­dy­ce ICOM (Input, Control, Output, Mechanizm). Jak już wspo­mnia­no dia­gra­my IDEF0 to nie są dia­gra­my prze­pły­wów pra­cy. Jest to bar­dzo istot­ne, gdyż z punk­tu widze­nia pro­ce­sów biz­ne­so­wych nie istot­ne jest to jak dany pro­dukt jest wyko­ny­wa­ny, istot­ne są cel i koniecz­ność jego wytwo­rze­nia. To pod­sta­wo­wa rów­ni­ca pomię­dzy pro­ce­sem o prze­pły­wem! Opis reali­za­cji czyn­no­ści to wła­śnie pro­ce­du­ry czy­li dia­gra­my prze­pły­wu pra­cy (ang. work flow). 

IDEF0 to stan­dard, któ­re­go korze­nie się­ga­ją 1950 roku. Powstał jako narzę­dzie budo­wy mode­li biz­ne­so­wych na uży­tek two­rze­nia apli­ka­cji wspie­ra­ją­cych biz­nes. Rozwijał się poza śro­do­wi­skiem tech­no­lo­gii dla­te­go utrzy­mał swo­ją pro­sto­tę i łatwość przy­swa­ja­nia przez mene­dże­rów. Był i jest sku­tecz­nym języ­kiem pomię­dzy biz­ne­sem a technologią. 

Przejście od dia­gra­mu pro­ce­sów do pro­ce­dur jest natu­ral­ne. Procedury two­rzy się tam, gdzie koń­czy się dekom­po­zy­cja pro­ce­sów na pod­pro­ce­sy. Inaczej mówiąc, jeże­li pro­ce­su nie da się podzie­lić na pod­pro­ce­sy to zna­czy, że nale­ży opi­sać czyn­no­ści słu­żą­ce do jego reali­za­cji czy­li prze­pły­wy pra­cy (pro­ce­du­ry).

Procedury i przepływy

Powyższy sche­mat to pro­ce­du­ra (defi­ni­cja prze­pły­wu pra­cy). Diagramy opi­su pro­ce­dur dopusz­cza­ją dodat­ko­we sym­bo­le ozna­cza­ją­ce doku­men­ty, decy­zje, pro­ce­sy pre­de­fi­nio­wa­ne itp. Procedury moż­na defi­nio­wać jako spo­sób pro­sty tj, reali­za­cji sekwen­cji czyn­no­ści bez defi­nio­wa­nie zaso­bów (np. doty­czy jed­ne­go działu). 

UML i Use Case

Odnosząc się do defi­ni­cji Feldmana (WWW​.devx​.com): UML ? Unified Modeling Language: stan­dard prze­my­sło­wy słu­żą­cy do spe­cy­fi­ka­cji, wizu­ali­za­cji, kon­struk­cji i doku­men­to­wa­nia ele­men­tów ludz­kiej pra­cy do celów two­rze­nia opro­gra­mo­wa­nia. UML słu­ży pro­gra­mi­stom do uła­twie­nia pro­ce­su i roz­wi­ja­nia two­rze­nia opro­gra­mo­wa­nia. Ten aka­pit jest w nie­zgo­dzie z gramatyką(naszą)

UML sku­pia się na mode­lo­wa­niu ele­men­tów opro­gra­mo­wa­nia.nie sku­pia się tyl­ko jeest do… i nie­ko­niecz­nie ele­men­tów Nie jest narzę­dziem opi­su pro­ce­sów są róż­ne pro­ce­sy i do wie­lu moze byc, w szczeg. Diagramy poka­zu­ja­ce co sie dzie­je W CZASIE. Opis UML powi­nien być uzu­peł­nio­ny opi­sem pro­ce­sów jako kon­tek­stem pro­jek­tu ??????. (spe­cy­fi­ka­cja OMG UML v.1.2)

Tyle defi­ni­cje. Jak widać nie ma w niej sło­wa o biz­ne­sie i pro­ce­sach. Skąd więc tak powszech­ne uży­wa­nie UML w pro­jek­tach biz­ne­so­wych zwią­za­nych z apli­ka­cja­mi? Uważam, że jest to efekt dotych­cza­so­we­go bra­ku komu­ni­ka­cji pomię­dzy biz­ne­sem a tech­no­lo­gią. Dość powszech­ne tech­no­kra­tycz­ne podej­ście do two­rze­nia i imple­men­ta­cji sys­te­mów infor­ma­tycz­nych owo­cu­je moim zda­niem wła­śnie ponu­ry­mi sta­ty­sty­ka­mi nie­uda­nych projektów. 

Drugie źró­dło powyż­szych kło­po­tów to dość powszech­na nie­chęć mene­dże­rów do wgłę­bia­nia się w taj­ni­ki ana­li­zy sys­te­mo­wej i mode­lo­wa­nia. Pytanie czy to koniecz­ne? Wiedza ta do tej pory była potrzeb­na mene­dże­rom rzad­ko. Okazuje się jed­nak, że kon­ku­ren­cja i coraz szyb­ciej zmie­nia­ją­ce się warun­ki na ryn­ku nie dają szans na pro­wa­dze­nie fir­my w spo­sób pole­ga­ją­cy na pier­wot­nym wymy­śle­niu biz­ne­su (pomy­słu na pro­dukt), jego wdro­że­niu i utrzy­my­wa­niu. Jeżeli w ubie­głym wie­ku zmia­ny na ryn­ku zacho­dzi­ły w odstę­pach rzę­du deka­dy tak obec­nie zacho­dzą one w okre­sach mie­rzo­nych poje­dyn­czy­mi lata­mi a bywa że nawet kwartałami. 

O Use Case nie bylo… 

UML i Use Case powsta­ły do doku­men­to­wa­nia zja­wisk. Modelowanie to odzwier­cie­dla­nie sta­nu zasta­ne­go dla mnie bar­dzo nie­sci­sle. Technologie obiek­to­we to inży­nie­ria opro­gra­mo­wa­nia a nie mode­lo­wa­ne gospo­dar­cze. Modelowanie to nie pro­jek­to­wa­nie a opi­sy­wa­nie. Projektowanie to wymy­śla­nie nowe­go. Zjawiska gospo­dar­cze i fir­my cha­rak­te­ry­zu­ją się hie­rar­chicz­ną struk­tu­rą i prze­pły­wo­wą isto­tą zacho­dzą­cych zda­rzeń. Nie pasu­je do tego struk­tu­ral­ny sys­tem baz danych i obiek­to­we narzę­dzia inży­nier­skie. Są one dosko­na­łe do two­rze­nia kodu pro­gra­mu i maga­zy­no­wa­nia danych ale czło­wiek nie jest ani obiek­to­wy ani struk­tu­ral­ny.tu jakies dale­kie odnie­sie­nia- nie rozumiem

UML i Use Case tak na praw­dę opi­su­ją pro­jek­to­wa­ny sys­tem a nie fir­mę dla któ­rej on powstaje! 

Czy znasz przy­kla­dy opi­sy­wa­nia fir­my- UML-em?? 

?Nie zauwa­ży­łem jed­nak jasne­go połą­cze­nia gospo­dar­czych z sys­te­mo­wy­mi przy­pad­ka­mi uży­cia. Zmartwi to tych, któ­rzy szu­ka­ją auto­ma­tycz­ne­go spo­so­bu wypro­wa­dza­nia wyma­gań sys­te­mo­wych z??? pro­ce­sów gospo­dar­czych. Nie sądzę, żeby takie auto­ma­tycz­ne wypro­wa­dze­nia były moż­li­we.? (Alistair Cockbourn, gooru pro­jek­to­wa­nia opro­gra­mo­wa­nia, uzna­ny na świe­cie spe­cja­li­sta od meto­dy­ki obiek­to­wej, teo­rii wyma­gań i zarzą­dza­nia przed­się­wzię­cia­mi pro­gra­mi­stycz­ny­mi, patrz spis literatury). 

Pytanie więc: co uła­twi pra­ce na pozio­mie mene­dże­ra i ana­li­ty­ka? Pełna doku­men­ta­cja UML któ­rą mam to 540 stron. Opis nor­my IDEF0 to 79 stron z kom­ple­tem załączników. 

Proces modelowania

W czym tkwi pro­blem? Skuteczny sys­tem mode­lo­wa­nia powi­nien być nie­za­leż­ny od tech­no­lo­gii. Inaczej rzecz ujmu­jąc: kom­plet­ny model fir­my powi­nien być moż­li­wy do wyko­na­nia za pomo­cą ołów­ka na kart­ce papie­ru i nie powi­nien w żad­nym stop­niu deter­mi­no­wać uży­tych w przy­szło­ści narzę­dzi pro­gra­mi­stycz­nych lub goto­wych i para­me­try­zo­wal­nych aplikacji. 

Na powyż­szym sche­ma­cie przed­sta­wio­no isto­tę pro­ce­su mode­lo­wa­nia, któ­re­go celem jest model pro­ce­sów zro­zu­mia­ły i zaak­cep­to­wa­ny przez zarząd fir­my (w koń­cu to tak­że dla nich powsta­je ta mapa!). 

Modele referencyjne

Niezależnie od tego, że mode­lo­wa­nie to pro­ces twór­czy moż­na przy­jąć pew­ne nad­rzęd­ne sche­ma­ty. Nie ma to nic wspól­ne­go z two­rze­niem ogra­ni­czeń a tyl­ko z zaak­cep­to­wa­niem, że pew­ne śro­do­wi­ska dają wska­zów­ki do postę­po­wa­nia. Takim śro­do­wi­skiem jest np. rynek. Oznacza to, że fir­ma nie­za­leż­nie od pomy­słu na biz­nes i tego jaki by nie był on nowa­tor­ski musi np. prze­strze­gać pew­nych reguł i zasad zwią­za­nych z eko­no­mią, mar­ke­tin­giem, zja­wi­ska­mi ryn­ko­wy­mi itp. Skoro tak to pew­ne regu­ły moż­na uznać za uni­wer­sal­ne dla dane­go śro­do­wi­ska. Model (np. pro­ce­sów) odnie­sie­nia powsta­ły na bazie takich warun­ków będzie­my nazy­wa­li mode­lem referencyjnym. 

W przy­pad­ku pod­mio­tów gospo­dar­czych moż­na wyróż­nić czte­ry pod­sta­wo­we procesy: 

Polemizowalabym ? z tymi 4 podstawowymi

1. two­rze­nie nowych produktów 
2. zdo­by­wa­nie nowych zamówień 
3. reali­za­cja zamówień 
4. obsłu­ga klienta 

Wymienione pro­ce­sy two­rzą łań­cuch pod­sta­wo­wy. Pozostałe pro­ce­sy wystę­pu­ją­ce w fir­mie (np. nali­cza­nie płac, roz­li­cze­nia z dostaw­ca­mi itp. słu­żą jako wspar­cie??? pro­ce­sów głównych). 

Powyższy przy­kład obra­zu­je pro­stą mapę pro­ce­sów. Zawiera on czte­ry głów­ne pro­ce­sy oraz wybra­ny pro­ces wspo­ma­ga­ją­cy (usłu­gi praw­ne) a tak­że zazna­cze­nie jed­ne­go z zaso­bów, tu sys­tem IT. Omówmy po kolei te mapę. 

Proces two­rze­nia pro­duk­tów. Jego celem jest dostar­cze­nie dóbr będą­cych przed­mio­tem sprze­da­ży. Mogą to być usłu­gi, przed­mio­ty itp. Nie ma tu (na tym eta­pie) zna­cze­nia czy jest to pro­duk­cja czy zaku­py do dal­szej odsprze­da­ży czy też defi­nio­wa­nie usłu­gi i zabez­pie­cze­nie moż­li­wo­ści jej świadczenia. 

Wyjście tego pro­ce­su to oczy­wi­ście pro­dukt, któ­ry opusz­cza fir­ma ale tak­że infor­ma­cje o pro­duk­cie (jego cechy, koszt wytwo­rze­nia itp.) prze­ka­zy­wa­ne do pro­ce­su sprzedaży. 

Zdobywanie zamó­wień. Proces ten dosta­je na wej­ściu infor­ma­cje z ryn­ku oraz z pro­ce­su two­rze­nia pro­duk­tów. Wyjście pro­ce­su to: ofer­ty kie­ro­wa­ne na rynek, umo­wy sprze­da­ży prze­ka­zy­wa­ne do pro­ce­su obsłu­gu­ją­ce­go spra­wy praw­ne oraz infor­ma­cje o zamó­wie­niach prze­ka­zy­wa­ne do pro­ce­su reali­za­cji zamówień. 

Realizacja zamó­wień to przede wszyst­kim logi­sty­ka. Na wej­ście pro­ce­su docie­ra­ją zamó­wie­nia do reali­za­cji na wyj­ściu zaś poja­wia­ją się infor­ma­cje prze­ka­zy­wa­ne do pro­ce­su obsłu­gi klien­ta o sta­nie realizacji. 

Proces obsłu­gu­ją­cy spra­wy praw­ne obra­zu­je przy­kład, w któ­rym dane wyj­ścio­we ste­ru­ją inny­mi pro­ce­sa­mi. W tym przy­pad­ku mogą to być tre­ści umów, któ­re wyzna­cza­ją spo­sób reali­za­cji zamó­wie­nia a potem obsłu­gi klien­ta (np. obsłu­gę reklamacji). 

Systemy IT poka­za­no by zobra­zo­wać zasa­dy umiesz­cza­nia zaso­bów w mode­lu pro­ce­sów. Zasobami tymi są tak­że pra­cow­ni­cy. Jednak dział per­so­nal­ny to osob­ny pro­ces (odręb­ny łań­cuch), któ­re­go celem jest zarzą­dza­nie zaso­ba­mi ludz­ki­mi. Nie jest on trak­to­wa­ny podob­nie jak zaso­by IT. ???????/ 

Powyższy przy­kład to tyl­ko wybra­ny model refe­ren­cyj­ny firm dzia­ła­ją­cych na ryn­ku. W przy­pad­ku urzę­dów publicz­nych będzie to zupeł­nie innym model podob­nie jak w przy­pad­ku pla­có­wek służ­by zdrowia. 

Literatura:

Opracowanie powsta­ło na bazie doświad­czeń i prak­ty­ki auto­ra. Celem tego spi­su jest wska­za­nie źró­deł infor­ma­cji mogą­cych pomóc czy­tel­ni­ko­wi w posze­rze­niu pre­zen­to­wa­nej tu wie­dzy. Użyte defi­ni­cje pojęć pocho­dzą z poniż­szych źródeł. 

1. ?Introduction to Business Process Reengineering and Its Common Tools (Use Case and Modeling)?, STC Annual Conference, Nashville, Tennessee, UID 10A, Session Materials. Rebecca Edgerton, Woolpert LLP?????? 
2. ?Delivering Results: Evolving BPR from Art to Engineering?, Richard J. Mayerm PhD., Associate Professor Department of Industrial Engineering Texas A&M University, College Station, Texas; Paula S. deWitte, PhD., Executive Vice President Knowledge Based Systems, Inc. College Station, Texas. ma byc źró­dlo nie adres!! 
3. Draft Federal Information Processing Standards Publication 183. 1993 December 21, Announcing the Standard for Integration Definition for Function Modeling (IDEF0).
4. OMG Unified Modeling Language Specification. V.1.2 1997. 
5. Studia infor­ma­ty­ki gospo­dar­czej: Modele refe­ren­cyj­ne w zarzą­dza­niu pro­ce­sa­mi biz­ne­su. Praca zbio­ro­wa pod redak­cją nauko­wą Tadeusza Kasprzaka., Difin, Warszawa 2005. 
6. Process Rengineering: Optymalizacja Procesów Zorientowanych na Klienta. Roland Muller, Peter Rupper. ASTRUM, Wrocław 2000. 
7. Strategie Konkurencji. Dawid Faulkner, Cliff Bosman. Gebethner & S‑ka. Warszawa 1996. 
8. Inżynieria Oprogramowania: Jak pisać efek­tyw­ne przy­pad­ki uży­cia. Alistair Cockbourn. WNT, Warszawa 2004. 
9. Radykalna reor­ga­ni­za­cja fir­my. Charlene B. Adair, Bruce A. Murray. PWN, Warszawa 2001. 
10. Serwis inter­ne­to­wy: WWW​.devx​.com
11. Serwis inter­ne­to­wy: WWW​.idef​.com