Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…
Tym razem małe "case study". Poniżej opis , tak wygląda większość mich projektów. Najczęściej mam kontakt z firmami, które przekonały się, że zawarcie umowy od razu na analizę wymagań i realizację projektu bez projektowania, i to w dodatku jako umowę T&M (czas i materiał) rodzi problemy. Prezes EXTREM, lubi zadawać wiele pytań, miał doświadczenie z poprzedniego wdrożenia (w zasadzie nie doprowadzonego nigdy do końca): Firma EXTREM w 2013 roku rozpoczęła proces wyszukiwania na rynku oprogramowania CRM i jego dostawcy. W toku prowadzanych prezentacji okazało się, że oferty różnią się od…
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.
Tak zaprojektowany system staje się systemem otwartym, pozwalającym wymienić lub dodać funkcjonalności bez ingerencji w pozostałe. I niezależnie od tego jak "uniwersalny" jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że "brzydszy" ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat... Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem.
Pamiętajmy pewną starą reklamę: "Banki od wszystkiego są do niczego"....
Artykuł jaki ukazał się w COMPUTERWORLD skłonił mnie do konfrontacji moich doświadczeń i obserwacji z jego treścią, uwagami innych doświadczonych specjalistów. Być może warto pokusić się o pewne wnioski i sugestie... Wina klienta Według niego większość firm nie jest przygotowana na wdrożenie systemu ERP. "Firmy generalnie nie radzą sobie ze zmianami. Tymczasem wdrożenie systemu ERP pociąga ich za sobą nadzwyczaj dużo. Poza tym wiele organizacji ma problemy z odpowiednim definiowaniem procesów biznesowych. To właśnie te firmy będą miały największe problemy w uzyskaniu wymiernych korzyści z posiadanego systemu" - mówi David Bergen, były szef informatyki w…
