CIORynekPolecane tematy

Cyfrowa transformacja nie potrzebuje kolejnego pilotażu, ale decyzji

Firmy potrafią kupić technologię, uruchomić program transformacyjny i rozliczyć jego budżet, nie zmieniając przy tym zasad, według których działają. Dlatego największym zagrożeniem dla transformacji bywa nie spektakularna porażka, lecz sukces, który istnieje wyłącznie w dokumentacji projektu. System działa. Organizacja stoi w miejscu.

Cyfrowa transformacja nie potrzebuje kolejnego pilotażu, ale decyzji

Wyobraźmy sobie poniedziałek po zakończeniu dużego wdrożenia. Nowy system już działa, zespół projektowy odebrał gratulacje, a zarząd zobaczył prezentację podsumowującą sukces. Tymczasem pracownik obsługi klienta nadal kopiuje dane między aplikacjami. Kierownik czeka na te same trzy akceptacje. Klient po raz kolejny wyjaśnia sprawę, którą firma powinna już znać.

Nie wydarzyła się awaria. Przeciwnie: wszystko uruchomiono zgodnie z planem. Tyle że plan obejmował wdrożenie technologii, a nie zmianę sposobu działania firmy.

Ten obraz dobrze oddaje pułapkę cyfrowej transformacji. Można wymienić systemy, przenieść dane do chmury i udostępnić pracownikom narzędzia AI, zachowując dotychczasowy porządek: te same silosy, te same wąskie gardła decyzyjne i ten sam brak odpowiedzialności za cały proces. Organizacja staje się bardziej cyfrowa, ale niekoniecznie bardziej skuteczna.

Technologia potrafi przyspieszyć pracę. Nie rozstrzygnie jednak za zarząd, która praca ma sens, a z której należy zrezygnować. Jeśli automatyzujemy źle zaprojektowany proces, możemy po prostu szybciej wykonywać czynności, których w ogóle nie powinno być.

Wdrożenie zakończone, transformacja nierozpoczęta

Na slajdzie transformacja jest uporządkowana. Ma etapy, kamienie milowe, właścicieli i datę osiągnięcia korzyści. Nie musi negocjować z dyrektorem, który popiera zmianę pod warunkiem, że nie obejmie ona jego obszaru. Nie musi współpracować z systemem sprzed piętnastu lat ani rozstrzygać, kto zapłaci za przebudowę procesu przebiegającego przez cztery działy.

Cyfrowa transformacja nie potrzebuje kolejnego pilotażu, ale decyzji

Prawdziwa organizacja musi. I właśnie w tym miejscu kończy się wygodna opowieść o technologii, a zaczyna rozmowa o władzy, pieniądzach i odpowiedzialności.

Dlatego szczególnie niebezpieczna jest transformacja, którą uznano za zakończoną na podstawie niewłaściwych dowodów. System wdrożono, budżet rozliczono, raportowanie uruchomiono. Tylko decyzje nadal zapadają równie wolno, pracownicy obchodzą niewygodne procedury, a klient nie odczuwa różnicy. Firma zyskała kolejne narzędzie, lecz nie zyskała nowej zdolności do działania.

Nie oznacza to, że modernizacja technologiczna jest zbędna. Nowy system ERP, chmura czy platforma danych mogą być konieczne, aby w ogóle ruszyć dalej. Nie są jednak dowodem transformacji. Dowodem jest dopiero to, co dzięki nim organizacja potrafi robić inaczej: szybciej rozstrzygać sprawy klientów, rozwijać nowe usługi, trafniej podejmować decyzje albo zmieniać sposób zarabiania.

Projekt technologiczny dostarcza rozwiązanie. Transformacja wymaga, by firma nauczyła się działać z jego pomocą i przestała działać po staremu. Produkcyjne uruchomienie nie zamyka więc zmiany. Często dopiero wystawia ją na najważniejszą próbę.

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

Wyobraźmy sobie raport przygotowywany co tydzień dla kilku szczebli zarządzania. Pracownik zbiera dane z trzech systemów, uzgadnia rozbieżności i opisuje wyniki. Następnie dokument wędruje przez kolejne akceptacje, choć nikt nie potrafi wskazać decyzji, która rzeczywiście od niego zależy.

Można wykorzystać AI, aby przygotowywać taki raport w kilka minut zamiast kilku godzin. Można też najpierw zapytać, czy raport jest potrzebny. Pierwsza decyzja poprawia wydajność wykonywania zadania. Druga może usunąć zadanie, które nie powinno nikogo zajmować.

W podejściu Lean takie marnotrawstwo określa się japońskim słowem „muda”: to czynności, które zużywają czas, pracę lub inne zasoby, ale nie tworzą wartości dla klienta (Lean Enterprise Institute). W realiach biurowych łatwo wskazać jego przykłady: wielokrotne przepisywanie tych samych danych, poprawianie błędów powstałych na wcześniejszym etapie czy oczekiwanie na akceptację, która niczego już nie rozstrzyga.

Nie znaczy to, że każdą czynność niewidoczną dla klienta można skreślić: Lean rozróżnia marnotrawstwo możliwe do usunięcia od działań, które nie dodają wartości, ale w obecnych warunkach pozostają konieczne (Lean Enterprise Institute). W transformacji to ważna przestroga: wymaganej kontroli bezpieczeństwa nie należy mylić z podpisem zbieranym wyłącznie dlatego, że „zawsze tak robiliśmy”.

AI może pomóc ograniczyć zbędną pracę. Sama nie przesądzi jednak, które zasady organizacja powinna zmienić. Jeśli zlecimy jej obsługę niepotrzebnych raportów, zbędnych akceptacji i źle zaprojektowanych procesów, nadamy marnotrawstwu nową skalę. Będziemy robić więcej, szybciej i być może taniej, nadal bez odpowiedzi na pytanie: po co?

Dlatego rozmowy o AI warto zaczynać nie od pytania „gdzie możemy ją wdrożyć?”, lecz „co chcemy zmienić w decyzji, procesie lub doświadczeniu klienta?”. Dopiero potem przychodzi miejsce na wybór narzędzia i ustalenie, po czym poznamy, że rzeczywiście pomogło.

Pilotaż bywa wygodniejszy niż decyzja

Eksperyment pozwala sprawdzić pomysł bez narażania całej organizacji. Jest potrzebny. Problem zaczyna się wtedy, gdy przestaje służyć podjęciu decyzji, a staje się sposobem jej odkładania.

W pilotażu można ograniczyć zakres, ręcznie poprawić dane i oprzeć działanie rozwiązania na zaangażowaniu kilku osób. Można też nie rozstrzygać jeszcze, kto będzie odpowiadał za usługę, finansował jej utrzymanie i reagował, kiedy zawiedzie. Demonstracja pokazuje, że rozwiązanie potrafi wykonać zadanie. Nie dowodzi, że firma potrafi na nim polegać.

Przy próbie skalowania wracają więc pytania, które odłożono na później. Kto odpowiada za jakość danych? Kto ma prawo zmienić proces? Jak włączyć rozwiązanie do istniejących systemów? Jak spełnić wymagania prawne i bezpieczeństwa? Kto odpowie za wynik po odejściu zespołu projektowego?

Kolejny pilotaż pozwala czasem uniknąć tej rozmowy. Daje nowy temat na komitet, nowe wyniki do pokazania i poczucie postępu. Nie wymaga jeszcze wyłączenia starego narzędzia, zmiany budżetu ani naruszenia granic między działami.

Dojrzałość transformacyjna nie polega na liczbie rozpoczętych eksperymentów. Polega na zdolności do rozstrzygania ich losu: rozwijania tych, które przynoszą wartość, i zamykania tych, które jej nie potwierdziły. Najtrudniejsze przejście prowadzi od „sprawdzamy, czy to działa” do „tak od dziś działa nasza firma”.

Fundamenty wystawiają rachunek

Architektura, jakość danych i bezpieczeństwo przegrywają pod względem widowiskowości z demonstracją nowego modelu AI. Trudniej pokazać efekt uporządkowania zależności między systemami niż asystenta, który w kilka sekund odpowiada na pytanie. Do czasu, aż asystent ma udzielić odpowiedzi na podstawie danych, którym nie można zaufać.

Dług technologiczny nie pozostaje zamknięty w dziale IT. Wraca do biznesu jako dłuższy czas wprowadzenia produktu, większy koszt zmiany i ryzyko przerwania działalności. Niespójne dane wracają jako spotkania poświęcone ustalaniu, czyj raport pokazuje właściwy wynik. Źle zaprojektowane procesy wracają jako opóźnienia, reklamacje i praca wykonywana ponownie.

To nie są techniczne szczegóły, które można zostawić na później. To warunki realizacji strategii. Zarząd może zdecydować, że chce działać szybciej, ale powinien również zdecydować, które ograniczenia trzeba usunąć i kto za to odpowiada.

Podobnie bezpieczeństwo nie może być ostatnią przeszkodą do pokonania przed uruchomieniem rozwiązania. Powinno być częścią jego projektu: od zasad dostępu do danych po sposób reagowania na awarię lub incydent. Organizacja potrzebuje nie obietnicy, że nic się nie wydarzy, lecz zdolności do ograniczenia skutków zdarzenia i utrzymania kluczowych operacji.

W tym sensie fundamenty nie konkurują 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

Sformułowanie „IT powinno być partnerem biznesu” brzmi rozsądnie, ale zawiera kłopotliwe założenie: biznes znajduje się gdzie indziej. Jedna strona określa potrzeby, druga ma je zrealizować. Gdy pojawiają się problemy, obie mogą wykazać, że wywiązały się ze swojej części.

W cyfrowym produkcie taka granica jest sztuczna. Doświadczenie klienta zależy jednocześnie od oferty, procesu, danych i działania systemów. Nie da się sensownie oceniać tych elementów w oderwaniu od efektu, który wspólnie tworzą.

Dlatego potrzebujemy czegoś więcej niż lepszej komunikacji między działami. Potrzebujemy wspólnej odpowiedzialności za produkt lub proces, wspólnych mierników i jasnych praw do podejmowania decyzji. Tam, gdzie ma to uzasadnienie, także wspólnego rachunku przychodów i kosztów. Zespół nie powinien wygrywać wyłącznie dlatego, że terminowo dostarczył funkcję, z której nikt nie korzysta.

Tak rozumiemy kierunek „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. Nie chodzi o nową nazwę działu ani o usługę, którą można kupić. Chodzi o zmianę zasad zarządzania.

Wspólna odpowiedzialność nie oznacza przy tym odpowiedzialności rozmytej. Każdy istotny wynik nadal potrzebuje konkretnego właściciela, a wspólny zespół nie zwalnia nikogo z podjęcia ostatecznej decyzji.

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

Łatwo uznać, że ludzie nie lubią zmian. Trudniej przyznać, że proponowana zmiana może być dla nich racjonalnym powodem do obaw. Nowy proces odbiera komuś prawo do akceptacji, dane podważają dotychczasowy osąd, a automatyzacja zmniejsza znaczenie kompetencji budowanych przez lata.

Szczególnie trudna bywa sytuacja menedżerów średniego szczebla. Mają wdrażać zmianę, utrzymać bieżący wynik i przekonywać zespół do kierunku, który może zmienić również ich własną rolę. Jeśli nadal są rozliczani wyłącznie z wyniku swojego działu, trudno oczekiwać, że bez oporu podporządkują go usprawnieniu całego procesu.

Nie wystarczy więc wyjaśnić pracownikom, jak korzystać z nowego narzędzia. Trzeba również powiedzieć, co zmieni się w ich odpowiedzialności, wpływie i sposobie oceny pracy. Przede wszystkim zaś trzeba uzgodnić te zmiany na poziomie kierownictwa, zamiast zostawiać zespołom sprzeczne oczekiwania do samodzielnego pogodzenia.

Przywództwo ujawnia się właśnie tutaj: w rozstrzyganiu konfliktów, nazywaniu kosztów zmiany i usuwaniu starych mechanizmów, które stoją w sprzeczności z nowymi celami. Nie można oczekiwać współpracy ponad silosami, a premiować wyłącznie lokalną optymalizację. Nie można zachęcać do eksperymentowania, a każdą nieudaną próbę traktować jak dowód niekompetencji.

Nie oznacza to obniżenia wymagań. Klient nadal musi zostać obsłużony, fabryka musi produkować, a wynik finansowy pozostaje ważny. Dojrzała organizacja potrafi wyznaczyć przestrzeń do eksperymentu i jednocześnie ustalić granice ryzyka, których przekroczyć nie wolno.

7. pytań przed następną inwestycją

Zanim zarząd zatwierdzi kolejny program transformacyjny, wdrożenie AI lub dużą modernizację, powinien zatrzymać się przy siedmiu pytaniach. Nie zastąpią one strategii, ale pozwolą sprawdzić, czy firma przygotowuje zmianę sposobu działania, czy tylko zakup 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ć znane przed pierwszym eksperymentem. Trzeba jednak wiedzieć, które niewiadome ma on rozstrzygnąć, kto podejmie decyzję i w jakim terminie. „Ustalimy w trakcie” może być uczciwym opisem hipotezy. Nie powinno być stałym modelem zarządzania.

Warto zatrzymać się zwłaszcza przy pytaniu o rezygnację. Jeśli nowe rozwiązanie nie zastępuje żadnej dotychczasowej czynności, zasady ani technologii, trzeba sprawdzić, czy rzeczywiście zmienia organizację, czy tylko dokłada jej kolejną warstwę pracy i kosztów.

Dlaczego napisaliśmy tę książkę

Z napięcia między wdrożeniem technologii a rzeczywistą zmianą powstała książka „Cyfrowa Transformacja. AI · Dane · Ludzie”. 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.

Publikację współtworzy ponad dwudziestu praktyków biznesu i technologii. Łączymy w niej 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 i technologii przemysłu 5.0; wreszcie lekcje liderów oraz drogę od diagnozy do działania. Różne doświadczenia nie składają się na jeden model do skopiowania. Pomagają natomiast zobaczyć zależności, które umykają, gdy patrzymy na transformację wyłącznie przez własny obszar odpowiedzialności.

To książka o technologii, ale jej głównym tematem jest odpowiedzialność za zmianę. Za decyzje podejmowane przy niepełnych danych, za kompromisy między tempem a bezpieczeństwem i za ludzi, którzy mają przebudowywać firmę, nie zatrzymując jej codziennego działania.

Transformacja nie rozstrzyga się podczas demonstracji ani w dniu podpisania protokołu odbioru. Rozstrzyga się w poniedziałek rano, kiedy trzeba zrezygnować ze zbędnej akceptacji, przekazać komuś prawo do decyzji albo wyłączyć stary proces, choć przez lata dawał poczucie kontroli.

Dlatego przed kolejną inwestycją warto zapytać nie tylko „jaką technologię kupujemy?”, lecz także „jaką zdolność firmy dzięki niej budujemy?”. A zaraz potem zadać trudniejsze pytanie: „co jesteśmy gotowi zmienić we własnym sposobie zarządzania, żeby ta zdolność rzeczywiście powstała?”.

Agnieszka Bochacka, Global Digital Transformation Director – Product Managment, GE HealthCare

Robert Pławiak, CTO / CAIO, ProService Finteco

Cyfrowa transformacja nie potrzebuje kolejnego pilotażu, ale decyzji

Premiera książki „Cyfrowa Transformacja. AI · Dane · Ludzie”, autorstwa i pod redakcją merytoryczną Agnieszki Bochackiej i Roberta Pławiaka, odbędzie się 4 listopada 2026 roku. Publikację współtworzy ponad dwudziestu praktyków biznesu i technologii.

Dla czytelników ITwiz autorzy przygotowali 10% rabatu na zakup książki. Kod ITWIZ100 obowiązuje do 15 października 2026 roku; szczegóły książki i przedsprzedaż są dostępne na stronie cyfrowatransformacja.com.pl.

Tagi

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *