Mgr Magdalena Kotarba

Transkrypt

1 PROBLEMY WYSTĘPUJĄCE PODCZAS MODYFIKACJI STANDARDOWEGO SYSTEMU KLASY ERP I SPOSOBY ICH POKONANIA NA PRZYKŁADZIE WDROŻENIA SYSTEMU ORACLE J.D. EDWARDS ENTERPRISE ONE W PRZEDSIĘBIORSTWIE Z BRANŻY SPOŻYWCZEJ Mgr Magdalena Kotarba Wprowadzenie Przedstawiony w niniejszym artykule przypadek dotyczy problemów związanych z dokonaniem modyfikacji standardowego oprogramowania klasy ERP na przykładzie wdrożenia systemu Oracle J.D. Edwards EnterpriseOne w przedsiębiorstwie z branży spożywczej (nazwa nie zostanie w tekście ujawniona i od tego miejsca stosowane będzie określenie Przedsiębiorstwo ). Celem pracy obok zdefiniowania problemów jest przede wszystkim analiza sposobów ich pokonania. Opisywane Przedsiębiorstwo należy do czołówki światowych producentów i dystrybutorów świeżych owoców i warzyw. Prowadzi sprzedaż w 90 krajach osiągając przychody rzędu 5 miliardów dolarów rocznie. Mając na uwadze, iż nowoczesną firmą nie można dzisiaj zarządzać bez odpowiedniego systemu informatycznego zapewniającego szybki dostęp do informacji, zarząd europejski koncernu zdecydował w 2002 roku o wdrożeniu zintegrowanej aplikacji wspomagającej zarządzanie w oddziałach obejmujących Hiszpanię, Francję, Niemcy i Włochy. Wybór padł na korporacyjne oprogramowanie Oracle J.D. Edwards EnterpriseOne.

2 Przedsięwzięcie wdrożeniowe rozpoczęto w 2003 roku od zdefiniowania procesów biznesowych oraz poznania specyfiki organizacji we wszystkich wymienionych krajach. W wyniku prac stwierdzono, że system należy dopasować do organizacji w wielu obszarach w celu osiągnięcia jak największej użyteczności z oprogramowania. Użyteczność w tym wypadku była rozumiana jako satysfakcja z posiadania aplikacji umożliwiającej wykonywanie zadań o strategicznym znaczeniu, wspomagającej codzienną pracę użytkowników oraz dostarczającej wymaganych informacji zarządowi zarówno na szczeblu lokalnym, jak i europejskim. Rozpoznane rozbieżności pomiędzy aplikacją Oracle J.D. Edwards EnterpriseOne a zdefiniowanymi wymaganiami Przedsiębiorstwa przede wszystkim obejmowały: rozbieżności funkcjonalne brak wbudowanych rozwiązań umożliwiających obsługę procesów biznesowych specyficznych dla Przedsiębiorstwa, np.: analiza marży na poziomie centrum dystrybucyjnego, obsługa dostawców na zasadach rozliczenia prowizyjnego z tytułu osiągniętej sprzedaży dostarczonej partii, wydruk faktury z modułu zobowiązań w przypadku kiedy dostawca nie jest zobligowany prawnie do wystawiania faktur. rozbieżności dotyczące prezentacji wyników programy interaktywne oraz standardowe raporty nie przedstawiały wszystkich wymaganych danych lub sekwencja prezentacji była niesatysfakcjonująca, np.: program do wprowadzania zleceń sprzedaży nie pokazywał wagi netto produktu, wagi opakowania oraz wagi brutto,

3 nazwa kontrahenta nie wyświetlała się na wszystkich wymaganych programach interaktywnych, raporty dotyczące analizy zobowiązań oraz należności nie zawsze wyświetlały informacje o centrach kosztowych. Strategia wdrożenia zakładała implementację pilotażową całej funkcjonalności, która obejmowała moduły finansowe i dystrybucyjne łącznie z odpowiednio zaprojektowanymi modyfikacjami we Włoszech, a następnie tzw. roll-out w pozostałych oddziałach Przedsiębiorstwa. Roll-out w tym wypadku miał polegać na wdrożeniu włoskiego modelu w identycznym zakresie w pozostałych krajach. Wdrożenie standardowego systemu klasy ERP w organizacji Implementacja oprogramowania wspomagającego zarządzanie ma na celu dostosowanie systemu do organizacji oraz jego integrację z procesami w niej zachodzącymi. Zasady wdrożenia systemu informatycznego klasy ERP zależą od zakresu dziedzinowego obsługiwanych funkcji, właściwości technicznych pakietów, zakresu wymaganej adaptacji, strategii wypracowanej przez dostawcę aplikacji oraz warunków istotnych dla użytkownika [Klon04]. Implementacja pakietu przebiega w ramach projektu charakteryzującego się oznaczonym czasem rozpoczęcia i zakończenia, zdefiniowanymi celami oraz wyznaczonymi zasobami przeznaczonymi na jego realizację [Pank01]. 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

4 z określeniami powszechnie przyjętymi w literaturze cybernetycznej pożądany stan systemu można zdefiniować jako uporządkowany zbiór wartości parametrów, który zapewnia osiągnięcie celów przedsiębiorstwa [Nowi99]. 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 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 odnośnie 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 [SoST00]. Modyfikacje są procesem, który powinien być zorganizowany według następującego schematu: ETAP I - formułowanie zadania modyfikacji polegające na opisie celu i zakresu zmian, które muszą zostać dokonane w standardowym programie. W tej fazie powinien zostać przygotowany odpowiedni dokument zawierający opis żądanej przez użytkownika modyfikacji łącznie z uzasadnieniem powodu jej przeprowadzenia.

5 ETAP II dobór odpowiedniej metody wykonawczej mając na uwadze istniejące ograniczenia zasobów technicznych oraz finansowych. ETAP III dokonanie modyfikacji na podstawie uzgodnionej metody wykonawczej oraz przeprowadzenie testów. ETAP IV - implementacja zmian oraz ich integracja z resztą systemu. Alternatywę dla modyfikacji stanowi wprowadzenie zmian w firmie oraz reorganizacja procesów w ramach tzw. najlepszych praktyk biznesowych. W rzeczywistości każda organizacja decydująca się na implementację standardowego oprogramowania klasy ERP powinna być gotowa na zmiany, tak by pod płaszczykiem nowego pakietu nie odtwarzać starych procedur, które warunkowały decyzję o wdrożeniu gotowej aplikacji [Pary00]. Przedsiębiorstwa jednak bardzo rzadko decydują się na implementację zintegrowanego systemu wspomagającego zarządzanie bez żadnych modyfikacji, gdyż to oznacza restrukturyzację procesów biznesowych oraz przeprowadzenie zmian organizacyjnych, które mogą się spotkać z dużym oporem ze strony pracowników. Dodatkowo restrukturyzacja dokonana w celu przystosowania procedur działania organizacji do zintegrowanego systemu wydłuża czas projektu, co powoduje, że wszelkie zmiany procesowe są postrzegane jako czynnik hamujący wdrożenie oraz podnoszący koszty [Pary00]. Organizacja decydująca się na wdrożenie standardowego pakietu zwykle musi podjąć decyzję odnośnie koniecznych modyfikacji, tak by znaleźć równowagę pomiędzy dopasowaniem dotyczącym celów strategicznych przedsiębiorstwa oraz służącym jedynie do spełnienia potrzeb użytkowników broniących się przed zmianami. Modyfikacje dokonane w strategicznych obszarach działalności są uzasadnione i brak dostoso-

6 wania systemu do organizacji może wpływać na jej pozycję rynkową, np. współpracę z dostawcami czy relacje z klientami. Z kolei zgoda na wszystkie zgłoszone przez użytkownika zapotrzebowania dotyczące zmiany kodu w gotowym pakiecie wpłynie na budżet, harmonogram oraz jakość implementacji. System Oracle J.D. Edwards EnterpriseOne Oracle JD Edwards EnterpriseOne od strony funkcjonalnej należy do czołówki dostępnych na świecie rozwiązań wspomagających zarządzanie przedsiębiorstwem, wybrało go ponad klientów w 150 krajach [według informacji podanej na stronie firmy Hogart, System przeznaczony dla średnich i dużych organizacji posiada narzędzia wspomagające sprawozdawczość ekonomiczno finansową oraz optymalizujące łańcuch dostaw, procesy produkcyjne i obsługę handlu elektronicznego. Oprogramowanie stanowi w pełni zintegrowany zestaw aplikacji o charakterze modułowym, który jest przeznaczony przede wszystkim dla następujących branż: produkcyjnej, spożywczej, odzieżowej i obuwniczej, dystrybucyjnej, budowlanej, farmaceutycznej i usługowej. Do podstawowych funkcjonalności wybieranych najczęściej przez klientów decydujących się na wdrożenie systemu Oracle J.D. Edwards EnterpriseOne należy obsługa finansów (Księga główna, Zobowiązania, Należności), dystrybucji (Gospodarka magazynowa, Zaopatrzenie, Zarządzanie sprzedażą) oraz produkcji (Zarządzanie danymi o wyrobach, Zarządzanie produkcją). Moduły zorganizowane są w pakiety, które

7 w trakcie wdrożenia można uzupełnić o dowolną funkcjonalność z innego obszaru działalności firmy. System Oracle J.D. Edwards EnterpriseOne bazujący na architekturze internetowej umożliwia integrację oprogramowania dzięki zastosowaniu jednej platformy sprzętowej oraz wspólnego środowiska programistycznego. Pozwala na korzystanie z wielu baz danych (DB2, MS SQL, Oracle) oraz działa na różnych systemach operacyjnych (i5/os dawniej OS/400, Unix, Windows, Linux). Dostarczane sterowniki i łatwość tworzenia interfejsów w oparciu o technologie EDI i XML umożliwiają swobodną wymianę danych z innymi aplikacjami działającymi w przedsiębiorstwie, np. specjalistyczne systemy produkcyjne, systemy telesprzedażowe itp. [na podstawie informacji dostępnych na stronie internetowej firmy Oracle, applications/jdedwards -enterpriseone.htm]. Do klientów systemu Oracle J.D. Edwards EnterpriseOne należą: Bakoma, BIC, Bonduelle, Castrol, Chevron, Coty, Dole, Elektrolux, Fujitsu, Gerber, Harley Davidson, Huta Szkła Owens Illinois, Johnson & Johnson, Lafarge, Lexmark, Michelin, Mobil, Reckitt Benckiser, Samsonite, Securitas, Silver Sreen, Shell, Sony Music, Wall Mart, Wyeth. Problemy związane z modyfikacjami oraz sposoby ich pokonania w Przedsiębiorstwie Zmiany wprowadzone do kodu standardowego oprogramowania wspomagającego zarządzanie klasy ERP należą ze swej natury do ryzykownych przedsięwzięć i należy mieć na uwadze możliwość pojawienia

8 się problemów podczas procesu modyfikacji. W Przedsiębiorstwie już na początku projektu wdrożeniowego zdecydowano, że celem implementacji nowego oprogramowania jest przede wszystkim otrzymanie systemu o jak największym dopasowaniu do organizacji, który będzie wspomagał wykonywanie czynności codziennych oraz okresowych pracowników i kadry zarządzającej. Przygotowany plan projektu obejmował oszacowany czas i koszty związane z wymaganymi zmianami programistycznymi, a także zakładał pewien margines bezpieczeństwa zarówno w harmonogramie, jak i budżecie na wypadek dokonania błędnego szacunku odnośnie planów przeprowadzenia modyfikacji. W trakcie trwania projektu wdrożeniowego oraz wykonywania czynności związanych z optymalnym dopasowaniem gotowego pakietu do Przedsiębiorstwa zaobserwowano pojawiające się problemy zarówno organizacyjne, jak i techniczne. W celu zminimalizowania zagrożeń związanych z modyfikacjami systemu Oracle J.D. Edwards EnterpriseOne stopniowo wprowadzano odpowiednio przygotowane procedury postępowania. Zdefiniowane problemy łącznie z zaproponowanymi sposobami ich pokonania zostały przedstawione w tabeli poniżej. Tabela 1 Problemy związane z modyfikacjami i sposoby ich pokonania Problem Sposób pokonania problemu Brak zrozumienia działania standardowego systemu przez zespół wdrożeniowy powodował zgłaszanie modyfikacji, które nie były potrzebne, gdyż gotowy pakiet zawierał wymaganą funkcjonalność. Podczas całego okresu trwania projektu przywiązywano dużą wagę do szkoleń kluczowych użytkowników odnośnie standardowej funkcjonalności oraz procesów obsługiwanych przez system. W przypadku wątpliwości organizowano spotkania, w których uczestniczyli zarówno człon-

9 kowie zespołów wdrożeniowych, jak i ich menadżerowie. Celem było wspólne omówienie nowego procesu oraz podjęcie decyzji o konieczności zgłoszenia modyfikacji. W czasie trwania projektu wdrożeniowego kluczowi użytkownicy poszczególnych krajów mieli tendencje do żądania wszystkich funkcjonalności, które posiadali w dotychczas użytkowanym systemie. Często nie starali się zrozumieć możliwości nowej aplikacji dążąc do odwzorowania stanu obecnego i nie godząc się na żądne ustępstwa. Takie podejście mogło okazać się nie tylko kosztowne, ale również istniało zagrożenie przeniesienia istniejących problemów do nowego oprogramowania. Brak komunikacji na projekcie między zespołem wdrożeniowym a najwyższym kierownictwem powodował rozbieżność celów, gdyż często uczestnicy przedsięwzięcia nie mieli świadomości potrzeb organizacji. Tym samym istniało ryzyko, że modyfikacje zostaną przeprowadzone w obszarach, które nie wymagały zmian z punktu widzenia strategii przedsiębiorstwa oraz jego kadry zarządczej. Często trudno było oszacować koszt oraz czas związany z przeprowadzeniem modyfikacji. Wysoki koszt zwiększał ryzyko przekroczenia budżetu przeznaczonego na wdrożenie. Opracowano procedurę zatwierdzania modyfikacji. Każde żądanie wprowadzenia zmiany podlegało rejestracji, a następnie szczegółowej analizie przez odpowiednio przypisanego analityka. Modyfikacje wymagające prac programistycznych musiały zostać zaakceptowane przez Komitet Sterujący. Z kolei zmiany odnośnie parametryzacji różnej niż zakładał model systemu, musiały zdobyć akceptację lidera funkcjonalnego oraz kierownika projektu. Zgłaszane zapotrzebowania na modyfikacje programistyczne musiał zaakceptować Komitet Sterujący, w skład którego wchodziło najwyższe kierownictwo organizacji, zarówno szczebla lokalnego, jak i europejskiego. Opracowano procedurę planowania godzin wymaganych do przeprowadzenia zmian programistycznych łącznie z czasem potrzebnym na testy. Procedura zakładała we wstępnej fazie opracowanie dokumentu wymaganych zmian przez przydzielonego analityka. Następnie dokument podlegał analizie przez kierownika projektu oraz programistę, których zadaniem było jak najdokładniejsze oszacowanie kosztu związanego z dokonaniem modyfikacji. W trakcie realizacji zmian programistycznych wszystkie wydatkowane środki finansowe były monitorowane pod kątem

10 budżetu. Duża ilość wprowadzonych zmian do standardowego oprogramowania spowodowała, że instalacja automatycznych aktualizacji przygotowanych przez dostawcę systemu stała się niemożliwa. W rezultacie nie można było stosować szybkiej korekty wykrytych błędów w aplikacji. Szczególnie w pierwszym etapie projektu wdrożeniowego pojawiało się wiele błędów w zmodyfikowanych programach, co często zakłócało działanie standardowych aplikacji i powodowało niestabilność systemu. Ponadto zdarzyły się przypadki, że błędy uniemożliwiały pracę ze zmodyfikowanym programem. Od początku projektu istniało ryzyko, iż nie wszystkie zmiany programistyczne zostaną odpowienio udokumentowane. Bez dokładnego opisu wykonanych modyfikacji mogłoby być bardzo trudno wspierać system już po uruchomieniu. Zagrożenie odnośnie braku odpowiednio wyszkolonych pracowników, którzy mogli wspierać zmodyfikowany system. Dostawcy standardowych Na początku projektu wdrożeniowego wynegocjowano z dostawcą standardowego systemu, że kiedy ten przygotuje automatyczną aktualizację i jej instalacja będzie konieczna w celu zapewnienia prawidłowości działania systemu, wówczas dostarczony zostanie do Przedsiębiorstwa kod źródłowy przygotowanej aktualizacji. Odpowiednie zmiany były wprowadzane przez programistów zatrudnionych przez korporację, tak by zachować funkcjonalność zmodyfikowanych wersji i jednocześnie zaaplikować aktualizacje. Opracowano specjalną procedurę odnośnie testów zmodyfikowanego programu, co miało zapewnić jak najdokładniejsze sprawdzenie każdej wprowadzonej zmiany programistycznej. Procedura zakładała: testy w środowisku programistycznym przez programistę i przydzielonego analityka, testy w środowisku testowym przez użytkownika kluczowego z danej organizacji, po pozytywnym wykonaniu testów oraz zatwierdzeniu zmiana mogła być przeniesiona do środowiska produkcyjnego. Każda zmiana programistyczna dokonana w systemie musiała być udokumentowana. Procedura wykonania modyfikacji zakładała przygotowanie odpowiedniej dokumentacji przez przydzielonego analityka. Brak dokumentu równoznaczny był z brakiem zgody na przeniesienie zmiany do środowiska produkcyjnego. Przedsiębiorstwo stworzyło europejskie centrum wsparcia użytkowników systemu, zatrudniając konsultantów pracujących podczas wdrożenia. Po-

11 systemów zwykle nie oferują wsparcia w przypadku dokonania modyfikacji w oprogramowaniu. Źródło: Opracowanie własne nadto członkowie zespołu wdrożeniowego stali się super użytkownikami znającymi funkcjonalność standardową oraz wszystkie zmiany dokonane w oprogramowaniu. Na bieżąco opracowywano szczegółową dokumentację odnośnie parametryzacji systemu oraz wszystkich wykonanych zmian programistycznych. Niestety pomimo stosowania odpowiednich procedur związanych z wykonaniem zmian programistycznych w standardowej aplikacji nie udało się całkowicie wyeliminować zagrożeń związanych z modyfikacjami. W trakcie trwania projektu wdrożeniowego zdarzyły się w Przedsiębiorstwie następujące sytuacje: Wprowadzono modyfikacje, które nie były konieczne, a zostały zgłoszone przez użytkowników słabo przeszkolonych oraz chcących posiadać dotychczasowe rozwiązania w nowym systemie. Po zakończeniu wdrożenia ci sami użytkownicy często przyznawali, że zmiany programistyczne nie były potrzebne, gdyż podobne informacje mogli znaleźć np. przeglądając odpowiedni program interaktywny. Często planowany czas i koszt przeznaczony na przeprowadzenie modyfikacji był niedoszacowany, co w efekcie spowodowało przekroczenie budżetu przeznaczonego na implementacje standardowego oprogramowania. Pojawiające się błędy w zmodyfikowanej aplikacji powodowały dodatkowe koszty związane z pracami programistycznymi oraz testami, a użytkownicy pracując już w systemie produkcyjnym musieli znajdować alternatywne sposoby działania w okresie naprawy programu.

12 Podsumowanie Przedsiębiorstwo podeszło do procesu wdrożenia standardowego systemu klasy ERP oraz jego dopasowania do organizacji bardzo profesjonalnie. Z jednej strony postanowiono, że nowe oprogramowanie musi spełniać wymagania europejskich oddziałów koncernu, z drugiej jednak wzięto pod uwagę możliwość pojawienia się problemów związanych z modyfikacjami oraz odpowiednio wcześnie zaczęto wprowadzać procedury mające na celu minimalizację wystąpienia potencjalnych zagrożeń. Opracowane reguły oraz system zarządzania zmianami miały na celu zachowanie spójności i integralności przedsięwzięcia oraz zabezpieczenie osiągnięcia zakładanej jakości [Frac03]. Ponadto miały umożliwić wprowadzanie modyfikacji do standardowego pakietu w sposób bezkonfliktowy. Realizację procesu modyfikacji w Przedsiębiorstwie zawsze rozpoczynano od dokładnego opisania celu zmiany oraz sposobów jej osiągnięcia, tj. ustalano wykonawców oraz kryteria działania mając na uwadze ograniczone zasoby techniczne oraz ekonomiczne. Każda zgłoszona modyfikacja programistyczna posiadała odrębną dokumentacją zawierającą informacje dotyczące zakresu zmiany oraz wymaganego czasu potrzebnego na jej przeprowadzenie. Jednocześnie organizowano szkolenia kluczowych użytkowników oraz spotkania z kadrą zarządzającą mające na celu jak najdokładniejsze przekazanie informacji o standardowej funkcjonalności systemu. Zrozumienie nowego oprogramowania wśród pracowników

13 Przedsiębiorstwa miało zapewnić, że potrzebne modyfikacje zostaną zgłoszone tylko w strategicznych dla organizacji obszarach. Oczywiście wprowadzone procedury nie wyeliminowały całkowicie problemów, czego jednak przy tak dużej skali projektu implementacyjnego należało się spodziewać. Pomimo tego należy zdecydowanie stwierdzić, że podjęte próby minimalizacji zagrożeń i sposoby pokonania problemów były odpowiednio zaplanowane oraz wdrożone. Obecnie Przedsiębiorstwo posiada nowoczesny system informatyczny dostosowany do specyficznych potrzeb koncernu działającego na rynku globalnym w branży spożywczej. Zarówno pracownicy, jak i kadra zarządzająca są zadowoleni z oferowanych rozwiązań, które umożliwiają im optymalizację stanów magazynowych, zamówień, a także kontaktów z dostawcami oraz klientami Literatura [Frac03] [Klon04] [Nowi99] Frączkowski K.: Zarządzanie projektem informatycznym, Projekty w środowisku wirtualnym, Czynniki sukcesu i niepowodzeń projektów, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław Klonowski Z.: Systemy informatyczne zarządzania przedsiębiorstwem, Modele rozwoju i właściwości funkcjonalne, Oficyna Wydawnicza Politechnik Wrocławskiej, Wrocław Nowicki A.: Strategia doskonalenia systemu informacyjnego w zarządzaniu przedsiębiorstwem, Wydawnictwo

14 [Pank01] [SoST00] [Pary00] Akadamii Ekonomicznej im. Oskara Langego we Wrocławiu, Wrocław Pańkowska M.: Zarządzanie zasobami informatycznymi, Difin, Warszawa Soh C., Sia Siew K., Tay-Yap J.: Enterprise resource planing: cultural fits and misfits: is ERP a universal solution?, Communications of the ACM, ACM Press, Nowy Jork Parys T.: Zintegrowany system wspomagania zarządzania MRP II, [w:] Kasprzak T. (red.), Integracja i architektury systemów informacyjnych przedsiębiorstw, Katedra Informatyki Gospodarczej i Analizy Ekonomicznych Uniwersytet Warszawski, Warszawa Literatura źródła Internetowe Informacje o autorach Mgr Magalena Kotarba Wydział Zarządzania Uniwersytet Warszawski ul. Szturmowa Warszawa Polska Numer telefonu +48/ magdakotarba@yahoo.com