Kluczowe błędy jakie obserwuję w prezentowanych mi nie raz przez klientów do audytu cudzych opracowaniach i modelach to moim zdaniem zupełnie zbędne opisy i modele czynności oczywistych, będących kompetencją pracownika lub po prostu zwyczajowych lub co gorsza są to niepotrzebne modele posiadanych instrukcji obsługi i podręczników użytkownika sprzętu lub używanego oprogramowania. Drugim często spotykanym błędem jest zupełny brak metodyki tworzenia modelu czyli brak tego o czym już nie raz wspominałem: semantyki i syntaktyki modelu. Inaczej mówiąc model musi mieć określony słownik symboli i zasady ich łączenia. Rozumiem, że błędne modele wykonują niedoświadczeni analitycy. Jednak szkolne błędy obserwuję w pracach ludzi i firm biorących za to pieniądze, nie raz bardzo duże.  Nie raz są to niestety posiadające światową markę firmy doradcze.

Uważam, że najprościej jest stosować standardy.  Np. do modelowania procesów używać notacji BPMN a do analizy obiektowej notacji UML, obie z określoną i dostępną w sieci WWW metodyką modelowania (http://www.omg.org).  Jeszcze stosunkowo popularna jest w niektórych zastosowaniach notacja eEPC rodem z firmy IDS Scheer. W uzasadnionych przypadkach można stworzyć własną prostą notację. Sama notacja jednak nie chroni nas przed popełnianiem błędów analitycznych podobnie jak sama norma opisująca wymiary i zastosowanie gniazdka elektrycznego w ścianie nie chroni nikogo przed wetknięciem tam gołymi rękami gwoździa.

Jak, co i po co modelować

Poprawny model organizacji, w szczególności mapa procesów biznesowych, powinien opisywać tylko przedmiot analizy np. specyfikę organizacji będąca np. źródłem jej przewagi konkurencyjnej i to jak organizacja tę specyfikę tworzy. Model powinien się odwoływać do innych istniejących już dokumentów, np. zakresu kompetencji pracownika czy instrukcji stanowiskowej. Model zawsze powinien mieć jakiś cel swojego powstania i kontekst.

Poniżej ogólna zasada modelowania organizacji:

Diagram powyższy pokazuje trzy warstwy, poziomy szczegółowości, modelowania stanowiące osobne etapy projektu modelowania organizacji. Sam model nie powinien jednak być przedmiotem projektu bo sam z siebie moim zdaniem praktycznie do niczego nie służy poza położeniem go na półce. Model to narzędzie analityczne wspomagające prace nad  reorganizacją, oceną rentowności inwestycji, analizą wymagań na systemy IT itp. Głównym celem jego wykonania jest zrozumienie analizowanego przedmiotu i wypracowanie rekomendacji.

Celowość każdego modelu zależy od rodzaju projektu. Jeżeli tworzymy biznesplan lub to wystarczy model biznesowy. Jeżeli planujemy optymalizację firmy,  analizę rentowności inwestycji lub wdrożenie Zrównoważonej Karty Wyników to należy wykonać model procesów biznesowych. Jeżeli zaś interesują nas szczegóły angażowanych zasobów w procesach, scenariusze realizacji poszczególnych procesów itp. wykonujemy opisy wnętrza procesów czyli dokumentujemy ich scenariusze lub tworzymy tak zwane procedury.

Jak nie trudno sie domyślić w miarę przemieszczania się w dół piramidy pracochłonność, a co za tym idzie i koszt, wykonania tych modeli szybko rośniedlatego należy bardzo ostrożnie decydować się na podejmowanie sie ich realizacji. Sugeruję przyjęcie założenia w którym taka analiza i model służą obniżeniu ryzyka podejmowanych decyzji. Przy takim podejściu możliwa staje sie ocena rentowności projektu analitycznego i łatwiej jest określić budżet na taki projekt. Konsultant powinien umieć taka ocenę przeprowadzić.

W raportach z analiz powinna być utrzymywana zasada, że dla jednej osoby dokumentacja (lub jej część adresowana do osoby pełniącej w firmie konkretną funkcję) nie powinna przekraczać kilkudziesięciu stron łącznie z diagramami (bez załączników). Dokumenty dłuższe z reguły nie są czytane i moim zdaniem niczemu nie służą, są kosztowne i nieprzydatne. Dokumentacja analizy, to skomentowane diagramy opisujące problem i jego rozwiązanie. Tekst stanowi streszczenie i ewentualny opis tego co wymagało by słownego przekazu. Wybrane diagramy umieszczane w tekście powinny stanowić ilustrację jego treści. Dokładne ich wersje należy umieszczać w załącznikach do których zainteresowana osoba zawsze może zajrzeć. Każdy raport powinien mieć na początku jednostronicowe streszczenie, podkreślam: JEDNOSTRONICOWE.Konieczność zamknięcia streszczenia na jednej stronie zmusza do skupienia się na kluczowym elemencie projektu bo tylko ten jest istotny dla najwyższych władz w firmie.

O analizie wymagań na system IT

Projekt, którego celem jest określenie wymagań na system informatyczny wymaga:

• analizy otoczenia rynkowego organizacji, w której ma być prowadzone wdrożenie,
• modelu wewnętrznego funkcjonowania czyli map procesów biznesowych,
• określenia, które procesy biznesowe będą wspierane nowym systemem czyli określenia zakresu projektu
• opisania danych, które system będzie przetwarzał i wykonanie ich modelu,

Celem analizy otoczenia rynkowego organizacji jest upewnienie się, że rozumiemy sposób jej funkcjonowania. Analiza powinna pokazać co jest głównym przedmiotem działalności organizacji. Wiedza ta umożliwia określenie priorytetu każdej oczekiwanej od nowego systemu funkcjonalności i ewentualne świadome ich modyfikacje w przypadku gdy budżet projektu nie pozwoli zrealizować wszystkich oczekiwań. Pozwala także na wzajemne zrozumienie działalności Firmy przez wykonawcę i zleceniodawcę, bez którego nie wyobrażam sobie żadnego skutecznego wdrożenia i analizy.

Wykonanie modelu funkcjonowania organizacji to zbudowanie mapy jej procesów biznesowych. Celem jest opisanie jak organizacja pracuje (tworzy wartość rynkową) i dokonanie ewentualnych zmian w celu jej ulepszenia. Jest to opis tego jak w firmie powstaje wartość dodana.

Kolejnym etapem jest określenie, które procesy biznesowe chcemy wesprzeć nowym systemem i czy jest to rentowne. Uzyskujemy tą metodą definicję zakresu projektu i jego oczekiwany graniczny budżet. Metoda ta jest zgodna z architektura SOA (Service Oriented Architekcture, ang. Architektura [systemu IT] Zorientowana na Usługi).

Jednocześnie analizujemy informacje przetwarzane w organizacji i tworzymy ich model (model danych). Stanie się on podstawą wymagań na bazę danych, która jest fundamentem każdego systemu informatycznego. Ten opis jest kluczowym elementem specyfikacji wymagań. Błędy i niedopatrzenia powstałe na tym etapie (zły opis przetwarzanych danych) powodują bardzo kosztowne modyfikacje w trakcie realizacji i wdrożenia systemu.

Model produktów takiej analizy można zilustrować w następujący sposób:

Projekt dla fikcyjnej firmy.

W odpowiedzi na liczne pytania opracowałem przykład takiej analizy. Analiza ta prezentowana jest w formie uproszczonej w celu zademonstrowania jej treści a nie objętości. Treść i stopień szczegółowości każdorazowo są ustalane zależnie od kontekstu i celu projektu. Osoby zainteresowane tym dokumentem zapraszam na kurs modelowania: Projekt