Krytyczny obszar

Podczas planowania wdrożenia systemu ERP, pierwsze elementy, na które zwraca się zazwyczaj uwagę, to funkcjonalność systemu, terminy projektu, skład zespołu wdrożeniowego, infrastruktura techniczna, koszty licencji. Po określeniu zakresu i harmonogramu wdrożenia projektu, ale przed sfinalizowaniem składu zespołów i innych elementów planu, należy wziąć pod uwagę również obszar zmian organizacyjnych.

Klienci są w pierwszej kolejności zainteresowani możliwościami dostosowania systemu do ich struktury organizacyjnej, procesów biznesowych, specyfiki rynku itp.

Elastyczność i ogromne możliwości konfiguracji systemów SAP są oczywiście ich wielkim atutem i decydują o popularności wdrożeń. W odpowiedzi na to zapotrzebowanie, SAP oferuje również kilkanaście wersji branżowych systemu (IS – Industry Solutions), a w ostateczności każde – nawet najbardziej indywidualne wymaganie biznesowe – można spełnić przy pomocy programowania dodatkowych rozwiązań (w języku ABAP, Java lub innym).

Nie można jednak zapominać o drugiej stronie – równolegle z wdrożeniem systemu przedsiębiorstwo będzie przechodzić zmiany organizacyjne. Element ten występuje podczas każdego wdrożenia, chociaż często jest traktowany jako coś oczywistego i zdarza się, że nie poświęca się mu wiele uwagi w projekcie.

Tymczasem to właśnie zmiany organizacyjne mogą wzbudzić największy opór wśród pracowników, a nawet kadry zarządzającej. Z drugiej strony, zmiany wprowadzone z sukcesem owocują usprawnieniami w przebiegu procesów i wpływają na efektywność firmy.

Ze względu na te zagrożenia i szanse, zarządzanie zmianami należy uznać za jeden z kluczowych obszarów zarządzania projektami SAP.

Efekt lub powód

Z punktu widzenia zmian organizacyjnych projekty SAP można podzielić na dwie grupy:

  • projekty SAP, które wynikają ze zmian organizacyjnych,
  • projekty SAP wywołujące zmiany organizacyjne.

Do pierwszej grupy można zaliczyć projekty prowadzone niejako „przy okazji” budowy nowego zakładu, wprowadzania nowej grupy produktów, reorganizacji procesów biznesowych, podziałów lub fuzji spółek itp.

Ta grupa projektów jest w pewnym sensie „bezpieczniejsza”, ponieważ dla wszystkich jest od początku oczywiste, że zmiany organizacyjne są centralnym punktem, wokół którego organizuje się przedsięwzięcie. Często sama zmiana (pociągająca za sobą wdrożenie systemu) jest zarządzana jako oddzielny projekt, z dedykowanym kierownikiem projektu, harmonogramem, budżetem itp.

Typowe zmiany organizacyjne, które są powodem projektów SAP:

  • fuzje i przejęcia
  • konsolidacja grupy kapitałowej
  • wydzielenie jednostki/firmy/zakładu
  • budowa nowego zakładu, centrum dystrybucyjnego itd.
  • zamknięcie zakładu itd.
  • reorganizacja procesów (np. centralizacja działalności handlowej i marketingowej do jednej jednostki centralnej w ramach holdingu)
  • wejście na nowy rynek – geograficzny, nowa grupa produktów, nowy kanał dystrybucji itd.

Projekt wdrożenia SAP jest równoległy i dokładnie zsynchronizowany z projektem zmian, ale to ten drugi bierze na siebie planowanie, komunikowanie i wprowadzenie zmian organizacyjnych. Pozostałe projekty SAP – niezwiązane ze spektakularnymi zmianami organizacyjnymi, muszą same aktywnie zarządzać tym obszarem. W tej grupie mieści się duża część kompleksowych wdrożeń systemu SAP.

W obu przypadkach do zarządzania zmianami możemy zaklasyfikować wszelkie działania związane z:

  • modyfikacją przebiegu procesów biznesowych w przedsiębiorstwie,
  • modyfikacją struktury organizacyjnej (np. nowe jednostki organizacyjne lub łączenie jednostek) lub zakresu obowiązków/opisu stanowisk,
  • zmianami procedur postępowania/instrukcji użytkownika (wynikające z poprzednich punktów),
  • szkolenia (wynikające z poprzednich punktów).

Zarządzanie zmianami należałoby uznać za jeden z krytycznych obszarów zarządzania projektami SAP.

Zmiany konieczne

Systemy SAP zapewniają duży stopień integracji i automatyczny przepływ danych pomiędzy wieloma obszarami (zasada „dane są wprowadzane do systemu jeden raz”), ale wymaga to m.in. uporządkowania procedur zarządzania kartoteką klientów, dostawców czy indeksów materiałowych.

Dlatego nawet jeśli wdrożenie jest przeprowadzone w trybie „minimum zmian organizacyjnych / maksimum dostosowania do obecnej struktury”, pewne rozwiązania systemu ERP pociągają za sobą zmiany procedur organizacyjnych.

Na przykład przy wprowadzaniu nowego wyrobu gotowego, należy opracować go od strony gospodarki zapasami, ustalić dane sterujące produkcją, parametry związane z rachunkowością i kontrolingiem, i wreszcie informacje związane ze sprzedażą (kanał dystrybucji, ceny, rabaty itp.).

Jeśli zarządzanie danymi podstawowymi nie jest objęte sprawną procedurą (obejmującą kilka działów firmy), okaże się, że system „nie pozwoli” sprzedać nowego wyrobu, ponieważ np. nie zostały opracowane informacje pozwalające na automatyczne odnotowanie tej sprzedaży w module finansowym. Stąd wdrożenie SAP niejako wymusza przygotowanie i uaktywnienie takiej procedury w organizacji.

Zmiany pożądane

Druga grupa zmian to okazja dla dyrektorów działów, którzy czekali na wdrożenie rozwiązań potrzebnych, chociaż nie zawsze popularnych wśród pracowników. Wdrożenie SAP jest „pretekstem” do wprowadzenia „dobrych praktyk” w niektórych obszarach organizacji, gdzie wcześniejsze systemy informacyjne nie oferowały dostatecznego wsparcia.

Przykładem takiego rozwiązania jest uporządkowanie sfery zakupów. SAP ERP oferuje wieloetapowe procesy zaopatrzenia, obejmujące: zgłoszenie zapotrzebowania, zapytanie ofertowe, ofertę dostawcy, zamówienie, przyjęcie towaru / potwierdzenie wykonania usługi i wreszcie weryfikację faktury. Firma może wybrać, które z wymienionych kroków wykorzystać w procesie zaopatrzenia.

Formalne zgłoszenie zapotrzebowania (na przykład na sprzęt biurowy lub IT), pozwoli śledzić rzeczywiste potrzeby pracowników. Zatwierdzanie zgłoszeń może być przekazane do odpowiednich kierowników działów – informacja jest rejestrowana w systemie, zamiast przesyłania niepowiązanych e-maili lub papierowych formularzy. Zgłoszenia zatwierdzone mogą być przekształcane w zamówienia w systemie, co zmniejsza ryzyko błędów podczas tworzenia zamówień (np. dokładna specyfikacja komputera, wprowadzona przez dział IT, jest przekazywana w zamówieniu do dostawcy, przez dział zakupów).

Dzięki formalnej rejestracji zamówienia w systemie, faktura od dostawcy może być automatycznie dopasowana i zweryfikowana – ilościowo i wartościowo, pod kątem zgodności z zamówieniem. Możliwość przekroczenia wartości zamówienia lub omyłkowego dwukrotnego wprowadzenia tej samej faktury do systemu jest w praktyce całkowicie wyeliminowana.

Z partykularnego punktu widzenia, pewną uciążliwość dla pracowników stanowi tym przypadku konieczność formalnego wprowadzania zgłoszeń zapotrzebowań do systemu – zamiast zamówień „na telefon” lub formularzy, które nie sprawdzają poprawności i kompletności wpisanych danych. Jednak globalne korzyści dla przedsiębiorstwa – informacyjne (kto/co zamawia), organizacyjne (zatwierdzanie zamówień przez właściwe osoby), jak i czysto materialne (unikanie błędnych rozrachunków z dostawcami), są ewidentne.

Od identyfikacji do opisu

Korzystając z wyżej opisanego przykładu można zilustrować cykl zarządzania zmianą w organizacji.

Zmiana zostaje zidentyfikowana w fazie koncepcji wdrożenia systemu. Na tym etapie zespół projektowy omawia procesy biznesowe: stan obecny oraz stan docelowy – który jest sumą potrzeb biznesowych i możliwości oferowanych przez system ERP (np. decyzja „czy włączymy zgłoszenie zapotrzebowania do procesu zakupów?”).

Jest bardzo ważne, aby pod koniec fazy koncepcji – która koncentruje się na schemacie procesu i powiązanych parametrach konfiguracji systemu – przeprowadzić raz jeszcze analizę zmian organizacyjnych i opracować ich listę.

Do każdej zmiany należy przypisać osobę odpowiedzialną za jej wdrożenie w organizacji. Powinna być to osoba, której podlega funkcjonalnie dział, w którym następuje zmiana (często, choć nie zawsze, będzie to zarazem kierownik odpowiedniego zespołu wdrożeniowego SAP).

W fazie realizacji następuje konfiguracja – utworzenie w systemie SAP prototypu działającego procesu. W tym czasie od strony organizacyjnej konieczne jest zebranie dodatkowych informacji sterujących dla procesu (np. strategia zatwierdzania: od osoby zgłaszającej – do osoby akceptującej, alternatywne strategie dla zamówień o wysokich kwotach itp.).

W fazie realizacji należy też zaplanować zmiany procedur, zarządzeń lub innych dokumentów organizacyjnych, które regulują przebieg procesów w firmie.

Szczegółowym opisem wykonania tych zmian będą instrukcje użytkowników końcowych (w kolejnej fazie projektu), lecz zazwyczaj takie instrukcje wymagają umocowania w innym, bardziej formalnym dokumencie, aby wprowadzić zmianę do istniejących procesów (często utrwalanych przez kilka czy kilkanaście lat).

Do startu przystąp

W fazie przygotowania startu produkcyjnego systemu SAP powstają instrukcje użytkowników końcowych i przeprowadzane są szkolenia. Nie wystarczy na tym etapie tylko opisać nowego / docelowego procesu i zakomunikować go użytkownikom. Kierownik projektu powinien zadbać o to, aby osoby odpowiedzialne za zarządzanie zmianami dodały odpowiednie objaśnienia do instrukcji i szkoleń.

Komunikacja zmian organizacyjnych musi mieć odpowiednią rangę, po to aby ważne zmiany nie zostały przeoczone wśród informacji o nowym systemie oraz innych bieżących prac. Liderzy poszczególnych zespołów projektowych powinni uzgodnić treść komunikatów z menedżerami/dyrektorami lub nawet prezesem firmy, którzy następnie przekażą informacje do odpowiednich grup pracowników – w mailu, artykule w firmowym biuletynie lub przy okazji spotkania pracowników.

Te pierwsze komunikaty muszą objaśnić przede wszystkim cel wprowadzenia zmian. Menedżerowie łatwo wpadają w pułapkę przyjmowania założeń, że wszyscy mają taką samą orientację w celach wdrożenia nowego systemu i pełne zrozumienie celów projektu. Inni kierownicy mogą sądzić, że wystarczy przekazać „co robić”, bez objaśnienia „dlaczego” należy to zrobić. Oba te podejścia są niebezpieczne, obniżają skuteczność komunikacji i nasilają naturalny (choć nie zawsze racjonalny) opór ludzi przed zmianami.

Każdy pracownik potrzebuje poczucia sensu wykonywanej pracy. Dlatego nawet zmiany dotyczące prostych powtarzalnych czynności zostaną wdrożone szybciej i bardziej skutecznie, z mniejszą liczbą błędów, kiedy wyjaśnimy po co zostają one wprowadzone. Warto tutaj unikać ogólników takich jak „większa efektywność procesu” i zastąpić je konkretnymi korzyściami dla pracowników, np. „Dzięki wdrożeniu workflow zatwierdzania zakupów oczekujemy skrócenia czasu akceptacji kosztów z 5 do 3 dni”.

Instrukcje zmian organizacyjnych muszą być precyzyjne i konkretne, żeby nie pozostawiać dużego pola do interpretacji. Wymaga to pewnej dyscypliny od liderów zespołów projektowych, którzy takie opisy przygotowują. Jeśli sam autor zmiany nie ma jasnej wizji, w jaki sposób przełożyć ją na konkretne działania, to tym bardziej każdy pracownik będzie ustalał swoją (najwygodniejszą dla siebie) wersję. Jeśli napiszemy np. „Zakupy o wysokiej wartości należy dokonywać poprzez procedurę zgłoszeń zapotrzebowania w systemie ERP”, to dla jednej osoby 10 tys. PLN okaże się dużą wartością, a dla innej „drobiazgiem” w  porównaniu z rocznymi kosztami działu.

Jednym z elementów, który należy precyzyjnie zdefiniować jest ustalenie początku obowiązywania zmiany i ewentualnego okresu przejściowego. Kontynuując wcześniejszy przykład procedury zakupów, w pełnym zakresie może ona wejść w życie dopiero kilka tygodni po uruchomieniu systemu (np. „faktury od dostawców, do których nie wprowadzono zamówień – ponieważ stary system na to nie pozwalał – będą księgowane do końca pierwszego miesiąca po starcie produkcyjnym systemu SAP”).

I wreszcie na koniec należy zaplanować sposoby weryfikacji/utrwalania zmian, aby uniknąć sytuacji kiedy nowy proces jest po prostu ignorowany. Mogą to być wyrywkowe kontrole dokumentów wprowadzanych w systemie, okresowe raporty, rozmowy z kierownikami poszczególnych działów. W pierwszych tygodniach pracownicy mogą po prostu – bez złych intencji – mylić się lub zapominać o nowej procedurze. Jeśli zorientują się jednak, że „stary sposób” postępowania nadal działa (np. zakupy zatwierdzane „na telefon”, bez zgłoszenia zapotrzebowania, są realizowane przez dział administracji) i nikt się tym nie interesuje, to zmiana organizacyjna szybko umrze śmiercią naturalną.

Idzie nowe

Wdrożenie nowego systemu ERP jest zawsze dużym wyzwaniem dla użytkowników. Aktywne i świadome zarządzanie zmianami organizacyjnymi, które wiążą się z nowym rozwiązaniem, pozwala na bardziej płynne uruchomienie systemu.

Odpowiednie planowanie, szkolenia, instrukcje, podkreślanie zalet takich jak oszczędności czasu lub zmniejszenie liczby błędów w procesie – to ważne elementy, które uczynią wdrożenie wyzwaniem łatwiejszym do pokonania.

Na koniec warto przypomnieć banalną prawdę, że wdrożenie SAP nie jest celem samym w sobie, a jedynie środkiem do wprowadzenia w firmie zmian na lepsze.

Dzięki właściwemu zarządzaniu zmianami podczas wdrożenia, zwiększamy akceptację nowego modelu działania wśród pracowników. Akceptację niezbędną do tego, by ludzie umieli i chcieli korzystać z nowego narzędzia. Bez tego nie można by mówić o pełnym sukcesie projektu SAP, jakim jest usprawnienie działalności firmy.

„Zarządzanie zmianami czyli…”

Podczas rozmów przy okazji planowania i realizacji projektów dość często słyszymy ogólne określenie „zarządzanie zmianami”, które nie jest jednoznaczne. Może odnosić się do:

  • zarządzania zmianami organizacyjnymi,
  • zarządzania zmianami w projekcie.

Pierwszy wariant dotyczy dopasowania struktury organizacyjnej, procesów, procedur itp. do nowych możliwości, jakie wnosi system ERP do firmy – jest to przedmiotem niniejszego artykułu.
Drugi wariant dotyczy reagowania na zdarzenia związane bezpośrednio z projektem, takie jak zmiany zakresu wdrożenia (dodanie lub wyłączenie z zakresu określonych funkcji systemu), zmiany składu zespołów, przesunięcia w czasie terminów zadań itp. Szczególnie w dużych projektach, trwających przez wiele miesięcy lub nawet lat, takie zmiany są nieuchronne. Należy w systematyczny sposób je rejestrować, oceniać ich wpływ na projekt i zatwierdzać na poziomie kierowników projektu, a w przypadku bardzo dużych zmian – komitetu sterującego, aby projekt nie pogrążył się w chaosie.