Kara umowna

Upadła ostatnio, z niejakim hukiem, koncepcja budowy drugiej linii metra w Warszawie. Wszystkie oferty okazały się zdecydowanie za drogie. Prasa trochę popisała o drożyźnie, trochę o zmowach cenowych, ciszej o wycinaniu części oferentów z sztucznych powodów (ot, brak potwierdzonego tłumaczenia na polski dyplomu któregoś z chińskich inżynierów). Między tym wszystkim dopatrzyłem się także kwestii bardzo dobrze mi znanej z projektów informatycznych. 

Miasto zażyczyło sobie bardzo wysokich kar umownych za przekroczenie terminu zakończenia budowy. Euro 2012! A firmy oceniły ryzyko i dodały sobie te kary do ceny.

Czy to działa?

Kary umowne są stosowane w ogromnej ilości kontraktów na zrobienie czegoś dużego. Autostrady, mostu, stadionu, systemu informatycznego, instalacji telekomunikacyjnej, … Jeśli wykonawca nie dostarczy systemu w terminie, płaci karę. Czasem stałą sumę za każdy dzień spóźnienia, czasem bardziej złożone kary progresywne. Ma to oczywiście wzmocnić motywację do zrobienia co trzeba we właściwym czasie.

Czy kara umowna daje coś zamawiającemu? Wyobraźmy sobie, że w czerwcu 2012 okolice stadionu Narodowego są totalnie rozkopane ze względu na budowę metra. I wpływają milionowe kary. Albo, że firma wprowadzająca nową usługę telekomunikacyjną musi opóźnić start o pół roku ze względu na spóźniający się system bilingowy – i zostaje przegoniona przez głównego konkurenta, do tego ponosząc z niepotrzebnym wyprzedzeniem koszty ludzi, sprzętu i budynków (przy których tak koszty samego systemu, jak kary, są stosunkowo skromne). Albo, że kraj traci jakieś dotacje czy dopłaty, bo nie zdążył zbudować systemu potrzebnego do ich rozliczania.

Kara umowna jest faktycznie – karą. Wykonawca odczuwa ją boleśnie, odbiorcy pomaga niewiele.

Co do funkcji motywacyjnej – nawet bez kar przeciąganie się projektu stanowi dla wykonawcy koszt (ludzi, sprzętu, niemożności brania się za kolejne zadania). Oczywiście, są szczególne przypadki, typu firma nabrała za dużo projektów i szacuje, odpuszczenie którego będzie najtańsze, ale to wyjątek, a nie norma.

Koszt

Można by wzruszyć ramionami. Źle zrobili, niech płacą, nawet niech splajtują. Tyle, że w większości wypadków kary umowne ciężko kosztują … klienta.

Chodzi nie tylko o to, że organizacja zobowiązująca się takie kary płacić wlicza je z góry do ceny, więc de facto nie tyle wykonawca płaci karę jeśli się spóźni, co odbiorca znacznie przepłaca, jeśli do spóźnienia nie dojdzie. Także – mniejsze firmy, mające mniejsze rezerwy finansowe, po prostu w takich przetargach nie startują. Nawet jeśli są w stanie wykonać projekt. Nawet jeśli … ostatecznie go robią - ale jako podwykonawcy.

A zamawiający płaci. To tu jest jedno z wyjaśnień zagadki, czemu systemy informatyczne dla administracji państwowej albo dużego biznesu są tak drogie (poziom ryzyka i niepewności jest w nich zawsze duży, więc i margines błędu trzeba przyjmować spory).

Dodajmy jeszcze, że ewentualna plajta wykonawcy jest poważnym problemem – kto będzie konserwował i rozwijał system? No i naturalną konsekwencję – oddawanie niedotestowanych, nie w pełni gotowych albo byle jak zrobionych elementów, byle w terminie.

No to jak

Nie chcę dawać tutaj żadnych cudownych recept, bo ich nie ma. Siedzę po wykonawczej stronie barykady, artykuł napisałem by przypomnieć, że kary – a także inne kontraktowe zobowiązania – obciążają obie strony. W mikroskali widzę, że zadania realizowane bez zdecydowanej presji czasu nieraz kończą się szybciej niż te, w których od początku jest przykręcana śruba – choć oczywiście wiele tu zależy tak od ludzi, jak od specyfiki pracy do wykonania.

Myślę, że współpracujące strony powinny dążyć nie do karania się nawzajem, a do tego, by – jeśli coś dzieje się źle – zauważyć to jak najwcześniej i albo wycofać się z projektu, albo go ograniczyć, albo w inny sposób zmodyfikować. Dla wszystkich jest to korzystniejsze.

W metodyce agile development mamy na wpół konsultacyjny model rozwoju systemów informatycznych. Klient płaci za czas i materiał (albo podobnie), za to regularnie, w ciasnych cyklach, powstają działające produkty (o powoli narastającej funkcjonalności). Zakończenie każdego cyklu wiąże się z przeglądem projektu, przy okazji którego klient może skorygować lub zmienić zakres funkcjonalny, a nawet wstrzymać lub zakończyć projekt (otrzymując wszystko, co do tego momentu wykonano). To podejście trochę szokuje (czy jeśli oni nic nie będą robić, też mamy płacić?, jak przewidzieć pełny koszt?) ale tak naprawdę minimalizuje ryzyko obu stron. No – ale to rewolucja.

Bardziej dostosowany do potrzeb biurokratyczno-formalnych wariant mamy, gdy pierwotne zamówienie jest małe. Niewiele funkcjonalności, stosunkowo niski koszt, gotowość do wyrzucenia do kosza jeśli coś pójdzie niewłaściwie. Oraz zobowiązanie do współpracy przy dalszym rozwoju. Jeżeli to inicjalne zamówienie kończy się powodzeniem, system jest rozbudowywany w formie wielu drobnych zleceń dotyczących konkretnych uzupełnień funkcjonalności.