Template:Transport: Difference between revisions

'''Headline''': ''[[Escalation]]s 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.'' <br>

In physical manufacture, our man [[Taiichi Ohno]] recognised that {{wasteprov|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 {{wasteprov|Waiting}} time. Such {{wasteprov|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.<ref>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]].</ref>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''<ref>Big if, in this contrarian’s humble experience.</ref> can make a difference to the process and eliminate wastage where transport is necessary. ''But {{wasteprov|transport}} should ''not'' be necessary for standardised regular client contracts. They key should be to eliminate the need for transport through removal of {{wasteprov|over-processing}} and poor process design.<br>