ERP

Wdrożenie SAP lub innego systemu ERP nie kończy pracy nad zmianą. Bardzo często dopiero ją rozpoczyna. Po uruchomieniu systemu firma zaczyna działać w środowisku, które trzeba dalej rozwijać: dopasowywać procesy, zmieniać raportowanie, korygować pola, aktualizować uprawnienia, usprawniać ścieżki akceptacji, reagować na potrzeby działów i poprawiać rozwiązania, które w praktyce okazały się niewystarczające.

Tak było w firmie produkcyjnej ze środkowej Polski, z którą pracowałem przy wdrażaniu małych zmian w SAP. W dwudniowym warsztacie, realizowanym w formule 2 × 8 godzin, wzięło udział 18 osób zaangażowanych w przygotowywanie i wdrażanie zmian w systemie.

Przez 16 godzin pracy warsztatowej zajmowaliśmy się jednym konkretnym wyzwaniem: jak wdrażać wiele małych zmian w SAP tak, aby nie przeciążać użytkowników i nie budować dużego projektu dla każdej modyfikacji systemu.

SAP i ERP żyją po wdrożeniu

Dla zespołu odpowiedzialnego za SAP kolejne modyfikacje są naturalną częścią rozwoju systemu. Firma się zmienia, procesy dojrzewają, dane wymagają lepszej jakości, raporty mają odpowiadać na nowe potrzeby menedżerów, a użytkownicy zgłaszają uwagi wynikające z codziennej pracy.

Z perspektywy użytkowników wygląda to jednak inaczej. Każda korekta oznacza konieczność dostosowania sposobu pracy. Czasem chodzi o nowe pole. Czasem o inną kolejność działań. Czasem o zmienioną odpowiedzialność, dodatkowy krok akceptacji, nowy raport albo inny sposób wprowadzania danych.

I wtedy pojawiają się narzekania:

• „Dopiero nauczyliśmy się poprzedniego rozwiązania”.
• „Czy znowu mamy robić to inaczej?”.
• „Kiedy wreszcie będzie stabilnie?”.
• „Dlaczego ciągle coś się zmienia?”.

Takie komentarze to naturalne reakcje ludzi, którzy mają wykonywać swoją codzienną pracę, obsługiwać procesy, realizować zadania, dbać o dane, terminy i wyniki, a jednocześnie co chwilę dostosowywać się do kolejnych zmian w systemie.

Mała zmiana w systemie nie zawsze jest mała dla użytkownika

Jednym z najważniejszych wniosków z pracy z zespołami wdrażającymi zmiany w ERP jest prosty fakt: wielkość zmiany technicznej nie zawsze odpowiada wielkości zmiany po stronie użytkownika.

Dla zespołu SAP modyfikacja może być niewielka. Dla użytkownika może oznaczać przerwanie rutynowego sposobu pracy. Jeżeli ktoś przez kilka miesięcy wykonywał czynność w określony sposób, znał ekran, kolejność kliknięć, pola i zależności, to każda zmiana wymaga ponownego uczenia się. Nawet wtedy, gdy z perspektywy systemu jest to tylko drobna korekta.

Kiedy liczba zmian staje się problemem

W firmie, z którą pracowałem, wyzwaniem nie była jedna konkretna modyfikacja SAP. Problemem była liczba zmian i ich częstotliwość. Użytkownicy zaczynali mieć poczucie, że zamiast spokojnie wykonywać swoją pracę, stale dostosowują się do systemu.

Zespół odpowiedzialny za SAP znalazł się w trudnym położeniu. Z jednej strony wdrażał usprawnienia, poprawiał jakość danych, reagował na potrzeby biznesu i rozwijał system. Z drugiej strony coraz częściej słyszał od użytkowników, że zmian jest za dużo, że są uciążliwe i że brakuje stabilności.

Zespół wdrażający chce usprawniać działanie firmy. Użytkownicy chcą dobrze wykonywać swoje obowiązki. Obie perspektywy są uzasadnione. Problem zaczyna się wtedy, gdy brakuje wypracowanego sposobu przeprowadzania małych zmian.

Dlaczego pełny projekt dla każdej zmiany w SAP nie ma sensu?

Przy dużym wdrożeniu ERP można przygotować rozbudowany projekt: harmonogram, plan komunikacji, szkolenia, materiały, spotkania informacyjne, sponsorów, właścicieli procesów i strukturę zarządzania zmianą. Przy dziesiątkach małych zmian takie podejście przestaje być praktyczne.

Nie da się każdej korekty przygotowywać przez miesiąc. Nie da się dla każdej drobnej modyfikacji budować dużego projektu wdrożeniowego. Nie da się też ograniczyć wdrożenia do samego uruchomienia zmiany w systemie.

Potrzebne jest podejście lżejsze, szybsze i powtarzalne. Takie, które pozwala zespołowi SAP przed kolejną zmianą szybko zebrać najważniejsze składowe nadchodzącej małej zmiany.

Dwudniowy warsztat Zwinnego Zarządzania Zmianą

W opisanym przypadku zaproponowałem warsztat „Zwinnologia 2.0. Zwinne Zarządzanie Zmianą”. Pracowaliśmy przez 2 dni, po 8 godzin dziennie. W warsztacie uczestniczyło 18 osób, które na co dzień przygotowują, komunikują i wdrażają zmiany w SAP.

Punktem wyjścia były konkretne sytuacje z codziennej praktyki uczestników. Jeszcze przed warsztatem uczestnicy przygotowali Pre-Work, w którym opisali przykłady zmian wywołujących napięcia, komunikatów, które nie zadziałały, powtarzających się reakcji użytkowników oraz przypadków, w których zespół wdrażający był postrzegany jako źródło problemu, mimo że jego intencją było usprawnienie pracy.

Dzięki temu podczas warsztatu nie rozmawialiśmy o abstrakcyjnych modelach. Pracowaliśmy na prawdziwych wyzwaniach zespołu.

Celem warsztatu było wypracowanie sposobu działania przy dużej liczbie małych zmian w SAP. Chodziło o wypracowanie praktycznego schematu pracy, który można wykorzystać przy każdej następnej zmianie.

Właśnie w takich sytuacjach sprawdza się zwinne podejście do zarządzania zmianą. uzupełnia ono kompetencje techniczne zespołu SAP o umiejętność prowadzenia ludzi przez kolejne modyfikacje systemu.

Kanwa Zmiany, reakcje użytkowników i cykl ZZZ

Podczas warsztatu, który prowadziłem wraz z Markiem Naumiukiem, zapoznałem uczestników narzędziami Zwinnego Zarządzania Zmianą, w tym z Kanwą Zmiany, narzędzia pracy z reakcjami ludzi oraz cyklem ZZZ, obejmującym Wgląd, Opcje działań i Eksperymenty.

Wgląd oznacza zrozumienie sytuacji przed wdrożeniem zmiany. W przypadku SAP może to być analiza tego, których użytkowników dotknie modyfikacja, jakie czynności będą wykonywać inaczej, co może być dla nich niejasne, uciążliwe albo ryzykowne. Elementem Wglądu jest wypełnienie Kanwy Zmiany i odpowiedzenie na kluczowe pytania:

• CO ulega zmianie w systemi?
• DLACZEGO wprowadzana jest ta zmiana? Jakie korzyści odniosą użytkownicy z tej zmiany?

Opcje działań to poszukiwanie różnych sposobów wsparcia zmiany. Nie zawsze rozwiązaniem jest szkolenie. Czasem wystarczy krótki komunikat, instrukcja ekranowa, rozmowa z liderami użytkowników, test z małą grupą albo dyżur wsparcia w pierwszych dniach po uruchomieniu zmiany.

Eksperymenty oznaczają sprawdzanie w praktyce, czy przyjęte działanie rzeczywiście pomaga. Na przykład: czy użytkownicy po otrzymaniu krótkiego komunikatu rozumieją zmianę, czy liczba błędów spada, czy pytania do zespołu SAP dotyczą wyjątków, a nie podstawowego sposobu pracy.

Co uczestnicy wypracowali na warsztacie?

Po 16 godzinach pracy uczestnicy wypracowali strukturę działania przy kolejnych małych zmianach w SAP. Powstała także lista możliwych działań komunikacyjnych, wspierających i angażujących użytkowników, dopasowana do różnych grup odbiorców zmiany.

Co ważne, uczestnicy wypracowali też konkretne rozwiązania dla swoich małych zmian, które “przynieśli” na warsztat, i mogli wdrażać te rozwiązania dosłownie od jutra.

Podsumowanie

W zmianach dotyczących SAP i ERP nie chodzi wyłącznie o to, czy system został poprawnie zmodyfikowany. To oczywiście warunek konieczny. Z perspektywy organizacji równie ważne jest to, czy ludzie akceptują wprowadzane doskonalenie, czy rozumieją nowe zasady, czy wiedzą, czego się od nich oczekuje i czy nie mają poczucia, że system co chwilę wytrąca ich z codziennych obowiązków.

Jeśli zmian w ERP jest dużo, sama sprawność techniczna nie wystarczy. Potrzebne są kompetencje zarządzania zmianą: rozumienie reakcji użytkowników, zgromadzenia argumentów za zmianą, umiejętność komunikowania zmian, angażowania właściwych osób, dobierania wsparcia oraz szybkiego sprawdzania, czy dane działanie przynosi oczekiwany efekt.

Warsztat Zwinnego Zarządzania Zmianą, taki jak ten, który poprowadziliśmy wspólnie z Markiem Naumiukiem, pokazuje zespołom odpowiedzialnym za SAP/ERP, jak przeprowadzić użytkowników przez kolejne modyfikacje systemu bez budowania wielkiego projektu dla każdej małej zmiany.