Umowy na realizację oprogramowania dedykowanego są na ogół bardzo skomplikowane. Obejmują kilka usług o odmiennym charakterze i dotyczą produktu, który funkcjonuje najczęściej tylko w wyobrażeniach zlecającego. Jak skonstruować umowę, aby udało się to wyobrażenie zrealizować?

Dobra umowa musi odzwierciedlać cały proces powstawania oprogramowania: analizę wymagań, projektowanie systemu, programowanie, testowanie, wdrożenie i opiekę serwisową. Każdy z tych etapów różni się rodzajem prac do wykonania, efektem końcowym i, co często jest pomijane, rozłożeniem ciężaru obowiązków spoczywających na obu stronach umowy.

Sporządzenie umowy na taką usługę nie jest łatwe jeszcze z jednego powodu. Produkt, który ma dopiero powstać i zaspokoić biznesowe potrzeby zlecającego, jest dopiero wyobrażeniem, koncepcją. Oznacza to, że umowa może ulec zmianie na każdym etapie przekształcania się w system. Jak więc pogodzić to zróżnicowanie usług i nieokreśloność przedmiotu umowy z konieczną precyzją i jednoznacznością przy uzgadnianiu czy interpretacji jej zapisów? Przede wszystkim sytuacja wymaga pewnej dojrzałości obu stron zawierających umowę.

Po pierwsze, znajomości i zrozumienia charakteru pracy nad systemami informatycznymi. Po drugie, świadomości wspólnego celu, jakim jest nie tyle wytworzenie oprogramowania, co zaspokojenie potrzeby biznesowej odbiorcy. I po trzecie, zaufania zbudowanego na solidnych podstawach, czyli jasno sprecyzowanych wymaganiach, właściwie przeprowadzonym procesie wyboru dostawcy usługi oraz przestrzeganiu zasad fair play.

Co, jak i kiedy

Podjęcie decyzji o zakupie każdego systemu powinno mieć uzasadnienie biznesowe i być poprzedzone analizą istniejących lub projektowaniem nowych procesów, które zostaną zinformatyzowane. Ważne jest też zidentyfikowanie celów, jakie mają zostać dzięki temu osiągnięte oraz zdefiniowanie mierników, określających stopień ich realizacji. Zebrane w ten sposób informacje pozwalają ocenić efektywność przedsięwzięcia. Są też kluczowe na kolejnych etapach realizacji projektu i niezbędne do właściwego sformułowania umowy. W oparciu o nie powinny powstać: specyfikacja systemu (dokumentacja techniczna jako podstawa wykonania i odbioru prac programistycznych), projekt wdrożenia (określający powiązania procesów realizowanych przez nowy system z pozostałymi procesami w organizacji), harmonogram uruchomień poszczególnych modułów i na koniec zakres oraz harmonogram szkoleń użytkowników systemu.

Takie podejście gwarantuje stworzenie właściwej pod względem prawnym i zadaniowym płaszczyzny porozumienia z przyszłym wykonawcą usług. Zapewnia jednocześnie odpowiedni poziom bezpieczeństwa obu stronom.

Specyfikacja a realia współpracy

Pierwsze problemy związane z brakiem właściwie zdefiniowanych wymagań pojawiają się jeszcze przed przystąpieniem do konstruowania i negocjowania szczegółowych zapisów umowy. Z jednej strony odbiorca oczekuje od dostawcy przedstawienia jak najbardziej szczegółowych i wiążących warunków realizacji zamówienia, kosztów i harmonogramu prac. Z drugiej jednak dostarcza ograniczone informacje na temat swoich potrzeb, celów i planów.

Ekstremalne sytuacje tego typu wcale nie są rzadkie i zdarzają się nie tylko na portalach aukcyjnych, gdzie zlecający zgłasza do licytacji wykonanie systemu opisanego jedynie kilkoma zdaniami. Niektórzy licytujący dowcipnie polecają odesłanie takiego zlecenia do serwisów wróżbiarskich.

Uzasadnionym powodem powściągliwości w przekazywaniu wymagań przy wycenie wstępnej może być konieczność ochrony informacji, które stanowić mogą o przewadze konkurencyjnej danej firmy. Mam tu na myśli dane dotyczące sposobu funkcjonowania firmy, pomysł na jego usprawnienie lub koncepcja nowego biznesu. Powinny one jednak zostać udostępnione razem z pełną specyfikacją, ponieważ wybór oferenta na podstawie nie-precyzyjnych szacunków jest posunięciem bardzo ryzykownym.

W tym przypadku problem można stosunkowo łatwo rozwiązać, dzieląc proces wyboru dostawców na dwa etapy. W pierwszym zawęża się listę potencjalnych zleceniobiorców, oceniając ich zdolność do zrealizowania projektu. Następnie, z firmami spełniającymi zadowalająco to kryterium, podpisuje się umowę zobowiązującą do zachowania tajemnicy handlowej (NDA – Non Disclosure Agreement). Dopiero w etapie drugim, po otrzymaniu pełnej specyfikacji, wybrani zleceniobiorcy konkurują warunkami wykonania zlecenia – ceną, czasem etc.

Innym z powodów precyzowania wymagań w sposób niewystarczający może być zwyczajny brak odpowiednich kompetencji po stronie klienta. W przypadku małych i nieskomplikowanych systemów specyfikacja może zostać wykonana wspólnym wysiłkiem dostawcy i klienta. Gdy w grę wchodzi większy system, lepiej jest umowę na realizację oprogramowania rozszerzyć o wykonanie analizy potrzeb i opracowanie koniecznej specyfikacji. Jednym z rozwiązań jest w tym wypadku podpisanie dwóch odrębnych umów – na stworzenie specyfikacji i docelowego systemu, z możliwością rozstania się po etapie wykonania projektu i wyceny. Takie rozwiązanie ma kilka dodatkowych zalet. Klient ma przede wszystkim możliwość wcześniejszego sprawdzenia zleceniobiorcy. Natomiast wykonawca lepiej pozna specyfikę wymagań zleceniodawcy. Szanse na stworzenie rozwiązań w określonych technologiach informatycznych, czasie i kosztach weryfikowane są natychmiastowo. Co więcej, nie dysponując specyfikacją, dostawca będzie zmuszony zawyżyć cenę oprogramowania, aby pozostawić margines bezpieczeństwa związany z ewentualnymi zmianami w założeniach projektu. Wadą tworzenia szczegółowej specyfikacji może być natomiast konieczność uwzględnienia dodatkowych wymogów w procesie wyboru dostawcy oprogramowania.

Mirosław Sztorc
Jako manager IT w Power Media zarządza działem realizującym oprogramowanie dedykowane. Zajmuje się głównie budowaniem właściwych relacji między klientem a zespołem projektowym.

Komentarze są zamknięte.

Kontakt

IFIRMA SA
ul. Grabiszyńska 241B
53-234 Wrocław

tel.: +48 71 769 43 00
fax: +48 71 321 00 16
e-mail: office@ifirma.pl

KRS: 0000281947
NIP: PL-898-16-47-572
REGON: 931082394
Nasz profil na Google+

Nasze certyfikaty