Jak skonsumować ERP

ERP – zgubiona integracja

Dominik Tylczyński

System ERP, traktowany jako narzędzie informatyczne, nie jest magiczną różdżką, która rozwiąże wszystkie problemy każdego działu w firmie. Wystarczy, aby system ERP pozwalał na optymalizację, integrację i automatyzację kluczowych procesów organizacji. Wtedy przedsiębiorstwo osiągnie oczekiwane korzyści z wdrożenia, a sama implementacja będzie sukcesem. Przyjrzyjmy się na początek trzem przykładom firm produkcyjnych wykorzystujących system SAP ERP w różnych branżach.

Branża produkcji projektowej
Charakterystyczną cechą tej branży jest każdorazowe dostosowywanie produktu do szczegółowych wymagań klienta. Firma posiada w swojej ofercie określone produkty. Jednak nie są one produkowane masowo. Każdy kontrakt z klientem staje się więc projektem, w ramach którego definiowane są precyzyjnie, oczekiwane przez klienta, cechy produktu. Standardowy wyrób jest dopasowywany do powyższych cech, często nawet gruntownie przeprojektowywany: modyfikowana jest specyfikacja materiałowa produktu, powstają nowe komponenty, itd. Taki sposób obsługi wymagań klienta, dopasowania produktu i realizacji produkcji znajdziemy np. w branży budowy jachtów, lotniczej czy w samochodowej.

Firma o takim charakterze używa zintegrowanego systemu SAP ERP od kilku lat. Dużym wysiłkiem finansowym i organizacyjnym uruchomiono w niej wszystkie kluczowe moduły systemu. Powstał dosyć skomplikowany model planowania i rozliczania produkcji, choć w istocie cały proces odbywa się w kilku gniazdach produkcyjnych. Przedsiębiorstwo nie potrafi jednak, na podstawie danych z systemu, określić poziomu zaawansowania produkcji w poszczególnych projektach, nie mówiąc już o zautomatyzowaniu planowania produkcji i integracji z pozostałymi funkcjami logistycznymi jak zaopatrzenie czy magazynowanie. Produkcja nadal jest planowana poza systemem, w Excelu, jej plan lepiej lub gorzej jest importowany do systemu ERP, a realizacja produkcji przeważnie jest niepotwierdzana w systemie lub jest, ale niezgodnie z rzeczywistością.

Dlaczego tak się dzieje? Dział produkcji nie uważa danych w systemie SAP ERP za swoje dane, a samego systemu za „moje” narzędzie. Po stronie biznesu nie ma poczucia odpowiedzialności za te dane, nawet na najprostszym poziomie: choćby potwierdzania operacji produkcyjnych. Zintegrowany system ERP jest traktowany jak droga zabawka działu IT, a nie narzędzie wspomagające i automatyzujące zarządzanie firmą. Można powiedzieć, że system został tutaj skonfigurowany i uruchomiony, ale nie wdrożony, bo wdrożenie jest wtedy kiedy zarządzanie w i przy pomocy systemu staje się częścią kultury organizacyjnej.

Branża FMCG
W przeciwieństwie do branży projektowej w branży dóbr konsumpcyjnych mamy do czynienia ze standardowymi wyrobami. Owszem, ich cykl życia może być krótki, podyktowany zmieniającą się modą, gustami klientów czy posunięciami konkurencji. Jednak same produkty nie zmieniają się wraz z kolejnymi zamówieniami i produkowane są anonimowo na magazyn. Głównym odbiorcą są duże sieci handlowe, a jednym z podstawowych czynników konkurencyjnych jest cena. Wyzwaniem dla branży jest zatem efektywne zarządzanie marżami, a co za tym idzie kosztami produkcji.

Firma o takim charakterze używa systemu SAP ERP od dłuższego czasu. Jednak nigdy nie został wdrożony moduł planowania produkcji, controllingu produkcji i analizy rentowności. Zużycie komponentów do produkcji jest rozliczane prostym wydaniem w zbiorcze miejsce powstawania kosztów, a kalkulacja standardowego kosztu wytworzenia jest robiona całkowicie poza systemem zintegrowanym, w Excelu. W konsekwencji koszty produkcji są rejestrowane na bardzo ogólnym poziomie, nie można przeanalizować odchyleń między planowanym a rzeczywistym kosztem produkcji, co prowadzi do braku informacji o rentowności poszczególnych produktów. Uzyskanie tych danych, niezbędnych przecież dla bieżącego zarządzania firmą, wymaga prowadzenia uciążliwych analiz w rozbudowanych arkuszach kalkulacyjnych, a informacje te nie są dostępne na bieżąco. Wątpliwa jest przy tym ich rzetelność i dokładność. Tutaj przyczynę widzę w braku zrozumienia potrzeb firmy przez konsultantów wdrożeniowych. To oni powinni zaproponować właściwe narzędzie i moduły implementacji, po zidentyfikowaniu faktycznych potrzeb swojego klienta. Rolę konsultanta widzę nie jako osoby realizującej wprost oczekiwania użytkowników, piszącej dodatkowe raporty czy przerabiającej standardowe transakcje. W moim przekonaniu jest to ktoś, kto potrafi dotrzeć do źródła problemu, zidentyfikować pierwotną potrzebę; zaproponować standardową funkcjonalność systemu, która tę potrzebę zaspokaja; skonfigurować system i, co najważniejsze, nauczyć użytkowników jak go używać.

Branża motoryzacyjna
W branży motoryzacyjnej, na poziomie produkcji komponentów do samochodów, wyroby są przeważnie standardowe. Zwracam tutaj szczególną uwagę na poziom, gdyż produkcja samych pojazdów jest już wysoce spersonalizowana i praktycznie każdy z nich jest indywidualnie konfigurowany zgodnie z oczekiwaniami klienta. Przedsiębiorstwo w tej branży korzysta z systemu SAP ERP w sposób wysoce zintegrowany. Prognozy popytu są wprowadzane do systemu, planowanie MRP na wszystkich poziomach produkcji odbywa się automatycznie przy pomocy standardowych funkcjonalności, również średnioterminowe planowanie produkcji wykorzystuje systemowe narzędzia. Dodatkowo, intensywnie wykorzystuje się elektroniczną komunikację z klientami oraz dostawcami surowców. A jednak na tym bardzo pozytywnym obrazie jest istotna rysa. Okazuje się, że bieżące sterowanie produkcją czy planowanie krótkoterminowe odbywa się w arkuszach kalkulacyjnych, całkowicie poza systemem. Dlaczego tak się dzieje pomimo bardzo wysokiej wiedzy o systemie SAP ERP i jego świadomego używania?

Mianowicie wszystkie produkty firmy, w danych podstawowych materiału, mają ustawiony horyzont zamrożenia planu produkcji na ponad 30 dni. To jedno pole wyłącza skutecznie funkcjonalność tablicy planowania produkcji w krótkim okresie i uniemożliwia wykorzystanie jej do bieżącego sterowania produkcją. Co ciekawe nikt nie potrafi udzielić odpowiedzi na pytanie o biznesowy sens tak długiego horyzontu zamrożenia planu produkcji. Po prostu, to ustawienie zawsze było i nikt go nie kwestionował. W tym przypadku zabrakło po prostu gruntownego przeszkolenia użytkowników i wytłumaczenia im jaki skutek mają poszczególne ustawienia danych w systemie. Takie przykłady można mnożyć. Istotne jest jednak pytanie o przyczyny, dla których firmy bardzo często w mikrym stopniu wykorzystują systemy zintegrowane ERP. Moim zdaniem pierwsza przyczyna tkwi już w procedurze wyboru systemu.

Wybór, czyli w gąszczu rozwiązań
Na rynku funkcjonuje wielu producentów oprogramowania: 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 rozwiązań i wybrać te właściwe? Należy przebić się przez słowotok sprzedawców, zrozumieć możliwości oferowanego systemu, ale przede wszystkim, co jest najtrudniejsze, wiedzieć czego się od systemu oczekuje. Skoro nie potrafimy tego zrobić, możemy 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. Jej efektem jest arkusz nierzadko z ponad dwoma tysiącami wymagań. Oferent może tylko odpowiedzieć czy jego system je spełnia czy nie, ewentualnie czy jest to 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 tego typu procesach 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:

1. „Możliwość przywrócenia domyślnego wyglądu formatek” – jakich formatek, kto ma mieć taką możliwość, jakiego nakładu czasu czy kwalifikacji wymaga takie przywrócenie?
2. „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 dosłownie to wymaganie powyższe informacje można wpisać po prostu w opis materiału, który nie ma żadnego wpływu na procesy logistyczne.

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. 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, w 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 proc. długości tekstu.

Metodyka waterfall
Projekty wdrożeniowe są zwykle realizowane w następujących 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.

Te fazy są przedstawiane poglądowo jako mapa drogowa projektu. Przykładowo firma SAP definiuje taką mapę następująco:

 

 

 

 

 

 

Rys. 1 – Fazy wdrożenia wg metodyki ASAP (źródło: SAP)

Każda faza zaczyna się po formalnym zaakceptowaniu i odebraniu fazy poprzedniej. Teoretycznie takie podejście jest jak najbardziej poprawne. Projekt jest ściśle kontrolowany w ramach faz. Każda z nich ma jasno zdefiniowane produkty, które są wymagane do rozpoczęcia kolejnej fazy. W każdej z nich są również zdefiniowane czynności i zadania oraz odpowiedzialni za ich realizację. Wszystko to prawda, ale tylko teoretycznie stanowi to gwarant udanego wdrożenia. 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. W wielkim skrócie jego wady wynikają z odmiennej perspektywy i optyki wykonawcy oraz zamawiającego czy klienta. W fazie Blueprint/Koncepcji wdrożenia wykonawca wspólnie z zamawiającym definiują docelowy kształt systemu i opisują go w obszernym dokumencie zwanym „koncepcją wdrożenia” lub „business blueprint”. Jednak zrozumienie tego dokumentu przez wykonawcę oraz zamawiającego oraz wyobrażenie, jak będzie działał zintegrowany system, są zgoła odmienne. To jest całkowicie naturalne i nie stanowiłoby problemu, gdyby te rozbieżności były na bieżąco weryfikowane i eliminowane. Jednak nie są – po fazie opracowania koncepcji przychodzi faza realizacji, po której zamawiający jest konfrontowany z niemal gotowym systemem i przeżywa bolesne rozczarowanie.

Dodatkowo konsultanci implementujący system skupiają się na obsłudze poszczególnych transakcji, na wdrożeniu określonych funkcjonalności systemu, gubiąc przy tym integrację i automatyzację procesów, planowanie i monitorowanie jakości obsługi procesów biznesowych przedsiębiorstwa. W efekcie dostarczony system potrafi rejestrować transakcje, ale nie potrafi wspomagać zarządzania firmą. W tym konkretnym kontekście, pisząc „system”, mam na myśli zarówno oprogramowanie, jak i dane w nim zawarte oraz przede wszystkim jego użytkowników, ich świadomość i wiedzę.
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 implementowane są jedynie wymagania funkcjonalne na bazie gotowego systemu ERP. Nacisk położony jest 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.
Ten model ma jeszcze jedną istotną wadę. Jest bardzo nieefektywny kosztowo. Diagram (rys. 2) pokazuje poglądowo wykorzystanie budżetu w poszczególnych fazach projektu.

 

 

 

 

 

 

Rys. 2 – Porównanie wykorzystania budżetu w metodyce „waterfall” i w metodyce „agile”

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 nieproporcjonalnie 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 i będą się one z czasem zwiększać.

Integracja i zmiana, czyli gdzie jest wartość w systemie ERP?

W wielu projektach wdrożeniowych zauważyłem, że za sukces pojmuje się system, w którym można zaksięgować fakturę, utworzyć zamówienie czy dokument PZ, a o integracji mówi się wtedy kiedy faktura czy PZ są automatycznie dekretowane na kontach i widoczne w module finansowym. W moim przekonaniu to bardzo wąskie pojmowanie integracji w systemie ERP, a poprzestanie na ręcznym księgowaniu dokumentów sprawia, że system jest używany jak bardzo droga kasa fiskalna.

O sukcesie wdrożenia systemu ERP czy o zrealizowaniu wartości z wdrożenia można mówić wtedy, gdy cała firma zaczyna pracować w jednym systemie, a płynące z niego informacje stanowią jedno źródło prawdy w poszczególnych działach firmy i na wszystkich poziomach zarządzania, a także gdy zostaną zintegrowane i zautomatyzowane w nim procesy biznesowe. Tę myśl ilustruje diagram na rys. 3.

 

 

 

 

 

 

Rys. 3 – Gdzie jest wartość w systemie ERP? (źródło: opracowanie własne)

Zazwyczaj implementacje systemu ERP traktowane są jako projekty IT, zarządzane są przez informatyków czy finansowane z budżetów IT. Czasami tylko, tytularnie w strukturach zarządzania projektem zasiadają przedstawiciele zarządu firmy. Prawdziwe wdrożenie systemu ERP natomiast jest projektem przede wszystkim biznesowym, projektem implementacji zmian organizacyjnych, integracji zarządzania i optymalizacji procesów, gdzie wspomniane zmiany są tylko inicjowane przez wprowadzenie nowego narzędzia informatycznego. Stąd transakcje i funkcjonalności systemu stanowią jedynie czubek góry lodowej. Te aspekty są oczywiście bardzo ważne, ale jedynie wówczas jeśli umożliwiają wydajne zarządzanie procesami firmy, pozwalają mierzyć jakość zarządzania, są obsługiwane przez wyszkolonych użytkowników, którzy czują się właścicielami danych, automatyzują procesy i sygnalizują poprzez wyjątki sytuacje wymagające ręcznej interwencji (ang. management by exceptions).

Można więc bezpiecznie założyć, że dojrzały system klasy ERP zawiera wszystkie funkcjonalności niezbędne do zarządzania przedsiębiorstwem, a także predefiniowane procesy biznesowe (ang. best practices) gotowe do szybkiego uruchomienia i wykorzystania. Ktoś powie, że to nazbyt radykalne podejście, że przecież każda firma ma swoją specyfikę i wymaga indywidualnego podejścia. To oczywiście prawda. Jednak prawdą również jest, że w każdej firmie produkcyjnej występują zlecenia produkcyjne, które są harmonogramowane które obciążają moce produkcyjne, że każda firma dokonująca zakupów tworzy zamówienia zaopatrzeniowe i weryfikuje do nich faktury. W moim przekonaniu unikatowość firmy leży w jej portfolio produktów, w relacjach z klientami, w polityce cenowej. Natomiast system ERP powinien tę unikatowość wspierać przy pomocy możliwie standardowych procesów. Oczywiście bywają przypadki, kiedy przedsiębiorstwo wymaga określonych specyficznych funkcjonalności jak np. dostawy JIS (ang. just-in-sequence). To powinno zostać jednak uwzględnione podczas wyboru systemu ERP, ponieważ to jego wybór, a nie wdrożenie musi zapewnić, że spełnia on takie specyficzne wymagania.

 

Michał Domolewski, Consulting Manager ERP, SID

Elementem decydującym o sukcesie jest właściwe zdefiniowanie celu projektu i ustalenie zakresu prac, który z jednej strony spełni oczekiwania sponsorów, a z drugiej – uwzględni dostępność zasobów po stronie biznesu. Optymalnie, gdy wiodące role w zespole projektowym pełnią eksperci z szeroką wiedzą nt. organizacji oraz decyzyjnością w kwestii jej funkcjonowania po wdrożeniu. Im większym autorytetem wewnątrz firmy cieszą się liderzy, tym większa szansa na pozytywne odebranie wprowadzanych zmian przez pracowników oraz finalny sukces projektu. Z punktu widzenia zakresu prowadzonych prac, szczególnie w obszarach produkcyjnych i zarządzania łańcuchem dostaw, rekomendujemy określenie czasu dla kluczowych zasobów.  Odpowiednie dostosowanie zakresu działań do realnych możliwości użytkowników to pewność, że rozwiązanie zostanie odpowiednio przetestowane i przede wszystkim –  prawidłowo obsłuży procesy biznesowe po starcie. Dlatego często sugerujemy podzielenie wdrożenia na etapy. W pierwszej kolejności rekomendujemy koncentrację na krytycznych procesach, usprawnienie i zautomatyzowanie najważniejszych obszarów. Następnie, realizujemy mniejsze projekty rozwojowe, które są wynikiem m.in. audytów powdrożeniowych. Po pierwszej implementacji, znacząco wzrasta świadomość kluczowych specjalistów w zakresie możliwości SAP ERP, dzięki czemu są w stanie znacznie lepiej ocenić realne potrzeby w obszarach wymagających  optymalizacji lub automatyzacji. W realizowanych projektach kładziemy nacisk, by jak najszerzej podzielić się wiedzą, by zespół klienta stał się partnerem wdrożenia, a nie tylko odbiorcą finalnego produktu. W modelu współpracy zakładamy rozwój oprogramowania wraz ze wzrostem świadomości pracowników nt. jego funkcjonowania. W konsekwencji, takie podejście umożliwia najbardziej efektywne wykorzystanie wszystkich funkcjonalności systemu.

 

dr Paweł Dawid, Business Development Manager, DSR S.A.

Jednym z najważniejszych elementów warunkujących sukces wdrożenia jest zaufanie pracowników do nowego systemu. Odpowiedzialność za ten element ponosi kadra zarządzająca, która powinna w odpowiedni sposób motywować użytkowników do korzystania z zaimplementowanego rozwiązania. Często wśród pracowników pojawia się również niepokój, związany z decyzją o wdrażaniu oprogramowania. Sądzą oni bowiem, że efektem zmian może być racjonalizacja zatrudnienia i w konsekwencji redukcja etatów. Ważne jest więc, żeby kadra zarządzająca jeszcze przed projektem wyjaśniła w przejrzysty sposób wszystkie kwestie. Tylko w ten sposób pracownicy staną się zwolennikami nowych technologii, podnoszącymi konkurencyjność firmy i jej wartość rynkową. Firma DSR S.A. współpracuje z Klientami na każdym etapie życia systemu informatycznego. Oczywiście po zakończeniu projektu implementacyjnego oraz uruchomieniu produkcyjnym systemu, realizowane są systematyczne analizy wykorzystywanych funkcjonalności. Dzięki temu konsultanci mogą na bieżąco weryfikować poziom eksploatacji oprogramowania, nie tylko w przypadku najbardziej newralgicznych funkcjonalności. Są również w stanie doradzać oraz sugerować rozwój aplikacji w odpowiednim, najbardziej korzystnym dla Klienta kierunku. Transfer wiedzy odbywa się na każdym etapie wdrażania systemu informatycznego. Już podczas fazy analizy, zbierane są informacje odnośnie wyzwań, zagrożeń, silnych i słabych stron. Na tej podstawie konsultanci mogą zaprojektować rozwiązanie odpowiadające potrzebom użytkowników w poszczególnych obszarach merytorycznych. W dalszych fazach następuje intensywny transfer wiedzy wykorzystujący zarówno szkolenia konsultantów z zakresu wdrażanego systemu, jaki ich doświadczenie oraz dogłębną wiedzę rynkową.

 

Damian Dziuba, główny architekt systemu, Sente Systemy Informatyczne sp. z o.o.

Z naszego doświadczenia wynika, że najlepiej jest poinformować pracowników firmy o planowanym wdrożeniu nowego systemu możliwie jak najszybciej. Wdrożenie powinno być jak najbardziej transparentne. Najlepiej aby w cały proces była włączona osoba bezpośrednio z działu produkcji. Daje to pracownikom poczucie bezpieczeństwa oraz wpływu na to, jak przebiega projekt wdrożeniowy. Ważne jest aby uświadomić pracownikom, że wdrażany system ma na celu usprawnienie ich pracy. System ma pomóc, ale nie zastąpić myślenia, wykorzystania wiedzy i umiejętności. Przede wszystkim wdrożone rozwiązanie nie może stanowić ograniczenia dla ludzi oraz organizacji. Kultura współodpowiedzialności, coraz częściej jest spotykana w firmach, ma to duże znaczenie podczas pracy przy danym projekcie. Obecnie zaczynając projekt ściśle współpracujemy z Product Ownerem projektu po stronie klienta, który angażuje swoich współpracowników w przygotowanie systemu. Dzięki przyjęciu takiego modelu, uwzględniamy potrzeby, jakie rzeczywiście występują w przedsiębiorstwie i dokładnie identyfikujemy obszary, których objęcie systemem, przyniesie największe korzyści biznesowe i personalne zwiększające zaangażowanie pracowników. Tworzymy z klientem narzędzia monitorujące aktywność operatorów w istotnych obszarach, dzięki temu jesteśmy w stanie zauważyć brak wykorzystywania danej funkcjonalności w systemie. Dodatkowo kilka razy w roku spotykamy się z klientem w jego firmie. Produkcja cały czas żyje, klient zmienia asortyment, wchodzi na nowe rynki, optymalizuje procesy, przebudowuje hale produkcyjną. W tym wszystkim uczestniczy system. Podczas asyst u klienta omawiamy bieżące potrzeby, rozmawiamy o tym jak zmieniają się procesy w firmie oraz jak możemy dostosować system do tych zmian. Przy stosowanej przez nas zwinnej metodyce pracy (scrum) transfer wiedzy odbywa się najpierw pomiędzy Product Ownerem a architektem systemu. Osoby te mają komplet wiedzy nt wszystkich procesów. Stają się one kolektorami wiedzy i to one tą wiedzę dystrybuują już bezpośrednio w przedsiębiorstwie, czy to przez szkolenia zewnętrzne jak i wewnętrzne. Wiedza dotycząca wdrażanego systemu jest taka sama po stronie dostawcy (w osobie architekta), jak i klienta (w osobie Product Ownera). Dzięki temu klient ma w firmie takie same kompetencje jak dostawca. W trakcie współpracy system jest aktualizowany, o takich zdarzeniach klient jest informowany z odpowiednim wyprzedzeniem. Otrzymuje dokładną instrukcję oraz informację co zmieni się po aktualizacji systemu. Stosujemy też formę warsztatów u klienta, gdzie asystujemy w pracy wskazanym pracownikom, pomagając im lepiej wykorzystać możliwości systemu w ich codziennej pracy.

 

Paweł Orzeszko, członek zarządu, proALPHA Polska Sp. z o.o.

Z naszych doświadczeń wynika, że firmy poszukujące i wdrażające nowe rozwiązania informatyczne najczęściej oczekują usprawnienia procesów w szeroko rozumianym obszarze zarządzania produkcją oraz wsparcia od dostawcy systemu – m.in. transferu wiedzy. Już na etapie przygotowania do wdrożenia wsparcie dotyczy zarówno sfery technicznej np. w zakresie uporządkowania danych podstawowych, ale również obszarów miękkich takich jak powołanie zespołu projektowego i odpowiednie przygotowanie jego członków do realizacji powierzonych im zadań. W zespole projektowym istotną rolę odgrywa Kierownik Projektu – osoba przygotowana, rozumiejąca co to jest projekt i mająca wsparcie zarządu lub właścicieli. Sprawna realizacja projektu wymaga zaangażowania pracowników na różnych szczeblach. W szczególności pracownicy z długim stażem mogą poczuć się niepewnie w kontakcie z nową technologią, mając dodatkowo poczucie utraty unikatowego know-how. Przygotowanie do projektu w sferze komunikacji, motywacji (również zachęty finansowe) ma tutaj kluczowe znaczenie. Informatyzacja procesów produkcyjnych  często odzwierciedla problemy w obszarze zakupów oraz sprzedaży. Konieczne staje się uporządkowanie relacji z dostawcami oraz zapewnienie zgodności polityki sprzedaży z zasadami planowania produkcji. Kierownictwo firmy powinno być przygotowane na udział w koordynacji  działań i przepływu wartości pomiędzy tymi działami. Przeprowadzenie wewnętrznych spotkań pozwala na uzgodnienie wdrożenia i zrozumienie planowych zmian.

 

Bartłomiej Lux, prokurent, CFI Systemy Informatyczne Sp. z o.o.

Monitorowanie sytuacji przedsiębiorstwa po implementacji rozwiązania powinno być standardowym postępowaniem każdego dostawcy oprogramowania klasy ERP. W CFI bieżąca kontrola sytuacji po wdrożeniu jest tak samo ważna jak analiza przedwdrożeniowa. Prowadzony przez nas monitoring wykorzystywania funkcjonalności z obszarów biznesowych pokrytych VENDO.ERP stanowi źródło wiedzy o naszym kliencie, jego potrzebach, możliwościach i potencjale. Poza działaniami indywidualnymi podejmujemy też bardziej globalne aktywności skierowane do wszystkich naszych klientów. Organizowane przez nas cykliczne wirtualne spotkania o charakterze edukacyjnym to znakomita okazja i możliwość podzielenia się wiedzą i doświadczeniem, nie tylko w obszarze ERP, ale także na temat szeroko pojętych procesów biznesowych. Współpracujemy także z ekspertami z zakresu Lean Management, którzy świadcząc usługi wśród naszych klientów zapewniają im jak najlepsze wykorzystanie posiadanych narzędzi w celu osiągnięcia maksymalnych korzyści.

 

Justyna Wronka-Dudzińska, Head of Consulting & Board Member, XPLUS
Nawet jeśli proces wdrożenia uznaje się za zamknięty, po jego zakończeniu wspieramy Klienta w eksploatacji systemu. Śledzimy szerokość i głębokość wykorzystywanych funkcji. Pozyskujemy informacje o potrzebach biznesowych, które adresujemy w systemie, pokrywając wymagania pracowników. W przypadku produkcji jest to istotne, ponieważ skuteczniej wdraża się ją etapami. Większe zrozumienie uzyskujemy, gdy pozwalamy okrzepnąć nowemu rozwiązaniu wśród pracowników, a dopiero po tym wprowadzamy trudniejsze funkcje. Monitorujemy zgłaszane problemy i błędy procesowe, proponując użycie nowych funkcji lub zmiany w obecnych, co w efekcie zwiększa efektywność rozwiązania. Wdrożenie systemu ERP to wprowadzenie szerszej strategii. Lider biznesowy musi znać jej założenia i rozumieć wpływ procesów. To podejście gwarantuje, że rozwiązanie będzie zrozumiałe dla końcowych użytkowników i ważne dla organizacji. Na początku należy przeanalizować dotychczasowe procesy wraz z zespołem wdrożeniowym i liderami biznesowymi  obszaru. Ich udział pozwoli na pełną wiedzę o sytuacji AS-IS w produkcji i uczyni z nich właścicieli tego procesu. Aby pracownicy zaangażowali się w eksploatację systemu, zrozumieli sens i dostrzegli wartość dla swojej pracy, należy zidentyfikować dotyczące ich problemy. Na etapie wdrożenia należy skupić się na rozwiązaniu problemów, eliminując nieproduktywne kroki.

 

Jacek Borkowski, szef Wydziału Modułów Sprzedażowych i Produkcyjnych w Dziale Produkcji Systemów ERP Asseco Business Solutions S.A.
W dzisiejszych czasach, gdy dostęp do technologii pozwalających monitorować stan procesów produkcyjnych jest ograniczony głównie wielkością inwestycji, bardzo ważne staje się optymalne zdefiniowanie potrzeb klienta przed wdrożeniem oprogramowania klasy ERP. Przy czym – co warto podkreślić – optymalizacja ta ma głównie na celu zrównoważenie wysiłku ponoszonego w celu zebrania danych oraz kosztu przygotowania odpowiednich do tego celu rozwiązań informatycznych. Oczywiście czas nie stoi w miejscu – w ramach opieki powdrożeniowej, która obejmuje m.in. wsparcie konsultantów Asseco Business Solutions, w porozumieniu z klientem uruchamiane są często nowe funkcjonalności – wspomagające kolejne procesy biznesowe powstałe w wyniku rozwoju firmy klienta. Inne narzędzia mogą natomiast z różnych względów być wygaszane, jeśli np. w wyniku zmian organizacyjnych nie są już potrzebne. Ten ostatni proces jest wspomagany przez odpowiedni moduł diagnostyczny monitorujący wykorzystanie funkcji systemu.

 

Witold Olczak, Consulting Team Manager, Senior SAP Consultant, itelligence Sp. z o.o.
Systemy ERP zostały stworzone z myślą o firmach produkcyjnych i właśnie w nich sprawdzają się najlepiej. Najważniejsze to mieć jasną wizję celu, do którego się zmierza i konkretne, mierzalne wskaźniki obrazujące status jego wykonania. Należy wziąć pod uwagę fakt, że systemy ERP ewoluują od wielu lat i zostały zaimplementowane w dziesiątkach tysięcy wdrożeń. Naprawdę trudno jest postawić przed nimi zupełnie nowe wyzwanie. Nie ma znaczenia czy mamy do czynienia z produkcją zleceniową, seryjną czy opartą na systemie projektowym. To czego szukamy na 99 proc. zostało już wymyślone. To co sprawia problem, to rozpoznanie rzeczywistych potrzeb przedsiębiorstwa i nieuzasadniony przerost oczekiwań tam, gdzie prostota daje najbardziej optymalne i wymierne efekty. Najczęściej powielane błędy to zbyt silne przyzwyczajenie do własnej metodyki pracy i stosowanych obecnie rozwiązań oraz posiadanej kultury organizacyjnej, przekonanie o wyjątkowości prowadzonej przez siebie działalności i unikatowości własnych procesów biznesowych i wynikająca z tego próba bezkrytycznego przełożenia w skali 1:1 wszystkich swoich oczekiwań na projektowany system ERP. Dlatego pierwszy i niełatwy krok, jaki należy podjąć to próba spojrzenia na wdrożenie oczami niezależnego obserwatora, realisty chłodno szacującego wszystkie koszty i wizjonera dostrzegającego wszystkie potencjalne korzyści. Kolejnym wyzwaniem jest zaszczepienie tej wizji we własnym zespole i pokazanie perspektyw jakie dają zmiany. Na koniec ważna jest umiejętność zadawania odpowiednich pytań i jeszcze ważniejsza umiejętność wsłuchania się w odpowiedzi.

Dominik Tylczyński

Dyrektor działu konsultingu SAP w Inteco Business Solution (grupa Amica), absolwent Francusko-Polskiej Wyższej Szkoły Nowych Technik Informacyjno-Telekomunikacyjnych i Politechniki Poznańskiej. Od 1995 r. zajmuje się wdrożeniami SAP w obszarach gospodarki materiałowej oraz gospodarki magazynowej, ma liczne certyfikaty, m.in. SAP Supply Chain Management – Procurement, SAP Supply Chain Management – Logistic Execution, a także SAP Exchange Infrastructure & Integration oraz SAP ABAP Development. Ma bogate, wieloletnie doświadczenie w obszarze integracji systemu SAP z systemami informatycznymi i telekomunikacyjnymi klienta. Obecnie specjalizuje się w projektach optymalizacji zarządzania łańcuchem dostaw z wykorzystaniem systemów SAP, w trakcie których buduje dojrzałość informacyjną przedsiębiorstwa, przywraca zaufanie do danych i automatyzuje procesy logistyczne. Współtwórca Polskiej Grupy Użytkowników SAP https://sapusers.pl i Forum SAP https://forumsap.pl