Template:Over-processing
Over-processing
Headline: Don't design your plane to be waterproof in case it falls into the sea. Design it so it doesn’t crash.
In its original physical manufacturing sense, over-processing refers to unnecessary complexity in design, whether brought about through carelessness or over-specification. The production cost of features that realistically no-one will ever use is as much a form of wastage as any.
The chief production cost in contract negotiation is time and human resource. The longer a contract takes to read, and the more it invites challenge[1], the more expensive it is to produce. Any time taken over the bare minimum needed and any client challenge to a term that is not really vital the the firm’s risk protection strategy is a waste in the contract negotiation process.
As we have seen, client challenges to credit terms create their own additional wastes (waiting, transport, as well as risking of overproduction and defects).
In contract negotiation, over-processing arises in two chief ways:
Risk controllers are short an option
Risk controllers are short an option. They are incentivised to err on the side of caution: they don't get a bonus if the client generates extra revenue, but they will be regarded as having failed if the client blows up owing the firm money[2]. So no wonder there are overreaches in the terms they require in general client documentation.
While credit teams do not typically monitor or collect data about the frequency with which they invoke specific credit terms, we know for sure that:
- Well over 90 percent of client contracts never default at all,
- Of those contracts which are closed out, in nearly all cases the cause of default is failure to pay or insolvency. These two events of default are generally not challenged during the negotiation process (it is hard to argue that if you are bust or you fail to make payments, your counterparty should not be able to terminate your contract!
Barnacles and the effluxion of time
“Policy is institutional scar tissue” - Jason Fried
Over time contract templates will inevitably accumulate what I call “barnacles” — ad hoc responses to historic situations, anecdotal reactions to unexpected risks, flannelesque flourishes to placate a truculent, obtuse or just downright stubborn counterparty — no-one likes them, but if your client insists on redundant (or misconceived) terms (“for the avoidance of doubt”; “without limitation”; “because it is our policy to require them” — that kind of thing) for the sort of fellow who prefers a short-term fix over long-term existential satisfaction, the pragmatic response is to agree them and move toward execution.
These barnacles have a habit of finding their way into, and encrusting, negotiation templates. And, as people move on, their original justification — if there even was one — becomes lost to time. The instinct of successive risk controllers, short an option as they are, upon encountering them will be, “I don’t know why that is there, but whoever put it in must have had a reason for doing that,[3] so the safest thing is to leave it there.”
This will lead more complicated templates, longer templates and a proliferation of different templates.
Summary: Over-processing arises through excessive caution in credit terms and through the natural, pragmatic process of getting negotiations across the line. The length and complexity of documents creates significant over-rprocessing wastage and, as a by-product, creates significant waiting and ===Transport===
Headline: Escalations and reporting are the “transport” of a negotiation process: they may be automated, but ideally should be avoided (where possible) by robust redesign of the contract production process.
In physical manufacture, our man Taiichi Ohno recognised that transport product between processes during manufacture incurs cost and adds no value. The answer is to reconfigure the production line to get all the inputs at the right time and sequence. Contract negotiations are no different. The hand-offs may be electronic, but the waiting is inevitable. They arise in:
- Escalation points: Against all expectations, a client challenges credit’s required credit terms. I mean, imagine. Unless there is a playbook with acceptable fallbacks, the negotiator must escalate to the credit/legal risk holder for approval to concede the required term. The very act of this escalation (regardless of how quickly it is actioned) will be costly in terms of Waiting time. Such transport may require some kind of escalation hub through which terms can be systematically captured. This is an additional cost, but may generate useful metadata as to trends, off-market terms, and bottlenecks.
- Post-negotiation approval, execution and storage processes: Once the negotiation is finally agreed there is a lot of time preparing execution agreements, summarising terms and submitting them for final formal approval, obtaining signatures and filing approvals, execution copies and capturing key agreement metadata in the firm’s risk and trading systems. Traditionally this is a labour-intensive, manual task. Technology here (particularly digital execution) offers an enormous capacity for efficiency and digital audit.
- Process maintenance: Maintenance, approval, version control, storage, retrieval and sharing of negotiation templates and knowhow. Again, technology offers significant organisation, time savings and better reporting. Also, product/process design will be important: generally there will be too many templates and they will be too complex. The job or organising them will be overwhelming.[4]Part of this is a by-product of the lack of control of the process (proliferation of different templates to do the same job); part is a function of over-processing (templates imposing requiring terms that are not really needed, though unnecessary caution or ossification through time).
Summary: Transport is a place where technology — if implemented thoughtfully[5] can make a difference to the process and eliminate wastage where transport is necessary. But transport should not be necessary for standardised regular client contracts. They key should be to eliminate the need for transport through removal of over-processing and poor process design.
wastage as well through unnecessary escalations."
- ↑ Which will be, in part, a function of its length - there more there is to read, the more there is to challenge.
- ↑ In theory. But see the circle of escalation.
- ↑ Not necessarily so. Just as likely to be a misconception. As to which, see indemnity.
- ↑ Here technology is a bane not a boon: the paradox is that it permits more complexity, even though complexity is not needed it grows through indolence. See the technology paradox.
- ↑ Big if, in this contrarian’s humble experience.