Ten artykuł jest pewną kontynuacją poprzedniego. Potraktujmy go jako "prostszą wersję" :) popartą oczekiwaniami przyszłego wykonawcy, który w swoim artykule niejako "składa zamówienie na dokument wymagań". Wpadła mi swego czasu…
W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że: - Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w…
Jednym z głównych problemów wielu projektów analitycznych (i nie tylko) jest komunikacja i dokumentowanie działań. Projekty analityczne mają to do siebie, że opisują organizację beneficjenta projektu. Tworzenie jej modeli wymaga "sprzężenia…
Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty “na żywioł”. Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany “maintenance”) niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania “na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: “czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”. W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: “ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). […] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.
To jest właśnie problem nazywany “użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.
Analiza biznesowa obejmuje wyłącznie obszar strategii i procesów biznesowych. Wdrożenie poprzedzane jest analizą całej organizacji, wydzielenie w niej niezależnych obszarów dziedzinowych (np. rachunkowość, zarządzanie procesami pracy, zarządzanie wiedzą, portal klienta, zarządzanie i sterowanie produkcją, zarządzanie procesem sprzedaży, inne).
Każdy obszar cechuje się tymi trzema poziomami: strategia, procesy, realizacja. Na etapie analizy potrzeb prowadzimy audyt i modelowanie procesów. Zakładamy, że szczegóły tego ?jak pracujemy? i tak ulegną zmianie po wdrożeniu nowego narzędzia pracy, więc pomijamy je na tym etapie (zostaną określone podczas wdrożenia). Jeżeli analiza wykaże, że istnieje obszar niestandardowy w organizacji, tylko dla tego obszaru prowadzi się szczegółową analizę, gdyż w tym obszarze będzie (najprawdopodobniej) wdrażane rozwiązanie dedykowane.
Tak więc zintegrowany system ERP II nie musi oznaczać “jedno rozwiązanie od jednego dostawcy”. Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, ze “systemy od wszystkiego są do niczego”…
Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście).
Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami “utrudniającymi”. Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe “atrakcje” to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma “rombów”, bramek decyzyjnych bo one są cechą “procesów decyzyjnych”, procedur, a te to reguły biznesowe i “wiedza o biznesie” a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że “tylko tak wolno tę pracę wykonać”.
Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR – opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać “maszyny” (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.
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” …
