Najpierw proces, potem SAP. Dlaczego samo SLA nie wystarczy?

Zmiana w systemie to dopiero jedna z możliwości

Wyobraźmy sobie sytuację, która w różnych wariantach regularnie pojawia się w pracy z systemami ERP. Użytkownicy zgłaszają problemy dotyczące tego samego etapu procesu. Support analizuje zgłoszenie, znajduje rozwiązanie i zamyka ticket. Wszystko przebiega zgodnie z ustalonym SLA.

Na poziomie pojedynczego zgłoszenia trudno powiedzieć, że coś poszło nie tak. Użytkownik otrzymał pomoc, problem został usunięty, a czas reakcji i rozwiązania mieścił się w wymaganym poziomie. Po kilku tygodniach pojawia się jednak kolejne zgłoszenie dotyczące tego samego obszaru. Potem następne.

I wtedy warto spojrzeć na sprawę trochę szerzej. Możemy ponownie rozwiązać zgłoszenie, zrobić to szybko i zgodnie z SLA, a mimo to nie poprawić sytuacji w dłuższej perspektywie. Pomocny może być również raport pokazujący skalę oraz częstotliwość występowania podobnych problemów.

Zgłoszenie rozwiązane. Problem nadal istnieje

SLA jest potrzebne. Określa zasady współpracy, pozwala mierzyć czas reakcji i rozwiązania oraz daje obu stronom jasny punkt odniesienia. Przede wszystkim pozwala ocenić, czy właściwie obsłużyliśmy zgłoszenie. Same wskaźniki nie opowiadają jednak całej historii.

Z perspektywy całej usługi ważne jest również to, czy dzięki naszej pracy podobne sytuacje będą pojawiały się rzadziej. Nie oznacza to, że każde zgłoszenie powinno kończyć się analizą przyczyn źródłowych czy dużym projektem naprawczym. Byłoby to nieefektywne i zwyczajnie niepotrzebne. Jeżeli jednak widzimy powtarzalny schemat, warto go nie ignorować. Seria podobnych zgłoszeń może być sygnałem, że źródło trudności znajduje się głębiej niż pojedynczy błąd.

W takiej sytuacji warto spojrzeć na wcześniejsze przypadki razem, znaleźć zależności i sprawdzić, czy dotychczasowe rozwiązania rzeczywiście usuwają przyczynę, czy tylko pozwalają kontynuować pracę. W takich analizach coraz częściej pomaga analityka, a także narzędzia wykorzystujące sztuczną inteligencję.

Co właściwie próbujemy naprawić?

To pytanie wydaje się banalne. W praktyce wcale takie nie jest. Użytkownik zgłasza, że nie może przejść dalej. Biznes mówi, że proces jest zbyt wolny. Konsultant widzi błąd w systemie. Developer dostaje wymaganie dotyczące zmiany. Każda z tych osób może mieć rację, ale każda patrzy na sytuację z nieco innej perspektywy.

Trudność pojawia się wtedy, kiedy zaczynamy rozwiązywać kwestię techniczną, zanim dobrze zrozumiemy potrzebę biznesową. W naszym przykładzie powtarzające się zgłoszenia mogą sugerować potrzebę zmiany w SAP, ale równie dobrze mogą wskazywać na niejasne zasady pracy, problemy z danymi, brak odpowiedzialności za konkretny etap albo rozwiązanie, które nie odpowiada już rzeczywistemu sposobowi działania organizacji.

Na początku wszystkie te sytuacje mogą wyglądać podobnie – jak „problem w SAP”. W praktyce prowadzą jednak do różnych rozwiązań, od zmiany konfiguracji po dostosowanie istniejącego systemu.

SAP jest częścią procesu

System ERP nie działa w oderwaniu od organizacji. Za każdym workflow, walidacją, formularzem czy automatyzacją stoją ludzie, odpowiedzialności i określony sposób pracy. Dlatego problem widoczny w SAP niekoniecznie powstał w SAP.

Może wynikać ze sposobu przygotowywania danych, braku jasnej odpowiedzialności albo z tego, że różne zespoły rozumieją ten sam etap procesu w nieco inny sposób. Czasami przyczyną jest również historia. Proces został zaprojektowany kilka lat temu, później organizacja się zmieniła, pojawiły się nowe role, nowe wymagania i kolejne wyjątki. System był modyfikowany krok po kroku, żeby nadążyć za tymi zmianami.

Każda pojedyncza decyzja mogła być uzasadniona. Po kilku latach całość może jednak wyglądać zupełnie inaczej niż pierwotnie. I właśnie wtedy warto zrobić krok wstecz. Nie po to, żeby szukać winnego, ale żeby sprawdzić, czy nadal wiemy, jak powinien działać cały proces. Dotyczy to zarówno środowisk opartych o SAP ERP, SAP ECC, jak i SAP HANA.

Krok wstecz nie oznacza zatrzymania

W środowisku IT łatwo odnieść wrażenie, że każda potrzeba powinna zostać zamieniona w zadanie. Ale nie zawsze pierwszym krokiem powinien być development. Czasem lepszym początkiem jest rozmowa z właścicielem procesu, przejście całej ścieżki razem z użytkownikiem albo sprawdzenie, co dzieje się przed miejscem, w którym pojawia się problem. Warto też zobaczyć, jak proces wygląda w praktyce, nie tylko w dokumentacji.

Dopiero wtedy łatwiej zdecydować, czy rzeczywiście potrzebujemy zmiany w systemie. Może to wydawać się wolniejsze, ale w rzeczywistości często pozwala uniknąć pracy, która później okaże się niepotrzebna. To ważny element planowania, realizacji projektu oraz skutecznego zarządzania zmianą.

Nie każda zmiana jest neutralna

Zmiana w SAP nie kończy się w momencie jej wdrożenia. Trzeba ją zaplanować, przetestować i udokumentować. Czasami trzeba dodatkowo przeszkolić użytkowników. Pojawiają się nowe zależności, które mogą mieć znaczenie przy kolejnych modyfikacjach. Dochodzi również coś, czego nie zawsze widać w momencie podejmowania decyzji: koszt utrzymania rozwiązania.

Dzisiaj dodajemy jeden wyjątek, żeby obsłużyć konkretny przypadek. Za kilka miesięcy pojawia się kolejny. Dodajemy więc następny. Po pewnym czasie system SAP zaczyna odzwierciedlać nie tyle dobrze zaprojektowany proces, co historię wszystkich problemów, które próbowaliśmy rozwiązać pojedynczymi zmianami.

Oczywiście nie każda modyfikacja prowadzi do takiego efektu. Chodzi raczej o świadomość, że każda decyzja techniczna ma swój dalszy ciąg. Dlatego przed wprowadzeniem kolejnej zmiany warto spojrzeć nie tylko na to, czy jest możliwa, ale również na to, czy właśnie w ten sposób powinniśmy rozwiązać dany problem. Ma to szczególne znaczenie podczas wdrożenia systemu, implementacji lub większej transformacji środowiska IT.

A gdzie w tym wszystkim jest Service Support?

Dla mnie właśnie tutaj zaczyna się ciekawsza część tej pracy. Support nie powinien być wyłącznie miejscem, do którego trafiają problemy, a następnie znikają po zamknięciu zgłoszenia.

Oczywiście codzienna obsługa musi działać. Użytkownik potrzebuje odpowiedzi, biznes potrzebuje ciągłości działania, a uzgodnione SLA trzeba realizować. Ale zespół projektowy lub zespół wsparcia, który przez dłuższy czas pracuje z daną usługą, zdobywa wiedzę, której nie da się znaleźć wyłącznie w dokumentacji. Wie, które problemy wracają, gdzie użytkownicy najczęściej się zatrzymują i które elementy procesu wymagają najwięcej uwagi.

Widząc kolejne podobne zgłoszenie, można zauważyć zależność, której nie widać przy analizie pojedynczego ticketu. To właśnie takie obserwacje mogą stać się punktem wyjścia do realnych udoskonaleń. To właśnie takie obserwacje mogą stać się punktem wyjścia do realnych usprawnień, monitorowania trendów oraz lepszego raportowania wyników.

SLA i Continuous Improvement powinny się uzupełniać

Nie traktuję SLA i Continuous Improvement jako dwóch różnych podejść. SLA pomaga nam ocenić, czy dobrze realizujemy usługę tu i teraz. Analiza zgłoszeń, problemów i procesów pozwala z kolei zastanowić się, jak ta usługa może działać lepiej w przyszłości.

Jedno bez drugiego może być niewystarczające. Możemy mieć bardzo dobre wyniki SLA, a jednocześnie dużą liczbę powtarzających się zgłoszeń. Możemy też mieć niewielką liczbę ticketów, ale proces, który jest skomplikowany, ręczny i zależny od wiedzy pojedynczych osób.

Dlatego same KPI nie zawsze powiedzą nam, gdzie naprawdę znajduje się przestrzeń do poprawy. Czasami trzeba połączyć liczby z doświadczeniem ludzi, którzy na co dzień pracują z usługą. Szczególnie w organizacjach przechodzących migrację, wdrożenie SAP lub modernizujących oprogramowanie SAP.

Continuous Improvement nie oznacza ciągłego zmieniania

To chyba jedna z ważniejszych rzeczy, których nauczyła mnie praca z procesami. Doskonalenie nie zawsze oznacza nową funkcjonalność, automatyzację czy kolejny projekt.

Czasami usprawnieniem jest usunięcie niepotrzebnego kroku, uporządkowanie danych albo doprecyzowanie odpowiedzialności. Innym razem będzie to aktualizacja instrukcji, która od dawna nie odpowiada temu, jak proces wygląda w rzeczywistości. Może to być również lepsza komunikacja pomiędzy zespołami.

A niekiedy decyzja, żeby na razie niczego w SAP nie zmieniać.

To ostatnie może być szczególnie trudne, bo w świecie IT łatwo utożsamić zmianę z postępem. Tymczasem nie każda zmiana poprawia proces i nie każda automatyzacja upraszcza pracę. Czasami większą wartość przynosi optymalizacja danych i procesów niż kolejne rozszerzanie funkcjonalności.

Ostatecznie chodzi o właściwą zmianę

Nie jestem zwolenniczką podejścia „nie zmieniajmy SAP, bo problem może być w procesie”. Zmiany w systemie są potrzebne i często przynoszą ogromną wartość. Chodzi raczej o kolejność.

Najpierw zrozumieć, co naprawdę chcemy poprawić. Potem przyjrzeć się procesowi i znaleźć przyczynę. Dopiero później zdecydować, jakie rozwiązanie będzie najlepsze: zmiana w SAP, zmiana procesu, uporządkowanie danych, lepsza komunikacja czy może kilka z tych elementów jednocześnie.

Mam wrażenie, że coraz łatwiej o tej kolejności zapomnieć. Tempo pracy, presja na szybkie rozwiązania i możliwości technologiczne sprawiają, że chcemy przejść od problemu prosto do odpowiedzi. Szczególnie dziś, gdy nowe technologie, cloud, chmura oraz rozwój rozwiązań SAP dają coraz więcej możliwości. Czasami warto zrobić krok wstecz. Nie po to, żeby spowalniać zmianę, ale żeby mieć większą pewność, że zmieniamy właściwą rzecz.

Dobra zmiana nie zaczyna się więc od pytania: „Co zmienić w SAP?”. Zaczyna się od prostszego pytania: „Co właściwie chcemy poprawić?”. Dopiero wtedy można świadomie planować wdrożenie nowego rozwiązania, rozwijać system SAP ERP oraz skutecznie zarządzać dalszym rozwojem organizacji.