Sutarčių automatizavimas per 4-6 savaites

Trumpai

• Vieno didelės apimties sutarties tipo, pavyzdžiui, NDA ar užsakymo formų, automatizavimas sutaupo realių valandų ir ciklo laiką dažnai sutrumpina iš savaičių į dienas.
• Visą sutarties gyvavimo ciklą verta automatizuoti tik tada, kai vienas aiškus srautas jau veikia stabiliai. Iki tol daugiausiai duoda užklausų gavimas ir pasirašymas.
• Pirmiausia reikia integruoti CRM, nes būtent ten atsiranda sutarčių užklausos. Pasirašyti webhook, pakartojimai ir logai yra tai, kas neleidžia srautui tyliai lūžti ar dubliuoti dokumentų.
• Tvirtinimo taisyklės, teisėmis pagrįsti leidimai ir audito žurnalai yra tai, kas leidžia automatiškai sugeneruotą sutartį apginti, o ne atvirkščiai.
• Pradėti nuo vieno paprasto sutarties tipo ir plėstis palaipsniui yra greitesnis kelias iki grąžos nei platus diegimas iš karto.

Kas yra sutarčių automatizavimas ir kada jį pradėti

Sutarčių automatizavimas apima šešis gyvavimo ciklo etapus: užklausos gavimą, generavimą, peržiūrą ir tvirtinimą, pasirašymą, saugojimą su duomenų ištraukimu ir veiksmus po pasirašymo. Dauguma teisės komandų pradžioje automatizuoja tik vieną ar du etapus, ir tai teisingas instinktas. Bandymas iš karto automatizuoti visą ciklą yra dažniausia priežastis, kodėl bandomieji projektai įstringa. Verta atskirti tikrą automatizavimą nuo dviejų dalykų, su kuriais jis painiojamas. Elektroninis parašas išsprendžia tik pasirašymo žingsnį, bet palieka rengimą, nukreipimą ir duomenų surinkimą rankomis. Paprasta sutarčių saugykla duoda saugojimą ir paiešką, bet jei niekas jos automatiškai nemaitina, kažkas vis tiek turi įkelti kiekvieną baigtą sutartį ranka.

• Didelė apimtis: dešimtys ar šimtai to paties tipo sutarčių per ketvirtį, o ne keli unikalūs sandoriai.
• Kelios sistemos: tie patys duomenys - kliento pavadinimas, kaina, terminai - turi būti atnaujinti CRM, ERP ir pasirašytame PDF.
• Rizikuojama pratęsimų verte: sutartys su automatinio pratęsimo sąlygomis ar įsipareigojimais, kurie pamirštami, kai niekas jų centralizuotai nestebi.

Kokios grąžos tikėtis

Verslo pagrindimas remiasi trimis matuojamais dalykais: trumpesniu ciklo laiku, mažesniu administracinių valandų skaičiumi ir švaresniais duomenimis. Komandos, perėjusios nuo rankinio rengimo prie šablonais grįsto generavimo, paprastai pasiekia parašą per dienas, o ne savaites, nes dokumentas nebelaukia kažkieno pašto dėžutėje laisvos valandos. Paprastas skaičiavimas padeda geriausiai. Jei komanda per metus paruošia 200 užsakymo formų ir kiekviena užima 45 minutes rengimo bei priminimų, tai yra 150 valandų per metus vienam sutarties tipui. Sumažinus tai bent perpus, atsilaisvina apie 75 valandos vertingesniam darbui.

• Ciklo laikas nuo užklausos iki parašo, matuojamas dienomis.
• Administracinės valandos vienai sutarčiai prieš ir po automatizavimo.
• Klaidų dažnis: kaip dažnai neteisingas skaičius, pavadinimas ar nuostata patenka į pasirašytą dokumentą.
• Pratęsimų fiksavimo rodiklis: kiek pratęsti tinkamų sutarčių iš tiesų pažymima ir sutvarkoma laiku.

Kokios funkcijos iš tikrųjų svarbios

Keturios galimybių grupės skiria tikrą automatizavimo sistemą nuo gražaus šablonų aplanko. Padarius jas gerai, srautas atlaiko realią apimtį; praleidus vieną, spraga pasijunta per kelias savaites.

• Šablonų variklis ir nuostatų logika: vienas pagrindinis dokumentas su sąlyginėmis nuostatomis, kurios atsiranda ar dingsta pagal atsakymus užklausos formoje.
• Darbo srautų kūrimas be kodo: šakotas tvirtinimas, lygiagreti kelių padalinių peržiūra ir automatiniai priminimai, kai tvirtintojas neatsako laiku.
• Sutarčių duomenų ištraukimas: šalių pavadinimai, datos ir sumos surenkami į registrą, kuriame galima ieškoti, kad niekam nereikėtų atidarinėti keturiasdešimties PDF.
• Integracijos ir saugumas: webhook ir API, HMAC parašai įvykių tikrumui, audito žurnalai ir tapatybės patvirtinimas pasirašymo metu.

Kaip sukurti pirmąjį automatizuotą sutarčių srautą

Šeši etapai veda nuo rankinio proceso iki veikiančio bandomojo srauto, ir kiekvienas etapas turi natūralų sustojimo tašką, kuriame darbas patikrinamas prieš einant toliau.

1. Pasirinkti vieną bandomąjį sutarties tipą: didelės apimties ir mažo sudėtingumo, ir iš anksto apibrėžti sėkmės rodiklius.
2. Aprašyti užklausos gavimą ir paruošti šablonus su sąlyginėmis nuostatomis. Tai lėčiausias etapas, kurį komandos dažniausiai skuba.
3. Sukurti patį darbo srautą su tvirtinimo maršrutais, atitinkančiais realias, o ne idealizuotas taisykles, ir prijungti elektroninį parašą.
4. Integruoti pirmąją sistemą - CRM, nes ten atsiranda dauguma užklausų. Kruopščiai susieti laukus ir apsaugoti įvykius pasirašytais webhook.
5. Bandyti su realiais žmonėmis ir realiomis sutartimis, o ne su išgalvotais duomenimis, ir taisyti srautą kas savaitę.
6. Plėstis tik tada, kai bandomasis srautas stabilus: pridėti duomenų ištraukimą, prijungti kitas sistemas ir tik po to svarstyti AI, kuris priima sprendimus.

Kurias sistemas jungti pirmiausia ir kas lūžta

Sistemas verta jungti pagal tai, kur iš tikrųjų atsiranda sutarčių duomenys, o ne pagal techninį įdomumą. Daugumai komercinių komandų tai reiškia pirmiausia CRM, tada ERP ar sąskaitų sistemą kainodaros tikslumui, tada HRIS, jei automatizuojamos darbo sutartys, ir galiausiai pirkimų bei dokumentų saugyklas. Klaidos, kurios užkerta kelią, retai būna dramatiškos: seni PDF be teksto sluoksnio, skirtingi laukų pavadinimai skirtingose sistemose ir trūkstami bendri identifikatoriai, dėl kurių tas pats klientas egzistuoja kaip trys atskiri įrašai.

• HMAC parašais apsaugoti webhook, kad būtų galima patikrinti, ar įvykis tikrai atėjo iš nurodytos sistemos.
• Idempotencijos patikros, kad du kartus suveikęs webhook nesugeneruotų dviejų sutarčių.
• Pakartojimai su atidėjimu, kai tolesnė sistema trumpam neprieinama.
• Centralizuotas žurnalų rinkimas ir stebėsena, kad gedimai matytųsi iš karto, o ne po trijų savaičių.

Kokios valdysenos ir atitikties patikros reikalingos

Automatizavimas nepanaikina priežiūros poreikio. Jis pakeičia priežiūros vietą: iš individualių sprendimų ji pereina į dokumentuotas taisykles, kurias sistema taiko nuosekliai. Teisinėje literatūroje apie automatizuotus procesus nuolat pabrėžiama, kad formalizuota tvirtinimų dokumentacija yra gynybiškumo pagrindas. Be jos automatiškai sugeneruotą sutartį apginti sunkiau nei ranka pasirašytą, o ne lengviau. Į teisininkų peržiūrą verta eskaluoti, kai nuostata nukrypsta nuo standartinės bibliotekos, kai finansinė rizika viršija nustatytą ribą arba kai kyla reguliacinis klausimas, kuriam srautas nebuvo sukurtas.

• Tvirtinimo taisyklės, aiškiai nurodančios, kurios sumos ar nuostatų tipai reikalauja žmogaus peržiūros.
• Teisėmis pagrįsti leidimai, kad tik tinkami žmonės galėtų tvirtinti, keisti šablonus ar apeiti žingsnį.
• Duomenų saugojimo ir asmens duomenų taisyklės, ypač darbo sutartims su jautriais darbuotojų duomenimis.
• Audito žurnalo reikalavimai kiekvienam generavimo, tvirtinimo ir pasirašymo įvykiui su tapatybės patvirtinimu.

Kaip matuoti rezultatą ir kiek tai kainuoja

Verta stebėti nedidelį pastovų rodiklių rinkinį, o ne plačią ataskaitų sistemą, kurios niekas nežiūri. Penki pagrindiniai rodikliai yra ciklo laikas iki parašo, visiškai automatizuotų sutarčių dalis, sutaupytas laikas vienai sutarčiai, pratęsimų fiksavimo rodiklis ir klaidų dažnis. Realūs terminai svarbūs lūkesčiams: vieno srauto bandomasis projektas paprastai trunka 4-6 savaites iki gyvo naudojimo, integracijų stuburas prideda dar 6-12 savaičių, o platus diegimas per kelis sutarčių tipus užtrunka nuo 3 iki 9 mėnesių.

• Integracijų sudėtingumas: vienas CRM yra kur kas pigiau nei penkios senos sistemos su nesuderintais laukais.
• Veikimas savoje infrastruktūroje: griežti duomenų rezidavimo reikalavimai brangiau kainuoja pradžioje, bet panaikina mokesčius už kiekvieną užduotį.
• Sutarčių apimtis: didesnis srautas pateisina daugiau investicijų į patikimumą - pakartojimus ir stebėseną.
• Ataskaitų gylis: paprastas įsipareigojimų registras kainuoja mažiau nei pilnas sutarčių duomenų sluoksnis su individualiomis ataskaitomis.

Kaip bandomąjį sutarties tipą paversti architektūra

Sutarčių automatizavimas tampa konkretus tik tada, kai jį susieji su vienu sutarties tipu ir viena sistema, kurioje atsiranda užklausa. NDA arba standartinė užsakymo forma tinka geriausiai, nes tekstas mažai kinta, o kintantys laukai yra aiškūs: šalis, jurisdikcija, terminas ir vertė. Būtent tokia struktūra leidžia šablonui su sąlyginėmis nuostatomis padengti didžiąją dalį atvejų be teisininko įsikišimo.

Architektūroje verta atskirti orkestravimą nuo dokumento kūrimo. Orkestravimo sluoksnis valdo paleidiklius, tvirtinimo šakas ir integracijas, o generavimo sluoksnis atsako už šabloną, nuostatų variantus ir galutinį PDF. Kai šie du dalykai sumaišomi, kiekvienas nuostatos pakeitimas virsta darbo srauto perdarymu.

Ši tema turi labai konkrečią paieškos intenciją: sutarčių automatizavimas, sutarčių generavimas iš CRM, NDA automatizavimas, sutarčių gyvavimo ciklo valdymas MVĮ ir dokumentų automatizavimas teisės komandoms. Tai terminai žmonių, kurie jau turi apimtį ir ieško konkretaus įgyvendinimo modelio.

• Vienas sutarties tipas su aiškiais kintamais laukais yra geriausias pirmas kandidatas.
• Orkestravimas ir dokumento generavimas turi likti atskiri sluoksniai.
• CRM yra pirmoji integracija, nes ten atsiranda užklausa ir ten gyvena kliento duomenys.

Kas svarbu produkciniame sutarčių sraute

Produkcijoje neužtenka, kad srautas suveiktų per demonstraciją. Reikia pakartojimo strategijos, klaidų eilės, žmogaus peržiūros ribų, aiškių žurnalų ir galimybės perleisti tik nepavykusį žingsnį. Sutartyse tai svarbiau nei daugelyje kitų dokumentų srautų, nes klaida čia yra pasirašytas įsipareigojimas, o ne tik netvarkinga ataskaita.

Antra dalis yra nuosavybė. Veikimas savoje infrastruktūroje reiškia, kad srauto logika, šablonai ir duomenys lieka jūsų perimetre, o kaštai neauga proporcingai sutarčių skaičiui. Mainais reikia stebėsenos, kredencialų valdymo ir versijavimo praktikos - arba komandos, kuri tai prižiūri.