Vadovas · Derybos
Sutarčių derybų versijų valdymas: viena gyva versija, visa istorija, jokių „final_v7” PDF failų
Jūs žinote tą failą. Jis vadinasi maždaug taip: `Supply_Agreement_FINAL_v7_REVISED_clean_THIS-ONE.pdf`, glūdi keturiasdešimties atsakymų laiškų gijoje, ir niekas iki galo nėra tikras, ar tai būtent ta versija, dėl kurios abi pusės iš tikrųjų susitarė. Sutarčių derybos el. paštu atrodo įprastos, kol dingsta kuri nors sąlyga, du žmonės redaguoja skirtingas kopijas arba kas nors pasirašo ne tą projektą. Tada tai tampa problema.
Sprendimas nėra didesnė disciplina ar griežtesnės failų pavadinimų taisyklės. Tai – sutarčių derybų versijų valdymas: viena gyva dokumento versija, su kuria dirba abi pusės, automatinis įrašas, kas, ką ir kada pakeitė, ir vienas akivaizdus tiesos šaltinis vietoj aplanko, pilno beveik vienodų PDF failų. Šiame straipsnyje apžvelgiama, kur strigsta derybos el. paštu, ką iš tikrųjų keičia versijų valdymas ir kaip sklandžios derybos tiesiogiai veda į parašą, kuriuo galėsite pasikliauti ir vėliau.
Kodėl derybos dėl sutarčių, kuriose atsižvelgiama į emisijas
El. paštas buvo sukurtas pranešimams siųsti, o ne dokumentui, kurį dvi šalys redaguoja pirmyn ir atgal, valdyti. Vos tik projektas palieka jūsų išsiųstųjų aplanką kaip priedas, jis išsišakoja. Jų advokatas jį parsisiunčia, atlieka pakeitimus, pervadina ir siunčia atgal. Jūsų kolega gijoje atsako į senesnę žinutę su kita kopija. Dabar yra du gyvi dokumentai ir jokios sistemos, kuri žinotų, kuris iš jų tikras.
Pavadinimų konvencija yra simptomas, kurį atpažįsta kiekvienas. „final“, paskui „final_v2“, paskui „final_REALLY_final“. Tos priesagos egzistuoja būtent todėl, kad el. paštas nesuteikia jokios versijų kontrolės, todėl žmonės improvizuoja ją failų pavadinimais — o improvizuota versijų kontrolė neatlaiko spaudimo. Esant terminui ir dalyvaujant trims žmonėms, ne tas failas pasirašomas pakankamai dažnai, kad tai būtų žinoma klaidų kategorija.
Gilesnė kaina yra rekonstrukcija. Kai po kelių mėnesių iškyla nesutarimas, jūs naršote po senus pašto aplankus bandydami sudėlioti, kuri sąlyga buvo pridėta, kada ir kieno, ir ar kita pusė ją apskritai kada nors priėmė. Atsakymas kažkur slypi gijoje, bet „kažkur gijoje“ nėra tas pats kaip įrodymas.
Ką "derybų dėl sutarties versijos kontrolė" iš tikrųjų reiškia
Pasiskolinta iš to, kaip programinės įrangos komandos valdo kodą, sutarčių versijų kontrolė reiškia, kad yra vienas kanoninis dokumentas ir viena registruojama jo pakeitimų istorija — o ne kopijų krūva. Užuot siuntinėjus priedus el. paštu, abi pusės atsidaro tą pačią gyvą versiją. Redagavimai, komentarai ir siūlomi sąlygų pakeitimai vyksta tame viename dokumente, ir kiekvienas pakeitimas užfiksuojamas priskiriant jį asmeniui, kuris jį atliko, ir laikui, kada jis tai padarė.
Praktinis skirtumas yra tas, kad jūs niekada daugiau neklausiate „kuri versija yra dabartinė?“, nes pagal apibrėžimą yra tik viena dabartinė versija. Ankstesnės būsenos neprarandamos; jos išsaugomos kaip istorija, į kurią galite atsigręžti. Taigi galite matyti, kaip sąlyga keitėsi nuo pirmojo projekto iki sutartos formuluotės, nelaikydami septynių failų greta ir nesiaurindami akių į skirtumus.
Būtent šiuo modeliu remiasi DokDesk. Pradedate nuo pakartotinai naudojamo šablono, paverčiate jį sutartimi su savo statusu ir istorija, ir deratės dėl tos vienos gyvos versijos. Sutartis turi savo versijų ir pakeitimų įrašą, todėl derybos ir jų pėdsakas gyvuoja vienoje vietoje, o ne išsibarstę po dviejų įmonių pašto dėžutes.
Kaip švari versija istorija saugo jus vėliau
Derybų istorija yra ne tik tvarkingumas — tai jūsų įrodymų pradžia. Kai galite parodyti, kad sąlyga buvo pasiūlyta, redaguota ir priimta aiškia seka, sutartis nustoja būti „PDF, dėl kurio, mūsų manymu, susitarėme“ ir tampa kažkuo, ką galima apginti. Įvykių tvarka yra svarbi, o registruojama istorija išsaugo tą tvarką automatiškai, užuot palikusi jus ją atkurti iš atminties ir el. laiškų laiko žymų.
Tai svarbiausia perėjimo nuo derybų prie pasirašymo metu. Pasirašytas PDF pats savaime stebėtinai mažai įrodo apie tai, kas buvo prieš jį. Parašui svorį suteikia jį supantis kontekstas: kuri versija buvo pasirašyta, kas su ja sutiko ir kaip dokumentas pasiekė savo galutinę formuluotę. Jei derybos vyko vienoje gyvoje versijoje su užfiksuota istorija, tas kontekstas jau yra vietoje, kai pasirašote — jums nereikia jo prikabinti vėliau.
DokDesk perneša tą giją iki pat galo. Po derybų tas pats dokumentas pereina į elektroninį pasirašymą, o pasirašymo žingsnis užfiksuoja savo įrodymų bazę — kas pasirašė, kada ir su kuria patvirtinta tapatybe — saugomą ES pagal GDPR. Esmė yra tęstinumas: vienas dokumentas, viena istorija, nuo pirmojo projekto iki teisme tinkamo naudoti įrašo, ir jokio PDF reeksporto, kuris nutrauktų grandinę.
Perėjimas nuo elektroninio pašto chaosas į vieną gyventi versija
Jums nereikia keisti, kaip deratės, tik kur tai vyksta. Poslinkis yra nuo „siųsk kopiją“ prie „suteik prieigą prie vienos versijos“. Abi pusės dirba su tuo pačiu dokumentu, komentarai ir pakeitimai prie jo prisikabina, o istorija kuriasi pati jums dirbant. Niekam nereikia prisiminti išsaugoti tinkamą failą ar atnaujinti pavadinimą, nes nėra ko klaidingai pavadinti.
Šablonai pašalina pradžios trintį. Užuot ieškoję praėjusio ketvirčio susitarimo ir šalinę iš jo konkrečias detales, pradedate nuo pakartotinai naudojamo šablono, kuris jau turi jūsų standartinę struktūrą, ir tada deratės dėl tų dalių, kurios iš tikrųjų yra svarbios. Pasikartojantis karkasas išlieka nuoseklus; jūsų dėmesys nukreipiamas į sąlygas, kurios svarbios šiam sandoriui.
Kai formuluotė suderinta, pasirašymas yra kitas žingsnis tame pačiame dokumente, o ne atskiras įrankis su nauju įkėlimu. DokDesk palaiko elektroninį pasirašymą eIDAS SES ir AES lygiais per nacionalines eID priemones, tokias kaip Smart-ID ir Mobile-ID, su paskyros nereikalaujančia saugiąja nuoroda, kad kita pusė galėtų pasirašyti nesukurdama paskyros. Kvalifikuoti elektroniniai parašai (QES) — ranka rašytam parašui prilygstanti pakopa pagal eIDAS Art. 25 — yra architektūros dalis, bet dar neveikia; mes aiškiai nurodysime, kas prieinama, kai pasirašysite.
Dažniausiai užduodami klausimai
- Ką versijų kontrolė reiškia sutarties deryboms?
- Tai reiškia, kad yra viena kanoninė versija sutarties, su kuria dirba abi šalys, plius automatinis kiekvieno pakeitimo įrašas — kas jį atliko ir kada — užuot keitusis kopijomis el. paštu. Visada žinote, kuri versija yra dabartinė, nes ji yra tik viena, o ankstesnės būsenos išsaugomos kaip istorija, į kurią galite atsigręžti, o ne kaip atskiri failai.
- Kuo tai skiriasi nuo PDF siuntinėjimo pirmyn ir atgal el. paštu?
- Siunčiant PDF el. paštu kaskart, kai failas išsiunčiamas, sukuriama nauja kopija, todėl dokumentas išsišakoja ir žmonės galiausiai pavadina failus final_v2 ir final_v7, kad atspėtų, kuris yra dabartinis. Su versijų kontrole abi pusės redaguoja tą pačią gyvą versiją, todėl nėra ko klaidingai pavadinti ir nelieka abejonių, kuris projektas tikras. Pakeitimų istorija taip pat suteikia jums aiškų įrašą ateičiai, užuot palikusi išsibarsčiusią el. laiškų giją.
- Ar derybų istorija padeda, jei sutartis ginčijama?
- Registruojama istorija išsaugo tvarką, kuria sąlygos buvo pasiūlytos, redaguotos ir priimtos, o tai kaip tik ir yra tas kontekstas, dėl kurio pasirašytą sutartį galima apginti. DokDesk šis derybų įrašas pernešamas iki pat pasirašymo, kur įrodymų bazė užfiksuoja, kas pasirašė, kada ir su kuria patvirtinta tapatybe, saugomą ES pagal GDPR. DokDesk yra sutarčių darbo eigos įrankis, o ne advokatų kontora, ir tai nėra teisinė konsultacija.
- Kaip DokDesk tvarko pasirašymą pasibaigus deryboms?
- Kai dėl formuluotės susitariama gyvoje versijoje, tas pats dokumentas pereina į elektroninį pasirašymą — be atskiro įkėlimo. DokDesk palaiko eIDAS SES ir AES lygius per nacionalines eID priemones, tokias kaip Smart-ID ir Mobile-ID, su paskyros nereikalaujančia saugiąja nuoroda, kad kita šalis galėtų pasirašyti nesukurdama paskyros. Kvalifikuoti parašai (QES) yra architektūros dalis, bet dar neveikia.