CZYNNO CI KONSULTANTÓW PODCZAS WDRO ENIA SYSTEMU ERP W KONTEK CIE ZARZ DZANIA WIEDZ PRZEMYSŁAW LECH Uniwersytet Gda ski 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
84 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz 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 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: 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; 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, 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, Przygotowanie do startu kiedy to przygotowywane jest rodowisko produkcyjne i migrowane s dane rzeczywiste, a tak e szkoleni s u ytkownicy ko cowi, 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: o projekcie wiedz o zasobach, bud ecie, harmonogramie, ryzykach i innych aspektach, niezb dnych do prowadzenia projektu; o organizacji wiedz o specyfice organizacji, w której nast puje wdro enie, jej systemie warto ci, celach, strukturach organizacyjnych, procesach gospodarczych, zasobach; 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; techniczn wiedz z zakresu IT;
POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 73, 2015 85 biznesow wiedz z zakresu dziedzinowego, podlegaj cego wdro eniu (np. wiedz o rachunkowo ci, logistyce, organizacji produkcji); zdolno ci komunikacyjne umo liwiaj ce prac w zespole. 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: 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; 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: zdobywanie/tworzenie; przechowywanie/zapisywanie, transfer/rozpowszechnianie, 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 ): zdobywanie/tworzenie tworzenie lub zdobywanie wiedzy w sposób inny ni poprzez jej transfer, przechowywanie/zapisywanie kodyfikacja wiedzy pozyskanej lub wytworzonej, przepływ wiedzy od uczestników do artefaktów, 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
86 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz z zarz dzaniem wiedz w poszczególnych jego fazach oraz wytworzone w wyniku tych działa artefakty znajduje si w [9]. 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.
POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 73, 2015 87 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ł: transfer wiedzy o organizacji od u ytkowników kluczowych do konsultantów; kodyfikacja wiedzy o organizacji oraz wiedzy o systemie w formie dokumentu koncepcji biznesowej; 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
88 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz 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: 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; 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.
POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 73, 2015 89 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
90 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz 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.
POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 73, 2015 91 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 osobodniach Udział w nakładach ogółem Nakłady zwi zane z zarz dzaniem wiedz Udział w nakładach fazy Koncepcja biznesowa 139,5 20,48% 139,5 100% Realizacja 199 29,22% 65 32,66% Testy 139,5 20,48% 52,5 37,63% Przygotowanie 56 8,22% 12,5 22,32% do startu Start i wsparcie 147 21,59% 89,5 60,88% Razem 681 100% 359 - ródło: opracowanie własne. ródło: opracowanie własne. Rys. 1. Podsumowanie wyników badania 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,
92 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz 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.
POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 73, 2015 93 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/jkm- 01-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.
94 Czynno ci konsultantów podczas wdro enia systemu ERP w kontek cie zarz dzania wiedz 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 Katedra Rachunkowo ci Wydział Zarz dzania Uniwersytet Gda ski e-mail: przemyslaw.lech@lst.com.pl