ZARZ DZANIE RYZYKIEM ZWI ZANYM Z DOPASOWANIEM SYSTEMU ERP DO ORGANIZACJI

Transkrypt

1 ZARZ DZANIE RYZYKIEM ZWI ZANYM Z DOPASOWANIEM SYSTEMU ERP DO ORGANIZACJI MAGDALENA KOTARBA Uniwersytet Warszawski Streszczenie Celem niniejszego artykułu jest przedstawienie zagro e wynikaj cych ze zmian programistycznych dokonanych w standardowym systemie klasy ERP w trakcie procesu 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 oprogramowania wspomagaj cego zarz dzanie w przedsi biorstwie. Druga cz skoncentrowana jest na identyfikacji ryzyka powi zanego z modyfikacjami, jego ocenie oraz proponowanych metodach zapobiegawczych. Tabela zbiorcza zidentyfikowanych zagro 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 eniowych. 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. Oczekiwane 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 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 odno nie zakresu zmian programistycznych w zakupionym oprogramowaniu. Modyfikacje w strategicznych obszarach działalno ci s uzasadnione i brak dopasowania aplikacji do organizacji 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

2 Magdalena Kotarba Zarz dzanie ryzykiem zwi zanym z dopasowaniem systemu ERP do organizacji 81 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 puje, 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 dokonywania zmian programistycznych w standardowej aplikacji umo liwia odpowiednie przygotowanie działa zapobiegawczych w przypadku, kiedy wyst pi zdarzenie okre lone jako ryzykowne. Zarz dzanie ryzykiem w tej sytuacji polega jak wskazuje w swojej pracy W. Bielecki [1] na poszukiwaniu i podejmowaniu działa, które powinny stanowi zabezpieczenie przed poniesieniem strat wi kszych ni przyj ty poziom bezpiecze stwa. 2. Projekt wdro eniowy i modyfikacje systemu Wdro enie gotowego systemu klasy ERP to nowy rodzaj przedsi wzi informatycznych polegaj cy na przystosowaniu zakupionego oprogramowania do konkretnych warunków biznesowych 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 zasobami 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 zapasów o 30%, czas realizacji (terminy) czas rozpocz cia i zako czenia prac wyznacza ramy czasowe realizacji, jest podstaw do wyceny pracochłonno ci, koszty realizacji (bud et) monitorowanie bud etu polegaj ce na zestawieniu stopnia jego wykorzystania z planem wykonanych zada. W celu osi gni cia po danego stanu aplikacji podczas projektu wdro eniowego obok parametryzacji 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 implementacji systemu wspomagaj cego zarz dzanie nast puje porównanie wymaga zdefiniowanych przez przedsi biorstwo do funkcjonalno ci zawartej w standardowym oprogramowaniu. W swoich badaniach C. Soh, K. Sia Siew, J. Tay-Yap [9] pokazuj, e rozbie no ci pomi dzy zakupion aplikacj 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 powa nych modyfikacji, które wymagaj ingerencji w struktur bazy danych.

3 82 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 10, 2007 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 spowoduj dodanie nowych elementów do oprogramowania. Kiedy pojawi si sytuacja problemowa dotycz ca zgłoszenia zapotrzebowania na przeprowadzenie modyfikacji nale y: dokona wspólnie z u ytkownikami przegl du procesu i zaproponowa alternatywny sposób działania według tzw. najlepszych praktyk biznesowych, opracowa rozwi zanie w systemie bazuj c na standardowej funkcjonalno ci oraz zaprezentowa 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, kosztem i pracochłonno ci umo liwiaj podj cie optymalnej decyzji, czyli najlepszej w danych warunkach działania, odno nie zmian w standardowym oprogramowaniu. Wszystkie decyzje dotycz ce zmian w zakupionym pakiecie klasy ERP wi si z mo liwo ci konsekwencji niepomy lnych dla podmiotu dokonuj cego modyfikacji oraz dla przedsi biorstwa. Wykonane działania 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 przeszkód i zagro e mog cych wyst pi podczas procesu modyfikacji standardowego oprogramowania, a nast pnie ich monitorowanie. 3. Ryzyko zwi zane 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) do: W swojej pracy C. Pritchard [8] zaleca, by zarz dzanie ryzykiem podczas projektu zmierzało zmniejszania ryzyka, eliminowania ryzyka, je li to mo liwe i praktycznie uzasadnione, przygotowania alternatywnych sposobów działania,

4 Magdalena Kotarba Zarz dzanie ryzykiem zwi zanym z dopasowaniem systemu ERP do organizacji 83 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 ryzykiem w projektach wdro eniowych polega na tym, e ró ne strony, tj. dostawca systemu, u ytkownicy, 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 diagnozowanie 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 monitorowanie ryzyka. RYZYKO Zarz dzanie ryzykiem Identyfikacja Ocena Zapobieganie Monitorowanie 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 realizacj modyfikacji. Przed podj ciem jakichkolwiek działa powinna zosta sporz dzona lista zagro 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] informacje 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 prawdopodobie stwa wyst pienia negatywnej sytuacji oraz jej skutków. Podstaw analizy stanowi plany

5 84 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 10, 2007 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 parametrem, 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 zabezpieczania 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 minimalizacj 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 awaryjnym, opracowanym wcze niej na etapie oceny ryzyka. Transfer ryzyka polegaj cy na przeniesieniu cało ci lub cz ci negatywnych skutków zdarze 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 tnie stosowana, gdy zwi zana jest z zamro eniem 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 projektu. 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 zarz dzaniem ryzykiem powinny by na bie co dokumentowane. Najcz stsze zagro enia mog ce wyst pi podczas procesu dopasowania gotowych pakietów do organizacji zostały przedstawione w tabeli poni ej, ł cznie z ocen ryzyka oraz sugerowanymi 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 ytkownicy cz sto próbuj przenie obecny stan do nowego systemu. Takie podej cie mo e by kosztowne oraz wi e si z zagro eniem przeniesienia dotychczasowych problemów do nowej aplikacji. Opracowanie procedury zatwierdzania modyfikacji. Wskazane jest, by zmiany w standardowym oprogramowaniu były akceptowane przez Komitet Steruj cy.

6 Magdalena Kotarba Zarz dzanie ryzykiem zwi zanym z dopasowaniem systemu ERP do organizacji 85 Identyfikacja ryzyka Ocena ryzyka Zapobieganie Brak zrozumienia działania systemu przez zespół wdro eniowy mo e powodowa zgłaszanie modyfikacji, które nie s potrzebne, gdy gotowy pakiet zawiera wymagan funkcjonalno. Dokonanie niepotrzebnych modyfikacji mo e okaza si bardzo kosztowne. Ponadto istnieje ryzyko, e wprowadzone zmiany spowoduj niestabilno standardowej aplikacji. Przeszkolenie zespołu wdro eniowego oraz innych decydentó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 przeprowadzone w obszarach, które nie wymagaj zmian z punktu widzenia strategii przedsi biorstwa. Zmieniaj ce si cele najwy szego kierownictwa oraz brak decyzyjnej kadry mo e skutkowa wprowadzeniem zmian do systemu, które b d kosztowne, ale nie zostan zaakceptowane przez klienta. Do pracy na projekcie wdro eniowym powinni zosta oddelegowani u ytkownicy znaj cy cele oraz wymagania firmy. Wskazane jest, by ka da decyzja tych osób odno nie kastomizacji została zaakceptowana przez Komitet Steruj cy. Niedoszacowanie kosztu modyfikacji. Niedoszacowanie czasu potrzebnego na wykonanie zmiany. Du a ilo wprowadzonych zmian do standardowego oprogramowania mo e spowodowa, e reinstalacja nowej wersji, tzw. upgrade b dzie trudny do wykonania, a mo e nawet niewykonalny. Wysoki koszt zwi ksza ryzyko przekroczenia bud etu przeznaczonego na wdro enie. Zbyt niski szacunek mo e prowadzi do powstania problemów w trakcie realizacji, kiedy prace wykonywane b d przy ograniczonych rodkach. Harmonogram wykonania modyfikacji oparty na optymistycznych zało eniach, które nie b d realizowalne. Brak mo liwo ci aplikacji automatycznych aktualizacji przygotowanych przez dostawc systemu oraz brak reinstalacji nowej wersji uniemo liwi korekt wykrytych bł dów w aplikacji. Koszt modyfikacji powinien by oszacowany przez specjalistów, którzy b d wykonywali zmiany. W trakcie realizacji projektu wszystkie wydatkowane rodki finansowe powinny by monitorowane pod k tem bud etu. W trakcie realizacji wszystkie odchylenia od harmonogramu powinny by na bie co raportowane. W przypadku reinstalacji nowej wersji potrzebni b d programi- ci, którzy przed rozpocz ciem procesu tzw. upgradu sprawdz, gdzie kod programu jest zmodyfikowany oraz wprowadz odpowiednie zmiany.

7 86 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 10, 2007 Identyfikacja ryzyka Ocena ryzyka Zapobieganie Wiele bł dów w zmodyfikowanym 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 pojawiania si bł dów w rodowisku produkcyjnym. Brak dokumentacji odno nie wykonanych zmian programistycznych. Bez dokładnego opisu wykonanych modyfikacji wsparcie systemu ju po uruchomieniu mo e okaza si bardzo trudne, a nawet niemo liwe. Procedura wykonania modyfikacji powinna zakłada obowi zkowe przygotowanie dokumentacji przez przydzielonego analityka. Brak odpowiednio wyszkolonych pracowników, którzy b d wspierali system ju po zmianach. Konsultanci zewn trzni nie b d w stanie wiadczy odpowiednich usług z powodu zmian dokonanych w standardowej aplikacji. Utrzymanie i wsparcie systemu tzw. support mo e sta si bardzo trudny, a zatem kosztowny. Dostawcy standardowych systemów zwykle nie oferuj wsparcia w przypadku dokonania modyfikacji w oprogramowaniu. Wdro enie powinno równocze- nie słu y przygotowaniu pracowników firmy do wsparcia systemu działaj cego w rodowisku produkcyjnym. Członkowie zespołu wdro eniowego powinni by super u ytkownikami znaj cymi funkcjonalno standardow oraz wszystkie zmiany dokonane w jej oprogramowaniu. 4. Uwagi ko cowe Zmiany wprowadzone do kodu standardowego oprogramowania gwarantuj wi ksze dopasowanie 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 zrozumienia standardowej funkcjonalno ci pakietu przez uczestników wdro enia, ch ci przeniesienia 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 programistycznych 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 pakietu klasy ERP zaleca si od pocz tku przedsi wzi cia wdro eniowego stał obserwacj projektu

8 Magdalena Kotarba Zarz dzanie ryzykiem zwi zanym z dopasowaniem systemu ERP do organizacji 87 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łaszania oraz zatwierdzania modyfikacji, testowania 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 znaczeniu, 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, przygotowywanie ogólnodost pnych raportów maj cych na celu odpowiednio wczesne wykrycie nowych zagro e i ocen prowadzonych działa zapobiegawczych. Zarz dzanie ryzykiem zwykle stanowi słaby punkt projektów informatycznych, gdy kierownictwo 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 przeszkó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 przewidywaniu potencjalnych, negatywnych zdarze i podejmowaniu odpowiednich kroków zapobiegawczych 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 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, Forecast: ERP Software, Worldwide, , 3Q04 Update, 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, Nowicki A.: Strategia doskonalenia systemu informacyjnego w zarz dzaniu przedsi biorstwem, Wydawnictwo Akadamii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław 1999.

9 88 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 10, Nowicki A., Unold J. /red/,: Organizacyjne aspekty doskonalenia systemów informacyjnodecyzyjnych zarz dzania, Wydawnictwo Akademii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław Pa kowska M.: Zarz dzanie zasobami informatycznymi, Difin, Warszawa Pritchard C.: Zarz dzanie ryzykiem w projektach, Teoria i praktyka, WIG-PRESS, Warszawa 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, Szyjewski Z.: Zarz dzanie Projektami Informatycznymi, Agencja Wydawnicza Placet, Warszawa 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 offthe-shelf package and the analysis of possible solutions to minimize those risk factors. The first part of the article contains definition of implementation project, followed 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 treatments. 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/ Warszawa magdakotarba@yahoo.com