Zarządzanie ryzykiem związanym z dopasowaniem systemu ERP do organizacji

Uniwersytet Warszawski

Streszczenie

Celem niniejszego artykułu jest przedstawienie zagroĪeĔ wynikających ze zmian programistycznych dokonanych w standardowym systemie klasy ERP w trakcie pro-cesu dostosowywania zakupionego pakietu do organizacji oraz analiza moĪliwoĞci minimalizacji ryzyka z tym związanym.

W pierwszej czĊĞci artykułu zdefiniowano pojĊcie projektu wdroĪeniowego, a takĪe opisano mechanizm przeprowadzania modyfikacji standardowego oprogra-mowania wspomagającego zarządzanie w przedsiĊbiorstwie. Druga czĊĞü skoncen-trowana jest na identyfikacji ryzyka powiązanego z modyfikacjami, jego ocenie oraz proponowanych metodach zapobiegawczych. Tabela zbiorcza zidentyfikowanych za-groĪeĔ została przygotowana na podstawie opracowaĔ fachowych zajmujących siĊ tematyką implementacji systemów klasy ERP w przedsiĊbiorstwach oraz obserwacji własnych autorki zgromadzonych podczas wieloletniej pracy na projektach wdroĪe-niowych.

Słowa kluczowe: projekt wdroĪeniowy, modyfikacje standardowych systemów klasy ERP, zarzą-dzanie ryzykiem

1. Wprowadzenie

We współczesnym przedsiĊbiorstwie efektywne zarządzanie prowadzące do wzrostu zysku i udziału w rynku moĪliwe jest wyłącznie wtedy, kiedy wykorzystana zostanie posiadana wiedza o organizacji i jej otoczeniu. Dzisiaj to przede wszystkim dziĊki nowoczesnym rozwiązaniom informatycznym, do których naleĪą systemy klasy ERP, moĪna tą wiedzą zarządzaü, a tym samym sprostaü stale rosnącej konkurencji, usprawniü dostawy oraz pozyskaü wiĊcej klientów. Oczeki-wane korzyĞci z tytułu wdroĪenia standardowego pakietu ERP powodują, Īe z roku na rok coraz wiĊcej przedsiĊbiorstw decyduje siĊ na implementacjĊ tego rodzaju oprogramowania. Gartner Group szacuje, patrz Forecast [3], Īe Ğrednioroczne tempo wzrostu sprzedaĪy licencji na Ğwiecie dla aplikacji ERP w latach 2003 – 2008 oscyluje w granicach 6%.

Organizacja decydująca siĊ na wdroĪenie standardowego pakietu musi dopasowaü zakupioną aplikacjĊ do swoich wymagaĔ, tak by ta wspomagała pracĊ w przedsiĊbiorstwie oraz przepływ informacji w ramach procesów gospodarczych. Dostosowując system naleĪy podjąü decyzjĊ od-noĞnie zakresu zmian programistycznych w zakupionym oprogramowaniu. Modyfikacje w strategicznych obszarach działalnoĞci są uzasadnione i brak dopasowania aplikacji do organiza-cji moĪe wpłynąü na jej rynkową pozycjĊ, np. współpracĊ z dostawcami czy relacje z klientami. Z kolei akceptacja wszystkich zgłoszonych przez uĪytkownika wymagaĔ dotyczących zmiany kodu w gotowym pakiecie wpłynie na budĪet, harmonogram oraz jakoĞü implementacji.

Modyfikacje standardowego oprogramowania wspomagającego zarządzanie klasy ERP są ze swej natury ryzykowne, gdyĪ zmieniają logikĊ działania systemu oraz jego funkcjonalnoĞü. Za

ryzyko w tym wypadku naleĪy uznaü moĪliwoĞü wystąpienia niepoĪądanych zdarzeĔ, które mogą mieü wpływ na jakoĞü oprogramowania i przebieg projektu wdroĪeniowego. W zaleĪnoĞci od rodzaju oraz wielkoĞci dokonanej zmiany ryzyko jest mniejsze lub wiĊksze, ale zawsze wystĊpu-je, stąd kluczowe podczas procesu dopasowania zakupionego pakietu do organizacji staje siĊ wprowadzenie programów zarządzania ryzykiem.

Badania i praktyka wyraĨnie pokazują, iĪ zarządzanie ryzykiem prowadzone podczas doko-nywania zmian programistycznych w standardowej aplikacji umoĪliwia odpowiednie przygotowa-nie działaĔ zapobiegawczych w przypadku, kiedy wystąpi zdarzeprzygotowa-nie okreĞlone jako ryzykowne. Zarządzanie ryzykiem w tej sytuacji polega jak wskazuje w swojej pracy W. Bielecki [1] na po-szukiwaniu i podejmowaniu działaĔ, które powinny stanowiü zabezpieczenie przed poniesieniem strat wiĊkszych niĪ przyjĊty poziom bezpieczeĔstwa.

2. Projekt wdroeniowy i modyfikacje systemu

WdroĪenie gotowego systemu klasy ERP to nowy rodzaj przedsiĊwziĊü informatycznych po-legający na przystosowaniu zakupionego oprogramowania do konkretnych warunków bizneso-wych w przedsiĊbiorstwie. Projekt wdroĪeniowy według M. PaĔkowskiej [7] charakteryzuje siĊ oznaczonym czasem rozpoczĊcia i zakoĔczenia, zdefiniowanymi celami oraz wyznaczonymi za-sobami przeznaczonymi na jego realizacjĊ. Z. Szyjewski [10] w swojej pracy zwraca uwagĊ, iĪ kaĪde przedsiĊwziĊcie polegające na wdroĪeniu standardowego oprogramowania definiowane jest przez nastĊpujące kryteria:

• efekt koĔcowy (zakres) – precyzyjnie zdefiniowane korzyĞci, zwykle wyraĪone w kategoriach liczbowych, np. wdroĪenie planowania mające na celu redukcjĊ stanu za-pasów o 30%,

• czas realizacji (terminy) – czas rozpoczĊcia i zakoĔczenia prac wyznacza ramy czasowe re-alizacji, jest podstawą do wyceny pracochłonnoĞci,

•

W celu osiągniĊcia poĪądanego stanu aplikacji podczas projektu wdroĪeniowego obok para-metryzacji standardowych funkcjonalnoĞci dokonuje siĊ modyfikacji programistycznych w kodzie oprogramowania. Zgodnie z okreĞleniami powszechnie przyjĊtymi w literaturze cybernetycznej A. Nowicki [5] definiuje poĪądany stan systemu jako uporządkowany zbiór wartoĞci parametrów, który zapewnia osiągniĊcie celów przedsiĊbiorstwa. W tym ujĊciu parametrami mogą byü funkcje i zadania, szybkoĞü przeprowadzania operacji, niezawodnoĞü oraz koszt działania systemu.

Według załoĪeĔ metodyk wdroĪeniowych na ogół w pierwszej lub drugiej fazie implementa-cji systemu wspomagającego zarządzanie nastĊpuje porównanie wymagaĔ zdefiniowanych przez przedsiĊbiorstwo do funkcjonalnoĞci zawartej w standardowym oprogramowaniu. W swoich ba-daniach C. Soh, K. Sia Siew, J. Tay-Yap [9] pokazują, Īe rozbieĪnoĞci pomiĊdzy zakupioną apli-kacją klasy ERP a zdefiniowanymi wymaganiami moĪna pogrupowaü według trzech kategorii:

• RozbieĪnoĞci dotyczące formatu danych – powstają, kiedy uĪytkownik nie moĪe wpisaü w standardowe pole informacji w dowolny sposób. Wynika to z faktu, iĪ kaĪde pole w bazie danych ma okreĞlony format oraz liczbĊ znaków. Zmiany dokonywane w formacie pól, np. rozszerzenia polegające na dodaniu kolejnych znaków naleĪą do po-waĪnych modyfikacji, które wymagają ingerencji w strukturĊ bazy danych.

• RozbieĪnoĞci dotyczące prezentacji wyników – programy interaktywne oraz standardowe raporty nie przedstawiają wszystkich wymaganych przez pracowników przedsiĊbiorstwa danych lub sekwencja prezentacji jest niesatysfakcjonująca dla uĪytkowników.

• RozbieĪnoĞci funkcjonalne – system nie posiada wbudowanych rozwiązaĔ umoĪliwiają-cych obsługĊ procesów biznesowych specyficznych dla danej firmy, branĪy lub kraju. W przypadku zdefiniowania obszarów, których aplikacja nie jest w stanie obsłuĪyü, naleĪy podjąü decyzjĊ dotyczącą zakresu modyfikacji. Eliminacja rozbieĪnoĞci w formacie danych oraz prezentacji wyników polega na dokonaniu zmian na standardowych wersjach interaktywnych oraz wsadowych, tak by programy funkcjonowały zgodnie z oczekiwaniami uĪytkowników. Z kolei rozbieĪnoĞci funkcjonalne wymagają podjĊcia odpowiednich działaĔ rozwojowych, które spowo-dują dodanie nowych elementów do oprogramowania.

Kiedy pojawi siĊ sytuacja problemowa dotycząca zgłoszenia zapotrzebowania na przeprowa-dzenie modyfikacji naleĪy:

• dokonaü wspólnie z uĪytkownikami przeglądu procesu i zaproponowaü alternatywny spo-sób działania według tzw. „najlepszych praktyk biznesowych”,

• opracowaü rozwiązanie w systemie bazując na standardowej funkcjonalnoĞci oraz zapre-zentowaü je osobom decydującym, np. komitetowi sterującemu,

• przeanalizowaü zalety i wady modyfikacji oprogramowania.

Analiza zalet i wad zmian programistycznych oraz uchwycenie dokładnych relacji miĊdzy czynnoĞciami dotyczącymi wykonania modyfikacji a zasobami ekonomicznymi tj. czasem, kosz-tem i pracochłonnoĞcią umoĪliwiają podjĊcie optymalnej decyzji, czyli najlepszej w danych wa-runkach działania, odnoĞnie zmian w standardowym oprogramowaniu. Wszystkie decyzje doty-czące zmian w zakupionym pakiecie klasy ERP wiąĪą siĊ z moĪliwoĞcią konsekwencji niepo-myĞlnych dla podmiotu dokonującego modyfikacji oraz dla przedsiĊbiorstwa. Wykonane działa-nia mogą nie przynieĞü oczekiwanych zmian strukturalnych i funkcjonalnych w systemie, a ponadto mogą charakteryzowaü siĊ przekroczeniem przeznaczonego na nie budĪetu oraz innym harmonogramem niĪ planowano. W celu zwiĊkszenia szansy na zakoĔczenie projektu sukcesem, istotne staje siĊ zarządzanie ryzykiem pozwalające na odpowiednio wczesne zdefiniowanie prze-szkód i zagroĪeĔ mogących wystąpiü podczas procesu modyfikacji standardowego oprogramowa-nia, a nastĊpnie ich monitorowanie.

3. Ryzyko zwizane z dopasowaniem standardowego systemu do organizacji

NajczĊĞciej ryzyko w literaturze definiuje siĊ jak jako funkcjĊ – np. patrz D. DĪega [2], w której do najwaĪniejszych składników naleĪy prawdopodobieĔstwo zajĞcia danego zdarzenia oraz jego wpływ na pozostałe zmienne:

Ryzyko = f (Prawdopodobie stwo, Wpływ na pozostałe zdarzenia) lub Ryzyko = f (Przypadek, Zabezpieczenie)

W swojej pracy C. Pritchard [8] zaleca, by zarządzanie ryzykiem podczas projektu zmierzało do:

• zmniejszania ryzyka,

• eliminowania ryzyka, jeĞli to moĪliwe i praktycznie uzasadnione, • przygotowania alternatywnych sposobów działania,

• okreĞlenia rezerw czasowych oraz finansowych stanowiących zabezpieczanie w przypadku wystąpienia sytuacji zdefiniowanej jako zagroĪenie.

Niestety jak wskazuje M. PaĔkowska [7] zasadnicza trudnoĞü w przypadku zarządzania ryzy-kiem w projektach wdroĪeniowych polega na tym, Īe róĪne strony, tj. dostawca systemu, uĪyt-kownicy, kierownik przedsiĊwziĊcia, zarząd przedsiĊbiorstwa mogą posiadaü odmienne punkty widzenia odnoĞnie sytuacji zdefiniowanych jako zagroĪenia. Wynika to z braku zbieĪnoĞci celów i priorytetów, a takĪe własnych odrĊbnych spostrzeĪeĔ odnoĞnie moĪliwoĞci ich realizacji. W takim wypadku ustalenie jednej strategii zarządzania ryzykiem moĪe okazaü siĊ bardzo trudne. NaleĪy jednak podjąü wysiłek zmierzający do wspólnego zaplanowania działaĔ minimalizujących czynniki ryzka.

Racjonalne podejĞcie stosowane podczas trwania projektu informatycznego według B. Nowarskiej [4] wymaga systematycznego wykonywania nastĊpujących czynnoĞci:

• gromadzenia wiedzy zdobytej na podstawie wczeĞniejszych doĞwiadczeĔ odnoĞnie sytuacji okreĞlanych jako ryzykowne,

• klasyfikacji zdefiniowanych problemów (strukturyzacji posiadanej wiedzy),

• zrozumienia przyczyn pojawiania siĊ czynników ryzyka, co ma na celu wczesne ich dia-gnozowanie oraz usuwanie przyczyn, a nie skutków,

• okreĞlenie zespołu Ğrodków i metod zapobiegawczych.

AktywnoĞü prewencyjna dotycząca minimalizacji prawdopodobieĔstwa wystąpienia ryzyka, obejmuje cztery cyklicznie powtarzane zadania, tj. identyfikacjĊ, ocenĊ, zapobieganie oraz moni-torowanie ryzyka.

Rysunek 1: Model zarządzania ryzykiem

ħródło: na podstawie Z. Szyjewski Zarządzanie Projektami Informatycznymi, Agencja Wydawnicza Placet, Warszawa 2001

Identyfikacja ryzyka polega na okreĞleniu zdarzeĔ, które mogą negatywnie wpłynąü na reali-zacjĊ modyfikacji. Przed podjĊciem jakichkolwiek działaĔ powinna zostaü sporządzona lista za-groĪeĔ, a nastĊpnie naleĪy tzw. rejestr ryzyka systematycznie uzupełniaü o nowe czynniki mogące mieü negatywne oddziaływanie na przebieg prac projektowych. Jak wskazuje D. DĪega [2] infor-macje wykorzystywane w czasie analizy ryzyka pochodzą z porównaĔ z podobnymi projektami, z doĞwiadczeĔ, wyników testów, modelowania i symulacji.

Ocena zidentyfikowanego w pierwszym etapie zagroĪenia polega na oszacowaniu prawdopo-dobieĔstwa wystąpienia negatywnej sytuacji oraz jej skutków. PodstawĊ analizy stanowią plany

RYZYKO

Identyfikacja Ocena Zapobieganie _{Monitorowanie}

projektu, harmonogram czasowo – zasobowy oraz inne dokumenty sporządzone na potrzeby wdroĪenia oraz przeprowadzenia zmian w oprogramowaniu. W swojej pracy Z. Szyjewski [10] zwraca uwagĊ, iĪ w zaleĪnoĞci od wagi danego zagroĪenia stosuje siĊ róĪne miary ryzyka, od bardzo prostych ocen, czy ryzyko jest wysokie, Ğrednie, niskie, do wyliczenia dokładnych wskaĨ-ników wyraĪonych jako prawdopodobieĔstwo wystąpienia danego zdarzenia. WaĪnym parame-trem, który powinien równieĪ zostaü oszacowany jest wysokoĞü potencjalnych strat. Na realne ryzyko wskazują bowiem moĪliwe straty w połączeniu z prawdopodobieĔstwem ich wystąpienia.

Identyfikacja i ocena ryzyka projektowego pozwalają na zdefiniowanie hierarchii zagroĪeĔ i skoncentrowanie siĊ na działaniach eliminujących ryzyko ich wystąpienia. Jako sposoby zabez-pieczania siĊ przed negatywnymi skutkami ryzyka A. Nowicki, J. Unold [6] wymieniają:

• Unikanie zagroĪeĔ przez podjĊcie działaĔ zapobiegawczych, które mają na celu minimali-zacjĊ wpływu negatywnych czynników na projekt. Działania osłabiające ryzyko powinny prowadziü zarówno do zmniejszenia prawdopodobieĔstwa wystąpienia zagroĪenia, jak i potencjalnych strat. W przypadku podejĞcia zapobiegawczego działania związane z urzeczywistnieniem siĊ ryzyka są podejmowane zgodnie z planem awaryj-nym, opracowanym wczeĞniej na etapie oceny ryzyka.

• Transfer ryzyka polegający na przeniesieniu całoĞci lub czĊĞci negatywnych skutków zda-rzeĔ na inne podmioty, np. zawierając odpowiednie klauzule w umowach pomiĊdzy podmiotami uczestniczącymi w projekcie.

• Tworzenie rezerw na wypadek wystąpienia negatywnych zdarzeĔ. Metoda ta jest niechĊt-nie stosowana, gdyĪ związana jest z zamroĪeniechĊt-niem Ğrodków finansowych i tym samym wpływa na wzrost kosztów projektu.

Realizacja zarządzania ryzykiem powinna byü monitorowana przez cały okres trwania pro-jektu. NaleĪy obserwowaü sytuacjĊ i odpowiednio dostosowywaü plany podejmowanych działaĔ zapobiegawczych. Zaleca siĊ okresowe organizowanie warsztatów sterowania ryzykiem, podczas których omawia siĊ problemy dotyczące zagroĪeĔ. Wszystkie prowadzone prace związane z za-rządzaniem ryzykiem powinny byü na bieĪąco dokumentowane.

NajczĊstsze zagroĪenia mogące wystąpiü podczas procesu dopasowania gotowych pakie-tów do organizacji zostały przedstawione w tabeli poniĪej, łącznie z oceną ryzyka oraz sugerowa-nymi metodami zapobiegania sytuacjom zdefiniowanym jako ryzykowne.

Tabela 1. Identyfikacja, ocena i zapobieganie ryzyku

Identyfikacja ryzyka Ocena ryzyka Zapobieganie

Brak odpowiedniej ewaluacji zgłaszanych zapotrzebowaĔ na modyfikacje. Skutkiem moĪe byü dokonanie niepotrzebnych, ale kosztownych zmian

w standardowej aplikacji.

W trakcie wdroĪenia uĪytkowni-cy czĊsto próbują przenieĞü ‘obecny stan’ do nowego syste-mu. Takie podejĞcie moĪe byü kosztowne oraz wiąĪe siĊ z za-groĪeniem przeniesienia dotych-czasowych problemów do nowej aplikacji.

Opracowanie procedury zatwier-dzania modyfikacji. Wskazane jest, by zmiany w standardowym oprogramowaniu były akcepto-wane przez Komitet Sterujący.

Identyfikacja ryzyka Ocena ryzyka Zapobieganie

Brak zrozumienia działania sys-temu przez zespół wdroĪeniowy moĪe powodowaü zgłaszanie modyfikacji, które nie są po-trzebne, gdyĪ gotowy pakiet zawiera wymaganą funkcjonal-noĞü.

Dokonanie niepotrzebnych mody-fikacji moĪe okazaü siĊ bardzo kosztowne. Ponadto istnieje ryzyko, Īe wprowadzone zmiany spowodują niestabilnoĞü standar-dowej aplikacji.

Przeszkolenie zespołu wdroĪe-niowego oraz innych decyden-tów z funkcjonalnoĞci i działania standardowego oprogramowania.

Brak komunikacji w realizacji projektu miĊdzy zespołem wdro-Īeniowym a kierownictwem moĪe powodowaü rozbieĪnoĞü celów. Modyfikacje bĊdą prze-prowadzone w obszarach, które nie wymagają zmian z punktu widzenia strategii przedsiĊbior-stwa.

Zmieniające siĊ cele najwyĪszego kierownictwa oraz brak decyzyj-nej kadry moĪe skutkowaü wprowadzeniem zmian do syste-mu, które bĊdą kosztowne, ale nie zostaną zaakceptowane przez klienta.

Do pracy na projekcie wdroĪe-niowym powinni zostaü oddele-gowani uĪytkownicy znający cele oraz wymagania firmy. Wskaza-ne jest, by kaĪda decyzja tych osób odnoĞnie kastomizacji zo-stała zaakceptowana przez Komi-tet Sterujący.

Niedoszacowanie kosztu modyfi-kacji.

Wysoki koszt zwiĊksza ryzyko przekroczenia budĪetu przezna-czonego na wdroĪenie. Zbyt niski szacunek moĪe prowadziü do powstania problemów w trakcie realizacji, kiedy prace wykonywane bĊdą przy ograni-czonych Ğrodkach.

Koszt modyfikacji powinien byü oszacowany przez specjalistów, którzy bĊdą wykonywali zmiany. W trakcie realizacji projektu wszystkie wydatkowane Ğrodki finansowe powinny byü monito-rowane pod kątem budĪetu.

Niedoszacowanie czasu potrzeb-nego na wykonanie zmiany.

Harmonogram wykonania mody-fikacji oparty na optymistycznych załoĪeniach, które nie bĊdą reali-zowalne.

W trakcie realizacji wszystkie odchylenia od harmonogramu powinny byü na bieĪąco raporto-wane.

DuĪa iloĞü wprowadzonych zmian do standardowego opro-gramowania moĪe spowodowaü, Īe reinstalacja nowej wersji, tzw. „upgrade” bĊdzie trudny do wykonania, a moĪe nawet niewy-konalny.

Brak moĪliwoĞci aplikacji auto-matycznych aktualizacji przygo-towanych przez dostawcĊ syste-mu oraz brak reinstalacji nowej wersji uniemoĪliwi korektĊ wy-krytych błĊdów w aplikacji.

W przypadku reinstalacji nowej wersji potrzebni bĊdą programi-Ğci, którzy przed rozpoczĊciem procesu tzw. upgradu sprawdzą, gdzie kod programu jest zmody-fikowany oraz wprowadzą odpo-wiednie zmiany.

Identyfikacja ryzyka Ocena ryzyka Zapobieganie

Wiele błĊdów w zmodyfikowa-nym programie. Niska jakoĞü modyfikacji.

Zmodyfikowana aplikacja moĪe zakłóciü działanie standardowego oprogramowania, przez co system bĊdzie niestabilny.

NaleĪy dokładnie przetestowaü kaĪdą wprowadzoną zmianĊ, aby wyeliminowaü moĪliwoĞü poja-wiania siĊ błĊdów w Ğrodowisku produkcyjnym.

Brak dokumentacji odnoĞnie wykonanych zmian programi-stycznych.

Bez dokładnego opisu wykona-nych modyfikacji wsparcie sys-temu juĪ po uruchomieniu moĪe okazaü siĊ bardzo trudne, a nawet niemoĪliwe.

Procedura wykonania modyfika-cji powinna zakładaü obowiąz-kowe przygotowanie dokumenta-cji przez przydzielonego anality-ka.

Brak odpowiednio wyszkolonych pracowników, którzy bĊdą wspie-rali system juĪ po zmianach. Konsultanci zewnĊtrzni nie bĊdą w stanie Ğwiadczyü odpowiednich usług z powodu zmian dokona-nych w standardowej aplikacji.

Utrzymanie i wsparcie systemu tzw. „support” moĪe staü siĊ bardzo trudny, a zatem kosztow-ny. Dostawcy standardowych systemów zwykle nie oferują wsparcia w przypadku dokonania modyfikacji w oprogramowaniu.

WdroĪenie powinno równocze-Ğnie słuĪyü przygotowaniu pra-cowników firmy do wsparcia systemu działającego w Ğrodowisku produkcyjnym. Członkowie zespołu wdroĪenio-wego powinni byü super uĪyt-kownikami znającymi funkcjo-nalnoĞü standardową oraz wszystkie zmiany dokonane w jej oprogramowaniu.

4. Uwagi ko cowe

Zmiany wprowadzone do kodu standardowego oprogramowania gwarantują wiĊksze dopaso-wanie systemu do organizacji, jednak są obarczone duĪym ryzykiem. Zidentyfikowane zagroĪenia związane z modyfikacjami gotowego pakietu klasy ERP obejmują przede wszystkim nastĊpujące rodzaje zdarzeĔ:

• wykonanie niepotrzebnych modyfikacji, które zostały zgłoszone z powodu braku zrozu-mienia standardowej funkcjonalnoĞci pakietu przez uczestników wdroĪenia, chĊci prze-niesienia „stanu obecnego” do nowego systemu czy braku znajomoĞci celów przedsiĊ-biorstwa przez członków zespołu wdroĪeniowego,

• niedoszacowanie kosztu oraz czasu potrzebnego na przeprowadzenie zmian programistycz-nych w standardowym oprogramowaniu,

• pojawienie siĊ błĊdów w zmodyfikowej aplikacji, czego skutkiem moĪe byü zakłócenie działania oraz niestabilonoĞü zaimplementowanego systemu.

Celem unikniĊcia przykrych niespodzianek wiąĪących siĊ z modyfikacjami zakupionego pakie-tu klasy ERP zaleca siĊ od początku przedsiĊwziĊcia wdroĪeniowego stałą obserwacjĊ projekpakie-tu

oraz jego otoczenia, monitorowanie zdefiniowanych zagroĪeĔ oraz aktywne podejmowanie dzia-łaĔ zapobiegawczych. Do zespołu Ğrodków i metod minimalizujących czynniki ryzyka naleĪą:

• tworzenie i przestrzeganie odpowiednich procedur projektowych dotyczących np. zgłasza-nia oraz zatwierdzazgłasza-nia modyfikacji, testowazgłasza-nia zmian dokonanych w standardowych programach, przygotowywania dokumentacji opisującej modyfikacjĊ,

• szkolenie uczestników projektu ze standardowej funkcjonalnoĞci systemu oraz dokonanych w aplikacji zmian programistycznych,

• szacowanie budĪetu i harmongramu wykonania modyfikacji przez specjalistów, którzy bĊ-dą wykonywali zmiany,

• aktywne działanie Komitetu Sterującego w przypadku zatwierdzania modyfikacji, kontroli ich przebiegu, akceptacji, a takĪe podjmowania wszystkich decyzji o strategicznym zna-czeniu,

• zapewnienie efektywnej komunikacji projektowej pomiĊdzy zespołem wdroĪeniowym, najwyĪszym kierownictwem, Komitetem Sterującym oraz konsultantami wspomagają-cymi implementacjĊ oprogramowania poprzez organizowanie spotkaĔ, warsztatów, przy-gotowywanie ogólnodostĊpnych raportów mających na celu odpowiednio wczesne wy-krycie nowych zagroĪeĔ i ocenĊ prowadzonych działaĔ zapobiegawczych.

Zarządzanie ryzykiem zwykle stanowi słaby punkt projektów informatycznych, gdyĪ kierow-nictwo czĊsto skupia siĊ bardziej na pozytywnych aspektach przedsiĊwziĊcia niĪ na negatywnych. W rzeczywistoĞci jednak kluczowa jest rola Komitetu Sterującego, którego działanie ma istotne znaczenie w przypadku identyfikacji, oceny, zapobiegania i monitorowania zdefiniowanych prze-szkód oraz zagroĪeĔ. Komitet powinien dbaü o przestrzeganie odpowiednich procedur, poprawĊ komunikacji projektowej, analizĊ pod kątem budĪetu wydatkowych Ğrodków finansowych oraz dotrzymanie wyznaczonych terminów. Prowadzenie aktywnych działaĔ polegających na przewi-dywaniu potencjalnych, negatywnych zdarzeĔ i podejmowaniu odpowiednich kroków zapobie-gawczych zanim niekorzystna sytuacja wystąpi, ma na celu minimalizacjĊ ryzyka związanego z wprowadzeniem modyfikacji w zakupionym systemie klasy ERP oraz zagwarantowanie sukcesu projektu wdroĪeniowego.

Bibliografia

1. Bielecki W.: Informatyzacja zarządzania, Polskie Wydawnictwo Ekonomiczne, Warszawa 2001.

2. DĪega D.: Identyfikacja i analiza ryzyka w projektach informatycznych. W: Informatyka we współczesnym zarządzaniu (Kisielnicki J., Nowak J., Grabara J. /red/), Wydawnictwa Naukowo-Techniczne, Warszawa 2004, 229-236.

3. Forecast: ERP Software, Worldwide, 2003-2008, 3Q04 Update, www.gartner.com, 06.01.2007.

4. Nowarska B.: Problemy uĪytkowników realizujących przedsiĊwziĊcia informatyczne (Wyniki badaĔ). W: Informatyka we współczesnym zarządzaniu (Kisielnicki J., Nowak J., Grabara J. /red/), Wydawnictwa Naukowo-Techniczne, Warszawa 2004, 439-451.

5. Nowicki A.: Strategia doskonalenia systemu informacyjnego w zarządzaniu przedsiĊbiorstwem, Wydawnictwo Akadamii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław 1999.

6. Nowicki A., Unold J. /red/,: Organizacyjne aspekty doskonalenia systemów informacyjno-decyzyjnych zarządzania, Wydawnictwo Akademii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław 2002.

7. PaĔkowska M.: Zarządzanie zasobami informatycznymi, Difin, Warszawa 2001.

8. Pritchard C.: Zarządzanie ryzykiem w projektach, Teoria i praktyka, WIG-PRESS, Warszawa 2002.

9. Soh C., Sia Siew K., Tay-Yap J.: Enterprise resource planning: cultural fits and misfits: is ERP a universal solution?, Communications of the ACM, ACM Press, Nowy Jork 2000, 47-51. 10. Szyjewski Z.: Zarządzanie Projektami Informatycznymi, Agencja Wydawnicza Placet,

Warszawa 2001.

RISK MANAGEMENT OF ADOPTING ERP SYSTEM TO ORGANISATION Summary

The main aim of this article is identification of risks and constraints that result from changes to standard ERP software code during the process of tailoring the off-the-shelf package and the analysis of possible solutions to minimize those risk fac-tors.

The first part of the article contains definition of implementation project, fol-lowed by the description of a mechanism of standard Enterprise Resource Planning software modifications. The second part is concentrated on risk identification that results from system modifications, its assessment and proposed potential risk treat-ments. The summary table of various identified risks is based on literature research that deals with ERP system implementations and the observations of the author of this article during her project activities as an implementation consultant.

Keywords: implementation project, modifications of standard ERP systems, risk management

MAGDALENA KOTARBA Wydział Zarządzania Uniwersystet Warszawski Ul. Szturmowa 1/3 02 – 678 Warszawa magdakotarba@yahoo.com