82,915
edits
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
With | {{a|gsv|}}With a hat-tip to Radiant Law’s {{author|Alex Hamilton}} for this categorisation of the contract process in his excellent book {{br|Sign Here}}, here is a ''functional'' breakdown of the contract process mapped against the [[contract tech]] landscape. | ||
As Alex points out, any of these functions can be captured by more than one application — which is itself a commercial problem for [[reg tech]] vendors, because no-one likes to pay eye-watering [[rent]] annuities for products which are partly duplicative. | |||
By way of prediction as to what will fly, what won’t, and what will lumber along the ground like a rhinoceros flapping its miniature gossamer wings and wondering why she cannot get airborne, the JC has added commentary along the lines of ''[[cui bono]]'': who benefits? Management or lawyer? — how hard is each to implement, how readily will a legal eagle take to it, if it is implemented, and to what extent does its careless implementation aggravate problems the installation was meant to solve? | |||
There is an argument that the trick the reg tech vendors are missing is consolidation: there are (literally; trust me) hundreds of startup variations with differing combinations of template management, [[document assembly]], [[document automation]], [[contract review]], [[contract approval]] and [[digital execution]] — you would expect this, as they are contiguous steps on the same commercial process — and all of them leave something to be desired. The entrepreneur that can rally these vendors together and consolidate them into a coherent single product — along the way crushing the precious aspirations of so many entrepreneurial plodders who dared to dream — might have a proposition on its hands. Especially one who builds it on an open-source platform. Like that will ever happen. | |||