Jeżeli nie masz dostępu do systemu SAP a masz ochotę sprawdzić się jako jego programista mam dla Ciebie bardzo dobrą wiadomość. Otóź możesz zainstalowac sobie darmowego SAP Netweavera, jak to zrobić możesz przeczytać tu. Rafał zapowiedział mi, że całość opisze w pięciu postach, powodzenia.
Każdy z nas jest na swój sposób unikalny, oraz posiada zdolności, które teraz nazywane są ”talentem”. Właściwe wykorzystanie naszych predyspozycji dostarczy nam przyjemności z wykonywania konkretnych zadań oraz sprawi, że druga strona z przyjemnością odwdzięczy się przelewami pieniężnymi na nasze konto. Jednakże samo jego zlokalizowanie to trochę za mało, trzeba zastanowić się jak ulepszyć nasze działania, aby dostarczać większej różnicy dla naszych klientów niż osoby działające w tej samej branży.
Przedstawię to na przykładzie programisty, ponieważ o tym przypadku mogę wypowiadać się na bazie swojego doświadczenia jako wielokrotnego dostarczyciela specyfikacji do programów, testera oraz aktualnie, początkującego programisty 
.
Założyłem, że nasz przykładowy programista posiada wiedzę ekspercką, to jest napisanie sprawnego i optymalnego kodu nie jest problemem.
Przykładowy proces tworzenie programu w pakiecie ERP wygląda następująco:
Oczywiście jest to jeden z wariantów, służący wyłącznie jako przykład na potrzeby tego posta. Wielu programistów wykonując swoją pracą skupia się wyłącznie na zakodowaniu otrzymanej specyfikacji (punkt 3) bez większego wnikania, jaki jest cel biznesowy pisanego rozwiązania.
To, co moim zdaniem dostarczy największej różnicy, to zainteresowanie się:
Celem powyższego jest zebranie informacji niezbędnych do aktywnego udziału w produkcie który jest tworzony, na tym etapie warto jeszcze zastanowić się czy zaproponowana przez klienta i konsultanta specyfikacja jest optymalna pod względem kosztu do korzyści. Idealnie by było zebrać te informacje z pierwszej ręki a więc od docelowego użytkownika a nie konsultanta modułowego, który może zniekształcić przekaz.
Powyższy przykład jest modelem, obrazującym, że dostarczenie ekstra kilku elementów sprawi, że to właśnie my będziemy zaproszeni do realizacji kolejnego zlecenia.
Pomyśl, jakie elementy mogą dostarczyć konkretnych korzyści dla Twoich klientów w Twoim podwórku, będzie mi miło gdy podzielisz się tym ze wszystkimi w komentarzach
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.
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
Pierwsze co rzuca się w oczy podczas kontaktów z headhunterami to bardzo pobieżna (a często żadna) znajomość tematu do którego rekrutują. Dla przykładu, wystarczy że ktoś ma w swoim profilu wzmiankę np. o SAP, aby wysłać mu propozycję w zupełnie innym obszarze systemu. Jednakże to jak dla mnie jest do przełknięcia (chociaż stoję na stanowisku, że jest to naganne i przez krótkie szkolenie do nadrobienia), najbardziej odrzucają mnie wklejane formatki z treścią ogłoszenia, które najczęściej kończą się sformułowaniem: “Jeśli interesuje Pana przedstawiono oferta proszę o kontakt”.
Kierując się logiką powyższego sformułowania zostawiam te propozycję bez odpowiedzi, za kilka dni dostaję ponaglającą wiadomość z rozbrajającym pytaniem: “Czy dostał Pan moją wiadomość z ofertą” lub “Czy już się Pan zastanowił?”. Po przedstawieniu faktu, iż zastosowałem się do zdania, aby pozostawić informację bez odpowiedzi, w sytuacji gdy mnie nie interesuje, uzyskuję kolejne wymówki zabierające mój czas. Pamiętajmy, że między zabraniem komuś chwili z życia, a całego życia jest tylko różnica skali.
Będą headhunterem zastosował bym w swoim działaniu poniższe zasady.
Ciekaw jestem jaka jest skuteczność naszych polskich łowców głów, albo inaczej o ile można by ją zwiększyć inwestując w szkolenia, szczególnie przy tak dużej konkurencji na rynku pracy specjalistów IT.
Jak wielokrotnie wspominałem, konsultant, programista oraz kierownik projektu oprócz twardych technologicznych umiejętności, musi wiedzieć jak kierować spotkanie aby dostarczyć wymiernego rezultatu. Ma być liderem, który prowadzi spotkanie w ściśle określonym kierunku, jednym z przykładów które skutecznie utrudniają osiągnięcie celu spotkania jest orientacja naszego klienta w kierunku problemu a nie rozwiązania.
Pomyśl teraz przez chwilę o jakimś problemie, które jest ciągle nie rozwiązany. Nie ma znaczenia czy dotyczy on sfery osobistej czy zawodowej, coś co pierwsze przychodzi ci do głowy. Odpowiadając w myślach na poniższe pytania, obserwuj jak zmienia się Twoje nastawienie:
A teraz kolejna partia pytań, ukierunkowana w inne miejsce, ponownie obserwuj swój stan wewnętrzny:
Czujesz różnicę w swojej chęci do działania?
Jeżeli w jakiejkolwiek sytuacji życiowej, zauważysz skupianie się na przyczynach, skutkach, czy ograniczeniach jakie dane sytuacja powoduje, natychmiast przekieruj rozmowę na właściwy tor.
Dyskusja o problemie wywoła co najwyżej nieprzyjemny stan u wszystkich osób biorących w niej udział, odbierze entuzjazm i chęć do działania. Jest bezproduktywnym marnowaniem czasu w dodatku bardzo destrukcyjnym dla naszego stanu wewnętrznego. Nie mamy wówczas dostępu do naszych zasobów (kreatywność, inteligencja itp.) a bez nich nie wypracujemy dobrego rozwiązania.
Procesy w przedsiębiorstwie mogą być analizowane w najróżniejszych celach: aby to zrobić po raz pierwszy, dokonać optymalizacji już istniejących, dodania nowych, wynikających ze zmiany struktury organizacyjnej itp. W tym poście będę odnosił się wyłącznie do sytuacji, gdy mapowanie wykonywane jest na potrzeby wdrożenia systemu ERP. Świadomość istnienia tego celu, jest podstawą do jasnego określenia, w jaki sposób proces ma być zmapowany oraz umożliwia rozwiązywanie sytuacji spornych: jak na przykład poziom szczegółowości i liczba procesów.
No to zaczynamy.
Oczywiście trzeba zdecydować, w jakim narzędziu będziemy pracować. Teoretycznie rysowanie procesów można wykonać nawet w Excelu czy zwykłym programie graficznym, jednakże ze względu na możliwości raportowania oraz systemowego zaznaczania połączeń między procesami polecam program, który będzie tworzył z naszych procesów bazę danych.
Do tworzenia map, gorąco polecam metodę EPC (Event-driven Process Chain). W metodologii tej Łańcuch sterowany zdarzeniami (EPC) jest dynamicznym modelem, który łączy ze sobą statyczne zasoby (osoba, dokumenty, aplikacje itp.) i układa je tak, aby dostarczyć sekwencje zadań lub czynności (proces), które tworzą wartość dodaną. Moim zdaniem jest to najlepsza metodologia, aby zrealizować cel określony w nagłówku tego posta.
Co dalej ? Ja skupiam się na poniższym:
Tuż przed startem systemu, poprawiamy mapy na procesy docelowe uwzględniając koncepcję wdrożenia i wyniki testów. Te mapy będą obrazowały funkcjonowanie przedsiębiorstwa po starcie produktywnym systemu.
To podejście ma dwie zalety. Analiza procesów, przebiegnie szybko i bezproblemowo, ponowna analiza tuż przed startem będzie jednocześnie wartościowym elementem instrukcji stanowiskowych