User talk:Amwelladmin: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
(Replaced content with "<ol> <li>list item A1 <ol> <li>list item B1</li> <li>list item B2</li> </ol>continuing list item A1 </li> <li>list item A2</li> </ol>")
Tag: Replaced
 
(182 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
<ol>
*{{prov|isda|2(a)(iii)}}
  <li>list item A1
*{{prov|csa|Test}}
    <ol>
*{{prov|efet|Test}}
      <li>list item B1</li>
*{{prov|gtma|Test}}
      <li>list item B2</li>
*{{prov|gmra|Test}}
    </ol>continuing list item A1
 
  </li>
*
  <li>list item A2</li>
*
</ol>
*{{eqderivprov|Determining Party}}
What are you trying to achieve by automating?
*Cost
*Speed
*Scale
*Enhanced Business Process
*Consistency/Quality/Robustness
*Reporting
**Performance MI
**Reference Data
 
Document Selection: Which docs do you automate first?
 
Automatability: Factors in assessing candidates for automation
*Volume: how many of these documents to you have to generate each month? The more the better.
*Time: how much time would be saved  in the accurate generation of the document by automation?  The more the better. The less time is saved, the higher the volume needs to be to justify the incremental expense of paying for the automation.
*Standardisation: how “boilerplatey” is the documentation? What proportion of the document is “market standard”? Are there market standard ways of expressing market standard terms?
*Susceptibility to change: how often do market or legal changes necessitate substantive adjustments to document terms?
*Susceptibility to negotiation: Partly a function of Standardisation, but how likely is there to be detailed negotiation of terms of the document?
*Complexity: how much “structural complexity” is there in your preferred terms for the document as they currently stand – if you had to describe your structure in a flowchart, how would it look?
*Formatting: styles, paragraph levels, headings numbering: is it consistent? Is it developed? Is it simple? Is it fully automated?
*Length: In general, the longer a document it is, all other things being equal, the harder it will be.
 
Changeable: how changeable are any of these factors
*Volume: will naturally tend to increase as the cost and time to generate documents decreases. But by how much?
*Time: Could you save time in the manual preparation of the documents by implementing enhancements other than automation (such as simplifying the terms)
*Standardisation: To what extent can you influence the market to move to more standard, simplified terms? Are you a big player?
*Susceptibility to Change: pretty hard to change the legal environment.
*Susceptibility to Negotiation: You *can* dramatically influence this, but it may mean stiffening the resolve of your legal and credit teams. Do you really need that Most Favoured Nation clause? Must you really fiddle with the definition of Specified Transaction?
*Complexity: In most institutions there is a huge opportunity here: the process of managing a busy negotiation team inevitably leads to more and more complexity in documents, as institutional knowledge walks out the door people are reluctant to remove things they can no longer understand. Many “non-negotiable” house positions are simply arbitrary stances that have encrusted themselves through the mists of time.
*Formatting: a surprisingly easy thing to do is overhaul your house style. It will make your documents look snappier too.
*Length: see Complexity
 
Making these changes are all beneficial to the ultimate automation process, so you should do them anyway.
 
Now they’re in shape, where are the candidates for automation
Axis:  volume/speed versus complexity
 
To bear in mind:
*You need to maintain the engine – this isn’t a one-stop, for-all-time fix. Standards change, documents develop – the garden needs to be weeded.
*Perfection is the enemy of just good enough – the 80/20 rule+
 
Other aspects of automating documements
*knowhow
*document execution (e-signatures)
 
 
== Gripes ==
'''Facebook''': “we’re in web 2.0 now – all this stuff is easy on the web. We should be able to make this work, just like Facebook, right?
*Point about Facebook is that web development is USER DRIVEN. Invariably internal systems implementation is that it is MANAGEMENT DRIVEN… a very big difference.
 
'''Wikipedia then?''': “what about Wikipedia? Why can’t this work like Wikipedia?
*Well it could, but firstly there’s the USER vs MANAGEMENT thing – and secondly, there is the power of the multitude. Wikipedia now has had 6,000,000 page views, 1,000,000,000 page edits, 150,000,000 were made by just 5,000 editors. If you scale those sorts of numbers down to organisation level, for an organisation of 25,000 people, those top 5000 editors equate to – about 0.6 of a person.
 
==When you finally get down to the automation process==
• It's not the app, it's the implementation: No matter how good the application, the aggravation in doc assembly is taking your existing doc templates and putting them into the app. ie building the templates and data structures.
o Requires a human: The application CANNOT do this for you
o Requires time and inclination: You need someone with the time and inclination to really get their hands dirty understanding both the fundamental legal content of your documents and the conceptual data structures underlying them
• Getting the Data Structure right: Optimising a Data Structure is hard.
o The data structure implicit in traditional legal documents is invariably sub-optimal, precisely because they are not prepared with a data structure in mind.
• Plan of attack:
o Rationalise: The first job is to reorganise the legal/textual content in a way which has a good or at least workable data structure. this involves:
 removing unnecessary optionality (optionality, from a doc assembly perspective, geometrically increases the complexity of a data structure - particularly if there is "nested" optionality)
 simplifying the expression of complex legal drafting (this usually has the benefit of clarifying and improving the document, but it is hard and requires choices
o Rationalising effectively requires three somewhat incompatible skills:
Understanding Data structures: understanding of how data structures and logical systems work best (familiarity with xml and html is an advantage);
Understanding Legal risks and mechanics: understanding the legal and commercial risks in a given document  type (e.g. MTN documentation, ISDA documentation, Loan documentation etc - these are specialist skills that in each case only a limited number of lawyers have) and
Being able to simplifiy: the ability (and disposition) to simplify, reduce and make plain English a technical language which has developed in a certain way over a number of years.
o Generally: these traits are not compatible:
 the sorts of people who understand (1) are IT folk and not lawyers;
 the sorts of people who understand (2) are lawyers and not IT folk and
 the sorts of people who understand (3) are neither (1) nor (2),
o needs authority: whoever does this also needs to have gravitas and experience - they need to have the insight and authority to make quite challenging decisions.
o hard to do inhouse: Additionally, it is a lot of work up front to get right, and in-house lawyers have to do all this off the side of the desk - meaning it gets de-prioritised, meaning it doesn't get done.
• Cost Benefit analysis: problem is that the cost benefit analysis is quite skewed: there is a lot of upfront cost, and you definitely incur it, but the benefit is all deferred, is only realised incrementally, and is somewhat speculative (depends on how well you execute).
o But the benefits are huge (including the ability to impose proper demand management across the portfolio of contracts by more easily outsourcing them).
o the better it is done the more benefits will flow - a botched job will release some benefits, a really smart, scalable solution will release a lot. This is difficult to articulate upfront.
• the upshot is that the general experience of document assembly across the market has not been a particularly  happy one, except where the product really is commoditised and the automation really is induistrial strength. I don't think this is a necessary conclusion - it is just that Doc Assembly has generally been hastily and poorly implemented.
• the answer is to engage a specialist (in addition to buying the software) to actually implement the solution in consulation with lawyers (as opposed to business consulting on it and expecting the work to be done in-house.

Latest revision as of 16:50, 6 January 2024

  1. list item A1
    1. list item B1
    2. list item B2
    continuing list item A1
  2. list item A2
Retrieved from "https://jollycontrarian.com/index.php?title=User_talk:Amwelladmin&oldid=82446"