82 Streszczenie
W niniejszym artykule przedstawiono analizĊ czynnoĞci konsultantów podczas wdroĪenia systemu klasy ERP w kontekĞcie ich związku z zarządzaniem wiedzą. Bazu-jąc na analizie dokumentów Ĩródáowych z projektu wdroĪenia systemu klasy ERP scharakteryzowano równieĪ poszczególne fazy projektu, przedstawiono gáówne dzia-áania, realizowane w kaĪdej z faz oraz ich efekty. Z przeprowadzonej analizy wynika, iĪ ponad poáowa dziaáaĔ konsultantów miaáa związek z zarządzaniem wiedzą. Najbar-dziej intensywne dziaáania prowadzone byáy w fazie koncepcji biznesowej oraz wsparcia po starcie, jednak zarządzanie wiedzą byáo obecne we wszystkich fazach pro-jektu.
Sáowa kluczowe: systemy ERP, zarządzanie projektami, wiedza w projektach, konsultanci, wdroĪenie, system zintegrowany, metodyka wdroĪenia
Wprowadzenie
Tradycyjny nurt badawczy, dotyczący zarządzania projektami informatycznymi w ogólnoĞci, a projektami wdroĪenia systemów standardowych w szczególnoĞci, traktuje te projekty jako zestaw skáadników, takich jak czynnoĞci projektowe, ludzie, zasoby, budĪety, harmonogramy, które muszą byü odpowiednio zarządzane i kontrolowane, aby project zakoĔczyá siĊ spodziewanymi rezultatami, przy zachowaniu budĪetu i harmonogramu [11]. ChociaĪ taki sposób postrzegania projektów jest uzasadniony i skutkuje powstawaniem zestawów dobrych praktych zarządzania projektami, zawar-tych w licznych opracowaniach naukowych i praktycznych (zob. np. PMBOK [16]), moĪna równieĪ zauwaĪyü próby analizy fenomenu, jakim są projekty z innych perspektyw, jedną z których jest perspektywa zarządzania wiedzą (por. np.: [5], [8], [11]). Projekty wymagają zróĪnicowanej, czĊsto specjalistycznej wiedzy od uczestników, a takĪe wiąĪą siĊ z wielokierunkowymi przepáywami tej wiedzy [2], [4], [6]. Projekty informatyczne nie są w tym zakresie wyjątkiem i wymagają integracji wielu róĪnych rodzajów wiedzy w celu prawidáowego zamodelowania domeny projektu w konkret-nym Ğrodowisku informatyczkonkret-nym, przy jednoczeskonkret-nym zarządzaniu wszystkimi „tradycyjkonkret-nymi” aspektami, czyli zakresem, budĪetem, harmonogramem i ryzykiem [10], [11]. WdroĪenie systemu klasy ERP pozostaje jednym z najbardziej skomplikowanych i o najwiĊkszym zakresie spoĞród przedsiĊwziĊü informatycznych, polegających na implementacji standardowego (powielarnego) rozwiązania [12]. Oprócz wiedzy z zakresu zarządzania projektami, umoĪliwiającej zarządzanie za-kresem, budĪetem, harmonogramem i ryzykiem, wymaga takĪe integracji wiedzy o konkretnym systemie klasy ERP z wiedzą o specyfice organizacji, w celu odwzorowania tej drugiej w budowa-nym rozwiązaniu. Z tego wzglĊdu wiĊkszoĞü organizacji, podejmujących siĊ wdroĪenia systemu klasy ERP korzysta z pomocy wyspecjalizowanych konsultantów, dostarczających wiedzĊ o wdra-Īanym systemie [7], [9], [14]. Celem badania, którego wyniki zaprezentowano w niniejszym
83
artykule jest analiza czynnoĞci, wykonanych podczas projektu wdroĪenia systemu klasy ERP, w po-dziale na czynnoĞci związane i niezwiązane z zarządzaniem wiedzą. UmoĪliwi to okreĞlenie roli zarządzania wiedzą podczas prowadzenia projektów wdroĪenia systemów tej klasy.
1. Projekt wdroĪenia systemu klasy ERP w kontekĞcie zarządzania wiedzą
Projekt wdroĪenia systemu ERP swym zakresem obejmuje wiĊkszoĞü kluczowych procesów gospodarczych i angaĪuje znaczne zasoby organizacji, jednoczeĞnie powodując koniecznoĞü zarzą-dzania róĪnymi rodzajami wiedzy [1], [15]. Aby móc podjąü analizĊ czynnoĞci projektowych, skáadających siĊ na wdroĪenie systemu ERP, naleĪy w pierwszej kolejnoĞci ustrukturyzowaü proces prowadzenia samego projektu.
Esteves i in. [3] proponują podziaá projektu zgodnie z metodyką ASAP wdroĪenia systemu SAP na nastĊpujące fazy:
x Przygotowanie projektu – w którym dookreĞlany jest zakres projektu, jego budĪet i harmo-nogram, formowane są struktury i zespoáy projektowe, przygotowywana jest infrastruktura oraz definiowane są procedury projektowe;
x Koncepcja biznesowa – podczas której dokonywana jest analiza struktur organizacyjnych i procesów gospodarczych organizacji, a nastĊpnie opracowywany jest projekt ich odwzoro-wania w systemie informatycznym, wraz z koncepcją migracji danych ze starych systemów, x Realizacja – podczas której nastĊpuje konfiguracja systemu, opracowywane są rozszerzenia programistyczne, raporty, interfejsy oraz narzĊdzia migracji danych, a nastĊpnie system pod-lega testowaniu i poprawkom,
x Przygotowanie do startu – kiedy to przygotowywane jest Ğrodowisko produkcyjne i migro-wane są dane rzeczywiste, a takĪe szkoleni są uĪytkownicy koĔcowi,
x Start i wsparcie po starcie – polegający na uruchomieniu systemu, po którym nastĊpuje faza jego stabilizacji, poprawek napotkanych báĊdów, w wyniku czego system przechodzi w stan normalnej eksploatacji.
ChociaĪ w literaturze przedmiotu wystĊpują takĪe inne podejĞcia do strukturyzacji projektu in-formatycznego, z których najpopularniejszym jest ten, prezentowany w [17], ze wzglĊdu na fakt, iĪ w przypadku, bĊdącym przedmiotem analizy w empirycznej czĊĞci niniejszego artykuáu, stosowano metodykĊ zbliĪoną do metodyki ASAP, przyjĊto tu podziaá projektu na wymienione powyĪej fazy.
Kolejnym aspektem, którego usystematyzowanie jest niezbĊdne do przeprowadzenia analizy, jest typologia wiedzy, niezbĊdnej do realizacji projektu. RozwaĪając typologiĊ wiedzy w projekcie ERP Chan i Rosemann [1] wyróĪnili nastĊpujące jej typy:
x o projekcie – wiedzĊ o zasobach, budĪecie, harmonogramie, ryzykach i innych aspektach, niezbĊdnych do prowadzenia projektu;
x o organizacji – wiedzĊ o specyfice organizacji, w której nastĊpuje wdroĪenie, jej systemie wartoĞci, celach, strukturach organizacyjnych, procesach gospodarczych, zasobach; x o produkcie/systemie – wiedzĊ o specyfice konkretnego systemu ERP, który jest
przedmio-tem wdroĪenia: jego funkcjonalnoĞci, moĪliwoĞciach i ograniczeniach, sposobie wdraĪania; x techniczną – wiedzĊ z zakresu IT;
x biznesową – wiedzĊ z zakresu dziedzinowego, podlegającego wdroĪeniu (np. wiedzĊ o ra-chunkowoĞci, logistyce, organizacji produkcji);
84
NaleĪy zauwaĪyü, iĪ pierwsze trzy typy wiedzy są bezpoĞrednio związane z prowadzonym pro-jektem (powstają lub są wymieniane w trakcie trwania projektu), natomiast trzy kolejne poĞrednio umoĪliwiają prowadzenie projektu (zdolnoĞci komunikacyjne umoĪliwiają pracĊ w zespoáach pro-jektowych, wiedza biznesowa umoĪliwia zrozumienie domeny projektu, wiedza techniczna umoĪliwia realizacjĊ strony technologicznej). MoĪna wiĊc wiedzĊ w projekcie podzieliü na dwie podstawowe kategorie:
x wiedzĊ bezpoĞrednią – która powstaje lub jest wymieniana w trakcie projektu i/lub wchodzi w skáad jego produktu. Innymi sáowy – jest to wiedza, która podlega transformacji w wyniku dziaáaĔ projektowych;
x wiedzĊ poĞrednią – która uáatwia uczestnikom projektu jego prowadzenie, jednak nie podlega transformacji (lub podlega jej w niewielkim stopniu) w wyniku dziaáaĔ projektowych. W tym kontekĞcie naleĪaáoby rozróĪniü pomiĊdzy wiedzą o projekcie (budĪet, harmonogram, zakres, ryzyka – konkretnego projektu) a wiedzą o zarządzaniu projektami – przejawiającą siĊ zna-jomoĞcią metodyk zarządzania projektami i doĞwiadczeniem projektowym. W związku z tym do typologii wiedzy, przedstawionej przez Chan’a i Rosemann’a powinna zostaü dodana kolejna kate-goria: wiedza PM (project management) – ogólna wiedza o metodykach i sposobach zarządzania projektami.
W stosunku do typów wiedzy, skáadających siĊ na kategoriĊ wiedzy bezpoĞredniej, w trakcie trwania projektu, mają zastosowanie dziaáania, skáadające siĊ na cykl Īycia wiedzy. ChociaĪ auto-rzy, zajmujący siĊ tym zagadnieniem przedstawiają róĪne warianty cyklu Īycia wiedzy, czĊsto odmiennie nazywając poszczególne jego fazy, jak stwierdza Sedera [13], w wiĊkszoĞci przypadków moĪna wyróĪniü cztery podstawowe fazy cyklu Īycia:
x zdobywanie/tworzenie; x przechowywanie/zapisywanie, x transfer/rozpowszechnianie, x uĪytkowanie/aplikacja.
Jako Īe kaĪda czynnoĞü w projekcie wymaga od jego uczestników uĪytkowania wiedzy, posia-danej przed jego rozpoczĊciem lub zdobytej w trakcie jego trwania, ta faza cyklu Īycia zostanie pominiĊta w dalszej czĊĞci rozwaĪaĔ. W związku z tym, jako dziaáania związane z zarządzaniem wiedzą bĊdą traktowane tylko te dziaáania, które powodują transformacjĊ wiedzy: jej przepáyw, zmianĊ stanu (np. zwiĊkszenie zasobów wiedzy uczestnika projektu) lub zmianĊ formy wiedzy (np. z nieskodyfikowanej na skodyfikowaną):
x zdobywanie/tworzenie – tworzenie lub zdobywanie wiedzy w sposób inny niĪ poprzez jej transfer,
x przechowywanie/zapisywanie – kodyfikacja wiedzy pozyskanej lub wytworzonej, przepáyw wiedzy od uczestników do artefaktów,
x transfer/rozpowszechnianie – przepáyw wiedzy pomiĊdzy uczestnikami.
Model zarządzania wiedzą w projekcie wdroĪenia systemu klasy ERP, determinujący wymaga-nia w zakresie wymienionych powyĪej typów wiedzy dla uczestników projektu, dziaáawymaga-nia, związane z zarządzaniem wiedzą w poszczególnych jego fazach oraz wytworzone w wyniku tych dziaáaĔ ar-tefakty znajduje siĊ w [9].
85
W niniejszym artykule, bazując na modelu zaprezentowanym w [9], dokonana zostanie analiza iloĞciowa nakáadów pracy konsultantów w podziale na czynnoĞci związane i niezwiązane z zarzą-dzaniem wiedzą. Jako czynnoĞci związane z zarzązarzą-dzaniem wiedzą do celów niniejszego badania uznano te z nich, które powodują transformacjĊ wiedzy (zdobywanie/tworzenie, przechowywa-nie/zapisywanie, transfer rozpowszechanie). W związku z tym, w procesie badawczym zostaá poáoĪony nacisk na te typy wiedzy, które podlegają transformacji w wyniku aktywnoĞci projekto-wej, czyli wchodzące w skáad wiedzy bezpoĞredniej: wiedzĊ o projekcie, o produkcie/systemie i o organizacji.
2. Analiza przypadku
Pytanie badawcze, sformuáowane na potrzeby niniejszego artykuáu brzmi nastĊpująco: Jaki jest udziaá nakáadu czasu pracy konsultantów na czynnoĞci związane z zarządzaniem wiedzą, w podziale na poszczególne fazy cyklu Īycia wiedzy, w stosunku do caáoĞci nakáadów czasu pracy na realizacjĊ projektu?
Zastosowaną metodą badawczą jest analiza przypadku, w której jako metodĊ szczegóáową wy-korzystano analizĊ dokumentów Ĩródáowych – sprawozdaĔ z wykonanych czynnoĞci konsultantów (ang. Activity Reports) – AR.
Przedmiotem badania byá projekt wdroĪenia systemu SAP w przedsiĊbiorstwie produkcyjnym Ğredniej wielkoĞci, przeprowadzony zgodnie z przedstawioną w sekcji teoretycznej metodyką ASAP. Czas trwania projektu wynosiá piĊtnaĞcie miesiĊcy, a zakres obejmowaá nastĊpujące obszary funkcjonalne: finanse i controlling, zakupy i gospodarkĊ magazynową, sprzedaĪ i dystrybucjĊ oraz produkcjĊ. W trakcie trwania projektu konsultanci i programiĞci zaangaĪowani w jego realizacjĊ wypeániali sprawozdania z wykonanych czynnoĞci w cyklu tygodniowym. Zestawienia te zawieraáy krótki opis wykonanych czynnoĞci oraz czas ich trwania z dokáadnoĞcią do póá dnia. àącznie wy-stąpiáy 232 wpisy, dotyczące 681 dni pracy konsultantów i programistów, ze wzglĊdu na fakt, iĪ wiele czynnoĞci trwaáo wiĊcej niĪ jeden dzieĔ. PoniewaĪ kierownictwo projektu nie wypeániaáo sprawozdaĔ z wykonanych czynnoĞci, analiza ograniczyáa siĊ do konsultantów i programistów.
Wpisy te zostaáy zebrane w zbiorcze zestawienie i poddane kodowaniu wedáug nastĊpującego kryterium: Czy dziaáanie powodowaáo transformacjĊ wiedzy: jej przepáyw, zmianĊ stanu lub zmianĊ formy wiedzy?
W trakcie trwania caáego projektu 359 dni pracy (52,72% nakáadów pracy) konsultantów i pro-gramistów powodowaáo zmianĊ stanu lub formy wiedzy bezpoĞredniej projektu, co pokazuje, Īe projekt wdroĪenia systemu klasy ERP jest przedsiĊwziĊciem niezwykle intensywnym z punktu widzenia zarządzania wiedzą. PoniĪej przedstawiono rozbicie wyników wedáug faz projektu.
86 2.1. Przygotowanie projektu
W fazie przygotowania projektu uczestniczyli jedynie kierownicy projektu. Przygotowali oni KartĊ Projektu, zawierającą definicjĊ struktury i procedur projektowych, formaty i spososby doku-mentacji, ramowy harmonogram prac oraz podziaá obowiązków pomiĊdzy stronami projektu. Konsultanci nie uczestniczyli aktywnie w tej fazie projektu.
2.2. Koncepcja biznesowa
W fazie koncepcji biznesowej dokonywana jest analiza struktur organizacyjnych i procesów gospodarczych przedsiĊbiorstwa, znajdujących siĊ w zakresie projektu, a nastĊpnie wykonywany jest projekt odwzorowania tych struktur i procesów w systemie informatycznym. Zbierane są takĪe pozostaáe wymagania dotyczące przyszáego systemu: struktura i zawartoĞü raportów, specyfikacja interfejsów z innymi systemami informatycznymi, struktura danych, podlegających migracji z ak-tualnie wykorzystywanych systemów, które zostaną wyáączone po wdroĪeniu nowego rozwiązania, specyfikacja ewentualnych rozszerzeĔ programistycznych w stosunku do standardowej funkcjonal-noĞci systemu oraz wygląd i zawartoĞü wydruków, (ang.: RICEF – Reports, Interfaces, Conversions, Enhancements, Forms). Efektem koĔcowym prac w tej fazie jest dokument koncepcji biznesowej, zawierający projekt przyszáego systemu. Ze wzglĊdu na fakt, iĪ przedmiotem projektu jest wdroĪe-nie systemu standardowego, projekt systemu zawiera specyfikacjĊ odwzorowania struktury organizacyjnej przedsiĊbiorstwa za pomocą obiektów struktury w systemie, specyfikacjĊ ustawieĔ konfiguracyjnych systemu w poszczególnych obszarach funkcjonalnych oraz ogólną specyfikacjĊ wymienionych powyĪej elementów dodatkowych (RICEF).
Analiza opisów czynnoĞci, wykonanych w tej fazie przez konsultantów prowadzi do wniosku, Īe w fazie koncepcji biznesowej wykonywane byáy dwa podstawowe dziaáania:
1. Warsztaty z uĪytkownikami kluczowymi klienta, podczas których konsultanci poznawali specyfikĊ dziaáalnoĞci przedsiĊbiorstwa i zbierali wymagania wobec systemu, a takĪe pre-zentowali propozycje rozwiązaĔ w systemie;
2. Tworzenie dokumentów koncepcji biznesowej, realizowane samodzielnie przez konsul-tantów;
Inaczej mówiąc w fazie tej nastĊpowaá:
x transfer wiedzy o organizacji od uĪytkowników kluczowych do konsultantów;
x kodyfikacja wiedzy o organizacji oraz wiedzy o systemie w formie dokumentu koncepcji biznesowej;
x transfer wiedzy o systemie od konsultantów do uĪytkowników kluczowych (jako Īe pre-zentowane byáy propozycje rozwiązaĔ w systemie).
W fazie tej konsultanci przepracowali 139,5 dni, co stanowi 20,48% caáoĞci nakáadów pracy w projekcie. Wszystkie dziaáania konsultantów w fazie koncepcji biznesowej powodowaáy zmianĊ stanu lub formy wiedzy, co oznacza, Īe faza ta byáa najbardziej intensywną pod wzglĊdem zarzą-dzania wiedzą fazą projektu. Na transfer wiedzy w formie warsztatów, konsultanci przeznaczyli 91,5 dnia, co stanowi 13,44% caáoĞci nakáadów pracy i 66% nakáadów w analizowanej fazie. ZawartoĞü wpisów w zestawieniach czynnoĞci nie umoĪliwiáa przeanalizowania podziaáu tych na-káadów pomiĊdzy transfer wiedzy o organizacji od uĪytkowników do konsultantów oraz wiedzy o systemie od konsultantów do uĪytkowników. Z analizy zapisów wynika jednak, Īe zdecydowaną przewagĊ miaá ten pierwszy. Gáównym celem warsztatów byáo przekazanie wiedzy o organizacji
87
konsultantom w taki sposób, aby mogli oni zaprojektowaü przyszáe rozwiązanie w formie doku-mentu koncepcji biznesowej. Transfer wiedzy o systemie miaá jedynie charakter dodatkowy i poboczny.
Kodyfikacja wiedzy o organizacji oraz o systemie w formie dokumentu koncepcji biznesowej, zajĊáa konsultantom 48 dni, co stanowiáo 7,05% caáoĞci nakáadów na wdroĪenie i 34% nakáadów w fazie koncepcji biznesowej.
2.3. Realizacja
W fazie realizacji konsultanci konfigurują system zgodnie z zaáoĪeniami, zawartymi w koncep-cji biznesowej. Wraz z programistami wykonują oni takĪe specyfikacje techniczne prac programistycznych (RICEF), które nastĊpnie realizowane są przez programistów. Zespóá migracji przygotowuje narzĊdzia do migracji danych, które zasilane są nastĊpnie danymi z systemów wyáą-czanych, po ich przygotowaniu przez zespóá ze strony klienta. Zgodnie z metodyką ASAP, ostatnim dziaáaniem w fazie realizacji są testy.
Analiza opisów czynnoĞci, wykonanych w fazie realizacji wykazaáa, Īe są one w wiĊkszoĞü zgodne z teoretycznymi zaáoĪeniami metodyki ASAP. W fazie tej wykonano nastĊpujące dziaáania:
1. KonfiguracjĊ systemu zgodnie z zapisami koncepcji biznesowej;
2. Sporządzenie specyfikacji technicznych prac programistycznych, wykonane wspólnie przez konsultantów i programistów, z udziaáem uĪytkowników kluczowych klienta w celu doszczegóáowienia wymagaĔ, zebranych wstĊpnie w fazie koncepcji biznesowej;
3. Wykonanie prac programistycznych w zakresie interfejsów, wydruków, raportów i rozsze-rzeĔ standardowej funkcjonalnoĞci;
4. Sporządzenie koncepcji migracji i wykonanie narzĊdzi migracji danych.
Ze wzglĊdu na fakt, iĪ testy rozwiązaĔ przenikaáy dwie fazy projektu: realizacjĊ i przygotowa-nie do startu, zostaáy one wydzielone jako osobna kategoria.
Nakáady pracy w fazie realizacji (z wyáączeniem testów) wyniosáy 199 dni, co stanowi 29,22% caáoĞci nakáadów na wykonanie projektu. Dziaáania intensywne z punktu widzenia zarządzania wie-dzą zajĊáy 65 dni, czyli 32,66% nakáadów na wykonanie fazy realizacji. Dziaáania te obejmowaáy: x przygotowanie specyfikacji prac programistycznych: transfer wiedzy o organizacji i pro-dukcie od uĪytkownikow kluczowych i konsultantów do programistów. Zapisanie wiedzy w formie dokumentów specyfikacji technicznej;
x przygotowanie specyfikacji migracji – transfer wiedzy o organizacji od uĪytkowników kluczowych i konsultantów do zespoáu migracji. Zapisanie wiedz w formie specyfikacji plików migracyjnych.
Reasumując, dziaáania związane z zarządzaniem wiedzą miaáy w tej fazie charakter uszczegó-áowienia wiedzy o organizacji i sposobie realizacji jej wymagaĔ w systemie do formy umoĪliwiającej rozpoczĊcie prac programistycznych. Efektem koĔcowym byáy dokumenty specyfi-kacji technicznej w zakresie prac programistycznych i migracji.
88 2.4. Testy
Zgodnie z metodyką ASAP, testy systemu są ostatnią z czynnoĞci, wykonywanych w ramach fazy realizacji. Ze wzglĊdu jednak na fakt, iĪ we wdroĪeniu, bĊdącym przedmiotem analizy w ni-niejszym artykule, dziaáania związane z testowaniem nowego rozwiązania zachodziáy zarówno w fazie realizacji, jak i przygotowania do startu, zostaáy one przedstawione odrĊbnie.
W projekcie wdroĪenia systemu klasy ERP wyróĪnia siĊ od dwóch do czterech faz testów, z których kaĪda skáada siĊ z co najmniej dwóch iteracji, przedzielonych okresem wprowadzania poprawek. Testy prowadzone są w oparciu o scenariusze testowe, których wzorce dostarczane są przez konsultantów, a które są wypeániane przypadkami testowymi przez uĪytkowników kluczo-wych klienta. Zakres scenariuszy testokluczo-wych pokrywa siĊ z procesami gospodarczymi, zidentyfikowanymi i opisanymi w koncepcji biznesowej. Dodatkowo przeprowadzane są testy ra-portów, wydruków, interfejsów, rozszerzeĔ oraz migracji.
Dwie podstawowe fazy testów, wystĊpujące w wiĊkszoĞci projektów to:
1. Testy moduáowe – prowadzone w obrĊbie jednego obszaru funkcjonalnego (np. finanse, controlling, sprzedaĪ, zakupy, gospodarka magazynowa, produkcja). Ich celem jest sprawdzenie poprawnoĞci funkcjonowania poszczególnych czĊĞci rozwiązania informa-tycznego, w obrĊbie poszczególnych zespoáów funkcjonalnych. Testy powinny byü prowadzone przez uĪytkowników kluczowych, przy wsparciu konsultantów.
2. Testy integracyjne – podczas których sprawdzana jest poprawnoĞü realizacji w systemie procesów gospodarczych, przebiegających pomiĊdzy obszarami funkcjonalnymi (modu-áami). W testach uczestniczą poáączone zespoáy funkcjonalne i podobnie jak w
poprzednim przypadku, prowadzone są one przez uĪytkownikow kluczowych pod nadzo-rem konsultantów.
Fazą testów, poprzedzającą testy moduáowe, są testy wewnĊtrzne, prowadzone samodzielnie przez konsultantów w obrĊbie przypisanych im obszarów funkcjonalnych (moduáów). Celem tej fazy jest wstĊpne sprawdzenie poprawnoĞci funkcjonowania systemu i wyeliminowanie najbardziej ewidentnych báĊdów. Testy te są prowadzone bez uĪycia formalnych scenariuszy testowych i wy-stĊpują praktycznie zawsze, gdyĪ dobre praktyki wdroĪenia nakazują sprawdzenie produktu przed oddaniem go do formalnych testów z udziaáem przedstawicieli klienta, jednak nie zawsze są one formalnie wydzielonym krokiem w metodyce prowadzenia projektu.
W niektórych wdroĪeniach po testach integracyjnych nastĊpują testy akceptacyjne, które są for-malną podstawą do wstĊpnego odbioru systemu przez klienta i podjĊcia decyzji o przejĞciu do fazy przygotowania systemu do startu. Przebiegają one w identyczny sposób i czĊsto w oparciu o te same scenariusze, co testy integracyjne, dlatego w mniej sformalizowanych projektach faza ta jest pomi-jana, a akceptacja rozwiązania nastĊpuje po pomyĞlnym zakoĔczeniu testów integracyjnych.
W badanym projekcie testy zaangaĪowaáy 139,5 dni pracy konsultantów, co stanowiáo 20,48 % caáoĞci nakáadów na wdroĪenie. Dziaáania związane z zarządzaniem wiedzą zajĊáy w tej fazie 52,5 dnia, co stanowi 37,63 % nakáadów poniesionych na testy. Wysoki odsetek dziaáaĔ istotnych z punktu widzenia zarządzania wiedzą wynikaá z przyjĊtego zaáoĪenia, Īe faza testów posáuĪy do inkrementalnego transferu wiedzy o nowym rozwiązaniu informatycznym do uĪytkowników klu-czowych klienta. Testy moduáowe i integracyjne byáy wykonywane przez uĪytkowników kluczowych, pod nadzorem konsultantów, a uĪytkownicy kluczowi w czasie ich trwania wykony-wali dodatkowo instrukcje stanowiskowe. WydáuĪyáo to co prawda czas trwania testów, jednak
89
umoĪliwiáo znaczne ograniczenie czasu szkoleĔ, przy jednoczesnym wydáuĪeniu czasu transferu wiedzy. Powtarzanie tych samych kroków w kolejnych iteracjach testów umoĪliwiáo uĪytkownikom kluczowym utrwalanie wiedzy o nowym systemie.
Dziaáania, związane z zarządzaniem wiedzą dotyczyáy testów moduáowych i integracyjnych, wykonywanych przez uĪytkownikow kluczowych pod nadzorem konsultantów, podczas których na-stĊpowaá transfer wiedzy o systemie od konsultantów do uĪytkowników kluczowych.
2.5. Przygotowanie do startu
W fazie przygotowania do startu nastĊpuje przygotowanie Ğrodowiska produktywnego do bie-Īącej eksploatacji. W przypadku systemu SAP oznacza to przeniesienie konfiguracji i rozszerzeĔ z systemu testowego do systemu produktywnego za pomocą tzw. transportów (narzĊdzia SAP, umoĪliwiającego zapis i nastĊpnie automatyczne przeniesienie zmian w konfiguracji pomiĊdzy dwoma Ğrodowiskami SAP), oraz migracjĊ danych do systemu produktywnego (danych podstawo-wych, otwartych pozycji oraz bilansów otwarcia). Efektem tej fazy jest system gotowy do rozpoczĊcia w nim bieĪącej pracy. Dodatkowo, w tej fazie wykonywane są szkolenia uĪytkowników koĔcowych.
Faza ta spowodowaáa w badanym projekcie zaangaĪowanie 56 dni pracy konsultantów, co sta-nowiáo 8,22% caáoĞci nakáadów. IloĞü osobodni, związanych z zarządzaniem wiedzą wyniosáa 12,5, czyli jedynie 22,32% nakáadów na caáą fazĊ i byáa związana ze szkoleniami uĪytkowników. Tak niewielka liczba dni szkoleĔ wynikaáa z dwóch powodów: przeszkolenia uĪytkowników kluczo-wych w fazie testów oraz niewielkiej liczby uĪytkowników, którzy nie uczestniczyli w projekcie (ze wzglĊdu na niewielkie rozmiary organizacji), a co za tym idzie ograniczoną koniecznoĞü prowadze-nia dodatkowych szkoleĔ.
2.6. Start i wsparcie po starcie
W fazie tej system przechodzi w stan bieĪącej eksploatacji. Jednak ze wzglĊdu na stopieĔ skom-plikowania, wymaga z reguáy wsparcia uĪytkowników przez konsultantów w pierwszych miesiącach uĪtytkowania. Wsparcie to polega na wyjaĞnianiu bieĪących wątpliwoĞci w zakresie sposobu realizacji procesów gospodarczych w systemie, a takĪe poprawianiu báĊdów, które nie zo-staáy wychwycone i wyeliminowane w fazie testów. W badanym projekcie wsparcie byáo realizowane na dwa sposoby:
1. Na miejscu, w siedzibie klienta, przez pierwszy miesiąc eksploatacji systemu oraz podczas procedury zamykania pierwszych trzech miesiĊcy. Ta czĊĞü wsparcia dotyczyáa gáównie pomocy w bieĪącej eksploatacji systemu.
2. Zdalnie, poprzez internetowy system zgáoszeniowy, gáównie w zakresie poprawek báĊdów, nieskorygowanych we wczeĞniejszych fazach.
Podczas tej fazy konsultanci wykonali 147 dni pracy, co stanowiáo 21,59% caáoĞci nakáadów, z czego 89,5 dnia (60,88% nakáadów w tej fazie) stanowiáy dziaáania zmieniające stan wiedzy w projekcie. W fazie tej nastĊpowaá transfer wiedzy szczegóáowej o systemie od konsultantów do uĪytkowników.
90 2.7. Podsumowanie wyników badania
IloĞciowe podsumowanie wyników przedstawiono w Tablicy 1 oraz na Schemacie 1. Tablica 1. Podsumowanie wyników badania
Faza projektu Nakáady w oso-bodniach
Udziaá w nakáa-dach ogóáem
Nakáady związane z za-rządzaniem wiedzą Udziaá w nakáa-dach fazy Koncepcja biz-nesowa 139,5 20,48% 139,5 100% Realizacja 199 29,22% 65 32,66% Testy 139,5 20,48% 52,5 37,63% Przygotowanie do startu 56 8,22% 12,5 22,32% Start i wsparcie 147 21,59% 89,5 60,88% Razem 681 100% 359 -
ħródáo: opracowanie wáasne.
Rys. 1. Podsumowanie wyników badania ħródáo: opracowanie wáasne.
Ponad 50% dziaáaĔ konsultantów w trakcie trwania caáego projektu miaáo charakter powodujące transformacjĊ wiedzy: jej przepáyw, zmianĊ stanu (np. zwiĊkszenie zasobów wiedzy uczestnika pro-jektu) lub zmianĊ formy wiedzy (np. z nieskodyfikowanej na skodyfikowaną). IntensywnoĞü dziaáaĔ, związanych z zarządzaniem wiedzą byá róĪny w poszczególnych fazach.
W fazie koncepcji biznesowej wszystkie dziaáania wiązaáy siĊ z transformacją wiedzy. Miaáy one przede wszystkim charakter transferu wiedzy o organizacji od uĪytkowników kluczowych do konsultantów oraz zapisu wiedzy o systemie w formie dokumentów koncepcji biznesowej. Pobocz-nym dziaáaniem byá transfer wiedzy o systemie od konsultantów do uĪytkowników kluczowych,
91
podczas warsztatów oraz podczas omawiania dokumentów koncepcji biznesowej. Byáa to najbar-dziej intensywna, zarówno w wielkoĞciach wzglĊdnych, jak i bezwzglĊdnych faza projektu pod wzglĊdem zarządzania wiedzą.
W fazie realizacji intensywnoĞü dziaáaĔ „wiedzowych” byáa znacznie niĪsza, gdyĪ gáówny na-cisk byá w niej poáoĪony na bezpoĞrednie prace konfiguracyjne w systemie. Transfer wiedzy miaá charakter doszczegóáawiający – w celu opracowania dokáadnych specyfikacji technicznych rozsze-rzeĔ programistycznych oraz koncepcji migracji.
Faza testów charakteryzowaáa siĊ relatywnie duĪą intensywnoĞcią dziaáaĔ, związanych z zarzą-dzaniem wiedzą. Wynikaáo to z przyjĊtego w projekcie zaáoĪenia, iĪ transfer wiedzy o systemie od konsultantów do uĪytkowników kluczowych bĊdzie realizowany przy okazji testów, a nie w osob-nych sesjach szkoleniowych. Zapis wiedzy o systemie byá realizowany przez uĪytkowników kluczowych w fazie testów.
Faza przygotowania do startu okazaáa siĊ byü fazą najmniej intensywną z punktu widzenia za-rządzania wiedzą, co stoi w sprzecznoĞci z zaáoĪeniami metodyki ASAP, jako Īe w tej fazie powinny odbywaü siĊ szkolenia uĪytkowników. W badanym projekcie byáy one bardzo ograniczone, ze wzglĊdu na wymieniony powyĪej transfer wiedzy podczas testów.
Drugą, po fazie koncepcji biznesowej, najbardziej intensywną w kontekĞcie zarządzania wiedzą fazą byáo wsparcie po starcie. W tej fazie nastąpiá doszczegóáawiający transfer wiedzy o systemie od konsultantów do uĪytkowników, realizowany podczas eksploatacji systemu.
3. Podsumowanie
Analiza przypadku, przedstawiona w niniejszym artykule ukazaáa rolĊ zarządzania wiedzą w projekcie wdroĪenia systemu klasy ERP. Ponad poáowa czynnoĞci, wykonanych przez konsultan-tów podczas projektu, byáa związana z zarządzaniem wiedzą. Gáówne dziaáania koncentrowaáy siĊ wokóá pozyskania wiedzy o organizacji od pracowników klienta oraz poáączenia tej wiedzy z wiedzą o systemie w celu stworzenia projektu rozwiązania w pierwszych fazach projektu, a nastĊpnie prze-kazaniu wiedzy o systemie uĪytkownikom klienta w fazach koĔcowych. Najbardziej intensywnymi z punktu widzenia zarządzania wiedzą okazaáy siĊ fazy koncepcji biznesowej oraz wsparcia po star-cie, jednak czynnoĞci związane z zarządzaniem wiedzą byáy obecne we wszystkich fazach projektu. Wskazuje to na niezwykle istotną rolĊ zarządzania wiedzą w projektach wdroĪenia systemów ERP i koniecznoĞü prowadzenia szeroko zakrojonych badaĔ nad metodykami zarządzania wiedzą w Ğro-dowisku projektowym.
92 Bibliografia
[1] Chan, R. and Rosemann, M. 2001. Managing knowledge in enterprise systems. Journal of Systems and Information Technology. 5, 2 (2001), 37–54.
[2] Desouza, K. and Evaristo, R. 2004. Managing Knowledge in Distibuted Projects. Commu-nications of the ACM. 47, 4 (2004), 87–91.
[3] Esteves, J. et al. 2003. An Exploratory Study of Knowledge Types Relevance Along En-terprise Systems Implementation Phases. 4-th European Conference on Organizational Knowledge and Learning Capabilities (2003), 13–14.
[4] Gasik, S. 2011. A model of project knowledge management. Project Management Journal. 42, 3 (2011), 23–44.
[5] Gemino, A. et al. 2007. A Temporal Model of Information Technology Project Perfor-mance. Journal of Management Information Systems. 24, 3 (Dec. 2007), 9–44.
[6] Hanisch, B. et al. 2009. Knowledge management in project environments. Journal of Knowledge Management. 13, 4 (2009), 148–160.
[7] Koch, S. and Mitlöhner, J. (2010) “Effort estimation for enterprise resource planning im-plementation projects using social choice – a comparative study”, Enterprise Information Systems, Vol. 4 No.3, pp.265–281
[8] Lee, Z. and Lee, J. 2000. An ERP implementation case study from a knowledge transfer perspective. Journal of Information Technology. 15, 4 (Dec. 2000), 281–288.
[9] Lech, P. (2014). Managing knowledge in IT projects: a framework for enterprise system implementation. Journal of Knowledge Management, 18(3), 551–573. doi:10.1108/JKM-01-2014-0006
[10] Reich, B.H. 2007. Managing knowledge and learning in IT projects: A conceptual frame-work and guidelines for practice. Project Management Journal. 38, 2 (2007), 5–17. [11] Reich, B.H. et al. 2008. Modeling the knowledge perspective of IT projects. Project
Man-agement Journal. 39, S1 (2008), S4–S14.
[12] Ribbers, P., & Schoo, K. 2002. Program management and complexity of ERP im-plementations. Engineering Management Journal, 14, 2 (2002), 45–52.
[13] Sedera, D. 2009. Knowledge management for enterprise systems: observations from small, medium and large organizations. PACIS 2009 Proceedings. (2009), 1.
[14] Simon, A., Schoeman, P. and Sohal, A.S. (2010) “Prioritised best practices in a ratified consulting services maturity model for ERP consulting”, Journal of Enterprise Information Management, Vol. 23, No.1, pp.100–124
[15] Wang, E. et al. 2007. Improving enterprise resource planning (ERP) fit to organizational process through knowledge transfer. International Journal of Information Management. 27, 3 (Jun. 2007), 200–212.
[16] PMBOK, A Guide to the Project Management Body of Knowledge. Management. Project Management Institute.
[17] Zmud R., Apple L. (1992), Measuring technology incorporation/infusion, “Journal of Prod-uct Innovation Management”, Vol. 9, Iss. 2, pp. 148–155.
93
ACTIVITIES OF CONSULTANTS DURING ERP IMPLEMENTATION IN THE CONTEXT OF KNOWLEDGE MANAGEMENT
Summary
This papers presents the results of a case study, during which the activities of consultants during ERP implementation were analysed against the criterion of their relation to knowledge management. Basing on source documents from an ERP imple-mentation project, phases of this project were also characterized, followed by the description of main activities performed in each phase as well as resulting effects. The results show that more than half of the activities of consultants were knowledge man-agement related. The most knowledge manman-agement intensive phases were Business Blueprint and Support but knowledge management activities were present throughout the whole project.
Keywords: ERP, project management, knowledge in projects, consultants, implementation, management system, implementation methodology
Przemysáaw Lech Katedra RachunkowoĞci Wydziaá Zarządzania Uniwersytet GdaĔski
