Strategija izlaska iz IT projekta – ostati ili napustiti brod koji tone?

04.
Sep 2019.

Autor teksta: Tijana Žunić Marić

Nina Raškov, advokatska kancelarija Žunić

Autor teksta: Nina Raškov

Ugovori o pružanju usluga razvoja softvera (za koje se i u domaćem pravnom prometu najčešće koristi terminologija „Software Development Agreement” ili „SDA”, što će biti primenjeno i u ovom tekstu) često imaju sudbinu poznatih holivudskih brakova. Na početku očekivanja partnera su visoka, a budućnost deluje blistavo. Ipak, posle nekog vremena naslućuje se kraj, a raskid može biti turbulentan i skup.

To je obično momenat kada ugovorne strane shvate da se nisu razumele od samog početka, što pokazuje da nisu regulisana sva pitanja na adekvatan način. Kod SDA[1] svaka odredba je vrlo važna i, ako joj se ne posveti dovoljna pažnja, detalj može biti seme razdora u budućnosti.

Ugovori o pružanju usluga razvoja softvera su specifični zbog svoje kompleksnosti. Master Software Development Agreement neizostavno prate Specifikacije, Instrukcije, Rasporedi, Licence, kao i Ugovori o nivou usluga (poznat kao „Service Level Agreement” ili „SLA”), što čini ove sporazume složenim aktima, sačinjenim od više različitih dokumenata, koji često nisu sastavljeni tako da čine koherentnu celinu. Kada se na to doda činjenica da je veoma teško do detalja predvideti tehničke zahteve i specifkaciju za razvoj softvera, te da je inicijalna procena troškova celog projekta često nerealna, ne začuđuje da najmanje 50% projekata propadne pre očekivanog završetka.

Za pružaoca usluge najveći problem nastaje kada plaćanje naknade izostane ili kasni, kada klijent dodatnim instrukcijama pokušava da proširi prvobitno ustanovljen obim projekta (poznato kao „scope creep”) ili kada pružalac usluge veruje da su unapred definisani kriterijumi prihvatanja za isporuku dela softvera ispunjeni, dok klijent to osporava. S druge strane, za klijenta problem nastaje kada isporuka softvera, odnosno njegovog dela, kasni ili kada kvalitet softvera nije u skladu sa tehničkom i/ili funkcionalnom specifikacijom.

Komplikacije nastaju, još češće, kada pružalac usluga projekat ne izvršava sam, već angažuje podizvođače (poznat kao „one throat to choke” model). Alternativna opcija je multi-vendor IT ugovor, kod koga, zbog postojanja više pružalaca usluga nadležnih za pojedine delove projekta, složenost pravnih pitanja i mogućnost spora raste eksponencijalno.

Imajući u vidu da ovi ugovori najčešće traju više godina, treba dodati i izazove koje sa sobom nose fluktuacije na tržištu (npr. promene u cenama rada/usluga/sredstava za rad itd.), ali i promene u poslovnoj strategiji klijenta, koje ne moraju biti u vezi sa samim izvršenjem ugovora (na primer: promena na insourcing sa outsourcing biznis modela).

Sve navedeno, izlazak iz Ugovora o pružanju usluga razvoja softvera sa što manje štete po ugovorne strane, predstavlja pravi izazov.

single vendor it ugovor
multi vendor it ugovor

Faktori za donošenje prave komercijalne odluke

Kada dođe do eskalacije u odnosu između ugovornih strana, načelno, ugovorne strane imaju sledeće opcije:

  • da kroz otvaranje novih pregovora modifikuju ugovor i održe ga na snazi po principu „hajde da damo još jednu šansu”;
  • da se raziđu raskidom ugovora po principu „sve smo probali i ne ide”;
  • da raskinu samo deo ugovora, a u drugom delu nastave saradnju po principu „nije sve tako crno”.

Da bi se donela najbolja komercijalna odluka treba razmotriti tehničku i pravnu stranu projekta. Tehnička pitanja su: šta se pogrešno desilo u praksi – nerealni rokovi, nedostatak resursa, nepredviđeni troškovi, menjanje obima projekta i sl. Pravna pitanja su: šta ugovor i merodavno pravo kažu na sporno pitanje.

Pitanje br. 1: Dokle smo stigli – tehnički nivo?

Radi donošenja konačne odluke treba utvrditi tehnički nivo do sada izvršenih usluga. Klasična pitanja koja će klijent razmatrati su sledeća:

  • U kojoj smo fazi? Na primer: da li smo u fazi izrade arhitekture projekta, u fazi razvoja i dizajna, u fazi testiranja, u fazi diplojmenta i sl.
  • Koliko kasnimo? Koliko bi obim projekta trebao da se smanji da bismo ispoštovali rok predviđen ugovorom?
  • Da li nam je važnije da očuvamo obim projekta ili da ispoštujemo rok?
  • Da li je pružalac usluga u stanju da završi projekat? Da li dizajn sistema dozvoljava da se angažuje novi pružalac usluga u kratkom roku?
  • Koliko je dodatno ulaganje?

Poseban problem se može javiti kada klijent proceni da pružalac usluga nije u stanju da tehnički dovrši projekat, ali projekat je trenutno u stadijumu da bi bilo neefikasno (ili čak nemoguće) da ga dovrši neki novi pružalac usluga. Tada klijent može biti zarobljen u ugovoru i prisiljen na ustupke pružalaca usluga, samo da bi se okončao projekat.

Pitanje br. 2: Šta kaže ugovor?

Ugovor o poslovnoj saradnji za pružanje usluga,

Praksa pokazuje da često ugovorne strane nisu svesne svih prava, obaveza i odgovornosti koje proističu iz ugovora, iako je to najvažnije za opstanak projekta.

Na primer: može biti jasno da je rok od godinu dana za završetak projekta probijen, ali da ne bude jasno čijom krivicom. Tada sledi pitanje da li pružalac usluga sada ima obavezu da završi projekat bez dodatnog troška za klijenta ili pak klijent treba da plati uvećanu naknadu zbog izmena koje su prouzrokovale kašnjenje?

Kada se javi problem u toku realizacije projekta, najčešće odredbe koje će vam pomoći da odlučite da li da otvarate nove pregovore ili da raskidate ugovor su sledeće:

1. Tačke provere (Checkpoints)

Odredbe koje omogućavaju da se proveri da li je izvršenje ugovora konzistentno tokom njegovog trajanja, kao i da se sam ugovor uskladi sa promenama u obimu projekta i u troškovima. Benčmarking (Benchmarking) je dobar formalan način da se revidira ugovor sa održavanjem na snazi. Ovakva opcija omogućava da se pružalac usluga obaveže da koriguje cenu usluge razvoja softvera sa cenom na definisanom tržištu, u tačno određenim vremenskim periodima. Ipak, veoma je važno da se ovakva mogućnost pažljivo predvidi u ugovoru kako bi obezbedila korist i jednoj i drugoj strani. Ukoliko je ova odredba sačinjena isključivo uzimajući u obzir klijentove interese, pružalac usluge može biti nemotivisan da održi visok standard usluge, što predstavlja samo Pirovu pobedu.

2. Procedura za kontrolu promena (Change Control Procedure)

Gotovo svaki IT projekat podrazumeva promenu nekog elementa, kako tehničkog tako i pravnog, pa je predviđanje procedura za kontrolu promena od esencijalnog značaja. Ugovorne strane treba da se sporazumeju oko procedure koja se primenjuje u slučaju da određena izmena treba da se implementira, ustanovljavajući jasne parametre za prihvatljivost određene izmene. Ipak, ovde treba biti svestan da ugovorne strane možda nisu uvek pratile proceduru za kontrolu promena propisanu ugovorom, već da su u praksi, tokom izvršenja ugovora, implicitno usvojile drugačije mehanizme za izmenu. Zbog toga je važno da se analiziraju svi formalni zahtevi za promenu kontrole, ali i držanje ugovornih strana tokom trajanja ugovora, kako bi se utvrdilo sve što može da utiče na pravnu poziciju.

3. Pravo da se angažuje novi pružalac usluga

Ako ste klijent, poželećete da ste ugovorili mogućnost da uvedete dodatnog pružaoca usluga u svoj projekat razvoja softvera. Klijentima se često savetuje da ne prenose celokupan projekat na samo jednog pružaoca usluga, jer je činjenica da kada jedan pružalac usluga ima potpunu kontrolu nad projektom raskid ugovora za klijenta je mnogo teži. Osim toga, uvođenjem dodatnog pružaoca usluga pregovaračka pozicija klijenta se pojačava, naročito u pogledu cene.

4. Plan izlaska i tranzicije

Ugovor treba da predviđa proceduru koja se primenjuje u slučaju prestanka ugovora, jasno definišući prava i obaveze obe ugovorne strane. Takve odredbe uglavnom predviđju sastavljanje „Plana izlaska” ili „Menadžment izlaska” ili „Raspored izlaska” („Exit Schedule”) u pogledu liste svih aktivnosti neophodnih da se izvrši transfer na novog pružaoca usluga ili na klijentov in-house tim.

Na primer: šta se dešava sa opremom ili pristupom softveru koje klijent sada treba da dopremi novom pružaocu usluga i da li sadašnji pružalac usluga ima obavezu da asistira u takvoj tranziciji? U zavisnosti od toga kako su regulisana prava intelektualne svojine, da li klijent treba da obezbedi prenos tih prava sa pružalaca usluga. Nažalost, to često nije slučaj jer ugovorne strane, prilikom pregovaranja, nisu sklone fokusiranju na pitanja prestanka ugovora i tranzicije, kao što ni bračni parovi ne vole da pričaju o razvodu na dan venčanja.

5. Prava intelektualne svojine

Za konačnu odluku da li će opstati Ugovor o pružanju usluga razvoja softvera biće važno pravno pitanje šta se dešava sa pravom intelektualne svojine. Najvažnije je jasno razgraničiti ko će biti titular prava intelektualne svojine na softveru, materijama i dokumentima, ukoliko se projekat završi u ovoj fazi?

Ukoliko klijent nije nosilac prava na softveru po ugovoru, već prava zadržava pružalac usluga (u celini ili delu), otpada mogućnost zamene drugim izvršiocem, koji bi nastavio gde je prvi izvršilac stao.

Nije retko da naizgled zanemarljive jezičke nijanse dovedu do ovakvog rezultata. Na primer: upotreba budućeg vremena u formulaciji (na primer: „…će preneti prava intelektualne svojine”) umesto sadašnjeg vremena (na primer: „prenosi prava intelektualne svojine”) može da bude veoma problematična, jer, čak i u slučaju da je pružalac usluga odgovoran za povredu ugovora zbog propusta u isporuci usluge, ne znači da će klijent steći vlasništvo nad pravima intelektualne svojine.

Osim toga, u ugovorima koji su sačinjeni po pravu jedne od država u okviru SAD, pogrešne jezičke nijanse mogu da dovedu do istinski problematičnih rezultata. Na primer: ugovorne strane često opisuju softver kao „work made for hire”, verujući da će time automatski preneti sva vlasnička prava na softveru na klijenta. Ipak, po pravilima autorskog prava u okviru SAD programski kod ne može spadati u tzv. „work made for hire”.

Za izvršioca, s druge strane, je bitno šta će biti sa intelektualnim pravima na njegovim ranijim projektima i kako jasno odvojiti prava intelektualne svojine koje pružalac već ima (nešto što se naziva „Background technlogy”) od onih koji proizlaze iz novog IT ugovora.

Klijent je zapravo taj koji će insistirati na preciznom regulisanju prava intelektualne svojine, jer u odsustvu izričitog normiranja u ugovoru, naše pravo (kao i npr. englesko pravo i mnoga druga širom sveta) štite autora dela – u ovom slučaju izvršioca kao stvaraoca softvera.

6. Koje pravo se primenjuje na ugovor

Ukoliko ugovor jednostavno ne definiše kako da se reši sporno pitanje koje je nastalo između ugovornih strana, ugovorne strane će morati da potraže odgovor u merodavnom pravu. Merodavno pravo je ono pravo čiju su primenu ugovorili klijent i pružalac usluga. Ugovori o pružanju usluga razvoja softvera su često ugovori sa međunarodnim elementom, u kojima ugovorne strane potiču iz različitih država. Odgovore na sva pitanja koja se ne nalaze u ugovoru, ugovorne strane će naći u pravnim propisima i sudskoj praksi te države. Tu je obično problem što će ugovorna strana koja ima jaču pregovaračku moć insistirati da merodavno pravo bude pravo države iz koje ta ugovorna strana potiče. Kada dođe do eskalacije u odnosima između ugovornih strana, mnogo težu poziciju će imati onaj ugovarač koji je prihvatio merodvano pravo druge ugovorne strane.

Komercijalna odluka

ugovor o pruzanju usluga razvoja softvera, software development agreement, sla ugovor

Nakon sagledavanja tehničkih i pravnih aspekata, ugovorne strane dolaze do konačne odluke da li nastavljaju zajedničkim putem. Ukoliko je to slučaj, potrebno je da se ugovor potpuno ažurira u skladu sa novim dogovorom. Ukoliko je komercijalna odluka negativna, moguć je raskid celog ugovora ili delimični raskid.

A. Delimičan raskid ugovora – jer nije baš sve tako crno

ugovor o pružanju usluga

Prvo pitanje koje sebi morate postaviti jeste, da li postoje delovi ugovornog odnosa koji su vredni spašavanja?

Delimičan raskid se uglavnom svodi na to da li se obaveze u projektu uopšte mogu razdvojiti. U kompleksnim ugovornim odnosima, ključno pitanje će biti da li je od početka ugovorna struktura bila podešena na način da dozvoljava delimičan raskid. Ukoliko prilikom sačinjavanja Ugovora o pružanju usluga razvoja softvera ova opcija nije dovoljno dobro razmotrena i razrađena, postoje male šanse da će ona u praksi moći da se primeni.

Ukoliko je pak moguće da jedan deo ugovora opstane, sledi aneksiranje ugovora i definisanje koje odredbe su prestale da važe, a zatim i usklađivanje ostalih odredaba sa naročitim akcentom na odredbama o plaćanju, rokovima i isključenju i/ili ograničenju odgovornosti.

B. Raskid – jer smo sve drugo probali i nije išlo

ugovor o pružanju usluga

Razmotrili ste sve opcije da sačuvate ugovor, ali jednostavno održavanje ugovora na snazi se pokazuje kao veći teret i/ili trošak, nego razumno rešenje. Tada je jedini način da raskinete ugovor. Kada donesete tu odluku, ne samo da niste završili posao, već ste zapravo na početku. Kao što je ugovor (zaključenje i izvršenje) jedan ozbiljan proces, tako sada predstoji jedan potpuno novi (i verovatno znatno neprijatniji) proces – raskidanje ugovora.

Ovo je vreme aktiviranja odredbe o raskidu za koju ste mislili da vam neće ni zatrebati. Dok sporazumni raskid ugovora nije problem, akcenat se mora staviti na jednostranom raskidu, odnosno pitanjima ko, kada, zašto i kako može jednostrano raskinuti ugovor. Ugovori često propuštaju da razlikuju raskid zbog povrede ugovora i raskid ugovora bez određenog razloga, što može da bude veliki propust, ako se nađete u ovoj situaciji.

Osim toga, ukoliko želite da raskinete ugovor, jer smatrate da je druga ugovorna strana povredila ugovor, ključna odredba će biti ona koja definiše koje povrede se smatraju tzv. „raskidnim uslovom” (Material breach). Takva odredba će predviđati određenu skalu težine povreda ugovora, dok će raskidni uslov predstavljati ozbiljne povrede, odnosno povrede koje imaju ozbiljan efekat. Ukoliko je takva odredba precizno definisana, ona će vam dati odgovor na pitanje da li imate pravo da raskinete ugovor sa drugom stranom.

ugovor o pruzanju usluga razvoja softvera, software development agreement

Sledeće pitanje koje se nameće je da li ćete imati pravo da tražite naknadu štete zbog povrede ugovora od druge strane i da li postoje ograničenja u visine te naknade štete.

Odgovor na to pitanje pružaju odredbe o ograničenju i/ili isključenju odgovornosti, koje bi morale biti neizostavni deo svakog Ugovora o pružanju usluga razvoja softvera.

Pružalac usluga će često insistirati na ugovaranju gornje granice vrednosti do koje može da odgovara za naknadu štete, što bi moralo da bude srazmerno vrednosti samog SDA. Klijent može biti neprijatno iznenađen, ako u momntu eskalacije utvrdi da je pružalac usluga ograničio iznos potencijalne odgovornosti za štetu na samo delić stvarne štete koju klijent trpi.

Međutim, odgovornosti za neispunjenje pojedinih obaveza, koje proističu iz ugovora, će često biti neograničene po visini. U situaciji kada raskidate ugovornu saradnju, za klijenta će biti veoma važno da može da utvrdi te oblasti. Uglavnom će odgovornost pružaoca usluga biti neograničena u pogledu povrede prava intelektualne svojine, jer klijent želi da se zaštiti od odgovornosti za naknadu štete prema trećim licima u iznosu koji je nepoznat i neograničen. Ugovaranje neograničene odgovornosti je karakteristično i za povredu podataka koji čine poslovnu tajnu, a u koje mogu da spadaju i podaci o ličnosti.

Sve navedeno ukazuje da će strategija izlaska iz Ugovora o pružanju usluga razvoja softvera zavisiti od više faktora, od kojih će jedan od najznačajnijih biti sama sadržina ugovora. Drugim rečima, odluka o kraju će vas uputiti na sam početak. Zato je nemoguće previše istaći važnost pregovaračkog procesa i kvalitetnog sačinjavanja ugovornih odredbi, bez kojih nema ni uspešnog partnerstva, ali ni lakog razlaza.

[1] U ovom tekstu se učestalo koriste termini na engleskom jeziku zbog činjenice da domaći pravni institut ne poznaje brojne pravne institute vezane za ovu vrstu ugovora, a koji potiču iz pravnih sistema u okviru SAD i Velike Britanije. Osim toga, u IT sektoru je uobičajeno korišćenje ovih termina na engleskom jeziku.

Najnovije:

NEWSLETTER

NEWSLETTER

KONTAKT

KONTAKT