Konieczność posiadania wiedzy i umiejętności programistycznych na etapie projektowania i wdrażania procesów została całkowicie wyeliminowana poprzez wprowadzenie narzędzi do graficznego projektowania procesów. […] Patrząc od strony korzyści dla przedsiębiorstw rozważających podjęcie decyzji o praktycznych wykorzystaniu systemu BPM 2.0, można wskazać pojawiające się dodatkowo możliwości łatwego projektowania, wdrażania i optymalizowania procesów.
Tego rodzaju opinie pojawiają się regularnie jak tylko na rynku pojawi się jakieś rozwiązanie z gatunku [[Rapid Development]]. Problem z takimi obietnicami polega na tym, że ukrywają pewien istotny fakt: każdy system to „narzędzie przetwarzania danych” i:
- pierwsza trudność to zrozumieć i udokumentować co, kto i po co ma zrobić z jakimiś danymi,
- druga, nie mniejsza, to opisać te dane i przygotować dla nich miejsce.
w czym problem? Poniżej diagram prostego procesu (notacja BPMN):
Żółte prostokąty (zaokrąglone rogi) to czynności (procesy), „karteczki z zagiętymi rogami” to nasze dane (jakieś dokumenty itp.). Nasze dane są składowane na różne sposoby. Jeżeli interesuje nas wyłącznie to ile stron dokumentów mamy, być może wystarczy traktowanie każdej karteczki na diagramie jak dokumentu. Jeżeli jednak chcemy wiedzieć kto, kiedy i co napisał, to pojawia się potrzeba „rozebranie” treści każdego dokumentu na te własnie „drobne” elementy. Ta rozbiórka nie jest prosta, nazywa się to [[modelowanie danych]] lub [[analiza i modelowanie dziedziny systemu]] a ogólnie jest to model informacyjny. Ten niestety nie jest łatwy do wykonania. Po jego wykonaniu zaś należy zaprojektować i stworzyć system, który tymi danymi będzie zarządzał.
Tak więc powyższy diagram faktycznie jest w stanie opracować tak zwany „biznes” i zapewne wielu menedżerów się tego nauczyło. Problem w tym, że nic nie zadziała do czasu gdy nie stworzymy systemu zarządzania danymi, który obsłuży owe karteczki na diagramach procesów.
Po za tym dostarczenie mechanizmów pracy grupowej użytkowników systemu, utrzymanie zgodności ze standardami nie prowadzącej do uzależnienia od jednego dostawcy oprogramowania, możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami – np. ERP czy CRM – i wreszcie ograniczenia kosztów w drodze wykorzystania jednej z istniejących, w pełni funkcjonalnych, implementacji rozwijanych w ramach projektów open-source. (za BPM 2.0 czyli nowa generacja zarządzania procesami w przedsiębiorstwach).
Powyższego niestety nie zrozumiałem (co to znaczy „możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami”), nie licząc tego, że faktycznie dobrze wdrożony system wspomagający zarządzanie przepływem pracy i dokumentów, jest swego rodzaju systemem pracy grupowej. Integracja, jej łatwość i koszt zaś nie zależy od systemu BPM a tych integrowanych systemów ERP czy CRM (pamiętajmy, że integracja w jednakowym stopniu dotyczy obu integrowanych systemów).
Tak więc nie sądzę by możliwe było projektowanie i wdrożenie systemu bez „służb informatycznych”. Jednak dobrze zaprojektowany i już wdrożony system BPM może pozwalać na komponowanie kolejnych nowych lub zmianę starych procesów, jednak tu możliwe jest jedynie używanie jak klocków, wstępnie zaprojektowanych i zaimplementowanych „procesów i obiektów danych”.
Muszę tu z niechęcią wystąpić jako klakier i zgodzić się całkowicie z wnioskami 🙂 Z drugiej strony należy zrozumieć tych pisali te teksty, bo zapewne pochodzą one z ulotek reklamowych stosownych produktów Jakoś musieli zachęcić przyszłych klientów 🙂
Budowanie systemów informatycznych, bez specjalistów IT – mrzonki które trochę inaczej sformułowane, słyszałem już 20 lat temu 🙂
No ewidentnie ktoś się zapędził z wnioskiem, że „wiedza i umiejętności programistyczne zostały wyeliminowane” 🙂 nie wyobrażam sobie wdrożeń w inny sposób(przynajmniej teraz), ale jak widać na potrzeby reklamy można wcisnąć ludziom wszystko.
Co do przytoczonego argumentu, że nie jest możliwe zaprojektowanie procesu bez umiejętności programowania, ponieważ potrzebny jest magazyn na dane, to jest on ciekawy, ale sposób jego obrony nie wydaje się być przekonujący.
Proszę sobie wyobrazić, że sposób składowania danych również można meta-modelować, tzn. mając wewnętrzną „dobrze określoną”, implementację sposobu składowania danych, udostępnić użytkownikowi narzędzie operujące na wyższym poziomie abstrakcji. Przykładowo pozwalające na zdefiniowanie dla procesu dotyczącego akceptacji faktury, takiego „magazynu” który poza reprezentacją binarną posiada jeszcze następujące atrybuty opisowe: numer, kwota, kontrahent, lub jakiekolwiek inne.
Czy wplecenie tak zdefiniowanych danych w definicje procesu wymaga umiejętności programowania?
Tak, jeżeli nie posiada się odpowiednich narzędzi lub posiadanych narzędzi nie potrafi się używać.
A przykładowo, jednorazowo poniesiony wysiłek wprowadzenia własnych rozszerzeń do notacji BPMN,
rozwiązuje, a przynajmniej ogranicza potrzebę programowania, przy implementacji każdego kolejnego procesu.
I to właśnie, między innymi, jest obietnica BPM 2.0. Dostarczenie narzędzi, które umiejętność programowania przesuną na dalszy plan.
P.S., to że coś nie jest łatwe do wykonania, nie znaczy, że jest niemożliwe i że nie ma ludzi którzy podołają zadaniu.
Nie chodzi o programowanie a modelowanie danych i to jak się to zrobi (analiza i modelowanie danych to w moich nie programowanie). Model procesu, by był wykonywalny musi powoływać się na „dane wejściowe i wyjściowe”. W zasadzie, można uznać, że zawsze jest to „free form” podobnie jak pole „nowy tekst” w blogu ale nie o to chodzi. To podobne do hurtowni danych i systemów BI: ktoś musi zaprojektować ten „metamodel danych”, zwany w niektórych systemach BI „świat obiektów”, bo dopiero wtedy można ich używać. Im wyższy poziom abstrakcji tym bardziej są wymagane owe „przedefiniowane” obiekty. Dlatego uważam, że BPM „sam się nie zrobi” podobnie jak żaden „biznes” sam nie wdroży (z sensem) systemu BI…