Wybór, porozumienie, realizacja – trzy aspekty wdrożenia zintegrowanego systemu ERP

Wybór, zakup licencji i wdrożenie zintegrowanego systemu klasy ERP to zawsze poważne wyzwanie dla przedsiębiorstwa i znaczna inwestycja. W organizacji średniej wielkości nakłady przekraczają zwykle milion złotych, a z samą implementacją wiąże się duże nadzieje na usprawnienie procesów gospodarczych i zarządzania firmą. Ze swej natury zintegrowany system ERP obsługuje prawie wszystkie działy przedsiębiorstwa, a przedstawiciele tych działów muszą zostać zaangażowani w wybór  i wdrożenie systemu. Takie interdyscyplinarne przedsięwzięcie musi zatem rodzić naturalne napięcia i konflikty interesów.

Przyjrzyjmy się zatem bliżej projektowi implementacji systemu ERP w trzech wymiarach – wyboru systemu, umowy wdrożeniowej oraz samego procesu implementacji.

Zanim do tego przejdziemy zastanówmy się czym w swej istocie jest projekt wdrożenia zintegrowanego systemu ERP, co jest najistotniejsze w takim przedsięwzięciu. Czy jest  to wybór producenta oprogramowania i wybór samego systemu, czy poszukiwanie odpowiedniego partnera wdrożeniowego i ustalenie zasad współpracy z nim, a może kwestia instalacji i konfiguracji systemu? Te wszystkie elementy są bez wątpienia istotne i ważne. W moim przekonaniu jednak wdrożenie systemu ERP to przede wszystkim edukacja i zarządzanie zmianami. Choć to clou każdego projektu wdrożeniowego, te dwa aspekty zbyt częstą umykają i są pomijane z fatalnymi skutkami.

Zadajmy jeszcze jedno fundamentalne pytanie – jaki jest cel wdrożenia?  Czy tym celem jest dostarczenie określonych funkcjonalności poszczególnym departamentom organizacji, czy też optymalizacja procesów biznesowych, a może integracja informacji zarządczej? Ciekawym ujęciem tego problemu są kwadranty dojrzałości informacyjnej przedsiębiorstwa.

Te kwadranty przedstawiają rosnącą umiejętność przedsiębiorstwa do utrzymywania, zarządzania informacją oraz budowania na jej podstawie realnej wartości biznesowej.

Pierwszy kwadrant to obszar porządkowania danych i utrzymywania prostej spójności informacji. Tutaj firma potrafi na bieżąco obsługiwać zaległe dokumenty, dane są wprowadzane do systemu na bieżąco lub z niewielkim tylko opóźnieniem, a użytkownicy wiedzą za jakie dane są odpowiedzialni i tę odpowiedzialność podejmują.

W drugim kwadrancie firma potrafi już efektywnie kategoryzować i priorytetyzować informacje, dane są precyzyjne, zgodne z rzeczywistością i poprawnie opisują realne procesy biznesowe, np. poziomy zapasów w systemie odpowiadają rzeczywistym stanom magazynowym, czasy dostawy są zgodne z warunkami ustalonymi z dostawcami. Użytkownicy zaczynają zarządzać łańcuchem dostaw poprzez wyjątki i mają, być może jeszcze nieco ograniczone, zaufanie do działania systemu.

Trzeci kwadrant zajmują organizacje, które na bazie spójnych, realnych danych potrafią automatyzować swoje procesy, np. w zakresie zaopatrzenia i komunikacji z dostawcami, a te procesy mierzyć przy pomocy wskaźników efektywności (ang. Key Performance Indicators, KPI).

Przedsiębiorstwa, które wykorzystują system ERP i dane zawarte w systemie, do tworzenia realnej wartości biznesowej, potrafią precyzyjnie wskazać w jaki sposób wykorzystanie systemu tę wartość buduje, a także ten przyrost stale mierzą, zajmują ekskluzywny czwarty kwadrant.

W moim przekonaniu nadrzędnym celem wdrożenia systemu ERP jest wzrost dojrzałości informacyjnej przedsiębiorstwa. Nauczenie firmy, we wszystkich obszarach objętych wdrożeniem, każdego użytkownika systemu w jego zakresie odpowiedzialności, jak budować wartość przedsiębiorstwa korzystając z systemu i z rzetelnych informacji w nim zawartych. Być może ktoś uzna, że to nazbyt idealistyczny czy dalekosiężny cel, jednak jestem pewien, że bez niego sukcesem wdrożenia stanie umożliwienie trywialnego księgowania dokumentów, a integracją będzie proste połączenie ruchów magazynowych z dekretacją na kontach. Bez tego celu energia ludzi i budżet projektu będzie marnotrawiony na budowanie indywidualnych rozszerzeń i zaspokajaniu wąskich, partykularnych potrzeb.

Wybór, czyli w gąszczu rozwiązań

Pierwszy etap każdej inwestycji w system ERP to wybór producenta oprogramowania i jego produktu. Na rynku funkcjonuje wielu producentów programowania, jest Epicor, Microsoft, Oracle czy SAP. Każdy z nich oferuje wiele produktów. Przykładowo cennik firmy SAP liczy sobie ponad tysiąc pozycji. Jak zatem zorientować się w tym gąszczu i dobrze wybrać? Jest to niewątpliwie trudne zadanie. Trzeba tutaj przebić się przez słowotok sprzedawców, zrozumieć możliwości oferowanego systemu, ale przede wszystkim wiedzieć czego się od systemu oczekuje. To ostatnie jest moim zdaniem najtrudniejsze. Naturalnie zawsze chcemy, żeby system robił wszystko, zintegrował i zoptymalizował firmę, generalnie poprowadził ku nowemu, lepszemu jutru. Jednak konkretna odpowiedź na pytanie co ma robić jest niezwykle trudna, bo wymaga procesowego, międzydepartamentalnego podejścia. Skoro nie potrafimy zrobić tego samemu, można zawsze zlecić wybór systemu wyspecjalizowanej firmie konsultingowej. Taka usługa polega zwykle na zbudowaniu listy wymagań funkcjonalnych wyartykułowanych przez wszystkie zainteresowane działy przedsiębiorstwa. Wynikiem jest arkusz z nierzadko ponad dwoma tysiącami wymagań. Oferent systemu może tylko odpowiedzieć czy jego system spełnia dane wymagania czy nie, ewentualnie czy spełnienie wymagania jest możliwe przez rozszerzenie standardowej funkcjonalności systemu.  Na pierwszy rzut oka takie podejście umożliwia obiektywny wybór. Uczestniczyłem jednak w wielu procesach wyboru systemu i wiem, że ta metoda jest przeciwskuteczna. Przede wszystkim wymagania są często formułowane bardzo ogólnikowo i rodzą uzasadnione wątpliwości oferenta.

Spójrzmy na rzeczywiste, realne przykłady:

„Możliwość przywrócenia domyślnego wyglądu formatek” – jakich formatek, kto ma mieć taką możliwość, jakiego nakładu czasu, kwalifikacji wymaga takie przywrócenie?

„Kartoteka materiału zawiera: miejsce na dane logistyczne np. waga, wymiary, sposób pakowania, warianty opakowania” – każdy system zawiera takie miejsce, przecież rozumiejąc literalnie to wymaganie te informacje można wpisać po prostu w opis materiału, który nie ma żadnego wpływu na procesy logistyczne.

„Możliwość definiowania “wąskich gardeł” w procesach produkcji i optymalizacja ich wykorzystania” – jak należy rozumieć proces optymalizacji wykorzystania?

Naturalnie oferenci mają możliwość zadania pytań uszczegółowiających. Jeśli jednak pytania są zbyt dociekliwe odpowiedzi są zwykle wymijające, np. „zostanie to uszczegółowione na etapie wdrożenia” lub „liczymy na ekspercką wiedzę oferenta”.

Moim ulubionym wymaganiem jest wymóg optymalizacji, regularnie podnoszony zwłaszcza w zakresie procesów logistycznych czy planowania produkcji. Jestem przekonany, że za takim wymogiem stoi następujące rozumowanie: „z wielu przyczyn nie potrafimy sami zintegrować naszych procesów, nie potrafimy sami zarządzić naszym planem produkcyjnym, zatem niech system za nas to zrobi, tak żeby było dobrze, czyli optymalnie”. Podczas formułowania tego wymagania nie określa się w jaki sposób optymalizacja miałaby przebiegać, wg jakiej funkcji celu, z zachowaniem jakich warunków brzegowych. Także nikt nie zwraca uwagi, że każdy, najlepszy nawet algorytm optymalizacyjny działa na dostarczonych mu danych. Jeśli te dane są nierzetelne, efekt optymalizacji może być daleki od oczekiwanego. Również mówiąc o optymalizacji rzadko kto zadaje sobie pytanie o sposób oceny wyniku, a przecież aby móc go ocenić, trzeba go rozumieć. Jestem przekonany, że zarówno w życiu codziennym, jak i w działalności gospodarczej ludzie nie potrzebują rozwiązań optymalnych. Oczekują natomiast rozwiązań wystarczająco dobrych, które łatwo ocenić i zrozumieć. Oczekują raczej wsparcia przy podejmowaniu decyzji, a nie decyzji wypracowanych przez najlepszy nawet, ale niezrozumiały algorytm optymalizacyjny. Ludzie zajmują dominującą pozycję na Ziemi, nie dlatego że potrafią optymalizować, ale dlatego że potrafią bardzo szybko rozpoznawać wzorce i często intuicyjnie podejmować decyzje przy niepełnych informacjach. Każdy z nas, kiedy ma do załatwienia nawet znaczną liczbę spraw w różnych punktach miasta, wie jak do nich dotrzeć i w jakiej kolejności. Po prostu to wiemy, bez optymalnego rozwiązywania problemu komiwojażera. Przekładając powyższy przykład na rzeczywistość gospodarczą, widać tutaj pełną analogię z wyznaczaniem optymalnej ścieżki pobrań w magazynie. Podobnie jest z szeregowaniem operacji produkcyjnych czy planowaniem pakowania.

W liście wymagań funkcjonalnych widzę następujące problemy. Po pierwsze wymagania te nie układają się i nie integrują w spójny proces gospodarczy. Można by sobie wyobrazić system, który literalnie spełni każde wymaganie funkcjonalne, ale nie będzie działał. W kartotekach będzie można zapisać wszystkie wymagane informacje, ale nie będą one miały wpływu na proces. Będzie można definiować dowolne raporty, ale ich definicja będzie wymagała zatrudnienia wysokospecjalizowanego programisty, itd. Czy faktycznie takiego systemu oczekuje klient?

Po drugie, lista wymagań funkcjonalnych staje się załącznikiem do umowy wdrożeniowej, zatem jest dokumentem wiążącym prawnie wykonawcę i zamawiającego. Wyjaśnianie niejasności i uogólnień takiego załącznika zajmie wiele czasu i będzie sporo kosztować kiedy dojdzie do sporu sądowego.

Po trzecie wreszcie, taka lista buduje u zamawiającego stan fałszywego spokoju – „przecież wszystko zdefiniowała dla nas renomowana firma”. W istocie większość wymagań powtarza się w delikatnie tylko zmienionej formie w kolejnych procesach wyboru systemu, kolejnych firmach. Jestem przekonany, że gdyby zmierzyć odległość Levenshteina wymagań przygotowanych dla poszczególnych zamawiających wyniosłaby ona nie więcej niż 30-40% długości tekstu wymagań.

Porozumienie, czyli umowa

W doskonałym artykule opublikowanym 9 kwietnia 2014 roku na łamach „Computerworld”, specjalista prawa zobowiązań oraz prawa autorskiego w zakresie umów i projektów informatycznych i telekomunikacyjnych, pan Marcin Maruta wskazuje na typowe błędy umów wdrożeniowych. Podstawowym błędem wskazanym w tym artykule jest brak precyzyjnego opisu świadczenia. Znajdziemy tam również stwierdzenie, że większość umów wdrożeniowych to umowy o dzieło.

Jeśli połączymy świadczenie zdefiniowane jako długa lista ogólnikowych wymagań funkcjonalnych, z potraktowaniem wdrożenia jako dzieło, w efekcie otrzymamy projekt o charakterze czysto technicznym, stricte IT, którego celem jest literalna implementacja wymagań. Jest to gotowa recepta na niepowodzenie projektu. Naturalnie wymagania są uszczegóławiane w trakcie wdrożenia, w fazie koncepcji (ang. blueprinting). Koncepcja często zmienia wymagania, definiuje nowe, unieważnia te zdefiniowane na etapie wyboru systemu, a sama parametryzacja systemu jest wykonywana zgodnie z koncepcją ze obopólną zgodą stron. Tyle, że lista wymagań funkcjonalnych jest załącznikiem do umowy wdrożeniowej, dokumentem prawnie wiążącym strony, a koncepcja jest tylko wewnętrznym dokumentem projektowym. Nie widziałem jeszcze przypadku, aby po zatwierdzeniu i odebraniu koncepcji, strony aneksowały umowę. Proszę porównać powyższą praktykę do przykładu z przytoczonego artykułu:  „Przykład prawdziwy i szkoleniowy: kierownicy projektu zmienili harmonogram szczegółowy, będący załącznikiem do analizy, która była załącznikiem do umowy. Pełna zgoda stron. Tylko że sąd stwierdził, że po pierwsze nie mieli w umowie do tego pełnomocnictw, a po drugie nie dochowali formy pisemnej. I uznał roszczenie zamawiającego o zapłatę kar umownych, liczonych według harmonogramu z umowy, a nie realizowanego rzeczywiście. W sumie kilkaset tysięcy złotych odszkodowania, które pojawiło się tylko dlatego, że wykonawca nie przypilnował zgodności umowy z rzeczywistością.

Pytanie zatem skąd powszechność takich praktyk, dlaczego o wymaganiach funkcjonalnych zapomina się od razu po starcie projektu, a przypomina o nich tylko w razie sporu? Moim zdaniem wynika to z faktu, że wymagania funkcjonalne przygotowane przez zewnętrzną firmę nie są poważnie traktowane przez zamawiającego, po prostu nikt w nie wierzy. Po co zatem je przygotowywać?

Napisałem wcześniej, że wdrożenie systemu to przede wszystkim edukacja i zarządzanie zmianą. Intuicyjnie przynajmniej wszyscy wiemy czym jest edukacja. Trudniej natomiast zdefiniować zarządzanie zmianą. Wg Wikipedii: zarządzanie zmianą jest procesem. Nie przebiega według gotowych schematów i prowadzi do rezultatów, które nie są do końca określone, ponieważ zachodzą w zespole ludzkim, np. jednym z czynników zaburzającym przebieg procesu jest opór pracowników wobec zmiany. Podstawowym warunkiem zmiany jest dobra diagnoza. Dodałbym do tego jeszcze wymóg zaangażowania obu stron i choć minimalną chęć zmiany po stronie zamawiającego. Efekt projektu wdrożeniowego bez takiego zaangażowania doskonale ilustruje rysunek Randy’ego Glasbergena, pierwszy wynik wyszukiwania w Google dla hasła: „change management glasbergen” i cytat z tego rysunku: „I want you to find a bold and innovative way to do everything exactly the same way it’s been done for 25 years”:

Pytanie czy tego rodzaju proces, proces edukacji i wprowadzania zmian organizacyjnych można nazwać dziełem i realizować w ramach umowy o dzieło? Jeśli nie, to w jakie ramy prawne należałoby ująć taki projekt?

Realizacja, czyli wdrożenie

Projekty wdrożeniowe są zwykle realizowane w fazach, pomijam tutaj aspekty stricte techniczne jak dostarczenie sprzętu czy instalacja oprogramowania:

  1. Opracowanie koncepcji
  2. Konfiguracja systemu
  3. Implementacja rozszerzeń
  4. Testy integracyjne
  5. Szkolenia użytkowników
  6. Zmiany organizacyjne
  7. Wsparcie pracy produktywnej systemu

Każda faza zaczyna się po formalnym zaakceptowaniu i odebraniu fazy poprzedniej. Takie podejście wynika wprost z wyboru systemu opartego o listę wymagań funkcjonalnych i potraktowanie implementacji jako dzieła w umowie wdrożeniowej. W istocie, nie jest tutaj wdrażany system dostarczony przez producenta oprogramowania, ale są wprost implementowane wymagania funkcjonalne na bazie tylko czy w środowisku gotowego systemu ERP. Nacisk jest tutaj położony na, często siłowe, dopasowanie systemu i jego procesów do zdefiniowanych wcześniej wymagań, zamiast na wykorzystanie „best practices” systemu, edukację użytkowników i zmiany organizacyjne.

Z punktu widzenia metodyki prowadzenia projektów jest to typowy model kaskadowy (ang. waterfall model). Pułapki i niedoskonałości tego modelu zostały już dokładnie przeanalizowane w literaturze fachowej i obśmiane w rysunkach satyrycznych, z których najbardziej znany to ilustracja budowy huśtawki – proszę sprawdzić wyniki wyszukiwania obrazów w Google dla hasła „waterfall model swing cartoon”:

Ten model ma jeszcze jedną istotną wadę. Jest bardzo nieefektywny kosztowo. Poniższy diagram pokazuje poglądowo wykorzystanie budżetu w poszczególnych fazach projektu:

Proszę zwrócić uwagę na fazę testów. Ze względu na liczbę niestandardowych rozszerzeń i dopasowań systemu do wymagań funkcjonalnych, należałoby wykonać znaczną liczbę testów integracyjnych. Zwykle w tej fazie projekt jest już istotnie spóźniony i pojawia się silna presja czasu. Poniechanie dokładnych testów, skutkuje wysokimi kosztami wsparcia i rozwiązywania problemów w systemie działającym już produktywnie. Te koszty zamawiający będzie ponosił już praktycznie stale przez długi okres użytkowania systemu. Rzadko kiedy są one jednak wliczane do kosztów projektu wdrożeniowego, choć stanowią składnik całkowitych kosztów korzystania z systemu (ang. TCO –Total Cost of Ownership).

Alternatywnym podejściem jest metodyka Value Within, która skupia się raczej na edukacji i implementacji zmian organizacyjnych, na budowaniu wartości i dojrzałości informacyjnej organizacji poprzez integrację procesów gospodarczych w ramach standardowych funkcjonalności systemu ERP.

Komentarze o “Wybór, porozumienie, realizacja – trzy aspekty wdrożenia zintegrowanego systemu ERP

  1. Świetnie ujmujący sprawę diagram. Cool ! Co do samej realizacji polecam ASAP metodologie. Osobiście uważam że powinno być obowiązkowe dla osób kierujących projektem. Prawda jest jednak często taka że zatrudnia się przebojowe dzieciaki bez wiedzy które podejmują wyzwania spod znaku mission impossible. Wynik to mega stres dla teamu ( poza studentami teorii chaosu ) a i często dodatkowe koszty $$$

    Pozdrawiam, adam

    1. Nie mam nic przeciwko metodyce ASAP. Uważam tylko, że jakakolwiek metodyka by nie była powinna się skupiać na wdrożeniu systemu tj. wykorzystaniu jego standardowej funkcjonalności do zarządzania biznesem, a nie na pisaniu Z-łat i oraniu standardowej konfiguracji. Nie po to klient płaci za gotowy system, aby go pisać praktycznie od zera. Moim zdaniem dwa najistotniejsze aspekty każdego wdrożenia SAP czy projektu optymalizacyjnego ValueWithin to edukacja i zarządzanie zmianą. Skuteczne wykorzystania zintegrowanego systemu wymaga zmiany i dużo nauki w całej organizacji.

  2. Bardzo ciekawy artykuł. Ja prowadzę firmę produkcyjną – produkujemy meble. Korzystam z Comarch ERP XL i jestem bardzo zadowolony. Skorzystałem z usług poznańskiej firmy Graphcom, bo dużo dobrego o niej słyszałem i się nie zawiodłem. Także jeśli ktoś się zastanawia nad systemem i wdrożeniem u siebie to polecam produkty Comarch i Graphcom.
    Przy okazji jeśli ktoś chciałby skorzystać z ich usług to polecam też skontaktować się z Supra Serwis, która współpracuje z Graphcom, dzięki pomocy w napisaniu wniosku dostałem dofinansowanie na system z UE.

Zostaw komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.