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.
Konferencja Modelowanie Biznesowe zgromadziła ok. 50 słuchaczy. Liczba ta przekroczyła planowana frekwencję co świadczy o dużym zainteresowaniu tą tematyka. Problem modelownia, a raczej braku modelowania w wielu projektach, oraz sposób postrzegania korzyści z tego typu projektów widać było w gorących dyskusjach pomiędzy kolejnymi wykładami.
Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.
Ano mamy opis firmy i możliwość wskazania priorytetów w obszarach wymagań na system, tak ważnych przy określaniu wykonywalności projektu IT, w szczególności jego rentowności. Mając model łańcucha wartości można łatwo zbudować model wewnętrznych procesów biznesowych , gdyż jest on ta na prawdę niczym innym jak dekompozycją modelu łańcucha wartości. Idąc wiec droga od opisu firmy do modelu jej procesów można zbudować np. taki oto model w notacji BPMN (od góry: model biznesowy, model procesów, wymagania na system IT) :
Tworzę model procesów (używam notacji i metodyki BPMN ale w prostszych przypadkach może to być np. diagram czynności UML), od którego proponuję zacząć. Potem wskazuję (wybieram) te czynności, które będą "komputeryzowane" (bo nie koniecznie wszystkie). W metodyce którą stosuję jest pojęcie czarnej skrzynki. Jest to np. projektowany jeszcze hipotetyczny system. Tworząc model procesów łączę czarną skrzynkę z wybranymi czynnościami (procesami) i optymalizuje tak powstały model.
Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się "tłumaczyć" na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego np. model wykonany za pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu typu CASE.
Jako konsultant prowadzę także projekty związane z wyborem systemu informatycznego nie wiąże się jednak z żadnym z jego dostawców na rynku. Narzędzia służące do modelowania wspierają te działania dlatego wymieniam tu te, których używam. Ich wybór jest podyktowany skutecznością z jaką wspierają pracę np. moją. Nie determinują one tego jakiego systemu wspierającego zarządzanie użyjemy w przyszłości po wykonaniu analizy i czy w ogóle. Jako praktyk jednak spokojnie mogę polecić programy, których sam używam.
