Czynności konsultantów podczas wdrożenia systemu ERP w

CZYNNOĝCI KONSULTANTÓW PODCZAS WDROĩENIA
SYSTEMU ERP W KONTEKĝCIE ZARZĄDZANIA WIEDZĄ
PRZEMYSŁAW LECH
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ą. Bazują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ą. Najbardziej intensywne dziaáania prowadzone byáy w fazie koncepcji biznesowej oraz
wsparcia po starcie, jednak zarządzanie wiedzą byáo obecne we wszystkich fazach projektu.
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, zawartych 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 konkretnym Ğrodowisku informatycznym, przy jednoczesnym zarządzaniu wszystkimi „tradycyjnymi”
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 zakresem, 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 budowanym 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
82
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
artykule jest analiza czynnoĞci, wykonanych podczas projektu wdroĪenia systemu klasy ERP, w podziale 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 harmonogram, 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 odwzorowania 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 podlega testowaniu i poprawkom,
x Przygotowanie do startu – kiedy to przygotowywane jest Ğrodowisko produkcyjne i migrowane 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 informatycznego, 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 przedmiotem 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 rachunkowoĞci, logistyce, organizacji produkcji);
x zdolnoĞci komunikacyjne – umoĪliwiające pracĊ w zespole.
83
Przemysáaw Lech
CzynnoĞci konsultantów podczas wdroĪenia systemu ERP w kontekĞcie zarządzania wiedzą
NaleĪy zauwaĪyü, iĪ pierwsze trzy typy wiedzy są bezpoĞrednio związane z prowadzonym projektem (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 projektowych, 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Ċ znajomoĞ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 kategoria: 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Ī autorzy, 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, posiadanej 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 wymagania w zakresie wymienionych powyĪej typów wiedzy dla uczestników projektu, dziaáania, związane
z zarządzaniem wiedzą w poszczególnych jego fazach oraz wytworzone w wyniku tych dziaáaĔ artefakty znajduje siĊ w [9].
84
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
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ądzaniem wiedzą do celów niniejszego badania
uznano te z nich, które powodują transformacjĊ wiedzy (zdobywanie/tworzenie, przechowywanie/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 projektowej, 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ą wykorzystano 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 wystą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 programistó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.
85
Przemysáaw Lech
CzynnoĞci konsultantów podczas wdroĪenia systemu ERP w kontekĞcie zarządzania wiedzą
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 dokumentacji, 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 aktualnie wykorzystywanych systemów, które zostaną wyáączone po wdroĪeniu nowego rozwiązania,
specyfikacja ewentualnych rozszerzeĔ programistycznych w stosunku do standardowej funkcjonalnoĞ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Īenie 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 prezentowali propozycje rozwiązaĔ w systemie;
2. Tworzenie dokumentów koncepcji biznesowej, realizowane samodzielnie przez konsultantó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 prezentowane 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 naká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
86
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
konsultantom w taki sposób, aby mogli oni zaprojektowaü przyszáe rozwiązanie w formie dokumentu 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 koncepcji 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 rozszerzeĔ 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 przygotowanie 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 wiedzą 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 produkcie 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 specyfikacji technicznej w zakresie prac programistycznych i migracji.
87
Przemysáaw Lech
CzynnoĞci konsultantów podczas wdroĪenia systemu ERP w kontekĞcie zarządzania wiedzą
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 niniejszym 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 kluczowych klienta. Zakres scenariuszy testowych pokrywa siĊ z procesami gospodarczymi,
zidentyfikowanymi i opisanymi w koncepcji biznesowej. Dodatkowo przeprowadzane są testy raportó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 informatycznego, 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 nadzorem 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 wystĊ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ą formalną 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 pomijana, 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 kluczowych 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 wykonywali dodatkowo instrukcje stanowiskowe. WydáuĪyáo to co prawda czas trwania testów, jednak
88
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
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 nastĊ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 podstawowych, 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 stanowiá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 kluczowych 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Ğü prowadzenia 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Ĕ skomplikowania, 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 zostaá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.
89
Przemysáaw Lech
CzynnoĞci konsultantów podczas wdroĪenia systemu ERP w kontekĞcie zarządzania wiedzą
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
Koncepcja biznesowa
Realizacja
Testy
Przygotowanie
do startu
Start i wsparcie
Razem
Nakáady w osobodniach
139,5
Udziaá w nakáadach ogóáem
20,48%
Nakáady związane z zarządzaniem wiedzą
139,5
Udziaá w nakáadach fazy
100%
199
139,5
56
29,22%
20,48%
8,22%
65
52,5
12,5
32,66%
37,63%
22,32%
147
681
21,59%
100%
89,5
359
60,88%
-
ħ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 projektu) 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. Pobocznym dziaáaniem byá transfer wiedzy o systemie od konsultantów do uĪytkowników kluczowych,
90
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
podczas warsztatów oraz podczas omawiania dokumentów koncepcji biznesowej. Byáa to najbardziej 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 nacisk 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 rozszerzeĔ 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 osobnych 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 zarzą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 konsultantó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 przekazaniu 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 starcie, 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 Ğrodowisku projektowym.
91
Przemysáaw Lech
CzynnoĞci konsultantów podczas wdroĪenia systemu ERP w kontekĞcie zarządzania wiedzą
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. Communications of the ACM. 47, 4 (2004), 87–91.
[3] Esteves, J. et al. 2003. An Exploratory Study of Knowledge Types Relevance Along Enterprise 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 Performance. 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 implementation 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/JKM01-2014-0006
[10] Reich, B.H. 2007. Managing knowledge and learning in IT projects: A conceptual framework 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 Management Journal. 39, S1 (2008), S4–S14.
[12]
Ribbers, P., & Schoo, K. 2002. Program management and complexity of ERP implementations. 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 Product Innovation Management”, Vol. 9, Iss. 2, pp. 148–155.
92
Studies & Proceedings of Polish Association for Knowledge Management
Nr 73, 2015
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 implementation 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 management related. The most knowledge management 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
e-mail: [email protected]
93