docWspółpraca Dostawca Klient jako czynnik sukcesu projektów
download 
Reklamacja Transkrypt
Współpraca Dostawca Klient jako czynnik sukcesu projektów
XVII Konferencja PLOUG Kościelisko Październik 2011 Współpraca Dostawca Klient jako czynnik sukcesu projektów informatycznych – kilka refleksji z projektów wdrożeń systemów klasy EPM (Oracle Hyperion) Ewa Sońta-Drączkowska SmartCon Sp. z.o.o. [email protected] Abstrakt. W artykule przedyskutowane będą problemy związane z realizacją projektów informatycznych ze szczególnym uwzględnieniem specyfiki wdrożeń systemów BI EPM (Enterprise Performance Management). Projekty będące przedmiotem opracowania realizowane są z udziałem zewnętrznego Dostawcy (integratora rozwiązania) w związku z tym gro problemów rodzi się właśnie na styku Dostawca Klient. Przyczyny źródłowe potencjalnych konfliktów między Dostawcą a Klientem to: asymetria informacji pomiędzy stronami transakcji oraz wysoka specyfika inwestycji jaką jest wdrożenie systemu informatycznego. Te warunki są właściwie normą we wszystkich projektach wdrożeń systemów i nie pozostaje nic innego jak być świadomym wynikających z nich zagrożeń i umieć moderować możliwe ryzyka pojawiające się zarówno przed jaki i po podpisaniu Umowy wdrożeniowej. Autorka dyskutuje źródła oraz typy ryzyk zachowaniowych obu stron transakcji jak również mechanizmy zabezpieczające i łagodzące problemy wynikające z tych ryzyk. Oprócz mechanizmów stosowanych w procedurach przetargowych i Umowach wdrożeniowych nie do przecenienia są takie kwestie jak: reputacja Dostawcy, doświadczenia ze zrealizowanych wdrożeń oraz zaufanie pomiędzy partnerami transakcji. Współpraca Dostawca Klient jako czynnik sukcesu projektów... 89 1. ‘Smutna’ rzeczywistość projektów informatycznych Doświadczenia praktyczne i badania dotyczące realizacji projektów informatycznych skłaniają do refleksji po pierwsze nad sensem biznesowym inicjowanych projektów, a po drugie nad skutecznością metodyk wspierających zarządzanie projektami. Dla porządku, na wstępie, należałoby przytoczyć definicję projektu oraz parametry pozwalające ocenić, czy jest on zrealizowany z sukcesem, czy też nie: ‘Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu lub dostarczenia unikalnej usługi’1. Udany projekt powinien spełniać parametry sukcesu takie jak: zrealizowany cel (zakres), zakończenie w określonym czasie oraz w ramach zaplanowanego budżetu. Niektórzy, co bardziej wybredni, dodają do tej listy jeszcze kryterium spełnienia określonych wymagań jakościowych dla produktów prac projektu, co jest ściśle powiązane z satysfakcją odbiorcy prac (klienta). Satysfakcja klienta JAKOŚĆ Zasoby Zakres Niektórzy mówią: „szybko, tanio, dobrze – WYBIERZ DWA!” Rysunek 1: Parametry sukcesu projektu Źródło: opracowanie własne na postawie: PMBoK, Fourth Edition, PMI, 2008, s. 5. Badania prowadzone corocznie przez często cytowaną amerykańską organizację Standish Group, tzw. ‘Chaos Report’2 dają wiele do myślenia. Warto zacytować klika statystyk, gdyż badania te koncentrują się na realizacji projektów informatycznych (a w szczególności projektów rozwoju oprogramowania), a respondenci biorący udział w badaniu to menedżerowie obszarów zarządzania informatyką. Generalnie, statystyki podsumowujące wywiady są alarmujące: • Projekty przekraczają budżet o średnio 189% • Projekty przedłużają się średnio o 222% w porównaniu z założonymi ramami czasowymi • Projekty spełniają cele/ zakres średnio tylko w 60%. Dane syntetyczne pokazują, że średnio tylko 16% projektów kończy się w ramach planowanych parametrów, ok. 13% to projekty zagrożone co najmniej w realizacji jednego parametru, a 32% kończy się całkowitą porażką, to znaczy zostaje zamknięte przed ich ukończeniem. 1 2 Project Management Body of Knowledge (PMBoK), Fourth Edition, PMI, 2008, s. 5. Źródło: Standish Group, Chaos Report, 2005. 90 Ewa Sońta-Drączkowska 2. Specyfika projektów wdrożeń systemów klasy BI Być może rzeczywistość projektów wdrożeń gotowych aplikacji na zlecenie klienta, nie wygląda aż tak drastycznie jak w przypadku rozwoju nowych aplikacji. Projektom integracji istniejącego oprogramowania towarzyszy z reguły mniejsze ryzyko technologiczne z uwagi gotową już aplikację. Niemniej w dalszym ciągu przedsięwzięciom wdrożeniowym towarzyszy konieczność przeprowadzania kastomizacji i dostosowań do wymogów klienta. W praktyce równie często można obserwować problemy i opóźnienia związane z dotrzymaniem parametrów sukcesu projektów wdrożeń systemów wspomagających zarządzanie przedsiębiorstwem. Aby określić cechy charakterystyczne projektów wdrożeń systemów klasy Business Intelligence, w pierwszym kroku konieczne jest zdefiniowanie, co dokładnie rozumiemy mając na myśli dziedzinę wiedzy jaką jest Business Intelligence. Nie ma jedynej i powszechnie obowiązującej definicji pojęcia Business Intelligence. W tym referacie zastosowana będzie definicja Gartner Group3: Business Intelligence jest definiowane jako zorientowany na użytkownika proces zbierania, eksploracji, interpretacji i analizy danych, który prowadzi do usprawniania i zracjonalizowania procesu podejmowania decyzji. Systemy klasy BI wspierają kadrę menedżerską w podejmowaniu decyzji biznesowych w celu tworzenia wartości przedsiębiorstwa. Projekty wdrożeń systemów klasy BI mają za zadanie zamieniać dane w informacje, wiedzę i plany, które prowadzą do podejmowania korzystnych decyzji biznesowych.4 Systemy klasy Business Intelligence obejmują następujące obszary technologiczne: 1. Narzędzia OLAP (ang. on-line analitycal processing) – czyli oprogramowanie umożliwiające analizę wielowymiarowych danych biznesowych, poprzez integrację, agregację oraz odpowiedni sposób prezentacji/wizualizacji różnego rodzaju danych. 2. Narzędzia eksploracji danych – algorytmy do automatycznej analizy dużych wolumenów danych, wykorzystujące metody statystyczne i ekonometryczne, a także metody maszynowego uczenia się, umożliwiające analizę danych o charakterze nie tylko ilościowym, ale również jakościowym. 3. Narzędzia zarządzania wiedzą – umożliwiające składowanie, indeksowanie i analizę dokumentów tekstowych oraz powiązanie ich z innymi danymi. Systemy zarządzania efektywnością firmy (ang. Enterprise Performance Management), typu Oracle Hyperion Financial Management, czy Oracle Hyperion Planning należy umiejscowić w pierwszym z wyżej wymienionych obszarów. Oprócz firmy Oracle podobne rozwiązania oferują firmy konkurencyjne takie jak: IBM, Microsoft, SAP oraz inni, mniej znani dostawcy. Poniżej znajduje się przykładowa architektura rozwiązania Business Intelligence obejmująca takie elementy jak: systemy źródłowe, mechanizmy ETL (czyli ekstrakcji, transformacji i ładowania danych), hurtownię danych oraz aplikacje BI. 3 4 Cytowane za: J. Surma, Business Intelligence – systemy wspomagania decyzji biznesowych, Wydawnictwo Naukowe PWN SA, Warszawa 2009, s. 13. TDWI Report Series, Evaluating ETL and Data Integration Platforms, 101communications, United States of America 2003, s. 2. Współpraca Dostawca Klient jako czynnik sukcesu projektów... 91 Rysunek 2: Przykład architektury hurtowni danych Źródło: K. Ośródka, Business Intelligence i hurtownie danych, nieopublikowana praca magisterska, Warszawa, 2008. Jeśli chodzi o projekty wdrożeń systemów w obszarze BI, to mają one kilka cech, które należy uwzględnić w planowaniu, ustanowieniu i wdrożeniu projektu tego typu w organizacji. • Złożony i obejmujący całą organizację zakres prac. W projektowaniu rozwiązania BI uwzględnić należy strategię organizacji, jej cele biznesowe oraz mierniki realizacji tych celów. W związku z tym rozwój rozwiązania BI powinien być pochodną strategii przedsiębiorstwa oraz mierników napędzających wartość organizacji. Z reguły więc realizacja takiego przedsięwzięcia to nie tylko technologia ale kompleksowy program zmiany w organizacji mający duży wpływ na zasady prowadzenia biznesu. • Konieczność zakwestionowania status quo w organizacji. W projektach wdrożeń systemów BI, trudne jest określenie rzeczywistych potrzeb raportowych, gdyż to oznacza niejednokrotnie kwestionowanie sensu i celu dotychczasowego sposobu raportowania w szczególności jeśli chodzi o raportowanie zarządcze. Oczekiwanie Klienta często sprowadza się do stwierdzenia: ‘Tak to robimy obecnie i chcielibyśmy mieć w nowym rozwiązaniu takie same raporty’. Inicjowanie projektów BI, bez uprzedniej weryfikacji autentycznych i aktualnych potrzeb biznesowych, nie wnosi do organizacji spodziewanej wartości. Kwestionowanie status quo z reguły napotyka duży opór przed zmianą. • ‘Przyrostowy’ charakter prac w projekcie. Z reguły realizacja wszystkich założeń biznesowych w ramach jednego projektu jest niemożliwa, w związku z tym rozwiązania BI projektuje się fazowo, obejmując coraz to szersze zakresy potrzeb biznesowych. Należy więc określić priorytety prac oraz być przygotowanym na ciągły rozwój i doskonalenie systemu BI w organizacji. Projekty takie mają z reguły charakter długofalowy. • Konieczność utrzymywania rozwiązania w perspektywie długoterminowej. Po zaprojektowaniu i wdrożeniu architektury systemu BI, należy być świadomym, że każdorazowe zmiany w systemach źródłowych lub / i aplikacjach BI powodują konieczność aktualizacji w hurtowni danych pod kątem dostosowania struktur danych do zaistniałych zmian. Organizacja musi więc wykształcić wewnętrzny zespół, który będzie posiadał kompetencje w zakresie utrzymania rozwiązania. • Duży nakład prac związany z integracją źródeł danych. W przypadku organizacji złożonych, posiadających wiele systemów informatycznych oraz własnych aplikacji i źródeł danych trzymanych przykładowo w MS Excel, istnieje konieczność inwentaryzacji oraz określenia zakresu informacyjnego istniejących aplikacji, zanim możliwe będzie zasilenie aplikacji EPM danymi źródłowymi. Nakład czasu poświęcony na integrację źródeł danych bar- 92 Ewa Sońta-Drączkowska dzo często jest nieoszacowany w projektach wdrożeń systemów BI, co z góry powoduje, że przyjęty harmonogram prac jest nierealistyczny. • Zaangażowanie różnego typu użytkowników w korzystanie z aplikacji BI. Użytkownikami i odbiorcami końcowymi aplikacji BI są pracownicy z różnych poziomów hierarchii organizacyjnej przedsiębiorstwa. Dlatego takie rozwiązanie musi spełniać wymagania zarówno analityków biznesowych drążących dane n.p. do poziomu pojedynczego rekordu, jak również członków zarządu, którzy otrzymują dane na poziomie syntetycznym w postaci tzw. kokpitów menedżerskich. 3. Struktura organizacyjna projektu wdrożeniowego oraz możliwe problemy na styku Dostawca Klient Projekty wdrożeniowe systemów EPM, jak również inne przedsięwzięcia informatyczne, prowadzone są z reguły z zaangażowaniem zewnętrznego integratora (Dostawcy), który parametryzuje aplikację zgodnie z wymaganiami zamawiającego (Klienta). Z reguły projekty tego typu odbywają się z udziałem dwóch partii: Dostawcy i Klienta. Zdarza się jednak w większych przedsięwzięciach informatycznych jak np. wdrożenie sytemu klasy Enterprise Ressource Planning (ERP), że dla potrzeb projektu powoływane jest konsorcjum wykonawcze składające się z kilku firm informatycznych lub/ i doradczych. Aranżacja prac w projekcie realizowanym w ramach konsorcjum jest o tyle trudniejsza, że wymaga koordynacji prac pomiędzy wieloma dostawcami. W takich sytuacjach rekomenduje się ustanowienie centralnego biura projektu nadzorującego prace. Dla uproszczenia i lepszego zilustrowania źródeł możliwych problemów projektowych, referat ten będzie się koncentrował na organizacji projektu, w której występuje jeden Dostawca integrujący rozwiązanie na zlecenie Klienta. Firma Dostawcy/ Integratora Komitet Sterujący Dostawca/Klient Kierownik Projektu Kierownik Projektu Zespół Dostawcy/ Integratora Zespół Klienta/ Zamawiającego Firma Klienta/ Zamawiając ego Rysunek 3: Organizacja projektu IT między Dostawcą a Klientem. Źródło: opracowanie własne. Na styku Dostawca Klient w projektach wdrożeń systemów klasy EPM pojawia się szereg problemów. Wywiady z praktykami wdrożeń systemów tej klasy przeprowadzone przez autorkę referatu pozwalają stwierdzić, że do najbardziej powszechnych należą: • Niedoszacowanie czasu na potrzebnego na integrację źródeł danych zasilających aplikację EPM na etapie ustanawiania projektu oraz wyceny prac. Dotyczy to zarówno organizacji Klienta wdrażającego aplikację, jak również Dostawcy, któremu bardzo trudno oszacować jest czas wymagany na integrację jeśli nie zna realiów organizacji Klienta, ilości systemów informatycznych Współpraca Dostawca Klient jako czynnik sukcesu projektów... 93 i innych źródeł danych wykorzystywanych przez Klienta i potrzebnych docelowo do zasilenia aplikacji EPM danymi. • Niejasna kwestia, związana z określeniem odpowiedzialności pomiędzy Klientem a Dostawcą za zarządzanie całością projektu. Rodzi to niejednokrotnie sytuacje konfliktowe i powoduje rozmycie odpowiedzialności za zarządzanie projektem. Często na etapie negocjacji Umowy wdrożeniowej pomija się kwestie kosztów związanych z zarządzaniem projektem oraz ustaleniem ról w projekcie. • Permanentna wielozadaniowość zarówno po strony Dostawcy, jak i Klienta. Oznacza to, że zespół Klienta, oprócz prac projektowych, ma do wykonania bieżące zadania związane z działalnością operacyjną, jak również zadania wynikające z ustanowionego projektu. Przy czym projekt traktowany jest często jako zadanie o niższym priorytecie. Dostawca rozwiązania natomiast realizuje często kilka projektów na raz, co wymaga żonglowania dostępnymi zasobami. Wielozadaniowość rodzi konieczność przełączania się między czynnościami projektowymi i operacyjnymi, co powoduje duże straty efektywności w pracy zespołu. • Opóźnienia projektu wynikające z długiego czasu weryfikacji i odpowiedzi Klienta na przekazane produkty prac (dokumenty i aplikację). Kwestia ta jest pochodną punktu powyższego, czyli wielozadaniowości członków zespołów wdrożeniowych. Może być również wynikiem niskiego priorytetu projektu w organizacji. Brak zaangażowania kierownictwa w nadzór i egzekwowanie harmonogramu prowadzi w rezultacie do spadku motywacji zespołu projektowego, aby projekt zakończyć w terminie. • Niejasne lub/ i niedoprecyzowane wymagania Klienta oraz zmiany do opracowanego projektu aplikacji. W projektach wdrożeń systemów klasy EPM, istotne jest precyzyjne określenie wymagań dla aplikacji w fazie jej projektowania. Zmiany wprowadzane na późniejszym etapie mogą okazać się pracochłonne i wymagające przeprojektowania modelu aplikacji. • Nieznajomość logiki działania aplikacji wielowymiarowych w zespole wdrożeniowym Klienta, może powodować nieporozumienia odnośnie funkcjonalności dostępnych w aplikacji. Przykładowo od aplikacji Oracle HFM nie należy oczekiwać szerokich funkcjonalności w zakresie analizy danych bazowych, gdyż służy ona głównie do konsolidowania sprawozdań finansowych na poziomie grupy kapitałowej według zdefiniowanych modeli agregacji danych wielowymiarowych. To tylko niektóre z możliwych problemów projektowych, z którymi borykają się zespoły wdrożeniowe i kierownicy projektów. Z punktu widzenia osiągania korzyści biznesowych zarówno Klient, jak i Dostawca, powinni być żywo zainteresowani szybką realizacją projektu. Główne korzyści sprawnej realizacji projektu dla Klienta to: • Szybkie wdrożenie zmiany biznesowej w organizacji. W przypadku rozwiązań klasy EPM zmiany wywołane nowym systemem dotyczą mogą mieć wpływ zarówno na raportowanie statutowe, jak również zarządcze. Szczególnie raportowanie zarządcze ma duży wpływ na organizację, gdyż od wyboru wskaźniki pomiaru efektywności zazębiają się z takim obszarami jak ocena personelu (HR), strategia i pomiar jej realizacji, sprzedaż i jej efektywność, itp. • Poprawienie procesu podejmowania decyzji w oparciu o rzetelne i spójne dane biznesowe. • Krótszy czas amortyzacji inwestycji jaką jest wdrożenie systemu informatycznego. • Pozytywny efekt marketingowy projektu w organizacji oraz zwiększona akceptacja użytkowników dla systemu. • Z punktu widzenia Dostawcy sprawna realizacja projektu jest istotna, gdyż: • Umożliwia realizację większej ilości projektów w danym okresie czasu, tzw. większe moce przerobowe Dostawcy. Korzystnie przekłada się to na przychody firmy. 94 Ewa Sońta-Drączkowska • Umożliwia obniżenie kosztów realizacji projektu poprzez efektywne wykorzystanie zasobów. • Poprawia reputację rynkową Dostawcy jako wiarygodnego partnera do współpracy. 4. Źródła problemów projektowych w relacji Dostawca Klient Paradoksalnie realizacja projektów informatycznych według dostępnych powszechnie metodyk zarządzania projektami, nie stanowi antidotum na dyskutowane powyżej problemy projektowe. Prowadzenie projektów ‘by the book’ może ograniczyć ryzyka projektowe, ale nie eliminuje do końca ryzyk ‘zachowaniowych’ stron zaangażowanych w projekt. W tym rozdziale przedyskutowane będą źródła problemów projektów informatycznych prowadzonych w relacji Dostawca Klient. Istnieją dwie zasadnicze przyczyny, dla których w projekty informatyczne realizowane z udziałem zewnętrznych firm wbudowane są ryzyka zachowaniowe wynikające z możliwych działań obu partnerów transakcji5: 1. Asymetria informacji – pomiędzy Dostawcą rozwiązania a Klientem/ Zamawiającym. Istniejąca różnica w dostępie do informacji powoduje, że obie strony nie mają pewności odnośnie zachowań, kompetencji oraz starań dołożonych przez partnerów transakcji. W przypadku Klienta poszukującego Dostawcy do wykonania przedmiotu zamówienia przed podpisaniem Umowy wdrożeniowej, istnieje problem wyboru partnera o kompetencjach adekwatnych dla potrzeb realizacji projektu (ang. selection problem). Z kolei potencjalny Dostawca nie ma pewności co do faktycznej sytuacji w obszarze systemów informatycznych i potrzeb biznesowych po stronie Klienta, jak również dokładności i adekwatności opisu przedmiotu Umowy. Przykładem może tu być chociażby zakres prac związany z integracją danych źródłowych. Faktyczny nakład potrzebny na realizację prac ujawnia się często po przeprowadzeniu fazy Analizy, dla Dostawcy obszar ten jest swego rodzaju ‘czarną skrzynką’, a nakład prac ex-ante jest trudny do oszacowania. Po podpisaniu Umowy z kolei Klient nie ma pewności, co poziomu starań dołożonych przez Dostawcę w przedmiocie realizacji Umowy (ang. moral hazard). 2. Wysoka specyfika przedmiotu transakcji – taki przedmiot Umowy jak system informatyczny wykazuje charakter tzw. inwestycji wyspecjalizowanej. Dostawca i Klient ponoszą w procesie wymiany spore nakłady, które mają małą lub żadną wartość w alternatywnym zastosowaniu. Dostawca ponosi nakład w przygotowaniu i przeprowadzeniu postępowania przetargowego i w momencie dokonania wyboru Dostawcy i negocjacji Umowy, jego nakłady związane z przygotowaniem transakcji są już znaczne. Odstąpienie Dostawcy od Umowy powodowałoby opóźnienia w rozpoczęciu projektu i konieczność nawiązywania rozmów z innymi dostawcami. Tym trudniej wycofać się ze współpracy z Dostawcą na bardziej zaawansowanych etapach projektu. Z kolei Dostawca inwestując czas w negocjacje, planowanie projektu oraz analizę wymagań po stronie Klienta ponosi nakłady specyficzne, gdyż produktu prac fazy analizy, jak również sparametryzowanej pod kątem wymagań aplikacji nie da się sprzedać po cenie rynkowej innemu klientowi. Wysoka specyfika inwestycji jaką jest projekt wdrożenia systemu może skutkować: • Trudnymi negocjacjami przedmiotu Umowy, gdyż w momencie podpisania Umowy nie istnieje faktycznie cena rynkowa produktu prac. W praktyce prowadzi to do przeciągających się negocjacji Umowy i obudowywania jej coraz większą ilością zabezpieczających mechanizmów umownych. 5 Problemami pełnomocnictwa i ryzyk związanych z relacjami między Pryncypałem (Klientem) a Agentem (Dostawcą), jak również ryzykami wynikającymi z dokonywania transakcji rynkowych ze szczególnym uwzględnieniem kosztów transakcyjnych zajmuje się tzw. nowa ekonomia instytucjonalna, która wykorzystuje m.in.: założenia teorii agencji oraz teorii kosztów transakcyjnych, m.in. J.E. Stiglitz / A. Weiss (1981); M. Jensen, W.H. Meckling (1976); O. E. Williamson (1975). Współpraca Dostawca Klient jako czynnik sukcesu projektów... 95 • Problem niedoinwestowania, czyli przykładowo dostarczenia przez Dostawcę zespołu realizującego projekt nie posiadającego najlepszych kwalifikacji do realizacji przedmiotu Umowy lub nie przywiązywania należytej wagi do jakości produktów prac (ang. under investment). • Problem oportunizmu. Oportunizm to zachowanie stron umowy polegających na dążeniu do realizacji maksymalizacji własnych korzyści. W kontekście inwestycji wyspecjalizowanych potencjał szantażu po obu stronach kontraktu jest wyższy z uwagi na trudności związane z wycofaniem się z Umowy (ang. hold-up). Na Rysunku 4 zestawione są typy ryzyk zachowaniowych w zależności od etapu formalizacji Umowy wdrożeniowej. Przed podpisaniem Umowy Podpisanie Umowy Po podpisaniu Umowy Wybór Dostawcy Negocjacje/ Pokusa nadużycia (ang. moral hazard) typy Umów i zapisy umowne Problem szantażu (ang. hold‐up) Negatywna Selekcja (ang. negative selection) Problem niedoinwestowania (ang. underinvestment) Rysunek 4: Typy ryzyk zachowaniowych w zależności etapu formalizacji projektu. Źródło: opracowanie własne. 5. Mechanizmy ograniczające ryzyka zachowaniowe w realizacji projektu W tym rozdziale przedyskutowane będą mechanizmy, które pozwalają na ograniczanie ryzyk zachowaniowych partnerów umowy wdrożeniowej ex-ante i ex-post. 5.1. Mechanizmy ograniczające ryzyka związane z wyborem Dostawcy W obszarze tym duże znaczenie ma polityka przedsiębiorstwa związana z zarządzaniem dostawcami (ang. procurement management). W kontekście tym warto poruszyć kilka czynników: między innymi określanie kryteriów wyboru dostawcy, formułowanie zapytań ofertowych i istotnych warunków zamówienia oraz procedury przetargowe. W kontekście realizacji projektów informatycznych ryzykowną polityką jest przyznawanie w kryteriach wyboru Dostawcy decydującej roli cenie za usługę wdrożeniową. Dostawcy oferujący ceny poniżej rynkowych z góry poddają w wątpliwość wiarygodność oferty. Zamawiający może narażać się tu na ryzyko tzw. negatywnej selekcji wykonawcy przedmiotu zamówienia. Rzetelni wykonawcy, posiadający kompetencje, którzy nie są w stanie zejść z ceną, mogą w ten sposób być wyeliminowani z rynku. W grze pozostają firmy, konkurujące ceną, co w obszarze wdrożeń systemów informatycznych, gdzie istotne są kompetencje i wiedza, jest szczególnie ryzykowną strategią wyboru. W rezultacie po podpisaniu Umowy może okazać się, że Dostawca nie posiada wystarczających zasobów lub/ i kompetencji do realizacji przedmiotu zamówienia. Naraża do Klienta na konieczność ponownego uruchomienia przetargu i zmiany Dostawcy, co może się okazać trudne i kosztowne. W wyborze Dostawcy systemu informatycznego (również klasy EPM) istotnymi kry- 96 Ewa Sońta-Drączkowska teriami oceny powinny być: merytoryczne i techniczne przygotowanie Dostawcy oraz kompetencje zarządzania projektami. Kolejną kwestią, którą należy uwzględnić na etapie przygotowania zapytania ofertowego, jest możliwości określenia dokładnej specyfikacji przedmiotu zamówienia. Dla systemów klasy BI, jest to zadanie niezwykle trudne, gdyż wymagania i rzeczywiste potrzeby Klienta, jak również nakład prac potrzebny dla realizacji projektu, nie dają się a priori precyzyjnie określić. W projektach BI istotne jest dokonanie w pierwszym kroku szczegółowej analizy potrzeb raportowych Klienta, jak również zakresu danych wymaganych do zasilenia aplikacji raportowych. Działania takie wymagają niejednokrotnie uruchomienia oddzielnego projektu przygotowującego do wdrożenia aplikacji EPM. Dopiero po określeniu: • potrzeb raportowych organizacji wynikających z realizowanej strategii • ilości i typu raportów i wskaźników efektywności • potrzeb i zakresu danych dla przygotowania budżetów i planów w organizacji • ilości i typu źródeł danych potrzebnych dla zasilenia aplikacji danymi raportowymi (lokacji) możliwe jest orientacyjne określenie zakresu i nakładu prac potrzebnego do wdrożenia aplikacji EPM. Największą niewiadomą w tym obszarze jest integracja źródeł danych, szczególnie w przedsiębiorstwach, które nie posiadają hurtowni danych, są złożone organizacyjnie (np. grupy kapitałowe), posiadają rozproszoną i niezintegrowaną strukturę systemów informatycznych. W takich przypadkach, aby ograniczyć ryzyko niepowodzenia projektu, rekomendowane jest wydzielenie fazy Analizy wymagań jako osobnego projektu, po którym można dopiero oszacować nakład prac i doprecyzować zakres projektu. W praktyce niestety często po fazie Analizy Dostawca jest konfrontowany z rzeczywistym nakładem prac potrzebnym na zrealizowanie przedmiotu Umowy. Może się okazać, że takiego rodzaju przedsięwzięcie okaże się z punktu widzenia pierwotnej wyceny prac, zupełnie nierentowne. Kolejną kwestią w procesie wyboru Dostawcy jest formalne sprawdzenie jego wiarygodności. Szczególne obostrzenia i wymagania dla procedury przetargowej narzuca Ustawa Prawo zamówień publicznych, której podlegają spółki sektora finansów publicznych. Dla firm uczestniczących w przetargach spełnienie takich wymagań na etapie przygotowania oferty stanowi uciążliwość niemniej jest uzasadnione z punktu widzenia ograniczania ryzyka Zamawiającego. Wiarygodność Dostawcy ma być potwierdzona szeregiem dokumentów formalnych, jak: aktualny KRS, oświadczenie o niepodleganiu wykluczeniu, oświadczenie o spełnianiu warunków uczestnictwa, wykaz referencji, doświadczenia zespołu projektowego. Dla potrzeb potwierdzenia wiarygodności potencjalnego Dostawcy na etapie ofertowania mogą być wymagane również: referencje od klientów, zaświadczenia potwierdzające kompetencje zespołu projektowego, jak np.: profesjonalne certyfikacje, gwarancje bankowe, itp. Możliwym sposobem w ograniczeniu ryzyka wyboru, może być również zaangażowanie zewnętrznego eksperta w proces wyboru dostawcy i systemu EPM. Bazując na ekspertyzie oraz doświadczeniu dostawca zewnętrzny jest w stanie lepiej ocenić kompetencje Dostawcy, jak również może zapobiegać nadużyciom związanym z udzielaniem zamówień dostawcom preferowanym z uwagi na partykularne interesy grup władzy w przedsiębiorstwie Zamawiającego. Niemniej zaangażowanie strony trzeciej z reguły znacznie podraża koszty związane z przetargiem/ procesem ofertowania. Jednym z lepszych mechanizmów zabezpieczających przez ryzykami złego wyboru jest budowanie bazy dostawców sprawdzonych i wiarygodnych, z których usług firma była w przeszłości zadowolona. Niemniej i tutaj mamy do czynienia z ryzykami wynikającymi z kwestii nieprzewidzianych, np. zmianą statusu finansowego dostawcy i jego potencjalną niewypłacalnością. W dobie kryzysu i dużej zmienności prowadzenia działalności gospodarczej ciężko zabezpieczyć się przed podobną ewentualnością w relacjach biznesowych. Rolę nie do przecenienia pełni reputacja Dostawcy oraz zaufanie zbudowane między partnerami kontraktu. Współpraca Dostawca Klient jako czynnik sukcesu projektów... 97 5.2. Rola typów Umów i zapisów umownych w ograniczaniu ryzyk projektowych Typ Umowy między Dostawcą i Klientem determinuje podział ryzyk projektowych między stronami kontraktu. Ponadto zapisy Umowne wprowadzają mechanizmy dyscyplinujące i motywujące zarówno Dostawcę jak i Klienta. Project Management Body of Knowledge6 w obszarze wiedzy ‘zarządzanie dostawcami’ wyróżnia 3 zasadnicze typy umów: 1) Umowa typu stała kwota (ang. Fixed Price Contract) – to powszechnie stosowany typ kontraktu w przypadku możliwości precyzyjnego określenie zakresu prac projektu. W umowie tego typu ryzyko nieprzewidzianego rozszerzenia zakresu przenoszone jest na Dostawcę. Ponosi on odpowiedzialność za koszty projektu, jak również zyski i straty z nim związane. Tego typu Umowa przy projektach wdrożeń systemów BI jest szczególnie ryzykowna dla Dostawcy w przypadku braku zdefiniowanych prac w obszarze integracji systemów źródłowych. Umowa typu stała kwota stanowi maksymalną zachętę dla Dostawcy do kontroli kosztów oraz efektywnej pracy na projekcie. Ponadto zaletą jej jest minimalny wysiłek administracyjny potrzebny dla rozliczenia pracy obu stron kontraktu. Niemniej również w ramach takiej Umowy możliwe są rozszerzenia kontraktu lub płatne modyfikacje, jeśli podlegają one procedurze zarządzania zmianami w Umowie. Egzekwowanie takich zmian zależy w dużej mierze od dobrej woli oraz współpracy partnerów kontraktu. 2) Umowa typu zwrot kosztów powiększony o premię, która jest zyskiem dla Dostawcy (ang. Cost-reimbursable contracts). W takiej Umowie Dostawca otrzymuje zwrot kosztów oraz procentową premię na poczet zysków. Może być ona liczona jako procentowy udział od poniesionych kosztów lub w wysokości procentowego udziału od szacowanych kosztów projektu. Możliwy jest również wariant w postaci zwrotu kosztów oraz uzgodnionej premii plus bonus za osiągnięcie celów doprecyzowanych w Umowie. W takim typie Umowy ryzyko przesuwa się w porównaniu z umową typu stała kwota na Zamawiającego. Umowa ta nadaje się w przypadkach, kiedy przedmiot umowy ciężko jest ex-ante zdefiniować lub kiedy brakuje danych, aby ostatecznie oszacować ostateczny budżet projektu. Takie umowy mają sens w przypadku, kiedy w perspektywie długoterminowej bardziej istotne jest zachowanie jakości niż kontrolowanie kosztów. Dostawca ma tu mniejszą zachętę, aby pracować efektywnie. Umowy tego typu wiążą się ze sporym wysiłkiem związany z rozliczeniem i administrowania kontraktu. 3) Umowa typu rozliczenie kosztów czasu i robocizny (ang. Time & Material). W tego typu Umowie zamawiający zgadza się płacić Dostawcy za czas i robociznę użytą do realizacji przedmiotu Umowy. Kontrakty takie zawierają elementy zarówno zwrotu kosztów, jak również stałej kwoty (np. poprzez ustalenie stałej stawki godzinowej). W takim typie Umowy wartość kontraktu może rosnąć, co zabezpiecza Dostawcę przed niedookreśleniem przedmiotu Umowy. W tym wypadku ryzyko rozszerzenia zakresu jest przeniesione na Zamawiającego. Umowa taka jest rekomendowana w przypadku niemożności zdefiniowania zakresu prac. Jej wadą jest dosyć duży nakład potrzebny na zarządzanie kontraktem. W praktyce często Klient ściśle monitoruje czas pracy zgłaszany przez Dostawcę i niejednokrotnie zgłasza zastrzeżenia. Wśród zapisów umownych dyscyplinujących strony kontraktu wyróżnić można następujące: • Obowiązki Dostawcy i Zamawiającego: w umowie wdrożeniowej często pojawia się paragraf precyzujący obowiązki obu stron kontraktu. • Harmonogram płatności: Określa kalendarz płatności za produkty prac projektu. Jednym z mechanizmów stosowanych tutaj jest zatrzymanie ok. 10-20% wartości kontraktu jako tzw. ‘gwarancji dobrego wykonania’, która wypłacana jest dostawcy np. po fazie stabilizacji systemu. • Procedura i kryteria odbioru: Precyzuje sposób oraz kryteria odbioru produktów prac projektu. Dotyczy to zarówno dokumentacji, aplikacji (kodu), jak również innych usług dostarczanych w projekcie, jak n.p. szkolenia użytkowników i administratorów. 6 Project Management Body of Knowledge (PMBoK), Fourth Edition, PMI, 2008. 98 Ewa Sońta-Drączkowska • Kary umowne: Nakładane są na Dostawcę w przypadku niedostarczenia przedmiotu Umowy w terminie z jego winy. Określają one wysokość kary za każdy dzień opóźnienia w stosunku do terminu końcowego określonego w Umowie. W praktyce są trudne do egzekwowania, gdyż wina za opóźnienia często leży po obu stronach kontraktu, a nie wynika wyłącznie z winy Dostawcy. 5.3. Zarządzanie projektem jako mechanizm nadzoru Po podpisaniu Umowy jednym z istotnych mechanizmów dyscyplinujących partnerów Umowy są zasady zarządzania projektem. Często precyzowane są one w tzw. Planie Projektu lub Karcie Projektu i egzekwowane przez kierowników projektu oraz Komitet Sterujący projektu. Poprzez sprecyzowanie procedur zarządzania projektem: • Struktury organizacyjnej projektu wraz z rolami i odpowiedzialnościami • Komunikacji i spotkań projektowych • Zasad raportowania o postępie prac • Procedury zarządzania zmianami • Zarządzania ryzykami i kwestiami otwartymi wprowadzone są zasady nadzoru nad pracami w projekcie. Niebagatelne znaczenie ma tu sporządzanie oraz archiwizowanie dokumentacji projektowej. Dokumentacja statusu prac w projekcie, formalnych ustaleń ze spotkań, jak również zmian dokonywanych w projekcie ma duże znaczenie porządkujące prace jak również zabezpieczające przed potencjalnym konfliktami i niedomówieniami. Bibliografia 1. 2. 3. 4. 5. 6. 7. 8. Jensen M., Meckling W. H., ‘Theory of the firm: Managerial behavior, agency costs, and the ownership structure.’ Journal of Financial Economics, 1976, 3: 305–360. Ośródka K., Business Intelligence i hurtownie danych, nieopublikowana praca magisterska, Warszawa, 2008. Project Management Body of Knowledge (PMBoK), Fourth Edition, PMI, 2008. Stiglitz J. E., Weiss A., Credit Rationing in Markets with Imperfect Information in: American Economic Review 71/3, 1981, S. 393–410. Surma J., Business Intelligence – systemy wspomagania decyzji biznesowych, Wydawnictwo Naukowe PWN SA, Warszawa, 2009, s. 13. Standish Group, Chaos Report, 2005. Williamson O. E., The economic institutions of capitalism. New York: Free Press, 1975. TDWI Report Series, Evaluating ETL and Data Integration Platforms, 101communications, United States of America 2003, s. 2.
