Quereo Blog

Blog poświęcony zarządzaniu projektami IT, systemom BI, ERP i CRM

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Login
    Login Login form

Jak bezpiecznie wdrożyć system ERP cz.2

Posted by on in ERP
  • Font size: Larger Smaller
  • Hits: 2235
  • 0 Comments
  • Subscribe to this entry
  • Print

 

W pierwszej częśći artykułu Jak bezpiecznie wdrożyć system ERP cz.1. zastanawialiśmy się nad sposobem wyboru wykonawcy.

Dzisiaj zajmiemy się metodyką.

 

Zweryfikuj metodykę wdrożeniową 

Przy wyborze systemu ERP skupiamy się na produkcie i dostawcy usług zapominając o samym procesie wdrożenia. Z uwagi na popularność systemów zarządzania, wiedza na ich temat staje się dość powszechna wśród menadżerów. Unikalna natomiast pozostaje umiejętność ich wdrażania. Wydaje się, że to właśnie dojrzałość organizacyjna i konsekwencja w stosowaniu metodyki odróżnia dobre od złych zespołów projektowych. Paradoksalnie, przestrzeganie standardów zarządzania projektami jest często ważniejsze podczas realizacji małych niż dużych wdrożeń. Nie należy się spodziewać, że skomplikowany z natury system informatyczny uda nam się wdrożyć przy niewielkim budżecie bez stosowania pewnego rodzaju szablonów. Zespoły zaangażowane w duże projekty mają czas na implementację uniwersalnych standardów, wypracowanie indywidualnej metodyki i naukę na własnych błędach na koszt klienta. Przy realizacji projektów niskobudżetowych kluczową rolę odgrywają gotowe schematy postępowania i oparta na szablonach metodyka.

Metodyki zarządzania dużym projektami informatycznymi oparte są na zaadaptowanych standardach PMBOK®, IPMA, PRINCE2®i CMMISM. Tymczasem w polskich realiach przy niskobudżetowych wdrożeniach najpowszechniej stosowana jest metodyka „szarży ułańskiej”. Łatwo ją rozpoznać po następujących cechach: 

  1. brak dokumentu planu projektu
  2. brak specyfikacji wymagań lub studium wykonalności
  3. brak dokumentu analizy wdrożeniowej lub stosowanie niezmodyfikowanego „gotowca”
  4. brak kamieni milowych weryfikujących postęp wdrożenia
  5. brak ustalonych sposobów monitorowania wdrożenia
  6. brak zasad dokonywania zmian w projekcie
  7. brak etapu testów przed uruchomieniem
  8. brak analizy ryzyka
  9. bliżej nie określony zespół wybitnie uzdolnionych konsultantów i programistów

Powszechnym zaniedbaniem jest pomijanie jednego z dokumentów: analizy wdrożeniowej lub planu projektu. Analiza wdrożeniowa zawiera specyfikację potrzeb klienta oraz opisuje sposób ich realizacji w ramach wdrażanego systemu. Plan projektu powinien opisywać sposób w jaki wdrożenie będzie realizowane. Niektórzy wykonawcy kopiują szablon dokumentu, podmieniają dane odbiorcy lekceważąc specyfikę jego procesów. 

 

Alternatywą dla klasycznego planu projektu i dokumentu analizy wdrożeniowej są tzw. „metodyki zwinne”. Występujące pod wspólną nazwą „Agile Project Management” metodyki Scrum, Extreme Programming, Feature Driven Development, Test Driven Development, Crystal Clear i kilka innych były do nie dawna domeną projektów programistycznych. Obecnie ich elementy coraz częściej są adaptowane do innych projektów informatycznych, w tym wdrożeniowych. Ponieważ każda z tych metodyk ceni działające oprogramowanie ponad dokumentację, należy się po nich spodziewać bardziej zwięzłego planu projektu oraz uproszczonej analizy. Podejście „zwinne” nie może być jednak wymówką usprawiedliwiającą brak jakiejkolwiek metodyki. Jeśli wykonawca nie dostarcza ani szczegółowej dokumentacji, ani w regularnych i krótkich interwałach fragmentów działającego systemu, oznacza to zwykle, że pojęcie metodyki zarządzania projektami nie jest mu znane.

 

Bez względu na przyjętą metodykę, najważniejszymi elementami planu projektu z punktu widzenia skuteczności wdrożenia są: 

  1. Zakres projektu i związany z nim kosztorys
  2. Harmonogram uwzględniający testy
  3. Plan zarządzania ryzykiem
  4. W przypadku metodyk zwinnych dodatkowo: plan cyklicznych spotkań, na których relacjonuje się postęp prac, precyzuje plany i prezentuje gotowe części rozwiązania

Brak jasno sprecyzowanego zakresu projektu prawie zawsze skutkuje mniejszym lub większym konfliktem, przekroczeniem kosztów, terminów lub brakami funkcjonalnymi. Jeśli wymagania funkcjonalne nie są precyzyjnie opisane, wykonawca może perfekcyjnie wywiązać się ze swoich formalnych zobowiązań, a mimo to system nie spełni oczekiwań klienta. 

W praktyce testy są często pomijane lub traktowane jako uciążliwy formalizm. W takiej sytuacji rzeczywiste testowanie ma miejsce po operacyjnym uruchomieniu systemu. Skutkiem jest bardzo bolesne wprowadzanie poprawek w trakcie pracy systemu, rezygnacja z części funkcjonalności, a w skrajnym przypadku ponowne uruchomienie. Modyfikacje wprowadzane na tak zaawansowanym etapie zazwyczaj są o wiele bardziej kosztowne niż rzetelne planowanie i testowanie rozwiązania. Testy należy zaplanować z wyprzedzeniem wystarczającym na wprowadzeniem poprawek. 

Karygodnym, choć zrozumiałym z marketingowego punktu widzenia błędem jest pomijanie analizy ryzyka. Ten element chyba najlepiej odróżnia amatorów od profesjonalistów. Dostawca usług albo nie rozumie potrzeby przeprowadzenia takiej analizy albo uznaje za „niepolityczne” informuje klienta o zagrożeniach. Mała skala niektórych projektów ERP nie jest żadnym usprawiedliwieniem. Realizując krótkie i powielarne projekty łatwiej jest skatalogować typowe zagrożenia i ocenić w jakim stopniu dotyczą każdego z kolejnych wdrożeń. 

Przygotowując agendę prezentacji należy zadbać o :

  1. Prezentację metodyki
  2. Przykładowy plan projektu lub harmonogram
  3. Przykładową analizę wdrożeniową

W trakcie realizacji wdrożenia połóż duży nacisk na:

  • Zgodność zakresu projektu z potrzebami użytkowników
  • Etap testów
  • Regularne monitorowanie ryzyka

 

 

Rate this blog entry:

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest środa, 22 listopad 2017

O nas

Jesteśmy grupą niezależnych konsultantów i twórców rozwiązań informatycznych w obszarze ERP, BI, CRM, BPMS i B2B.

Dane kontaktowe

Adres:
02-078 Warszawa,
Tel:
ul. Krzywickiego 2/1
Tel:
+(48) 22 666 97 71
Kom.:
+(48) 502 728 001
Kom.:
+(48) 604 586 470
E-Mail:
Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.
Website:
www.quereo.pl

Galeria

JoomShaper