Jeden proces, wiele systemów i dostawców. Kto odpowiada za wynik?

Platforma B2B przyjęła zamówienie. ERP je zarejestrował. WMS nie zgłasza błędu. Integracja z przewoźnikiem również działa.

A klient nadal nie otrzymał zamówienia.

W środowisku złożonym z wielu aplikacji właśnie takie sytuacje należą do najtrudniejszych. Problem nie musi wynikać z awarii jednego systemu. Może powstać pomiędzy nimi - przez brak statusu, inną interpretację danych, opóźnienie albo sytuację wyjątkową, której nikt wcześniej nie przypisał do konkretnego właściciela.

Każdy dostawca może wtedy zgodnie z prawdą powiedzieć: „po naszej stronie działa”.

Z perspektywy biznesu problem pozostaje nierozwiązany.

Dlatego przy projektowaniu systemów biznesowych nie wystarczy ustalić, kto odpowiada za poszczególne aplikacje. Trzeba również wiedzieć, kto patrzy na cały proces i odpowiada za to, aby kolejne elementy prowadziły do oczekiwanego rezultatu.

Jedno zamówienie, kilka systemów, jeden rezultat

Prześledźmy typowy proces sprzedaży B2B.

Klient składa zamówienie na platformie. System wykorzystuje dane produktowe i handlowe, sprawdzane są ceny, warunki współpracy lub limit kontrahenta. Zamówienie trafia do ERP, następnie do magazynu lub WMS. Po przygotowaniu wysyłki dane przekazywane są do operatora logistycznego, a status realizacji powinien wrócić do systemów wewnętrznych i ostatecznie do klienta.

W procesie mogą uczestniczyć również PIM, CRM, system płatności, DMS i rozwiązania partnerów zewnętrznych.

Każdy z tych systemów realizuje własny fragment procesu. Każdy może mieć osobnego właściciela i innego dostawcę.

Wyobraźmy sobie teraz, że między ERP a WMS nie pojawia się oczekiwany status.

ERP wykonał własną operację poprawnie. WMS nie otrzymał informacji, na którą czeka, więc nie ma czego przetwarzać. Platforma B2B nadal pokazuje ostatni znany stan. Żaden z systemów nie musi być niedostępny ani formalnie „zepsuty”.

Operacyjnie zamówienie stoi.

Handlowiec zaczyna sprawdzać sytuację ręcznie. Do sprawy włącza się obsługa klienta. IT analizuje kolejne aplikacje. Dostawcy weryfikują własne zakresy. Czas rozwiązania rośnie, mimo że sama przyczyna może być niewielka.

Najważniejszym problemem nie jest wtedy nawet brak jednego komunikatu. Jest nim brak szybkiej odpowiedzi na trzy pytania:

• Gdzie zatrzymał się proces?
• Dlaczego się zatrzymał?
• Kto prowadzi sprawę do rozwiązania?

Granice aplikacji nie są granicami procesu biznesowego

Architektura IT dzieli środowisko na aplikacje, moduły, interfejsy i zakresy odpowiedzialności. Proces biznesowy ma inne granice - wyznacza je rezultat, który organizacja chce osiągnąć.

Klient nie ocenia osobno platformy B2B, ERP i WMS. Ocenia, czy może złożyć zamówienie, otrzymać właściwy produkt, znać jego status i dostać wymagane dokumenty.

Podobnie właściciel procesu nie potrzebuje kilku poprawnie działających fragmentów, jeżeli nie prowadzą one do oczekiwanego wyniku.

Dlatego poprawność komponentu i poprawność procesu end-to-end to dwie różne rzeczy.

Można mieć sprawny e-commerce, poprawnie działające ERP, wyspecjalizowany WMS i prawidłowe połączenia pomiędzy nimi, a nadal pozostawić luki na styku systemów. Szczególnie dobrze widać je wtedy, gdy standardowy przebieg przestaje wystarczać: brakuje towaru, zmienia się cena, zamówienie jest realizowane częściowo albo jeden z etapów wymaga dodatkowej decyzji.

To właśnie sytuacje wyjątkowe pokazują, czy zaprojektowano cały proces, czy tylko jego poszczególne części.

Odpowiedzialność za komponent to nie to samo co odpowiedzialność za przepływ

Każdy system powinien mieć jasno określony zakres odpowiedzialności. To jednak nie rozwiązuje problemu procesu przechodzącego przez kilka aplikacji.

Potrzebne są dwa poziomy odpowiedzialności.

Pierwszy to właściciel procesu po stronie organizacji. To osoba lub rola odpowiedzialna za oczekiwany rezultat, reguły biznesowe, sytuacje wyjątkowe i konsekwencje błędów.

Drugi to perspektywa technologiczna obejmująca cały przepływ - zależności pomiędzy systemami, źródła danych, punkty kontrolne i sposób diagnozowania problemów.

Nie oznacza to, że jeden partner technologiczny powinien odpowiadać kontraktowo za bezawaryjne działanie ERP innego producenta, systemu bankowego, platformy przewoźnika czy każdej usługi zewnętrznej.

Może natomiast projektować własny zakres z uwzględnieniem całego procesu, monitorować istotne punkty wymiany danych, pomagać zlokalizować problem i uczestniczyć w koordynacji działań pomiędzy zaangażowanymi stronami.

To zasadnicza różnica.

Odpowiedzialność end-to-end nie oznacza pełnej kontroli nad każdym systemem. Oznacza, że ktoś widzi proces szerzej niż granice własnego modułu.

Cztery warunki kontroli procesu end-to-end

Samo wskazanie właściciela nie wystarczy. Odpowiedzialność trzeba przełożyć na konkretne zasady działania systemów i zespołów.

1. Dla najważniejszych danych musi być wiadomo, który system rozstrzyga

Te same informacje często występują w kilku aplikacjach.

Cena może być prezentowana w e-commerce, ale wynikać z ERP. Opis produktu może trafiać do wielu kanałów, lecz pochodzić z PIM. Stan magazynowy może być widoczny dla handlowca, klienta i magazynu, ale jeden system powinien dostarczać informację rozstrzygającą.

Podobnej decyzji wymagają zamówienia, dokumenty i statusy realizacji.

Nie chodzi o to, aby każda informacja fizycznie istniała tylko w jednym miejscu. Chodzi o jasną odpowiedź na pytanie:

który system rozstrzyga, jeżeli pojawi się rozbieżność?

Bez takiej zasady dwa poprawnie działające systemy mogą prezentować dwie różne wersje tej samej sytuacji.

2. Testować trzeba proces, nie tylko połączenia

Potwierdzenie, że system A potrafi wysłać dane do systemu B, nie oznacza jeszcze, że zamówienie, reklamacja albo dostawa zostaną poprawnie zrealizowane.

Test powinien zaczynać się tam, gdzie zaczyna się realny scenariusz użytkownika, i kończyć dopiero na oczekiwanym rezultacie biznesowym.

W przypadku zamówienia B2B oznacza to przeprowadzenie całego przebiegu - od działania klienta, przez weryfikację danych i realizację magazynową, po wysyłkę oraz aktualny status widoczny dla użytkownika.

Trzeba również sprawdzić sytuacje wyjątkowe.

Co wydarzy się, jeżeli produktu zabraknie? Jeśli zmieni się warunek handlowy? Gdy zamówienie można zrealizować tylko częściowo? Kto podejmuje decyzję i jak informacja wraca do pozostałych systemów?

Takie scenariusze często ujawniają problemy niewidoczne podczas testowania aplikacji osobno.

3. Pojedynczą sprawę trzeba umieć prześledzić przez cały proces

Gdy klient pyta o konkretne zamówienie, informacja „wszystkie systemy działają” nie rozwiązuje problemu.

Organizacja powinna móc ustalić, jakie etapy przeszło właśnie to zamówienie, jaki był ostatni poprawny krok i gdzie proces przestał zachowywać się zgodnie z oczekiwanym scenariuszem.

To samo dotyczy reklamacji, dokumentu, płatności, przesyłki czy innej sprawy biznesowej.

Dopiero taka perspektywa pozwala przejść od ogólnego zgłoszenia „coś nie działa” do konkretnej diagnozy.

4. Zasady eskalacji trzeba ustalić przed pojawieniem się problemu

W środowisku wielu systemów i dostawców warto wcześniej określić nie tylko zakresy odpowiedzialności, ale również zależności pomiędzy nimi.

Powinno być wiadomo, jakie są kluczowe punkty kontrolne, kto rozpoczyna diagnozę, jakie informacje trzeba zebrać, kiedy sprawa przechodzi do kolejnego zespołu i kto pilnuje jej zamknięcia z perspektywy całego procesu.

Takie zasady nie eliminują błędów.

Ograniczają natomiast sytuacje, w których kilka zespołów potwierdza poprawność własnych fragmentów, a nikt nie prowadzi problemu do końcowego rozwiązania.

Wielu wyspecjalizowanych dostawców może być zaletą

Odpowiedzialność end-to-end nie oznacza, że firma powinna dążyć do jednego systemu realizującego wszystkie procesy.

W wielu organizacjach wyspecjalizowane rozwiązania są świadomym i uzasadnionym wyborem.

Pozwalają dobrać narzędzia najlepiej odpowiadające konkretnym procesom, niezależnie rozwijać poszczególne obszary i unikać podporządkowywania całej organizacji ograniczeniom jednej aplikacji. Firma może korzystać z wyspecjalizowanego PIM do zarządzania informacją produktową, WMS dopasowanego do logistyki, własnej platformy sprzedażowej i usług zewnętrznych partnerów - bez konieczności zastępowania wszystkiego jednym rozwiązaniem.

Taki model daje elastyczność także wtedy, gdy jeden z elementów środowiska wymaga modernizacji lub wymiany. Zmiana konkretnego rozwiązania nie musi automatycznie oznaczać przebudowy wszystkich pozostałych.

Kosztem tej elastyczności jest jednak większa liczba zależności, które trzeba świadomie zaprojektować i kontrolować.

Problem pojawia się więc nie dlatego, że systemów lub dostawców jest wielu. Pojawia się wtedy, gdy wraz z podziałem systemów podzielona zostaje również odpowiedzialność za rezultat.

Im więcej granic pomiędzy aplikacjami i zespołami, tym ważniejsze stają się wspólne zasady dotyczące danych, testowania, monitorowania procesu i obsługi wyjątków.

Dlatego najważniejsze pytanie nie brzmi:

„Czy mamy za dużo systemów?”

Lepiej zapytać:

„Czy rozumiemy, jak cały proces przechodzi przez te systemy i co powinno wydarzyć się na każdym jego etapie?”

Partner technologiczny powinien patrzeć szerzej niż na własny moduł

To również dobre kryterium oceny firmy uczestniczącej w projekcie.

Warto sprawdzić, czy podczas analizy dostawca interesuje się systemami działającymi przed i po jego rozwiązaniu, pyta o źródła danych, uwzględnia sytuacje wyjątkowe i potrafi uczestniczyć we wspólnych testach całego scenariusza.

Istotne jest także, co dzieje się po uruchomieniu. Czy w razie problemu partner ogranicza diagnozę do potwierdzenia poprawności własnego komponentu, czy pomaga ustalić, na którym etapie przepływ przestał działać zgodnie z założeniami.

W Certusoft integracje projektujemy jako część całego procesu, a nie jako odizolowane połączenia pomiędzy aplikacjami. Łączymy m.in. ERP, WMS, PIM, e-commerce, POS, dokumenty, urządzenia i systemy partnerów, ale punktem odniesienia pozostaje proces, który te elementy mają wspólnie realizować.

Dzięki temu rozmowa o integracji nie kończy się na pytaniu, czy dane można przesłać z jednego systemu do drugiego. Równie ważne jest to, jaką rolę ta wymiana pełni w całym procesie i jaki rezultat ma umożliwić.

Pięć pytań przed uruchomieniem procesu obejmującego wiele systemów

Przed startem warto sprawdzić:

1. Czy cały proces ma jednego właściciela biznesowego?
   Kto odpowiada za jego rezultat od początku do końca, niezależnie od liczby aplikacji?

2. Czy wiadomo, który system rozstrzyga najważniejsze dane?
   Gdzie ustalane są produkt, cena, stan, zamówienie, dokument i status?

3. Czy testy obejmują pełny przebieg i sytuacje wyjątkowe?
   Czy sprawdzamy rezultat procesu, a nie tylko poprawność poszczególnych połączeń?

4. Czy można prześledzić pojedynczą sprawę przez wszystkie istotne systemy?
   Czy potrafimy ustalić, gdzie znajduje się konkretne zamówienie, dokument lub zgłoszenie?

5. Czy zakresy odpowiedzialności i zasady eskalacji zostały ustalone przed startem?
   Czy wiadomo, kto rozpoczyna diagnozę, kto uczestniczy w rozwiązaniu i kto pilnuje zamknięcia sprawy?

Jeżeli odpowiedź na któreś z tych pytań jest niejasna, ryzyko może nie wynikać z jakości konkretnej aplikacji. Może powstawać w przestrzeni pomiędzy systemami.

Systemy są elementami. Ostatecznie liczy się proces

W dojrzałym środowisku IT nie chodzi o to, aby wszystkie funkcje realizowała jedna aplikacja ani żeby jeden dostawca kontrolował każdy element infrastruktury.

Chodzi o coś bardziej praktycznego.

Organizacja powinna wiedzieć, jak jej najważniejsze procesy przechodzą przez kolejne systemy, które dane są rozstrzygające, gdzie znajdują się punkty krytyczne i kto odpowiada za diagnozę oraz koordynację wtedy, gdy przepływ nie prowadzi do oczekiwanego rezultatu.

Dopiero wtedy informacja „każdy system działa poprawnie” ma pełną wartość biznesową.

Bo dla klienta, handlowca, magazynu czy zarządu ostatecznym testem nie jest poprawność pojedynczej aplikacji.

Jest nim poprawnie zakończony proces.

Przeanalizujmy proces, który przechodzi przez kilka systemów

Jeżeli ważny proces w Twojej organizacji obejmuje kilka aplikacji, zespołów lub dostawców i trudno wskazać jednego właściciela technologicznego całego przepływu, warto zacząć od uporządkowania zależności, źródeł danych i punktów odpowiedzialności.
Porozmawiajmy o procesie i sprawdźmy, gdzie odpowiedzialność może dziś się rozmywać.

---

FAQ

Co oznacza odpowiedzialność za proces end-to-end?

Oznacza spojrzenie na pełny przebieg procesu - od zdarzenia, które go rozpoczyna, do rezultatu biznesowego - wraz z zależnościami pomiędzy systemami, źródłami danych, punktami kontrolnymi i zasadami diagnozowania problemów.

Czy jeden dostawca powinien odpowiadać za wszystkie systemy w procesie?

Nie. Poszczególne systemy mogą mieć różnych właścicieli i dostawców. Ważne jest jednak jasne określenie odpowiedzialności za architekturę przepływu, własny zakres integracji, diagnozę problemów i współpracę wtedy, gdy problem obejmuje kilka rozwiązań.

Co oznacza „źródło prawdy” w systemach biznesowych?

To system, którego dane są traktowane jako rozstrzygające dla określonego rodzaju informacji. Przykładowo PIM może pełnić tę rolę dla danych produktowych, ERP dla warunków handlowych, a system magazynowy dla stanów - zależnie od architektury organizacji.

Dlaczego testy poszczególnych integracji nie wystarczą?

Ponieważ poprawna wymiana danych pomiędzy dwoma systemami nie gwarantuje poprawnego zakończenia całego procesu. Test end-to-end sprawdza pełny scenariusz biznesowy, również w sytuacjach wyjątkowych.

Jak zidentyfikować lukę w odpowiedzialności między systemami?

Warto prześledzić jeden rzeczywisty proces od początku do końca i dla każdego etapu wskazać system, źródło danych, punkt kontrolny oraz osobę lub zespół odpowiedzialny w sytuacji wyjątku. Jeżeli pomiędzy dwoma etapami nie wiadomo, kto rozpoznaje problem i prowadzi go do rozwiązania, właśnie tam może powstawać luka odpowiedzialności.