82,891
edits
Legaltech landscape: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 6: | Line 6: | ||
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. | 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. | ||
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]]. | |||
Bear in mind the business units that develop these hacks themselves morph, merge and wink out of existence, as a function of the tectonic political machinations of the organisation, as do regulatory and commercial imperatives that notionally prompt them thus ''the system changes itself over time without any particular rhyme or reason'' — this is a truly dynamic, dancing landscape — and you can see that system is not only certain to be a monster, but it will categorically get more monstrous over time. | |||
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, melds and work-around, 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? | |||
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. | |||
This is a lesson both of the open architecture design of the internet (“end-to-end principle”) and also of the famous [[Bezos memo]]. | |||
{{sa}} | |||
*The [[Bezos memo]] | |||
*[[Adjacent possible]] | |||
*[[iteration]] | |||
*[[The temporary tends to become permanent]] | |||
*[[When budget allows]] | |||
{| class="wikitable sortable" style="text-align: left;" | {| class="wikitable sortable" style="text-align: left;" | ||