Większość firm nie ma aktualnej mapy systemów, czyli opisu tego, z jakich narzędzi korzysta, jak są ze sobą połączone i które procesy przez nie przechodzą. Dlatego każdy projekt technologiczny – wdrożenie e-commerce, wymiana ERP, nowa integracja, automatyzacja obsługi zamówień – zaczyna się od audytu wycinka architektury. Firma z góry wie, że ten koszt się pojawi i że decyzja o samym projekcie przesunie się o czas takiej analizy. Drugi skutek jest mniej widoczny: audyt robiony pod jeden projekt pokazuje tylko ten jeden wycinek, więc powiązania nowego systemu z resztą organizacji wychodzą dopiero w trakcie wdrożenia. Najbardziej jaskrawym objawem tego samego braku jest sytuacja, w której firma odkrywa u siebie narzędzie, o którego istnieniu nie wiedziała. Ten artykuł pokazuje, ile kosztuje brak mapy systemów, co powinien obejmować audyt systemów, którego nie trzeba powtarzać przy każdym projekcie, i jak utrzymać taką mapę aktualną.
Dlaczego każdy projekt technologiczny zaczyna się od audytu?
Kiedy zaczynamy z klientem rozmowę o automatyzacji albo o nowym systemie sprzedaży B2B, pierwszym etapem nie jest wdrożenie, tylko discovery: warsztat, na którym nazywamy, jak jest dzisiaj, a potem analiza przedwdrożeniowa, w której planujemy, jak ma być. Dopiero po tym etapie wiemy, co dokładnie będziemy robić, i dopiero wtedy ma sens rozmowa o zakresie i terminie. Robimy tak dlatego, że w firmie zwykle nie ma gotowego opisu stanu obecnego – nikt nie ma pod ręką mapy systemów, z której dałoby się odczytać, co jest wdrożone, co z czym rozmawia i gdzie fizycznie leżą dane.
Widać to już na pierwszym spotkaniu. Zanim cokolwiek policzymy, pytamy, czy firma ma wdrożony PIM, czy informacje o produktach centralizuje w ERP, skąd biorą się ceny i gdzie powstaje zamówienie. To nie są pytania o preferencje, tylko o architekturę – bez odpowiedzi na nie każda wycena jest zgadywanką. W większości rozmów odpowiedzi trzeba dopiero zebrać, bo część wiedzy jest u informatyka, część u osoby od logistyki, a część w głowie poprzedniego wykonawcy.
Konsekwencja jest prosta i powtarza się w każdym projekcie: zanim firma zacznie automatyzować cokolwiek, musi najpierw zaudytować ten fragment technologii, którego automatyzacja dotyczy. Ten audyt kosztuje czas i pieniądze, a projekt, o który naprawdę chodzi, rusza dopiero po nim.
Ile kosztuje wdrożenie, gdy brakuje mapy systemów?
Koszt jest rozłożony na kilka pozycji, z których większość nie trafia do żadnego zestawienia.
Czas przed startem projektu. Analiza przedwdrożeniowa jest pierwszym etapem każdego większego wdrożenia, a jej zakres rośnie wtedy, kiedy obraz architektury jest niepełny. W jednym z projektów ofertowych zwiększyliśmy zakres tej analizy już po warsztatach, bo wiele potrzeb klienta zostało zasygnalizowanych, ale nie pogłębionych – dodatkowe godziny analityczne były tańsze niż wejście we wdrożenie z niedomkniętymi wymaganiami. Część tej pracy firma może wykonać u siebie wcześniej; opisaliśmy to w briefie, który przygotowuje do analizy przedwdrożeniowej.
Analiza każdej integracji z osobna. W innym projekcie na samą precyzyjną analizę jednej integracji zaplanowaliśmy dwa do trzech dni roboczych: skąd biorą się dane o logistyce, skąd dane o zamówieniach, gdzie przechowywane są ceny i jak są skorelowane z konkretnym klientem. Jedna integracja, kilka dni pracy, zanim powstanie pierwsza linijka kodu. Przy trzech albo czterech integracjach to już jest osobny tydzień w harmonogramie.
Bufor ryzyka w wycenie. Kiedy nie wiadomo z góry, co jest po drugiej stronie integracji, do wyceny trzeba doliczyć bufor na niespodzianki. Firma płaci wtedy nie za pracę, tylko za niepewność – a jedynym sposobem, żeby ten bufor zmniejszyć, jest wcześniejsze opisanie architektury. Ten sam mechanizm zaniża dokładność rachunku całkowitego kosztu posiadania systemu, bo część pozycji po prostu nie jest jeszcze znana.
Odłożona decyzja o automatyzacji. To koszt, który najtrudniej zobaczyć w budżecie. Firma, która wie, że każdy pomysł na automatyzację ofertowania albo obsługi zapytań zacznie się od kilkutygodniowego rozpoznania, rzadziej te pomysły w ogóle zgłasza. Temat wraca za kwartał, potem za rok, a w międzyczasie proces dalej jest obsługiwany ręcznie.
Płacenie za funkcje, z których nikt nie korzysta. U jednego z klientów przenieśliśmy system z wersji Enterprise na wersję open source, bo firma realnie korzystała tylko z części funkcji, za które płaciła w licencji. Brakujące elementy dopisaliśmy w sposób dedykowany. Ta decyzja była możliwa dopiero wtedy, kiedy ktoś zestawił zakres licencji z tym, co jest faktycznie używane – czyli zrobił fragment tej mapy.
Czego nie widać przy wdrożeniu: powiązania nowego systemu z resztą firmy
Audyt robiony pod jeden projekt ma jedną wadę wbudowaną w założenie: pokazuje ten wycinek, o który pytamy. Jeśli wdrażamy nowy system do zarządzania cenami, opiszemy ceny, cenniki i to, co z nimi bezpośrednio sąsiaduje. Powiązania, których nikt nie zgłosił, zostają poza zakresem.
W praktyce nowy system w firmie handlowej dotyka zwykle znacznie szerszego zestawu:
- ERP – źródło stanów, cen i dokumentów sprzedażowych,
- WMS lub system magazynowy, często z własną logiką rezerwacji,
- PIM i DAM – dane produktowe oraz zdjęcia i materiały,
- OMS lub integrator zamówień z marketplace’ów,
- system do zarządzania cenami i rabatami, jeśli działa osobno od ERP,
- narzędzia marketing automation i systemy mailingowe,
- analityka i systemy raportowe,
- obieg dokumentów oraz systemy księgowe,
- importery i skrypty uruchomione kiedyś pod jednego dostawcę,
- konta i integracje w kanałach zewnętrznych, w tym w strukturach wielosklepowych i na marketplace’ach.
Każda z tych pozycji może mieć własną integrację, własny harmonogram synchronizacji i własne miejsce, w którym dana wartość jest „prawdziwa”. Kiedy nowe wdrożenie zmienia jedną z nich, konsekwencje dla pozostałych wychodzą w trakcie prac, a nie na etapie planowania. Harmonogram przesuwa się wtedy o czas, którego nikt nie zaplanował, bo zakres rozszerza się o coś, o czym na starcie nie było wiadomo.
Skrajny przypadek: narzędzie, o którym nikt w firmie nie wiedział
W jednym z projektów, przy których pracowaliśmy, podczas onboardingu okazało się, że w systemie klienta od dawna działa importer danych produktowych, o którym zespół nie miał pojęcia. Uruchomił go ktoś po stronie wcześniejszego wykonawcy i nie przekazał tej informacji dalej. Część zespołu przyznała, że nigdy wcześniej tego narzędzia nie widziała, a osoby odpowiedzialne za ten obszar opisały swoją wiedzę o własnej infrastrukturze jako zaczynanie od zera, mimo że pracowały w firmie od lat.
Taka sytuacja zdarza się rzadziej niż zwykły audyt przed projektem i sama w sobie nie jest zjawiskiem rynkowym. Jest natomiast najostrzejszym dowodem na to samo: skoro w firmie może przez lata działać narzędzie, o którym nikt nie wie, to nie ma w niej punktu odniesienia do oceny własnej architektury. A jeśli nie ma punktu odniesienia, to nie ma też jak oszacować, ile kosztują pozostałe, mniej widoczne rzeczy – dublujące się funkcje, integracje utrzymywane bez potrzeby, procesy obsługiwane ręcznie obok narzędzia, które umie je wykonać.
Mechanizm, który do tego prowadzi, jest zawsze podobny. Ktoś rozwiązał konkretny problem, uruchomił narzędzie i poszedł dalej. Wiedza o tym, że narzędzie istnieje i jak z niego korzystać, została w jego głowie, a nie w dokumentacji. Kiedy ta osoba zmienia projekt, dział albo pracodawcę, wiedza znika razem z nią, a firma zostaje z systemem, który dalej działa.
Jak wygląda audyt systemów, którego nie trzeba powtarzać?
Przy audycie ekosystemu e-commerce dla jednego z producentów dermokosmetyków zaczęliśmy od sprawdzenia, z jakich narzędzi firma już korzysta i jak są ze sobą połączone, zamiast od pytania, czego jej brakuje. Zweryfikowaliśmy istniejącą architekturę, zwizualizowaliśmy połączenia między systemami, opisaliśmy w schematach BPMN, jak faktycznie przebiegają procesy – od zamówienia, przez ERP, po wysyłkę – i udokumentowaliśmy, do czego każdy z systemów jest realnie wykorzystywany.
Efektem takiego audytu nie jest lista rekomendacji zakupowych. Efektem jest dokumentacja tego, co firma już ma. Dopiero z nią da się odróżnić lukę technologiczną od luki w wiedzy o własnej infrastrukturze, a to dwa różne problemy z różnymi rozwiązaniami.
Kompletna mapa systemów powinna zawierać:
- listę wszystkich systemów i narzędzi, łącznie z tymi uruchomionymi przez poprzednich wykonawców,
- właściciela biznesowego i osobę techniczną odpowiedzialną za każdy z nich,
- wersję i model licencyjny każdego systemu wraz z zakresem, z którego firma faktycznie korzysta,
- listę integracji: co z czym się łączy, w którą stronę i jak często,
- wskazanie, gdzie powstaje i gdzie jest „prawdziwa” każda kluczowa dana – produkt, cena, stan magazynowy, zamówienie, klient,
- schematy procesów przechodzących przez te systemy, w notacji czytelnej także dla osób nietechnicznych,
- informację, które funkcje są dublowane przez więcej niż jedno narzędzie,
- listę rzeczy obsługiwanych ręcznie mimo istnienia narzędzia, które umie to zrobić,
- znane ograniczenia i miejsca, w których architektura wymusza obejścia,
- datę ostatniej weryfikacji każdego wpisu.
Ta mapa ma wartość poza samym audytem. Bez niej każdy kolejny projekt – wymiana systemu na inną platformę, połączenie funkcji dwóch narzędzi w jedno, optymalizacja w obszarze magazynu, marketingu czy obsługi zamówień – musi zacząć się od fragmentarycznego rozpoznania tego jednego obszaru. Kiedy mapa jest gotowa i aktualizowana, do takich projektów można przystąpić od razu, a wycena jest dokładniejsza, bo od początku wiadomo, które połączenia trzeba będzie przebudować.
Projekt bez mapy systemów a projekt z mapą
| Etap projektu | Bez mapy systemów | Z aktualną mapą systemów |
|---|---|---|
| Start rozmowy o zakresie | Najpierw rozpoznanie, skąd biorą się dane i co jest wdrożone | Rozmowa zaczyna się od decyzji, nie od zbierania faktów |
| Analiza przedwdrożeniowa | Pełna, obejmuje też opis stanu obecnego | Skrócona, dotyczy wyłącznie planowanej zmiany |
| Zakres | Rośnie w trakcie, kiedy wychodzą nieznane powiązania | Ustalony na starcie, zmiany wynikają z decyzji, nie z odkryć |
| Wycena | Z buforem na niepewność integracji | Dokładniejsza, bo znane są punkty styku |
| Harmonogram | Przesuwa się o czas rozpoznania i o niespodzianki | Liczony od pierwszego dnia prac wdrożeniowych |
| Kolejny projekt | Rozpoznanie od nowa, na innym wycinku | Aktualizacja mapy o to, co się zmieniło |
| Decyzja o automatyzacji | Odkładana, bo zaczyna się od kosztu rozpoznania | Podejmowana na podstawie tego, co już opisane |
Czego audyt systemów nie rozwiązuje?
Audyt opisuje stan faktyczny i na tym się kończy. Warto wiedzieć, czego po nim nie należy oczekiwać.
Nie zastępuje decyzji biznesowych. Mapa pokaże, że dwa narzędzia dublują funkcję, ale tego, z którego zrezygnować, nie rozstrzygniemy sami – to zależy od tego, jak firma sprzedaje i kto z czego korzysta na co dzień. Naszą rolą jest pokazać konsekwencje każdego wariantu i wypracować rozstrzygnięcie razem z zespołem klienta.
Nie zastępuje analizy przedwdrożeniowej pod konkretny projekt. Skraca ją, bo część pracy jest już wykonana, ale planowanie zmiany to osobny etap.
Nie utrzymuje się sam. Mapa, której nikt nie aktualizuje, po roku opisuje firmę, której już nie ma – i wtedy wracamy do punktu wyjścia.
Nie odpowiada na pytanie, czy dane narzędzie jest dobre. Pokazuje, czy jest używane i z czym jest powiązane. Ocena, czy warto je wymienić, to już osobna rozmowa, zwykle przy okazji konkretnego projektu – tak jak przy wyborze systemu PIM, gdzie o wyniku decyduje znacznie więcej niż sama lista funkcji.
Co zrobić, żeby mapa nie zdezaktualizowała się po roku?
Jednorazowy audyt rozwiązuje problem na chwilę. Żeby za rok nowa osoba w zespole nie zaczynała odkrywania infrastruktury od początku, potrzebny jest prosty proces: ktoś w firmie odpowiada za to, żeby przy każdej zmianie w architekturze – nowym narzędziu, nowej integracji, wymianie systemu, zmianie dostawcy – mapa i jej dokumentacja zostały zaktualizowane, a informacja o zmianie trafiła do zespołu.
W praktyce sprawdza się powiązanie tej aktualizacji z odbiorem prac: zmiana jest zamknięta dopiero wtedy, kiedy opis w mapie odpowiada temu, co zostało wdrożone. Wtedy aktualizacja przestaje być osobnym zadaniem, na które nigdy nie ma czasu.
Najczęstsze pytania
Czym różni się audyt systemów od analizy przedwdrożeniowej? Audyt systemów opisuje stan obecny całej architektury: co jest wdrożone, jak jest połączone i do czego jest używane. Analiza przedwdrożeniowa planuje konkretną zmianę i powstaje pod jeden projekt. Audyt robi się raz i aktualizuje, analizę robi się przed każdym wdrożeniem – z gotową mapą jest ona krótsza, bo nie zaczyna się od zbierania faktów.
Ile trwa audyt systemów? Zależy od liczby systemów i integracji. Dla skali samego rozpoznania pomocny jest ten punkt odniesienia: precyzyjna analiza pojedynczej integracji to u nas zwykle dwa do trzech dni roboczych. Firma z kilkoma integracjami i jednym ERP potrzebuje innego nakładu niż firma sprzedająca w kilku kanałach naraz.
Czy audyt ma sens, jeśli wdrożenie planujemy dopiero za rok? Tak, i to jest najlepszy moment. Audyt zrobiony wcześniej nie wchodzi w harmonogram wdrożenia, a jego efekt skraca późniejszą analizę przedwdrożeniową i pozwala urealnić budżet, zanim zostanie zatwierdzony.
Kto po stronie firmy musi być zaangażowany? Zwykle osoba odpowiedzialna za IT albo za e-commerce, ktoś z logistyki i magazynu, ktoś od obsługi zamówień oraz osoba znająca proces cenowy. Część wiedzy jest rozproszona i zebranie jej w jednym miejscu jest właściwą treścią audytu.
Czy audyt kończy się listą narzędzi do kupienia? Nie. Kończy się dokumentacją tego, co firma już ma i jak to ze sobą współpracuje. Rekomendacje zakupowe, jeśli w ogóle się pojawiają, wynikają z tej dokumentacji i są osobną decyzją.
Mamy dokumentację od poprzedniego wykonawcy – czy to wystarczy? Bywa dobrym punktem startu, ale zwykle opisuje to, co dostawca wdrożył, a nie to, z czego firma korzysta dzisiaj. Warto ją zweryfikować wobec stanu faktycznego, zwłaszcza w częściach dotyczących integracji i danych.
Co ustalić przed kolejnym wdrożeniem?
Jeśli kolejny projekt technologiczny i tak zacznie się od rozpoznania architektury, warto zdecydować świadomie, czy to rozpoznanie ma być fragmentaryczne i zrobione po raz kolejny, czy całościowe i zrobione raz. Poniższa lista to minimum, które warto mieć spisane, zanim usiądziecie do rozmowy o zakresie.
- Czy macie spisane wszystkie systemy i narzędzia, z których korzysta firma – łącznie z tymi uruchomionymi przez poprzedniego dostawcę?
- Czy wiecie, jak te systemy są ze sobą połączone i które procesy przez nie przechodzą?
- Czy dla każdej kluczowej danej – produkt, cena, stan magazynowy, zamówienie – wiadomo, w którym systemie powstaje?
- Czy wiecie, z jakiego zakresu posiadanych licencji faktycznie korzystacie?
- Czy ta wiedza jest zapisana w miejscu dostępnym dla całego zespołu, a nie tylko w głowie jednej osoby?
- Czy ktoś odpowiada za aktualizowanie tej dokumentacji, kiedy coś się zmienia?
Jeśli przy większości punktów odpowiedź brzmi „częściowo”, kolejny projekt zacznie się tak samo jak poprzedni. Opisujemy architekturę klienta na starcie większych projektów doradczych i robimy to również jako osobne zlecenie – zakres naszej pracy opisaliśmy na stronie usług, a przykłady zrealizowanych projektów zebraliśmy w case studies. Jeśli chcecie po prostu sprawdzić, od czego zacząć u siebie, umówcie konsultację – wystarczy rozmowa o tym, co już macie.
