To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP "luźnej prozy". Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych - dlaczego mają sens tylko metody formalne i uznane notacje).Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze "nieudane" projekty...
Systemy zarządzania przepływem dokumentów, przepływem pracy lub szumnie nazywane (i na wyrost) sytemami zarządzania procesami biznesowymi, sprawiają wiele problemów. Zaryzykuje tezę, że ich wdrażanie jest ryzykiem nie mniejszym niż wdrażanie systemów CRM (podobno tu odsetek przekroczonych budżetów i terminów przekracza 90%).Nawet jeżeli ktoś przeprowadzi rzetelną analizę potrzeb i tak dostosuje (zaprojektuje i wytworzy) wdrażany system, że będzie spełniał pierwotne wymagania, okazuje się nie raz, że jego "życie" jest bardzo kosztowne. Problem tkwi w modelu zjawiska jakim jest przepływ pracy. Nie raz wielu z Państwa (mających takie systemy) słyszało po wdrożeniu, że coś wymaga wiele pracy albo jest wręcz nie możliwe już po rozpoczęciu eksploatacji systemu. Albo, że "proces może obsłużyć tylko jeden dokument" i złączenie w jeden kontrolowany bieg wypadków czegoś takiego jak opracowanie oferty w odpowiedzi na przyjęte zapytanie jest niemożliwe albo wymaga "sztucznego połączenia dwóch procesów w jeden" (czyli dwóch dokumentów Zapytanie i Oferta w jeden ciąg). Inny przypadek to "nie da się dowolnie zmieniać statusów dokumentów, proszę określić dokładnie jakie statusy będzie miał dokument oraz kiedy i jak będą się one zmieniały".Wiele dokumentów analiz zawiera statyczne tabele dopuszczalnych stanów obiektów implementowane "na żywca" czyli wprost, ich zmiana wymaga pracy programisty. W efekcie system jest bardzo kosztowny w samym posiadaniu i korzystaniu z niego, a jak wiemy środowisko biznesowe jest zmienne. Środowisko dokumentów biznesowych jest szczególnie zmienne.To są skutki stosowania (często) wzorca State Machine do budowy systemów wspomagający przepływ pracy. Wzorzec ten jest często stosowany w systemach ERP do kontroli pojedynczych dokumentów ale moim zdaniem kompletnie nie nadaje się do implementacji systemów zarządzających przepływem pracy. To nie jest przypadek, że wielu dostawców systemów ERP zaleca jednak integrację z jakimś "dobrym workflow" zamiast bardzo kosztownej kastomizacji (o tym już tu nie raz pisałem).Co z tym zrobić? Kupujący nie ma możliwości sprawdzenia wnętrza programu (tego jak zostało zaprojektowane) jeżeli kupuje gotowe. Musi bardzo "inteligentnie" stawiać wymagania na oprogramowanie by wychwycić wady jego projektu mogące wywołać lawinę kosztów podczas "zwykłego używania". Jeżeli zapada decyzja o projekcie dedykowanym warto pokusić się o dobrego analityka i projektanta. A co gdy kupujemy sami i gotowe? Proponuję np. umieszczenie w specyfikacji wymagań zgodności z wzorcem (metamodelem) WfMC a potem sprawdzać czy nas nie oszukano... Ale zwracam uwagę na ryzyko, że nie ma prostej zasady "zawsze taki wzorzec" ...
