Transformacja cyfrowa to nie wdrożenie systemu, lecz zmiana zasad gry

Wdrożenie zakończone protokołem odbioru, budżet rozliczony, prezentacja dla zarządu pokazuje sukces – a mimo to nic się nie zmienia. Pracownik nadal ręcznie przepisuje dane między systemami, kierownik czeka na te same akceptacje, a klient znów tłumaczy sprawę, którą firma powinna już znać. Nie doszło do żadnej awarii – wszystko poszło zgodnie z harmonogramem, tyle że plan dotyczył samej technologii, nie sposobu funkcjonowania firmy.

Na tym polega główna pułapka cyfrowej transformacji: można wymienić oprogramowanie, przenieść dane do chmury i dać zespołom narzędzia AI, zachowując przy tym stare silosy, te same wąskie gardła w podejmowaniu decyzji i brak jasnej odpowiedzialności za cały proces. Firma robi się bardziej cyfrowa, ale niekoniecznie bardziej efektywna. Nowe narzędzia potrafią przyspieszyć pracę, jednak nie podejmą za zarząd decyzji, które zadania w ogóle mają sens. Automatyzacja źle zaprojektowanego procesu oznacza po prostu szybsze wykonywanie czynności, które w ogóle nie powinny istnieć.

Wdrożenie zakończone, transformacja nierozpoczęta

Na papierze transformacja wygląda schludnie – ma harmonogram, kamienie milowe, właścicieli poszczególnych zadań i wyznaczoną datę osiągnięcia korzyści. Nie musi mierzyć się z dyrektorem, który popiera zmianę pod warunkiem, że ominie jego dział, ani z przestarzałym systemem sprzed piętnastu lat, ani z pytaniem, kto sfinansuje przebudowę procesu rozciągniętego na cztery różne piony.

W rzeczywistej organizacji te problemy trzeba jednak rozstrzygnąć – i właśnie tu kończy się bezpieczna narracja o technologii, a zaczyna trudna rozmowa o władzy, budżecie i odpowiedzialności.

Groźna jest sytuacja, w której transformację uznaje się za skończoną na podstawie mylących sygnałów: system działa, pieniądze rozliczone, raporty spływają regularnie, a mimo to decyzje zapadają tak samo powoli, pracownicy omijają uciążliwe procedury, a klient nie odczuwa żadnej różnicy. Organizacja ma nowe narzędzie, ale nie zyskała nowej umiejętności działania.

Nie znaczy to, że modernizacja infrastruktury jest niepotrzebna – nowy ERP, migracja do chmury czy platforma danych bywają warunkiem koniecznym dalszego rozwoju. Same w sobie nie świadczą jednak o transformacji. Świadczy o niej dopiero to, co dzięki nim firma zaczyna robić inaczej: szybsza obsługa klientów, nowe usługi, trafniejsze decyzje albo zmieniony model zarabiania. Projekt technologiczny dostarcza narzędzie – transformacja polega na tym, że firma uczy się z niego korzystać i rezygnuje ze starych nawyków. Uruchomienie produkcyjne nie kończy więc procesu zmiany, często dopiero go realnie testuje.

AI może przyspieszyć pracę, której nikt nie potrzebuje

Weźmy przykład cotygodniowego raportu przygotowywanego dla kilku szczebli zarządzania: ktoś zbiera dane z trzech systemów, uzgadnia rozbieżności, opisuje wyniki, a potem dokument krąży przez kolejne akceptacje, choć nikt nie potrafi wskazać decyzji, która faktycznie od niego zależy.

Sztuczna inteligencja może skrócić przygotowanie takiego raportu z kilku godzin do kilku minut. Można jednak wcześniej zadać pytanie, czy ten raport w ogóle jest potrzebny. Pierwsze podejście poprawia wydajność wykonywania zadania, drugie może w ogóle usunąć zbędne zadanie.

W metodyce Lean takie marnotrawstwo nazywa się japońskim słowem „muda” – to działania, które pochłaniają czas, pracę i zasoby, ale nie generują wartości dla klienta, jak wskazuje Lean Enterprise Institute. W codziennej pracy biurowej przykładów nie brakuje: wielokrotne przepisywanie tych samych danych, poprawianie błędów z wcześniejszego etapu czy czekanie na akceptację, która niczego już nie zmienia.

Lean odróżnia jednak marnotrawstwo, które można wyeliminować, od czynności, które wprawdzie nie tworzą wartości, ale w danych warunkach pozostają niezbędne, jak podaje Lean Enterprise Institute. To istotne ostrzeżenie w kontekście transformacji – wymaganej kontroli bezpieczeństwa nie wolno mylić z podpisem zbieranym tylko dlatego, że „zawsze tak było”.

AI potrafi ograniczać zbędną pracę, ale sama nie zdecyduje, które reguły organizacja powinna zmienić. Jeśli powierzymy jej niepotrzebne raporty, zbędne akceptacje i wadliwie zaprojektowane procesy, marnotrawstwo po prostu urośnie do nowej skali – więcej, szybciej, może taniej, ale bez odpowiedzi na pytanie, po co to wszystko robimy.

Dlatego dyskusję o AI lepiej zacząć nie od pytania „gdzie możemy ją zastosować?”, ale od pytania „co chcemy zmienić w decyzji, procesie albo doświadczeniu klienta?”. Wybór narzędzia i sposobu mierzenia efektów powinien przyjść dopiero potem.

Pilotaż bywa wygodniejszy niż decyzja

Eksperyment daje możliwość sprawdzenia pomysłu bez ryzykowania całej organizacji i jest w pełni uzasadniony. Kłopot pojawia się wtedy, gdy przestaje służyć podjęciu decyzji, a zaczyna być sposobem jej unikania.

W ramach pilotażu można zawęzić zakres działania, ręcznie poprawiać dane i opierać powodzenie rozwiązania na zaangażowaniu kilku osób, jednocześnie odkładając pytania o to, kto będzie odpowiadał za usługę, finansował jej utrzymanie i reagował w razie awarii. Demonstracja dowodzi jedynie, że rozwiązanie potrafi wykonać zadanie – nie dowodzi, że firma może na nim polegać.

Kiedy przychodzi moment skalowania, wracają odłożone wcześniej pytania: kto odpowiada za jakość danych, kto ma prawo zmieniać proces, jak zintegrować rozwiązanie z istniejącymi systemami, jak spełnić wymogi prawne i bezpieczeństwa oraz kto poniesie odpowiedzialność za wynik, gdy zespół projektowy zostanie rozwiązany.

Kolejny pilotaż często pozwala uniknąć tej konfrontacji – daje nowy temat na spotkanie komitetu, świeże wyniki do zaprezentowania i poczucie, że coś się dzieje, bez konieczności wyłączania starego narzędzia, zmiany budżetu czy naruszania granic między działami.

Dojrzałość transformacyjna nie polega na liczbie uruchomionych eksperymentów, lecz na zdolności do decydowania o ich dalszym losie – rozwijania tych, które przynoszą wartość, i zamykania tych, które jej nie potwierdziły. Najtrudniejszy moment to przejście od etapu „sprawdzamy, czy to działa” do stwierdzenia „tak teraz działa nasza firma”.

Fundamenty wystawiają rachunek

Architektura systemów, jakość danych i bezpieczeństwo z reguły przegrywają w konkurencji o uwagę z efektowną demonstracją nowego modelu AI. Znacznie trudniej pokazać korzyść z uporządkowania zależności między systemami niż asystenta odpowiadającego na pytanie w kilka sekund – dopóki nie okaże się, że odpowiedź opiera się na danych, którym nie można ufać.

Dług technologiczny nie zostaje w dziale IT – wraca do biznesu w postaci dłuższego czasu wprowadzania produktów na rynek, wyższych kosztów zmian i ryzyka przerwania działalności. Niespójne dane wracają jako spotkania poświęcone ustalaniu, czyj raport pokazuje prawdziwy wynik, a źle zaprojektowane procesy – jako opóźnienia, reklamacje i konieczność powtarzania pracy.

To nie są kwestie techniczne, które można zostawić na później, tylko warunki realizacji strategii firmy. Zarząd może chcieć działać szybciej, ale musi też zdecydować, jakie ograniczenia trzeba usunąć i kto za to odpowiada.

Podobnie bezpieczeństwo nie powinno być ostatnią przeszkodą przed uruchomieniem rozwiązania, lecz elementem jego projektu od samego początku – od zasad dostępu do danych po sposób reagowania na incydenty. Organizacja potrzebuje nie zapewnienia, że nic złego się nie wydarzy, tylko zdolności ograniczenia skutków zdarzenia i utrzymania kluczowych operacji. Fundamenty nie rywalizują z innowacją o budżet – decydują, czy obiecujący pomysł stanie się rozwiązaniem, na którym można oprzeć biznes.

IT nie jest drugą stroną stołu

Popularne hasło, że „IT powinno być partnerem biznesu”, brzmi rozsądnie, lecz kryje w sobie kłopotliwe założenie – że biznes to coś oddzielnego, gdzie jedna strona zgłasza potrzeby, a druga je realizuje. Gdy pojawia się problem, obie strony mogą powiedzieć, że wykonały swoją część zadania.

W przypadku produktu cyfrowego taki podział jest jednak sztuczny, bo doświadczenie klienta zależy jednocześnie od oferty, procesu, danych i działania systemów. Nie sposób oceniać tych elementów osobno, w oderwaniu od wspólnego efektu.

Potrzeba więc czegoś więcej niż lepszej komunikacji między działami – wspólnej odpowiedzialności za produkt lub proces, wspólnych mierników i jasno przypisanych praw do podejmowania decyzji, a tam, gdzie ma to sens, również wspólnego rozliczania przychodów i kosztów. Zespół nie powinien być nagradzany wyłącznie za terminowe dostarczenie funkcji, z której nikt nie korzysta.

Taki kierunek autorzy określają jako „IT as an Enterprise” – zarządzanie technologią jako integralną częścią działalności firmy, z odpowiedzialnością za wartość, koszty, ryzyko i rozwój. To nie jest nowa nazwa działu ani usługa do kupienia, lecz zmiana samych zasad zarządzania. Wspólna odpowiedzialność nie oznacza przy tym rozmycia – każdy istotny wynik potrzebuje konkretnego właściciela, a wspólny zespół nie zwalnia nikogo z obowiązku podjęcia ostatecznej decyzji.

Opór ma więcej wspólnego z wpływem niż z technologią

Łatwo powiedzieć, że ludzie nie lubią zmian, trudniej przyznać, że opór wobec konkretnej zmiany może być całkiem racjonalny. Nowy proces odbiera komuś prawo do akceptacji, dane podważają dotychczasowe osądy, a automatyzacja obniża wartość kompetencji budowanych latami.

Szczególnie trudno mają menedżerowie średniego szczebla, którzy muszą wdrażać zmianę, jednocześnie utrzymując bieżące wyniki i przekonując zespół do kierunku, który może przeorganizować także ich własną rolę. Jeśli nadal są rozliczani wyłącznie z wyników swojego działu, trudno liczyć, że bez oporu podporządkują je usprawnieniu całego procesu.

Nie wystarczy pokazać pracownikom obsługę nowego narzędzia – trzeba też wyjaśnić, co zmieni się w ich zakresie odpowiedzialności, wpływie na decyzje i sposobie oceniania pracy. Kluczowe jest wcześniejsze uzgodnienie tych zmian na poziomie kierownictwa, zamiast zostawiania zespołom sprzecznych oczekiwań do samodzielnego rozstrzygnięcia.

To właśnie w takich momentach objawia się przywództwo – w rozstrzyganiu konfliktów, otwartym nazywaniu kosztów zmiany i demontowaniu starych mechanizmów sprzecznych z nowymi celami. Nie da się oczekiwać współpracy między działami, jednocześnie premiując wyłącznie lokalną optymalizację, ani zachęcać do eksperymentowania i karać za każdą nieudaną próbę jak za błąd.

Nie oznacza to obniżenia poprzeczki – klient wciąż musi być obsłużony, produkcja musi trwać, a wynik finansowy pozostaje istotny. Dojrzała organizacja potrafi jednocześnie stworzyć przestrzeń do eksperymentowania i wyznaczyć granice ryzyka, których przekraczać nie wolno.

7 pytań przed następną inwestycją

Zanim zarząd zaakceptuje kolejny program transformacyjny, wdrożenie AI czy dużą modernizację, warto zatrzymać się przy siedmiu pytaniach. Nie zastąpią one strategii, ale pomogą ustalić, czy firma naprawdę szykuje się na zmianę sposobu działania, czy tylko na zakup kolejnego rozwiązania.

1. Jaki konkretny problem biznesowy rozwiązujemy i jaki jest koszt pozostawienia go bez zmiany?
2. Co rzeczywiście zmieni się dla klienta, pracownika lub partnera?
3. Kto odpowiada za efekt biznesowy, także po zakończeniu wdrożenia?
4. Które procesy, decyzje i zakresy odpowiedzialności musimy przeprojektować?
5. Czy nasze dane, architektura i bezpieczeństwo pozwalają nie tylko uruchomić rozwiązanie, lecz także korzystać z niego na większą skalę?
6. Z jakich narzędzi, czynności lub zasad zrezygnujemy, gdy nowe rozwiązanie zacznie działać?
7. Jak zmierzymy zmianę względem punktu wyjścia i kiedy zdecydujemy o dalszej inwestycji albo zatrzymaniu prac?

Nie wszystkie odpowiedzi muszą być gotowe przed pierwszym eksperymentem, ale trzeba wiedzieć, które niewiadome ma on wyjaśnić, kto podejmie ostateczną decyzję i w jakim terminie. Stwierdzenie „ustalimy w trakcie” może być uczciwym opisem hipotezy, ale nie powinno stać się na stałe modelem zarządzania.

Szczególną uwagę warto poświęcić pytaniu o rezygnację – jeśli nowe rozwiązanie nie zastępuje żadnej dotychczasowej czynności, zasady czy technologii, trzeba sprawdzić, czy faktycznie zmienia organizację, czy tylko dokłada jej kolejną warstwę pracy i kosztów.

Dlaczego powstała ta książka

Z napięcia pomiędzy wdrożeniem technologii a rzeczywistą zmianą narodziła się książka „Cyfrowa Transformacja. AI · Dane · Ludzie”. Jej autorom nie zależało na stworzeniu kolejnego zestawienia trendów, lecz na oddaniu głosu ludziom, którzy podejmowali decyzje, budowali rozwiązania, mierzyli się z oporem i ponosili konsekwencje swoich wyborów.

W tworzeniu publikacji wzięło udział ponad dwudziestu praktyków biznesu i technologii. Książka łączy sześć perspektyw: strategię i decyzje zarządu; architekturę, dane, procesy i bezpieczeństwo; przejście od projektów IT do trwałej zmiany; ludzi, kulturę i talenty; praktyczne zastosowania AI, platform oraz technologii przemysłu 5.0; a także lekcje liderów i drogę od diagnozy do działania. Zebrane doświadczenia nie tworzą jednego uniwersalnego wzorca do skopiowania, ale pozwalają dostrzec zależności, które łatwo przeoczyć, patrząc na transformację wyłącznie z perspektywy własnego obszaru odpowiedzialności.

To książka o technologii, której głównym tematem jest jednak odpowiedzialność za zmianę – za decyzje podejmowane przy niepełnych danych, kompromisy między tempem a bezpieczeństwem oraz ludzi, którzy muszą przebudować firmę, nie zatrzymując jej bieżącego działania.

O powodzeniu transformacji nie decyduje ani efektowna demonstracja, ani dzień podpisania protokołu odbioru, lecz zwykły poniedziałkowy poranek, w którym trzeba zrezygnować ze zbędnej akceptacji, przekazać komuś prawo do decyzji albo wyłączyć stary proces, mimo że przez lata dawał poczucie kontroli.

Dlatego przed kolejną inwestycją warto zapytać nie tylko, jaką technologię firma kupuje, ale też jaką zdolność organizacji buduje dzięki niej. A zaraz potem zadać trudniejsze pytanie: co jesteśmy gotowi zmienić we własnym sposobie zarządzania, żeby ta zdolność rzeczywiście powstała.

Nie chcieliśmy tworzyć kolejnego katalogu trendów. Zależało nam na perspektywie ludzi, którzy podejmowali decyzje, budowali rozwiązania, mierzyli się z oporem i odpowiadali za konsekwencje swoich wyborów.

Agnieszka Bochacka i Robert Pławiak, redaktorzy merytoryczni książki

Autorami tekstu są Agnieszka Bochacka, Global Digital Transformation Director – Product Management w GE HealthCare, oraz Robert Pławiak, CTO / CAIO w ProService Finteco. Premiera ich wspólnej książki „Cyfrowa Transformacja. AI · Dane · Ludzie”, powstałej pod ich redakcją merytoryczną przy udziale ponad dwudziestu praktyków biznesu i technologii, zaplanowana jest na 4 listopada 2026 roku.

Czytelnicy serwisu ITwiz mogą skorzystać z 10% rabatu na zakup publikacji – kod ITWIZ100 jest ważny do 15 października 2026 roku, a szczegóły oferty oraz przedsprzedaż dostępne są na stronie cyfrowatransformacja.com.pl.