Jak sprawdzić już w styczniu, czy plan na rok w firmie jest realny?

Jest koniec stycznia i w wielu firmach już teraz widać, czy plan na ten rok w ogóle ma szansę się wydarzyć. Pierwsze decyzje zaczęły rozmijać się z realnymi możliwościami zespołów. Jeśli w tym momencie plan zaczyna się korygować, przesuwać albo tłumaczyć bieżącymi sprawami, to bardzo często oznacza jedno. Ten plan nigdy nie był realny. I w poprzednim odcinku podcastu mówiłem o tym, dlaczego większość planów i projektów nie wychodzi. A dzisiaj chciałbym wrócić do tego tematu, ale z zupełnie innej perspektywy, z perspektywy IT i opowiedzieć o tym, jak zaplanować rok w firmie tak, żeby ten plan i projekty informatyczne faktycznie udało się zrealizować. Jeśli masz plan na ten rok, to ten odcinek pomoże ci sprawdzić, czy on naprawdę ma sens. Zostań do końca, a jeśli chcesz więcej takiego spojrzenia na IT i biznes, koniecznie zasubskrybuj nasz kanał. Kanał IT i biznes prowadzi firma Innovation. Rozwiązania technologiczne dopasowane do twojego biznesu ze wsparciem zewnętrznego dyrektora IT. Zapraszam, Grzegorz Tabor. Dobra, lecimy z konkretem.

Dlaczego plan roczny w IT powinien zaczynać się od rezygnacji, a nie od nowych inicjatyw?

Pierwsza rzecz. To, co trzeba zmienić, to sposób myślenia o planie rocznym. W IT szczególnie widać, jak często plan zamienia się w listę inicjatyw, nowy system, nowe integracje, automatyzację, modernizację infrastruktury, rozwój zespołu, bezpieczeństwo, dane, AI. Ale plan, który zawiera wyłącznie odpowiedzi na pytania, co jeszcze trzeba by było zrobić, to bardzo życzeniowy plan, który nigdy się nie uda. Dojrzałe planowanie zaczyna się od innego pytania. Z czego świadomie rezygnujemy w danym roku? Bo każda nowa inicjatywa technologiczna to dodatkowa złożoność, nowe zależności, większe ryzyko, większe obciążenie zespołu nie tylko technicznego, który musi to wszystko utrzymać. Dlatego zamiast jednej listy projektów dużo lepiej myśleć o planie jako o takiej strukturze warstwowej. Pierwsza warstwa to fundamenty technologiczne. Rzeczy, które muszą działać niezależnie od tego, co się wydarzy w ciągu roku. Stabilność systemów, bezpieczeństwo, dostępność i jakość danych, ciągłość działania. Jeżeli te elementy nie są zabezpieczone, każda inicjatywa rozwojowa może wpłynąć na stabilność tego, co już mamy. Druga warstwa to inicjatywy ważne, ale zależne od tego, jak potoczy się rok. Rozbudowy systemów, nowe integracje, usprawnienia procesów. One mają sens wtedy, gdy fundamenty działają stabilnie i nie trzeba cały czas wracać do gaszenia pożarów. Trzecia warstwa to obszary rozwojowe i eksperymentalne. Pilotaże, testy nowych technologii, prototypy rozwiązań. To rzeczy, które warto mieć w planie, ale które nie powinny być warunkiem powodzenia całego roku. Bardzo często już na etapie planu próbujemy odpowiedzieć nie tylko na pytanie, co chcemy osiągnąć, ale też dokładnie, jak to zrobimy. A to są tak naprawdę dwie różne rzeczy. Plan roczny powinien wyznaczać cele, ale nie powinien z góry definiować metod ich realizacji. Jeżeli celem jest zmiana lub wdrożenie nowego systemu, to plan nie powinien od razu przesądzać, czy budujemy rozwiązanie dedykowane, czy wybieramy gotowy system, czy idziemy w model hybrydowy.

Architektura IT i przepustowość zespołu: analiza wpływu projektu, ryzyka i model realizacji

To samo dotyczy architektury IT. Zanim podejmiemy decyzje technologiczne, trzeba zrozumieć, jak planowany projekt wpłynie na cały ekosystem. Na jego wydajność, na integrację, na dane, na bezpieczeństwo. Dlatego etap analizy powinien być uwzględniony w planie, żeby ocenić ryzyka, wąski gardła i wpływ planowanych zmian na to, co już w organizacji działa. Każdy plan IT musi uwzględniać przepustowość zespołu. Nie tylko w sensie liczby godzin, ale też w sensie odpowiedzialności i koncentracji. Dlaczego to ważne, wspominałem w poprzednim odcinku. Zespoły in-house bardzo często są odpowiedzialne za rzeczy krytyczne. Za utrzymanie systemów, za reagowanie na incydenty, za wsparcie biznesu w bieżących działaniach. To oznacza, że nawet jeśli na papierze mają wolne moce przerobowe, w praktyce ich dostępność jest zmienna i trudna do przewidzenia. I właśnie w tym momencie pojawia się pytanie o sposób realizacji planu. Co robimy własnymi siłami, a gdzie świadomie rozważamy inne scenariusze realizacji. Zespół wewnętrzny najlepiej zna architekturę, dane i procesy firmy. Ale to nie oznacza, że powinny realizować wszystkie inicjatywy rozwojowe równolegle z utrzymaniem bieżącego działania. Plan IT musi uwzględniać realne ograniczenia i możliwości zespołów, tak żeby już na etapie planowania było jasne, ile jesteśmy w stanie faktycznie zrealizować. I dopiero wtedy odpowiedzieć sobie na pytanie, czy to tempo jest wystarczające z perspektywy biznesu. Jeżeli nie, plan także powinien to uwzględniać. Nie przez dokładanie kolejnych zadań, ale przez rozważenie różnych dróg dojścia do celu.

Roadmapa IT i żywy plan roczny - jak podejmować dobre decyzje w trakcie roku

Czy wzmacniamy zespół in-house, czy zmieniamy kolejność inicjatyw, czy realizujemy część prac z zespołem zewnętrznym. To nie są decyzje, które trzeba rozstrzygnąć w styczniu. Ważne, żeby plan pokazywał, że takie decyzje będą potrzebne i na jakich zasadach będziemy je podejmować. Plan IT zaczyna żyć dopiero wtedy, gdy zostanie przełożone na czytelną roadmapę. Nie jako sztywny harmonogram, ale jako wspólny obraz kolejności i zależności. W projektach IT bardzo łatwo o rozjazd perspektyw. Zespół in-house patrzy na stabilność i ograniczenia techniczne. Biznes patrzy na efekty i terminy. Partner zewnętrzny realizuje swój zakres. Jeżeli te perspektywy nie spotykają się regularnie wokół jednej roadmapy, decyzje zaczynają być podejmowane punktowo, bez pełnego obrazu i bez konsekwencji. Roadmapa pozwala wracać do pytania, czy to, co robimy teraz nadal wspiera cele, które wyznaczyliśmy na początku roku. Na koniec rzecz, która w IT ma ogromne znaczenie. Plan roczny to nie dokument, który tworzy się raz i odkłada na półkę. Zaczyna mieć wartość dopiero wtedy, gdy firma do niego regularnie wraca. W świecie technologii bardzo łatwo zgubić kierunek w natłoku zgłoszeń, pomysłów i bieżących problemów. Plan staje się wtedy punktem odniesienia. Pomaga zdecydować, co przesuwamy, co wzmacniamy, a z czego świadomie rezygnujemy. Nie dlatego, że coś jest złe, ale dlatego, że nie wszystko da się zrobić na raz, od razu. Plan nie ma chronić firmy przed zmianą. Ma pomóc podejmować lepsze decyzje wtedy, gdy rzeczywistość zaczyna się zmieniać. Jeśli po tym odcinku masz w głowie więcej pytań niż odpowiedzi, to znak, że warto jeszcze raz zweryfikować swój plan. A jeśli chcesz skonfrontować go z realiami IT, architektury i zespołów, skontaktuj się ze mną. Pomogę spojrzeć na niego z perspektywy realnego działania twojej firmy. Dzięki za wysłuchanie i obejrzenie dzisiejszego odcinka.

Do zobaczenia za tydzień. Cześć.

‍