Współpraca na linii Dostawca – Klient jako dźwignia

XVII Konferencja PLOUG
Kościelisko
Październik 2011
Współpraca na linii Dostawca – Klient
jako dźwignia sukcesu projektów
informatycznych.
Doświadczenia zebrane podczas wdrożeń
Oracle Hyperion
Dariusz Satkowski
SmartCon Sp. z o.o.
[email protected]
Współpraca na linii Dostawca – Klient jako dźwignia sukcesu projektów informatycznych...
77
1. Zagrożenia dla wdrożeń zakończonych sukcesem
Wdrożenia systemów wspierających funkcje biznesowe w przedsiębiorstwach od zawsze wymagały odpowiedniego podejścia projektowego. Implementacje systemów w działach finansów, kontrolingu czy informowania kierownictwa polegają na dostosowaniu oprogramowania do wymagań
użytkowników i odbiorców informacji. Wymagania stawiane systemom w tych obszarach są bardzo
złożone, co więcej, są wypadkową obowiązujących przepisów (Ustawa o Rachunkowości), standardów (Międzynarodowe Standardy Sprawozdawczości Finansowej), branży, specyfiki danej firmy,
kultury korporacyjnej czy wręcz przyzwyczajeń użytkowników wpisujących się w procesy biznesowe.
Wyróżniamy 3 typy wdrażanych systemów (pomijamy systemy stanowiące połączenie dwóch
lub trzech typów:
• Wdrożenia typu ‘custom’ polegające na tworzeniu programu wspierającego funkcje bizneso-
we z wykorzystaniem dostępnych na rynku narzędzi deweloperskich.
• Wdrożenia oparte na budowie modeli biznesowych z wykorzystaniem standardowych pro-
gramów na przykład MS Excel.
• Wdrożenia oparte na dedykowanym oprogramowaniu przystosowanym do obsługi wybra-
nych obszarów biznesowych.
Firma SmartCon w swojej działalności skupiona jest na implementacji systemów dedykowanych: opartych na rozwiązaniach pakietu Oracle Hyperion oraz aplikacji smartKonsolidacja będącej
produktem zbudowanym od podstaw przez zespół programistów SmartCon. Typowym podejściem
do projektów wdrożeniowych rozwiązań ‘z pudełka’ jest model kaskadowy. Podejście do projektu
w modelu kaskadowym jest sztywne, ale przejrzyste i schematyczne. Jego niewątpliwą zaletą jest
możliwość określenia zakresu projektu przed jego rozpoczęciem, a co za tym idzie wyceny projektu
już na etapie sprzedaży.
Z doświadczeń firm zajmujących się wdrożeniami systemów opartych na dedykowanym oprogramowaniu, niezależnie od producenta, wynika jednak, że istnieje szereg zagrożeń dla pełnego
sukcesu implementacji przy zastosowaniu metodyki kaskadowej:
• Złe lub niepełne określenie wymagań użytkowników przed wdrożeniem: wynika zazwyczaj
ze złego zrozumienia Klienta i Dostawcy podczas fazy sprzedaży i specyfikacji istotnych warunków zamówienia. Ze względu na ograniczony czas i możliwości przed rozpoczęciem projektu nie jest przeprowadzana pełna analiza wymagań użytkowników.
• Rozbieżności między oczekiwanymi funkcjami a tymi oferowanymi przez wdrażany system:
oprogramowanie dedykowane do obsługi procesów biznesowych w określonym obszarze budowane jest zgodnie z zasadą oceny istotności wymagań funkcjonalnych potencjalnych użytkowników. Nie istnieje zestaw funkcjonalności aplikacji do konsolidacji sprawozdań finansowych lub planowania i budżetowania pokrywający w pełni wymagania użytkowników we
wszystkich przedsiębiorstwach działających na rynku. W związku z tym producenci oprogramowania wybierają zestaw funkcjonalności, które zostaną zaimplementowane w oprogramowaniu, pozostawiając miejsce na funkcjonalności realizowane przez tak zwane ‘obejścia’ (ang. ‘work around’).
• Zmiany i modyfikacje wymagań: projekty wdrożeniowe to procesy trwające często wiele
miesięcy. W tym czasie zmienia się otoczenie projektowe i wymagania zdefiniowane w początkowej fazie projektu mogą stać się nieaktualne.
Odpowiedzią na wyżej wymienione zagrożenia mogło by być bardziej dynamiczne i umożliwiające efektywne wdrażanie systemów informatycznych podejście ‘agile’. Przeszkodą są tutaj względy rynkowe i finansowe polegające na braku gotowości klientów na wdrożenia bez określonego
78
Dariusz Satkowski
wcześniej, sztywnego budżetu. W związku z tym firma SmartCon opracowała podejście łączące
zalety obu metodyk i przynoszące satysfakcjonujące efekty.
Metoda ‘agile’ polega na częstych etapach weryfikacji wymagań i założeń do projektu, co wiąże
się ze sprawdzeniem, czy dany etap spełnia oczekiwania Klienta co do systemu. Z drugiej strony
metoda wymusza aktywny udział klienta w weryfikacji i budowie, dzięki czemu poprawia się komunikacja pomiędzy Klientem a Dostawcą. Zaletą podejścia łączącego obie metodyki jest utrzymanie swoistego porządku w harmonogramie projektu. Wyraźny jego podział na etapy, które pozwalają na przedstawienie przejrzystego planu działania Klientowi. Z drugiej zaś strony po zakończeniu
każdego etapu przeprowadzana jest sesja spotkań z Klientem, mających na celu weryfikację dotychczasowych postępów w pracach. Pozwala to na weryfikację zarówno przez Klienta, jak i Dostawcę założeń do systemu w dosyć wczesnym etapie prac, a nie tak jak w przypadku zwykłego
podejścia kaskadowego dopiero w etapie Testowania. Takie podejście ma za zadanie wdrożenie
systemu, który będzie w jak największym stopniu odpowiadał i pasował do specyfiki Klienta.
Umożliwia to uniknięcia podstawowych błędów koncepcyjnych wynikających ze strony Klienta
z niezrozumienia systemu, zaś Dostawcy – potrzeb Klienta. Ma też pozwolić na uniknięcie ewentualnych konfliktów pomiędzy Dostawcą, a Klientem na etapie oddawania projektu.
W kolejnych rozdziałach opisane zostały elementy podejścia łączącego metodykę kaskadowego
prowadzenia projektów z metodą ‘agile’ na przykładzie wdrożeń oprogramowania Oracle Hyperion.
Firma SmartCon prowadziła i z sukcesem zakończyła wdrożenia Oracle Hyperion w obszarach
sprawozdawczości finansowej, kontrolingu i raportowania.
2. Podejście do wdrożenia
Z doświadczeń projektowych zespołu SmartCon oraz opinii naszych klientów związanych
z wdrażaniem aplikacji wspierających zarządzanie efektywnością przedsiębiorstwa wynika, że
główne czynniki sukcesu projektów wdrożeń produktów klasy Oracle Hyperion to przede wszystkim:
• Współpraca zespołu projektowego Klienta z zespołem Dostawcy rozwiązania.
• Precyzyjne określenie wymagań dla systemu.
• Zapobieganie niekontrolowanym zmianom systemu będących poza zakresem projektu oraz
dążenie do upraszczania istniejących procesów.
W związku z tymi postulatami nasza metodyka wdrożenia łączy zalety wynikające z klasycznego modelu fazowego realizacji projektów (ang. waterfall) oraz metodyk tzw. adaptacyjnych realizacji projektu (ang. agile).
Tabela 1. Porównanie metodyk
Zalety podejścia fazowego
(ang. waterfall)
Zalety podejścia adaptacyjnego
(ang. agile)
• Zapewnienie przejrzystej struktury projektu oraz harmonogramu
• Dostarczenie punktów kontrolnych dla
realizacji prac w projekcie
• Precyzyjne określenie produktów prac
projektu (wyników) oraz warunków ich
odbioru.
• Bliska współpraca z klientem w trakcie
definiowania wymagań, projektowania
i budowy aplikacji
• Możliwość szybkiej reakcji na uwagi
użytkowników systemu
• Zaangażowanie odbiorców produktów
prac w powstawanie aplikacji już
w pierwszej fazie projektu
• Skrócenie czasu potrzebnego na testy akceptacyjne aplikacji
Współpraca na linii Dostawca – Klient jako dźwignia sukcesu projektów informatycznych...
79
W opracowaniu podejścia do wdrożenia wykorzystujemy przede wszystkim:
• Nasze doświadczenia i sprawdzone praktyki ze zrealizowanych projektów wraz z sugestiami
naszych klientów.
• Standardy zarządzania projektami, w tym metodykę PMBoK ‘Project Management Body of
Knowledge’ Project Management Institute oraz brytyjską metodykę Prince2, Organization of
Government Commerce.
• Zasady zarządzania projektami pochodzące z podejść adaptacyjnych, w tym metodyki
SCRUM.
3. Główne etapy wdrożenia
Poniższy wykres pokazuje podejście SmartCon do realizacji projektu, w którym zawarte zostały
typowe zadania procesu implementacji Oracle Hyperion:
I. Analiza i
Projekt
II. Implementacja
Analiza i
potwierdzenie
wymagań
III. Testy i
IV.
szkolenia Wsparcie
Przygotowanie Instrukcji dla
użytkowników i administratorów
Projekt
techniczny
aplikacji
Implementacja koncepcji
biznesowej w systemie
Przygotowanie
projektu infrastruktury
technicznej oraz
oprogramowania
Testy
procesów
Szkolenia
Użytkowników
merytorycznych
Testy
dostawcy
Instalacja
oprogramowania
Świadczenie
wsparcia
w siedzibie
klienta
Szkolenia
administratorów
Przygotowanie dokumentacji projektowej
Zarządzanie Projektem
Przygotowanie Klienta do pracy w nowym systemie
2 miesiące
Spotkanie
uruchamiające
projekt
4 miesiące
Odbiór
‘Koncepcja
rozwiązania’
‘Rundy weryfikacji
aplikacji z klientem’
2 miesiące
Aplikacja
gotowa
do Testów
Odbiór
systemu
Rys. 1. Fazy projektu wdrożeniowego
Faza I. Analiza i projekt
Prace w tej fazie projektu obejmą weryfikację, ocenę oraz wskazanie ewentualnych zmian do
koncepcji i procedur biznesowych dla potrzeb Klienta pod kątem wymagań wdrażanego systemu
oraz projektowanie infrastruktury technicznej oraz sposobu implementacji wymagań w systemie.
Potwierdzenie wymagań klienta oraz zbieranie informacji potrzebnych do opracowania projektu
technicznego oraz projektu aplikacji odbywa się w formie cyklu ustrukturyzowanych spotkań
z zespołem Klienta.
W początkowym etapie analizy wymagań odbywają się warsztaty narzędziowe dla przedstawicieli Klienta odpowiedzialnych za uzgadnianie wymagań dotyczących systemu. Warsztaty zapewniają lepsze zrozumienie między zespołami Klienta oraz Dostawcy oraz pozwalają na lepsze określenie priorytetów wymagań.
80
Dariusz Satkowski
Tabela 2. Kroki fazy analizy
Nazwy kolejnych
kroków w ramach
Fazy
Cele poszczególnych
kroków
Rezultaty
Sposób pracy
Lepsze zrozumienie
procesu wdrożenia
Lepsze zrozumienie
między zespołami
klienta a zespołem
SmartCon
Użytkownicy biorący
udział w analizie wymagań ze strony
Klienta są zapoznani
z możliwościami
wdrażanych narzędzi
Rola SmartCon: przygotowanie i przeprowadzenie warsztatów
Rola Klienta: Udział
w warsztatach
Analiza wymagań
biznesowych
Poznanie wymagań klien- Opis wymagań bizneta w obszarze wdrożenia sowych systemu
systemu
Określenie wymagań biznesowych w zakresie:
1. Realizowanych procesów
2. Funkcjonalności biznesowych
3. Obszarów danych
4. Formularzy wprowadzania danych
5. Raportowania
6. Wymagań szczegółowych
7. Wymagań specyficznych grup użytkowników systemu
Rola SmartCon:
Planowanie prac (spotkań), moderowanie
spotkań, przygotowanie dokumentacji
Rola klienta:
Udział w spotkaniach,
dostarczanie informacji, weryfikacja kompletności wymagań
zawartych w produkcie Fazy
Analiza wymagań
technicznych
Poznanie wymagań klien- Opis wymagań techta w obszarze wdrożenia nicznych systemu
systemu
Określenie wymagań
technicznych w obszarach:
1. Bezpieczeństwa systemu oraz danych
2. Architektury logicznej/technicznej systemu
3. Przepływów i integracji
danych
4. Innych wymagań technicznych
Rola SmartCon: Planowanie prac (spotkań), moderowanie
spotkań, Przygotowanie dokumentacji
Rola klienta: Udział
w spotkaniach, dostarczanie informacji,
weryfikacja kompletności wymagań zawartych w produkcie
Fazy
Warsztaty narzędzio- •
we dla członków zespołu ze strony Klien- •
ta
Z punktu widzenia zarządzania projektem istotnym elementem tego etapu jest powołanie zespołu
wdrożeniowego u Klienta z wyróżnieniem funkcji Kierownika Projektu, Sponsora projektu oraz
administratora merytorycznego i technicznego aplikacji. Zorganizowanie spotkania uruchamiającego projekt oraz opracowanie harmonogramu projektu i określenie zasad zarządzania projektem.
Współpraca na linii Dostawca – Klient jako dźwignia sukcesu projektów informatycznych...
81
Produktem prac tego etapu jest dokumentacja „Koncepcja rozwiązania dla systemu” zawierająca:
• Weryfikację i uszczegółowienie wymagań dotyczących koncepcji i procedury biznesowej.
• Projekt infrastruktury technicznej (sprzętu i oprogramowania) dla uruchomienia systemu
Oracle Hyperion.
• Projekt aplikacji Oracle Hyperion z uwzględnieniem sposobu, w jaki wymagania biznesowe
do aplikacji zostaną odzwierciedlone w systemie.
Faza II. Implementacja rozwiązania
W fazie implementacji rozwiązania zespół Dostawcy wdraża założenia koncepcji rozwiązania
zaakceptowanej w pierwszej fazie projektu. Prace fazy implementacji odbywają się według podejścia adaptacyjnego i obejmują tzw. rundy weryfikacji aplikacji z Klientem. Oznacza to, że Klient
może w cyklach dwutygodniowych zgłaszać uwagi przekazanego fragmentu aplikacji. Pozwala to
na uczestniczenie Klienta w procesie budowy aplikacji już na wczesnym etapie projektu oraz akceptację produktów pośrednich prac.
Dla zapewnienia możliwości iteracyjnego podejście do budowy na wstępie fazy II rekomendowane jest szkolenie z obsługi aplikacji dla zespołu wdrożeniowego Klienta oraz utworzenie instancji szkoleniowej, gdzie zespół Klienta będzie miał możliwość pracy z aplikacją i identyfikacji ewentualnych błędów w jej działaniu. Pod koniec fazy budowy przed oddaniem aplikacji testowej odbywają się testy wewnętrzne Dostawcy, sprawdzające po raz kolejny poprawność działania aplikacji.
Ponadto, równolegle przygotowywane są instrukcje dla użytkowników merytorycznych aplikacji
oraz instrukcje dla administratorów.
Z udziałem Klienta, powstają scenariusze testowe weryfikujące poprawność działania aplikacji i
sprawdzające funkcjonalność określoną zakresem projektu.
Produktem prac tej fazy są:
• Skonfigurowane według założeń Koncepcji rozwiązania (etap I) aplikacja Oracle Hyperion
dostosowana do wymogów biznesowych Klienta określonych w zakresie umowy.
• Instrukcje dla użytkowników oraz dokumentacja techniczna systemu dla administratorów
(materiały te są aktualizowane po przeprowadzeniu testów oraz szkoleń).
Faza III. Testy i szkolenia
W ramach skontrolowania poprawności aplikacji na danych historycznych wykonywane są testy
sprawdzające poprawność działania fragmentów aplikacji zgodnie z zaakceptowaną koncepcją rozwiązania (faza I). Dla przygotowania testów konieczne będzie zasilenie danych do aplikacji.
W ramach testów sprawdzona jest poprawność działania funkcjonalności będących w zakresie projektu (określonego szczegółowo w Fazie I wdrożenia):
Błędy znalezione w aplikacji w procesie testów, przekazywane są do poprawy w zespole Dostawcy oraz ponownie testowane. Zakładamy, że w wyniku podejścia iteracyjnego do realizacji
projektu, na etapie testów większość uwag Klienta jest już uwzględniona. Pozwala to na otrzymanie
dobrej jakości aplikacji oraz skrócenie czasu potrzebnego na przeprowadzenie testów akceptacyjnych.
W trakcie III fazy wdrożenia odbywają się również szkolenia użytkowników aplikacji oraz administratorów.
82
Dariusz Satkowski
Produktem prac tej fazy są:
• Przetestowana i formalnie odebrana przez Klienta aplikacja Oracle Hyperion odpowiadająca
potrzebom biznesowym Klienta określonym w zakresie umowy wdrożeniowej i doprecyzowanym w koncepcji rozwiązania (Faza I).
• Zestaw dokumentacji do systemu, czyli dokumentacja użytkownika aplikacji (dostosowany
materiał szkoleniowy) oraz administratora technicznego.
• Przeszkolony w aplikacji Oracle Hyperion zespół użytkowników i administratorów z zespołu
Klienta.
Etap IV. Wsparcie produkcyjne systemu
Większość zapytań dotyczących wdrożeń systemów klasy EPM (ang. Enterprise Performance
Management, pol. Zarządzanie Efektywnością Przedsiębiorstwa) obejmuje wsparcie produkcyjne
systemu. Rozwiązania pakietu Oracle Hyperion obsługują procesy biznesowe związane z raportowaniem, planowaniem i strategią przedsiębiorstwa. Procesy te są ograniczone wymaganiami czasowymi nie tylko wewnętrznymi ale również nałożonymi przez zewnętrznych regulatorów: Giełdę
Papierów Wartościowych, banki czy instytucje regulujące poszczególne rynki. Wsparcie produkcyjne wdrożonych systemów obejmuje zwykle pomoc dla użytkowników w pierwszych cyklach
procesów mającą na celu zapewnienie terminowości i płynności działania.
Wsparcie produkcyjne systemu oferowane jest przez zespół Dostawcy w zakresie określonym
w wymaganiach Klienta. Zazwyczaj są to konsultacje w siedzibie Klienta w dni robocze w godzinach pracy. W ciągu pierwszych miesięcy po zakończeniu wdrożenia usługi polegają na:
• Administrowaniu systemu (monitorowaniu i kontroli pracy systemu, monitorowaniu wydaj-
ności),
• Analizie i rozwiązywaniu błędów, strojeniu bazy danych oraz parametrów pracy systemu,
• Monitorowaniu pracy systemu,
• Usuwaniu powstałych błędów,
• Wprowadzaniu poprawek do systemu,
• Asyście podczas procesu wprowadzania danych ich przetwarzania oraz generowania spra-
wozdań.
Usługi związane z rozwojem nowych funkcjonalności przekazanej do produkcji aplikacji objęte
są procedurą zgłaszania wniosków o zmianę.
Dodatkowo, przez cały czas trwania wsparcia, realizowane są 3 zadania:
1. Opracowanie dokumentacji projektowej – powstaje ona iteracyjnie w cyklu trwania projektu
i jest sukcesywnie uzupełniania wraz z rozwojem aplikacji.
2. Przygotowanie zespołu Klienta do pracy w nowym systemie – wdrożenie nowego systemu informatycznego zawsze wiąże się ze zmianą w organizacji. Aby przystosować zespół do pracy
w nowym systemie potrzebne są działania ukierunkowane na płynne przejście przez tą zmianę.
Należy do nich informowanie zespołu o korzyściach nowego rozwiązania, przypisywanie kompetentnych pracowników do realizacji projektu i uczynienie z nich tzw. agentów zmian. Istotne
są w procesie wdrażania zmian są szkolenia oraz zapewnienie pracownikom czasu na pracę
w nowym systemie raportowym oraz regularne komunikowanie o postępach prac w projekcie.
Takie działania zapewnią większe zaangażowanie zespołu projektowego w prace projektowe
oraz lepszą akceptację zespołu dla nowego rozwiązania.
3. Zarządzanie projektem wdrożenia i zespołem wsparcia.
Współpraca na linii Dostawca – Klient jako dźwignia sukcesu projektów informatycznych...
83
4. Zasady zarządzania projektem
Poniższa tabela podsumowuje obszary zarządzania projektem wybrane z metodyki Project Management Institute (PMI), oraz działania w tych obszarach, które mogą znacząco przyczynić się do
sprawności realizowanego projektu:
Tabela 3. Sprawdzone praktyki zarządzania projektami
Obszar
projektu
Sprawdzone praktyki
Wpływ
Zarządzanie
zakresem
• Ustalenie jasnych zasad zarządzania zmianami
Zarządzanie
czasem
• Utrzymywanie ramowego harmonogramu prac wraz
• Unikanie
Zarządzanie
komunikacją
i zespołem
• Wprowadzenie spotkań statusowych zespołu projek-
• Zapewnienie
Zarządzanie
ryzykiem
• Prowadzenie przez Kierownika Projektu rejestru
• Antycypowanie i ogra-
ryzyk, przegląd ryzyk i przygotowywanie planów
zapobiegających ich wystąpieniu.
niczanie ryzyk związanych z prowadzeniem
projektu
Zarządzanie
jakością
• Wprowadzenie spójnej notyfikacji w projekcie tech-
• Poprawa jakości oraz
nicznym stosowanej przez Klienta i Dostawcę.
• Zapewnienie spójności w zarządzaniu środowiskami
deweloperskim, testowym i produkcyjnym.
skrócenie czasu potrzebnego na prace programistyczne
Ograniczanie tzw. pełzaw projekcie oraz przestrzeganie ich przez strony jącego, rosnącego zakresu
projektu (tzw. procedura zarządzania zmianą, chan- projektu, co negatywnie
ge request procedure).
wpływa na terminowość
• Ustalenie kryteriów odbioru prac w projekcie oraz prac
formalne odbiory prac przez Klienta po każdej fazie
projektu.
• Wprowadzenia zasady, że istotne dla budowy rozwiązania ustalenia ze spotkań powinny być zapisywane i zatwierdzane jako obowiązujące w projekcie,
a notatki ze spotkań przesyłane do uczestników spotkania.
ciągłych
z datami kamieni milowych, ale elastyczne harmozmian i potrzeby ciągłej
nogramowanie prac i zadań w ramach etapów proaktualizacji harmonojektu
gramu
• Ustalenie i przestrzeganie reguły, że produkty prac, • Uniknięcie przedłużado których w ciągu określonej liczby dni Klient nie
nia się projektu z podośle uwag zostają zaakceptowane w formie jakiej
wodu opóźnień w dosyzostały przekazane.
łaniu uwag
transpatowego oraz Komitetu Sterującego Dostawcy oraz
rencji i wymiany inKlienta w cyklu minimum dwutygodniowym.
formacji w prowadzeniu prac projektowych
• Wprowadzenie ko-lokacji, czyli przydzielenie zespołowi Dostawcy pokoju w ramach lokalizacji • Ułatwienie współpracy
pomiędzy
Klientem
Klienta.
oraz Dostawcą
• Ustanowienie po stronie Klienta grupy tzw. ‘super
użytkowników’ lub administratora merytorycznego
odpowiedzialnego za ustalanie i potwierdzanie założeń do budowy aplikacji.
• Wdrożenie procesu gromadzenia i eskalacji kwestii
otwartych w projekcie do poziomu Komitetu Sterującego, który w cyklu dwutygodniowym podejmuje
decyzje istotne dla prowadzenia prac w projekcie.
84
Dariusz Satkowski
Poniższy rysunek przedstawia proponowaną strukturę organizacyjną projektu:
Komitet Sterujący Projektu
(Sponsor projektu, Kierownik Projektu, Kierownik Projektu Dostawcy)
Kierownictwo Projektu
Kierownik Projektu, Kierownik Projektu
Dostawcy
Zespół projektowy Klienta
Zespół projektowy Dostawcy
Ekspert merytoryczny
Procesu
Eksperci merytoryczni
Procesy/
Raportowanie
Wsparcie IT
Ekspert merytoryczny
Raportowanie
Ekspert techniczny
Architekt rozwiązania
Wdrożeniowcy Oracle
Hyperion
Rys. 2. Struktura organizacyjna projektu.
5. Wyróżniki podejścia wdrożeniowego SmartCon
Na jakość naszego podejścia do realizacji projektu, poza zastosowaniem opisanej wyżej metodyki łączącej podejście kaskadowe i ‘agile’ wpływają następujące elementy:
• Posiadamy w firmie SmartCon bazę wiedzy w aplikacji Mantis, która pozwala naszym kon-
sultantom na szybkie znalezienie rozwiązania problemów technicznych, które pojawiały się
na poprzednich projektach. Dotyczy to również szablonów projektowych i formatek wspierających zarządzanie projektem.
• Nasi konsultanci są przeszkoleni w metodyce realizacji projektów w ramach programu
szkolenia obejmującego wszystkie aspekty realizacji projektów: począwszy od definiowania
zakresu projektu, poprzez harmonogramowanie, zarządzanie ryzykami projektu, komunikację
oraz techniki adaptacyjne pracy na projekcie. Szkolenia realizowane były przez firmę InvestProfit oraz Mandarine Project Partners.
• Nasi konsultanci posiadają certyfikację Profesjonalnych Kierowników Projektów. Obec-
nie posiadamy w zespole 2 certyfikaty, poświadczone zdanym egzaminem Project Management Professional.
• Nasi konsultanci to eksperci w obszarze finansów i zagadnień związanych z konsolidacją
sprawozdań finansowych. 3 konsultanci mają zdany egzamin ACCA, poświadczający szeroką
wiedzę z zakresu zagadnień finansowych przedsiębiorstwa.
Współpraca na linii Dostawca – Klient jako dźwignia sukcesu projektów informatycznych...
85
6. Podsumowanie
Odejście od stosowanego powszechnie podejścia do wdrożeń systemów dedykowanych do zarządzania efektywnością przedsiębiorstwa, mimo trudności polegających głównie na przekonaniu
Klienta do zmian w metodyce i obsłużenia ryzyka związanego z wyceną projektu, okazało się korzystne z kilku powodów istotnych zarówno dla Dostawcy jak i Klienta:
• Zaprezentowane podejście projektowe pozwala uniknąć długich i kosztownych zmian do spa-
rametryzowanego systemu na etapie testów rozwiązania lub po jego uruchomieniu produktywnym.
• Rundy weryfikacji aplikacji z Klientem wymuszają większe zaangażowanie kluczowych
użytkowników wdrażanej aplikacji co pozwala na płynne jej przejęcie na etapie wdrożenia
produktywnego przez pracowników Klienta.
• Weryfikacja wdrażanych funkcjonalności zapewnia poczucie własności implementowanego
systemu u jego odbiorców.
• Podejście mieszane pozwala uniknąć sytuacji, kiedy wdrożony system działa inaczej niż
oczekiwali tego użytkownicy a zakończona jest już faza implementacji rozwiązania.
• Weryfikacja oczekiwań Klienta z możliwościami oprogramowania pomaga negocjować i za-
rządzać wymaganiami użytkownika.
Na podstawie naszych wieloletnich doświadczeń z opisywanym podejściem do projektów wdrożeniowych zachęcamy wszystkich Dostawców oferujących usługi wdrożeniowe produktów klasy
EPM do zaimplementowania metodyki mieszanej. W przypadku jakichkolwiek pytań lub propozycji współpracy zachęcamy również do kontaktu z przedstawicielami firmy SmartCon.
Bibliografia
[RWW70]
Royce, W.W., Managing the Development of Large Software, 1970
[PMI2010]
Project Management Body of Knowledge, Project Management Institute