Wiele firm mówi o mapowaniu procesów a opisuje tylko procedury i zasoby. Nie chcą czy może nie potrafią?

Wiele firm oferujących usługi doradcze, nawet te uznane na rynku, myli mapowanie i modelowanie procesów biznesowych z odzwierciedlaniem stanu organizacji pracy firmy w postaci procedur i opisu przepływu pracy. Pominięcie etapu opisu modelu firmy jeszcze w oderwaniu od systemu informatycznego jest moim zdaniem głównym powodem niepowodzeń wielu projektów.

Obecnie stale spotykam się z modelami wykonywanymi przez inżynierów systemowych zamiast analityków biznesowych. Używają oni do tego celu narzędzi do obiektowego modelowania elementów systemów informatycznych, które nie nadają się do modelowania zjawisk biznesowych w sposób zrozumiały dla menedżerów. DIAGRAMY UML i Use Case tak na prawdę opisują projektowany system a nie firmę, dla której on powstaje!

Nie jest moim celem negacja używania UML czy Use Case ani technologii obiektowych. W tym artykule przedstawię cele i korzyści z modelowania oraz granicę pomiędzy obszarami gdzie uzasadnione jest używanie UML a gdzie już ono uzasadnienia nie ma.

Proces a procedura

Proces: zespół czynności lub działań, których celem jest osiągnięcie oczekiwanego rezultatu. Rezultat ten jest osiągany poprzez przetworzenie stanu wejścia procesu w stan wyjściowy. Przetworzenie to sterowane jest za pomocą z góry ustalonych reguł. Do osiągnięcia tak określonego rezultatu wymagane zasoby.

Proces biznesowy: spójny zespół działań, których celem jest osiągnięcie określonej wartości w postaci produktu. Do wytworzenia produktu wymagane są: zasoby, inne produkty (półprodukty) oraz reguły (zasady) według których tworzony jest produkt. Produkt musi dać się opisać (zdefiniować) i być mierzalny.

W szczególności nie jest procesem to co ludzie robią a to co się dzieje, czyli seria działań zmierzających do wytworzenia nowej wartości (produktu). Np. w urzędzie procesem będzie wydanie decyzji na wniosek petenta. Wymagana seria czynności do tego potrzebna takich jak ocena formalna wniosku, jego ewentualne zwrócenie do poprawienia, opinia prawna oraz podjęcie decyzji zarówno pozytywnej jak i negatywnej to jest tylko przepływ pracy (procedury). Na wyjściu procesu pojawia się decyzja, wymagane zasoby to urzędnicy, poczta elektroniczna itp. reguły to przepisy prawa i regulaminy.

Procesy łączą się w łańcuchy. Zawsze jednak dla jednego procesu na wejściu znajduje się produkt będące efektem działania innego procesu. Mapa procesów zawiera tylko symbole procesów oraz interfejsy. Nie zawiera żadnych innych symboli w szczególności elementów decyzyjnych.

UWAGA! Specyfiką mapy procesów jest to, że produkt musi powstać. Dlatego mapa procesów nie zawiera symboli decyzji jak to ma miejscy przy opisie procedur czy przepływów pracy.

Mapa procesów

Jednym z prostszych i skuteczniejszych narzędzi do modelowania procesów jest właśnie standard IDEF0, odpowiada on dokładnie powyższym definicjom. Standard ma dodatkowo zdefiniowane sposoby dokumentowania map procesów w tym: sposób numerowania diagramów i stron, sposób prowadzenia i opisu interfejsów, sposób łączenia diagramów dekompozycji.

IDEF0 w swej konstrukcji bazuje na metodyce ICOM (Input, Control, Output, Mechanizm). Jak już wspomniano diagramy IDEF0 to nie są diagramy przepływów pracy. Jest to bardzo istotne, gdyż z punktu widzenia procesów biznesowych nie istotne jest to jak dany produkt jest wykonywany, istotne są cel i konieczność jego wytworzenia. To podstawowa równica pomiędzy procesem o przepływem! Opis realizacji czynności to właśnie procedury czyli diagramy przepływu pracy (ang. work flow).

IDEF0 to standard, którego korzenie sięgają 1950 roku. Powstał jako narzędzie budowy modeli biznesowych na użytek tworzenia aplikacji wspierających biznes. Rozwijał się poza środowiskiem technologii dlatego utrzymał swoją prostotę i łatwość przyswajania przez menedżerów. Był i jest skutecznym językiem pomiędzy biznesem a technologią.

Przejście od diagramu procesów do procedur jest naturalne. Procedury tworzy się tam, gdzie kończy się dekompozycja procesów na podprocesy. Inaczej mówiąc, jeżeli procesu nie da się podzielić na podprocesy to znaczy, że należy opisać czynności służące do jego realizacji czyli przepływy pracy (procedury).

Procedury i przepływy

Powyższy schemat to procedura (definicja przepływu pracy). Diagramy opisu procedur dopuszczają dodatkowe symbole oznaczające dokumenty, decyzje, procesy predefiniowane itp. Procedury można definiować jako sposób prosty tj, realizacji sekwencji czynności bez definiowanie zasobów (np. dotyczy jednego działu).

UML i Use Case

Odnosząc się do definicji Feldmana (WWW.devx.com): UML ? Unified Modeling Language: standard przemysłowy służący do specyfikacji, wizualizacji, konstrukcji i dokumentowania elementów ludzkiej pracy do celów tworzenia oprogramowania. UML służy programistom do ułatwienia procesu i rozwijania tworzenia oprogramowania. Ten akapit jest w niezgodzie z gramatyką(naszą)

UML skupia się na modelowaniu elementów oprogramowania.nie skupia się tylko jeest do… i niekoniecznie elementów Nie jest narzędziem opisu procesów są różne procesy i do wielu moze byc, w szczeg. Diagramy pokazujace co sie dzieje W CZASIE. Opis UML powinien być uzupełniony opisem procesów jako kontekstem projektu ??????. (specyfikacja OMG UML v.1.2)

Tyle definicje. Jak widać nie ma w niej słowa o biznesie i procesach. Skąd więc tak powszechne używanie UML w projektach biznesowych związanych z aplikacjami? Uważam, że jest to efekt dotychczasowego braku komunikacji pomiędzy biznesem a technologią. Dość powszechne technokratyczne podejście do tworzenia i implementacji systemów informatycznych owocuje moim zdaniem właśnie ponurymi statystykami nieudanych projektów.

Drugie źródło powyższych kłopotów to dość powszechna niechęć menedżerów do wgłębiania się w tajniki analizy systemowej i modelowania. Pytanie czy to konieczne? Wiedza ta do tej pory była potrzebna menedżerom rzadko. Okazuje się jednak, że konkurencja i coraz szybciej zmieniające się warunki na rynku nie dają szans na prowadzenie firmy w sposób polegający na pierwotnym wymyśleniu biznesu (pomysłu na produkt), jego wdrożeniu i utrzymywaniu. Jeżeli w ubiegłym wieku zmiany na rynku zachodziły w odstępach rzędu dekady tak obecnie zachodzą one w okresach mierzonych pojedynczymi latami a bywa że nawet kwartałami.

O Use Case nie bylo…

UML i Use Case powstały do dokumentowania zjawisk. Modelowanie to odzwierciedlanie stanu zastanego dla mnie bardzo niescisle. Technologie obiektowe to inżynieria oprogramowania a nie modelowane gospodarcze. Modelowanie to nie projektowanie a opisywanie. Projektowanie to wymyślanie nowego. Zjawiska gospodarcze i firmy charakteryzują się hierarchiczną strukturą i przepływową istotą zachodzących zdarzeń. Nie pasuje do tego strukturalny system baz danych i obiektowe narzędzia inżynierskie. Są one doskonałe do tworzenia kodu programu i magazynowania danych ale człowiek nie jest ani obiektowy ani strukturalny.tu jakies dalekie odniesienia- nie rozumiem

UML i Use Case tak na prawdę opisują projektowany system a nie firmę dla której on powstaje!

Czy znasz przyklady opisywania firmy- UML-em??

?Nie zauważyłem jednak jasnego połączenia gospodarczych z systemowymi przypadkami użycia. Zmartwi to tych, którzy szukają automatycznego sposobu wyprowadzania wymagań systemowych z??? procesów gospodarczych. Nie sądzę, żeby takie automatyczne wyprowadzenia były możliwe.? (Alistair Cockbourn, gooru projektowania oprogramowania, uznany na świecie specjalista od metodyki obiektowej, teorii wymagań i zarządzania przedsięwzięciami programistycznymi, patrz spis literatury).

Pytanie więc: co ułatwi prace na poziomie menedżera i analityka? Pełna dokumentacja UML którą mam to 540 stron. Opis normy IDEF0 to 79 stron z kompletem załączników.

Proces modelowania

W czym tkwi problem? Skuteczny system modelowania powinien być niezależny od technologii. Inaczej rzecz ujmując: kompletny model firmy powinien być możliwy do wykonania za pomocą ołówka na kartce papieru i nie powinien w żadnym stopniu determinować użytych w przyszłości narzędzi programistycznych lub gotowych i parametryzowalnych aplikacji.

Na powyższym schemacie przedstawiono istotę procesu modelowania, którego celem jest model procesów zrozumiały i zaakceptowany przez zarząd firmy (w końcu to także dla nich powstaje ta mapa!).

Modele referencyjne

Niezależnie od tego, że modelowanie to proces twórczy można przyjąć pewne nadrzędne schematy. Nie ma to nic wspólnego z tworzeniem ograniczeń a tylko z zaakceptowaniem, że pewne środowiska dają wskazówki do postępowania. Takim środowiskiem jest np. rynek. Oznacza to, że firma niezależnie od pomysłu na biznes i tego jaki by nie był on nowatorski musi np. przestrzegać pewnych reguł i zasad związanych z ekonomią, marketingiem, zjawiskami rynkowymi itp. Skoro tak to pewne reguły można uznać za uniwersalne dla danego środowiska. Model (np. procesów) odniesienia powstały na bazie takich warunków będziemy nazywali modelem referencyjnym.

W przypadku podmiotów gospodarczych można wyróżnić cztery podstawowe procesy:

Polemizowalabym ? z tymi 4 podstawowymi

1. tworzenie nowych produktów
2. zdobywanie nowych zamówień
3. realizacja zamówień
4. obsługa klienta

Wymienione procesy tworzą łańcuch podstawowy. Pozostałe procesy występujące w firmie (np. naliczanie płac, rozliczenia z dostawcami itp. służą jako wsparcie??? procesów głównych).

Powyższy przykład obrazuje prostą mapę procesów. Zawiera on cztery główne procesy oraz wybrany proces wspomagający (usługi prawne) a także zaznaczenie jednego z zasobów, tu system IT. Omówmy po kolei te mapę.

Proces tworzenia produktów. Jego celem jest dostarczenie dóbr będących przedmiotem sprzedaży. Mogą to być usługi, przedmioty itp. Nie ma tu (na tym etapie) znaczenia czy jest to produkcja czy zakupy do dalszej odsprzedaży czy też definiowanie usługi i zabezpieczenie możliwości jej świadczenia.

Wyjście tego procesu to oczywiście produkt, który opuszcza firma ale także informacje o produkcie (jego cechy, koszt wytworzenia itp.) przekazywane do procesu sprzedaży.

Zdobywanie zamówień. Proces ten dostaje na wejściu informacje z rynku oraz z procesu tworzenia produktów. Wyjście procesu to: oferty kierowane na rynek, umowy sprzedaży przekazywane do procesu obsługującego sprawy prawne oraz informacje o zamówieniach przekazywane do procesu realizacji zamówień.

Realizacja zamówień to przede wszystkim logistyka. Na wejście procesu docierają zamówienia do realizacji na wyjściu zaś pojawiają się informacje przekazywane do procesu obsługi klienta o stanie realizacji.

Proces obsługujący sprawy prawne obrazuje przykład, w którym dane wyjściowe sterują innymi procesami. W tym przypadku mogą to być treści umów, które wyznaczają sposób realizacji zamówienia a potem obsługi klienta (np. obsługę reklamacji).

Systemy IT pokazano by zobrazować zasady umieszczania zasobów w modelu procesów. Zasobami tymi są także pracownicy. Jednak dział personalny to osobny proces (odrębny łańcuch), którego celem jest zarządzanie zasobami ludzkimi. Nie jest on traktowany podobnie jak zasoby IT. ???????/

Powyższy przykład to tylko wybrany model referencyjny firm działających na rynku. W przypadku urzędów publicznych będzie to zupełnie innym model podobnie jak w przypadku placówek służby zdrowia.

Literatura:

Opracowanie powstało na bazie doświadczeń i praktyki autora. Celem tego spisu jest wskazanie źródeł informacji mogących pomóc czytelnikowi w poszerzeniu prezentowanej tu wiedzy. Użyte definicje pojęć pochodzą 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 informatyki gospodarczej: Modele referencyjne w zarządzaniu procesami biznesu. Praca zbiorowa pod redakcją naukową 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ć efektywne przypadki użycia. Alistair Cockbourn. WNT, Warszawa 2004.
9. Radykalna reorganizacja firmy. Charlene B. Adair, Bruce A. Murray. PWN, Warszawa 2001.
10. Serwis internetowy: WWW.devx.com
11. Serwis internetowy: WWW.idef.com