Wdrożenie systemu IT nie powinno zaczynać się od konfiguracji, wyboru pól w formularzu ani pierwszych prac programistycznych. Powinno zaczynać się od zrozumienia procesu: jak firma działa dzisiaj, jak chce działać po wdrożeniu, jakie dane są potrzebne, kto podejmuje decyzje i które systemy mają ze sobą współpracować.
System nie naprawi chaosu, jeżeli wcześniej nie wiadomo, jak działa proces. Może go jedynie przyspieszyć.
To jedna z najważniejszych zasad w projektach IT. Dotyczy zarówno firm zamawiających oprogramowanie, jak i software house’ów, integratorów oraz zespołów wdrożeniowych. Jeżeli potrzeba biznesowa nie zostanie dobrze opisana, a wymagania nie zostaną uporządkowane, projekt bardzo szybko zaczyna opierać się na domysłach.
Zamawiający myśli, że wykonawca rozumie jego proces. Wykonawca zakłada, że klient wie, czego potrzebuje. Użytkownicy końcowi oczekują czegoś innego niż osoby decyzyjne. A gdy system zaczyna powstawać, okazuje się, że każda ze stron wyobrażała sobie rozwiązanie trochę inaczej.
Właśnie dlatego analiza biznesowo-systemowa nie jest zbędnym etapem ani formalnością. Jest sposobem na ograniczenie ryzyka, kosztów i konfliktów w projekcie.
Konfiguracja systemu to nie początek wdrożenia
W wielu projektach naturalna pokusa jest prosta: zacznijmy od razu działać. Skonfigurujmy system. Uruchommy moduł. Dodajmy użytkowników. Napiszmy integrację. Przygotujmy formularz. Zróbmy pierwszą wersję i zobaczymy, co wyjdzie.
Takie podejście może działać przy bardzo prostych wdrożeniach. Jednak gdy projekt dotyczy kilku działów, wielu użytkowników, integracji z ERP, obiegu dokumentów, stanów magazynowych, rozliczeń, uprawnień albo raportowania, rozpoczęcie od konfiguracji jest ryzykowne.
Konfiguracja odpowiada na pytanie: „jak ustawić system?”.
Analiza odpowiada na ważniejsze pytanie: „co ten system ma właściwie obsłużyć i dlaczego?”.
Jeżeli tego drugiego pytania nie zadamy wystarczająco wcześnie, system może zostać poprawnie skonfigurowany technicznie, ale nadal nie będzie odpowiadał na realną potrzebę organizacji.
Najczęstszy błąd: wykonawca pyta o ustawienia, a nie o proces
W projektach IT często pojawia się sytuacja, w której rozmowa zbyt szybko schodzi na poziom ustawień systemu.
- Czy pole ma być obowiązkowe?
- Jaki ma być status?
- Kto ma mieć dostęp?
- Czy dodać checkbox?
- Czy raport ma mieć taki czy inny filtr?
To są ważne pytania, ale powinny wynikać z procesu. Jeżeli zaczynamy od szczegółów interfejsu lub konfiguracji, łatwo pominąć sedno: po co użytkownik wykonuje daną czynność, jaka decyzja ma zostać podjęta, jakie dane są potrzebne dalej i co stanie się w przypadku wyjątku.
Przykład: można zapytać, czy w formularzu wniosku o nadgodziny ma być pole „projekt”. Ale ważniejsze pytanie brzmi: czy nadgodziny są rozliczane względem projektu, budżetu lub centrum kosztów? Jeżeli tak, to pole „projekt” nie jest tylko elementem formularza. Staje się częścią procesu rozliczenia, integracji i raportowania.
Podobnie w e-commerce można zapytać, czy sklep ma pobierać stan magazynowy z WMS. Ale najpierw trzeba ustalić, który system jest źródłem prawdy dla stanów, jak działa rezerwacja, co dzieje się przy sprzedaży stacjonarnej i jak obsługiwać braki magazynowe.
Bez analizy można poprawnie wykonać niewłaściwe ustawienia.
Dlaczego brak analizy prowadzi do konfliktów?
W projektach IT konflikty rzadko zaczynają się od złej woli. Najczęściej wynikają z różnego rozumienia tego samego zamówienia.
Zamawiający mówi: „potrzebujemy modułu do obsługi wniosków”. Wykonawca rozumie: formularz, statusy i lista spraw. HR oczekuje: ścieżek akceptacji, limitów, raportów i zgodności z zasadami organizacji. Pracownik oczekuje: prostego ekranu i jasnej informacji, co się dzieje z jego sprawą. Zarząd oczekuje: kontroli, obniżenia ryzyka i lepszej efektywności.
Każda z tych perspektyw jest uzasadniona, ale bez analizy nie zostaje zamieniona w spójny zakres prac.
Wtedy pojawiają się zdania:
- „przecież to miało działać inaczej”,
- „myśleliśmy, że to jest w standardzie”,
- „wykonawca tego nie przewidział”,
- „klient nie powiedział, że to jest potrzebne”,
- „to wymaga dodatkowej wyceny”,
- „tego nie było w zakresie”.
Dobra analiza nie usuwa wszystkich ryzyk, ale znacząco ogranicza liczbę takich sytuacji. Pozwala wcześniej nazwać proces, wyjątki, odpowiedzialności, integracje i oczekiwane efekty.
Co trzeba ustalić przed wdrożeniem?
Przed rozpoczęciem konfiguracji albo prac programistycznych warto ustalić przynajmniej kilka podstawowych elementów.
Cel biznesowy
Najpierw trzeba odpowiedzieć na pytanie, po co projekt jest realizowany. Czy chodzi o ograniczenie ręcznej pracy? Zmniejszenie liczby błędów? Przyspieszenie obsługi klienta? Lepszą kontrolę nad procesem? Uporządkowanie danych? Integrację systemów?
Bez celu biznesowego trudno później ocenić, czy wdrożenie się udało.
Obecny proces
Trzeba zrozumieć, jak firma działa dzisiaj. Nawet jeżeli obecny proces jest nieidealny, warto go opisać. To pozwala zobaczyć, gdzie są ręczne czynności, arkusze, obejścia, podwójne wprowadzanie danych i miejsca, w których powstają błędy.
Docelowy proces
Następnie trzeba zaprojektować, jak proces ma działać po wdrożeniu. Nie jako lista funkcji, ale jako przebieg działań: kto zaczyna, co wprowadza, kto akceptuje, jakie dane są walidowane, co dzieje się dalej i kiedy proces się kończy.
Systemy biorące udział w procesie
Wdrożenie rzadko dotyczy jednego systemu. W procesie mogą uczestniczyć ERP, WMS, CRM, sklep internetowy, aplikacja pracownicza, system projektów, narzędzia raportowe, systemy księgowe, moduły płacowe, integratory i API.
Trzeba jasno określić, który system za co odpowiada.
Dane i źródła prawdy
To jeden z najważniejszych punktów. Trzeba ustalić, skąd pochodzą dane i gdzie są nadrzędnie utrzymywane. Produkty, ceny, stany magazynowe, pracownicy, projekty, dokumenty, statusy i rozliczenia nie mogą mieć kilku równorzędnych wersji prawdy.
Role użytkowników i uprawnienia
System powinien wiedzieć, kto może złożyć wniosek, kto może go zaakceptować, kto może go poprawić, kto widzi raport, kto może zmienić status i kto ma dostęp do danych wrażliwych.
Wyjątki
Standardowy przebieg procesu to za mało. Trzeba opisać również anulowania, odrzucenia, braki danych, błędy walidacji, korekty, zwroty, ponowne akceptacje i sytuacje nietypowe.
To właśnie wyjątki często decydują o tym, czy system będzie użyteczny.
Integracje
Jeżeli dane mają przechodzić między systemami, trzeba ustalić kierunek integracji, moment wywołania, zakres danych, odpowiedzialność za błąd i sposób potwierdzania operacji.
W przypadku REST API warto opisać przynajmniej przykładowe endpointy, strukturę danych, statusy odpowiedzi i komunikaty błędów.
Raporty
Raporty nie powinny być dodatkiem wymyślanym na końcu. Jeżeli organizacja chce kontrolować proces, trzeba wcześniej ustalić, jakie dane mają być raportowane i w którym miejscu procesu powstają.
Testy
Testy powinny wynikać z procesu. Trzeba przygotować scenariusze dla typowego przebiegu, ale także dla wyjątków: odrzucenia, błędu integracji, braku danych, niezgodnego statusu, korekty lub powrotu do wcześniejszego etapu.
Odpowiedzialność po wdrożeniu
Na końcu trzeba ustalić, kto utrzymuje konfigurację, kto zarządza słownikami, kto obsługuje błędy, kto przyjmuje zgłoszenia i kto decyduje o zmianach w procesie.
Wdrożenie nie kończy się w dniu uruchomienia systemu.
Analiza pomaga firmie zamawiającej
Dla firmy zamawiającej analiza jest sposobem na uporządkowanie własnej potrzeby przed złożeniem zamówienia.
To szczególnie ważne, gdy organizacja chce zamówić oprogramowanie, moduł systemu, integrację albo dedykowane rozszerzenie. Bez wcześniejszej analizy zamówienie często opisuje oczekiwany efekt bardzo ogólnie. Wtedy wykonawca musi sam interpretować intencje klienta, a to zwiększa ryzyko nieporozumień.
Dobrze przygotowana analiza pozwala firmie:
- lepiej określić zakres zamówienia,
- porównać oferty wykonawców,
- ograniczyć ryzyko niedoszacowania,
- uniknąć kosztownych zmian w trakcie projektu,
- lepiej kontrolować odbiór prac,
- pokazać decydentom, co dokładnie ma zostać wdrożone,
- upewnić się, że system wspiera proces, a nie tylko wygląda poprawnie na ekranie.
Dla zarządu i osób decyzyjnych analiza jest narzędziem ograniczania ryzyka. Pozwala zobaczyć, czy projekt ma jasno określony cel, zakres, odpowiedzialności i sposób weryfikacji efektu.
Analiza pomaga software house’owi
Analiza jest równie ważna po stronie wykonawcy. Software house albo integrator często dostaje od klienta ogólny opis potrzeby. Klient zna swój biznes, ale nie zawsze potrafi opisać go językiem wymagań systemowych.
W takiej sytuacji analityk może pomóc wykonawcy uporządkować temat przed rozpoczęciem prac. To zmniejsza ryzyko błędnej wyceny, ogranicza liczbę zmian zakresu i ułatwia zaplanowanie prac zespołu.
Dla software house’u dobra analiza oznacza:
- mniej domysłów,
- jaśniejsze zadania dla zespołu,
- lepsze planowanie etapów prac,
- mniejsze ryzyko konfliktu z klientem,
- konkretniejsze kryteria odbioru,
- lepsze podstawy do wyceny,
- mniej sytuacji, w których „to miało działać inaczej”.
W praktyce analiza jest pomostem między językiem biznesu a językiem wykonania.
Przykład 1: integracja sprzedaży, magazynu, WMS, ERP i e-commerce
Dobrym przykładem jest firma handlowa, która korzysta ze sklepu internetowego, sprzedaży stacjonarnej, WMS, ERP i integratora sprzedaży.
Na poziomie ogólnym potrzeba może brzmieć prosto: „chcemy zintegrować systemy”.
Ale analiza musi odpowiedzieć na dużo bardziej konkretne pytania:
- gdzie powstaje zamówienie,
- kiedy następuje rezerwacja towaru,
- który system jest źródłem stanu magazynowego,
- gdzie powstaje dokument sprzedaży,
- jak WMS przekazuje status kompletacji,
- jak obsługiwać zwroty w punkcie stacjonarnym,
- jak sprzedaż stacjonarna wpływa na dostępność produktów online,
- jak synchronizować wiele magazynów,
- co dzieje się przy braku towaru.
Bez tych ustaleń integracja może jedynie przyspieszyć bałagan. Systemy zaczną wymieniać dane, ale dalej nie będzie wiadomo, które dane są nadrzędne i kto odpowiada za poszczególne etapy procesu.
Przykład 2: procesy kadrowe, wnioski pracownicze i integracja z ERP
Drugi przykład to wdrożenie aplikacji pracowniczej obsługującej procesy kadrowe: wnioski o nadgodziny, rozliczanie wyjazdów, akceptacje przełożonych, weryfikację HR i przekazywanie danych do ERP.
Na poziomie biznesowym można powiedzieć: „potrzebujemy obsługi wniosków pracowniczych”.
Analiza musi jednak ustalić:
- kto składa wniosek,
- jakie dane są wymagane,
- kto akceptuje,
- jakie są statusy,
- jakie dane trafiają do ERP,
- jak powiązać wniosek z ewidencją czasu pracy,
- jak obsłużyć błędy walidacji,
- jakie REST API jest potrzebne,
- jak wygląda przykładowy JSON przekazywany między systemami,
- co widzi pracownik, przełożony i HR.
Dopiero wtedy wykonawca może przygotować system, który nie jest tylko formularzem, ale realnym narzędziem obsługującym proces.
Przykład 3: Apilo, Shoper, Subiekt i wFirma
Podobna zasada działa w mniejszych i średnich firmach e-commerce. Przedsiębiorca może korzystać z Shoper, Apilo, Subiekta, wFirma, kurierów, marketplace’ów i narzędzi do obsługi płatności.
Na pierwszy rzut oka chodzi o konfigurację integratora sprzedaży. W praktyce trzeba odpowiedzieć na pytania:
- które kanały sprzedaży mają być obsługiwane,
- gdzie są produkty,
- gdzie są ceny,
- skąd pochodzą stany magazynowe,
- gdzie mają powstawać faktury,
- jak obsługiwać paragony,
- jak przekazywać dane do księgowości,
- jak działają zwroty,
- jak automatyzować statusy,
- które działania mają być automatyczne, a które wymagają kontroli użytkownika.
Nawet przy popularnych narzędziach problemem rzadko jest samo kliknięcie opcji w panelu. Problemem jest wcześniejsze ustalenie, jak firma chce pracować.
Co powinno być efektem analizy?
Efektem analizy nie powinien być dokument napisany tylko po to, żeby „była dokumentacja”. Dobra analiza powinna być użyteczna dla wszystkich stron projektu.
Dla biznesu powinna jasno pokazywać, jak będzie działał proces. Dla wykonawcy powinna opisywać wymagania i integracje. Dla decydentów powinna ograniczać ryzyko i pomagać kontrolować zakres. Dla użytkowników końcowych powinna prowadzić do systemu, który jest zrozumiały i wspiera codzienną pracę.
W praktyce po analizie mogą powstać:
- opis obecnego procesu,
- opis docelowego procesu,
- diagramy przepływu,
- wymagania funkcjonalne,
- wymagania niefunkcjonalne,
- lista ról i uprawnień,
- statusy obiektów,
- reguły walidacji,
- opis integracji,
- przykładowe endpointy API,
- przykładowe struktury JSON,
- scenariusze testowe,
- kryteria odbioru,
- backlog zadań dla zespołu wykonawczego,
- rekomendacje wdrożeniowe.
To są materiały, które realnie pomagają prowadzić projekt.
Analiza nie spowalnia projektu. Analiza ogranicza straty
Częsty argument przeciwko analizie brzmi: „nie mamy czasu, trzeba wdrażać”.
W praktyce brak analizy nie usuwa pracy analitycznej. On tylko przesuwa ją na później — na etap konfiguracji, programowania, testów albo produkcji.
Wtedy analiza odbywa się w najdroższym możliwym momencie: gdy zespół już pracuje, terminy biegną, budżet jest wykorzystany, a każda zmiana powoduje napięcia.
Dobrze przeprowadzona analiza na początku projektu może wydawać się dodatkowym kosztem. W rzeczywistości często ogranicza koszty późniejszych zmian, poprawek, sporów i przestojów.
Wiele problemów wdrożeniowych wynika nie z tego, że system był niemożliwy do zbudowania, ale z tego, że wcześniej nie ustalono, co dokładnie ma zostać zbudowane.
Rola LISNET
W LISNET wspieram firmy i zespoły IT tam, gdzie trzeba uporządkować wymagania, procesy i przepływy danych przed wdrożeniem.
Mogę pełnić różne role w zależności od potrzeb projektu.
Dla firmy zamawiającej mogę pomóc opisać potrzebę biznesową przed rozmową z wykonawcą. Dzięki temu łatwiej przygotować zapytanie, porównać oferty i kontrolować zakres prac.
Dla software house’u lub integratora mogę wesprzeć etap analizy przedwdrożeniowej: rozmawiać z klientem, porządkować wymagania, tworzyć diagramy, opisywać procesy, przygotowywać przykłady API i zamieniać ustalenia biznesowe na zadania możliwe do wykonania przez zespół.
Dla projektu wdrożeniowego mogę pomóc przeprowadzić klienta od ogólnej potrzeby do konkretnego modelu procesu, integracji i wymagań.
Wspólny cel jest zawsze ten sam: zmniejszyć liczbę domysłów i zwiększyć szansę, że system będzie odpowiadał na realną potrzebę organizacji.
Kiedy warto zaangażować analityka?
Analityka warto zaangażować szczególnie wtedy, gdy:
- projekt dotyczy kilku działów,
- w procesie uczestniczy więcej niż jeden system,
- potrzebna jest integracja z ERP, WMS, CRM, sklepem internetowym albo systemem księgowym,
- biznes wie, czego potrzebuje, ale nie ma tego opisanego,
- wykonawca potrzebuje uporządkowanych wymagań,
- pojawiają się różne interpretacje zakresu,
- istnieje ryzyko konfliktu między klientem a wykonawcą,
- projekt wymaga REST API lub wymiany danych między systemami,
- potrzebne są diagramy, statusy, reguły i scenariusze testowe,
- decydenci chcą ograniczyć ryzyko kosztów i opóźnień.
Im wcześniej taka praca zostanie wykonana, tym większa szansa, że wdrożenie będzie przebiegało spokojniej.
Podsumowanie
Wdrożenie IT powinno zaczynać się od analizy procesu, a nie od konfiguracji systemu. To szczególnie ważne tam, gdzie projekt dotyczy wielu użytkowników, kilku systemów, integracji, raportowania, rozliczeń albo niestandardowych procesów biznesowych.
Analiza pozwala ustalić cel, opisać obecny i docelowy proces, określić role, dane, wyjątki, integracje i kryteria odbioru. Dzięki temu firma wie, co zamawia, a wykonawca wie, co ma zbudować.
System może być bardzo dobrym narzędziem, ale tylko wtedy, gdy wspiera dobrze opisany proces. Jeżeli procesu nie opisano, wdrożenie zaczyna się od domysłów. A domysły w projektach IT bardzo często kosztują więcej niż analiza wykonana na początku.
