Rozdział 1. Po co robić analizę przedwdrożeniową

Rozdział 1 pokazuje, jak w praktyce potraktować obszar: po co robić analizę przedwdrożeniową. W analizie przedwdrożeniowej nie chodzi o sporządzenie eleganckiego dokumentu dla samego dokumentu. Chodzi o zbudowanie wspólnego rozumienia procesu oraz o przygotowanie decyzji, które później przełożą się na konfigurację systemu, integracje, dane, szkolenia i sposób pracy użytkowników.

Obszar „sens analizy” warto omawiać bardzo konkretnie. Analityk powinien pytać nie tylko o to, jak firma chciałaby pracować, lecz przede wszystkim o to, jak pracuje dziś: kto wykonuje czynność, gdzie zapisuje informację, kto ją sprawdza, kiedy powstaje błąd, jakie są wyjątki i co dzieje się, gdy zabraknie danych. Dopiero wtedy można oddzielić realną potrzebę od przyzwyczajenia.

Obszar „granice projektu” warto omawiać bardzo konkretnie. Analityk powinien pytać nie tylko o to, jak firma chciałaby pracować, lecz przede wszystkim o to, jak pracuje dziś: kto wykonuje czynność, gdzie zapisuje informację, kto ją sprawdza, kiedy powstaje błąd, jakie są wyjątki i co dzieje się, gdy zabraknie danych. Dopiero wtedy można oddzielić realną potrzebę od przyzwyczajenia.

Obszar „decyzje zarządu” warto omawiać bardzo konkretnie. Analityk powinien pytać nie tylko o to, jak firma chciałaby pracować, lecz przede wszystkim o to, jak pracuje dziś: kto wykonuje czynność, gdzie zapisuje informację, kto ją sprawdza, kiedy powstaje błąd, jakie są wyjątki i co dzieje się, gdy zabraknie danych. Dopiero wtedy można oddzielić realną potrzebę od przyzwyczajenia.

Obszar „koszt braku analizy” warto omawiać bardzo konkretnie. Analityk powinien pytać nie tylko o to, jak firma chciałaby pracować, lecz przede wszystkim o to, jak pracuje dziś: kto wykonuje czynność, gdzie zapisuje informację, kto ją sprawdza, kiedy powstaje błąd, jakie są wyjątki i co dzieje się, gdy zabraknie danych. Dopiero wtedy można oddzielić realną potrzebę od przyzwyczajenia.

Obszar „efekt końcowy” warto omawiać bardzo konkretnie. Analityk powinien pytać nie tylko o to, jak firma chciałaby pracować, lecz przede wszystkim o to, jak pracuje dziś: kto wykonuje czynność, gdzie zapisuje informację, kto ją sprawdza, kiedy powstaje błąd, jakie są wyjątki i co dzieje się, gdy zabraknie danych. Dopiero wtedy można oddzielić realną potrzebę od przyzwyczajenia.

Problem, który trzeba zobaczyć. W wielu firmach problem nie jest ukryty w braku programu, ale w braku wspólnego obrazu procesu. Każdy dział zna swój fragment pracy, lecz mało kto potrafi opisać całość od zapytania klienta, przez przygotowanie technologii, planowanie, zakupy, magazyn, produkcję, kontrolę jakości, aż po wysyłkę i rozliczenie. Analiza przedwdrożeniowa ma wydobyć tę wiedzę z głów ludzi i zamienić ją w materiał, na podstawie którego można podjąć decyzję.

W kontekście rozdziału „Po co robić analizę przedwdrożeniową” oznacza to konieczność zadania prostych pytań: jakie dane są potrzebne przed rozpoczęciem pracy, kto zatwierdza zmianę, jakie statusy muszą być widoczne dla innych działów i które czynności powinny zostać obsłużone przez system, a które nadal mogą pozostać poza nim. Zbyt ogólne odpowiedzi są sygnałem, że analiza wymaga pogłębienia.

Co powinno być wynikiem. Dobry wynik analizy to nie tylko opis obecnego stanu. To także katalog problemów, mapa procesu docelowego, lista wymagań, ocena jakości danych, zakres integracji, warianty wdrożenia, plan etapów, ryzyka oraz wstępna wycena. Dokument powinien być zrozumiały dla zarządu, kierownika produkcji, konsultanta, informatyka i przyszłych użytkowników systemu.

Jak rozmawiać z użytkownikami. Wywiad nie powinien przypominać przesłuchania. Konsultant musi zadawać konkretne pytania, ale jednocześnie słuchać języka firmy. Operator, magazynier, technolog i planista często używają innych pojęć niż dostawca systemu. Zadaniem analityka jest przełożyć realną pracę na wymagania, a nie udowadniać uczestnikom, że używają niewłaściwych nazw.

Najczęstsze błędne założenie. Najbardziej ryzykowne założenie brzmi: wdrożymy system i proces sam się uporządkuje. W praktyce system tylko przyspiesza to, co zostało dobrze zaprojektowane, oraz obnaża to, co pozostało niejasne. Jeżeli indeksy są zdublowane, BOM-y nieaktualne, marszruty niepełne, a odpowiedzialności rozmyte, system nie usunie tych problemów automatycznie.

Decyzje, które trzeba podjąć. Analiza powinna prowadzić do decyzji. Trzeba określić, które obszary wdrażamy w pierwszym etapie, które zostają na później, gdzie potrzebna jest zmiana procesu, gdzie wystarczy konfiguracja, a gdzie konieczne jest programowanie lub integracja. Brak decyzji na etapie analizy często wraca później jako opóźnienie, koszt dodatkowy albo konflikt.

Miernik jakości analizy. Jakość analizy można ocenić po tym, czy po jej zakończeniu strony wiedzą, co dokładnie ma być wdrożone, czego nie będzie w zakresie, jakie dane trzeba przygotować, jakie są zależności między działami i kto odpowiada za kolejne kroki. Jeżeli po analizie nadal dominuje zdanie „to wyjdzie w trakcie”, dokument nie spełnił swojej roli.

Przykład z praktyki: Firma metalowa. Firma produkująca konstrukcje stalowe miała problem z terminami. Analiza pokazała, że główną przyczyną nie był brak mocy produkcyjnych, lecz nieaktualne marszruty i brak rezerwacji materiałów pod zlecenia. System planował prace, ale nie widział, że część komponentów została już zużyta na pilne zlecenia. Wniosek z takiego przypadku jest prosty: analiza nie może ograniczać się do listy funkcji. Musi wyjaśnić, dlaczego dana funkcja jest potrzebna, jakie dane ją zasilają i kto będzie korzystał z wyniku.

Pytania kontrolne dla tego obszaru: Jak dziś powstaje informacja i kto jest jej właścicielem? Które dane są wpisywane raz, a które przepisywane kilka razy? Gdzie pracownicy omijają oficjalną procedurę i dlaczego? Jakie decyzje są podejmowane na podstawie pamięci, a nie danych? Który problem występuje regularnie, ale firma traktuje go jako normalny? Co musi być gotowe przed startem pilota? Jak rozpoznamy, że wdrożenie przyniosło realną poprawę?

Typowe artefakty analizy w tym obszarze to: opis procesu, lista problemów, lista decyzji, tabela wymagań, lista danych do przygotowania, mapa zależności oraz zestaw ryzyk. Każdy artefakt powinien mieć właściciela i termin weryfikacji. Bez tego dokument analizy będzie wyglądał profesjonalnie, ale nie przełoży się na działanie.

Najważniejsza zasada brzmi: nie dokumentuj wszystkiego z taką samą dokładnością. Najwięcej energii poświęć miejscom, w których powstaje koszt, opóźnienie, konflikt, brak danych albo ryzyko jakościowe. Mniej istotne obszary opisz krócej, ale zachowaj spójny format, żeby w kolejnych etapach łatwo było wrócić do ustaleń.

Warto także oddzielić wymagania pierwszego etapu od wymagań rozwojowych. W MŚP często próbuje się za jednym razem wdrożyć zlecenia, MRP, MES, WMS, QMS, APS, raporty zarządcze i integrację z księgowością. Analiza powinna pokazać kolejność, a nie tylko pełną listę życzeń. Dobre etapowanie chroni projekt przed przeciążeniem.

Tabela kontrolna rozdziału

Element	Pytanie kontrolne	Oczekiwany wynik
ustalony właściciel procesu	Czy obszar „ustalony właściciel procesu” został opisany dla procesu po co robić analizę przedwdrożeniową?	decyzja, właściciel, ryzyko lub wymaganie
opisane wejścia i wyjścia	Czy obszar „opisane wejścia i wyjścia” został opisany dla procesu po co robić analizę przedwdrożeniową?	decyzja, właściciel, ryzyko lub wymaganie
znane dokumenty i systemy	Czy obszar „znane dokumenty i systemy” został opisany dla procesu po co robić analizę przedwdrożeniową?	decyzja, właściciel, ryzyko lub wymaganie
wskazane wyjątki	Czy obszar „wskazane wyjątki” został opisany dla procesu po co robić analizę przedwdrożeniową?	decyzja, właściciel, ryzyko lub wymaganie
opisane problemy i ich skutki	Czy obszar „opisane problemy i ich skutki” został opisany dla procesu po co robić analizę przedwdrożeniową?	decyzja, właściciel, ryzyko lub wymaganie

Mini-checklista dla konsultanta

· ustalony właściciel procesu

· opisane wejścia i wyjścia

· znane dokumenty i systemy

· wskazane wyjątki

· opisane problemy i ich skutki

· określone wymagania wobec systemu

· wskazane dane do migracji

· zidentyfikowane ryzyka

· zatwierdzony zakres pierwszego etapu

· ustalony sposób pomiaru efektu

Notatka wdrożeniowa

W każdej analizie warto tworzyć rejestr decyzji otwartych. Są to tematy, których nie da się rozstrzygnąć na spotkaniu, ale nie wolno ich zgubić. Typowe przykłady to sposób numeracji indeksów, zakres integracji z ERP, moment rozchodu materiału, odpowiedzialność za poprawność BOM, poziom szczegółowości meldunków i zasady blokady jakościowej. Rejestr decyzji chroni projekt przed pozorną zgodą.

Dobrym nawykiem jest opisywanie wymagań językiem użytkownika i dopiero późniejsze tłumaczenie ich na język systemu. Użytkownik może powiedzieć: chcę widzieć, które zlecenia stoją, bo brakuje materiału. Wymaganie systemowe może brzmieć: lista zleceń z automatycznym statusem dostępności materiałowej, wyliczanym na podstawie BOM, rezerwacji i stanów magazynowych. Oba zapisy są potrzebne, ale służą różnym odbiorcom.

Analiza powinna kończyć się nie tylko dokumentem, lecz także rozmową podsumowującą z decydentami. Na tym spotkaniu trzeba pokazać zakres, ryzyka, koszt, priorytety i obszary sporne. Właściciel lub zarząd musi świadomie zaakceptować, że niektóre funkcje będą w pierwszym etapie, inne później, a część pomysłów nie zostanie wdrożona, bo ich koszt przewyższa korzyść.

Analizując ten fragment, konsultant powinien zawsze rozróżnić trzy poziomy: opis faktów, interpretację problemu oraz rekomendację zmiany. Faktem jest na przykład to, że status zlecenia jest zmieniany ręcznie raz dziennie. Interpretacją jest stwierdzenie, że użytkownicy nie mają bieżącej informacji. Rekomendacją może być terminal produkcyjny, automatyczny status operacji lub prostsza procedura raportowania. Mieszanie tych poziomów prowadzi do sporów, bo uczestnicy warsztatów zaczynają dyskutować o rozwiązaniu, zanim zgodzą się co do problemu.