Lepingu läbirääkimiste versioonihaldus: üks elav versioon, täielik ajalugu, ilma „final_v7" PDF-ideta

E-post loodi sõnumite saatmiseks, mitte sellise dokumendi haldamiseks, mida kaks osapoolt edasi-tagasi redigeerivad. Niipea kui mustand lahkub teie postkastist manusena, hargneb see. Nende advokaat laeb selle alla, teeb muudatusi, nimetab ümber ja saadab tagasi. Teie kolleeg vastab lõimes vanemale sõnumile teistsuguse koopiaga. Nüüd on olemas kaks aktiivset dokumenti ja ükski süsteem ei tea, kumb neist on õige.

Nimetamistava on sümptom, mille kõik ära tunnevad. `final`, seejärel `final_v2`, seejärel `final_REALLY_final`. Need järelliited on olemas just seetõttu, et e-post ei paku teile mingit versioonihaldust, nii et inimesed improviseerivad selle failinimedega - ja improviseeritud versioonihaldus ebaõnnestub surve all. Tähtaja surve all, kui kaasatud on kolm inimest, allkirjastatakse vale fail piisavalt sageli, et see on tuntud veakategooria.

Sügavam kulu on taastamine. Kui lahkarvamus tõuseb pinnale kuid hiljem, kerite läbi vanade postkastide, püüdes kokku panna, milline klausel millal ja kelle poolt lisati ning kas teine pool selle kunagi tegelikult aktsepteeris. Vastus istub kuskil lõimes, kuid „kuskil lõimes" ei ole sama mis tõend.

Tarkvarameeskondade koodihalduse põhimõttest laenatud versioonihaldus tähendab lepingute puhul, et on olemas üks kanooniline dokument ja üks jälgitav muudatuste ajalugu - mitte koopiate hunnik. Manuste saatmise asemel avavad mõlemad pooled sama aktiivse versiooni. Muudatused, kommentaarid ja väljapakutud klauslimuudatused toimuvad sellel ühel dokumendil ning iga muudatus salvestatakse selle teinud isiku ja tegemise aja kohta.

Praktiline erinevus on see, et te ei küsi enam kunagi „milline versioon on praegune?", sest on ainult üks praegune versioon - definitsiooni järgi. Varasemad olekud ei kao; need säilitatakse ajaloona, mida saate tagasi vaadata. Nii näete, kuidas klausel arenes esimesest mustandist kokkulepitud sõnastuseni, ilma et peaksite seitset faili kõrvuti hoidma ja erinevusi silmi kissitades otsima.

Just sellele mudelile DokDesk ongi üles ehitatud. Alustate korduvkasutatavast mallist, muudate selle oma staatuse ja ajalooga lepinguks ning peate läbirääkimisi sellel ühel aktiivsel versioonil. Leping kannab oma versioonide ja muudatuste registrit, nii et läbirääkimised ja nende jälg elavad ühes kohas, mitte hajutatuna kahe ettevõtte postkastides.

Läbirääkimiste ajalugu ei ole pelgalt korrasolek - see on teie tõendite algus. Kui saate näidata, et klausel pakuti välja, seda redigeeriti ja võeti vastu selges järjekorras, lakkab leping olemast „PDF, mille osas arvame, et kokku leppisime" ja muutub millekski kaitstavaks. Sündmuste järjekord on oluline ja jälgitav ajalugu säilitab selle järjekorra automaatselt, selle asemel et jätta teie hooleks selle taastamine mälu ja e-kirjade ajatemplite põhjal.

Kõige olulisem on see üleminekul läbirääkimistelt allkirjastamisele. Allkirjastatud PDF tõestab iseenesest üllatavalt vähe selle kohta, mis sellele eelnes. Allkirjale annab kaalu seda ümbritsev kontekst: milline versioon allkirjastati, kes sellega nõustus ja kuidas dokument oma lõpliku sõnastuseni jõudis. Kui läbirääkimised toimusid ühel aktiivsel versioonil salvestatud ajalooga, on see kontekst allkirjastamise hetkel juba olemas - te ei pooki seda tagantjärele külge.

DokDesk viib selle lõime lõpuni. Pärast läbirääkimisi liigub sama dokument digiallkirjastamisse ja allkirjastamise samm salvestab oma tõendusbaasi - kes allkirjastas, millal ja millise kontrollitud isikuga - mis säilitatakse EL-is GDPR alusel. Mõte on järjepidevuses: üks dokument, üks ajalugu, esimesest mustandist kuni kohtukõlbliku kirjeni, ilma et PDF-i taaseksport ahelat katkestaks.

Te ei pea muutma seda, kuidas läbi räägite, vaid ainult seda, kus see toimub. Nihe on „saada koopia" pealt „jaga juurdepääsu ühele versioonile" peale. Mõlemad pooled töötavad sama dokumendiga, kommentaarid ja muudatused kinnituvad selle külge ning ajalugu ehitab end töö käigus ise. Kellelgi ei ole vaja meeles pidada õige faili salvestamist ega nime uuendamist, sest midagi ei saa valesti nimetada.

Mallid võtavad alustamiselt hõõrdumise maha. Selle asemel et eelmise kvartali leping üles otsida ja sealt eripärad välja kraapida, alustate korduvkasutatavast mallist, mis juba sisaldab teie standardstruktuuri, ning peate seejärel läbirääkimisi nende osade üle, mis tegelikult on mängus. Korduv tugistruktuur jääb järjepidevaks; teie tähelepanu suundub klauslitele, mis on selle tehingu jaoks olulised.

Kui sõnastus on paika saanud, on allkirjastamine sama dokumendi järgmine samm, mitte eraldi tööriist uue üleslaadimisega. DokDesk toetab digiallkirjastamist eIDAS SES ja AES tasemel riiklike eID-de kaudu, nagu Smart-ID ja Mobiil-ID, kontot mittenõudva turvalise lingiga, et teine pool saaks allkirjastada kontot loomata. Kvalifitseeritud digiallkirjad (QES) - käsitsi kirjutatud allkirjaga samaväärne tase eIDAS Art. 25 alusel - on osa arhitektuurist, kuid ei ole veel kasutuses; selgitame allkirjastamise hetkel, mis on saadaval.