Artur Jaworski Blog

To stwierdzenie obserwuję bardzo często u najróżniejszych osób, które spotykam na swojej drodze. Swego czasu mogłem odczuć nieprzyjemność jego występowania na własnej skórze.
U mnie wyglądało to w następujący sposób: otóż wczesnym niedzielnym popołudniem odczuwałem psychiczny dyskomfort, rodzaj wewnętrznego niepokoju, lęku przed czymś, co niebawem ma nastąpić.
Postanowiłem znaleźć przyczyny powstawania tego powtarzającego się tydzień w tydzień stanu. Tak więc u mnie pierwotnym podłożem tego uczucia była szkoła… a właściwie lęk przed atmosferą tam panującą i klasówkami z rzeczy, których nie czułem potrzeby się uczyć.
Ważne, aby zdawać sobie sprawę, ze tym stanem organizm daje nam czytelny sygnał, że coś dzieje się nie tak, że na przykład środowisko w którym się poruszamy jest dla nas nieodpowiednie.
Jak już zaobserwujemy taki stan, to najlepszą metodą jest działanie (to najlepsza metoda na każdy stresor). Znajdź przyczynę, następnie opracuj działania zaradcze.
I zrób to wszystko natychmiast. Miłych niedziel.

Sprawą oczywistą jest, że program szkoleniowy jest nieodłączną częścią każdego wdrożenia systemu klasy ERP. Jednakże większość tych szkoleń koncentruje się wyłącznie na przekazaniu technicznych informacji jak obsługiwać daną transakcję oraz nie przekazuje elementarnej wiedzy na temat procesu wdrożenia. Pamiętaj też, że członkowie zespołów wdrożeniowych są normalnymi ludźmi z różną pozycją wyjściową (bagażem doświadczeń) oraz lękami i obawami.
W związku z powyższym proponuję następujące podejście.
Przed przystąpieniem do technicznych szkoleń (obsługa systemu transakcyjnego) należy jasno przekazać wszystkim osobom zaangażowanym w projekt następujące aspekty:
- Przede wszystkim należy wybiec naprzeciw wszelkim obawom, które na tym etapie projektu pojawiają się u pracowników. Typowe przykłady to: „czy podołam”, „co będzie z moim stanowiskiem pracy” „po co nam ten system”. Przekaż wszystkim, że to najnormalniejsza rzecz pod słońcem i między innymi to spotkanie jest po to, aby rozwiać wszelkie wątpliwości
- Idea systemów klasy ERP – jak będzie przebiegać wdrożenie, czym różni się implementacja systemu konfigurowalnego od pisanego w narzędziu developerskim itd.
- Cel wdrożenia – może się tak zdarzyć, że z perspektywy konkretnych stanowisk pracy, wdrożenie będzie oznaczało krok wstecz. Przykładowo może się okazać, że pewne niezbędne funkcjonalności w danych stanowisku pracy nie będą w standardzie lub pracochłonności ich obsługi będzie większa. Kwintesencją systemów klasy ERP jest to, że nie można ich oceniać z perspektywy pojedynczych funkcji a całościowych korzyści. Przekaż, że istnieje jasno zdeklarowany cel wdrożenia, który dostarcza konkretnych korzyści dla firmy, a więc i dla wszystkich jej pracowników. Jakość wdrożenia oceniamy poprzez zdolność do realizacji tego celu, a nie przez ocenę poszczególnych wycinków systemu.

Podczas szkoleń technicznych (przegląd funkcjonalności) zawsze punktem wyjścia jest proces. Szczególnie istotne są te, które przebiegają przez wiele działów na przykład począwszy od produkcji przez zaopatrzenie na księgowości kończąc. Jeżeli pokazujemy transakcję umożliwiająca tworzenie zamówienia zakupowego, oprócz przekazania umiejętności obsługi poszczególnych ekranów jasno określamy, w której części procesu jesteśmy oraz jak konkretne decyzje wdrożeniowe wpływają na całościowy przebieg procesu. Użytkownik musi zrozumieć, że transakcja jest elementem procesu biznesowego oraz to, że system konfigurowalny sam w sobie zawiera sposoby jak działać (procesy biznesowe) i my kupując pakiet nabywamy sprawdzony sposób na funkcjonowanie przedsiębiorstwa.

Pamiętaj, aby wszystkim zespołom przekazać ogólne informacje o funkcjonalnościach wspólnych dla wszystkich modułów takich jak: workflow, DMS czy klasyfikacja.

Przebywając dłuższy czas w określonym środowisku podświadomie przejmujemy sposoby zachowywania się, które tam obowiązują. Podobnie wygląda sytuacja ze zbyt długim oglądaniem telewizji, która przeładowana jest toksycznymi wzorcami językowymi, które chcąc nie chcąc przyjmujemy i stosujemy podczas codziennego życia. Większość wywiadów, które można pooglądać w telewizji nie jest nakierowana na uzyskanie sposobu postrzegania świata przez osobę odpytywaną, a utwierdzenie się “reportera”, że znał odpowiedź na zadawane pytanie.

Ważne, aby zdawać sobie sprawę z tej prawidłowości, (kto z kim przystaje takim się staje) unikać toksycznych miejsc, brak polskiej telewizji też długofalowo może wyjść na plus.
Zaskakujące jest dla mnie jak wielu profesjonalistów mówiących o poważnych sprawach używa trybu niedokonanego oraz słów udało się czy spróbuj. Wyeliminowanie tych konstrukcji sprawi, że odbiór naszej osoby będzie bardziej profesjonalny, konkretny i przekonywający dla słuchaczy.

SPRÓBUJ
Ja osobiście używam go wyłącznie w połączeniu z tematami kulinarnymi. “To danie wygląda fantastycznie, daj spróbować.” W każdym innym wydaniu insynuuje porażkę. Zerknij na przykłady:

“Od jutra nie palę”
“Od jutra spróbuję nie palić”

“Otwórz okno”
“Spróbuj otworzyć okno”

Czujecie różnicę ? Jeżeli na szkoleniu proszę kogoś o wykonanie ćwiczenia, które dla uczącego jest nowe nie mówią spróbuj. Moja wersja to: zrób to najlepiej jak potrafisz.

UDALO SIĘ
Przede wszystkim sugeruje ono, że to co się stało głównie jest zasługą przypadku a nie naszych świadomych i profesjonalnych działań. Jeżeli dla przykładu kierownik projektu podsumowuje właśnie zakończoną fazę wdrożenia zaczynając zdanie od słowa udało nam się, mnie od razu pojawiają się myśli: uff mieliśmy szczęście, ale fart, ktoś nad nami czuwa itp. Po prostu takie skojarzenie ładujemy do naszych odbiorców. Jeżeli dany sukces jest wynikiem naszych świadomych i konkretnych działań to nie opisujmy ich słowem “udało się” są przecież takie ładne jak: Zrobiliśmy, dokonaliśmy, zakończyliśmy itd.

Tryb niedokonany. Co z nim złego ?
Jak dla mnie jest taki rozlazły, nudny i mało konkretny. Mam pomysł posłużę się przykładem: Jesteśmy na ważnej prezentacji u klienta, właśnie kończę omawianie swojej części, kolejną ma prezentować koleżanka. Przykład użycia trybu niedokonanego:
“A teraz chciałbym przekazać głos koleżance”, moja propozycja to: “Teraz przekazuję głos koleżance”. Jedno słowo, a odbiór diametralnie różny.

W skrajnym wydaniu to zdanie można spaskudzić w następujący sposób: “A teraz chciałbym spróbować przekazać głos koleżance, zobaczymy czy mi to się uda”. To autentyk, który słyszałem podczas prezentowania rozwiązania wartego kilka milionów złotych.

Czemu warto przejmować się tymi sprawami? Bo to może być to coś co sprawi, że właśnie nasza oferta (czy sama osoba) zostanie odebrana jako bardziej profesjonalna. To może być ta jedna rzecz, które wyróżni nas od innych oferentów czy kandydatów do wykonania danej pracy.

Jest to umiejętność, która wymaga treningu. Przygotowując się do wystąpienia należy uważnie obserwować samego siebie (np. nagrać wystąpienie) i krok po kroku eliminować negatywne wzorce. Cierpliwość i ciężka praca zaowocuje zainstalowaniem tego do naszych podświadomych działań, no chyba że nad piszemy to słuchając w nadmiarze dyskusji polityków :).

Upgrade to zmiana aktualnie użytkowanej wersji systemu do nowszej. Motywacje do tego działania mogą być różne najczęściej spotykane to:

- wzrost kosztów utrzymania starszych wersji SAP
- potrzeba nowych funkcjonalności, które są standardem w nowych wersjach
- okazja do zrobienia porządku w eksploatowanej funkcjonalności, rozszerzeniach klienckich itp

Jedno jest pewnie coraz więcej firm będzie stawało przed takim dylematem. Opcje są dwie: zmiana do najnowszej wersji SAP lub implementacja nowego rozwiązania innego producenta.
Jakie są rodzaje projektów:

- Upgrade techniczny - polegający na zainstalowaniu nowego systemu oraz sprawdzeniu poprawności funkcjonowania procesów biznesowych
- Upgrade funkcjonalny - oprócz tego co powyżej, dodawane są nowe nowe procesy a w maksymalnej opcji dokonywany jest gruntowny przegląd i modyfikacja wszystkich procesów wspieranych przez system.

Ja jestem fanem upgrejdów technicznych. Jeżeli jest potrzeba dokonania reingeringu procesów, zróbmy to w oddzielnym projekcie. Na tym etapie polecam skupić się wyłącznie na wykonaniu technicznej pracy (zmiana systemu operacyjnego na serwerach, zmiana bazy danych, upgrade systemu SAP) oraz sprawdzeniu czy wszystko działa OK. Jestem wstanie wyobrazić sobie odstępstwa od tej reguły, na przykład gdy aktualny przebieg procesów jest niezgodny z potrzebami biznesowymi lub z innych powodów ich aktualny wygląd jest nie do zaakceptowania.
Teoretycznie tego typu projekt, użytkownik systemu może wykonać własnymi zasobami. Jednakże należy pamiętać, że upgrade nie sprowadza się wyłącznie do włożenia płyty DVD uruchomienia setup.exe i poczekaniu kilku godzin. Na złożoność tego projektu wpływ ma dużo aspektów, wiele tematów które pojawiają się podczas projektu można znacznie szybciej rozwiązać posiadając wsparcie osób z konkretnym doświadczeniem w takich projektach (koszt współmierny do korzyści). Jeżeli decydujesz się na samodzielne przeprowadzenie upgrejdu pamiętaj o planie B, a więc co najmniej o wstępnej umowie z partnerem SAP, który w razie potrzeby dostarczy zasobów.
Ja osobiście przy określaniu złożoności projektu używam następujących wskaźników:

- Liczba rozszerzeń w systemie (programy ABAP, user-exity)
- Złożoność struktury organizacyjnej (ilość jednostek gospodarczych, zakładów itp.)
- Liczba mandantów używanych na systemie produkcyjnym
- Strona kodowa (konwersja do UNICODE)

Moim zdaniem tego typu projekt jest bardziej skomplikowany niż implementacja nowego systemu. Poszczególne fazy wyglądają podobnie to jest: przygotowanie projektu, koncepcja, realizacja oraz wsparcie po starcie. Jednakże dochodzi konieczność podjęcia wielu decyzji, których jakość rzutuje na końcowych efekt projektu. Do podstawowych należą:

- koncepcja technologicznego upgrejdu poszczególnych maszyn (ilość cykli, obsługa dwóch systemów developerskich itp.)
- faza “code freez”, okres podczas którego zmiany na systemie produktywnym są niemożliwe
- brak dostępu do systemu produkcyjnego (down time)

Z punktu widzenia konsultanta SAP, praca w takim projekcie sprowadza się do rozwiązywania bieżących błędów w systemie oraz szkolenia z nowych funkcjonalności.

Ostatnio kilku młodszych kolegów pytało mnie jak wygląd praca konsultanta, co tak naprawdę się robi. Postanowiłem więc napisać parę słów, które są uzupełnieniem posta Zawód konsultant.

Zadania dla konsultanta ja dzielę na dwie kategorie: wdrożeniowiec czyli osoba zajmująca się implementację pierwszej wersji systemu oraz serwisant, który jest odpowiedzialny za sprawne utrzymanie działającego już systemu.

Tak naprawdę to rodzaj projektu decyduje o tym, jakie zadania stoją przed konsultantem.  Niezależnie od tego, czy wdrażamy system od początku czy utrzymujemy już funkcjonujący, poziom naszych umiejętności musi być jednakowo wysoki (zarówno technologicznych jak i interpersonalnych).

Skupmy się więc, na rodzajach projektów jakie są dostępne na rynku:

Wdrożenie systemu od 0 po raz pierwszy.

• Pierwszym etapem w takim projekcie jest analiza procesów biznesowych. Tu szkoły są dwie. Pierwsza mówi, że taką analizę powinna wykonać firma specjalizująca się w mapowaniu procesów biznesowych, druga że wykonają ją konsultanci którzy później będą konfigurować system. Ja osobiście jestem zwolennikiem tej pierwszej. Jednakże bądź gotów, że takie zadania mogą stanąć przed Tobą. Jak to robić napisałem tu.

• Następnie na bazie analizy procesów wykonywana jest koncepcja wdrożenia. Zespoły wdrożeniowe (klent i wykonawca) ustalają, które procesy i w jakim zakresie mają być wspierane przez system.  Decyzje te zapisywane są w dokumencie, który nazywany jest koncepcją systemu. Konsultant dostaje przygotowany przez Kierownictwo projektu szablon, który wypełnia istotnymi dla swojego modułu treściami (odwzorowanie struktur organizacyjnych, dane podstawowe, opisy procesów, raporty itp.). Na tym etapie szczególnie ważne są umiejętności komunikacyjne, które są niezbędne aby sprawnie kierować pracami.

• Kolejnym etapem jest konfiguracja systemu. Dobrze opracowana koncepcja umożliwia gładkie przeprowadzenia tego etapu. Polega to na sparametryzowaniu systemu tak, aby funkcjonował zgodnie z ustaleniami z kocepcji.  Po prostu siadamy do komputera, logujemy się do systemu i uruchamiamy odpowiednie transakcje.

• Po konfiguracji przychodzi czas na testy integracyjne. Wszystkie zespoły wdrożeniowe spotykają się ponownie, aby sprawdzić czy system przygotowany jest do kompleksowej obsługi procesów. Głównie skupiamy się na powiązaniach między modułowymi, po prostu trzeba sprawdzić czy jesteś w stanie wykonać proces od początku do końca. Dla przykładu proces rozpoczyna się od utworzenia zgłoszenia zapotrzebowania na zakup surowca a kończy przelewem pieniążków dla naszego dostawcy.  Po środku jest tworzenie zamówienia, przyjęcie na magazyn, zużycie itd. To mój ulubiony etap.

• Szkolenia. Gdy wszyscy są zgodni, że konfiguracja jest wykonana prawidłowo, przystępujemy do szkolenia użytkowników końcowych oraz przygotawaniu instrukcji stanowiskowych. Mimo iż mamy 21 wiek, to pamiętajmy że na szkoleniach poziom znajomości technik komputerowych u naszych użytkowników będzie różny. Mogą to być osoby, dla których jest to pierwszy kontakt z system klasy ERP a nawet komputerem PC. Należy mieć cała stertę cierpliwości oraz po prostu lubić to robić (chociaż to tyczy się wszystkich etapów).

• Przygotowania do startu.  W tym etapie przygotowujemy się organizacyjnie do uruchomienia systemu oraz  dokonujemy migracji danych na system produktywny (bilans otwarcia).

• Wsparcie po starcie.  Przez najbliższe 2 miesiące aktywnie wspieramy użytkowników w produktywnej obsłudze systemu. Generalnie na wszystkich etapach pamiętajmy o odnoszeniu się z szacunkiem do innych osób. Doskonale zdaję sobie sprawę, że może irytować ciągłe pytanie o sprawy które wielokrotnie były tłumaczone. Po prostu nikt nie rodzi się ze znajomością wszystkich rzeczy, niektórzy potrzebują więcej czasu aby przyswoić wiedzę.

Roll-out, czyli implementacja korporacyjnego rozwiązania w nowym miejscu.  Ideą jest, aby wszystkie oddziały danego koncernu używały takich samych procesów biznesowych oraz konfiguracji systemu (oczywiście jeżeli to jest możliwe).
Cechą charakterystyczną tego projektu jest fakt, że lwia część koncepcji wdrożeniowej jest już wykonana. My skupiamy się wyłącznie na modyfikacjach będących wynikiem przepisów prawnych danego kraju i opisaniu ewentualnych specyficznych procesów biznesowych. Koncepcja biznesowa zawiera wyłącznie te elementy.   Kolejne etapy przebiegają podobnie, z tą różnicą że konfigurujemy wyłącznie struktury organizacyjne nowego przedsiębiorstwa oraz ewentualne specyficzne procesy.
Serwis, naszym zadaniem wówczas jest utrzymywanie podległego nam modułu w pełnej sprawności. Tak więc reagujemy na wszelkie zgłoszenia nieprawidłowego funkcjonowania sytemu, dokonujemy testów i konfiguracji nowych rozwiązań oraz szkolimy nowych użytkowników.

Jest jeszcze jeden rodzaj projektów to jest upgrade do nowej wersji, jednakże moim zdaniem zasługuje on na osobnego posta więc napiszę o tym niebawem