Problem polega na tym, że niemalże każdy dostawca systemu ERP  twierdzi, że jego produkt pasuje dla każdej firmy. Czy na pewno? Ale po kolei…

Systemy klasy ERP to szeroka gama oprogramowania wspomagającego zarządzanie przedsiębiorstwami i organizacjami. Skrót ERP oznacza [[Enterprise Resource Planning]] (z ang. Planowanie Zasobów Organizacji). Systemy tego typu wywodzą się ewolucyjne z systemów MRP (Material Requirement Planning, Planowanie Potrzeb Materiałowych) i MRP II (Manufacturing Resource Planning, Planowanie Zasobów Produkcyjnych).

ERP jest opisywane jako MRP III czyli Money Resource Planning – Planowanie Zasobów Finansowych, w tym:

1.  jest systemem obejmującym całość procesów produkcji i dystrybucji;
2.  integruje różne obszary działania przedsiębiorstwa;
3.  usprawnia przepływ krytycznych dla jego funkcjonowania informacji;

Od kilku lat obecne jest pojęcie ERP II. Podstawową cechą odróżniającą systemy ERP II od poprzedników jest to, że oprócz funkcjonalności umożliwiającej planowanie zasobów rzeczowych i finansowych przedsiębiorstwa, zawierają oprogramowanie pozwalające na zarządzanie kontaktami z klientem (tzw. CRM – Customer Relationship Management) oraz dokonywanie zaawansowanych analiz, prowadzenia tak zwanego kontrolingu, mają funkcjonalności zaawansowanego raportowania (podsystem wspomagania podejmowania decyzji, Business Intelligence). Cechą tych systemów, obecnie już wymaganą, jest także możliwość korzystania z nich poprzez sieć WWW.

Systemy te umożliwiają tworzenie serwisów internetowych dla klientów przedsiębiorstwa, kooperantów czy wreszcie pracowników. Portale takie umożliwiają bezpośrednią komunikację użytkowników z systemem informacyjnym przedsiębiorstwa. Klienci mogą przeglądać aktualną ofertę firmy, zamawiać wyroby czy uzyskiwać na bieżąco informacje o stanie wcześniej złożonych zamówień. Podwykonawcy mogą sami sprawdzić bieżący stan zapasów produkowanego przez siebie elementu i dopasować swój plan produkcyjny do zamówień generowanych przez system MRP odbiorcy. Pracownicy przedsiębiorstwa, nawet będąc poza nim, mogą zdobyć informacje o bieżącym stanie wybranych przez siebie dziedzin działalności. (na podstawie http://www.mrp.malicki.info/erp2.html)

Jak widać są to bardzo złożone systemy. Lista funkcjonalności takiego pakietu ERP II obejmuje ponad 6 tys. cech! Planowanie ich wdrożenia a wcześniej specyfikowanie wymagań, wybór produktu i jego dostawcy nie może być typowym procesem wyboru oprogramowania: nikt nie jest w stanie zarządzać taką masą wymagań w jednym projekcie.

Dlatego metodyka, którą stosuję bazuje na twierdzeniu, że systemy obsługujące standardowe obszary działania, powinny być obsługiwane standardowymi narzędziami. Ich definiowanie nie polega na specyfikowaniu wszystkich ich cech, których są setki a powoływaniu się na normy i przepisy, z którymi muszą być (lub chcemy by były) zgodne. Wymagania na całość wystarczy uzupełnić o kluczowe parametry naszych procesów i dokumentów (najwyżej kilkadziesiąt!) oraz testy czy konkretny system je spełnia.

Projekty, których celem jest wdrożenie systemu ERP II powinny być prowadzone w sposób pozwalający jak najszybciej zdefiniować obszar stanowiący klucz przewagi konkurencyjnej, stanowiący specyfikę danej organizacji, to co odróżnia ją od reszty. Praktyka pokazuje, że jest to kilka do kilkunastu procent działań (nie więcej niż 20%). To założenie pozwala prowadzić projekt w następujący sposób:

1. analiza biznesowa,
2. analiza przewagi konkurencyjnej,
3. wyłonienie obszaru budującego przewagą na rynku,
4. zdefiniowanie wymagań na tak określony obszar,
5. wskazanie standardów, które opisują pozostałe działania w organizacji,
6. projekt logiki architektury systemu.

Pierwsze trzy to element studium możliwości. Pozostałe trzy, uzupełnione o oferty dostawców, to studium wykonywalności: w tym miejscy można zrezygnować z projektu lub przedefiniować jego zakres i nie ma tym nic złego.

Kolejny wniosek z wielu wdrożeń złożonych systemów: system IT należy opisywać jako odrębne dziedzinowe podsystemy, wybierać, kupować i wdrażać osobno (polecam artykuł firmy K2Consulting: Jak zjeść słonia w terminie i budżecie i się przy tym nie udławić?).

Obecny poziom standaryzacji pozwala na relatywnie łatwą integrację systemów różnych producentów. Praktyka pokazuje, że wdrożenie kilku dobrze dobranych podsystemów osobno, jest znacznie tańsze i trwa krócej niż kompromisowy (najczęściej tak zwany zgniły kompromis) wybór jednego uniwersalnego systemu i dostosowywanie go do swoich potrzeb (tak zwana kastomizacja).

Struktura takiego projektu wygląda następująco:

(źr. Jarosław Żeliński, opracowanie własne, 2005 rok)

Analiza biznesowa obejmuje wyłącznie obszar strategii i procesów biznesowych. Wdrożenie poprzedzane jest analizą całej organizacji, wydzielenie w niej niezależnych obszarów dziedzinowych (np. rachunkowość, zarządzanie procesami pracy, zarządzanie wiedzą, portal klienta, zarządzanie i sterowanie produkcją, zarządzanie procesem sprzedaży, inne).

Każdy obszar cechuje się tymi trzema poziomami: strategia, procesy, realizacja. Na etapie analizy potrzeb prowadzimy audyt i modelowanie procesów. Zakładamy, że szczegóły tego ?jak pracujemy? i tak ulegną zmianie po wdrożeniu nowego narzędzia pracy, więc pomijamy je na tym etapie (zostaną określone podczas wdrożenia). Jeżeli analiza wykaże, że istnieje obszar niestandardowy w organizacji, tylko dla tego obszaru prowadzi się szczegółową analizę, gdyż w tym obszarze będzie (najprawdopodobniej) wdrażane rozwiązanie dedykowane.

Co do części standardowej można zrobić to samemu korzystając z tanich ofert dostępnych w sieci np. http://rfp-builder.com/ (Ready-to-use RFI/RFP Templates Designed by expert analysts for any software selection project) gdzie można nabyć gotowce. (patrz mój wcześniejszy artykuł: Ile zapłaciłeś za wykonanie SIWZ na system ERP?).

Tak więc zintegrowany system ERP II nie musi oznaczać “od jednego dostawcy”. Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, że “systemy od wszystkiego są do niczego”…

Opracowywanie wymagań to planowanie zmian. Nie ma sensu spisywanie szczegółów tej pracy, jeżeli wdrażane zmian spowoduje powstanie np. nowych procedur, wynikających z celu projektu. Zupełnie wystarczy wiedza o procesach i ich produktach (co i po co robimy). To jak one będą powstawały (w jaki sposób) będzie efektem wdrożenia np. nowego systemu ERP i istniejących ograniczeń, reguł biznesowych. (cytat z artykułu: Modelowanie biznesowe c.d. ? know-how, gdzie ono jest?).