Automatyzacja end-to-end bez wielkiego projektu, który trwa latami

Im większy projekt, tym silniejsza pokusa, by najpierw zebrać kompletną specyfikację, a dopiero później rozpocząć budowę rozwiązania. Problem pojawia się, gdy część wymagań dezaktualizuje się jeszcze przed uruchomieniem systemu. Z biegiem czasu zmienić się mogą procesy, struktura organizacyjna, regulacje albo oczekiwania użytkowników.

W klasycznym modelu rozbudowanego wdrożenia przedsiębiorstwo może otrzymać rozwiązanie zgodne z pierwotną specyfikacją, ale już nie w pełni dopasowane do rzeczywistego sposobu pracy. Jedne funkcje trzeba dodawać, inne modyfikować. Oznacza to kolejne koszty i wydłużenie prac.

Jednym ze sposobów ograniczenia tego ryzyka jest rozwijana iteracyjnie automatyzacja end-to-end. Zamiast próbować szczegółowo opisać cały docelowy system przed rozpoczęciem prac, organizacja może wyjść od konkretnego problemu i możliwie szybko uruchomić pierwsze działające rozwiązanie. Dane o czasie realizacji zadań, wyjątkach czy wąskich gardłach pozwalają następnie zweryfikować pierwotne założenia i na tej podstawie decydować o kolejnych etapach rozwoju.

Rozbudowane wdrożenie, w którym organizacja próbuje z góry opisać docelowy kształt całego środowiska procesowego, można porównać do projektowania domu w najdrobniejszych szczegółach jeszcze przed rozpoczęciem budowy. Problem pojawia się wtedy, gdy między stworzeniem projektu a zakończeniem prac zmieniają się potrzeby jego przyszłych mieszkańców. Część pierwotnych założeń trzeba wówczas modyfikować, choć ich realizacja już się rozpoczęła.

W przypadku systemów do automatyzacji procesów bizneoswych podobne zmiany są właściwie nieuniknione, bo w międzyczasie pojawiają się np. nowe wymagania i regulacje, zmieniają się struktury organizacyjne czy sposób pracy. Mimo to, zamiast próbować przewidzieć docelowy kształt wszystkich procesów, można rozpocząć od jednego, a następnie łączyć go z kolejnymi aplikacjami i systemami, stopniowo rozwijając automatyzację end-to-end. Jak może ona wyglądać?

Punktem wyjścia może być proces obsługi faktur. Początkowo obejmuje on elektroniczną akceptację dokumentów. Uruchamiany jest możliwie najszybciej, by móc go przetestować w praktyce. W tej fazie szybko ujawniają się potrzeby kolejnych zespołów: połączenie z obsługą płatności, workflow finansowym czy systemem ERP. W dalszej kolejności rozwiązanie może objąć także obieg zamówień, kontrolę budżetu, rozliczanie kosztów czy obsługę umów powiązanych z danym wydatkiem.

Jeżeli nowe aplikacje powstają na wspólnym fundamencie, nie trzeba za każdym razem budować osobnego zaplecza technologicznego. Kolejne procesy mogą korzystać ze wspólnych danych, komponentów, integracji i mechanizmów kontroli. Tak budowane aplikacje nie pozostają odrębnymi wyspami, ale tworzą portfolio zintegrowanych ze sobą rozwiązań.

Wspólne środowisko ułatwia też:

• audytowalność,
• bieżące monitorowanie procesów,
• transparentne raportowanie.

Inicjatywy można dzięki temu priorytetyzować na podstawie danych procesowych, a nie wyłącznie presji poszczególnych działów. Efektem działań nie jest „wielki system” wdrożony jednym projektem, ale środowisko, które rośnie wraz z kolejnymi potrzebami biznesu – również takimi, które pojawiają się nagle i które trudno przewidzieć na etapie analiz.