�ݺ�ߣ

Modele wdrażania i zarządzania projektami ERP
Jarosław Żeliński – analityk
biznesowy, projektant systemów
(c) Jarosław Żeliński IT-Consulting 1

Cel prezentacji
• Wskazanie kluczowych ryzyk projektów
wdrożenia systemu ERP/ERPII
(oprogramowania):
– Niepełne zrozumienie problemu – odkrywanie
problemów (wymagań) dopiero podczas
wdrożenia
– Złe zarządzanie ryzykiem – kolejność działań
zawsze ma znaczenie: co najpierw jajko czy kura?

Agenda
• Ogólna architektura obecnych systemów ERP
• Co zalecają producenci systemów ERP
• Fazy i etapy projektu „Wdrożenie nowego
systemu ERP” - warianty

ERP - dziedzinowy podział systemu
Obiektowy System Zintegrowany
Dokumenty sprzed.
- Dane
- Operacja na danych
Dokumenty fin.
- Dane
Dokumenty HR
- Dane
Dokumenty prod.
- Dane
- Operacja na danych Dokumenty …
- Dane
Nowoczesne
systemy ERP to
systemy obiektowe
Test architektury: czy możliwa jest dowolna kolejność wdrożenia modułów?

Duży system to dużo wymagań, gdzie jest granica?
ANALIZA I SPECYFIKOWANIE
WYMAGAŃ

Specyfikowanie czy testowanie
• Specyfikowanie złożonych systemów jest
kosztowne i czasochłonne, jest także narażone na
pomyłki proporcjonalnie do stopnia jego
złożoności
• Przekazanie dostawcy systemu, zamiast takiej
specyfikacji, celu oraz opisu testu czy cel jest
spełniony, pozwala uniknąć ryzyka pomyłki:
– Zamiast specyfikować szczegóły tego jak ma być
wspomagana czynność wystawienia faktury
bezpieczniej jest zażądać tego, by fakturę tę testowo
wystawiono dostarczonym narzędziem co jest
dowodem spełnienia naszych oczekiwań (wymagań).

Mała uwaga…
Prawdopodobnie jest to
najbardziej kosztowna i
niepotrzebna praca bo
podnosi ryzyko projektu
zamiast go obniżać…

Skuteczne postępowanie…
• Opracowanie modelu organizacji: mapy procesów powiązane z wzorami
dokumentów,
• Opracowanie sformalizowanej struktury organizacyjnej (podległość i
zasoby, wiedza użytkowników),
• Opracowanie specyfikacji reguł biznesowych (sterują procesami),
• Słownik pojęciowy – specyfikacja tego co znaczą kluczowe pojęcia w firmie
np. czym jest Projekt, Produkt czy Sprzedaż, tworzenie wspólnego
wewnętrznego języka,
• Kolejny krok to analiza obszarów dziedzinowych:
– Model dziedziny - opisujący jakimi informacjami i jak zarządza organizacja,
– Identyfikacja spójnych oraz luźno powiązanych obszarów dziedzinowych,
• Wyszukanie na rynku gotowego oprogramowania spełniającego
wymagania dziedzinowe (tak zwane COTS: Commercial of the shelf)
• Opisanie wymagań na podsystemy dedykowane, te których nie ma na
rynku a są wymagane.

Wymagania
• Powodem wielu porażek i nieudanych projektów wdrożeniowych jest:
– zbyt wiele nacisków dostawcy na kompromisy podczas wdrażania gotowego, parametryzowanego
oprogramowania w postaci jednego zintegrowanego pakietu: oprogramowanie staje mało przydatne
– zbyt wiele nacisków kupującego na dopasowanie (kastomizację): znacznie rosną koszty i odsuwa się
termin jego wdrożenia a nadal nie ma gwarancji powodzenia.
• Wiele specyfikacji jakie obserwuję to lista setek pozycji, opisujących jak ma „ten
program działać”, typowe efekty:
– Lista cech dużego systemu ERP to ponad 6000 pozycji
– Optymistycznie patrząc można liczyć na zgodność własnej takiej listy z gotowym produktem na rynku
w 80%
– Pozostaje więc 20% cech brakujących, to jest 1200 cech
– Jedna nowa funkcjonalność to optymistycznie licząc dwa dni pracy konsultanta i programisty, przy
koszcie 1200zł/dzień wychodzi 2,88 mln.
• Kupując oprogramowanie gotowe nie projektujemy go, a specyfikujemy to do
czego będzie używane: wskazujemy które procesy system ma obsłużyć i jakiego
produktu procesu oczekujemy.
• Kluczowe wydaje się wydzielenie tych procesów, które są najistotniejsze dla firmy a
ich wparcia nie oferuje gotowe oprogramowanie, pozostaje rezygnacja lub
umiejętne zaprojektowanie ich jako aplikacji dedykowanej.

Proces analizy i specyfikowania vs. kastomizacja vs.
wytworzenie
Cel: zakup gotowego systemu to szybsze i tańsze uzyskanie korzyści z jego posiadania
Wyspecyfikowano 100% cech
Czas trwania
koszt
Co system wspiera Jak to system wspiera
Dostarczono 100% cech
Dokumentacja opisuje:

Ile powinno być tych „wymagań”?
• Lista funkcjonalności typowego kompletnego pakietu ERP II może
obejmować nawet ponad 6 tys. cech!
• Planowanie ich wdrożenia a wcześniej wyspecyfikowanie, wybór
produktu i jego dostawcy nie może być typowym procesem wyboru
oprogramowania: nikt nie jest w stanie zarządzać taką liczbą
wymagań w jednym projekcie.
• Jeżeli zgodność gotowego oprogramowania z naszymi
szczegółowymi wymaganiami osiągnie przypadkiem 80% (mało
prawdopodobne!) to pozostanie 20% do „kastomizacji” – 1200
cech,
• Gdyby na jedną poświęcić tylko jeden dzień (mrzonka) a dzień
konsultanta kosztował 1000zł (?!) to projekt osiąga wartość 1,2 mln!
• Dlatego wymagania na gotowe oprogramowanie powinny być
„krótką” listą tego do czego będzie ono używane a nie „mega listą”
tego jak ma wyglądać…

Kompromis
• Zamawiamy schody,
po których możliwe
będzie wniesienie na
pierwsze piętro szafy
o wymiarach
200x60x80 cm
• Określenie celu
(planowanego
użycia) gwarantuje
spełnienie
wymagania.
• Zakup gotowego
produktu to
rezygnacja z
pewnych szczegółów
na korzyść krótkiego
terminu dostarczenia
i niższego kosztu w
porównaniu z
tworzeniem
dedykowanego.
?????????

Dwie najistotniejsze rzeczy w wymaganiach:
• Opis logiki biznesowej i
dokumentów (dane
wprowadzane, zasady
ich przetwarzania, dane
oczekiwane – wynik
przetwarzania)
• Opis podziału
kompetencji pomiędzy
użytkowników i system
(kto policzy VAT na
fakturze?)

Podsumowanie wymagań
Wymagania na złożone systemy, zdefiniowane jako zestaw testów
są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna
specyfikacja prostych funkcji. Tworzenie testów wymaga jednak
określenia biznesowego celu wdrożenia i zrozumienia tego jak
organizacja funkcjonuje (opracowanie modeli).
Praktyka pokazuje, że koszt analizy i opracowania takich testów
jest znacznie niższy niż nieplanowany dodatkowy koszt projektów
(średnie przekroczenie budżetu to ponad 60%).

Produkty analizy systemowej

Proces zalecany z perspektywy producenta
oprogramowania ERP
Wybór systemu ERP i jego dostawcy to pierwszy krok

Proces zalecany w perspektywy nabywcy
Wybór systemu ERP i jego dostawcy to ostatni krok

Praktyka mówi, że
WYBÓR PRODUKTU I JEGO DOSTAWCY
POWINIEN BYĆ OSTATNIM KROKIEM
POPRZEDZAJĄCYMI WDROŻENIE…

Dziękuję za uwagę…
PYTANIA…?

O mnie…
Od 1991 roku w branży IT i zarządzania
Od 1998 roku jako niezależny analityk, projektant i
firma it-consulting.Pl
Dziesiątki publikacji w prasie branżowej i
gospodarczej
Członek stowarzyszenia doradców gospodarczych
Wykładowca katedry systemów informacyjnych
wydziału przedsiębiorczości akademii morskiej w gdyni
Kilkudziesięciu odbiorców usług doradczych, małe,
średnie i duże firmy zarówno informatyczne jak i ich
klienci.
Poświadczenie bezpieczeństwa wydane przez abw
Ekspert przy gabinecie komisji nadzoru finansowego
Doktorant katedry informatyki gospodarczej SGH
Projekty analityczne
między innymi dla…
Publikacje między innymi w …

�ݺ�ߣ

Modele wdrażania i zarządzania projektami erp

Recommended

More Related Content

Viewers also liked (20)

Similar to Modele wdrażania i zarządzania projektami erp (20)

More from Jaroslaw Zelinski (7)

Modele wdrażania i zarządzania projektami erp