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" ...
Wydaje mi się, że rynek na systemy ERP/CRM rośnie, jednak z mody na taki system (tu chyba faktycznie można mówić o nasyceniu) przechodzi w ocenę realnych potrzeb i biznesowej opłacalności (nadal mniej niż 80% ma taki system). Co maja pozostałe skoro wiemy, że "coś mają?". Z moich doświadczeń wynika, ze mają "jakiś system FK/magazyny/sprzedaż" oraz bazy ad-hoc (np. Excel) lub po protu dużo ręcznej pracy. Czemu nie inwestują w ERP? Nie widzą powodu by wydać tak duże pieniądze choć czują, że dalej tak nie pociągną.Jeżeli wierzyć innym badaniem, mówiącym, że w firmach dużych jest nasycenie, należy się skupić na firmach średnich i małych. Patrząc na wyniki oceny tworzonej wartości dodanej w każdej grupie (na pierwszym miejscu są firmy duże w udziałem 44%. Na drugim są firmy mikro ? 28%) oraz moim niedawnym wyliczeniem, że rozbudowany system tego typu na własność to inwestycja rzędu minimum 75 tys. zł, moim zdaniem można raczej mówić, że inwestycje poczynią firmy średnie. A mikro? Tworzą dużą wartość dodaną więc maja dochody, nie mają jednak możliwości zainwestowania aż 75 tys. zł. Co pozostało? Dzierżawa czyli SaaS. Prawdopodobnie jest to duży rynek (mikro firmy) dla usług dzierżawy oprogramowania o typowej wielości kontraktu 5 użytkowników/10GB danych. Te wielkości to coraz popularniejsze w USA oferty hostingowe/SaaS o wdzięcznej nazwie Lite.
Mało która firma ma modele procesów a każda jakoś istnieje! Można żyć bez map procesów, straszne! Co więc oferują firmy doradcze "sprzedające" usługę modelowania procesów biznesowych?Sedno sposobu pracy organizacji to reguły biznesowe. One rządzą tym, co jest wykonywane i jak. Proces (to jak jest wykonywana praca) to abstrakcja, efekt istnienia ograniczeń (w tym właśnie reguł biznesowych). Tak wiec można zarządzać firmą nie mając modeli procesów podobnie jak można mieszkać w mieście nie mając jego planu.W czym problem? Bez "mapy" nie rozumiemy wielu zjawisk mimo, że występują. Jednak przydatny model biznesowy to model procesów powiązany z pozostałymi czterema składnikami opisu organizacji (ludzie, prawo, wewnętrzne zarządzenia i procedury).Model biznesowy to nie są dziesiątki i setki nieczytanych diagramów, pokazujących szczegółowo to co robię pracownicy bo mogą to robić na nieskończenie wiele sposobów. Istotne jest to co powstaje, po co i dlaczego akurat tak.Na zakończenie: np. model pracy operacyjnej każdego urzędu można kompletnie opisać jednym diagramem. Jeżeli chcesz na prawdę poznać swoją firmę, opracuj jej model. Ale nie w postaci setek diagramów będących suchym zapisem wywiadu.Rozłóż firmę na czynniki pierwsze i zrozum ją. Bez tego nie zarządzasz a próbujesz zarządzać!Wykonaj sformalizowany notacjami i słownikiem pojęć, audyt firmy, sposobu funkcjonowania i zrozum jak na prawdę działa.
Poprzedni mój wpis, Noworoczne wynurzenia, dotyczył etyki. Tu polecam szczególnie tę puentę ale i cały artykuł polecam jako lekturę: Ważnym jest też, że nie robimy żadnych manipulacji, trików, erystyki, NLP itp. tylko wypreparowujemy prawdę, a potem w razie konieczności walimy nią jak maczugą w leni i kombinatorów Oczywiście o ile nie da się z nim wcześniej ?porozumować?, bo od tego zaczynamy tak czy inaczej. Dopiero jak ktoś nie chce/nie potrafi myśleć, to mamy ?licence to kill? (za Upierdliwy klient wewnętrzny działu IT cz.2 ? Blog Alexa.)
Gorąco polecam dwie książki autorstwa Ronalda G. Ross'a, ich okładki tu widzicie. Wydane zostały przez Business Rule Solutions, LLC. Pierwsza skupia się na regułach biznesowych jako koncepcji. Metody i system pojęciowy w niej opisany znalazły się na liście otwartych standardów OMG jako SBVR. W ubiegłym roku ukazało się już trzecie wydanie tej książki.Druga to pozycja nowa, całościowo opisująca podejście polegająca na modelowaniu organizacji w analizie biznesowej (zawiera część materiału pierwszej) . Zwraca uwagę na fakt, że nie chodzi w analizie o tworzenie mnóstwa diagramów a o to, by zrozumieć jak organizacja funkcjonuje opisując to, oraz stworzyć model, który pozwoli na prognozowanie zachowania organizacji w odpowiedzi na bodźce, nawet te które jeszcze nie zaistniały. Prognoza? A jak Państwo chcecie ocenić ryzyko i skutki utraty członka zarządu (np. złamał nogę na nartach...;)) lub jednego z kluczowych dyrektorów? Jak chcecie ocenić skutki i ryzyko wdrożenia nowego systemu systemu ERP?Da się... ale model organizacji to nie trawnik boiska z wydeptanymi ścieżkami, bo trwa rośnie a kolejne rozgrywki to nowe ścieżki, nie narysujemy wszystkich możliwych! Model to reguły gry w piłkę nożną, umiejętności poszczególnych piłkarzy, granice boiska, obie połowy, pola karne i bramki. To decyduje o tym ja wygląda gra. Co jest ważne? Odkryć i jednoznacznie udokumentować formalne zasady.
Analiza to dość pojemne pojęcie w potocznym języku, jednak analiza jako etap procesu rozwiązywania problemu, wymaga podejścia wręcz naukowego, bardzo ścisłego. To się wiąże w zasadzie z koniecznością stosowania wyrafinowanych narzędzi analitycznych a takimi są systemy pojęciowe (najczęściej spotykane w tej branży po postacią notacji).Należy je bardzo dobrze poznać i zrozumieć ?moc? narzędzi jakim jest ?system pojęciowy? i ?język?. To wymaga czasu, braku presji do naginania zasad (np. naciskający na zmianę treści pracodawca lub zamawiający) oraz przede wszystkim przekonania, że ?to działa?.Niestety wielu ?sponsorów? projektów uważa, że płaci za wynik analizy. Niestety na rynku jest wielu analityków uważających, że właśnie to jest ich rola: dać oczekiwany wynik analizy.
