Transformacja cyfrowa firm produkcyjnych, handlowych czy usługowych rzadko upada z powodu samej technologii. Narzędzia automatyzujące dziś powstają szybko, tanio i działają poprawnie już od pierwszego wdrożenia — to nie jest wąskie gardło. Wąskim gardłem jest moment, w którym działające narzędzie trafia do organizacji zbudowanej wokół zupełnie innych nawyków, ról i struktur odpowiedzialności. Origami Effect obserwowało ten wzorzec wielokrotnie — w rozmowach z dwudziestoma przedstawicielami zarządów oraz w kilkunastu wdrożeniach automatyzacji w firmach z różnych branż: od gospodarstw rolnych, przez firmy importowe, po instytucje finansowe. Za każdym razem powtarzał się ten sam mechanizm: technologia działała bez zarzutu, a mimo to proces utykał — na poziomie decyzji zarządu, oporu działu, który bronił swojej roli, albo cichego porzucenia inicjatywy, zanim ktokolwiek wprost powiedział "nie". Poniższe przykłady pochodzą bezpośrednio z tych doświadczeń. Nie są ilustracją tezy postawionej z góry — to one tę tezę uformowały: skuteczna transformacja cyfrowa wymaga czegoś więcej niż gotowego narzędzia. Wymaga kogoś, kto przeprowadzi organizację przez etap, w którym technologia przestaje być obietnicą, a staje się zmianą tego, jak firma faktycznie pracuje.
Rynek nie myśli jeszcze kategorią "zbuduj własne", tylko "kup gotowe"
Rozmowy z 20 przedstawicielami zarządów potwierdziły przypuszczenie postawione na wstępie tego dokumentu: żaden z rozmówców nigdy wcześniej nie rozważał budowania własnego, dedykowanego rozwiązania wewnątrz swojej firmy — wszyscy byli przyzwyczajeni wyłącznie do kupowania gotowych produktów z pudełka. Prezentowane rozwiązania były odbierane jako coś do przyjęcia lub odrzucenia w całości ("czy to jest dobre rozwiązanie?"), a nie jako punkt wyjścia, który można ukształtować pod własny proces ("jak dostosujemy to do tego, jak faktycznie pracujemy?").
To dokładnie ta sama bariera mentalna, która stoi za tezą z początku dokumentu: rynek dopiero uczy się, że można kupować nie licencję na gotowy produkt, lecz proces budowania własnego aktywa — albo, w wersji pośredniej, licencję na rozwiązanie odpowiadające własnym potrzebom, zarówno obecnym, jak i przyszłym: takie, które można dostosowywać i które ewoluuje razem z firmą, wraz z jej zmieniającymi się wyzwaniami, zamiast zamrażać ją w kształcie z dnia zakupu. Dopóki zarząd myśli kategorią oceny gotowego produktu, nie dostrzega, że stoi przed nim coś, co można ukształtować pod jego własne, zmieniające się w czasie wymagania. X
Gdy zarząd czeka, aż inicjatywę przejmą pracownicy
Naturalną konsekwencją tego myślenia jest przerzucenie ciężaru decyzji niżej — zarząd zakłada, że jeśli rozwiązanie jest wartościowe, to pracownicy sami wykażą się inicjatywą, przetestują je i zgłoszą uwagi. W praktyce dzieje się odwrotnie. Wdrożenie webowej wersji systemu analogicznego do Quantis, obejmującej jednocześnie dane analityczne, marketingowe i zamówienia, utknęło na kilka miesięcy, ponieważ nikt po stronie klienta nie chciał wypowiedzieć się, czy system spełnia ich wyobrażenia i wymagania — łatwiej nie zabierać głosu, niż wydać ocenę, za którą później trzeba by odpowiadać. Ciekawy kontrast pojawił się przy module alertów informujących o problemach w bieżącej sytuacji firmy: wersja webowa spotkała się z dużym uznaniem, ale analogiczny system wysyłający te same alerty jako komunikaty na Discordzie nie został nawet sprawdzony — nie dlatego, że był gorszy, lecz dlatego, że forma nie budziła wystarczającego zaufania, by ktokolwiek poświęcił mu uwagę.
Automatyzacja jako zagrożenie dla roli, nie tylko jako narzędzie
W jednej z firm importowych pracownicy działu logistyki ręcznie przepisywali dane z dokumentów SAD do systemu ERP. Zlecenie na automatyzację tego procesu powstało w reakcji na konkretny problem: podczas ręcznego przepisywania pojawiły się błędne dane, co pokazuje, jak automatyzacja tego typu procesów może być rozwiązaniem nie tylko na oszczędność czasu, ale i na ryzyko błędu ludzkiego, szczególnie przy wdrażaniu nowych pracowników do procesu.
Zewnętrzny partner wycenił pełną automatyzację na kwotę kilkukrotnie wyższą niż ostatecznie zaproponowane rozwiązanie. Origami Effect przygotowało system generujący gotowy Excel z dokumentu PDF w mniej niż minutę — i tę część dział logistyki przyjął i wdrożył. Zaproponowano jednak krok dalej: żeby dane trafiały automatycznie do bufora systemu ERP, wymagając już tylko krótkiej weryfikacji i zatwierdzenia, zamiast ręcznego wklejania gotowego Excela do systemu. Właśnie na tym etapie temat ucichł.
To jest najważniejszy wniosek z tego przykładu: dział logistyki chętnie przyjął automatyzację tam, gdzie oszczędzała czas, nie naruszając przy tym jego roli — ale zatrzymał się dokładnie w momencie, w którym kolejny, technicznie prosty krok oznaczałby realną zmianę tego, czym ten dział zajmuje się na co dzień. Zamiast szukać kolejnych usprawnień, pojawił się odruch ochrony status quo: lepiej zostawić sobie ręczne wklejanie danych, nawet jeśli jest zbędne, niż zgodzić się na krok, po którym rola zespołu ograniczyłaby się do samej weryfikacji. Dodatkowo, gdy zaproponowano przy okazji uproszczenie procedury obsługi faktur zagranicznych, na tę propozycję w ogóle nie podjęto rozmowy.
Opór pracowników wobec automatyzacji, która działa
W jednym z wdrożeń — generowanie wniosków leasingowych na samochody w banku — pracownicy ręcznie przepisywali dane z faktur PDF do Excela, który następnie wgrywali do systemu bankowego. Po wdrożeniu prostego systemu działającego na zasadzie "wrzuć PDF do folderu, odbierz gotowy Excel z drugiego folderu" — przy najbliższej okazji zespół i tak wrócił do ręcznego przepisywania.
Bariera nie zawsze leży po stronie klienta — czasem leży wewnątrz samej struktury wdrożenia Origami Effect współpracuje też z zewnętrznymi Interim CFO, dostarczając im narzędzia do automatyzacji raportowania i analiz, które mogą wykorzystać we własnych mandatach u klientów. Jeden z takich przypadków — moduł analogiczny do Themis, wspomagający analizy rynkowe automatycznym pobieraniem i przetwarzaniem danych z katalogów PDF, w skali około 50 razy większej niż to, co pracownik ogarniał ręcznie — został zaproponowany przez Interim CFO wewnątrz jednej z obsługiwanych przez niego firm, ale ugrzązł na poziomie działu. Nie był to opór wobec samego narzędzia, lecz konsekwencja szerszego problemu: Interim CFO, wchodząc do organizacji, sam prowadzi już rozległą pracę nad ustawieniem całej firmy i nie zawsze ma przestrzeń, by dodatkowo przeprowadzić pojedynczy dział przez wdrożenie nowego narzędzia analitycznego.
Dlaczego wewnętrzne IT samo tego nie rozwiąże
Ten sam problem, obserwowany od strony klienta w powyższych przykładach, ma swoje lustrzane odbicie po stronie wewnętrznych działów IT — i warto go nazwać wprost, bo tłumaczy, dlaczego duże organizacje z własnym zapleczem technologicznym też nie radzą sobie z tym wyzwaniem samodzielnie.
Tradycyjne IT potrafi wdrażać systemy deterministyczne: określone działanie zawsze daje ten sam, przewidywalny rezultat. AI działa inaczej — jest probabilistyczne, przewiduje najbardziej prawdopodobny wynik, nie oblicza go w sposób deterministyczny. Działy IT, próbując podłączyć gotowe modele AI bezpośrednio do własnych, nieuporządkowanych hurtowni danych, trafiają dokładnie na problem opisany wcześniej w tym dokumencie: AI zaczyna zgadywać na niespójnych danych, efekt bywa niewiarygodny, a dział IT — nie rozumiejąc do końca, dlaczego tak się dzieje — z ostrożności blokuje projekt, uznając, że "technologia nie jest jeszcze gotowa". W rzeczywistości problemem nie jest AI, lecz brak warstwy orkiestracji i precyzyjnej matematyki (takiej jak ABC czy Driver Based Modeling) zanim dane w ogóle trafią do modelu.
Do tego dochodzi rozdźwięk kompetencyjny między IT a biznesem. Dział IT rzadko rozumie szczegóły konkretnego procesu operacyjnego — jak agronom kalkuluje dawkę żywieniową, jak logistyk układa towar w kontenerze — i w efekcie projektuje rozwiązania z perspektywy technologii, nie z perspektywy procesu. Powstają rozbudowane dashboardy webowe, których nikt nie chce używać, bo menedżer i tak woli pracować w znanym sobie Excelu — dokładnie ten sam mechanizm, który widzieliśmy wcześniej przy kontraście między wersją webową a komunikatem na Discordzie. IT rzadko też dochodzi samodzielnie do architektury typu Single Entry – Multi Output — ich naturalnym punktem odniesienia jest wdrożenie zamkniętego systemu, nie zaprojektowanie warstwy, która elastycznie łączy dane u źródła.
Efektem ubocznym tej bezwładności bywa też zjawisko znane jako Shadow IT: gdy oficjalne wdrożenia trwają miesiącami, działy biznesowe — finanse, sprzedaż, logistyka — zaczynają cyfryzować się na własną rękę, poza kontrolą IT, podpinając firmowe dane pod przypadkowe narzędzia SaaS czy AI. Powstaje w ten sposób bałagan bezpieczeństwa i zarządzania danymi, którego rozwiązywanie pochłania jeszcze więcej czasu i zaufania po obu stronach.
To wzmacnia argument stojący za modelem Origami Effect: potrzebna jest osoba z zewnątrz, która rozumie jednocześnie precyzyjną matematykę modelu, architekturę orkiestracji danych i konkretny proces biznesowy klienta — a nie wewnętrzny dział IT, który zna tylko jeden z tych trzech elementów naraz.
Pojedynczy entuzjasta uderza w ścianę, której sam nie widzi
Obok barier organizacyjnych opisanych wyżej, istnieje jeszcze jeden wzorzec — pojedynczy pracownik, zwykle najbardziej zaangażowany i kompetentny w swoim zespole, który z własnej inicjatywy próbuje przeprowadzić fragment automatyzacji samodzielnie. Taka osoba dociera zwykle dość szybko do punktu, poza który nie jest w stanie przejść — nie z braku umiejętności, lecz dlatego, że jest częścią tego samego systemu, który próbuje zmienić. To trochę jak z jaskinią Platona: będąc wewnątrz organizacji, widzi się tylko cienie rzucane przez dotychczasowe procesy — sposób pracy, który wydaje się jedyną możliwą rzeczywistością, bo nikt wewnątrz nigdy nie widział niczego innego. Pojedynczy pracownik, nawet bardzo zdeterminowany, nie ma dystansu, by zakwestionować założenia, na których cała organizacja od lat się opiera, ani mandatu, by przeprowadzić zmianę wykraczającą poza jego własne stanowisko — a jeszcze mniej ma odwagi, by narazić się przełożonym czy kolegom, z którymi codziennie pracuje.
Ktoś z zewnątrz — nieobciążony sympatią do konkretnych osób, lojalnością wobec tego, jak zawsze to robiono, ani obawą o własną pozycję w firmie — może spojrzeć na te same procesy bez tego rodzaju emocjonalnego uwikłania, kierując się wyłącznie tym, co jest obiektywnie najlepsze dla firmy jako całości. To nie jest przewaga wynikająca z większej wiedzy technicznej — to przewaga wynikająca z pozycji, z której się patrzy: poza jaskinią, a nie wewnątrz niej.
Malejący punkt startowy — mniej samodzielności, więcej potrzeby kontroli
Warto nazwać zjawisko widoczne w perspektywie dłuższej niż pojedyncze wdrożenie. Osiemnaście lat temu menedżerowi biura podróży tłumaczono, jak samodzielnie rozbudować makra VBA w Excelu, żeby jego zespół mógł koordynować i raportować sprzedaż. Dziś, w innych projektach, dwóm menedżerom trzeba tłumaczyć, w które dokładnie pole w Excelu wpisać ścieżkę do katalogu, żeby system zapisał im w tym miejscu plik PDF z zamówieniem. To nie jest anegdota o spadku inteligencji — to obserwacja zmieniającego się punktu startowego samodzielności technicznej wśród osób zarządzających oraz towarzyszącego mu wzrostu oczekiwania, że ktoś inny wszystko skonfiguruje, sprawdzi i utrzyma.
Architektura lęku, czyli korporacyjna Gra pozorów
Z tym zjawiskiem splata się coś głębszego niż sama kompetencja techniczna: rosnąca ostrożność w braniu na siebie jednoznacznej odpowiedzialności za decyzję lub wynik działania własnego działu. Współczesny management często uprawia grę pozorów — na zewnątrz deklaruje chęć innowacji i pełną kontrolę, ale pod powierzchnią kryje się lęk przed błędem lub dodatkowym wysiłkiem. W praktyce Origami Effect spotyka się z sytuacjami, w których ocena nowego rozwiązania jest odwlekana tak długo, aż inicjatywa naturalnie wygasa. To w gruncie rzeczy racjonalna strategia przetrwania w środowisku, w którym jednoznaczna rekomendacja wiąże się z osobistym ryzykiem — lepiej pozwolić projektowi umrzeć w ciszy, niż podpisać się pod czymś, co mogłoby zaburzyć starannie budowany obraz sukcesu.
To zjawisko ostatecznie wyjaśnia, dlaczego rola interim managera stała się dziś kluczowa. Ktoś z zewnątrz, nieobciążony potrzebą ochrony własnej pozycji w hierarchii, może wziąć tę odpowiedzialność na siebie wprost — nie z nadludzkiej odwagi, lecz z prostej dynamiki: interim manager nie uczestniczy w wewnętrznej grze o wizerunek, bo w przeciwieństwie do etatowego pracownika nie musi z tymi samymi ludźmi budować relacji na kolejne lata. Przychodzi, wykonuje zadanie i wychodzi.
Nie wszędzie jest tak samo — gospodarstwa rolne jako kontrprzykład
Nie każda organizacja napotyka te same bariery. Gospodarstwa rolne, takie jak to opisane w Case Study I, przyjmowały tego typu rozwiązania ze zdecydowanie większą otwartością niż firmy korporacyjne z dużych miast. To okazał się zupełnie inny typ klienta — znacznie bardziej otwarty na innowacje, niż sugerowałby stereotyp branży rolniczej jako tradycyjnej i zachowawczej. Wdrożenia oparte na Excelu poszły w tych gospodarstwach najprościej ze wszystkich dotychczasowych projektów. Pracownicy biurowi w gospodarstwach rolnych wykazywali też wyraźnie większą zdolność do skupienia i zaangażowania w proces wdrożenia niż ich odpowiednicy np. w firmie importowej.
Po pierwsze, w gospodarstwie rolnym decyzję podejmuje zwykle sam właściciel, a nie wielopoziomowa struktura zarządcza — eliminuje to mechanizm "obawy przed wzięciem odpowiedzialności za decyzję" przed kimś wyżej. Po drugie, konsekwencje decyzji operacyjnych są tam bezpośrednie i namacalne — plon, cena mleka, koszt paszy przekładają się wprost na dochód właściciela. Po trzecie, presja marżowa w rolnictwie jest dziś na tyle duża, że potrzeba precyzyjnego narzędzia jest odczuwana bezpośrednio, a nie teoretycznie.
To pokazuje ważną rzecz dla modelu rozwoju Origami Effect: branże, w których decydent jest jednocześnie właścicielem ponoszącym bezpośrednie ryzyko finansowe swoich decyzji, są naturalnie bardziej podatnym gruntem dla tego typu wdrożeń niż organizacje z rozproszoną, wielowarstwową strukturą decyzyjną.
Zmiana i tak nadejdzie — nie z wyboru, lecz z konieczności pokoleniowej
Niezależnie od tego, jak długo zarządy będą zwlekać z tą zmianą myślenia, sama struktura demograficzna organizacji sprawi, że stanie się ona nieunikniona. Starsza kadra, przyzwyczajona do dotychczasowych metod pracy, systematycznie odchodzi z rynku pracy. Zastępuje ją pokolenie, które jest z jednej strony bardziej niecierpliwe wobec powolnych, ręcznych procesów, a z drugiej — z racji mniejszego doświadczenia — mniej dokładne w ich wykonywaniu, co samo w sobie zwiększa presję na automatyzację jako sposób minimalizacji błędu, a nie tylko oszczędności czasu.
To nie jest zmiana, którą zarządy świadomie wybiorą — to zmiana, która zostanie im narzucona przez naturalną wymianę pokoleniową w ich własnych zespołach.
Dlaczego konkret rozbraja ten opór
Wszystkie opisane wyżej bariery — obawa przed wzięciem odpowiedzialności za ocenę, ochrona status quo własnej roli, gra pozorów wokół rzekomej gotowości na zmianę — mają jedną wspólną cechę: żywią się abstrakcją. Dopóki automatyzacja jest obietnicą, a nie czymś widocznym, każda ocena jest oceną ryzyka nieznanego, a nikt nie chce być tym, kto zaakceptował coś, co się nie sprawdziło. To dlatego pierwsza rozmowa nie powinna zaczynać się od pytania "czy warto się cyfryzować", tylko od pokazania konkretnego, działającego przykładu osadzonego w realiach danej firmy — dashboardu, raportu, przepływu danych zbudowanego na bazie tego, co już istnieje. Sam przykład nie jest jednak celem — jest punktem wejścia do rozmowy o czymś ważniejszym: jak faktycznie wygląda proces w tej konkretnej firmie i jak technologię dopasować do niego, a nie odwrotnie. Zarząd i interesariusze przestają wtedy oceniać abstrakcyjną obietnicę technologii — zaczynają rozmawiać o własnym procesie, patrząc na coś, co mają przed oczami.
To zmienia całą dynamikę odpowiedzialności opisaną wcześniej w tej sekcji. Nikt nie musi już ręczyć głową za abstrakcyjną obietnicę technologii, której jeszcze nie widział — ocenia coś, co ma przed oczami, a to jest zupełnie inny, dużo bezpieczniejszy rodzaj decyzji: nie "czy wierzę, że to zadziała", tylko "czy to, co widzę, pasuje do tego, jak u nas pracujemy". Odpowiedzialność za pierwszy krok przesuwa się z pracownika na sam draft — to on jest oceniany, nie osoba, która się pod nim podpisała. Z czasem rola interim managera naturalnie się zawęża — z architekta budującego rozwiązanie od zera, do kogoś, kto pilnuje poprawności wdrożenia w praktyce i reaguje na nowe potrzeby, aktualizacje czy rozszerzenia systemu, w miarę jak firma rośnie i zmienia się jej rzeczywistość biznesowa. To dużo skuteczniejsza droga niż same szkolenia z Excela, które próbują zmieniać nawyk pojedynczych ludzi jeden po drugim, bez żadnego namacalnego punktu odniesienia, do którego mogliby wrócić, gdy szkolenie się skończy i codzienna presja pracy każe wrócić do starych przyzwyczajeń. Jest w tym coś głębszego niż tylko wygoda demonstracji: gotowy draft działa jak kotwica, do której organizacja może się odwoływać miesiącami po pierwszym spotkaniu — "chcemy dojść do tego, co nam wtedy pokazano" — podczas gdy szkolenie jest ulotne z definicji, bo istnieje tylko w pamięci uczestników, która więdnie szybciej niż jakikolwiek nawyk, który miała zbudować.
Co to potwierdza
Wspólnym mianownikiem tych doświadczeń nie jest jakość technologii — każde z opisanych rozwiązań działało i dawało wymierną, policzalną korzyść. Wspólnym mianownikiem jest brak kogoś wewnątrz procesu wdrożenia, kto miałby czas, mandat i determinację, by przeprowadzić organizację przez ostatni, najtrudniejszy etap zmiany — a nie tylko dostarczyć działające narzędzie i uznać zadanie za zakończone. To właśnie ten etap decyduje, czy transformacja cyfrowa faktycznie się wydarzy, czy pozostanie zbiorem pojedynczych, niepowiązanych ze sobą usprawnień. Dlatego Origami Effect wchodzi do firmy nie jako dostawca gotowego produktu, lecz jako interim manager transformacji cyfrowej — ktoś, kto pozostaje przy wdrożeniu na tyle długo, by przeprowadzić przez ten etap nie tylko system, ale i ludzi, którzy mają z niego korzystać na co dzień.
