Controlling projektów w organizacji klienta cz.I

Skuteczny system controllingu projektów w organizacji klienta musi realizować takie same cele, które są stawiane przed każdym systemem controllingu. Kierownicy projektów potrafią zarządzać produkcją produktów projektu tym lepiej, im jaśniej są zdefiniowane reguły decydowania o produktach. Controllerzy potrafią dostarczać analiz, sprawozdań i rekomendacji tym lepiej, im bardziej działania te są wystandaryzowane i zrozumiałe dla nich. Komitety sterujące tym lepiej dbają o sukces projektu, im jaśniejsze są cele.

Projekty same w sobie są tymczasowe i ryzykowne, tj. obarczone dużą niepewnością celu i zakresu. Projekty w organizacji klienta ingerują w tak złożone i dynamiczne środowisko procesów organizacji, że jakość planowania zmian w procesach (czyli planowanie projektów) jest dramatycznie niższa niż jakość planowania powtarzalnych ciągłych działań w procesach. Niepewność celu i zakresu przekłada się przy tym na niepewność doboru zasobów, terminów, środków finansowych, metod pracy itp.
W związku z tym organizacjom klienta pozostaje rozwinięcie umiejętności przewidywania i adaptacji do zmian, tak aby z niedoskonałym planem w ręku nadal panować nad projektami i procesami jednocześnie.

Organizacja klienta

Współczesne rozważania na temat projektów w organizacjach są zorientowane na tzw. organizacje zarządzane przez projekty. Do takich organizacji należą przede wszystkim wykonawcy projektów. Projekty są tam podstawowym obiektem controllingowym wiążącym w sobie cechy centrum zysków, centrum kosztów i centrum inwestycji, i jako takie są podstawowym instrumentem zarządzania.
Organizacje niebędące wykonawcami projektów - nazwijmy je tutaj dla uproszczenia klientami - stanowią „drugą stronę medalu". Projekt klienta, jako wyodrębniony obiekt organizacyjny w strukturze zarządzania, zawiera w sobie (choć nie musi) część projektu zewnętrznego wykonawcy. Do dalszych rozważań przyjmijmy następujące założenia:

• organizacja klienta generuje wynik dzięki sprawności i efektywności procesów gospodarczych, projekt nie jest podstawową formą tworzenia wyniku,
• projekty są powoływane wtedy, gdy z jakiegoś powodu okazuje się to wygodniejsze, 
• nie ma wymogu angażowana zewnętrznych wykonawców w realizację produktów projektów, istnieją więc projekty realizowane w całości własnymi siłami i zasobami,
• istnieją 3 kluczowe role w controllingu projektów: kierownik projektu, komitet sterujący oraz controller.
  

Założenia powyższe, choć ogólne, znakomicie charakteryzują większość tzw. organizacji nie-projektowych. Przyjmijmy również controllingową definicję projektu: tymczasowy obiekt zarządzania złożony z celu oraz produktów umożliwiających jego osiągnięcie.

Projekt w organizacji nieprojektowej

Projekt dostawcy jest oczekiwanym skutkiem działania procesów wykonawcy, tj. procesu sprzedaży, badań i rozwoju oraz procesu realizacji projektów dla klientów. Projekt klienta nie jest oczekiwanym skutkiem działania procesów. Wręcz przeciwnie, stanowi planowaną i uzasadnioną ingerencję w procesy klienta z celem ich zmiany. Opanowanie tej ingerencji jest trudne, bo słabo poddaje się standaryzacji.
Albo prościej: u klienta z zasady nie istnieje proces kreacji projektów, może co najwyżej istnieć proces obsługi projektów (zarządzania projektami). U klienta "nie istnieje proces stałego generowania celów projektów, chociaż może istnieć standard obsługi projektów. Dla porównania - u wykonawcy cele projektu generowane są w sposób ciągły przez proces sprzedaży. To dlatego właśnie controlling projektów w organizacji klienta jest znacznie bardziej skomplikowany od contr ollingu projektów w organizacji dostawcy.

Uwaga:
Warto podkreślić, że klient nie dysponuje wystandaryzowanym instrumentarium modelowania zmian w swoich procesach. Dlatego jest zmuszony definiować cele projektu i wszystko to, co z nich wynika, w warunkach dużej niepewności. Oczywiście istnieją instrumenty controllingu strategicznego wspomagające między innymi zarządzanie zmianą (np. Balanced Scorecard), ale ich użycie w organizacjach nieprojektowych służy bardziej procesom niż projektom. Stąd związanie celu projektu z produktami projektu jest zawsze znacznie trudniejsze w organizacji klienta.

Tabela 1: Porównanie postawy inwestora i wykonawcy

Cecha	Inwestor	Konsument
Cele (korzyści)	Zarobić jak najwięcej	Skorzystać jak najwięcej
Cele (wydatki)	Wydać jak najmniej	Wydać jak najmniej
Czas	Zyskiwać jak najdłużej	Korzystać jak najdłużej
Od czego zależy decyzja tak/nie	Przewidywany zysk (renotowność	Przewidywany stopień zaspokojenia potrzeby w stosunku do ceny
Podatność na obietnice dostawcy	Mała	Duża
Narzędzia	Rachunek ekonomiczny	Porównanie dóbr, intuicja, czasami emocje

 

Projekt dostawcy ma wbudowane produkty badawczo-rozwojowe, które klienta interesują jedynie w konteks'cie utrzymania i rozwoju zamówionych u dostawcy produktów podstawowych. Dodatkowo dostawca zawsze pracuje nad rozwojem sprzedaży u tego konkretnego klienta i, szerzej, w danym segmencie rynku czy linii ofertowej.
Projekt klienta ma wbudowane produkty dodane, realizujące niejako przy okazji dodatkowe cele. Produkty te są skutkiem optymalizacji zakresu projektu, jako takie nie pochodzą wprost z celów projektu i mogą (ale nie muszą) stać się składnikiem procesów. Przykłady:

• transfer środków pieniężnych pomiędzy spółkami jednego ugrupowania gospodarczego (produkt nieprocesowy, jednorazowy),
  
• nowy standard umowy z dostawcami (produkt, który może stać się składnikiem procesu zakupowego).
  

Serwis oraz utrzymanie i rozwój produktów projektu zaistnieją zawsze odpowiednio u dostawcy i u klienta. Interesująca obie strony część wspólna może zaistnieć w formie umowy serwisowej, ale umowa taka nigdy nie pokryje pełnego zakresu działań interesujących każdą ze stron.

Geneza projektu

Czynniki przesądzające o powołaniu projektu są zróżnicowane i szeroko opisane w literaturze, a wynikają wprost z definicji projektu. Każda metodyka zarządzania projektami zawiera w tym względzie konkretne zalecenia. Decyzja o powołaniu projektu ma zawsze u podstaw porównanie wysiłku związanego z realizacją projektu ze spodziewanymi korzyściami. Decydent może przy tym przyjąć postawę konsumencką lub inwestorską, ale nie zmienia to w niczym sedna istnienia projektu: uzyskać subiektywnie oceniony dodatni wynik na projekcie.

Perspektywa zarządzania organizacją

Projekt, w myśl teorii zarządzania projektami, to wyodrębniona tymczasowa organizacja (por. PRINCE2™, PMBOK®). Jak każdy obiekt organizacyjny, projekt powinien mieć swoje miejsce w systemie controllingu organizacji.
W tym miejscu pojawiają się kłopoty controł-lera i księgowego w organizacji klienta, których nie mają ich odpowiednicy w organizacjach wykonawców. Zaczyna się od pytań elementarnych związanych z pojedynczym projektem. Z szerokiej listy interesujące wydają się takie:

1. Czy projekt istnieje jako jawny, odrębny obiekt ewidencyjny? Jeśli tak, to jakiego rodzaju? Sub--MPK? Inwestycja rozpoczęta? Inne - jakie?
2. Czy budżet projektu jest odrębnie identyfikowany? Jeśli tak, to czy budżet ten zawiera koszt lub nakład związany z pracą pracowników i wykorzystaniem własnych zasobów przedsiębiorstwa na potrzeby projektu, czy tylko usługi obce i wartość planowanych zakupów?
3. Czy za projekt odpowiedzialna jest jedna (znana księgowym i controłlerom) osoba? Jeśli tak, to czy znany jest jej zakres uprawnień?

Pytania powyższe w naturalny sposób skutkują kolejnymi:

1. Jak księgować operacje gospodarcze związane z projektem?
2. Jak planować operacje gospodarcze związane z projektem? Jaki przyjąć horyzont planowania?
3. Jak w związku z tym uwzględnić stan projektu w rachunku wyników?
4. Czy i jak uwzględnić długi okres, w szczególności utrzymanie i rozwój produktów projektu?
5. Czy i jak tworzyć rezerwy na potrzeby projektu? Jak się mają do siebie rezerwy księgowe i controllingowe związane z projektem?

Idąc dalej, w przypadku projektów tworzących produkt z wbudowaną umową serwisową (zewnętrzną łub wewnętrzną - nie ma to znaczenia), kolejne pytania to:

1. Czy koszt usług serwisowych rozpatrywać łącznie z kosztami i wydatkami poniesionymi na powstanie produktów projektu, jako łączny budżet przedsięwzięcia?
2. Jak podejmować decyzje o zmianach produktów w trakcie pracy nad nimi?
3. Kto powinien dostarczać takich analiz i komu?

Powyższe dodatkowo komplikuje się o stałe i semistałe produkty infrastrukturalne, wspólne dla projektów i procesów, np. skokowy przyrost mocy obliczeniowej systemów informatycznych wskutek rozbudowy infrastruktury IT albo skokowy przyrost zapotrzebowania na pracę wskutek rozbudowy wybranej komórki organizacyjnej odpowiadającej za działania pośrednie wobec produktów i usług organizacji. W odniesieniu do takich produktów trzeba rozstrzygnąć:

1. Który projekt lub proces (a może projekty lub procesy) powinien finansować takie koszty?
2. Kto podejmuje decyzje o takich kosztach lub wydatkach?
3. Kto odpowiada za długoterminowe przesądzone zobowiązania wynikające z projektu, takie jak umowy serwisowe, licencyjne, dzierżawne itp.?
4. Czym są części wspólne projektów i jak je traktować rachunkowo i controllingowo?
5. Jaką wartość wobec powyższego zabudżeto-wać w bieżącym roku i w przyszłych latach? I przede wszystkim: Na jakim obiekcie umieścić taki budżet?

Perspektywa zarządzania finansami organizacji

Wybrane typowe oczekiwania stawiane wobec controlłerów zajmujących się projektami są w skrócie następujące: osiągnięcie celu capeksowego i opeksowego (perspektywa sterowania rocznym wynikiem finansowym), stabilne nieduże odchylenia, osiągnięcie celu budżetowego oznaczające zarówno redukowanie kosztów i nakładów, jak i ponoszenie kosztów i nakładów w zaplanowanym okresie, możliwie szybkie zamknięcie i rozliczenie okresu z uwzględnieniem projektów.

Uwaga
W przypadku procesów controller dysponuje danymi historycznymi, stabilnym systemem informacji zarządczej oraz stałym zespołem współpracowników. W projektach powyższe w zasadzie nie występuje. Teoretycznie rzecz biorąc, można założyć, że istnieje przynajmniej stała grupa kierowników projektów, ale w rzeczywistości wiele projektów prowadzonych jest samodzielnie przez procesowy manage-ment, i controller po prostu o nich nie wie.

Nietypowe oczekiwania związane z projektami to przede wszystkim użycie projektu jako instrumentu do zarządzania finansami w ramach ugrupowania gospodarczego (grupy kapitałowej). Wyróżnić tutaj można:

• transfery kosztów lub przychodów (projekt pozwala sterować wynikami finansowymi spółek, a tym samym realizować m.in. założony cel podatkowy),
• transfery kapitałów (projekt jest organizacyjnym instrumentem finansowania działalności jednej spółki przez drugą, w tym także pozwala pozyskać kapitał celowy z zewnątrz),
• transfery pieniądza (w ramach projektu możliwa jest zmiana cash flow w dwóch lub więcej spółkach; występuje zawsze w połączeniu z transferem kapitału lub kosztu/wydatku).

Powyższe nietypowe działania zazwyczaj stanowią uzupełnienie „normalnych" celów projektu. Wadą jest wysoki dodatkowy koszt realizacji, np.: W sprzedaż wytworzonej w ramach projektu wartości niematerialnej i prawnej przez jedną spółkę dla drugiej wymaga powołania rzeczoznawcy w celu uzasadnienia ceny, wytworzenie środowiska do świadczenia usług wzajemnych pomiędzy spółkami jest produktem projektu, ale zastosowanie rozliczeń wzajemnych w praktyce wymaga bardzo dobrego uzasadnienia, tak aby uniknąć zarzutu niestosowania cen rynkowych.

Reasumując, projekt może być użyty jako instrument do sterowania wynikiem, płynnością oraz pasywami. Jednocześnie musi być tak zarządzany, aby controller miał szansę wywiązania się z typowych oczekiwań przed nim stawianych.

Marek Gmerski