Na początek wspomnę tylko o sprawach oczywistych – system BPM powinien stabilnie działać, żeby jego codzienna obsługa i administracja nie były karkołomnymi zadaniami. I tyle w temacie podstaw, bo Dział IT na pewno o to zadba na etapie wyboru systemu, to i co tu dużo pisać.

Co w takim razie jest naprawdę ważne przy wyborze systemu? Na co zwrócić uwagę z rzeczy mniej oczywistych, o których albo dowiemy się od kogoś, albo z nabierzemy doświadczenia na własnym przykładzie (i na własny rachunek)?

Jedną z ważniejszych kwestii jest ocena systemu pod kątem bezpieczeństwa wyboru tego rozwiązania dla naszej organizacji. Innymi słowy musimy się upewnić, że rozwiązanie na które się decydujemy ma szansę istnieć i być rozwijane przez najbliższe lata i nie zostaniemy za rok z systemem, którego nikt już nie rozwija i nie świadczy usług wsparcia technicznego ani nie łata ewentualnych błędów. Nie namawiam tutaj tylko do wyboru rozwiązań dużych firm, bo nie dla każdej organizacji będzie miało to sens ekonomiczny. Niemniej ważne jest, by dokonać takiej analizy i zdecydować, czy ryzyko upadku producenta jest dla nas pomijalne w kontekście zarówno ceny systemu jak i wysiłku poniesionego we wdrożenie i utrzymanie systemu w organizacji. Zdecydowanie nie chcemy kupić autorskiego systemu tworzonego przez jedną osobę, która w każdej chwili może zmienić zatrudnienie i będzie po systemie, a my zostaniemy z problemami.

Warto również sprawdzić, czy system, który planujemy wdrożyć sprawdził się w innych organizacjach. Jak wielu używa go użytkowników czy firm, od ilu lat istnieje na rynku. Czym większe to liczby tym dla nas lepiej, bo świadczy to o tym, że system zdobył sobie zaufanie klientów i jest szansa, że i nasza organizacja nie wyjdzie źle na jego wdrożeniu.

Oczywiście w każdym projekcie ważne są koszty. Analizując koszty wdrożenia systemu klasy BPM musimy wziąć pod uwagę nie tylko koszt zakupu licencji na użytkowanie systemu oraz coroczny koszt odnowienia licencji i wsparcia, ale również koszt rozwoju platformy. Bardzo ważne i wpływające na całkowitą opłacalność rozważanej platformy są też dodatkowe koszty, które mogą nas spotkać niekoniecznie przy samym wdrożeniu. Warto sprawdzić, czy jeśli zechcemy po pewnym czasie przejść na wyższą wersję systemu z bogatszymi funkcjonalnościami, to czy zapłacimy tylko różnicę, czy kupujemy od nowa? Ile kosztują rozszerzenia funkcjonalności i czy w ogóle istnieją w danym systemie czy też trzeba z góry zapłacić za wszystkie, nawet niepotrzebne nam funkcjonalności?

I wreszcie bodaj najważniejsze – coś, co na pewno nas spotka z definicji – czy będziemy w stanie własnymi siłami wewnątrz organizacji tworzyć nowe procesy i modyfikować istniejące? W wielu systemach to zadanie czysto programistyczne, do tego system pozbawiony jest dostępu do edycji procesów. Są też systemy tzw. „low code”, czyli wymagające bardzo mało lub w niektórych przypadkach w ogóle nie wymagające programowania. Takie systemy będą droższe na początku, ale w ogólnym rozrachunku może się to organizacji opłacić. Oczywiście gdy potrzebujemy tylko jednego lub kilku procesów i cena startowa jest dla nas ważna, może opłacać się skorzystać z tańszych systemów, ale tutaj akceptujemy ryzyko dodatkowych kosztów za każdym razem, gdy zechcemy coś zmienić. Warto wtedy szczególnie mocno przyłożyć się do dobrej definicji procesów na początku i skorzystać z oferty firmy, która nie tylko sprzedaje nam system, ale też może pomóc w opisaniu procesów i uniknięciu pułapek. Niektóre systemy oferują rozwiązania chmurowe, gdzie system zainstalowany jest w chmurze producenta lub dystrybutora, a nasza organizacja jedynie go używa. Wtedy trzeba porównać koszty wdrożenia rozwiązania on premise (lokalizacja w naszej serwerowni) z wersją chmurową, nie zapominając o ewentualnych kosztach corocznego odnowienia licencji czy wsparcia. Rozwiązanie chmurowe najczęściej jest pozbawione takich kosztów, więc nie pomijajmy ich w rachunkach rozwiązań on premise. W rozwiązaniu chmurowym mogą natomiast istnieć dodatkowe koszty utrzymania serwerów pod wykupiony system – o nich również nie należy zapominać.

Jak już wspomniano wcześniej, ważnym elementem decyzji jest temat łatwości tworzenia i modyfikacji procesów na naszej platformie oraz jej integracji z innymi systemami, jakie posiadamy w organizacji. W niektórych systemach tworzenie procesów to praca programisty, która wymaga nie tylko umiejętności programowania i wiedzy o tworzonym procesie, ale również dostępu do specyficznej wiedzy o architekturze danego systemu, co w praktyce bardzo utrudnia albo wręcz uniemożliwia samodzielne tworzenie i modyfikację procesów w organizacji i wymaga każdorazowego angażowania we wszelkie zmiany firmy, która nam oprogramowanie wdrożyła. Na drugim końcu skali są rozwiązania, które posiadają graficzne edytory procesów, umożliwiają dokonywanie większości prac w wygodnej formie osobom bez żadnej wiedzy programistycznej i wymagają kodowania jedynie w specyficznych sytuacjach, ale i wtedy są to proste funkcje zbudowane na szablonie, a pełna wiedza o architekturze systemu nie jest zwyczajnie potrzebna. Są też rozwiązania plasujące się gdzieś po środku tej skali, w których edycja procesów jest częściowo dostępna dla biznesu, ale sporo wymaga wciąż wiedzy o programowaniu.

Decydując się na wybór rozwiązania musimy przeanalizować te i pewnie jeszcze inne kryteria, związane ze specyficznymi potrzebami naszej organizacji, jak np. konieczność obsługi kodów kreskowych czy zastosowania technologii OCR do rozpoznawania pisma, by ułatwić obsługę ton korespondencji czy faktur. Mam nadzieję, że te kilka krótkich rad pozwoli Wam drodzy Czytelnicy lepiej się przygotować do możliwej cyfrowej transformacji w Waszej organizacji.