Wiedza zintegrowana z projektami

Zarządzanie finansami portfela projektów dostarcza mechanizmów jednoznacznie wskazujących biznesowe źródła kosztów IT.

Współczesny biznes zależy w znaczącej części od Internetu i innych kanałów wymagających zastosowania nowoczesnych technologii informatycznych. W takiej sytuacji zadziwiające jest, w jak wielu polskich firmach postrzega się go jako jednostkę czysto kosztową. Prawda jednak jest taka, że w nowoczesnej organizacji IT stanowi jednostkę w dużym stopniu wspierającą swoimi usługami działalność biznesową. Jeżeli by się przyjrzeć portfelowi projektów IT w przeciętnej organizacji, to okaże się, że większość tych projektów jest realizowana na potrzeby departamentów biznesowych. Bardzo często projekty o charakterze czysto "informatycznym" (np. infrastrukturalne, takie jak wymiana sieci na nowszą) mają również swoje uzasadnienie biznesowe, podyktowane zapewnieniem ciągłości funkcjonowania organizacji.

Zarządzanie finansami portfela projektów dostarcza mechanizmów (i co czasami jest ważniejsze - argumentów) jednoznacznie wskazujących biznesowe źródła kosztów IT. Ułatwia ono również racjonalizację kosztów projektów informatycznych. Jednym z najczęstszych przykładów nie zawsze uzasadnionych kosztów projektowych są wymagania zapewnienia wysokiej dostępności dla rozwiązań, które w rzeczywistości - np. ze względu na niski priorytet systemu z biznesowego punktu widzenia - takiej dostępności wcale nie potrzebują.

Dostępność systemu informatycznego jest jednym z elementów składających się na całkowity koszt rozwiązania. TCO dla systemu informatycznego to nie tylko koszt jego wytworzenia (tj. projektu, w ramach którego system jest wdrażany), ale również koszty jego późniejszego utrzymania, rozwoju, a następnie wycofania z produkcji lub zastąpienia nowym. W organizacjach cechujących się dojrzałą kulturą projektową oraz umiejętnością utrzymywania dialogu pomiędzy biznesem a IT można zaobserwować próby wplecenia szacowania TCO systemu do procesów planowania i budżetowania projektów. W organizacjach mniej dojrzałych obserwuje się tendencje zupełnie odwrotne. Ramy finansowe projektów kończą się z chwilą wdrożenia systemu, a to, na jakich zasadach system będzie później utrzymywany (i finansowany), postrzegane jest jako problem działu IT.

Aplikacje w portfelu

Mówiąc o kosztach systemów informatycznych, warto wspomnieć o zarządzaniu portfelem aplikacji (ang. Application Portfolio Management, APM). Ta odmiana zarządzania portfelowego powstała na potrzeby IT i pozwala na zachowanie wiedzy o powiązaniach pomiędzy projektami a systemami informatycznymi, na które te projekty wpływają. Dzięki monitorowaniu wydatków projektowych z perspektywy systemów IT organizacje bardzo często uzyskują efekt synergii. Niejednokrotnie spotkałem się z sytuacją, w której w różnych częściach organizacji wdrażano lokalnie niezależne instancje tego samego systemu. W ten sposób zwiększane były nie tylko koszty licencji, ale również liczba kupowanych serwerów czy tworzonych niezależnych zespołów utrzymaniowych.

Zarządzanie portfelem aplikacji pozwala w momencie powoływania projektu na uzyskanie odpowiedzi, czy przypadkiem organizacja nie ma już takiego samego lub podobnego systemu informatycznego. Dzięki takiemu podejściu możliwe jest nie tylko zmniejszenie kosztów, ale również skrócenie czasu trwania projektu, poziomu jego skomplikowania, a czasami nawet uzyskanie dodatkowych korzyści wynikających np. z zastosowania już wdrożonych rozwiązań.

Bardzo często mam do czynienia z firmami wdrażającymi u siebie systemy wspierające zarządzanie projektami. Dość powszechnie spotykam się z sytuacją, w której jeden dział kupuje i wdraża takie rozwiązanie "lokalnie" (np. na potrzeby zarządzania projektami marketingowymi), nie zdając sobie sprawy, że organizacja ma już podobne rozwiązania. W skrajnym przypadku obserwowałem organizacje, których dwie jednostki organizacyjne korzystały z różnych systemów - z pełnymi tego skutkami, tj. zakupem różnych licencji oraz serwerów, utrzymywaniem oddzielnych zespołów administracyjnych (o różnych kwalifikacjach, bo systemy były w różnych technologiach) i podpisywaniem oddzielnych umów serwisowych.

Często okazuje się, że przyczyną takiego stanu rzeczy jest brak wiedzy o posiadanych rozwiązaniach w organizacji. Oczywiście z pomocą przychodzą różne metody gromadzenia i wykorzystywania wiedzy o posiadanych systemach informatycznych. Jedną z metod jest omawiane zarządzanie portfelem aplikacji. Podobne obszary zainteresowania można znaleźć np. również w ITIL. Application Portfolio Management jako metoda opisuje jednak najdokładniej związki pomiędzy systemami IT a realizowanymi projektami.

Zarządzanie portfelem aplikacji pozwala również na śledzenie cyklu życia systemu informatycznego z finansowego punktu widzenia. Jest on bardzo podobny do finansowego cyklu życia projektu. Na pierwszym etapie - wdrożenia - system informatyczny zazwyczaj kosztuje organizację, nie przynosząc zysków. Następnie - podczas wykorzystywania systemu przez jednostki biznesowe - generowane są zyski przewyższające koszty utrzymania systemu. W pewnym momencie dochodzi się jednak do punktu, w którym koszty utrzymania przewyższają uzyskiwane korzyści. Jednakże w przypadku skomplikowanych systemów IT może się okazać, że po osiągnięciu tego punktu utrzymywanie funkcjonującego systemu jeszcze przez jakiś czas jest bardziej opłacalne, niż jego wyłączenie z produkcji. APM wspiera podejmowanie świadomych i uzasadnionych biznesowo decyzji o czasie wykorzystywania systemów informatycznych w organizacji. Na wykresie bardzo dobrze widać, że projekt stanowi tylko część cyklu życia przedsięwzięcia informatycznego.

Dodatkowym atutem wprowadzenia zarządzania finansami portfela projektów oraz portfela aplikacji jest wsparcie procesów budżetowania działów IT. PPM dostarcza dyrektorom IT wiedzy zarówno o prognozowanych, jak i o rzeczywistych wydatkach projektowych. Należy pamiętać, że zarządzanie portfelem projektów służy nie tylko do monitorowania realizowanych równolegle inicjatyw, ale również do planowania przyszłych projektów. Dzięki temu do kadry zarządzającej trafiają dodatkowo informacje o kosztach przedsięwzięć planowanych w przyszłości.

CAPEX czy OPEX?

Spójrzmy jeszcze na zarządzanie finansami portfela projektów IT z trochę innej perspektywy. Najważniejszym zadaniem każdego dyrektora finansowego jest dbanie, aby organizacja uzyskiwała optymalne wyniki finansowe. Na pierwszy rzut oka może się wydawać, że dla CFO portfel projektów IT to głównie koszty operacyjne i kapitałowe rozłożone w czasie. Niemniej jednak w przypadku wielu kosztów projektów IT decyzja o tym, co w rzeczywistości jest CAPEX-em a co OPEX-em, ma charakter uznaniowy. W szczególności w dużych organizacjach można spotkać się z operacją "capeksowania OPEX-u" polegającą na zmianie kwalifikacji niektórych wydatków z kosztów operacyjnych na koszty kapitałowe poprzez przeniesienie niektórych wydatków do grupy działań rozwojowych.

Projekty informatyczne ze względu na swój charakter stanowią bardzo wdzięczny materiał do takich działań. Zarządzanie finansami portfela projektów dostarcza wiedzy o aktualnej klasyfikacji wydatków IT oraz ułatwia opisanie procesów decyzyjnych. W bardzo wielu organizacjach ustalone zasady podziału kosztów IT na koszty kapitałowe i operacyjne mają duże przełożenie na kształt procesów przetargowych, budżetów projektowych oraz formalny zakres produktów projektu. W przypadku jednego z naszych klientów zdecydowana większość wydatków na projekty IT musiała być klasyfikowana jako CAPEX-y. Dla kierownika projektu oznaczało to w praktyce, że zamiast szkoleń powdrożeniowych musiał zamawiać przewodniki użytkownika, a dostawca musiał zawsze udzielać rocznej, bezpłatnej gwarancji i wsparcia utrzymaniowego - co oczywiście (za zgodą obu stron) zawsze skutkowało wkalkulowaniem usług poprojektowych w koszty projektu.

Przyjrzyjmy się jeszcze jednemu powszechnemu przykładowi firmy, w której prognozy wyników finansowych zostały uznane za niewystarczające. Decyzją dyrektora finansowego, rozpoczęto w organizacji działania, mające na celu - w pełni legalne - przekwalifikowanie wydatków operacyjnych na inwestycyjne. Decyzja ta oczywiście miała bezpośrednie przełożenie na portfel projektów. Jak łatwo się domyślić, dokładnie zostało określone, jakie typy kosztów mają ulec zmianie kwalifikacji (np. wspomniane szkolenia zamienione na warsztaty).

Dzięki zastosowaniu zarządzania portfelem projektów możliwe było łatwe zidentyfikowanie tych projektów, które powinny zostać objęte zmianami. W następnym kroku rozpoczęto iteracyjne wprowadzanie modyfikacji. Na początek zidentyfikowano projekty, w których zmiana kwalifikacji nie wiązała się ze skomplikowanymi i długotrwałymi zmianami umów z wykonawcami. Po zakończeniu tej operacji (oraz wielu podobnych, realizowanych poza obszarem projektowym) dział finansowy zweryfikował, jak duża część wydatków musi jeszcze ulec zmianie kwalifikacji, aby osiągnąć pożądany poziom wyników. Na podstawie tej wiedzy wybrano kolejny zbiór projektów, w których wprowadzano stosowne modyfikacje.

Skuteczne i bezbolesne przeprowadzenie tej operacji w obszarze projektowym możliwe było dzięki wykorzystaniu informacji dostarczanych przez wdrożone zarządzanie finansami portfela projektów. W organizacjach, które nie mają takich mechanizmów, często obserwuje się "strzelanie na oślep", polegające na losowym wybieraniu projektów obejmowanych zmianami lub zmianach kwalifikacji środków w projektach, o których dział finansowy wie, że są realizowane - a dość powszechnie zdarzają się przypadki, że nie wie o wszystkich.

Dominik Chrzanowski jest dyrektorem Departamentu ValueBoard w firmie ValueTank dostarczającej usługi doradcze i rozwiązania wspomagające strategiczne obszary zarządzania przedsiębiorstwem.

Budżet pod kontrolą

Myśląc o wykorzystaniu zarządzania portfelem projektów oraz portfelem aplikacji w budżetowaniu IT, można czasami wpaść w pułapkę pokusy wykorzystania PPM jako głównego mechanizmu do budżetowania. Kilkukrotnie miałem okazję przyglądać się takim próbom. Zawsze kończyły się one w ten sam sposób - mniejszą lub większą porażką. Należy pamiętać, że systemy PPM nie są rozwiązaniami do budżetowania IT i o ile mogą dostarczać częściowej wiedzy o planowanym zapotrzebowaniu finansowym, o tyle ich dostosowanie do potrzeb kompleksowego budżetowania IT zawsze jest bardzo kosztowne i skomplikowane. Zdecydowanie lepszym rozwiązaniem jest integracja systemu PPM z typowymi systemami do budżetowania i kontrolingu finansowego - w takim scenariuszu aplikacja PPM stanowi jedno ze źródeł danych finansowych.

Warto tu przytoczyć przykład z jednej, dużej organizacji. W trakcie budżetowania organizacja ta wydziela oddzielne budżety projektowe - pogrupowane względem kilku parametrów, takich jak obszar biznesowy czy kategoria projektów. Innym, wykorzystywanym przez organizację sposobem dzielenia rocznych budżetów projektowych jest ustalanie rocznych limitów finansowych na usługi kluczowych dostawców. Podział taki wynika z faktu, że na początku roku nie są znane wszystkie projekty i prace, które będą zlecone danemu dostawcy. Organizacja natomiast - między innymi na podstawie danych historycznych - potrafi oszacować, ile pieniędzy będzie potrzebowała na usługi wybranego dostawcy. W trakcie roku budżety projektowe śledzone są na poziomie funkcjonujących procesów zarządzania portfelem projektów. W ten sposób PPM dostarcza wiedzy o rzeczywistej konsumpcji środków per dostawca i możliwe jest monitorowanie ilości środków pozostałych do wykorzystania oraz prognozowanie przyszłych zapotrzebowań.