Współpraca na linii Dostawca Klient jako dźwignia sukcesu projektów informatycznych. Doświadczenia zebrane podczas wdrożeń Oracle Hyperion

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. dariusz.satkowski@smartcon.pl

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 biznesowe z wykorzystaniem dostępnych na rynku narzędzi deweloperskich. Wdrożenia oparte na budowie modeli biznesowych z wykorzystaniem standardowych programów na przykład MS Excel. Wdrożenia oparte na dedykowanym oprogramowaniu przystosowanym do obsługi wybranych 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. 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 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, 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, 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. Zapobieganie niekontrolowanym zmianom 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) 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. Zalety podejścia adaptacyjnego (ang. agile) Bliska współpraca z klientem w trakcie definiowania wymagań, projektowania i budowy aplikacji Możliwość szybkiej reakcji na uwagi użytkowników 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 Analiza i potwierdzenie wymagań Projekt techniczny aplikacji Przygotowanie projektu infrastruktury technicznej oraz oprogramowania Implementacja koncepcji biznesowej w systemie Instalacja oprogramowania II. Implementacja Przygotowanie Instrukcji dla użytkowników i administratorów Testy dostawcy III. Testy i szkolenia Testy procesów Szkolenia Użytkowników merytorycznych Szkolenia administratorów IV. Wsparcie Świadczenie wsparcia w siedzibie klienta 2miesiące Przygotowanie dokumentacji projektowej Zarządzanie Projektem Przygotowanie Klienta do pracy w nowym systemie 4 miesiące 2miesiące Spotkanie uruchamiające projekt Odbiór Koncepcja rozwiązania Rundy weryfikacji aplikacji z klientem Aplikacja gotowa do Testów Odbiór 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 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. 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 Warsztaty narzędziowe dla członków zespołu ze strony Klienta Analiza wymagań biznesowych Analiza wymagań technicznych Lepsze zrozumienie procesu wdrożenia Lepsze zrozumienie między zespołami klienta a zespołem SmartCon Poznanie wymagań klienta w obszarze wdrożenia 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 Poznanie wymagań klienta w obszarze wdrożenia Określenie wymagań technicznych w obszarach: 1. Bezpieczeństwa oraz danych 2. Architektury logicznej/technicznej 3. Przepływów i integracji danych 4. Innych wymagań technicznych Użytkownicy biorący udział w analizie wymagań ze strony Klienta są zapoznani z możliwościami wdrażanych narzędzi Opis wymagań biznesowych Opis wymagań technicznych Rola SmartCon: przygotowanie i przeprowadzenie warsztatów Rola Klienta: Udział w warsztatach Rola SmartCon: Planowanie prac (spotkań), moderowanie spotkań, przygotowanie dokumentacji Rola klienta: Udział w spotkaniach, dostarczanie informacji, weryfikacja kompletności wymagań zawartych w produkcie Fazy Rola SmartCon: Planowanie prac (spotkań), moderowanie spotkań, Przygotowanie dokumentacji Rola klienta: Udział w spotkaniach, dostarczanie informacji, weryfikacja kompletności wymagań zawartych w produkcie Fazy 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 zawierająca: Weryfikację i uszczegółowienie wymagań dotyczących koncepcji i procedury biznesowej. Projekt infrastruktury technicznej (sprzętu i oprogramowania) dla uruchomienia 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 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, 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 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. 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 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 (monitorowaniu i kontroli pracy, monitorowaniu wydajności), Analizie i rozwiązywaniu błędów, strojeniu bazy danych oraz parametrów pracy, Monitorowaniu pracy, Usuwaniu powstałych błędów, Wprowadzaniu poprawek do, Asyście podczas procesu wprowadzania danych ich przetwarzania oraz generowania sprawozdań. 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 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 Zarządzanie zakresem Zarządzanie czasem Zarządzanie komunikacją i zespołem Zarządzanie ryzykiem Zarządzanie jakością Sprawdzone praktyki Ustalenie jasnych zasad zarządzania zmianami w projekcie oraz przestrzeganie ich przez strony projektu (tzw. procedura zarządzania zmianą, change request procedure). Ustalenie kryteriów odbioru prac w projekcie oraz 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. Utrzymywanie ramowego harmonogramu prac wraz z datami kamieni milowych, ale elastyczne harmonogramowanie prac i zadań w ramach etapów projektu Ustalenie i przestrzeganie reguły, że produkty prac, do których w ciągu określonej liczby dni Klient nie dośle uwag zostają zaakceptowane w formie jakiej zostały przekazane. Wprowadzenie spotkań statusowych zespołu projektowego oraz Komitetu Sterującego Dostawcy oraz Klienta w cyklu minimum dwutygodniowym. Wprowadzenie ko-lokacji, czyli przydzielenie zespołowi Dostawcy pokoju w ramach lokalizacji Klienta. 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. Prowadzenie przez Kierownika Projektu rejestru ryzyk, przegląd ryzyk i przygotowywanie planów zapobiegających ich wystąpieniu. Wprowadzenie spójnej notyfikacji w projekcie technicznym stosowanej przez Klienta i Dostawcę. Zapewnienie spójności w zarządzaniu środowiskami deweloperskim, testowym i produkcyjnym. Wpływ Ograniczanie tzw. pełzającego, rosnącego zakresu projektu, co negatywnie wpływa na terminowość prac Unikanie ciągłych zmian i potrzeby ciągłej aktualizacji harmonogramu Uniknięcie przedłużania się projektu z powodu opóźnień w dosyłaniu uwag Zapewnienie transparencji i wymiany informacji w prowadzeniu prac projektowych Ułatwienie współpracy pomiędzy Klientem oraz Dostawcą Antycypowanie i ograniczanie ryzyk związanych z prowadzeniem projektu Poprawa jakości oraz skrócenie czasu potrzebnego na prace programistyczne

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 Eksperci merytoryczni Procesy/ Raportowanie Zespół projektowy Dostawcy Ekspert merytoryczny Procesu Ekspert merytoryczny Raportowanie Wsparcie IT 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 konsultantom 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ę Invest- Profit oraz Mandarine Project Partners. Nasi konsultanci posiadają certyfikację Profesjonalnych Kierowników Projektów. Obecnie 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 sparametryzowanego 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 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 zarzą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