Artur Jaworski Blog

Ten post jest uzupełnieniem wpisu, który możesz przeczytać tu. A więc przedstawiam dodatkowe informacje co możesz zrobić, aby stać się konsultantem wdrożeniowym.

Sama świadomość chęci zamiany to dużo, jednakże proponuję również abyś przed rozpoczęciem konkretnych działań zasięgnął języka u osoby, która wykonuje dokładnie to co Ty planujesz robić. Dla przykładu, jeżeli chcesz podyskutować o pozytywach i negatywach bycia konsultantem SAP wystarczy odezwać się do mnie za pomocą kanałów podanych tu lub zadać pytanie w komentarzach (w ten sposób więcej osób może z niego skorzystać). Generalną zasadą jaką stosuję podczas zasięgania opinii u osób trzecich, to fakt, że dana osoba jest praktykiem w tym temacie, to jest służy własnym doświadczeniem, a nie powtarza zasłyszane kwestie. Jeżeli chcesz funkcjonować w podobny sposób jak ktoś już to robiący, to jest on najlepszym ekspertem do zapytania i bardzo często chętnie udzieli Ci cennych wskazówek. Uważaj natomiast na “rady” osób, które nie mają praktycznych doświadczeń w temacie na który się wypowiadają. Słuchaj tych, których świat jest podobny do tego w jakim Ty chcesz się obracać.

Jeżeli jesteś na 100% przekonany, że chcesz wejść w Konsulting i masz dostępu do systemu SAP jako użytkownik systemu produkcyjnego posiadasz następujące opcje:

Struktura systemów SAP w Twojej firmie, musi składać się co najmniej z trzech systemów: developerski, testowy oraz produkcyjny. Wszelkie zmiany w konfiguracji, wprowadzane są na systemie developerskim a następnie transportowane przez testowy na produkcyjny. Poproś w swojej firmie o dostęp co najmniej do systemu testowego, gdzie będziesz mógł w bezpieczny sposób powiększać swoje umiejętności na temat systemu. Nie będzie tu możliwe ćwiczenie konfiguracji ponieważ system ten najczęściej ma zablokowaną taką funkcjonalność. Sprawdź czy w Twojej firmie jest dostępny bezpieczny mandant, gdzie bez zagrożenia dla bezpieczeństwa spójności systemów można testować nowe rozwiązania.

Argumentując swoją prośbę zaznacz, że nie będzie to zagrożeniem dla poprawności wykonywania Twoich normalnych obowiązków, że zwiększanie Twojej wiedzy na temat SAP będzie korzystne dla wszystkich stron. Dla przykładu właśnie takimi działaniami możesz odkryć, że pewne procesy mogą być lepiej wspierane przez system. Jeszcze raz podkreślam, można to łatwo zorganizować w taki sposób, aby nie zagrażało spójności konfiguracji po między systemami. Jeżeli powyższe nie przekona Twojego pracodawcy, to przemyśl czy jesteś we właściwym miejscu :).

Jeżeli jesteś już na 100% przekonany, że chcesz wejść w Konsulting i nie masz dostęu do systemu SAP masz następujące opcje:

Zatrudnić się w firmie, która eksploatuje SAP oraz wykonać co napisałem powyżej lub w firmie konsultingowej (partner SAP) jako konsultant Junior. Ostatnio doszły do mnie słuchy, że nie jest to taki proste, to jest firmy te w większości poszukują ludzi z doświadczeniem, których od razu można wrzucić na głęboką wodę. Rozumiem to podejście, jednakże wiem doskonale, że podczas projektu jest również miejsce dla osób, które zbierając doświadczenie będą wykonywac masę bardzo ważnej pracy takiej jak: dokumentacja testów, materiały szkoleniowe, protokoły i organizacja spotkań itp. W ten sposób można uczyć się konkretnych technicznych umiejętności i jednocześnie odciąrzyć konsultanta wiodącego. To czysty biznesowy układu win-win, gdzie obie strony zyskują w konkretnych kwestiach, wystarczy je jasno zdeklarować.

Tak wiec starając się o posadą junior konsultanta, podkreśl swoją determinację i chęć wykonywania tej pracy, przedstaw swojemu pracodawcy korzyści jakie osiągnie zatrudniając Ciebie (odciążenie konsultanta wiodącego, dobrze rokującą zdeterminowaną osobę itp.) oraz zaakceptuj fakt, że proces nauki jest stosunkowo długi (co najmniej kilka miesięcy) a w tym okresie pensja nie będzie oszałamiająca. Rozważ również propozycję, którą Alex opisuje w tym poście.

Ciekawą opcją jest poproszenie freelancera o możliwość współpracy z nim, korzyści dla niego będą podobne jak te napisane wyżej, a jeżeli jest teraz w ciekawym projekcie to proces Twojej nauki będzie jeszcze wydajniejszy.

Generalnie bazując na własnych doświadczeniach polecam, aby zadawać pytania, jest bardzo duża ilość osób (np. ja) które są chętnie do bezinteresownej pomocy, a jeżeli nie uzyskasz żadnej odpowiedzi to i tak nie pogarszasz swojej pozycji wyjściowej. Nic nie tracisz, ale wybór jak zawsze należy do Ciebie.

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:

1. Potrzeba biznesowa (raport, rozszerzenie, nowa funkcjonalność itp.) - klient
2. Opracowanie specyfikacji programu (opis zagadnienia, wstępny algorytm działania, dane testowe itp.) – konsultant modułowy
3. Wykonanie programu - programista
4. Testy akceptacyjne + korekty – konsultant, klient, programista
5. Produktywne użytkowanie - klient

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ę:

• Kim są przyszli użytkownicy programu
• Jaką wartość dodaną dostarczy dana implementacja
• Jakie są korzyści i koszty
• Na jakie procesy dany program będzie miał wpływ
• Itp.

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