Automatizace právních dokumentů: tři cesty a jejich limity

Podle čeho je srovnávám

Dívám se na 3 věci: kolik variant dokumentu existuje, jak často dokumenty vznikají a jak náročné bude řešení nastavit a udržovat.

První výpočet dělám ještě před výběrem nástroje. Pokud firma připravuje 40 dodatků měsíčně a u každého ušetří automatizací 12 minut, vychází to na 8 hodin za měsíc. Do stejného výpočtu je ale potřeba přidat údržbu šablony, kontroly výstupů a řešení chyb. Úspora času se obvykle uvádí snadno, náklady na provoz už méně.

Podobně jako u jiné automatizace se vyplatí nejdřív popsat současný proces a změřit jeho čas i chybovost. U dokumentů navíc potřebuji znát počet skutečných variant. „Máme 1 vzorovou smlouvu“ často znamená 1 šablonu a 9 zavedených způsobů, jak ji ručně přepsat.

Čas potřebný k přípravě neodvozuji jen od zvolené cesty. Záleží i na stavu podkladů a množství ručních zásahů, které je potřeba převést do šablony nebo pravidel. 1 čistá smlouva o mlčenlivosti a 10 historických vzorů plných ručních zásahů vyžadují zcela odlišnou přípravu.

1. Šablona ve Wordu nebo Google Docs

Nejjednodušší cesta je dokument s pojmenovanými poli. Název firmy, IČO, adresa, cena, datum a kontaktní osoba se doplní z formuláře nebo tabulky. Výstup se uloží jako nový dokument nebo PDF.

Tahle varianta se hodí pro dokumenty s pevnou strukturou. Typicky jde o objednávky, jednoduché dodatky, předávací protokoly, dohody o mlčenlivosti nebo pracovní dokumenty, ve kterých se mění hlavně identifikační údaje.

Začal bych 1 dokumentem a nejvýše 10 až 15 poli. Každé pole bych pojmenoval podle významu, například zakaznikico, ne text7. Potom bych připravil 5 testovacích případů: chybějící údaj, dlouhý název firmy, zahraniční adresu, nulovou částku a neobvykle dlouhý popis služby. Dlouhý text často odhalí problémy s formátováním, zejména v tabulkách ve Wordu.

Šablona se nehodí tam, kde se podle odpovědí přidávají celé články, mění odpovědnost stran nebo vybírá několik režimů ukončení smlouvy. Podmínky lze do kancelářských nástrojů doplnit, jejich přehlednost ale rychle klesá. Po několika úpravách už nemusí být jasné, proč se konkrétní odstavec v dokumentu objevil.

Volil bych ji pro firmu, která vytváří menší objem podobných dokumentů, nemá složitý schvalovací proces a dokáže určit 1 vlastníka šablony. Musí to být člověk, který má odpovědnost za změny šablony a rozumí jejímu použití.

2. Nástroj bez programování s formulářem a pravidly

Druhá cesta přidává rozhodovací logiku. Uživatel vyplní formulář a systém podle odpovědí vybere správnou šablonu, vloží klauzule, pošle dokument ke schválení a případně jej předá k elektronickému podpisu.

Hodí se pro dokumenty s několika předvídatelnými variantami. Například smlouva obsahuje jiný článek podle délky závazku, země zákazníka nebo způsobu fakturace. Podstatné je slovo předvídatelnými. Pokud obchodníci u každého případu vytvářejí novou kombinaci podmínek, formulář problém nevyřeší. Jen přenese složitost do jiného rozhraní.

Při návrhu bych oddělil 3 vrstvy. První jsou vstupní údaje. Druhá jsou pravidla, například „při splatnosti nad 30 dnů vyžádej schválení“. Třetí je text dokumentu. Právník pak může upravit klauzuli bez zásahu do formuláře a správce procesu může změnit schvalovatele bez přepisování smlouvy.

Před spuštěním bych vytvořil rozhodovací tabulku. Každý řádek představuje 1 podmínku, výsledek a osobu oprávněnou schválit výjimku. Pokud tabulka kvůli kombinování podmínek přestává být přehledná nebo v ní nelze změny snadno sledovat a testovat, je to signál, že jednoduchá platforma naráží na své limity. Rozhodující není samotný počet řádků, ale možnosti konkrétního nástroje a vazby mezi pravidly.

Nevýhodou bývá závislost na možnostech nástroje. Problém může nastat u složitých tabulek, vícejazyčných verzí, netypického číslování nebo napojení na starší firemní systém. Je potřeba ověřit také historii verzí, přístupová práva a záznam o tom, kdo dokument vytvořil a schválil. Tlačítko pro odeslání k podpisu samo o sobě nezajišťuje kontrolu nad procesem.

Tuto cestu bych doporučil firmě, které opakovaně vzniká větší objem dokumentů v několika stabilních variantách a která má jasná schvalovací pravidla. Nehodí se tam, kde je téměř každý dokument výsledkem individuálního vyjednávání.

3. Vlastní aplikace napojená na firemní systémy

Vlastní řešení dává smysl, když dokument není samostatný soubor, ale výsledek širšího procesu. Data přicházejí z CRM nebo účetnictví, systém kontroluje oprávnění, vytváří dokument, řídí schválení, posílá jej k podpisu a ukládá výsledek ke správnému zákazníkovi.

Hlavní výhodou je přesná kontrola nad pravidly a integracemi. Lze hlídat povinná pole, zabránit použití neplatné šablony a zaznamenat každé rozhodnutí. To je důležité hlavně tehdy, když výjimka ovlivňuje cenu, odpovědnost nebo délku závazku.

Právě rozhodnutí bych ale neautomatizoval bez rozmyslu. Systém může rozpoznat, že zákazník požaduje nestandardní limit odpovědnosti. Neměl by sám určit, zda je takový limit pro firmu přijatelný. U podobných hranic platí, že rozhodování s obchodním nebo právním dopadem má zůstat na konkrétním člověku.

Vlastní aplikace se nehodí firmě bez správce procesu, rozpočtu na změny a disciplíny při správě verzí. První vydání není konec práce. Mění se smluvní vzory, organizační role, zdroje dat i podpisové služby. Do rozpočtu je proto potřeba zahrnout nejen vývoj, ale také průběžné úpravy a podporu.

Zvolil bych ji pro proces, ve kterém objem dokumentů, počet napojení nebo riziko ruční chyby odůvodní náklady na vývoj a provoz. Nejdřív bych však stejný postup ověřil na jednodušší platformě. Vlastní vývoj má řešit potvrzený proces, ne financovat hledání toho, jak má proces fungovat.

Pro pevný dokument a malý objem bych začal šablonou. Pro stabilní varianty a schvalování bych zvolil nástroj bez programování. Vlastní aplikaci bych nasadil až ve chvíli, kdy existují změřené objemy, popsaná pravidla a člověk odpovědný za jejich údržbu.

Rozsah změny se u jednotlivých cest liší. U šablony se obvykle upravuje zdrojový dokument, u nástroje s pravidly také související podmínky a schvalování a u vlastní aplikace mohou změny zasáhnout napojené systémy. Čím více vazeb řešení obsahuje, tím více míst je potřeba při úpravě zdrojového textu nebo pravidla zkontrolovat.