Jedno z najczęstszych zdań, jakie słyszę podczas rozmów z klientami i analiz przedwdrożeniowych w e-MSI, brzmi mniej więcej tak:
„Chcemy zdigitalizować tylko jeden proces.”
Na początku rzeczywiście może tak wyglądać. Jest wniosek, dokument albo sprawa. Jest kilka osób, które muszą wykonać określone działania. Jest początek, kilka akceptacji i koniec. Na kartce można to często narysować w kilku lub kilkunastu prostokątach.
Dopiero podczas głębszej analizy okazuje się, że ten „jeden proces” pobiera dane z ERP, korzysta ze struktury organizacyjnej z systemu HR, wymaga akceptacji działu finansowego, sprawdzenia limitu budżetowego, konsultacji prawnej, spełnienia określonych wymogów compliance, a na końcu ma jeszcze zasilać raport zarządczy.
I właśnie w tym momencie przestajemy mówić wyłącznie o digitalizacji pojedynczego procesu. Zaczynamy mówić o zmianie sposobu funkcjonowania fragmentu organizacji. To rozróżnienie jest niezwykle ważne, ponieważ największym błędem na początku projektu workflow/BPM nie jest źle wybrana technologia – jest nim błędna diagnoza skali zmiany.
Po latach rozmów z klientami, analiz i projektów wdrożeniowych mam w tym obszarze jedną szczególnie istotną obserwację:
O skali projektu IT nie decyduje liczba ekranów, kroków procesów ani użytkowników. W największym stopniu decyduje o niej liczba zależności, granic organizacyjnych, źródeł danych, reguł decyzyjnych i odpowiedzialności, które musi połączyć rozwiązanie.
Dlatego proces składający się ze 100 kroków wykonywanych przez jeden zespół może być łatwiejszy do wdrożenia niż proces mający 8 kroków, ale przechodzący przez finanse, zakupy, IT, dział prawny i Zarząd.
Najpierw ustalmy, czym właściwie jest proces
Proces biznesowy nie powinien być definiowany poprzez system, dokument ani nazwę działu. „Obieg faktur”, „wnioski zakupowe” czy „obsługa umów” są dobrymi nazwami roboczymi, ale na etapie analizy to za mało. Dobrze zdefiniowany proces powinien mieć co najmniej kilka jednoznacznych elementów.
1. Zdarzenie rozpoczynające: Co powoduje rozpoczęcie procesu?
Czy jest nim wpływ dokumentu? Złożenie wniosku? Powstanie potrzeby zakupowej? Zawarcie umowy? Zatrudnienie pracownika? Informacja otrzymana z innego systemu? Bez jednoznacznego początku trudno określić zakres odpowiedzialności systemu.
2. Rezultat biznesowy: Co musi się wydarzyć, żebyśmy uznali proces za zakończony?
To istotne, ponieważ „akceptacja wniosku” często wcale nie jest końcem procesu. W procesie zakupowym rezultatem może być dopiero utworzone zamówienie w ERP. W obiegu umowy – podpisany i zarchiwizowany dokument. W procesie HR – nadane pracownikowi uprawnienia i potwierdzone wyposażenie stanowiska.
3. Właściciel procesu: Kto odpowiada za wynik całego procesu?
Ważne: Nie za pojedynczy krok – za proces. Jeżeli na to pytanie słyszymy kilka różnych odpowiedzi, jest to pierwszy sygnał, że być może analizujemy proces cross-organizacyjny.
4. Dane i systemy: Jakich informacji potrzebujemy, aby przeprowadzić proces?
Skąd te informacje pochodzą? Który system jest ich źródłem referencyjnym? Gdzie ma znaleźć się wynik procesu? Bardzo często organizacja opisuje proces jako sekwencję czynności wykonywanych przez ludzi, podczas gdy znaczna część jego rzeczywistej złożoności znajduje się pomiędzy systemami.
Gdzie kończy się jeden proces?
To jedno z trudniejszych pytań analizy przedwdrożeniowej, ponieważ organizacje naturalnie patrzą na procesy przez strukturę działową, na przykład: Dział HR widzi swój fragment, Finanse widzą swój, Zakupy swój, IT swój, i tak dalej… Tymczasem klient, pracownik, dostawca czy dokument nie przechodzą przez organizację zgodnie z jej schematem organizacyjnym. Przechodzą end-to-end.
Dobrym przykładem jest offboarding pracownika.
Dla HR proces może pozornie kończyć się wraz z rozwiązaniem umowy. Z perspektywy organizacji trzeba jednak rozliczyć sprzęt, uprawnienia, finanse, szkolenia czy zobowiązania. W rozwiązaniu wdrożonym przez e-MSI w MyOrlen karta obiegowa angażowała między innymi IT, księgowość, szkolenia i bezpieczeństwo, a system automatycznie kierował zadania do odpowiedzialnych osób.
To nadal można nazwać „jednym procesem HR”. Ale technologicznie i organizacyjnie jest to już mechanizm łączący kilka różnych obszarów przedsiębiorstwa. I właśnie tutaj pojawia się pojęcie, które w praktyce uważam za znacznie bardziej użyteczne niż sama liczba kroków:
Powierzchnia organizacyjna procesu
Przez powierzchnię organizacyjną procesu rozumiem liczbę obszarów przedsiębiorstwa, zasad, danych, systemów i modeli odpowiedzialności, z którymi proces styka się od początku do końca. Im większa powierzchnia organizacyjna, tym większa zazwyczaj złożoność wdrożenia.
Proces może mieć tylko osiem kroków, ale jeżeli:
- inicjuje go sprzedaż,
- dane pochodzą z CRM,
- koszt weryfikują finanse,
- warunki opiniuje dział prawny,
- zgodę wydaje Zarząd,
- dokument trafia do ERP,
- archiwizacja musi odpowiadać polityce compliance,
- a wynik ma znaleźć się w raporcie controllingowym,
to nie mamy prostego, ośmiokrokowego workflow – mamy osiem kroków osadzonych w wielu różnych porządkach organizacyjnych i to właśnie te porządki trzeba ze sobą uzgodnić.
Długość procesu nie jest dobrym miernikiem jego złożoności
To jedna z najważniejszych rzeczy, które warto ustalić przed rozpoczęciem projektu, bo liczba kroków jest oczywiście jednym z parametrów procesu, ale sama w sobie mówi niewiele o skali wdrożenia.
Podobnie jak to, czy kroki realizowane są szeregowo, czy równolegle, bo nowoczesne platformy workflow bardzo dobrze radzą sobie zarówno z procesami sekwencyjnymi, jak i z rozgałęzieniami, równoległymi ścieżkami czy wielostopniową akceptacją.
Znacznie trudniejsze pytania brzmią:
- Czy poszczególne działy tak samo rozumieją dane?
- Czy pracują według tych samych reguł?
- Czy mają spójne KPI?
- Czy obowiązują je te same wymagania compliance?
- Czy zgadzają się co do tego, kto podejmuje decyzję?
- Czy systemy, z których korzystają, posiadają spójne informacje?
Dlatego długość procesu nie powinna być traktowana jako podstawowy miernik jego złożoności. Proces składający się z relatywnie niewielkiej liczby kroków może okazać się wymagającym projektem, jeśli łączy wiele systemów, źródeł danych, reguł biznesowych, mechanizmów akceptacyjnych, urządzeń, kanałów komunikacji czy wymagań raportowych.
Z perspektywy wdrożeniowej znacznie ważniejsze od tego, ile kroków znajduje się na diagramie, jest więc to, ile zależności trzeba obsłużyć pomiędzy tymi krokami. To właśnie liczba punktów styku pomiędzy działami, systemami, danymi i odpowiedzialnościami w największym stopniu determinuje rzeczywistą złożoność rozwiązania.
Liczba użytkowników również może wprowadzać w błąd
Drugim często stosowanym miernikiem jest liczba użytkowników.
„Będzie z tego korzystało tylko 30 osób, więc projekt powinien być mały.”
Niekoniecznie, bo projekt dla 30 użytkowników może wymagać skomplikowanej integracji z czterema systemami, nowych zasad odpowiedzialności, mechanizmów audytu oraz raportowania dla Zarządu. Z kolei proces obejmujący tysiące użytkowników może mieć bardzo precyzyjnie określone reguły i stosunkowo jednolitą ścieżkę.
Dobrym przykładem jest pierwszy etap digitalizacji procesu okresowej oceny pracy, który objął około 2400 pracowników i został zintegrowany między innymi z SAP HR oraz Active Directory. Dopiero po powodzeniu tego wdrożenia platformę wykorzystano szerzej – w procesach kancelaryjnych, zarządzaniu dostępami, umowach, zakupach, inwestycjach i kolejnych procesach kadrowych.
Kiedy „problem z procesem” jest tylko objawem?
W rozmowie z klientem często zaczynamy od konkretnego problemu:
- „Za długo akceptujemy umowy.”
- „Nie wiemy, gdzie znajduje się faktura.”
- „Zakupy trwają zbyt długo.”
- „Chcemy zautomatyzować onboarding.”
Samo spowolnienie procesu może jednak być objawem problemu znajdującego się gdzie indziej. Przykładowo, umowa nie czeka dlatego, że jej elektroniczny workflow jest niewystarczająco szybki. Czeka dlatego, że organizacja nie ma jasno określonego modelu decyzyjnego.
Zakup nie trwa długo z powodu braku formularza. Problemem może być brak spójnych limitów, właścicieli budżetów albo informacji pochodzących z ERP. Raport powstaje przez trzy dni nie dlatego, że źle zaprojektowano ekran systemu, lecz dlatego, że trzy działy inaczej interpretują ten sam wskaźnik. Dlatego podczas diagnozy szukamy kilku charakterystycznych sygnałów.
Sygnał 1. Proces regularnie wychodzi poza jeden dział
Jeden hand-off między działami nie oznacza jeszcze transformacji. Jeżeli jednak każdy kolejny fragment procesu wymaga nowych osób, nowych zasad i nowych decyzji, skala szybko rośnie.
Sygnał 2. Ta sama informacja ma kilka wersji
Jeżeli uczestnicy procesu używają różnych Exceli, baz, systemów dziedzinowych albo ręcznie uzgadniają dane, problemem nie jest już jedynie workflow. Problemem staje się model danych i źródło prawdy.
Sygnał 3. Decyzje podejmowane są poza procesem
Jeżeli system przesyła zadanie, ale faktyczna decyzja zapada na Teamsie, telefonicznie, w Excelu albo podczas spotkania – digitalizujemy jedynie otoczenie procesu, a nie sam proces.
Sygnał 4. Każdy dział mierzy sukces inaczej
Zakupy mierzą czas realizacji. Finanse kontrolę budżetu. Compliance zgodność. Biznes termin dostawy. Każdy z tych KPI może być poprawny, ale projekt musi rozstrzygnąć, jak pogodzić je w jednym przebiegu.
Sygnał 5. Proces tworzy dane do raportowania zarządczego
Wtedy zmiana sposobu realizacji procesu może zmienić sposób liczenia KPI, moment rejestracji danych oraz odpowiedzialność za ich jakość. To przestaje być jedynie projekt operacyjny.
Pięć wymiarów, którymi warto mierzyć skalę projektu
W praktyce przed decyzją o sposobie prowadzenia wdrożenia oceniłbym pięć obszarów.
1. Działy i odpowiedzialności
- Ile niezależnych obszarów organizacji uczestniczy w procesie?
- Czy posiadają jednego właściciela nadrzędnego?
- Czy zmieniamy zakres odpowiedzialności któregoś z zespołów?
2. Dane i integracje
- Z ilu systemów pobieramy informacje?
- Który system jest źródłem referencyjnym?
- Czy dane są ze sobą zgodne?
- Czy rezultat procesu musi zostać zapisany w kolejnych systemach?
3. Decyzje
- Czy system jedynie przesyła informacje, czy ma również egzekwować logikę podejmowania decyzji?
- Czy reguły są jednoznaczne?
- Czy występuje dużo wyjątków?
4. Compliance i audyt
- Czy proces realizuje wymagania regulacyjne, polityki bezpieczeństwa, ISO, RODO, zasady korporacyjne lub wymagania audytowe?
- Czy musimy być w stanie odtworzyć po kilku latach nie tylko wynik, ale również sposób podjęcia decyzji?
5. Raportowanie
- Kto będzie korzystał z informacji powstających w procesie?
- Czy raportujemy operacyjnie, controllingowo czy zarządczo?
- Czy uruchomienie rozwiązania zmieni definicję któregoś KPI?
Te pięć wymiarów mówi o projekcie znacznie więcej niż liczba ekranów.
Trzy sygnały, że „mały projekt” prawdopodobnie urośnie
W praktyce często podczas pierwszych rozmów można zastosować bardzo prostą metodologię.
Jeżeli występują co najmniej dwa z poniższych trzech elementów, projekt warto od początku traktować jako potencjalnie cross-organizacyjny:
1. Integracja z więcej niż jednym systemem trzecim
2. Zmiana ról lub odpowiedzialności pomiędzy zespołami.
3. Dane z procesu trafiają do raportowania zarządczego.
Nie jest to matematyczna reguła. Jest to sygnał ostrzegawczy. Każdy z tych elementów tworzy bowiem kolejną kategorię zależności, która musi zostać uzgodniona przed uruchomieniem rozwiązania.
Na początku drogi wprowadzania narzędzi workflow/BPM lepiej wybrać mniejszy proces niż utknąć w idealnym
To jedna z rekomendacji, do których przywiązuję dużą wagę. Jeżeli organizacja dopiero zaczyna swoją drogę z workflow, elektronicznym obiegiem dokumentów lub BPM, pierwszym celem nie powinno być stworzenie najbardziej zaawansowanego procesu, jaki jesteśmy sobie w stanie wyobrazić.
Wręcz odwrotnie: pierwszym celem powinno być uzyskanie działającego procesu, z którego użytkownicy rzeczywiście zaczną korzystać.
Dlatego często lepszym kandydatem na pierwsze wdrożenie jest proces:
- stosunkowo dobrze zdefiniowany,
- posiadający wyraźnego właściciela,
- o ograniczonej liczbie obszarów organizacyjnych,
- wystarczająco częsty, aby użytkownicy zobaczyli korzyść,
- ale równocześnie na tyle ograniczony, aby można było szybko zebrać doświadczenia.
Dobrym przykładem filozofii stopniowego rozwoju jest projekt w Gdańskich Wodociągach. Pierwszym etapem był elektroniczny obieg faktur zintegrowany z Dynamics 365. Po jego wdrożeniu i uzyskaniu oczekiwanych efektów automatyzację rozszerzono o zapotrzebowania, zamówienia oraz dokumenty magazynowe.
To podejście daje organizacji coś bardzo cennego: digital experience. Użytkownicy przestają projektować nowy proces wyłącznie na podstawie doświadczeń z papieru, Excela i poczty elektronicznej, a zaczynają rozumieć, co daje im workflow:
automatyczne przypisanie zadań, dynamiczne formularze, integracje, walidacje, raporty, kontrola terminów, historia działań, delegowanie, automatyczne decyzje czy równoległe ścieżki. I dopiero wtedy potrafią znacznie lepiej powiedzieć, czego potrzebują w kolejnym etapie.
MVP nie oznacza niekompletnego procesu
MVP (Minimum Viable Product – minimalna wersja produktu gotowa do użycia) w projektach procesowych bywa źle rozumiane. Bo nie chodzi o uruchomienie procesu, który „działa tylko trochę”.
Chodzi o świadome ustalenie, jaki najmniejszy zakres pozwala przeprowadzić kompletną wartość biznesową od początku do końca.
Możemy na przykład świadomie pozostawić część rzadkich wyjątków do obsługi ręcznej.
Możemy odłożyć zaawansowany dashboard.
Możemy zaplanować część integracji na kolejny etap.
Ale podstawowy scenariusz powinien tworzyć zamkniętą wartość dla użytkownika.
To szczególnie ważne, ponieważ dopiero działający proces pozwala zweryfikować założenia z analizy. Proces narysowany na warsztacie pokazuje nam, jak organizacja uważa, że pracuje. Proces uruchomiony w systemie bardzo szybko pokazuje nam, jak organizacja pracuje naprawdę.
Kiedy duży proces warto podzielić?
Podział dużego procesu nie musi oznaczać rezygnacji z podejścia end-to-end, a wręcz przeciwnie. Możemy zachować docelową architekturę end-to-end, ale dostarczać ją etapami.
Warto rozważyć podział, jeżeli:
- poszczególne fragmenty mają różnych właścicieli,
- część procesu może samodzielnie przynosić wartość,
- jeden fragment wymaga szczególnie trudnej integracji,
- jeden obszar posiada znacznie większą niepewność biznesową,
- zmiana wymaga przeszkolenia różnych grup użytkowników,
- organizacja dopiero buduje kompetencje procesowe.
Czasem jeden proces biznesowy warto technicznie zrealizować za pomocą kilku współpracujących procesów. Architektura procesu nie musi więc odzwierciedlać jednego ogromnego diagramu.
Powinna odzwierciedlać logikę biznesową oraz umożliwiać jej bezpieczny rozwój.
Podsumowie
Po 15 latach doświadczeń e-MSI w digitalizacji procesów jest to jedna z najważniejszych lekcji płynących z projektów prowadzonych w bardzo różnych organizacjach: od procesów obejmujących pojedyncze obszary po transformacje łączące wiele jednostek, systemów oraz funkcji przedsiębiorstwa. Portfolio e-MSI obejmuje między innymi realizacje dla MyOrlen, DHL Parcel Polska, Anwim, administracji publicznej, Gdańskich Wodociągów oraz innych organizacji korzystających z workflow, automatyzacji procesów i integracji systemów.
I dlatego organizacjom rozpoczynającym swoją drogę z budowaniem procesów w oparciu o narzędzia Workflow/BPM rekomenduję przede wszystkim jedno:
nie zaczynajcie od procesu najbardziej spektakularnego. Zacznijcie od procesu, który pozwoli organizacji nauczyć się digitalizacji.
Zanim jednak organizacja zdecyduje, od którego obszaru rozpocząć, warto dobrze rozpoznać procesy, ich zależności i rzeczywistą skalę planowanego projektu. Pomocnym punktem wyjścia może być audyt procesów biznesowych, który pozwala spojrzeć na obecny sposób działania organizacji i wskazać obszary z największym potencjałem do digitalizacji.
Warto też jeszcze przed startem wdrożenia sprawdzić, czy projekt rzeczywiście dotyczy jednego procesu, czy już na początku obejmuje większą część organizacji. W tym celu przygotowaliśmy Checklistę: Diagnoza skali projektu IT – 15 pytań, która pomaga szybko ocenić liczbę zależności organizacyjnych, systemowych i decyzyjnych związanych z planowanym wdrożeniem.
A potem:
Uruchomcie rozwiązanie.
Pozwólcie użytkownikom zacząć z niego korzystać.
Zbierajcie informacje.
Rozwijajcie proces w oparciu o rzeczywiste doświadczenie użytkowników.
A dopiero później zwiększajcie powierzchnię organizacyjną kolejnych wdrożeń.
Bo dobra transformacja cyfrowa bardzo rzadko polega na przeniesieniu do systemu tego, jak organizacja pracowała do tej pory.
Jej wartość zaczyna się wtedy, gdy technologia pozwala organizacji pracować inaczej niż wcześniej.
Autor tekstu:
Bartosz Wicijowski | Chief Sales Officer
