Pomimo upływu czasu i nieustannego rozwoju metodologii i podnoszenia poziomu wiedzy, realizacja dużych przedsięwzięć informatycznych nadal jest obarczona ogromnym ryzykiem niepowodzenia. W tym kontekście można postawić pytanie, czy znaczącej roli nie odgrywają tu zbyt niskie wymagania stawiane dostawcom przez kupujących? Czy nie jest tak, że dostawcy nie dedykują do prac wystarczających środków, gdyż nie wymagają tego kupujący?

Doświadczenia z rynku polskiego pokazują, że w większości przypadków kupującym najbardziej zależy na ograniczeniu początkowych kosztów przedsięwzięć informatycznych. Jednocześnie często nie rozumieją oni ani roli, ani wpływu poprawnej definicji zakresu prac na całkowite koszty i jakość osiągniętych rezultatów.

Zadaniem kupującego powinno być zapewnienie sobie możliwości egzekwowania wysokiej jakości i poziomu prowadzonych prac - i to już na etapie negocjacji warunków i zakresu współpracy. Niestety, obserwacja obecnej praktyki pozwala postawić tezę, iż większość kupujących nie przywiązuje należytej wagi do roli negocjacji kontraktowych i nie rozumie roli kontraktu w procesie współpracy z dostawcą, a kontrakty z obszaru IT należą do najbardziej zaniedbywanych.

Oczywiste nie znaczy zrozumiałe

Tabela 1

W dzisiejszych czasach coraz większą wagę przywiązuje się do formalnych metodyk prowadzenia projektów informatycznych. Wiele metodyk, zbiorów dobrych zasad czy modeli właściwie z dnia na dzień zdobywa popularność. Trudno w dzisiejszych czasach spotkać kierownika projektu, który nie wiedziałby, czym jest PMBOK, CMMI czy PRINCE2. Jednocześnie ogromna liczba firm posiada certyfikat zgodności systemu jakości z normą ISO 9001.

Przedstawiane w normach, metodykach i modelach dobre praktyki powinny pozwolić zorganizować procesy związane z wytwarzaniem czy wdrażaniem oprogramowania w taki sposób, aby projekty informatyczne kończyły się - w przeważającej części - sukcesem. Jak się jednak okazuje, dużo łatwiej zapoznać się z dobrymi praktykami, niż stosować je w praktyce.

Ogromnym problemem, szczególnie w polskich warunkach, jest brak praktycznych doświadczeń wyniesionych z rzeczywistych projektów. Jest to najczęściej efekt braku możliwości współpracy z osobami, które takie doświadczenia posiadają, a w konsekwencji mogłyby je przekazać swoim młodszym współpracownikom.

Ludzie i ich wiedza są podstawowym elementem procesów wytwórczych oprogramowania. Wiedza formalna jest zdobywana w procesie edukacji (szkoła, studia, szkolenia i lektura). Jednocześnie ogromne znaczenie ma wiedza nieformalna (gromadzona poprzez nabywanie doświadczenia, szczególnie na zasadzie mistrz-uczeń).

O ile w Polsce nie brakuje osób z wysokim poziomem wiedzy formalnej, o tyle niewiele osób dysponuje wiedzą wynikającą z osobistych doświadczeń. Przyczyn takiego stanu rzeczy należy upatrywać w dynamicznym rozwoju sektora IT, który następował w Polsce w pierwszej połowie lat 90., gdy nasze kontakty z innymi krajami, gdzie inżynieria oprogramowania stała na znacząco wyższym poziomie, były bardzo ograniczone. Większość osób kierujących dzisiaj projektami IT rozpoczynała swoją karierę informatyczną właśnie w tamtych latach.

Jednocześnie wiedza wynikająca z nabytego doświadczenia kosztuje bardzo dużo. Pensja doświadczonego szefa projektu z wieloletnim stażem, który miał możliwość pracować w trakcie swojej kariery z autorytetami w tej dziedzinie, będzie w Polsce ok. sześć razy wyższa niż pensja osoby z niewielką praktyką. Osoby te mogą nawet posiadać analogiczne certyfikaty i kwalifikacje formalne. Jest jednocześnie bardzo mało prawdopodobne, aby osoba bez doświadczenia była w stanie poprowadzić duży projekt i osiągnąć zadowalające wyniki.

Podpiszemy, bo jesteście miłe chłopaki

Tabela 2

Okazuje się, że nie jest najważniejsze według jakiej metodyki prowadzony jest projekt. Najważniejsze, by ludzie biorący udział w projekcie wiedzieli co robią, gdyż stoi za nimi osobiste doświadczenie wyniesione z wielu projektów oraz stosowania różnorodnych metodyk i modeli.

Można by dojść do wniosku, że wystarczyłoby skierować do prowadzenia projektu odpowiednio doświadczony zespół, aby zagwarantować sukces. Tutaj staje na przeszkodzie aspekt finansowy. Można oczywiście stworzyć zespół profesjonalistów lub choćby zapewnić udział w projekcie jednej osoby z bogatym doświadczeniem, ale to znacząco podniesie koszty projektu.

Realia wolnego rynku gwarantują nam, iż dostawca przeznaczy do projektu najtańsze zasoby, na jakie zgodzi się klient - odbiorca systemu. Dostawcy wiedzą, że najważniejsze dla nich jest podpisanie korzystnego kontraktu. Każdy dostawca ma swój wzór kontraktu, nad przygotowaniem którego głowiły się zapewne najbardziej znane kancelarie krajowe i międzynarodowe. Nie ma wątpliwości, iż zawarte tam zapisy w pełni zabezpieczają interes dostawcy. Oczywiście wolą dostawców nie jest oszukiwanie swoich klientów. Przygotowują oni swoje wzory ze świadomością, że powinny one być tylko punktem wyjścia do dalszych negocjacji i ustalenia końcowego kształtu umowy.

Uzgodnienia kontraktowe (zarówno dotyczące zakresu projektu, jak i warunków współpracy na dobre i złe czasy) są chyba najbardziej zaniedbywanym aspektem projektów informatycznych. Niektóre polskie firmy potrafią podpisać ze swoimi dostawcami usług IT kontrakty tak dla nich niekorzystne, że aż trudno sobie wyobrazić przyczynę takiego stanu rzeczy. Wbrew temu, co niektórzy mogliby sobie tutaj pomyśleć, to w praktyce najczęściej spotykaną przyczyną takiego stanu rzeczy okazuje się brak czasu osób nadzorujących IT w firmie.

Kontrakty często nie gwarantują żadnego poziomu bezpieczeństwa w sytuacji utraty dobrych relacji z dostawcą. Obserwując nawet bardzo duże i renomowane firmy działające na rynku polskim, można łatwo dojść do wniosku, iż często brak jest po stronie kupujących umiejętności lub chęci negocjowania korzystnych warunków współpracy z dostawcą technologii IT.

 

Jakość wymuszona

Dlaczego nie zawsze istnieje dostateczna wola negocjacji korzystnych warunków współpracy? Ważnym czynnikiem jest wiara we własną nieomylność i strach przed przyznaniem się do własnej niewiedzy przez osoby odpowiedzialne za negocjacje i wybór dostawcy. W sytuacji, gdy zapadła decyzja o wyborze konkretnego dostawcy, trudno jest przyznać tym, którzy tę decyzję podjęli, że dostawca oferuje niekorzystne warunki współpracy. Jednocześnie firmy przykładają zbyt dużą wagę do negocjacji ceny za usługi IT, bardzo pobieżnie traktując natomiast kwestie zakresu usług oraz ustaleń mających wpływ na bezpieczeństwo biznesowe.

W efekcie cena zostaje obniżona, ale jednocześnie ulega okrojeniu zakres projektu i odpowiedzialność dostawcy. Za elementy usunięte z zakresu projektu i tak trzeba będzie zapłacić w ramach rozszerzeń zakresu prac. To jednak nastąpi już po podpisaniu umowy i będzie kosztowało znacząco więcej, niż gdyby od razu było wliczone w podstawową cenę usługi.

Tabela 3

Dla zachowania równowagi pomiędzy stronami niezbędne jest wynegocjowanie warunków, które gwarantują uczciwe zasady współpracy pomiędzy dostawcą a kupującym. Osiągnięcie tego celu wymaga zarówno wiedzy prawniczej, umiejętności negocjacji, jak i ogromnej wiedzy informatycznej. Warunki komercyjne (cena) muszą być negocjowane jednocześnie z warunkami dotyczącymi zakresu i harmonogramu prac, poziomu usług oraz kar i podziału ryzyka pomiędzy dostawcę a kupującego.

Pierwszym krokiem w procesie zapewnienia partnerskich warunków współpracy powinno być zrozumienie różnic w podejściu do wdrożenia i negocjacji pomiędzy dostawcami a kupującymi (tabela 2).

Zrozumienie różnic w podejściu pozwala określić, jakie elementy kontraktu z dostawcą powinny być dla kupującego najważniejsze i na jakie powinniśmy położyć nacisk w procesie negocjacji.

Jednocześnie pewne podstawowe kryteria powinny być spełnione praktycznie w każdym przypadku, szczególnie jeżeli mamy do czynienia z usługami o długotrwałym charakterze. Do tej kategorii należą przede wszystkim usługi outsourcingu IT (tabela 3).

Najważniejsze, byśmy pamiętali, że złe zdefiniowanie relacji z dostawcą prowadzi zazwyczaj do znacznego wzrostu kosztów, gdyż koszt początkowy (zapisany w umowie) nie jest kosztem całkowitym, zaś rozszerzenia zakresu usług są jednym z podstawowych źródeł przychodów wielu dostawców IT. Dołożenie starań, by umowa z dostawcą była korzystna także dla odbiorcy, jest nie tylko prawem, ale i obowiązkiem każdego kupującego. 

Z życia wzięte Przykład 1 - Ogólna pułapka Często umowy powołują się na "Warunki ogólne" świadczenia usług. W większości przypadków owe "Warunki ogólne" nie mogą być akceptowalne dla kupującego. W żadnym przypadku "Warunki ogólne" nie mogą być podstawą świadczenia usług o znacznej wartości, gdyż zapewniają tylko ochronę interesów dostawcy. Dlatego nigdy nie akceptujemy "Warunków ogólnych" w przypadku usług na outsourcing! Przykład niekorzystnego zapisu (dla kupującego): "Usługi objęte niniejszą Umową będą świadczone zgodnie z "Warunkami ogólnymi świadczenia usług" obowiązującymi u Dostawcy. Warunki to zostały przesłane Kupującemu za pośrednictwem poczty w dniu DD.MM.YYYY" Prawnicy dostawcy na pewno długo pracowali nad każdym z punktów owych warunków ogólnych - dostawca wszak zapłacił im za to, by były to warunki korzystne dla niego. Przykład 2 - Eliminacja konkurencji Czasem dostawcy dążą do uniemożliwienia korzystania przez kupującego z usług i ofert innych dostawców usług IT, poprzez zapisy bezpośrednio lub pośrednio zabraniające współpracy z innymi. Zazwyczaj związane są z tym wysokie stawki, bez możliwości renegocjacji i w powiązaniu z bardzo długim czasem trwania umowy (utrzymanie, rozwój, outsourcing). Przykład: "Niniejszym Kupujący zobowiązuje się, iż w trakcie trwania niniejszej Umowy nie będzie korzystał z usług innych firm, świadczących usługi konkurencyjne w stosunku do Dostawcy. W szczególności Kupujący zobowiązuje się do dokonywania zakupów wszelkiego wyposażenia i sprzętu komputerowego u Dostawcy. (...) W przypadku, gdyby Kupujący chciał zaangażować jakieś strony trzecie, Kupujący zapewni, iż taka strona trzecia podpisze z Dostawcą umowę o zachowaniu poufności przed przystąpieniem do realizacji usług dla Kupującego". To wbrew pozorom zapis o daleko idących konsekwencjach, pozwalający tak sformułować dostawcy ową "umowę o zachowaniu poufności", że żadna normalna firma jej nigdy nie podpisze. Przykład 3 - Ograniczenie odpowiedzialności Nierzadko zdarza się sytuacja, w której poziom odpowiedzialności finansowej dostawcy jest określony na bardzo niskim poziomie - brakuje jakiejkolwiek motywacji do utrzymywania wysokiego poziomu usług. Błędne zapisy ujawniają się dopiero w sytuacji konfliktu czy nieporozumienia. Do tego dochodzi wyłączenie odpowiedzialności za najbardziej prawdopodobne awarie - takie jak utrata danych, zakłócenie biznesu, naruszenie bezpieczeństwa czy włamanie. Przykład: "Całkowita odpowiedzialność Dostawcy wynikająca z tej Umowy nie może przekroczyć 12,5% wynagrodzenia zapłaconego przez Kupującego w kwartale, w którym miało miejsce wydarzenie, które spowodowało stratę, jeżeli Kupujący opóźnił się z jakąkolwiek płatnością w ciągu 18 miesięcy poprzedzających chwilę wystąpienia wydarzenia powodującego stratę. (...) W żadnym przypadku Dostawca nie jest odpowiedzialny za utracone korzyści lub szkody będące skutkiem zakłóceń biznesu Kupującego czy utraty danych (...)". I wystarczy, że dostawca nie wystawi w tym kwartale żadnej faktury, na podstawie której można by wypłacić wynagrodzenie... Przykład 4 - Ograniczenie poziomu odpowiedzialności za błędy Zawężona definicja błędu, poprzez odniesienie do dokumentacji. Dokumentacja nigdy nie opisuje wszystkich aspektów systemu, dokumentacja może zawierać (i zawiera) błędy. Wiele szczegółów nie jest opisywanych w dokumentacji (np. zasady zaokrąglenia VAT na fakturze...). Przykład: "Błędem jest każde zachowanie systemu niezgodne z dokumentacją". A co, jeśli dokumentacja jest niepełna? Zdarzać się mogą różne sytuacje, które nie są ujęte w dokumentacji. Inna sprawa to kwestia odpowiedzialności za błędy w dokumentacji.