Strategia IT, która nie trafi do szuflady: co naprawdę powinno się w niej znaleźć?

Ten wpis jest dla osób, które strategię zamawiają, zatwierdzają albo mają ją potem wykonywać: sekretarzy i skarbników w urzędach, prezesów i członków zarządów spółek komunalnych, prezesów i dyrektorów finansowych firm, a także kierowników IT, którzy chcą, żeby dokument wreszcie pomagał im w rozmowie o budżecie. O typowych błędach w strategiach urzędów pisałem osobno we wpisie Strategia IT w JST: najczęstsze błędy. Tutaj skupiam się na tym, co powinno znaleźć się w samym dokumencie.

Dlaczego strategie trafiają do szuflady

Z tego, co widziałem w organizacjach publicznych i prywatnych, strategia rzadko jest zła merytorycznie. Trafia do szuflady, bo nie da się jej użyć przy pierwszej konkretnej decyzji.

• Zaczyna się od wizji, a nie od inwentarza. Nikt nie sprawdził, jakie systemy, umowy i zależności już istnieją, więc plan rozmija się z rzeczywistością przy pierwszym zakupie.
• Opisuje cele, ale nie kolejność. Wszystko jest ważne, więc nic nie jest pierwsze.
• Nie ma pieniędzy. Brak powiązania z budżetem sprawia, że strategia i plan finansowy żyją osobno.
• Nie zmienia sposobu kupowania. Kolejne systemy dalej kupuje się tak jak wcześniej, na podstawie ofert dostawców, a nie własnych standardów.
• Nie ma właściciela. Dokument przyjęto uchwałą albo decyzją zarządu i na tym jego życie się skończyło.
• Jest pisana językiem IT. Zarząd i Rada nie widzą w niej odpowiedzi na swoje pytania: ile, po co, co się stanie, jeśli nie zrobimy nic.

Siedem elementów strategii, której się używa

1. Stan obecny. Rejestr systemów z właścicielem, umową, licencją, kosztem i końcem wsparcia, mapa procesów i integracji, rejestr ryzyk. Bez tego każdy kolejny punkt jest zgadywaniem. To zadanie dla inwentaryzacji.
2. Architektura docelowa. Prosty obraz, jak względem siebie mają się rejestry, procesy, integracje i dostęp. Nie chodzi o schematy techniczne, tylko o odpowiedź na pytanie, które systemy są centralne, a które je wspierają, gdzie dane powinny powstawać i które systemy powinne te dane dziedziczyć.
3. Standardy. Kilka zasad obowiązujących przy każdym zakupie: jak nadajemy uprawnienia, jak ma wyglądać interfejs dla pracowników, jak dokumentujemy wymagania, jakie prawa do danych musimy mieć, jakiego języka (standardu) używamy do komunikowania procesów, jak zabezpieczamy wyjście ze współpracy.
4. Mapa drogowa z podziałem na obowiązek i inwestycję. Osobno to, co musimy zrobić, bo wymaga tego prawo lub umowa (w urzędach na przykład system klasy EZD, KSeF, e-Doręczenia), a osobno to, co robimy, bo się opłaca. Z kolejnością i uzasadnieniem. Przykładowo: fakturę po pobraniu z KSeF możemy zapisać do akt sprawy, ale zgodnie z prawem powinna ona uzyskać akceptację merytoryczną, weryfikację formalno-rachunkową i skończyć swój bieg poprzez automatyczny zapis do systemu finansowo-księgowego.
5. Budżet z podziałem na inwestycję i utrzymanie. Utrzymanie rośnie z każdym nowym systemem i powinno być widoczne, zanim zapadnie decyzja o zakupie. Więcej o tym we wpisie o całkowitym koszcie posiadania. Pamiętaj, że wdrożenie to z reguły jednorazowa inwestycja (CAPEX) ale z punktu widzenia budżetu, ciągłość działania i bezpieczeństwo to m.in. serwis i aktualizacje (OPEX), który powtarza się rok do roku.
6. Zasady zakupowe dla systemów. Kiedy potrzebna jest inwentaryzacja lub analiza przed zakupem, kto opiniuje ofertę, jakie klauzule muszą znaleźć się w umowie. Część z nich opisałem we wpisie o SWZ bez uzależnienia od dostawcy.
7. Właściciel i rytm przeglądu. Konkretna osoba po stronie zarządczej powinna dokonywać przeglądu strategii i kosztów posiadania, co najmniej raz w roku przy okazji budżetu, respektując czytelną zasadę cykliczności tych przeglądów.

Przykład z praktyki

Spółka Wodociągi Miejskie, należąca do średniej wielkości gminy, przygotowywała plan zakupów IT na kolejny rok. Początkowo dział IT wnioskował o jednoczesną wymianę komputerów biurowych, zakup nowego systemu monitorowania oraz modernizację infrastruktury sieciowej. Zarząd poprosił jednak o wykazanie, które wydatki są najpilniejsze z punktu widzenia ciągłości dostaw wody.

Spółka zaczęła od inwentaryzacji: zestawiła urządzenia, oprogramowanie, połączenia sieciowe i umowy serwisowe, a następnie przypisała je do konkretnych procesów — od obsługi klientów po sterowanie pracą stacji uzdatniania. Okazało się, że część urządzeń pośredniczących w komunikacji ze stacjami była bliska końca okresu wsparcia, a dokumentacja połączeń nie obejmowała wszystkich lokalizacji. Jednocześnie większość komputerów biurowych mogła nadal pracować bez istotnego wpływu na kluczowe usługi.

Na tej podstawie zmieniono kolejność zakupów. Najpierw przewidziano uporządkowanie i zabezpieczenie połączeń z obiektami technologicznymi oraz wymianę urządzeń, których awaria mogłaby utrudnić nadzór nad dostawami wody. Następnie zaplanowano uzupełnienie kopii zapasowych i monitorowania. Wymianę części komputerów biurowych przesunięto na późniejszy etap.

Przed zarządem dział IT nie uzasadniał już budżetu ogólnym stwierdzeniem, że „sprzęt jest stary”. Pokazał zależność: konkretny składnik infrastruktury → obsługiwany proces → skutek awarii → proponowany zakup. Dzięki temu zarząd mógł zatwierdzić wydatki w etapach i wyjaśnić radzie nadzorczej, dlaczego pierwszeństwo otrzymała infrastruktura związana z ciągłością usług, a nie najbardziej widoczny dla pracowników sprzęt biurowy.

Kiedy potrzebny jest niezależny doradca

Strategię da się napisać własnymi siłami, jeżeli w organizacji jest ktoś, kto ma na to czas i widzi całość. Zewnętrzne wsparcie przydaje się, gdy stan obecny nie jest spisany, gdy strategia ma być podstawą do obrony budżetu przed Radą, właścicielem albo centralą, gdy nadchodzi kilka obowiązków regulacyjnych naraz albo gdy zarząd i IT patrzą na priorytety inaczej i potrzebny jest ktoś, kto przełoży jedną perspektywę na drugą.

Przygotowuję strategię cyfryzacji i architekturę docelową na podstawie inwentaryzacji: z mapą drogową, standardami, zasadami zakupowymi i budżetem, który da się obronić.