I've been told many times that outcome based contracts, such as flying hours, power by the hour, availability etc. are actually solutions-based contracts. (more on outcome based contracts at my previous blogpost here)
It's not.... so I thought l'll blog about the difference. Much of these insights come from my research in OBC so if you want the papers, check out my academic site
1. Diferent capability. Ability to achieve outcomes on Outcome based contracts means a capability to co-create, partner, collaborate and work together with your customer (see blogpost on value co-creation). That means you recognise that you need to keep your customers engaged and working with you and you develop your capability to do that. Solutions imply a passive customer. When you deliver 'a solution' it implies you do everything, and everything is under your control and the customer stays as a passive 'consumer'. Companies that don't really know how to collaborate, co-create and partner often prefer solutioning. Why? Because they want everything under their control. Co-creating and partnering is hard because they lose control. The ability to achieve outcomes on OBC is therefore a different capability from solutions. It's a capability of managing customer autonomy and complexity.
2. Different system. The system of solutioning is complicated. The system of achieving outcomes is complex. Complicated systems often means there is a central 'command and control' to achieve a solution. Complex means parties are autonomous and collaborating to achieve an outcome (see blog post on complicated vs complex). Complicated systems are based on reductionistic engineering science. Complex systems are based on holistic and systems science. Two completely different ways of understanding, viewing and analysing the system. Complicated systems are usually closed systems where anything outside comes into the system through designed and pre-specified conduits for inputs and outputs and predetermined 'touchpoints'. Complex systems are usually open systems where, because of autonomy, allows for a freer flow of people and information. I must stress that there are often closed complicated-type systems within complex systems so the distinction is a logical one, rather than a physical difference. We have inherited a world where often managers use reductionistic science to carve out the 'problem space' and solve it in isolation which can create more complexity from unintended consequences elsewhere in the system so its hard to tell the line between complicated and complex (there usually isn't one).
3. Paradox of solutioning is that the more you provide 'solutions' and relegate your customer to a passive role, the harder it is for you to please your customer. The logic is that an engaged customer is a happy customer because you respect their autonomy and yet able to manage the cooperation. Wanting your customer to be passive is like wanting your child to be passive and you provide everything for a child. it usually doesn't make for happy children.
4. Sometimes more expensive. Solutioning is sometimes more expensive than OBC. Why? Because to provide the 'solution' a provider need to price resources where ideally, some of these resources should not be provided by the provider but by the customer, because the customer, at the use end, has more updated information. For example, say you provide a security service for a house. If your customer wants 'incident-free' as an outcome, it goes beyond just patrolling the grounds or cctvs. It is also knowing when there may be a particular event in the house (e.g. a celebrity visit) where the event could attract security incidents. Your customer knows it but you may not. Not knowing it may make it costly for you as you need to overprovide or be overly cautious. If the customer is also responsible for the risk, the total cost of the outcome may come down. Of course, OBC could also be more expensive sometimes because of cost of cooperation/engagement. Hey, its a capability right? It's not meant to be easy.
5. Complex outcomes vs functional complicated outcomes. Some outcomes are impossible to be 'solutioned'. For example, if you may be able to provide the 'solution' of constructing a 'village' (build houses, townhall, parks, roads etc.), but you can never provide a 'community'. that can only be co-created. Similarly, many emergent properties of systems e.g. family, experience are co-created and not 'solutioned'. So if you are outsourcing a service of your firm be very careful what outcome you are outsourcing. I see firms specifying functions to be outsourced and then becoming very unhappy because they got the outcomes wrong. Its easily to think the world is about functions. Often the outcomes we want are complex outcomes and not complicated functional outcomes. Specifying only the complicated functional outcomes for outsourcing is the most common problem I encounter because it underestimates the full outcome of the 'outsourced' element and reduces it to only a function when that element was achieving more complex outcomes before it was outsourced (and when it was part of an internal division).
6. Variety. Solutions and reductionistic engineering science in systems are really useful when there isn't much variety in the system i.e. in the context of customer 'use' of your service, there aren't many anomalies e.g. the experience of a flight. In such cases, a fully systematic system could be put in place where almost every contingency have been covered. When you have a customer in an enclosed cabin, there isn't really much else s/he needs except sleep, eat, drink, entertain (which is why I always think they dont want to give us internet access). In systems where customer 'use' of a service could have high variety e.g. a resort hotel, trying to 'command and control' the experience could end up with the customer disengaged. Be careful how you try to limit variety because not only do you end up not co-creating value, you engineer a disengaged customer. 'Variety' is double edged. It means more work for you but also an opportunity to create a better experience.
So in short, outcome-based systems are not 'solutioning' systems!
-- Posted from my iPhone