83,063
edits
Legaltech landscape: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{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 | {{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 as Alex describes it, mapped against the contract tech landscape, as we find it. | ||
As Alex points out, any of these functions can be captured by more than one application — which is itself a commercial problem for [[ | As Alex points out, any of these functions can be captured by more than one application — which is itself a commercial problem for [[legaltechbro]]s, 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 | 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 [[Eagle squad|Eagle Squad]]? — 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 | [[Legaltech startup conference|There is an argument]] that the trick the [[legaltechbro]]s are presently 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. | ||
The colossal collision of interests that needs to be resolved in order to deliver true front-to-back processing brings to mind {{author|Stuart Kauffman}}’s concept of the “[[adjacent possible]]” — being possible worlds that are accessible ''directly'' by opening one of the doors presently available to you — a remark on the path-dependency of any evolutionary change. From most organisations, integrated front-to-back processing as a concept is not ''remotely'' adjacent to where they are now, dealing with a hodge-podge of locally implemented databases, applications, systems, processes, workflows, hacks and work-arounds — ranging from fully weaponised SAP or Tableau implementations to spreadsheets with jury-rigged macros stored on the C: drive, each developed by different teams and individuals, without thought for the wider process, to suit local and probably [[the temporary tends to become permanent|temporary]] needs, with a view to putting something better in place [[when budget allows]]. | The colossal collision of interests that needs to be resolved in order to deliver true front-to-back processing brings to mind {{author|Stuart Kauffman}}’s concept of the “[[adjacent possible]]” — being possible worlds that are accessible ''directly'' by opening one of the doors presently available to you — a remark on the path-dependency of any evolutionary change. From most organisations, integrated front-to-back processing as a concept is not ''remotely'' adjacent to where they are now, dealing with a hodge-podge of locally implemented databases, applications, systems, processes, workflows, hacks and work-arounds — ranging from fully weaponised SAP or Tableau implementations to spreadsheets with jury-rigged macros stored on the C: drive, each developed by different teams and individuals, without thought for the wider process, to suit local and probably [[the temporary tends to become permanent|temporary]] needs, with a view to putting something better in place [[when budget allows]]. | ||
| Line 13: | Line 13: | ||
A one-stroke attempt to fix even a component of the system ''as a time-bound project'' can only have a temporary effect, and even that will be offset by the distraction value and implementation glitches associated with that project. | A one-stroke attempt to fix even a component of the system ''as a time-bound project'' can only have a temporary effect, and even that will be offset by the distraction value and implementation glitches associated with that project. | ||
The possibility of even building the consensus to implement a comprehensive front-to-back system, let alone specifying it, let alone actually implementing it, and more to the point, persuading all the squabbling stakeholders to abandon their present system work-arounds, would be quite impossible even if your desired end-game was not a moving target. The localised, ramshackle, rag-tag fugitive fleet of hacks and workarounds has that advantage: it can and generally will flow, | The possibility of even building the consensus to implement a comprehensive front-to-back system, let alone specifying it, let alone actually implementing it, and more to the point, persuading all the squabbling stakeholders to abandon their present system work-arounds, would be quite impossible even if your desired end-game was not a moving target. The localised, ramshackle, rag-tag fugitive fleet of hacks and workarounds has that advantage: it can and generally will flow, meld and morph, however inefficiently and unprettily, to cope with whatever demand is thrown at it. It has at least the flexibility of a bottom up ecosystem: top-down central planning will work hard to beat that in the long run. | ||
So, answers? | So, answers? | ||
One is to invite all stakeholders to imagine a perfect, machine-age end state, however fantastical, and encourage them to develop their own systems ''toward'' that. You may never get to that destination — it may be impossible, or have winked out of existence, or lost its allure by the time you get there, but at least open the nearest door in that direction that puts you in a better place than the one you are in now. Evolve away from unsatisfactory now: nudge yourself in the direction of what looks like a more satisfactory future. That may ''change'' your options, but it doesn’t cut off them off — every room in the palace of adjacent possibilities has many doors opening off it. | One is to invite all stakeholders to imagine a perfect, machine-age end state, however fantastical, and encourage them to develop their own systems ''toward'' that. You may never get to that destination — it may be impossible, or have winked out of existence, or lost its allure by the time you get there, but at least open the nearest door in that direction that puts you in a better place than the one you are in now. Evolve ''away from'' an unsatisfactory ''now'': nudge yourself in the direction of what looks like a ''more'' satisfactory ''future''. | ||
That may ''change'' your options, but it doesn’t cut off them off — every room in the palace of adjacent possibilities has many doors opening off it. | |||
This is a lesson both of the open architecture design of the internet (“end-to-end principle”) and also of the famous [[Bezos memo]]. | This is a lesson both of the open architecture design of the internet (“end-to-end principle”) and also of the famous [[Bezos memo]]. | ||
So, cui bono, Sonny? | |||
{| class="wikitable sortable" style="text-align: left;" | {| class="wikitable sortable" style="text-align: left;" | ||
!<small>Phase</small> | !<small>Phase</small> | ||
| Line 159: | Line 159: | ||
*[[The temporary tends to become permanent]] | *[[The temporary tends to become permanent]] | ||
*[[When budget allows]] | *[[When budget allows]] | ||
*[[Why is | *[[Why is legaltech so disappointing?]] | ||
{{ref}} | {{ref}} | ||