Artur Jaworski Blog

Raporty - temat który podczas wdrażania pakietu SAP jest traktowany pobieżnie lub odsuwany na późniejszy lepszy moment. Nawet, jeśli podczas fazy implementacji przyłożyliśmy się do tego elementu, to w trakcie eksploatacji systemu pojawiają się nowe potrzeby biznesowe związane z raportowym wydobywaniem danych z systemu.
Przy rozmowach o raportowaniu należy pamiętać o jednym ograniczeniu: szczegółowość danych uzyskiwanych z systemu nie może być większa od szczegółowości przy ich wprowadzaniu. Poza tym wszystko czeka grzecznie w tabelach. Kwestią otwartą jest jak się do nich dobrać ? Od wersji 4.6 dostępna jest transakcja SQVI, która w przystępny sposób (bez konieczności programowania) umożliwia stworzenie raportu.
Do transakcji można też dostać się z menu głównego: System -> Usługi -> Szybki przegląd

Poniższy przykład odnosi się do danych z modułu gospodarki remontowej PM, przedstawia zestawienie potwierdzonej robocizna własnej (potwierdzenia) w odniesieniu do elementów PSP na które zlecenie jest rozliczane. W pierwszym kroku należy podać nazwę raportu oraz nacisnąć Tworzenie
 
W polu 1. Źródło danych, wybieramy z dostępnych wartości miejsce pozyskiwania informacji.
Tabele – umożliwia uzyskanie danych tylko z jednej tabeli, jest alternatywą do transakcji SE16N.
Połączenie tabel – dwie lub więcej połączonych tabel
Logiczna baza danych – zdefiniowane przez SAP zbiory danych, umożliwiające uzyskanie danych z wielu tabel.
SAP Query InfoSet: - Zestaw tabel wykorzystywanych w zapytaniach w systemie. Umożliwiają dostęp poprzez SQVI do już utworzonych zapytań (queries).
Ja w tym przykładzie wykorzystuje standardową Logiczną bazę danych AFI. Jednakże równie dobrze można wykorzystywać łączone tabele.

Kolejnym krokiem jest wskazanie pól, które są istotne dla naszego zestawienia. Dokonujemy tego przez zaznaczenie checkboxa w lewej części ekranu lub poprzez wybranie z listy dostępnych pól znajdujących się w prawej części ekranu.
Ja wybrałem:
DIAUFK-TPLNR Lokalizacja funkcjonalna
DIAUFK-PSPEL Element planu strukturalnego projektu (element PSP)
DIAUFK-INGPR Grupa planistów dla Usł. serw. dla klienta i Gospod. remont.
DIAUFK-AUFNR Nr zlecenia
DIAUFK-AUART Rodzaj zlecenia
DIAFVC-STEUS Klucz sterujący
DIAFVC-LTXA1 Krótki tekst operacji
DIAFRU-RUECK Numer potwierdzenia operacji
DIAFRU-ISMNW Praca rzeczywista
DIAFRU-GEWRK Stanowisko robocze
DIAFRU-ERSDA Data wprowadzenie potwierdzenia

Kolejnym wartościowym ustawieniem jest wybranie sposobu wyprowadzania danych z raportu.

Po uruchomieniu raportu (F8), na pierwszym ekranie widoczne są pola służące do ograniczenia listy wyników. Znajdują się tu zarówno te własnoręcznie dodane oraz te które są domyślne dla danej struktury.

Po wprowadzeniu warunków ograniczających pozostaje wykonać raport
Jeżeli chcemy pokazać światu nasz raport, wystarczy w nowej sesji uruchomić transakcję SE38, wówczas system podpowie nazwę ostatnio przetwarzanego raportu. W moim przypadku nazwa to: AQTGSYSTQV000031AJ_PM_ROB=====. Wystarczy podać ją innym użytkownikom, którzy będą korzystać z raportu poprzez SE38.
Inną drogą jest podanie nazwy raportu do programisty ABAP, który może dodać do niego nazwę transakcji lub profil uprawnień jeżeli jest to wymagane.
Miłego używania, w przypadku pytań zawsze chętnie pomogę

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

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.

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.

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.

1. Rekrutując na stanowisko specjalistyczne, wiedza na temat tej branży musi być na poziomie umożliwiającym skonfrontowanie wymagań oferty z doświadczeniem wpisanym w CV. Na przykład, jeżeli szukam konsultanta SAP, to trzeba wiedzieć że system jest modułowy (finanse, kontroling, logistyka itp.), jakie są etapy wdrożenia, czym różni się roll-out od nowego wdrożenia itd.
2. Jeżeli oferta skierowana jest do osoby z doświadczeniem, unikam sformułowań typu: “atrakcyjne wynagrodzenie”, “możliwość rozwoju”, “zebranie cennych doświadczeń”. No chyba, że mam przygotowane konkretne odpowiedzi na pytania doprecyzowujące do tych sformułowań. Nawet jeśli tak, czy na pewno będą zbieżne z oczekiwaniami pytającego ? Możliwości rozwoju to baaaardzo szeroki temat, każdy ma swoją mapę świata i inne potrzeby rozwojowe.
3. List kończę zdaniem: “Będę wdzięczny za informację zwrotną o Pana decyzji”. Z szacunkiem dla czasu wszystkich stron proszę o jednoznaczną deklarację.

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.

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:

• Ilość i szczegółowość map. Tu po prostu trzeba kierować się zdrowym rozsądkiem i każdą decyzję podejmować z uwzględnieniem celu naszych działań. Nie ma na pewno potrzeby, rozbudowania przebiegu procesu o elementy, które nie są istotne z punktu widzenia prac przy wdrożeniu systemu IT (na tym etapie niezbędna jest wiedza co to za pakiet i co zawiera). Pamiętaj, że każda dodatkowa czynności czy element w procesie zmniejsza jego czytelność czytelność i chęć do analizy przez osoby trzecie.
• Na tym etapie muszą to być procesy obecne. Wśród wielu kierowników projektów obserwuję, nieodpartą chęć od razu mapowania procesów docelowych. Nie jest to najlepsze podejście z bardzo prostego powodu. Aby móc określić proces docelowy, wymagana jest po stronie osób merytorycznie odpowiedzialnych za proces, dobra znajomość pakietu ERP. Ta wiedza, będzie dostępna dopiero po zakończeniu fazy konfiguracji i testów. Te mapy mają być jedynie materiałem wejściowym do fazy, w której tworzona jest koncepcja wdrożenia.

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

Sukces sprawnego wdrożenia pakietu ERP, wymaga pełnego zaangażowania obu stron to jest: Kupującego i Wdrażającego. Od kupującego wymagana jest świadomość tego co nabywa, oraz przygotowania swojej organizacji do zmiany. Wdrażający również powinien zainteresować się, czy Kupujący odrobił swoją pracę domową, w przeciwnym razie istnieje duże prawdopodobieństwo, że nie zrealizuje zadania zgodnie z harmonogramem i budżetem. Śmiem twierdzić, że większość niezrealizowanych o czasie projektów IT, jest wynikiem braku przygotowania organizacji do tak dużej zmiany, jeżeli chcesz robić biznes na wdrożeniach sprawdź gotowość Twojego klienta do zmiany oraz jego potrzeby w zakresie IT. To długofalowo jest dobre dla obu stron. No chyba, że celem Twojej działalności jest rozpowszechnienie informatyzacji traktowane jako hobby i działalność niezorientowaną na zysk.
W momencie, gdy Kupujący jest gotowy do zmiany, wybrał już najlepiej dopasowany do własnych potrzeb system IT pozostało podpisać umowę wdrożeniową z świadomie wyselekcjonowanym dostawcą usług konsultingowych.

Metodologie wdrożenia… moim zdaniem co innego dostarczy większych korzyści.
Sama metodologia wdrożenia (sposób działania w projekcie) moim zdaniem ma drugorzędne znacznie, tzn dopracowanie poniższych tematów ma o wiele większe przełożenie na terminowe i zgodne z budżetem zakończenie prac. Z tego też powodu na tym koncentruję swoje działania.

Zespoły wdrożeniowe.
Idealny członek zespołu wdrożeniowego po stronie Kupującego to młoda osoba, która jest w firmie od co najmniej dwóch lat. Pod określeniem młoda, rozumiem pracownika, który doskonale wie czym jest „core biznes” swojego przedsiębiorstwa, ma potencjał wzrostu, bystrość umysłu oraz czuje co to software komputerowy. Taka umiejętność wyobrażenia sobie, czym jest program, co to są linie kodu, jest niezbędna przy analizie kosztu do korzyści, która jest wykonywana w momencie podejmowania decyzji o objęciu wdrożeniem danej czynności w procesie. Szybkie podejmowanie trafnych decyzji jest kluczowe dla wszystkich faz projektu.

Fundusz motywacyjny
Zwolnienie z normalnie wykonywanych obowiązków wszystkich członków zespołów wdrożeniowych może być zagrożeniem dla płynnego funkcjonowanie przedsiębiorstwa. Z tego też powodu, gorąco polecam opracowanie pokaźnego funduszu motywacyjnego. Celem tego funduszu jest motywowanie pracowników, docenienie przejściowego okresu, w którym pracują na więcej niż 100%. Zgrubne reguły podziału funduszu, muszą być jasne i podane do publicznej wiadomości na samym początku wdrożenia. W temacie motywacji, należy pamiętać, aby stale podkreślać jak ważny jest to projekt dla zarządu o Prezesie nie zapominając.

Standard pakietu
Należy wykorzystywać standardowe funkcjonalności i procesy pakietu ERP, tam gdzie skutecznie realizują założony cel, nawet jeżeli dawniej robiono to inaczej. Temat jest pokrewny z właściwym przygotowaniem do wdrożenia, o którym pisałem na początku. Przy modyfikacji standardu danego rozwiązania, należy pamiętać o następujących konsekwencjach:

Główną zaletą pakietów pudełkowych jest fakt, że zawierają one w sobie gotowe procesy biznesowe. Naszym zadaniem jest określenie, których chcemy używać oraz skonfigurowanie struktury przedsiębiorstwa w systemie. W momencie, gdy dokonujemy modyfikacji standardowego procesu, to oprócz utraty gwarancji na tę część systemu, potencjalnych kłopotów przy ugrejdzie a nawet po wczytaniu not korygujących należy pamiętać że: w pakietach ERP, konkretne linie kodu uruchamiają się w zależności od akcji użytkownika podczas jego pracy. Naciśnięcie lub nie danego przycisku, uaktywnia funkcją zapisaną przez linie kodu. Z tego prostego powodu, zakodowanie rozwiązania w programie, który „żyje własnym życiem” nawet gdy algorytm jest prosty nie jest banalne. Cała trudność polega na połączeniu nowego programu ze standardem. Jakość naszej pracy jest możliwa do zweryfikowania dopiero po uruchomienieu nowej funkcjonalności. Wówczas dopiero widoczne są tematy, które z uwagi na ogromne ilości standardowego kodu pakietu ERP, nie były do przewidzenia na etapie opracowywania specyfikacji. W efekcie potrzebujemy dużego budżetu na testowanie rozwiązania, w wielu przypadkach jest to taka niekończąca się historia, po wyeliminowaniu danego błędu pojawiają się nowe.
Powyższe przykłady nie zagwarantują oczywiście 100% skuteczności (kolejne opisze w oddzielnych postach), moim zdaniem skupienie się na nich, dostarczy największego rezultatu. Dopilnowanie tych tematów leży w interesie wszystkich stron w s p ó l n e g o projektu.

Przed takim dylematem, stają osoby którym wyznaczono cel: załatw nam system komputerowy. Pod terminem pudełko rozumiem dowolny pakiet ERP, który kupujemy, instalujemy, wdrażamy a potem użytkujemy. Czysta kartka to system informatyczny tworzony na indywidualne zamówienie w dowolnym narzędziu deweloperskim. Najpierw trzeba go napisać, wdrożyć a potem użytkować.

Czego nie załatwi nam żaden system komputerowy?
Niezależnie od tego czy kupimy gotowy ERP, czy napiszemy coś od zera to wcześniej musimy dokładnie wiedzieć, w jakim celu to robimy. Jakie mają być konkretne korzyści z implementacji systemu IT. Nasze motywacje mogą być dowolne, np. analiza procesowa kosztów, zmniejszenie stanów magazynowych, czy dostęp do raportów poprzez portal. Ważne jest, że taki cel musi być jasno określony. Żaden, nawet najmodniejszy system, nie określi strategii działania przedsiębiorstwa, sam w sobie nie jest modelem poprawnego funkcjonowania. Na tym etapie rozwoju ludzkości (sztuczna inteligencja jest ciągle celem) system komputerowy służy do wspomagania nas w operacyjnej działalności, automatyzuje konkretne czynności zapewnia dostęp do informacji. Należy jednak pamiętać, ze ma on być nakładką na dobrze funkcjonujący biznes, a nie lekiem na bieżące problemy. Przed wdrożeniem należy dokładnie przygotować organizację, począwszy od ludzi, którzy ją tworzą na optymalizacji procesów, które chcemy informatyzować kończąc. Bez odrobienia tej pracy domowej, nawet dobrze określony cel trudno będzie zrealizować, przy założeniu że chcemy to zrobić w określonym czasie i budżecie.

Nasuwa się pytanie co wybrać?
Panuje powszechne przekonanie, że w grze pozostały tylko pakiety ERP, że nikt już nie pisze systemu od początku, że świat IT wie doskonale czym jest „paradoks produktywności IT” czyli sytuacja, że korzyści z informatyzacji są niewspółmierne do kosztów wytworzenia oprogramowania. W efekcie wiele decyzji o zakupie pakietu pudełkowego, jest podejmowanych pod wpływem mody, skoro tylu znajomych prezesów się na to zdecydowało to coś w tym musi być. Ja proponuję inne rozwiązanie. Przed wyborem rodzaju systemu należy pamiętać o elementarnej sprawie. Pakiety ERP zawierają same w sobie gotowe procesy biznesowe, kupując taki program kupujemy jednocześnie sposób, w jaki funkcjonować. Oczywiście można powiedzieć że są to elastyczne pakiety konfigurowalne, że można dostosować je do konkretnych potrzeb. Moja odpowiedź: TAK z tym że konfiguracja sprowadza się do wprowadzenia struktur naszej organizacji do pakietu ERP oraz wybrania których modułów chcemy używać. Jak ich używać jest „narzucone” przez pakiet. Jeżeli znasz swoje procesy, to jest wiesz, które czynności chcesz objąć informatyzacją, sprawdź ile z nich jest do realizacji standardowymi procesami pakietu ERP. Jeżeli jest ich ponad 90% to wszystko ok, kupując dane rozwiązanie wszyscy będą zadowoleni. Jeżeli mniej masz dwie opcje, przemodelować przebiegi procesów aby można było realizować je standardem, lub skorzystać z czystej kartki i napisać sobie system od początku. Która opcja jest lepsza wymaga analizy konkretnego przypadku. Deweloperka w pakiecie ERP, który żyje swoim życiem jest jak najbardziej możliwa jednakże ma to swoją cenę. Temat ten z uwagi na częstość jego występowania w Polsce opiszą w oddzielnym poście.