System pojąć a ludzi zrozumieć - recepta na udane wdrożenie?

Czy głównym wyznacznikiem zakresu wdrożenia jest rozmiar systemu ERP?
Zakres funkcjonalny mySAP ERP
Rozwiązania branżowe zbudowane na mySAP Business Suite
Na co ukierunkować projekt wdrożeniowy?
Definicja głównych celów projektowych
Zarządzanie zmianą to konieczność
Zakres projektu należy dobrać do możliwości akceptacji zmian przez organizację

Czy głównym wyznacznikiem zakresu wdrożenia jest rozmiar systemu ERP?
Jak wynika z praktyki IMG, często spotykanym oczekiwaniem Klientów jest wdrożenie całego zakresu zakupionego przez nich systemu ERP. Zwłaszcza umowa typu stała cena (ang. fixed price) sprzyja takiemu podejściu - "zapłaciliśmy za cały system, więc oczekujemy, że wdrożone zostaną wszystkie funkcjonalności, które system posiada". W wypadku, kiedy zakres wdrożenia ograniczają posiadane zasoby, np. budżet, to projekt rozpisuje się na wiele etapów. Dla Klienta ważne jest to, aby było co wdrażać, czyli aby jak największy zakres systemu ERP pasował do firmy. Podejście takie broni się zwłaszcza w kontekście globalizacji, która generuje zapotrzebowanie na wsparcie biznesu technologią IT w jak największym stopniu. Skoro tak jest to przeanalizujmy oferowany zakres funkcjonalny systemu klasy ERP na przykładzie produktów firmy SAP AG, aby zbadać czy zakres ten może satysfakcjonować Klienta.

Zakres funkcjonalny mySAP ERP
Z punktu widzenia wsparcia dla poszczególnych komórek organizacyjnych, system mySAP ERP obejmuje swym zakresem m. in. następujące obszary firmy: rachunkowość, zarządzanie kadrami, zaopatrzenie, gospodarka magazynowa, zarządzanie sprzedażą, utrzymanie ruchu, itd. Opisując zakres funkcjonalny mySAP ERP poprzez grupy procesów biznesowych, które wspiera należy wymienić: zarządzanie przedsiębiorstwem, finansami, kadrą pracowniczą, tworzenie wartości dla Klienta (produkcja / usługi), utrzymanie ruchu, świadczenie usług wewnętrznych. Grupa procesów związanych z zarządzaniem przedsiębiorstwem na poziomie Zarządu firmy składa się z procesów głównych związanych z:

• monitorowaniem statusu firmy (m. in. Zrównoważona Karta Wyników, Kokpit Managera, Planowanie strategiczne, Zarządzanie wartością firmy czy konsolidacja)
• dostarczaniem analiz finansowych (raportowanie dla zarządu, planowanie finansowe, budżetowanie i prognozowanie, zarządzanie rentownością, kosztami produktów i usług, przepływami pieniężnymi (ang. Cash flow), kapitałem pracującym, rachunek kosztów pośrednich, analiza historii płatności na potrzeby optymalizacji warunków płatności - współczynnik DSO)
• analizą sprawności operacyjnej firmy (analiza zaopatrzenia, gospodarki zapasami, transportu związanego z wysyłkami, sprzedaży / usług, programów inwestycyjnych, kontroli jakości i nieruchomości)
• oceną efektywności kadry (ocena stopnia identyfikowania się działów / ludzi z celami strategicznymi, raporty porównawcze oceniające efektywność pracowników (ang. benchmarking)

Powyższa specyfikacja to "czubek góry lodowej" nie tylko dlatego, że jest niekompletna (to nie jest celem niniejszej publikacji), ale dlatego że mySAP ERP to tylko jeden z komponentów zbioru rozwiązań informatycznych mySAP Business Suite.

Rozwiązania branżowe zbudowane na mySAP Business Suite
mySAP ERP i mySAP Business Suite łączy ta sama technologia, na którą składa się: system transakcyjny, hurtownia danych, portal korporacyjny, workflow (obieg zadań i dokumentów) wzbogacone o pełną platformę integracyjną NetWeaver. MySAP Business Suite umożliwia integrację ludzi, informacji i procesów biznesowych przy pomocy następujących (przykładowych) rozwiązań informatycznych: zarządzanie relacjami z klientami i dostawcami, zarządzanie łańcuchem dostaw, zarządzanie cyklem życia produktu czy zaawansowanych analiz biznesowych (ang. Business Intelligence). W sumie na mySAP Business Suite składa się 11 takich rozwiązań. To, co wydaje się najważniejsze to fakt, że w oparciu o nie zbudowano ponad 20 map procesów dedykowanych dla poszczególnych branż (przemysł, energetyka, bankowość, instytucje publiczne, handel,...). Jest to dlatego interesujące, że w każdej firmie można zidentyfikować procesy standardowe (np. w obszarze rachunkowości, zaopatrzenia) niezależne od branży oraz te procesy, których specyfika decyduje o przynależności do branży.

Jak można się zorientować już po wstępnej analizie zakresu funkcjonalnego produktów firmy SAP AG - jest w czym wybierać i w związku z tym jest też co wdrażać. Oferowany zakres funkcjonalny, nawet po "przefiltrowaniu" go przez potrzeby Klienta, jest zwykle tak duży, iż jego ustalenie na poziomie szczegółowym wymaga działań projektowych rozpisanych w czasie.
Jak zatem zdefiniować zakres wdrożenia przed uruchomieniem projektu w sytuacji, kiedy oferta jest bogata i nie stanowi istotnego ograniczenia?

Na co ukierunkować projekt wdrożeniowy?
Potrzeba ukierunkowania wdrożenia istnieje zawsze, ponieważ zawsze istnieje problem racjonalnego wykorzystania posiadanych zasobów projektowych (czas, budżet, ludzie, wiedza). Najwięcej zasobów należy poświęcić na rozwiązanie tych problemów, które z punktu widzenia funkcjonowania biznesu są najważniejsze. Zajmowanie się wszystkim w takim samym stopniu nie jest racjonalne. Jest to temat wart omówienia, ponieważ ciągle zdarzają się projekty sterowane potrzebami użytkowników końcowych. Sytuacja taka rodzi powszechne przekonanie, że system ERP zakupiono ku wygodzie pracowników. A to z kolei jest przyczyną "pełzania" zakresu prac, ponieważ coraz to inny użytkownik zgłasza potrzeby ukierunkowane na automatyzację i łatwość obsługi. Główny kłopot polega wówczas na tym, że takie potrzeby są niespójne, że zwycięża interes osób, które posiadają największą siłę przebicia, a nie interes firmy. W efekcie Klient jest niezadowolony, ponieważ nie ma takiej możliwości, aby zadowolić dziesiątki (czy nawet setki) sprzecznych oczekiwań. Jak zatem ukierunkować prace projektowe na potrzeby reprezentowane przez Zarząd firmy, a więc na potrzeby wynikające z biznesu? Odpowiedź na to pytanie nie jest trudna, ponieważ można ją znaleźć w każdej profesjonalnej metodyce zarządzania projektem. Specyfika projektu polega na tym, że w praktyce to, co można na projekcie kontrolować to poziom realizacji celów zdefiniowanych w taki sposób, aby ich osiąganie było weryfikowalne. Zwłaszcza w wypadku projektów informatycznych zdefiniowanie produktu, czyli zakresu funkcjonalnego do wdrożenia, jest z różnych powodów niebywale trudne. Jak już wspomniano, ustalenie szczegółowego zakresu funkcjonalności do wdrożenia wymaga prac projektowych. Dlatego rozsądnym rozwiązaniem jest zdefiniowanie celów projektu, a nie szczegółowego zakresu. To z potrzeby realizacji celu powinno wynikać uzasadnienie wdrożenia konkretnej funkcjonalności, a nie z tego, że istnieje w systemie. To cel projektowy jednoczy wysiłki wszystkich członków zespołów, czyli ukierunkowuje projekt. Przy takim podejściu należy odpowiedzieć na pytanie jak zdefiniować cele projektu?

Definicja głównych celów projektowych
W przypadku podejścia ukierunkowanego na biznes dobrze jest zacząć analizę od zdefiniowanie rynku, czyli co trzeba spełnić, jakie oczekiwania Klientów, aby trwać na rynku w dłuższym okresie czasu. Chodzi o zdefiniowanie kilku tzw. krytycznych czynników sukcesu (ang. CSF). W kontekście tak określonych wymagań zewnętrznych w stosunku do firmy, należy zaprojektować kilka głównych procesów (wystarczy ich nazwa), które produkować będą coś, co z punktu widzenia rynku odebrane zostanie jako atrakcyjne (do tego potrzebna jest definicja CSF’ów). Następnie należy zaprojektować procesy pomocnicze, które generować będą rezultaty nieodzowne do funkcjonowania procesów głównych. Jako osobną kategorię należy wyodrębnić procesy zarządcze związane z planowaniem, budżetowaniem, prognozami i symulacjami. Przy czym nie chodzi o szczegóły. Chodzi o zdefiniowanie tego, co z biznesowego punktu widzenia w firmie jest najważniejsze, a więc tzw. Mapy Procesów, na której proces definiują jego nazwa i główne wyjścia (rezultaty) oraz powiązania pomiędzy nimi (wyjście procesu jest wejściem do innego procesu). Dla każdego procesu należy zdefiniować weryfikowalny cel i jego wskaźniki oceniające poziom realizacji tego celu. Posiadanie tak zdefiniowanej Mapy Procesów, uzgodnionej z Zarządem firmy to jeden ze sposobów ukierunkowania projektu na cel - maksymalne wsparcie systemem IT głównych procesów biznesowych. Alternatywą do takiego podejścia jest uzgodnienie z Zarządem firmy 30 - 50 wskaźników (danych liczbowych o firmie) pozwalających na wiarygodną ocenę statusu firmy. Taka lista wskaźników to również niezłe kryterium, w kontekście którego można uzasadniać dlaczego tą a nie inną funkcjonalność należy wdrożyć.

Czy posiadając system ERP, którego funkcjonalność dobrze pasuje do branży (jest co wdrażać) i dobrze zdefiniowane cele można powiedzieć, że posiadamy wszystko co należy, aby poprawnie zdefiniować zakres wdrożenia?

Powyższe pytanie celowo umieszczono na końcu niniejszego tekstu, ponieważ również w praktyce najdłużej dochodzono do wiedzy, że istnieje jeszcze jedno główne ograniczenie zakresu wdrożenia, a związanie ze zdolnością organizacji do akceptacji zmian. Również praktyka IMG potwierdza, że głównych ograniczeń zakresu wdrożenia nie należy upatrywać tylko w systemie czy zarządzaniu projektem, ale przede wszystkim w ludziach.


Zarządzanie zmianą to konieczność
Nikt z nas nie lubi zmian i w związku z tym w mniejszym lub większym stopniu, ale zawsze przeciwstawiamy się zmianom. Powody opierania się zmianom rzadko bywają logiczne, najczęściej bowiem dotyczą warstwy emocjonalnej wynikającej z braku komunikacji wewnątrz organizacji i jej kultury (ang. corporate culture). Choć bywa, że opory te mają swoje polityczne lub racjonalne uzasadnienie. W trakcie trwania projektu natężenie oporu przed zmianami czy nastrojów emocjonalnych ulega zmianom. Jeżeli proces ten nie jest kontrolowany to właśnie emocje i opór przed zmianą mogą być prawdziwą przyczyną kryzysu na projekcie, a nie jakość systemu, konsultantów czy samo zarządzanie projektem. Ważne w tym jest to, że zarówno w przypadku osób biorących udział w projekcie jak i osób dotkniętych efektami projektu, można zarządzać dynamiką zmian, nastrojów i emocji. Najbardziej podstawowa zasady zarządzania zmianą to m. in.: potrzeba zakomunikowania, iż zmiany są nieuniknione, potrzeba zbudowania planu komunikacji zorientowanego na grupy różnie nastawione do projektu (mogą na projekcie skorzystać, stracić, są neutralne), opracowanie systemu motywującego do osiągania jasno zdefiniowanych weryfikowalnych celów czy ciągłe wyciszanie obaw i monitorowanie nastrojów na projekcie.

Zakres projektu należy dobrać do możliwości akceptacji zmian przez organizację
To jest na dzisiaj najbardziej krytyczny z krytycznych czynników ograniczających zakres projektu. Systemy ERP są już dojrzałe i oferują coraz to więcej i więcej. Firmy wdrożeniowe zdobyły doświadczenie na licznych projektach. To, na co należy zwracać uwagę w dobie transformacji do e-Biznesu to fakt, że "Sukces = jakość rozwiązania * jego akceptacja przez ludzi, których zmiana dotyczy".

Ireneusz Kuterek
Consulting Manager
IMG Polska