Definice vad a incidentů

Vady či incidenty softwaru je možné dle metodiky ITIL definovat jako neplánované přerušení služby nebo omezení kvality služby informačních technologií. Incidentem je v kontextu ITIL rovněž porucha hardwarového zařízení a softwaru, která dosud negativně neovlivnila sjednané vlastnosti servisovaného softwaru nebo služby. V tomto textu vadou budeme rozumět chybu, která má původ ve zdrojovém kódů softwaru, za kterou nese odpovědnost dodavatel (poskytovatel servisu). Incidentem pak bude přerušení či omezení funkcionality softwaru v důsledku okolností, za které nenese poskytovatel či dodavatel odpovědnost a nejde o vadu softwaru.

Vady mohou být skrytými vadami softwaru, mohou vzniknout vadnou implementací, v důsledku jednání samotného uživatele či z jiných příčin. Servisní činnost by měla řešit vady bez ohledu na příčinu jejího vzniku, pokud není dohodnuto a výslovně vymezeno jinak.

Zcela zásadní je vždy úprava servisní smlouvy, a to definice jak vad (chyb) softwaru, tak incidentů, a na ně vázané odpovědnosti. Určení této odpovědnosti může (ale nemusí) mít dopad na cenu servisních služeb, a to v závislosti na sjednané záruce či původu vzniku vady či incidentu.

V podstatě jsou možné následující varianty:

1. Vady softwaru, na které se vztahuje záruka (pokud je sjednána) – jsou odstraňovány zdarma nebo v ceně servisu.
2. Mimozáruční vady softwaru, za které nese odpovědnost dodavatel – jsou odstraňovány v paušální ceně servisu nebo mimo paušální cenu servisu za sjednanou cenu (např. hodinová sazba).
3. Mimozáruční vady, za které nese odpovědnost objednatel – jsou odstraňovány v paušální ceně servisu nebo mimo paušální cenu servisu za sjednanou cenu.
4. Incidenty, které jsou způsobeny okolnosti vylučujícími odpovědnost (objednatele i poskytovatele) – jsou odstraňovány v paušální ceně servisu nebo mimo paušální cenu servisu za sjednanou cenu (např. hodinová sazba), případně poskytovatel servisních služeb splní svou povinnost už lokalizací příčiny incidentu (není-li na jeho straně) a informováním objednatele.

Jen pro úplnost doplňuji, že záruka není vždy součástí dodávky softwaru a pokud je výslovně sjednána, pak může být tato záruka zcela nahrazena úpravou servisní smlouvy (což doporučuji z důvodu obtížného rozlišení záručních či mimozáručních vad), případně může mít odstraňování vad pod zárukou úplně jiné lhůty pro odstranění (zpravidla delší) než je sjednáno v servisní smlouvě.

Kategorizace vad a incidentů

Klíčovou je v servisní smlouvě úprava jednotlivých kategorií vad a incidentů, a to dle dopadů na provoz softwaru a fungování objednatele. Tato kategorizace má význam z pohledu doby reakce a odstranění vady a sankcí za neodstranění. A také jak si později ukážeme, i z pohledu určování časové priority odstraňování vad.

Je logické, že kritické vady způsobující naprostý výpadek funkcí softwaru by měly být odstraňovány prakticky okamžitě, tak aby škody byly co nejmenší. Naopak u vad, které nezpůsobují zásadní omezení fungování softwaru, není nutné stanovit dobu odstranění v řádu několika hodin, resp. je možné nechat na vůli objednatele, zda v konkrétním případě stanoví i delší termín, než je doba odstranění dle smlouvy. Na základě sjednaných kategorií vad a incidentů je tedy stanovena priorita pro jejich řešení. Tato priorita může být součástí evidence (např. v podobě tzv. tiketů) vedené o řešení každé vady či incidentu.

Ke stanovení jednotlivých kategorií a v návaznosti na to i doby odstranění se někdy používá tzv. analýza dopadů na business (Business Impact Analysis – BIA). Ta umožňuje definovat dopady na chod objednatele, pokud dojde k výpadku softwaru, a to i se zohledněním doby trvání takového výpadku. Závažnost dopadů může být hodnocena na základě exaktních kritérií (ztráta tržeb, zpoždění s doručením zboží zákazníkovi apod.), ale významnou roli hrají také veličiny jako např. poškození dobrého jména objednatele u jeho zákazníků. V praxi bývá často využíváno také subjektivní hodnocení míry dopadů manažery jednotlivých procesů činností objednatele. Popsaný postup umožňuje identifikovat požadavky kategorizace vad a doby jejich odstranění.

Za příklad kategorizace mohu uvést následující:

Určitě není vhodné mít více kategorií než čtyři nebo méně než tři, a to právě z důvodu potenciálního sporu o klasifikaci jednotlivých vad a incidentů. Velmi důležité je ve smlouvě určení, kdo provádí klasifikaci jednotlivých vad a incidentů. Lze předpokládat, že objednatel bude mít snahu přiřadit i méně závažným vadám a incidentům kategorii vyšší, a naopak poskytovatel kategorii nižší. Smluvní úprava může spočívat nakonec v tom, že primární kategorizaci provede objednatel v rámci hlášení vady a poskytovatel bude mít právo uplatnění překlasifikace za předpokladu řádného odůvodnění. V případě, že ani poté by nebyla shoda na kategorii vady či incidentu, pak je vhodné sjednat víceúrovňový eskalační proces na osoby stojící výše ve firemní hierarchii. Složitému způsobu klasifikace vad lze částečně předejít také tím, že v servisní smlouvě jsou u jednotlivých kategorií vad vyjmenovány demonstrativně konkrétní příklady projevů dané vady.

Souběh vad a incidentů

V praxi se lze setkat i se souběhem více vad a incidentů buď shodných či různých kategorií, kdy lze zvolit dvojí řešení:

1. Poskytovatel má povinnost řešit všechny vady najednou ve lhůtách pro odstranění – zde však hrozí nebezpečí z prodlení a současně to, že bude odstraněna vada, která v daném okamžiku nemá prioritu (například první hlášená vada kategorie B bude odstraněna o x hodin dříve než druhá vada kategorie B, jejíž odstranění v daný okamžik má daleko větší prioritu pro objednatele).
2. Objednatel má pravomoc určit prioritu řešení vad při jejich souběhu. Tím mám na mysli možnost určení vady, která má být odstraněná jako první, s ohledem na to, že situace objednatele (provozní potřeba) vyžaduje odstranění vady, která dle smlouvy např. není významná, ale vzhledem k provozní potřebě objednatele významnou v daném okamžiku je. Tento způsob řešení souběhu vad umožňuje na druhé straně poskytovateli soustředit veškeré síly na řešení právě toho nejpalčivějšího problému na úkor méně významného.

Stanovení priority řešení konkrétní vady či incidentu by mělo být stanoveno s ohledem na aktuální dopad na provoz a podnikání objednatele, a nejen dle dopadu na software a kategorizace sjednané ve smlouvě. Některé menší vady softwaru v oblasti fakturace či logistiky mohou být totiž závažnější (z pohledu cash flow či fungování firmy), nežli shodné vady v oblasti HR systému. Smluvní strany by si měly tak stanovit i způsob stanovení priorit řešení vad a změna této priority by měla mít vliv i na dobu odstranění vady, které priorita řešení dána nebyla.

Odstranění vady – vyřešení incidentu, problém workaround

Odstranění vady lze provést několika způsoby, přičemž primárním cílem je umožnit objednateli bezvadné užívání softwaru. V praxi dochází buď k přímému úplnému odstranění vady (fixed) nebo k zajištění náhradního řešení (workaround), např. formou konfigurace, která zajistí funkčnost softwaru či omezenou funkčnost, ale při odstranění projevu nahlášené vady funkcionality softwaru. Možnost náhradního řešení však musí být sjednána ve smlouvě výslovně, protože striktně vzato o odstranění vady nejde.

Pro splnění doby odstranění vady a pro případné uplatnění náhrady škody či smluvní pokuty je významný stejně jako počátek běhu i okamžik odstranění vady. Pokud se jedná o rozsáhlejší opravu formou zásahu u objednatele, pak je možné podepsat protokol s uvedením času odstranění, menší závady se považují za vyřešené okamžikem jejich odstranění nebo potvrzením o odstranění ze strany objednatele nebo tzv. fikcí odstranění, kterou se rozumí uplynutí určité doby od odstranění vady, pokud toto není zpochybněno.

Problém při řešení vad a incidentů může ovšem přinést náhradní řešení (workaround), a to ve dvou směrech:

1. Workaround může být definitivní a současně znamenat náročnější uživatelské chování (např. více úkonů) nebo může být dočasný. V těchto případech je nutné stanovit lhůtu pro úplné odstranění vady se zohledněním sankcí (smluvní pokuty) a náhradou škody.
2. Workaround způsobí snížení závažnosti kategorie vady či incidentu. V takové případě by mělo být stanoveno, že např. pokud workaround byl uplatněn u vady kategorie A a došlo ke snížení na vadu kategorie B, pak je poskytovatel oprávněn řídit se při odstraňování původně hlášené vady kategorie A lhůtami platnými pro vady kategorie B. A takto by se k dopadům workaroundu mělo přistoupit i z pohledu eventuálně uplatněných smluvních pokut.

Závěr

Závěrem lze shrnout, že smluvní strany by neměly v servisních smlouvách opomenout odpovídající úpravu kategorií vad, určení strany oprávněné ke klasifikaci či podmínky eskalačního procesu. Dále lze doporučit, aby jednotlivé kategorie vad a incidentů reflektovaly potřeby objednatele a byla dána objednateli možnost určení priorit řešení vad při jejich souběhu. Stejně tak i workaround by neměl automaticky znamenat vyřešení vady či incidentu, ale pouze náhradní řešení, které je dočasné či spadající do nižší kategorie vady či incidentu.

JUDr. Lukáš Jansa, jansa@lawyer.cz Autor článku je společníkem advokátní kanceláře Jansa, Mokrý, Otevřel & partneři. Je spoluautorem odborných publikací „Softwarové právo“ a „Internetové právo“.