Kiedy ostatnio czytałem o tym, jak Lidl spalił pół miliarda euro na nieudanym wdrożeniu SAP-a, pomyślałem o własnych doświadczeniach z projektami IT. Zarządzając firmami w tak różnych branżach jak Digital Development, Juristo, czy Twoja Strefa Szkód i Zlikwidowani, widziałem już niejedną historię o "cudownych systemach", które miały rozwiązać wszystkie problemy.

Spoiler: rzadko tak się dzieje.

Z mojej perspektywy, problem nie leży w technologii – leży w naszym podejściu do niej. Tak naprawdę, większość firm rzuca się na wdrożenia IT jak na ostatnią deskę ratunku, nie robiąc jednej kluczowej rzeczy: nie rozumiejąc najpierw samych siebie.

Dlaczego mapowanie procesów to nie "nudna formalność"?

W Digital Development, gdy klient dzwoni z prośbą o automatyzację, pierwszą rzeczą, którą mówię, nie jest "jakie narzędzie chcecie?", ale "opowiedzcie mi, jak naprawdę działacie".

I wiesz co? W 90% przypadków okazuje się, że to, co myślą że robią, różni się od tego, co faktycznie robią.

Mapowanie procesów to w gruncie rzeczy szczera rozmowa z samym sobą i swoją firmą. To odpowiedź na pytania:

• Kto za co odpowiada?
• Gdzie są wąskie gardła?
• Co robimy z przyzwyczajenia, a co dlatego, że to ma sens?
• Które z naszych procesów to nasza przewaga, a które to balast?

Na dany moment, po latach pracy z różnymi firmami, mogę powiedzieć jedno: firmy, które przeskakują ten etap, płacą za to później – czasem bardzo drogo.

Moja metoda: 4 kroki do zrozumienia siebie

Przez lata wypracowałem proces, który sprawdza się w różnych branżach. W tym zakresie oferujemy w Digital Development różne podejścia, ale fundamenty pozostają te same.

Krok 1: "As-is" – jak naprawdę działamy

Pierwszy etap to brutalna szczerość. Siadamy z kluczowymi ludźmi z firmy i rysujemy na tablicy (dosłownie), jak przebiegają najważniejsze procesy. Nie to, jak powinny przebiegać – jak przebiegają.

Pytania, które zadaję:

• Kto dostaje informację jako pierwszy?
• Ile razy ten sam dokument jest przepisywany?
• Gdzie ludzie "kombinują", bo system ich zmusza?
• Co robicie, gdy "standard" nie działa?

Pamiętam case z jedną z kancelarii prawnych, gdzie okazało się, że jeden dokument był przygotowywany przez 4 różne osoby, a każda dodawała swoje "poprawki" bez konsultacji z poprzednimi. W kontekście efektywności to był prawdziwy chaos.

Krok 2: Identyfikacja przewag i problemów

Drugi etap to rozróżnienie, co w firmie jest:

• Przewagą konkurencyjną (tego bronić za wszelką cenę)
• Standardem branżowym (można dostosować do narzędzia)
• Problemem do rozwiązania (zmienić niezależnie od systemu)

W kontekście moich firm, w Digital Development przewagą jest szybkość wdrożeń dzięki technologiom low-code. W firmach odszkodowawczych – specjalistyczna wiedza prawna i network rzeczoznawców. Standardem są procesy księgowe czy komunikacja z klientami.

Krok 3: "To-be" – jak chcemy działać

Dopiero teraz projektujemy procesy docelowe. I tu jest kluczowe pytanie: "Czy ten proces będzie lepszy po automatyzacji, czy lepszy po usprawieniu?"

Często okazuje się, że problem nie leży w braku systemu, tylko w złej organizacji pracy. Automatyzacja chaosu to przepis na cyfrowy chaos.

Krok 4: Wymagania dla systemu

Mając jasny obraz procesów, można określić konkretne wymagania. Pod kątem priorytetyzacji używam metodyki MoSCoW:

• Must-have: bez tego system jest bezużyteczny
• Should-have: ważne, ale da się bez tego żyć
• Could-have: miłe dodatki
• Won't-have: tego nie potrzebujemy (najważniejsza kategoria!)

Przypadek Lidla – lekcja z pół miliarda euro

Historia Lidla to podręcznikowy przykład tego, co się dzieje, gdy firma ma jasną wizję swoich procesów, ale nie ma jasnej wizji, które z nich są warte obrony za każdą cenę.

Lidl operował na cenach zakupu, SAP na cenach sprzedaży. Fundamentalna różnica. Problem w tym, że przez 7 lat próbowali "naprawić" SAP-a zamiast zadać sobie pytanie: "Czy nasz sposób kalkulacji rzeczywiście daje nam przewagę, czy to po prostu przyzwyczajenie?"

Z mojej perspektywy, błąd Lidla nie leżał w tym, że bronili swoich procesów. Błąd leżał w tym, że nie przeanalizowali wcześniej, których procesów bronić, a które można zmienić.

Każda firma ma swoje "święte krowy" – sposoby działania, z którymi się nie dyskutuje. Problem w tym, że połowa z nich to nie przewagi konkurencyjne, tylko stare przyzwyczajenia.

Dwa podejścia do wdrożeń: narzędzie czy proces pierwszy?

W ciągu lat widziałem dwa skrajnie różne podejścia do wdrożeń IT:

Podejście "tool-driven" – recepta na problemy

Firma wybiera system (często dlatego, że "wszyscy go mają" lub "słyszałem, że jest dobry"), a potem próbuje wcisnąć swoje procesy w szablon narzucony przez technologię.

Skutki tego podejścia:

• Projekty przekraczają budżet o 50-200%
• Pracownicy sabotują system, bo "utrudnia im pracę"
• Firma traci to, co ją wyróżniało
• W skrajnych przypadkach – całkowite fiasko jak u Lidla

Podejście "process-driven" – klucz do sukcesu

Najpierw mapujemy i optymalizujemy procesy, potem szukamy narzędzia, które je najlepiej wspiera lub budujemy dedykowane rozwiązanie.

Tak naprawdę, chodzi o świadomy wybór: gdzie dostosujemy się do standardu systemu (bo tak będzie taniej i szybciej), a gdzie system musi się dostosować do nas (bo to nasza przewaga).

Najczęstsze błędy wdrożeniowe

Po latach doświadczeń z wdrożeniami, widzę kilka powtarzających się błędów:

Błąd #1: "Nowy system rozwiąże wszystkie problemy"

Nie rozwiąże. System może przyspieszyć dobre procesy, ale nie naprawi złych procesów.

Błąd #2: "Dostosujemy się do systemu, bo tak będzie taniej"

Czasem tak, czasem nie. Jeśli tracisz przewagę konkurencyjną, "tańszy" system może kosztować Cię więcej w długim okresie.

Błąd #3: "Wdrożymy wszystko naraz"

Recepta na chaos. Lepiej wdrażać etapami – tak można kontrolować ryzyko i uczyć się na błędach. W Digital Development pracujemy w 2-tygodniowych sprintach właśnie z tego powodu.

Błąd #4: "Nie mamy czasu na analizy"

Pamiętam klienta, który chciał "zaoszczędzić" na analizie. Po roku wrócił z prośbą o pomoc w naprawieniu systemu, który "nie działał tak, jak powinien". Koszt naprawy? Trzykrotność pierwotnego budżetu analizy.

Bez problemu można wydać więcej na naprawianie błędów niż na ich unikanie.

Moje doświadczenia z różnych branż

Zarządzając firmami w różnych sektorach, widzę, jak bardzo kontekst ma znaczenie:

W Digital Development – szybkość i elastyczność to wszystko. Używamy głównie rozwiązań low-code (AppSheet, FlutterFlow, Power Apps, Bubble), które pozwalają na błyskawiczne dostosowania.

W kancelarii prawnej – standardy prawne nie podlegają negocjacjom, ale sposób obsługi klienta już tak. Automatyzujemy rutynę, pozostawiając prawników do tego, co robią najlepiej.

W firmach odszkodowawczych – każda sprawa jest inna, ale proces jej obsługi może być standardowy. Tu kluczowy jest system CRM dopasowany do specyfiki branży.

Kluczowa lekcja z tego wszystkiego: nie ma uniwersalnego rozwiązania, ale jest uniwersalny proces jego znajdowania.

Kiedy warto inwestować w mapowanie procesów?

Nie zawsze. Jeśli prowadzisz jednoosobową działalność i wdrażasz prosty system księgowy – analiza może być przesadą.

Mapowanie się opłaca, gdy:

• Automatyzujesz procesy za ponad 50 tysięcy złotych
• System wpłynie na pracę więcej niż 5 osób
• Automatyzujesz procesy kluczowe dla biznesu
• Masz unikalne procesy, które mogą nie pasować do standardów
• Wcześniej mieliście problemy z wdrożeniami IT

Pierwsze kroki dla Twojej firmy

Jeśli doszedłeś do końca tego artykułu, prawdopodobnie myślisz o jakimś wdrożeniu w swojej firmie. Oto pierwsze kroki:

1. Zadaj sobie pytanie: "Czy naprawdę rozumiem, jak działają kluczowe procesy w mojej firmie?"
2. Znajdź godzinę na naszkicowanie jednego procesu od początku do końca
3. Porozmawiaj z pracownikami – jak oni widzą te procesy?
4. Zidentyfikuj największy problem – gdzie firma się "zatyka"?

Dopiero mając odpowiedzi na te pytania, warto myśleć o systemach IT.

Podsumowanie: proces przed technologią

Historia Lidla to przestroga, ale też inspiracja. Pokazuje, że nawet ogromne budżety nie gwarantują sukcesu bez fundamentu – rozumienia własnych procesów.

Kluczowe wnioski z mojego doświadczenia:

• Mapowanie procesów to ubezpieczenie od kosztownych błędów wdrożeniowych
• Nie wszystkie procesy są jednakowo ważne – naucz się rozróżniać przewagi od przyzwyczajeń
• Lepiej wydać mniej na analizę na początku niż więcej na ratowanie projektu później
• Technologia ma wspierać biznes, nie go zastępować
• Pilotaż i sprinty to klucz – testuj na małą skalę, wdrażaj iteracyjnie

W erze cyfryzacji wygrywają ci, którzy pamiętają, że technologia to narzędzie, nie cel sam w sobie. Najinteligenniejszy system świata nie zastąpi przemyślanych procesów i ludzi, którzy je wykonują.

A jakie są Twoje doświadczenia z wdrożeniami IT? Spotkałeś się z podobnymi wyzwaniami w swojej firmie? Chętnie wymienię się doświadczeniami – może Twoja historia pomoże innym uniknąć kosztownych błędów podczas niezobowiązującego spotkania biznesowego.

‍