Pierwsze 100 dni dyrektora IT

W roli dyrektora IT odpowiadałem za systemy, infrastrukturę, sieć i bezpieczeństwo, a także za zespół, budżet i dostawców. Pracowałem bezpośrednio z zarządem.

Moje działania obejmowały audyt, plan rozwoju uzgodniony z zarządem, negocjowanie budżetu, polityki bezpieczeństwa, helpdesk, dokumentację i szkolenie zespołu.

Na tym doświadczeniu opieram propozycję poniżej: jakie ustalenia wypracować na początku nowej roli i po czym ocenić postęp.

Pierwsze ustalenie z przełożonym dotyczy wyniku, za który odpowiadam, i moich uprawnień. Sam zakres „zarządzanie IT” pozostawia zbyt wiele miejsca na odmienne oczekiwania.

Proponuję zapisać odpowiedzi na kilka konkretnych pytań:

• Które decyzje podejmuję samodzielnie, a które wymagają zgody zarządu?

• Kto rozstrzyga konflikt priorytetów między działami?

• Kto może zaakceptować ryzyko pozostawienia istotnego problemu bez rozwiązania?

• Jakie decyzje dotyczące wydatków, dostawców i zespołu mieszczą się w moim mandacie?

• Jakich rezultatów oczekuje przełożony i kiedy wspólnie ocenimy postęp?

Efektem tej rozmowy powinien być krótki zapis odpowiedzialności, granic decyzji i zasad eskalacji. Wstępne ustalenie powinno umożliwiać działanie od początku. Po rozpoznaniu sytuacji proponuję je doprecyzować, zwłaszcza gdy oczekiwania okażą się szersze niż dostępne zasoby.

W proponowanym planie rozdzielam dwa obszary.

Pierwszy to zabezpieczenie ciągłości działania. Proponuję sprawdzić, które usługi są krytyczne dla firmy, kto za nie odpowiada, jakie mamy dowody możliwości ich odtworzenia oraz gdzie występują zależności od jednej osoby lub dostawcy. Rezultatem powinno być wskazanie pilnych działań, odpowiedzialnych osób i ryzyk wymagających decyzji.

Drugi obszar to nowe inicjatywy: rozwój systemów, automatyzacja, integracje czy wymiana rozwiązań. Każda propozycja powinna mieć nazwany problem biznesowy, właściciela wyniku, oczekiwany efekt oraz zapotrzebowanie na pieniądze i czas ludzi.

W budżecie proponuję osobno pokazać utrzymanie usług, działania ograniczające ryzyko i rozwój. Dopiero wtedy zarząd może świadomie zdecydować, co finansuje, co odracza i jakie konsekwencje przyjmuje.

Jeśli te same osoby mają jednocześnie utrzymywać krytyczne systemy i prowadzić nowe wdrożenie, potrzebna jest decyzja o ich dostępności. Samo wpisanie projektu do planu nie tworzy dodatkowych zdolności wykonawczych.

O powiązaniu celów firmy z wyborem priorytetów piszę w artykule Od celu biznesowego do priorytetu IT.

Przedziały dni w planie są orientacyjne i częściowo się nakładają. Pilne ryzyko wymaga decyzji od razu; duże wdrożenia mogą wykraczać poza tę ramę.

„Właściciel” oznacza odpowiedzialnego za doprowadzenie do wskazanego ustalenia lub decyzji; nie musi sam wykonywać wszystkich prac. Mierniki są propozycjami do uzgodnienia po ustaleniu stanu początkowego.

Przy każdym mierniku potrzebne są źródło danych, częstotliwość przeglądu i osoba odpowiedzialna za raportowanie. Dla testów odtworzenia trzeba również uzgodnić ich zakres, kryteria powodzenia i aktualność dowodu. Dla udziałów procentowych trzeba zachować jawny zakres: co dokładnie znajduje się w mianowniku i czy zmienił się on od poprzedniego pomiaru.

Brak wiarygodnych danych początkowych powinien być widoczny. Nie pozwala uczciwie obiecać określonego spadku incydentów ani procentowych oszczędności.

Efektem rozmów z zespołem powinna być mapa odpowiedzialności: kto utrzymuje daną usługę, kto może go zastąpić i gdzie potrzebujemy dokumentacji lub szkolenia. Jeżeli istotna wiedza pozostaje u jednej osoby, ustaleniem powinien być konkretny zakres jej przekazania i sposób sprawdzenia, czy zastępstwo jest możliwe.

Z rozmów z biznesem powinna powstać uzgodniona kolejność problemów do rozwiązania. Przy każdym problemie potrzebuję określenia wpływu na działalność, właściciela procesu i warunku, po którym uznamy, że nastąpiła poprawa.

Takie ustalenia pozwalają ocenić, czy lider słucha i przekłada rozpoznanie na decyzje. Sama liczba spotkań niewiele o tym mówi.

W ocenie pierwszych miesięcy proponuję precyzyjnie nazywać stopień zaawansowania prac.

Helpdesk uznałbym za uruchomiony, gdy działa uzgodniony kanał zgłoszeń, przypisano odpowiedzialność, określono zasady priorytetyzacji i można prześledzić obsługę rzeczywistych spraw. To jeszcze nie dowodzi poprawy jakości wsparcia. Tę ocenę oparłbym na danych z uzgodnionego okresu oraz informacjach od użytkowników.

Podobnie przyjęcie polityki bezpieczeństwa potwierdza decyzję o zasadach. Ich stosowanie wymaga osobnych dowodów, na przykład sprawdzenia wybranych przypadków i obsługi wyjątków.

Przy dużym wdrożeniu wynikiem pierwszych 100 dni mogą być uzgodnione wymagania, sponsor, finansowanie, plan i zakończony etap przygotowawczy. Zakończenie całego wdrożenia wymaga spełnienia kryteriów odbioru, w tym gotowości użytkowników i przekazania rozwiązania do utrzymania. Status „projekt rozpoczęty” powinien pozostać odróżniony od statusu „rozwiązanie odebrane”.

Nie czekałbym na koniec audytu, gdy rozpoznany problem wymaga decyzji wykraczającej poza mandat dyrektora IT. W proponowanym podejściu dotyczy to zwłaszcza sytuacji, w których:

• zagrożona jest ciągłość krytycznej działalności, a zabezpieczenie wymaga dodatkowych środków, przestoju lub akceptacji ryzyka;

• oczekiwany termin lub zakres prac przekracza dostępność zespołu i budżet;

• działy zgłaszają sprzeczne priorytety, których nie da się rozstrzygnąć w ramach uzgodnionych uprawnień;

• istotny problem pozostaje bez właściciela biznesowego albo wymaga zmiany wcześniejszej decyzji zarządu.

Eskalację przygotowałbym jako materiał do decyzji: co wiemy, czego jeszcze nie wiemy, jaki jest możliwy wpływ na firmę, jakie mamy opcje, co rekomenduję i do kiedy potrzebne jest rozstrzygnięcie. Wskazałbym też skutek braku decyzji.

W przypadku trwającego incydentu eskalację prowadziłbym równolegle z działaniami zabezpieczającymi mieszczącymi się w moich uprawnieniach.

Celem pierwszych 100 dni jest przedstawienie zarządowi spójnego obrazu: znamy najważniejsze ryzyka, mamy uzgodnione priorytety i finansowanie, odpowiedzialność jest przypisana, a postęp można sprawdzić. Przy nierozwiązanych problemach wiadomo, co je blokuje i kto ma podjąć kolejną decyzję.

Dla przyszłego przełożonego byłby to dowód, że lider potrafi połączyć rozpoznanie techniczne z odpowiedzialnością za działanie firmy. Dla headhuntera — konkretna podstawa do rozmowy o zakresie roli, decyzjach i sposobie współpracy z zarządem.

O autorze: Rafał Mokrowiecki ma ponad 20 lat doświadczenia w IT, od programowania ERP po zarządzanie zespołem i budżetem. Od października 2024 do września 2025 pełnił funkcję dyrektora IT. Od października 2025 działa jako niezależny doradca IT.

Zapraszam do rozmowy o zakresie stałej roli lidera IT — mandacie, odpowiedzialności i oczekiwaniach wobec pierwszych miesięcy pracy, szczególnie w firmie produkcyjnej.

Podstawa tekstu: doświadczenie zawodowe autora i proponowany plan rozpoczęcia nowej roli.