Poziomy implementacji BPM

W jednym z moich pierwszych projektów BPM kierownikiem był fan wzorców projektowych w obszarze dobrego programowania.

Jednym z głównych założeń dobrego kodu jest wytwarzania kawałków funkcjonalnych, tak by miały zakodowane wszystkie docelowe mechanizmy.

W efekcie gdy mieliśmy ok 40% funkcjonalności biznesowych, które zostały dobrze oprogramowane, skończył się czas i budżet. Niestety bez brakujących 60% cały proces nie zadziałał (KP, jeżeli to czytasz to przepraszam Cię za sarkazm).

Problem polega na tym, że jak zwykle musieliśmy jak najszybciej i jak najtaniej zrealizować te braki (tak pominęliśmy zasady dobrego programowania).

No i te 60% funkcjonalności cały czas generuje błędy i sprawia, że rozwiązanie jest bardzo niestabilne.

Gdzie został popełniony błąd.

Otóż w rozwiązaniach BPM istnieje macierz funkcjonalności, poziomo są funkcjonalności biznesowo pionowo funkcjonalności technologiczne.

W ramach danego sprintu powinniśmy określić, które kwadraty będziemy realizować, a każdy kwadrat powinien być objęty zasadami dobrego programowania.

Uwaga, kolejność jest nieprzypadkowa, choć w zależności od priorytetów może ulec zamianie!

Oto funkcjonalności biznesowe (wiersze):
1. Ścieżka główna
2. Wyjątki główne
3. Ścieżki krytyczne
4. Wyjątki krytyczne
5. Ścieżki alternatywne
6. Wyjątki niezidentyfikowane


Oto funkcjonalności technologiczne (kolumny):
1. Obsługa struktury operacyjnej
2. Kierowanie procesem
3. Obiekt biznesowy
4. Obiekt kierowania procesem
5. Wsparcie diagnozy patologii
6. Wsparcie konserwacji środowiska produkcyjnego
7. Testy automatyczne
8. Wsparcie migracji instancji
9. Wsparcie wznawiania procesów
10. Przygotowanie danych BI
11. Raportowanie jakościowe i strategiczne
12. Raportowanie ilościowe i operacyjne
13. BAM
14. Archiwum dokumentów

Dla przykładu zrobienie ścieżki głównej z 14 funkcjonalnościami technologicznymi, sprawi że biznes zapomni o tym, że dla niego realizujemy projekt.