Znowu procesy

Po decyzji o podjęciu wdrożenia SAP, jeszcze raz przyjrzano się procesom. Wybrano te, które były najbliższe standardom tego oprogramowania. "Staraliśmy się wprowadzać do systemu jak najmniej zmian. Jeśli w systemie SAP między wystawieniem zapotrzebowania a zamówieniem przez jedną osobę jest przewidziana zgoda jeszcze innej osoby, to znaczy, że trzeba to zaakceptować i wdrożyć, mimo że zawsze u nas te dwie czynności wykonywał jeden pracownik" - wyjaśnia Roman Maret. Problem w tym, że takich wyborów trzeba uczynić dziesiątki. Ktoś musi rozstrzygać ostatecznie: akceptujemy rozwiązanie z SAP czy wdrażamy inny wariant. Musi to być decyzja niepodważalna, gdyż w przeciwnym razie powstanie bałagan i wdrożenie utkwi w takich szczegółowych sprawach. "Decydujący głos w sprawie zmian w procesie ma właściciel procesu. Po tym się go rozpoznaje. Jeśli jednak menedżer ten uprawni kogoś do podejmowania decyzji, to musi liczyć się z tym, że później nie będzie mógł zakwestionować postanowień tej osoby. Niektórzy menedżerowie długo nie mogli zrozumieć, że delegacje są niepodważalne. Przychodzili na zebranie zespołu i byli zdziwieni, że ktoś zastępujący ich na poprzednich spotkaniach coś postanowił, co mu się teraz nie podoba, ale nie można tego cofnąć. Ale projekt może posuwać się do przodu tylko dzięki kolejnym systematycznym decyzjom" - tłumaczy Aleksander Kwiatkowski.

Niektóre decyzje może podjąć tylko najwyższe kierownictwo. Ktoś z tego grona musi na bieżąco uczestniczyć w pracach zespołu wdrożeniowego. Nie tylko dlatego że jest wtedy łatwiej dostępny niż w gabinecie, do którego zwykle ustawia się kolejka ludzi z pilnymi sprawami, i może długo potrwać, zanim zajmie się problemem, pojawiającym się w projekcie. Również dlatego że tylko będąc stale zorientowanym w pracach zespołu będzie mógł podjąć trafną, a nawet jakąkolwiek decyzję. Nieoptymalna decyzja jest lepsza niż jej brak. Decydent, poproszony o rozstrzygnięcie, musi skorzystać ze swojej wiedzy już nabytej podczas uczestnictwa w projekcie, krótko zastanowić się i zdecydować. Tego wymagają od niego inni uczestnicy przedsięwzięcia, by pracować dalej. Dyrektor, którego się "ściąga" w pewnym momencie i przedstawia mu problem do decyzji, nie podejmie jej szybko i trafnie, gdyż trzeba mu wszystko wyjaśniać, począwszy "od Adama i Ewy". Potrzebuje czasu, by w ogóle wgryźć się w zagadnienie, a i potem zostaje jeszcze daleka droga do decyzji.

Transfer wiedzy

Udany projekt to taki, który będzie funkcjonował po odejściu konsultantów. To rozumieją wszystkie przedsiębiorstwa, ale mało które rozumie jeszcze i to, że podczas tworzenia projektu muszą zadbać o odpowiedni transfer wiedzy od konsultantów do użytkowników. Jak mówi Roman Maret: "Nałapać, ile się da". Praktycznie jest to możliwe tylko wtedy, gdy pracownicy będą oddelegowani do zespołu wdrożeniowego w 100%. Jeśli będą natomiast wykonywać normalne obowiązki, a w projekcie uczestniczyć tylko incydentalnie, to niczego się nie nauczą. "W praktyce taka stała obecność jest bardzo trudna do wyegzekwowania dla obu stron. Konsultant wolałby czasem zrobić coś sam, bo to i szybciej, i nie trzeba na tyle pytań odpowiedzieć, a pracownik często ma wrażenie, że w zasadzie na nic się konsultantowi przydaje, a sam marnuje czas mogąc być bardziej potrzebny na swoim stanowisku. I konsultant, i pracownik powinni zrozumieć, że muszą pracować razem, gdyż tylko tak przekazuje się wiedzę. W BAT konsultant wykonywał pewną pracę, a pracownik firmy ją dokumentował. Dzięki temu nasza wiedza została w firmie po ukończeniu projektu" - mówi Aleksander Kwiatkowski. Roman Maret zaś dodaje, że jest wielkim błędem pozostawianie prawie do końca projektu w rękach konsultantów, a dopiero w ostatniej chwili pośpieszne szkolenie pracowników po to, aby zastąpili konsultantów. "Wiedza konsultantów i wiedza naszych pracowników to były dwie krzywe, które w jakimś momencie przecięły się i odtąd nasza kompetencja okazywała się coraz bardziej wystarczająca, a zapotrzebowanie na kompetencję konsultantów coraz mniejsze". W BAT mobilizowano konsultantów do przekazywania swojej wiedzy użytkownikom przez zastosowanie prostej zasady: "Jeśli coś zrobisz za użytkownika, to za to ponosisz odpowiedzialność".

Uważa się, że transfer wiedzy jest udany, jeśli przedsiębiorstwo potrafi samodzielnie przeszkolić nowych pracowników do pracy w systemie, zmienić nieco konfigurację systemu, uwzględniając np. nowy kanał dystrybucyjny, wprowadzić drobne zmiany do raportowania, poprawnie sformułować pytania do konsultantów.

Wielki finał

Pod koniec projektu ludzi ogarnia wielkie zwątpienie. Stają przed wyborem: czy wystartować zgodnie z harmonogramem, czy może tę godzinę zero przełożyć i system jeszcze dopracować. "Istnieje wielka pokusa, aby przełożyć termin, gdyż ten ostatni okres to faza testów, wychodzą błędy, ludzie są podatni na krytykę" - twierdzi Roman Maret. W BAT też nikt nie chciał ostatecznie zdecydować, co robić. "Aby przełamać impas, zaproponowaliśmy, żeby wszyscy członkowie komitetu podpisali swoją zgodę na piłce. Wiadomo, piłka jest okrągła" - wspomina Aleksander Kwiatkowski. Zdecydowano ruszyć w terminie. We wdrożeniu już na początku podjęto decyzję, że nie będzie żadnych etapów, tylko wszystko jednocześnie.

Start trzymał ludzi w pogotowiu przez 36 godzin. "Wszystko poszło dobrze. Zakład nie stanął. Wszystko zadziałało tak jak powinno" - podsumowuje Roman Maret finał 9-miesięcznej pracy.

To nie znaczy, że potem nie było problemów i wpadek. Przez pierwszy miesiąc po wdrożeniu - kiedy zgodnie z kontraktem konsultanci są jeszcze w pogotowiu - stają się widoczne wszystkie konsekwencje wdrożonych procedur i procesów. Uczestnicy projektu widzą też, ilu rzeczy nie przewidzieli i w jakich sprawach nie przeszkolili ludzi, ponieważ nie można wszystkiego przewidzieć i wyuczyć.

"Co pewien czas padał okrzyk - SAP nie działa - który stawiał nas wszystkich na równe nogi. Pamiętam jedną z pierwszych takich sytuacji, kilka dni po wdrożeniu. Jest 1 listopada i pracownik rano sygnalizuje mi, że nie działa magazyn. Jedzie do niego informatyk, który stwierdza, że rzeczywiście nie działa, sprawdza poprawność połączeń, tu wszystko w porządku. Co jest więc nie w porządku? Jak znaleźć błąd? Dzwonić po konsultanta? I tu właśnie okazał się bezcenny ów transfer wiedzy. Informatyk nie zadzwonił po konsultanta, lecz sam zdiagnozował system i znalazł błąd. Przedniego dnia, ostatniego dnia października, księgowa nie zamknęła miesiąca. Następnego dnia nic nie działało" - wspomina Roman Maret. Dodaje, że później było jeszcze wiele takich alarmów zanim ludzie nauczyli się wykonywać określone czynności na bieżąco i dokładnie tak jak przewiduje procedura, a nie tak jak robili to wcześniej.

Dzisiaj system jest już ustabilizowany. Trwało to pierwszych 5 miesięcy tego roku. Stopniowo zawężano uprawnienia, budując również strukturę organizacyjną.

Powody do dumy

Roman Maret za sukces uważa fakt, że wdrożenie odbyło się w zaplanowanym okresie 9 miesięcy i w określonych kosztach (umowa z PriceWaterhouseCoopers opiewała na tzw. fixed price). Po namyśle dodaje: "Osiągnęliśmy nasze cele biznesowe, lecz zmieniliśmy też coś ważnego w naszych pracownikach. Dawniej za wyznacznik statusu uważali oni standard drukarki czy komputera, który stał na ich biurku. Teraz swój autorytet i znaczenie budują na możliwościach decydowania, które dał im system i nowa organizacja. Od kiedy mogą sprawdzać się w pracy, mniejszą uwagę zwracają na te zewnętrzne gadżety statusu".

PS

Zarówno Roman Maret, Aleksander Kwiatkowski, jak i autorka artykułu są osobami niepalącymi.