Mit o ustalonej cenie umowy „na system informatyczny”

Data: 2011-04-04
Autor: Sebastian Konkol

Wśród zamawiających wytworzenie oprogramowania, wdrożenia systemów, czy ich integracje – szczególnie w biurach zakupów dużych firm – funkcjonuje głębokie przekonanie, że kontrakt o ustalonej cenie (tzw. Fixed Price) zabezpiecza interesy zamawiającego i wystarczy jedynie wycisnąć tak niską cenę, jak to tylko możliwe, bo i tak całe ryzyko pozostaje po stronie wykonawcy. „Mylny błąd”, cytując jedną z reklam, a co gorsze, na podstawie takiego, mylnego przeświadczenia podejmowanych jest wiele kluczowych decyzji – nie tylko finansowych.

Po pierwsze, wycena wykonawcy kalkulowana w czasie składania oferty opiera się o wiele założeń odnośnie tego, czym system ostatecznie ma być – w tym czasie są znane jedynie częściowo oczekiwania zamawiającego i zupełnie nie ma podstaw do rzetelnego, inżynierskiego oszacowania wysiłku. Wycena przygotowywana jest w oparciu o doświadczenia z podobnych prac (u innych klientów) i bez wątpienia włącza budżet na ryzyko – budżet, który staje się ostatecznie wynagrodzeniem wykonawcy bez względu na to, czy ryzyko wystąpi, czy nie. Rzecz jasna, wykonawcy pamiętają o różnych „wpadkach” z wcześniejszych projektów i dorzucają sporo ryzyka do tej wyceny. Prawda jest taka, że jeśli przebieg negocjacji sprawia, że budżet ryzyka staje się zagrożony, wykonawcy potrafią dodać do umowy takie zapisy, które przeniosą to ryzyko na zamawiającego, z czego negocjatorzy nawet nie zdadzą sobie sprawy. Aż do momentu wystąpienia tego ryzyka.

Po drugie, to zamawiającemu potrzebny jest system informatyczny, a nie wykonawcy. Największe ryzyko ponosi więc zamawiający, bo – w razie trudności wynikających na przykład z niedoszacowania projektu przez wykonawcę – jemu potrzebny system nie zostanie dostarczony. Być może zamawiający będzie dochodził sądownie różnych odszkodowań, ale praktyka jest taka, że będzie musiał zapłacić wykonawcy co najmniej poniesione koszty, a sprawa będzie się ciągnęła latami. W tym czasie systemu nie będzie, co będzie największą szkodą właśnie dla zamawiającego. Kontrakt Fixed Price to narzędzie wprowadzone wiele lat temu i stosowane do kontraktów wytworzenia systemów informatycznych wtedy, kiedy powstawały one w metodzie wodospadowej (ang. Waterfall). Ta metoda została jednak uznana przez świat inżynierii oprogramowania za beznadziejną jakoś na przełomie lat 80. i 90. ubiegłego wieku. Od tamtej pory oprogramowanie tworzy się iteracyjnie, a ostatnio nawet agile’owo. Tylko jakoś formy kontraktowe do tego nie dorosły, choć istnieją takie, które odpowiadają nowocześniejszym metodom wytwarzania oprogramowania.

Po trzecie, zamawiający wierzy, że dzięki ustalonej cenie umowy sprawuje on kontrolę nad realizacją systemu. Tak naprawdę, umowa o ustalonej cenie daje mu jedynie bardzo iluzoryczne poczucie kontroli nad przedsięwzięciem, bo umowa taka karze zamawiającego za każde niedociągnięcie na etapie zbierania wymagań (kosztowne procedury żądań zmian w zakresie prac), a pierwsze wyniki realizowanego systemu są widoczne niemal na samym końcu prac. Nie czarujmy się, wykonawcy mają znacznie większe doświadczenie w takim ustawianiu procedur zmian, żeby zamawiający musiał odpowiednio odcierpieć za błędne decyzje. Mają także znacznie większe doświadczenie (realizacja takich projektów to ich core business) w zabezpieczaniu się na okoliczność późniejszych problemów. Jeszcze bardziej kosztowne jest to po zakończeniu projektu, kiedy to układ sił się znacznie zmienia – zamawiający staje się petentem wykonawcy, który zwykle może dyktować warunki współpracy.

Ustalona cena nie zapewnia żadnego bezpieczeństwa zamawiającemu – wręcz przeciwnie, staje się karą dla zamawiającego niemal od samego początku projektu. Kara ta jest wymierzana z jeszcze większą stanowczością po zakończeniu projektu – im bardziej „upierdliwy” był klient w trakcie projektu, tym więcej będzie płacił za każdą modyfikację systemu po zakończeniu tego projektu. Jeśli tylko dostrzeże (tak naprawdę), że to on jest zainteresowany rzeczywistym powodzeniem realizacji projektu informatycznego, powinien zmienić swoje nastawienie na działania zdecydowanie bardziej partnerskie, uwzględniające także rozwój myśli inżynierii oprogramowania wraz z formami kontrakowymi.

komentarze 2 dla

  1. Marek Jagła napisał(a):

    W kwestii kontraktów różnej maści – „fixed price” czy też ” time&material” polecam artykuł:
    ” Optional Scope” autorstwa Kent Beck, First Class Software,Dave Cleal.
    Poniekąd nawiązujesz do niego w powyższym artykule ale bez nazwania. Po przeczytaniu założeń do optional targają mną przeciwstawne uczucia: z jednej strony idea super ale czy do zrealizowania w czym innym niż „extreme programming”? Czy da się to przetestować na kontrakcie np. na analizę systemów czy też doradztwo? Kto wie, może w najbliższym czasie będę miał okazję to sprawdzić i wtedy podzielę się przemyśleniami.

  2. Sebastian Konkol napisał(a):

    Kontrakty skonstruowane w myśl „optional scope” to bardzo fajna sprawa. Niestety, martwa w naszych realiach. Dokąd zawieranie umów ma dwa etapy (najpierw uzgodnienia, a później twarde targowanie się), to zawsze w drugim etapie będą decydować „ludzie od zakupów”, a nie merytorycznie zaangażowani w dany kontrakt. A ludzie od zakupów chcą mieć problem z głowy – fixed price zdejmuje z nich kompletnie odpowiedzialność i są szczęśliwi. A że w ostatecznym rozrachunku ich firma dostanie – za przeproszeniem – gówno, to już ludzi od kontraktów nie interesuje. :-)
    Do pary z „optional scope” polecam metodę wyceny „real options value” – równie postępowa i równie niewykorzystywana, choć wiele dowodów teoretycznych i empirycznych jest na to, że wycena projektów informatycznych w tradycyjnych kategoriach NPV/IRR/DCF i takich tam prowadzi do niewłaściwych decyzji. No i co z tego? :-)

Pozostaw komentarz