Právní úprava změnového řízení v rámci implementace softwaru

Autor: JUDr. Lukáš Jansa | Vloženo: 8. 5. 2018 23:23 | Přečteno: 3655X

U složitých projektů dodávek softwaru, u kterých se předpokládá delší doba implementace, není neobvyklá aktuální potřeba na straně objednatele na změnu funkcionality softwaru či způsobu implementace nebo na straně dodavatele na úpravu cenových podmínek. V tomto směru je výhodou odpovídající úprava tzv. změnového řízení (Change Management) v samotné smlouvě o vývoji a implementaci softwaru. Tento článek nebude pojednávat o změnovém řízení v rámci servisní smlouvy, které slouží ke customizaci již užívaného softwaru, ale bude věnován výlučně změnovému řízení při vývoji a implementaci.

Důvody změnového řízení
Důvodů pro zahájení změnového řízení může být celá řada. Lze je rozdělit na předvídatelné a nepředvídatelné. Obecně je však možné konstatovat, že změnové řízení je vyvoláno stavem, kdy jedna či druhá strana má potřebu změnit rozsah projektu, harmonogram nebo cenové podmínky. Tento stav vzniká zejména z těchto důvodů:

Požadavky smluvních stran na změnu
Nové požadavky objednatele u rozsáhlejších dodávek softwaru mohou být dány časovým rozpětím mezi podpisem smlouvy a následným vývojem a implementací. Stejně tak nové požadavky mohou resultovat z měnících se podmínek IT prostředí, nové potřeby na fungování softwaru, množstevní potřeby licencí v důsledku snížení či zvýšení počtu zaměstnanců apod. U dodavatele může být nutnost změny ovlivněna úpravou cenových podmínek výrobce softwaru (pakliže není dodavatel výrobcem, ale pouze implementátorem), podceněním časového harmonogramu, apod. Stejně tak požadavek může být oboustranný, pokud se objeví nová smluvními stranami nepředvídaná okolnost, která při analýze či formulaci smlouvy nebyla známa.

Nedostatky analýzy
Analýza IT prostředí zákazníka a jeho potřeb je pro zpracování návrhu projektu vývoje a implementace naprosto klíčová. Jakékoliv vady ať už samotné analýzy nebo návrhu projektu se projevují při samotné implementaci softwaru, kdy objednatel zjišťuje, že software není úplně podle jeho představ. V tomto směru lze doporučit, aby výstup analýzy byl natolik dostatečné konkrétní a umožnil odpovídající konfrontaci aktuálních představ zákazníka s tím, co formuloval dodavateli během analýzy. Při zjištění vad analýzy je pak nutné zkoumat, kdo za vady odpovídá. To znamená, zda formulace dotazů na zákazníka byla správná, použita metodika analýzy byla vhodná a správně aplikovaná dodavatelem, zda informace sdělené objednatelem jsou dostatečně určité a odpovídají výstupu analýzy a zda protokol o převzetí analýzy neznamená, že dodavatel již neodpovídá za jakékoliv vady, jelikož objednatel se dostatečné seznámil s analýzou a vše odsouhlasil. V tomto směru bude klíčová pak smlouva o provedení analýzy, či část smlouvy o vývoji a implementaci, která danou činnost upravuje. U vad analýzy způsobených špatnou formulací požadavků či nesdělením důležitých informací objednatelem, by odpovědnost objednatele odůvodnila i zvýšení ceny. Nicméně při odpovědnosti dodavatele za vady analýzy by zvýšení ceny oprávněné nebylo a náklady spojené se změnou projektu by šly na vrub dodavatele, pokud smluvní strany se nedohodnou jinak.

Vadný implementační projekt
Vadný implementační projekt či jinak nazvaný dokument formulující funkcionalitu softwaru, akceptační kritéria a fáze implementace (návrh projektu, projektová dokumentace) může mít původ buď z chybné analýzy a jejího výstupu jak bylo uvedeno shora nebo z vadných formulací. Implementační projekt přebírá výstupy analýzy a dále je podrobněji rozvíjí a při převzetí chybných podkladů se tyto vady přenáší následně do samotného vývoje a implementace. Ani při odsouhlasení implementačního projektu, který bývá obvykle přílohou vlastní implementační smlouvy, nemusí být jeho vady odhaleny. Ty se projeví až následně. Druhou kategorií vad implementačního projektu jsou vady formulací funkcionality a akceptačních kritérií, kdy lze jako příklad uvést příliš obecné formulace funkcionality umožňující dvojí či ještě širší výklad. Objednatel tak může své požadavky v rámci širšího výkladu obecných definic konkretizovat natolik, že dodavatel vývoj takových funkcí při kalkulaci ceny nepředpokládal. Dodavatel pak má logicky snahu tyto požadavky objednatele podrobit změnovému řízení a navýšení ceny. Hledání a určení odpovědnosti může být u špatných formulací složité a ideálním řešení je dohoda o konkretizaci funkcionality softwaru.

Postupné upřesňování projektu
Další problémy vývoje a implementace vznikají u takového typu projektu, kde při podpisu smlouvy není znám úplný rozsah projektu a funkcionalita se definuje postupně v rámci jednotlivých fází. Nemusí jít nutně o agilní způsob vývoje a implementace, ale také o vývoj a implementaci probíhající v delších časových intervalech (např. půlročních, ročních), a to dokonce v horizontu několika let. Pokud je součástí postupného definování fází a jednotlivých částí vyvíjeného softwaru podmínkou dodržení na počátku stanoveného rozpočtu, pak může postupně vznikat rozkol v rozsahu postupně požadovaného softwarového řešení a cenových podmínek dosud akceptovaných dodavatelem. V takovém případě je důležité, aby změnové řízení stanovilo přesné postupy pro další vývoj a implementaci a případnou možnost úpravy ceny.

Vykolejení projektu neboli vývoj a implementace mimo smlouvu
Ne neobvyklým důvodem pro zahájení změnového řízení bývá situace, kdy k odlišnému vývoji a implementaci než je upraveno ve smlouvě, dochází fakticky činností obou smluvních stran. Typickou situací jsou změny dohodnuté v zápisech z projektových schůzek nebo emailem např. vedoucími projektu, ačkoliv ani projektový tým v rámci projektových schůzek nebo samostatně vedoucí projektu nebyli oprávněni takovou formou změnové řízení provést. Jestliže jsou prováděny bez smluvního zmocnění změny dohodnuté v zápisech z projektových schůzek a nedojde k jejich úpravě např. dodatkem smlouvy, pak jsou tyto změny neplatné. Objednatel není oprávněn tudíž požadovat dodání takto změněného softwaru a dodavatel naopak není oprávněn požadovat úhradu provedených změn mimo režim smlouvy. Jestliže již tento stav nastane, pak lze doporučit realizaci změnového řízení dle smlouvy a již dříve provedené dohody stvrdit nejlépe dodatkem či jiným dokumentem předvídaným smlouvou pro účely změn. Pokud by k tomu nedošlo, pak se pohybujeme v režimu tzv. bezdůvodného obohacení a diskuzí o jeho hodnotě. Tento problém a následné spory smluvních stran vznikají obvykle při prvním prodlení s dodržením harmonogramu nebo při předávání projektu v rámci akceptačních testů, kdy zákazník není s implementovaným softwarovým řešením spokojen. Reakcí objednatele je pak jeho diskuze o ceně, která nebyla dohodnuta v rámci sjednaného změnového řízení, smluvních pokutách z důvodu prodlení, případně dokonce nepřevzetí softwaru a odstoupení od smlouvy.

Samozřejmě každý případ je individuální a není ani vyloučeno, aby změnové řízení umožňovalo změnu nikoliv dodatkem, ale jakkoliv písemně (emailem, zápisem z projektové schůzky), a to i osobou odlišnou od statutárního zástupce, který podepsal implementační smlouvu.
Úprava změnového řízení

Implementační smlouva by neměla opomenout úpravu změnového řízení, jelikož její absence může vést k celé řadě sporů a nedorozumění při realizaci smlouvy. Standardní úpravu změnového řízení obvykle tvoří:

• Kompetence v rámci změnového řízení, to znamená určení osob, které mohou vznést požadavek na změnu a osob, které jsou oprávněny změny odsouhlasit, a to např. dle jednotlivých kategorií změn. Tato úprava je vhodná z důvodu vyšší flexibility, kdy např. některé menší změny smlouvy sjednávají pověření členové projektového týmu. V takovém případě je nejvhodnější zvolit formu přímého zmocnění uvedeného ve smlouvě.
• Kategorizace změn představuje rozdělení změn na podstatné a méně podstatné s jejich definicí, tak aby bylo zřejmé, které změny který projektový orgán schvaluje v rámci svých pravomocí a které již jsou v kompetenci statutárních orgánů. Proto je namístě vymezit úkony, k nimž jsou oprávněni členové projektového týmu, např. obsahově včetně uvedení nejvyšší možné hranice, jako je stanovení maximální částky pro zvýšení ceny nebo stanovení hodnoty vyjádřené jako procento z ceny.

Příklad úpravy kompetence a kategorizace změn:
„Řídící výbor je oprávněn schválit formou zápisu v rámci projektových schůzek pouze takovou změnu projektu, která znamená v součtu všech dosavadních změn změnu cenových podmínek maximálně o 5 %, změnu rozsahu projektu maximálně o 40 člověkohodin nebo posunutí konečného termínu pro předání Softwaru maximálně o 14 dnů. V ostatních případech je nutná změna formou dodatku k této smlouvě podpisem statutárních zástupců smluvních stran.“

• Způsob komunikace v rámci změnového řízení by měl upravit, jakou formou se předkládá požadavek na změnu (emailem, písemně či ústně na projektové schůzce), komu se adresuje, zda budou realizovány osobní schůzky za účelem dohody o změně atd.
• Odůvodnění změn předpokládá povinnost, aby každý požadavek byl řádně odůvodněn pro účely jeho posouzení druhou smluvní stranou.
• Postup změnového řízení znamená jeho zahájení předáním požadavku na změnu, jeho následné posouzení v určitém termínu druhou smluvní stranou a vyjednávání o změně s určením maximální doby.
• Úprava smluvních podmínek by měla obsahovat určení konkrétních změn ve vztahu k původnímu rozsahu, úpravu harmonogramu a cenových podmínek, případně další změny s odkazem na konkrétní ustanovení smlouvy.
• Forma úpravy smluvních podmínek může spočívat v tom, že veškeré změny je nutné upravit pouze dodatkem smlouvy nebo může definovat více forem úpravy, kdy nepodstatné změny předem definované budou provedeny oběma smluvními stranami podepsaným zápisem z projektových schůzek, ostatní podpisem dodatku ke smlouvě.
• Eskalace by měla stanovit jak postupovat v případě, že druhá strana změnu odmítne nebo vyjednávání o změně bude neúspěšné. Eskalovat lze tento spor z projektového výboru na vedoucí projekty s určením termínu pro vyjednávání a následně na statutární zástupce smluvních stran. Pokud ani tito nebudou v určitém termínu schopni se na změnách dohodnout, pak musí být dána možnost ukončení smlouvy.
• Ukončení smlouvy je logickým vyústěním neúspěšného změnového řízení, po všech stupních eskalace, pakliže jsou požadavky či okolnosti pro změnu tak zásadní, že beze změny by nebylo možné projekt dokončit. V tomto směru by měla být sjednána úprava dokončení dané fáze, resp. předání dosud zhotoveného a implementovaného softwaru s určením vypořádání dosud uhrazené či neuhrazené ceny, a to s ohledem na využitelnost dosud zhotovené a implementovaného softwaru pro objednatele.

Chyby změnového řízení
Existence smluvní úpravy změnového řízení ještě neznamená, že změnové řízení proběhne v souladu s těmito pravidly nebo bude mít očekávaný efekt. Nejčastějšími příčinami neefektivního změnového řízení jsou:

• Nedodržení smluvního postupu, kdy opět dochází k řešením mimo režim smlouvy, a to např. jednáním nekompetentních osob, překročení pravomocí jednajících osob, nedodržení formy výstupu změnového řízení (chybějící podpis, chybějící dodatek smlouvy atd.).
• Nedostatečná smluvní úprava změnového řízení, u níž absentuje některá z výše uvedených obsahových náležitostí nebo je vadná jiným způsobem (např. kompetence projektových orgánů se vzájemně překrývají).
• Nedostatečné narovnání předchozích vad vývoje a implementace či sporů může spočívat v opomenutí některých vad, které vyvolaly potřebu změnového řízení, nebo nedostatečné narovnání vzniklých sporů ohledně postupu projektu. Nastane-li taková situace spočívající ve vadném či sporném postupu projektu, pak lze jen doporučit dostatečné vymezení těchto vad a formu jejich odstranění či prevenci dalšího vzniku v podobě dohodnuté změny smlouvy či formou narovnání sporných postupů.
• Nedostatečná úprava změny projektu, která může být dána chybnými podklady a analýzou požadované změny, nedorozuměním stran a což resultuje v následnou vadnou specifikací změny apod. Co když úpravy změnového řízení ve smlouvě chybí?

Jestliže implementační smlouva neobsahuje ustanovení o změnovém řízení, a to ani v minimální podobě, pak se použije občanský zákoník a rozhodující pro možnost změny smlouvy bude, zda byla cena sjednána dle rozpočtu s výhradou (neúplnosti či nezávaznosti) či jako pevná cena, resp. cena dle rozpočtu bez výhrady.

V případě pevně stanovené ceny za dodávku softwaru jsou rozhodující pouze závěrečná ustanovení, která umožňují např. změnu smlouvy pouze formou písemných dodatků. Jejich obsah je zcela na vůli smluvních stran, jinak platí původní smlouva. Vedle toho však platí rovněž možnost zániku smlouvy z důvodu následné nemožnosti plnění za předpokladu, že plnění není nemožné jen proto, že lze software dodat za ztížených podmínek, s většími náklady, s pomocí jiné osoby nebo až po určené době. Obdobně toto platí u ceny vývoje a implementace stanovené dle rozpočtu (bez výhrad), kdy nemůže dodavatel požadovat zvýšení ceny ani tehdy, objeví-li se potřeba dalších prací k dokončení vývoje a implementace.

Stejně tak institut podstatné změny okolností (§1765 OZ) umožňuje při vzniku znevýhodnění jedné ze smluvních stran v intenzitě zvlášť hrubého nepoměru buď neúměrným zvýšením nákladů vývoje a implementace, anebo neúměrným snížením hodnoty vývoje a implementace, že aby dotčená strana se domáhala vůči druhé straně obnovení jednání o smlouvě. Podmínkou však je, že jde o takovou podstatnou změnu okolností, že změnu nemohla rozumně předpokládat ani ovlivnit a že skutečnost nastala až po uzavření smlouvy, anebo se dotčené straně stala až po uzavření smlouvy známou. Uplatnění tohoto práva neopravňuje dotčenou stranu, aby odložila plnění. Stejně tak právo na obnovu smluvních jednání nevznikne, převzala-li na sebe nebezpečí změny okolností. Občanský zákoník dále umožňuje v § 2620, aby v případě vzniku zcela mimořádné nepředvídatelné okolnosti, která dokončení vývoje a implementace podstatně ztěžuje, aby soud podle svého uvážení rozhodl o spravedlivém zvýšení ceny za dokončení implementace softwaru, anebo o zrušení smlouvy a o tom, jak se strany vypořádají.

Byla-li však cena určena na základě cenového rozpočtu daného s výhradou neúplnosti či nezávaznosti, může dodavatel požadovat zvýšení ceny, objeví-li se při realizaci smlouvy potřeba činností do rozpočtu nezahrnutých. Musí se však jednat o činnosti a jejich náklady nepředvídatelné v době uzavření smlouvy (u výhrady neúplnosti), a v případě výhrady nezávaznosti, náklady účelně vynaložených činností, které nevyhnutelně převýší náklady zahrnuté do rozpočtu. Nesouhlasí-li objednatel se zvýšením ceny, určí zvýšení ceny na návrh zhotovitele soud.

Dodavatel ovšem nebude mít nárok na určení zvýšení ceny, jestliže neoznámí nutnost překročení rozpočtované částky a výši požadovaného zvýšení ceny bez zbytečného odkladu poté, kdy se při realizaci smlouvy ukázala jeho nevyhnutelnost.

Objednatel může na druhou stranu bez zbytečného odkladu odstoupit od smlouvy, požaduje-li dodavatel zvýšení o více než 10 % ceny podle rozpočtu. V tomto případě je objednatel povinen nahradit zhotoviteli část ceny odpovídající rozsahu částečného provedení díla podle rozpočtu.

Je zřejmé, že zákonné řešení není z pohledu žádné smluvní strany ideální, a to pro formulace umožňující různý výklad a pro očekávané dlouhotrvající soudní řešení. Taková situace by do projektu vnesla chaos a jeho pozastavení na velmi dlouhou dobu.

Závěr
Závěrem lze doporučit, aby si smluvní strany ve smlouvě o dodání softwaru odpovídajícím způsobem upravili přesný postup sjednávání změn, a to při zachování dostatečné flexibility s možností eskalace i exitu smlouvy. Z praktických zkušeností je však většina problémů způsobena nedodržování sjednaných smluvních podmínek či špatnou smluvní formulací klíčových ustanovení. Nicméně důvodů pro nutnost změn u větších projektů je celá řada a chybějící úprava změnového řízení v implementační smlouvě k jistotě smluvních stran nijak nepřispívá.

Tento článek byl publikován v časopise IT Systems č. 7-8/2017

JUDr. Lukáš Jansa, jansa@lawyer.cz
Autor působí jako advokát v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři. Je spoluautorem odborné publikace Softwarové právo a Internetové právo.