Dla większości menedżerów IT budżetowanie to ponury koszmar. Niektórzy nigdy nie zrozumieli, na czym polega alokacja kosztów, ale w życiu się do tego nie przyznają. Inni z ponurą satysfakcją wpisują tu i tam cyfry wzięte z księżyca, wiedząc, że nikt i tak nie zwróci na to uwagi. Tak czy owak, budżetowanie nie należy do miłych zajęć.

Do budżetowania można mieć różne podejście. Można zakładać, że jest to zło konieczne, podobnie jak w ogóle jakiekolwiek wydatki, czego konsekwencją jest ograniczanie ich do minimum i utrzymywanie minimalnym kosztem środowiska IT w kształcie, który przybrało wiele lat temu. Od osobowości szefa działu IT i prezesa całej firmy zależy wówczas zazwyczaj przyszłość jakichkolwiek projektów, które miałyby być przez ów dział IT realizowane. Można traktować budżet jak Biblię, trzymając się ściśle słów i cyfr zapisanych 12 miesięcy wcześniej. Być może budżet został zaplanowany bardzo rzetelnie i starannie, a procedury monitorowania jego realizacji są godne uznania, niemniej skrajnie nieelastyczne podejście do ewentualnych zmian strasznie usztywnia organizację, odbierając jej jakikolwiek dynamizm i możliwość reagowania na nowe potrzeby i możliwości. Działanie w takim właśnie środowisku zmusza zazwyczaj co bardziej energicznych szefów działów IT do stałego poszukiwania uzasadnionych okazji do przeforsowania pożądanych zmian w nieubłaganym zestawieniu zaplanowanych na dany rok wydatków.

Przejęcie, reorganizacja, wprowadzenie nowej linii produktów, otwarcie nowego oddziału - wstrzelenie się w odpowiednim momencie z propozycją technologiczną uzupełniającą plany biznesowe może dać działowi IT nieco oddechu i przestrzeni w ciasnych ramach budżetu. Można uznawać, że budżet jest tylko zbiorem luźnych wytycznych ogólnie określających ramy, w których należy się zmieścić na bieżąco planując wydatki. To oznacza pożądaną elastyczność, ale z drugiej strony może prowadzić do serii nieuporządkowanych, chaotycznych działań, które niekoniecznie muszą przekładać się na sukces przedsiębiorstwa czy jakiekolwiek oszczędności. Szybkie decyzje mogą oznaczać nadmierne wydatki w jednym czy kilku obszarach działania IT. Z drugiej jednak strony, taki elastyczny budżet we właściwych rękach pozwala na szybkie dostosowania do zmieniających się warunków, co przy sprzyjających wiatrach może się firmie bardzo opłacać. W ten sposób dochodzimy do złotego środka, czyli budżetu, który trzyma się kierunku nakreślonego w perspektywie roku i kilku lat przez zarząd firmy, ale jednocześnie pozwala się uelastyczniać w granicach rozsądku.

Od uzasadnionych oszacowań do wróżenia z fusów George Sifri pisał niedawno na łamach Computerworld o konieczności uwzględniania ryzyka w harmonogramach projektów opracowywanych metodą ścieżki krytycznej. Autor zauważył m.in., że "w metodzie ścieżki krytycznej posługujemy się ściśle określonymi czasami trwania poszczególnych działań, podczas gdy w rzeczywistości mamy raczej do czynienia z pewnymi zakresami określającymi najkrótszy i najdłuższy możliwy czas trwania projektu" oraz "tak naprawdę to, co uznajemy zgodnie z metodą ścieżki krytycznej za najbardziej prawdopodobny scenariusz, jest scenariuszem optymistycznym". Sytuacja jest analogiczna w przypadku budżetu! Planując od wiosny do jesieni budżet na kolejny rok finansowy (załóżmy, że pokrywa się on z rokiem kalendarzowym), wpisujemy w odpowiednie formatki konkretne kwoty, ale w gruncie rzeczy operujemy, czy może raczej powinniśmy operować, zakresami.

O ile bowiem pewne kwestie da się przewidzieć z dużym prawdopodobieństwem (cena kontraktów serwisowych, opłaty licencyjne szczególnie w projektach i kontraktach długoterminowych, opłaty w kontraktach outsourcingowych), o tyle reszta jest oszacowaniem z kategorii "między -50% a +100%", które z biegiem miesięcy jest coraz bardziej uszczegóławiane. Jeśli jest inaczej, jeśli zarząd firmy wymaga ścisłego określenia i późniejszego bezwzględnego trzymania się kwot w rozmaitych kategoriach (ludzie, sprzęt, usługi, oprogramowanie, telekomunikacja czy wręcz ludzie w projekcie A, ludzie w projekcie B, sprzęt w projekcie A i B, doradztwo na etapie szacowania wymagań, na etapie projektu pilotowego i wiele innych), to szef działu IT albo zostanie zmuszony do kreatywnej księgowości, albo dopracuje się mentalności i tempa pracy kiepskiego urzędnika, albo znając od lat to sztywne podejście zabezpieczy się mocno na zakładkę na etapie planowania, obcinając z konieczności wiele interesujących, mniejszych projektów, które mogłyby się jeszcze zmieścić przy bardziej elastycznym podejściu.

Czy możemy dokładnie zaplanować koszty pracy? Wystarczy dwóch pracowników, którzy zdecydowali się wyjechać do Szwajcarii i Wlk. Brytanii i nieoczekiwana konieczność szukania zastępców na ich miejsce, by kwoty wpisane we wrześniu przestały mieć zastosowanie. Czy wiemy dokładnie, jakie będą ceny sprzętu pod koniec roku? Czy nasz dostawca utrzyma się na rynku? Zmieni partnera technologicznego? A może urzędy skarbowe otrzymają wykładnię postępowania z firmami posługującymi się wyłącznie fakturami elektronicznymi, co pozwoli nadać impet związany z tym tematem projektom IT? A może firma w ogóle zacznie wycofywać się z Polski lub kupi jednego z konkurentów? Szefowie działów IT doskonale to wszystko wiedzą i stąd bierze się szaleństwo zakupów pod koniec roku finansowego.

Ryzyko, że wydarzy się coś nieprzewidzianego, co wywróci nasz budżet do góry nogami, jest już minimalne. Ryzyko, że niewydane pieniądze wrócą do nas rykoszetem w postaci obciętego budżetu na kolejny rok, jest ogromne. Czy te świąteczne zakupy mają sens biznesowy? Jakiś na pewno, ale z pewnością miałyby o wiele większy, gdyby gdzieś między IT a dyrektorskimi gabinetami miała miejsce rozmowa, może nawet dyskusja, może nawet trwający przez cały rok dialog, a nie tylko okazjonalna wymiana arkuszy Excel opatrzonych komentarzem starannie sformułowanym, tak aby chronić jego autora od wszelkiego wypadku.

Najemnicy globalizacji

W gruncie rzeczy sytuacja ta jest jakąś pochodną globalizacji i będącej jej konsekwencją centralizacji decyzji i zarządu. Formatka budżetowa działu IT dokłada się do formatki kilkunastu co najmniej działów polskiego oddziału jakiejś zachodniej korporacji, która z kolei takich zestawów dostaje kilkadziesiąt ze wszystkich krajów i regionów, w których posiada przedstawicielstwa. Nikt nie ma czasu i narzędzi na kompilację zakresów i wczytywanie się w komentarze, założenia i zastrzeżenia. Dyrektor polskiego oddziału nie otrzymuje premii za dyskutowanie subtelnych niuansów zbliżania się z biegiem czasu od szacunków do wartości rzeczywistych, lecz za zduszenie kosztów i pokazanie zysków.

Czy bazując na zdrowym rozsądku nie można by wypracować kompromisu na lokalnym szczeblu? Pewnie można, tylko ważne, aby odbiorca i egzekutor budżetu zgodzili się, że pewne luźne trzymanie się wcześniej określonych kwot jest zbliżaniem się do zdrowych realiów w miarę precyzowania się sytuacji, a nie widomym dowodem kompletnej niekompetencji autora odpowiedniego fragmentu planu budżetowego. Tu oczywiście ważne jest zastrzeżenie, że jeśli kolejne przybliżenia coraz bardziej odbiegają od planów raz na plus, raz na minus, a nie zbiegają się ku pewnej wartości rzeczywistej, to faktycznie autor mógł nie być kompetentny. Gdyby wszystkie strony zgodziły się, że budżet ma być dla nich, a nie oni dla budżetu, można by złagodzić niemiły obowiązek jego tworzenia i wykrzesać z ludzi inicjatywę, a nie tylko pielęgnować konformistyczną zachowawczość. Jak do tego podejść?

Skupić się na tym co ważne

Godząc się na pewną zmienność i szacunkowość budżetowych planów, można z góry zaplanować nowe projekty IT w formie listy, na której najwyższe pozycje mają najwyższy priorytet. Im więcej projektów uda się w ciągu roku odciąć z listy i skierować do realizacji, tym lepiej. Pierwszeństwo w finansowaniu mają te na najwyższych pozycjach, a w październiku okaże się, czy firmie uda się zrealizować tylko projekty konieczne, czy również takie, które miło byłoby zrealizować. Nie ma sensu zbyt szczegółowe określanie priorytetów, wystarczy podział na cztery grupy.

Pierwsza grupa obejmuje projekty, które muszą być zrealizowane ze względów bezpieczeństwa, z powodu wejścia w życie nowego prawa czy też zestarzenia się posiadanego sprzętu i aplikacji. W tej kategorii mieszczą się również projekty narzucone przez korporację, na które lokalne oddziały nie mają żadnego wpływu. Generalnie chodzi więc o projekty, które nie mogą zostać niezrealizowane. Jeśli budżet informatyczny jest wyjątkowo ciasny, to tu w zasadzie kończą się projekty do wykonania w danym okresie budżetowym. W drugiej grupie znajdują się projekty, które firma bardzo chciałaby zrealizować ze względów biznesowych, inwestycje, które z ogromnym prawdopodobieństwem zwrócą się przed upływem sześciu miesięcy, szybko generując narastające oszczędności, oraz duże projekty w trakcie realizacji. Tutaj zazwyczaj kończą się pieniądze w większości firm. Trzecia grupa to projekty pożądane. To, czy się zwrócą w kategoriach finansowych, nie jest jednoznaczne, a okres zwrotu zawsze przekracza rok. Te projekty mogą liczyć na finansowanie tylko wówczas, gdy pozostaną wolne środki, gdy faktyczna sprzedaż jest lepsza od prognozowanej lub choćby pokrywa się z przewidywaniami. Zdarza się, że projekty te przechodzą do drugiej lub nawet pierwszej kategorii w kolejnych okresach budżetowych. Ostatnia grupa to "dobawki" - tak znajomi informatycy zajmujący się oprogramowaniem internetowym określają funkcjonalność uprzyjemniającą życie użytkownikowi. W tej kategorii mieszczą się wszystkie projekty, które wyglądają nieźle i wydaje się, że warto je realizować, ale w gruncie rzeczy dość trudno jest uzasadnić potrzebę ich realizacji w kategoriach biznesowych. Istnienie tej grupy projektów ma swoje uzasadnienie - wiadomo, gdzie wrzucić entuzjastycznie promowane przez kogoś pomysły, które nie przechodzą finansowego i biznesowego sita. Być może okażą się warte uwagi w następnych okresach.

Może wydawać się niedorzecznością koncentrowanie się na wydatkach kapitałowych, kiedy większość działów IT z trudem mieści się w budżecie z bieżącą działalnością operacyjną, przeznaczając na nowe projekty kilkanaście procent środków. Pensje, premie, prowizje dla agencji doradztwa personalnego, szkolenia, podróże, przygotowanie miejsca pracy dla pracowników, konsultanci zewnętrzni, amortyzacja sprzętu i oprogramowania, utrzymanie, naprawy, wynajem, wsparcie użytkowników, aktualizacje, utrzymanie i wynajem linii telekomunikacyjnych, usługi sieciowe, bezpieczeństwo, transport - to wszystko pochłania większą część budżetu działu IT. Ale to nowe projekty są tym, co tworzy wartość. Posiadanie interesującej listy projektów czekających na realizację pomaga kreatywnie podejść do bieżących wydatków operacyjnych. Wizja pomaga wyłuskać fundusze tam, gdzie nikt by się ich już nie spodziewał. Oczywiście, prawie zawsze okazuje się, że późniejsze oszczędności wymagają wcześniejszych inwestycji. Ale czasem okazuje się, że wystarczy nieco się zorientować w warunkach rynkowych, by skłonić dostawcę usług telekomunikacyjnych czy serwisowych do przedstawienia lepszej oferty.