Zadania BPM w Twoim CRM, a nie w osobnym panelu
Silniki BPM mają własne listy zadań i gotowe panele. Mimo to wpięliśmy zadania procesów w istniejący panel administracyjny. Wyjaśniamy dlaczego — i czego nauczył nas pierwszy tydzień po wdrożeniu.
Każdy dojrzały silnik BPM ma własny interfejs: listę zadań, formularze, podgląd procesów. Wdrażając procesy dla platformy SaaS, mieliśmy go pod ręką od pierwszego dnia. Świadomie z niego zrezygnowaliśmy i wbudowaliśmy zadania w panel administracyjny, w którym zespół pracował już wcześniej. Pełna integracja z interfejsem zajęła 9 dni.
Teza
Proces, który żyje w osobnym narzędziu, przegrywa z procesem, który żyje tam, gdzie ludzie już pracują. Nie dlatego, że osobny panel jest gorszy technicznie, ale dlatego, że każdy dodatkowy login, każda dodatkowa zakładka i każde przełączanie kontekstu obniża szansę, że zadanie zostanie wykonane na czas.
Argumenty
Jeden login, te same role
Silnik BPM w naszym wdrożeniu akceptuje te same tokeny JWT co panel administracyjny i weryfikuje je tym samym kluczem publicznym. Role z panelu przekładają się na grupy kandydatów w procesie. Nie ma drugiej bazy użytkowników do synchronizowania ani drugiego miejsca, w którym trzeba odebrać uprawnienia odchodzącemu pracownikowi.
Kontekst danych pod ręką
Zadanie „zadzwoń do klienta” ma sens tylko razem z historią klienta: kiedy się zarejestrował, czy korzystał z usługi, jaki kupon dostał tydzień temu. W panelu ten kontekst jest o jedno kliknięcie od zadania. W osobnym narzędziu trzeba by go albo kopiować do zmiennych procesu, albo kazać ludziom przełączać się między aplikacjami.
Formularze z definicji procesu
Formularz zadania nie jest zakodowany w interfejsie. Panel czyta pola z definicji procesu — typ, etykietę, wymagalność, listę wartości — i buduje formularz dynamicznie. Dodanie nowego procesu z nowymi polami nie wymaga wdrożenia frontendu. To zachowuje największą zaletę osobnego panelu BPM — elastyczność — bez jego wad.
Widoczność procesu
Do listy zadań dodaliśmy podgląd diagramu BPMN z zaznaczonym krokiem, na którym stoi konkretna instancja. Pliki procesów pisaliśmy ręcznie, bez informacji o układzie graficznym, więc diagram jest układany automatycznie w przeglądarce. Dla zespołu sprzedaży to odpowiedź na pytanie „dlaczego ten klient dostał tę wiadomość” bez czytania XML.
Granica bezpieczeństwa
Panel administracyjny i panel klienta korzystają z osobnych API. To świadoma decyzja sprzed lat: mieszanie API administracyjnego z klienckim zwykle kończy się problemami z bezpieczeństwem. Wpinając BPM, zachowaliśmy tę granicę — pracownicy obsługują zadania przez panel administracyjny, klienci przez własne API. Silnik procesów nie jest dostępny dla klientów bezpośrednio. Opisujemy to szerzej w tekście o zadaniach wykonywanych przez klienta.
Czego nauczył nas pierwszy tydzień
Lista zadań działała, formularze działały, procesy tworzyły zadania zgodnie z planem. A mimo to zadania leżały. Okazało się, że zespół nie zaglądał na nową stronę z własnej inicjatywy — nawet wbudowaną w znany panel.
Dodaliśmy trzy rzeczy:
- przekierowanie po zalogowaniu na listę zadań, jeśli są otwarte zadania,
- licznik w menu odświeżany automatycznie,
- codzienny e-mail o zadaniach otwartych dłużej niż kilka dni.
Wniosek jest prosty i dotyczy każdego wdrożenia procesów: technologia to połowa pracy. Druga połowa to zadbanie, żeby zadanie samo znalazło człowieka.
Kiedy osobny panel ma sens
Gdy procesy obejmują wiele systemów i żaden nie jest naturalnym „domem” dla użytkowników, albo gdy organizacja ma dziesiątki procesów i dedykowany zespół do ich obsługi. W firmach, które mają jeden główny system pracy — CRM, ERP, panel — zadania powinny trafiać właśnie tam.
Cały projekt opisaliśmy w realizacji Silnik BPM wpięty w istniejący CRM.