Modelowanie warstwowe

Możemy oczywiście założyć, że kontekst dokumentacji wystarczy, aby w każdej sytuacji zidentyfikować znaczenie terminu. Można także poprosić określone osoby o komentarz, ale to wiąże się z dodatkowym czasem. Z drugiej strony, chcemy uzyskać wspomniany efekt zmniejszenia nadmiarowości opisów procesów. Warto więc zdefiniować określone konwencje terminologiczne, pozwalające na oszczędność słów bez strat precyzji przekazu. Jedną z nich jest stosowanie warstwowości w modelowaniu procesu biznesowego. Przykładowo: na najwyższym poziomie modelowania używamy liczby mnogiej, stosując konstrukcje typu "procesy produkcji“; na kolejnym, niższym poziomie, umawiamy się, że stosujemy liczbę pojedynczą, w zwrotach o postaci "proces pakowania". Wreszcie, na najniższej warstwie modelowania (tutaj w modelu trójpoziomowym) posługujemy się złożeniami czasownik+rzeczownik, np. "konfekcjonowanie wyrobów", przy czym w idealnym wariancie występujące tu pojęcia pochodzą z ich zdefiniowanego katalogu.

O czym musimy jeszcze pamiętać, aby nasz projekt zakończył się powodzeniem? Warto tu wskazać na wieloletnie statystyki projektów IT (Standish Group), pozwalające na identyfikację kilku głównych czynników sukcesu:

1. Wsparcie kierownictwa (18%),
2. Zaangażowanie użytkowników (16%),
3. Doświadczenie wykonawców projektu (14%),
4. Jasne cele biznesowe (12%),
5. Minimalizacja zakresu projektu (10%),
6. Inne (30%): użycie standardów informatycznych, niezmienność podstawowych wymagań, formalna metodologia, wiarygodne oszacowania.

Widzimy zatem, że jeśli tylko zdecydujemy się na projekt z zaangażowanym kierownictwem i użytkownikami oraz doświadczonymi wykonawcami (doradcami), to mamy statystyczną gwarancję ponad połowy sukcesu. Zawsze warto jednak używać standardów referencyjnych lub choćby prostych narzędzi do "samodzielnego" użytku (w przypadku mniejszych przedsięwzięć, aby minimalizować ryzyko inwestycyjne).

Do tej pory mówiliśmy o zaletach BPM - a co z wadami takiego podejścia? Minusy modelu BPM z reguły nie dotyczą jego samego, ale wadliwych metod jego stosowania, tj. syndromu BINO (BPM In Name Only), czyli modelu tylko z nazwy, tzn. wybiórczego stosowania tej strategii w odniesieniu do jej pojedynczych składników, bez głębszej analizy i zwracania uwagi na całość metodyki. W takiej sytuacji mamy do czynienia z następującymi zjawiskami:

• konieczność regularnej wymiany informacji między uczestnikami projektu prowokuje niekończące się ciągi bezproduktywnych spotkań, ograniczające ilość czasu na rzeczywiste implementacje;
• dla małych projektów, zbyt ścisłe przestrzeganie procedur referencyjnych może być bardzo pracochłonne i w takim przypadku niezbędna jest adaptacja modelu uwzględniająca lokalne realia biznesowe;
• dokumentacja, która jest nieodzowna podczas stosowania modelu referencyjnego, staje się celem samym w sobie, prowadząc nawet do niepowodzeń projektowych, wskutek przerostów biurokracji organizacyjnej (problem bardzo dużych firm).