Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…
Przy piątku naszło mnie na zestawienie pewnych treści (cytaty). Podczas codziennej "prasówki" wpadłem na artykuł "Najczęściej popełniane błędy podczas wdrożenia ERP", oto cytat pierwszy: - Największym błędem popełnianym przy wdrożeniach…
Pokusa wdrożenia systemu połączonego z “modyfikowaniem pod potrzeby klienta” ładnie brzmi, ale nawet gdyby się to udało, to system taki usztywni firmę, zabierze jej więc jej kluczową zaletę: zwinność! Tak więc dla MSP owszem nawet duży system ERP ale z bogatym menu i swobodą dostępu do niego. Po drugie “wielkie zintegrowane zwierzę” będzie się wdrażało długo bo jest wielkie. Znacznie bezpieczniejszą dla MSP strategią jest wdrażanie funkcjonalności ERP etapami, mieszczącymi się w granicach roku budżetowego, nawet jeżeli miało by to oznaczać, że poszczególne moduły będą pochodziły od różnych dostawców (pisałem o tym nie raz tu).
Nie ma możliwości łatwego udzielenia odpowiedzi na przytoczone dwa pytania na zadawane na konferencjach, bez zrozumienia tego co trapi daną firmę, jednak nasz kraj przoduje w sprzedaży leków bez recepty i mam wrażenie, że analogiczne zjawisko ma miejsce na rynku oprogramowania: po co nam jakaś analiza czy audyt, idziemy i kupujemy tego “erpa” bo mówią, że pomaga a firma sprzedająca obiecała, że pomoże.
Pojęcie ERP samo z siebie nie ma ścisłej definicji więc nie ma mowy o “upośledzaniu czegoś jako ERP”. Komentując dalej: ERP dla mnie nie jest żadną religią, jest jednym z wielu dostępnych na rynku pakietów oprogramowania. Skór ERP występuje w tak wielu nazwach produktów, tak wielu dostawców, że traktowanie go, moim zdaniem, jako cokolwiek więcej niż “zestaw oprogramowania kompleksowo wspomagający zarządzanie organizacją” jest chyba trudne do uzasadnienia. A skoro i tak do “ERP” dodaje się dziedzinowe rozwiązania (logistyka, produkcja, HR, wiele innych) to chyba dowodzenie, że to “monolit” w jakiejkolwiek części do niczego nie prowadzi.
Z ust adwersarza padło stwierdzenie:
Wszelkie rozwiązania polegające na tym, że jakiś podzbiór funkcji z wyżej wymienionego jest osobnym systemem rejestrującym zdarzenia osobno od centralnej bazy danych i przesyłającym je później do niej w celu zarejestrowania upośledza system jako ERP.
Dziwi mnie to, bo np. prosty proces zatwierdzania kosztów mający co najmniej dwa etapy: rejestracja faktury obcej oraz jej zatwierdzenie (lub odrzucenie) i uznanie w księgach to co najmniej dwuetapowy proces i nie ma tu większego znaczenia miejsce przechowywania pośrednich statusów bo w rzeczywistości i tak “księgi” widzą efekt ostateczny (uznanie na kontach) a poprzedzające etapy weryfikacji kosztów (proces biznesowy) “dzieją się” poza księgami.
Moim zdaniem brak ścisłej definicji pojęcia “System ERP” czy dalszą dyskusję bezwartościową. Oprogramowanie SAP nie jest żadnym referencyjnym produktem ERP (choć wielu próbuje tej tezy bronić) i posługiwanie się jego przykładem jako “wzorem” w moich oczach nie jest żadnym argumentem. Nie twierdze, ze SAP to produkt zły. To po prostu produkt jeden z wielu na rynku… ma swoje wdrożeniowe sukcesy i ma porażki jak inne.
Opisane tu podejście często nazywane jest “kaskadowym” (waterfall – wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle “wodospadowe” podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.
Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju “nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go”. To nie ma prawa się udać…
A nasze “lessons learned”? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.
Pojawiła się polemika do mojego artykułu Duży monolityczny ERP czy integracja (fragment, gorąco polecam cały wpis): Witam Kolegę Blogera i na powitanie mam małą polemikę. Otóż nie mogę się zgodzić na…
Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: “duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany”, kontra teza “duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę”. […] “lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie”…
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.
Tak więc zintegrowany system ERP II nie musi oznaczać “jedno rozwiązanie od jednego dostawcy”. Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, ze “systemy od wszystkiego są do niczego”…
