Spis treści
Efektywność IT warto poprawiać przez wspólne z biznesem ustalanie celów, jasną odpowiedzialność i skracanie oczekiwania między etapami pracy. Proponuję siedem zmian, z których warto wybrać te odpowiadające na problemy organizacji — bez zakładania, że potrzebna jest reorganizacja całego działu.
Wyobraź sobie hipotetyczną zmianę w systemie: wymaga uzgodnień z kilkoma działami, zatwierdzenia przez trzy osoby, konsultacji z zespołem bezpieczeństwa i oczekiwania na komitet zmian. Samo wdrożenie zajmuje dwie godziny, ale cały proces trwa trzy tygodnie.
Jeśli decyzja zajmuje więcej czasu niż rozwiązanie problemu, warto przyjrzeć się organizacji pracy. Nawet dobrzy specjaliści tracą czas na zbędne uzgodnienia, wielokrotne raportowanie tych samych informacji czy realizację zadań, których wartości biznesowej nikt wcześniej nie określił.
Od lat śledzę, jak zmienia się rola IT w organizacjach. Uważam, że jednym z ważniejszych wyzwań dla dyrektora IT jest stworzenie warunków, w których zespoły technologiczne skutecznie współpracują z biznesem i wspólnie z nim odpowiadają za rezultaty.
Inspiracją do tych propozycji są moje doświadczenia i obserwacje, zasady ITIL 4, podejście Lean oraz wypowiedzi liderów technologicznych. Punktem wyjścia do tekstu był również artykuł Johna Edwardsa w CIO z 22 września 2026 roku. Rozwijam tutaj własne rekomendacje; nie jest to jednolita metodyka narzucona przez ITIL lub Lean.
Mierz wartość dla biznesu
Liczba zrealizowanych zgłoszeń, zakończonych projektów i wdrożonych funkcji pomaga kontrolować pracę IT. Nie odpowiada jednak na pytanie, czy ta praca poprawia funkcjonowanie przedsiębiorstwa.
Możemy zakończyć projekt zgodnie z harmonogramem i budżetem, a mimo to nie osiągnąć zakładanego rezultatu. Możemy też wdrożyć system, z którego pracownicy nie chcą korzystać, ponieważ nie rozwiązuje ich problemów.
W ITIL 4 zasada Focus on Value przypomina o wartości dla odbiorcy usług. Lean również zaczyna od zrozumienia wartości z perspektywy klienta.
Zamiast rozpoczynać rozmowę od pytania: „Jakie rozwiązanie mamy wdrożyć?”, proponuję zapytać: „Jaki problem chcemy rozwiązać i po czym poznamy, że osiągnęliśmy sukces?”.
Jeśli sprzedaż zgłasza potrzebę nowego narzędzia do raportowania, najpierw warto zrozumieć, dlaczego jest potrzebne. Czy proces działa? Czy można ufać obecnym danym? Ile czasu zajmuje przygotowanie raportów i jakie decyzje mają być na ich podstawie podejmowane?
Może się okazać, że zamiast nowego systemu wystarczy poprawić integrację istniejących rozwiązań, zoptymalizować wydajność obecnego systemu albo zautomatyzować jeden etap procesu. Być może trzeba też usunąć niespójności w danych i uzgodnić jedno źródło informacji.
Takie podejście stosuje już wiele organizacji, ale widzę wciąż takie, które oceniają IT przede wszystkim przez liczbę wykonanych zadań i uruchomionych systemów. Rzadziej sprawdzają ich wpływ na wyniki firmy. IT pozostaje wtedy kosztem, choć mogłoby uczestniczyć w budowaniu przewagi konkurencyjnej.
Co proponuję zmienić? Dla każdej większej inicjatywy określ wspólnie z biznesem oczekiwany rezultat, właściciela biznesowego i sposób oceny efektów. Dobierz mierniki do problemu: czas pracy ludzi, koszty, przychody, ryzyko lub doświadczenie klientów. Najpierw ustal punkt odniesienia; szacunków nie przedstawiaj jako uzyskanych wyników.
IT staje się partnerem wtedy, gdy potrafi wyjaśnić, co zmieniło się w firmie dzięki jego pracy. Inne obszary organizacji również muszą być gotowe do takiej rozmowy.
Decyzje i odpowiedzialność
Ograniczeniem bywa czas oczekiwania na rozpoczęcie pracy. Zadanie przechodzi przez analityka, architekta, bezpieczeństwo, kierownika projektu i kolejne osoby zatwierdzające zmianę. Każdy analizuje fragment, a odpowiedzialność za całość rozmywa się między działami. W innym przypadku IT ma gotową listę zadań, ale czeka na decyzję biznesu o priorytetach.
Kontrole bezpieczeństwa, ryzyka i zgodności są potrzebne. Problem pojawia się wtedy, gdy każda decyzja, niezależnie od jej znaczenia, wymaga podobnie rozbudowanej ścieżki zatwierdzania.
Przyjrzałbym się temu, kto powinien podejmować poszczególne decyzje. Dla powtarzalnych zmian o niskim ryzyku można uzgodnić i zatwierdzić sposób postępowania z wyprzedzeniem, wraz z warunkami jego stosowania. Decyzje o dużym wpływie biznesowym, kosztowym lub bezpieczeństwa nadal wymagają odpowiedniej kontroli.
PeopleCert opisuje Change Enablement w ITIL 4 jako praktykę wspierającą kontrolowane zmiany, ograniczanie ryzyka i ciągłość działania. Konkretne uprawnienia i ścieżki zatwierdzania trzeba ustalić dla własnej organizacji.
Warto wskazać właściciela decyzji oraz określić, kto powinien zostać skonsultowany, a kto poinformowany. Kilka osób współodpowiedzialnych bez prawa do rozstrzygnięcia sprawy to przepis na kolejną kolejkę.
Co proponuję zmienić? Wybierz kilka częstych procesów IT i zmierz czas pracy oraz oczekiwania na decyzje. Usuń zbędne etapy i przekaż uprawnienia możliwie blisko osób odpowiedzialnych za realizację, zachowując kontrolę ryzyka i zapis decyzji.
W hipotetycznej sytuacji, w której wykonanie zadania zajmuje dwie godziny, a zatwierdzenie dwa tygodnie, od procesu decyzyjnego rozpocząłbym poszukiwanie usprawnień.
Praca wokół procesów biznesowych
Tradycyjna struktura IT odzwierciedla technologie lub specjalizacje: infrastrukturę, sieci, aplikacje, bazy danych, bezpieczeństwo, wsparcie i rozwój oprogramowania. Taki podział ułatwia budowanie kompetencji eksperckich, zarządzanie standardami i utrzymanie jakości usług.
Trudność pojawia się, gdy jeden cel biznesowy wymaga współpracy wielu zespołów o różnych priorytetach. Usprawnienie obsługi zamówień może wymagać zmian w aplikacji sprzedażowej, integracjach, bazie danych i infrastrukturze. Niewielka zmiana staje się wtedy przedsięwzięciem organizacyjnym.
Jedną z opcji jest organizowanie części pracy wokół produktów, zdolności biznesowych lub strumieni wartości. Zespół interdyscyplinarny zajmuje się określonym obszarem, np. obsługą klienta czy rozliczeniami. Współpracują w nim specjaliści IT i przedstawiciele biznesu, z odpowiedzialnością za rozwój, utrzymanie i ocenę efektów.
Nie trzeba likwidować zespołów specjalistycznych. W mojej ocenie często praktyczny jest model hybrydowy: zespoły produktowe korzystają z centralnych kompetencji i wspólnych platform. Analiza McKinsey z 28 lutego 2020 roku opisuje taki podział oraz możliwość czasowego dołączania ekspertów platformowych do zespołów produktowych.
Czy dwa procesy potrzebujące inżyniera sieci lub programisty oznaczają dwa etaty? Nie. Jeśli dwa zespoły potrzebują programisty Python okresowo, mogą korzystać ze wspólnego specjalisty, pod warunkiem uzgodnienia priorytetów i dostępności. Stałe przypisanie ma większy sens, gdy kompetencja jest potrzebna w codziennej pracy, a oczekiwanie na nią opóźnia realizację celu.
Sam udział kilku zespołów w procesie nie przesądza o potrzebie reorganizacji. Porównaj zapotrzebowanie na kompetencje i koszt zespołu z kosztami oczekiwania oraz koordynacji. Oceniaj również wpływ dostępności specjalisty na pracę pozostałych osób, nie tylko jego indywidualne obłożenie.
Co proponuję zmienić? Wybierz ważny proces i sprawdź, które zespoły uczestniczą w jego rozwoju i utrzymaniu oraz gdzie pojawiają się opóźnienia. Ustal wspólny cel, priorytety i odpowiedzialność. Dopiero potem oceń, czy potrzebny jest stały zespół interdyscyplinarny, czy wystarczy usprawnić współpracę istniejących zespołów.
Usprawnij przepływ pracy
W IT marnotrawstwo może być trudne do dostrzeżenia. Nie musi oznaczać niepotrzebnych licencji czy niewykorzystanej infrastruktury. Może chodzić o spotkania powtarzające informacje z systemu zgłoszeń, kilka wersji tego samego raportu, ciągłe przełączanie zadań albo wielokrotne przekazywanie incydentu między zespołami.
Rozpoczynanie wielu inicjatyw jednocześnie również może wydłużać kolejki. Większe obciążenie ludzi nie musi przekładać się na więcej ukończonych prac.
Pomocne jest Value Stream Mapping, czyli mapowanie strumienia wartości. Analizujemy cały przepływ pracy i informacji potrzebny do dostarczenia rezultatu, a następnie projektujemy usprawnienia. W IT może to być droga od zgłoszenia potrzeby do wykorzystania rozwiązania w procesie biznesowym.
Ważny jest zarówno czas wykonywania czynności, jak i przerwy między nimi. Zgłoszenie czeka na doprecyzowanie wymagań, propozycja rozwiązania na zatwierdzenie, a programista na dostęp do środowiska lub dane od innego zespołu. Nowa wersja systemu nie może zostać wdrożona, ponieważ użytkownicy kluczowi nie zakończyli testów i odbioru zmian.
Czekamy także na odpowiedź dostawcy, okno wdrożeniowe lub przejęcie zadania przez kolejny zespół. Zadanie pozostaje otwarte, choć nikt aktualnie nad nim nie pracuje.
W hipotetycznym przykładzie przygotowanie zmiany zajmuje jeden dzień, testy kolejny, a wdrożenie kilka godzin. Cały proces trwa jednak miesiąc, ponieważ zadanie większość czasu spędza w kolejce. Przy mapowaniu sprawdziłbym, które przerwy są uzasadnione kontrolą ryzyka lub potrzebami operacyjnymi, które można skrócić, a które usunąć.
Co proponuję zmienić? Przeanalizuj jeden proces powodujący opóźnienia. Oznacz etapy oczekiwania, zbędne przekazania i powtarzane czynności. Uzgodnij też limit równolegle realizowanych zadań, aby zespoły mogły kończyć rozpoczęte prace.
Zamiast pytać ludzi, jak mogą pracować szybciej, zapytałbym, co przeszkadza im w sprawnym wykonywaniu obowiązków.
Prostsze IT i automatyzacja
Kolejne projekty wprowadzają nowe aplikacje i narzędzia. Część powstaje poza uzgodnionym nadzorem IT — to tzw. shadow IT. Po latach firma może mieć kilka systemów o podobnych funkcjach, wiele kanałów komunikacji i niezależne repozytoria wiedzy.
Różnorodność nie zawsze wynika z potrzeb biznesowych. Bywa skutkiem historycznych decyzji i lokalnych preferencji. Rosną wtedy koszty utrzymania, liczba integracji i złożoność środowiska.
Przed zakupem narzędzia sprawdź, czy posiadane rozwiązanie nie pozwala osiągnąć tego samego celu. Zasada ITIL 4 Start Where You Are przypomina o ocenie istniejących zasobów przed wyborem zmian.
Nie jestem zwolennikiem automatyzowania wszystkiego, na co pozwala technologia. Automatyzacja źle zaprojektowanego procesu może przyspieszyć powstawanie błędów i utrwalić nieefektywny sposób pracy. Najpierw warto uporządkować proces, a potem ocenić jego automatyzację.
Kandydatami są powtarzalne, przewidywalne czynności: zakładanie kont, nadawanie standardowych uprawnień, przygotowanie środowisk, rutynowe zmiany czy raporty. Automatyzacja powinna zachować wymagane zatwierdzenia i możliwość kontroli.
AI można rozważyć przy analizie zgłoszeń, wyszukiwaniu wiedzy, diagnostyce czy przygotowaniu dokumentacji. Przydatność oceń na wybranych zadaniach: jakość wyniku, błędy, czas weryfikacji i zasady dostępu do danych mogą przesądzić o korzyści.
Własne materiały Walmartu opisują wspólną podstawę technologiczną pozostawiającą miejsce na lokalne różnice. To przykład kierunku upraszczania, nie dowód, że identyczne rozwiązanie sprawdzi się w każdej jednostce.
Co proponuję zmienić? Przejrzyj narzędzia: kto ich używa, do czego i które funkcje się dublują? Oceń konsolidację lub wycofanie zbędnych rozwiązań. Równolegle przygotuj arkusz kandydatów do automatyzacji: właściciel procesu, wymagane warunki, częstotliwość, złożoność, szacowany koszt wdrożenia i utrzymania oraz oczekiwane korzyści. Zapisz założenia i później porównaj je z wynikiem.
Przy ocenie finansowej może pomóc kalkulator ROI wdrożenia AI. Sam szacunek zwrotu nie zastępuje oceny jakości i ryzyka.
Bezpieczeństwo od początku
Gdy gotowa aplikacja trafia dopiero na końcu do ekspertów bezpieczeństwa lub architektury, uwagi mogą wymagać poprawek, ponownych testów, a nawet zmiany koncepcji. To ryzyko opóźnień i kosztów.
Wymagania bezpieczeństwa, architektury i zarządzania danymi warto uwzględnić już podczas projektowania. Potrzebna jest współpraca specjalistów, wspólne standardy oraz gotowe komponenty, które spełniają uzgodnione wymagania.
Takie podejście jest zbieżne z DevSecOps, czyli włączeniem bezpieczeństwa do rozwoju i utrzymania oprogramowania. NIST opisuje jego uwzględnianie od najwcześniejszych etapów cyklu życia.
W rozmowie opublikowanej przez CIO Jeremy Koppen, przedstawiony jako CISO Equifax, mówi o bezpieczeństwie wspierającym tempo rozwoju. Według jego relacji zespoły wspierały bezpieczne wprowadzenie ponad 180 innowacji produktowych w 2025 roku. To wypowiedź przedstawiciela firmy, a nie niezależny pomiar wpływu modelu organizacyjnego na ten wynik.
Zespołu bezpieczeństwa nie oceniałbym wyłącznie przez liczbę wykrytych niezgodności, a architektów przez egzekwowanie standardów. Ich zadaniem jest również pomoc w osiąganiu celów biznesowych przy uzgodnionym poziomie ryzyka.
Co proponuję zmienić? Włącz te kompetencje do planowania ważnych inicjatyw. Zdefiniuj wzorce rozwiązań, automatyzuj kontrole tam, gdzie ma to sens, i ustal zasady oceny wyjątków. Wcześniejsze rozpoznanie wymagań i ryzyk może ograniczyć poprawki pod koniec projektu.
Wspólne rozwiązywanie problemów
Ta zmiana jest dla mnie najważniejsza, ponieważ dotyczy sposobu myślenia o roli obu stron.
W wielu firmach relacja przypomina współpracę zamawiającego z dostawcą. Biznes przygotowuje wymagania, a IT wycenia, planuje i realizuje zadanie. Po wdrożeniu odpowiedzialność za wykorzystanie rozwiązania wraca do jednostki biznesowej. Taki model może wystarczyć przy prostych usługach, ale ogranicza wspólne poszukiwanie usprawnień.
Spotkałem się również z kilkoma organizacjami, w których odpowiedzialność za wykorzystanie ERP przez biznes przeniesiono w pełni na IT. To IT organizowało szkolenia stanowiskowe i testowało zmiany, a użytkownicy i ich przełożeni nie czuli się odpowiedzialni za narzędzia, z których korzystali.
Szkolenia i wsparcie są potrzebne, ale nie zastępują odpowiedzialności właścicieli procesów. IT może pomóc wdrożyć rozwiązanie i przygotować użytkowników. Biznes powinien określić problemy i potrzeby, uczestniczyć w odbiorze zmian oraz zadbać o wykorzystanie systemu w pracy. Partnerstwo wymaga zaangażowania obu stron.
IT powinno uczestniczyć w rozmowie, zanim zapadnie decyzja o konkretnym rozwiązaniu. Jeśli obsługa klienta chce zatrudnić dodatkowych pracowników z powodu rosnącej liczby zgłoszeń, warto wspólnie przeanalizować przyczyny. Być może problemem są brak integracji, nieczytelny interfejs lub ręczne przepisywanie danych. To przykład możliwej diagnozy, nie argument przeciw zatrudnianiu ludzi.
Przykładem zmiany modelu jest Tungsten Automation. Według rozmowy z Shelley Seewald opublikowanej przez CIO 4 maja 2026 roku zespoły dostarczające rozwiązania powiązano z obszarami biznesowymi, takimi jak sprzedaż, marketing, obsługa klienta i finanse. To opis podejścia; nie przytaczam zmierzonych korzyści tej reorganizacji.
Dostawca koncentruje się na realizacji zamówienia. Partner rozumie problem, wspólnie poszukuje rozwiązania, pomaga ustalać priorytety i bierze współodpowiedzialność za rezultat. Biznes również powinien być partnerem dla IT: wyjaśniać cel, wskazywać właściciela procesu i zapewniać czas osób potrzebnych do decyzji, testów oraz wdrożenia zmiany w codziennej pracy.
Przy rozpoczynaniu inicjatywy uzgodnijcie, za co odpowiada każda strona i jak ocenicie korzyści. Odbiór techniczny nie kończy współpracy. Sprawdźcie wykorzystanie rozwiązania oraz efekt. Hipotetycznym celem może być skrócenie średniego czasu obsługi zgłoszeń w biurze obsługi klienta o 10% względem uzgodnionego poziomu bazowego, przy zachowaniu jakości obsługi. To przykład celu, nie mój wynik ani prognoza.
Jeśli nowa potrzeba ma być pilna, biznes musi uczestniczyć w wyborze priorytetów i zaakceptować, które zadania zostaną odłożone.
Co proponuję zmienić? Wprowadź regularne rozmowy liderów IT i biznesu o celach, problemach, kosztach, ryzykach i możliwościach rozwoju. Wyjdź poza statusy projektów. Zadbaj, aby osoby z IT znały procesy, które wspierają, a osoby z biznesu uczestniczyły w decyzjach i ocenie efektów.
Relacji partnerskiej nie zbuduje sama zmiana nazwy stanowiska czy powołanie zespołu. Powstaje wtedy, gdy biznes widzi w IT uczestnika podejmowania decyzji, a IT rozumie cele i ograniczenia biznesu. Obie strony wspólnie ustalają priorytety i dzielą odpowiedzialność za rezultaty.
Od czego zacząć transformację IT?
Nie uważam, że skuteczna transformacja musi zaczynać się od dużej reorganizacji, nowych etatów czy kolejnej platformy.
Często lepsze jest rozpoczęcie od kilku niewielkich, dobrze przemyślanych zmian. Siedem propozycji może być punktem wyjścia dla organizacji o różnej skali i strukturze. Wybierz jedną lub dwie odpowiadające na jej rzeczywiste problemy.
Proponuję zacząć od jednego procesu: przeanalizować przepływ pracy, określić odpowiedzialność, uprościć decyzje i ustalić wspólne mierniki. Sprawdź wynik, zanim rozszerzysz podejście. To odpowiada zasadzie ITIL 4 Progress Iteratively with Feedback — stopniowemu doskonaleniu na podstawie informacji zwrotnych.
Zależy mi, aby po lekturze zostało przekonanie, że IT i biznes mogą współpracować inaczej, a pierwszy krok jest możliwy również we własnej organizacji. Warto przy tym zachować kompetencje eksperckie, standardy bezpieczeństwa i stabilność usług, które już działają dobrze.
Siedem zmian i ich efekty
Poniższa tabela przedstawia kierunki usprawnień i oczekiwane efekty, nie zmierzone wyniki ani gwarancję korzyści. Sposób pomiaru trzeba dopasować do wybranego procesu.
| Zmiana | Oczekiwany efekt | Co sprawdzić w wybranym procesie |
|---|---|---|
| 1. Mierzenie wartości biznesowej | Trafniejsze inwestycje i koncentracja na rezultacie | Wynik biznesowy względem punktu odniesienia |
| 2. Jasne decyzje i odpowiedzialność | Krótsze oczekiwanie na decyzje | Czas oczekiwania i liczba ponownych zatwierdzeń |
| 3. Wspólny cel wokół procesu | Mniej konfliktów między zespołami | Opóźnienia na styku zespołów i dostępność kompetencji |
| 4. Usprawnienie przepływu pracy | Sprawniejsze kończenie zadań | Czas od potrzeby do rezultatu i liczba zadań w toku |
| 5. Upraszczanie i automatyzacja | Mniej powielonych narzędzi i ręcznej pracy | Koszt utrzymania, czas pracy i błędy |
| 6. Wczesne bezpieczeństwo i architektura | Mniej poprawek przed wdrożeniem | Poprawki wynikające z późno rozpoznanych wymagań |
| 7. Partnerstwo obu stron | Wspólne priorytety i odpowiedzialność | Udział biznesu w decyzjach, odbiorze i ocenie korzyści |
Źródła i charakter materiału
To moje rekomendacje oparte na doświadczeniu, obserwacjach i poniższych materiałach. Przykłady liczbowe są hipotetyczne; relacje innych firm mają wskazane źródła i nie stanowią obietnicy podobnych efektów. W tekście odwołuję się do zasad ITIL 4, bez przedstawiania ich jako najnowszej wersji ITIL.
PeopleCert: ITIL 4 Guiding Principles — materiał Roadshow 2024, slajd oznaczony 16, z siedmioma zasadami.
PeopleCert: Create, Deliver and Support oraz Change Enablement — publiczne opisy zakresu praktyk; nie pełne podręczniki.
Lean Enterprise Institute: What is Lean? oraz Value Stream Mapping — wartość, przepływ pracy i mapowanie stanu obecnego oraz docelowego.
McKinsey: Products and platforms, 28 lutego 2020 — model produktowo-platformowy. Nie wykorzystuję statystyk z badania jako danych o obecnym rynku.
NIST/NCCoE: DevSecOps Practices — Introduction — materiał rozwijany na bieżąco, wydanie z września 2026, dotyczący bezpieczeństwa w cyklu życia oprogramowania.
CIO: 7 ways to restructure IT for maximum productivity, John Edwards, 22 września 2026 — inspiracja i wypowiedź Jeremy’ego Koppena.
CIO: CIOs rethink IT’s operating model, Mary K. Pratt, 4 maja 2026 — relacja Shelley Seewald o Tungsten Automation.
Walmart Global Tech: A Conversation with John Furner and Suresh Kumar, 24 kwietnia 2026 — tekst o wspólnej podstawie technologicznej i lokalnych różnicach.
O autorze
Rafał Mokrowiecki. Mam ponad 20 lat doświadczenia w IT, od programowania ERP do stanowiska dyrektora IT. Obecnie jestem niezależnym doradcą IT. Zobacz moje doświadczenie i zakres odpowiedzialności.
Który proces najbardziej utrudnia współpracę biznesu z IT? Napisz, gdzie pojawiają się opóźnienia i kto uczestniczy w decyzjach. To punkt wyjścia do rozmowy o zakresie wsparcia dla firm.
