Supplier Engagement Model

When establishing the relationship with an external service provider (outsourcer), why do we document a whole operating model spanning both organisations? The whole point of outsourcing is that the supplier should be a black box, with inputs, outputs and performance requirements. What we need to define is the interface between the two entities, to ensure the operating models of each one mesh properly together. Define the connecting cogs, or the plug-and-socket - choose your analogy.

This is more efficient: we don't redundantly document processes which already exist, and are documented elsewhere. It is more effective: we focus on the gaps, specifying the requirements for change in each organisation in order to connect their operating models.

This is pioneering stuff: there is very little published on what an engagement model should look like or how to develop and use it. So I built one. I use the name "Hono" for the model, which is a Maori word for a join, bond, or weld.

Here is a presentation on what I came up with:

When we speak of a "Service provider" we can mean many things: Service integration, Service aggregation, XaaS , Cloud, or old-school “bespoke” outsourcing. This model os not intended for the commodity providers with a one-size-fits-all approach (though it might work there, i just haven't thought about it). We're talking here about any situation where there is "mutual engagement", where the entities negotiate an arrangement, and most importantly an operating model.

Normally that operating model spans both organisations: on big flowcharts, the processes flow from the suppler swimlane to the customer swimlane and back again, with every step defined. We end up with a huge document.

Most importantly, it happens separately for each suppler-customer relationship. So a supplier has different, say, incident process for each customer. And likewise a customer has different, say, change process, for each supplier.

This is nuts.

It would be so much simpler to only define the touch points: on the flowchart, the points where process crosses from the suppler swim-lane to the customer swimlane.

We should define our expectations of each other, not how the other should fulfill that expectation. This is an Engagement Model.

The outcomes are

  • clarity of expectations
  • Gap analysis
  • Specify Operating Model changes
  • Single operating model
  • Single procedural documentation
  • Brevity and focus
  • Speed and efficiency

Here is the "data model" I came up with for such an Engagement Model, the "pins on the plug and socket" of engagement.

Below you will find a sample spreadsheet and a document explaining the principles (login required, I won't spam you) updated 5th August 2015. I use this to record all the detail of an Engagement Model for a client.

These resources are provided free, open source, with no warranty or support. No outcome is implied or expected: use at your own risk.

We would all be very grateful if those of you who use these ideas provide us with feedback on how they worked for you, so we can refine the idea further.

* A process interlock is where my process interlocks with yours, e.g I open a problem ticket then one gets opened in your system too, or I change the priority of it and I tell you, or I have a change ticket that needs your approval .