Współpraca na linii Dostawca – Klient jako dźwignia
Transkrypt
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