Object reference not set to an instance of an object.

Over the last few years there have been many articles extolling the virtues of Blockchain and Distributed Ledger Technologies (DLTs). These often began by going through every imaginable use case for DLTs and theorising how they would deliver benefits that would be truly transformative. Recently the publication stream has refocussed onto a much smaller (and realistic) subset of use cases, with a smaller subset of transformative benefits, also highlighting the trickle of actual production implementations. The benefits for firms are predominantly around cost reduction but intriguingly, also around revenue increases.

So what can we observe from this current state? The first is that good progress is being made and if there was any question on when to get into this technology, then the time is definitely now. The second, is that few businesses will be left unchanged by DLTs. Most organisations will either be winners or losers, so great care must be taken to ensure you end up on the right side.

The last point is that there is a big gulf between delivering a DLT system and realising the transformative benefits. This is because if we consider organisational change to be one of the more taxing activities in business, then process change across the business is probably the hardest to make happen. In some ways solving the technology is the ‘easy’ part; changing hearts and minds is much harder.

There are three models that we have observed, each with their own Pros and Cons:

The strong man

In this scenario, a company providing a piece of the market infrastructure decides to lead a transformative change in a particular direction utilising DLT. Good examples of this are the Australian Stock Exchange, DTCC, CLS and others. They not only have the power to encourage their members to adopt the change, they may also have the strategic interest in protecting their positions as intermediaries. This notion of ‘protection’ may, however, be too simplistic as this change actually allows the market infrastructure middle-men to refocus on the real added-value they deliver and build new services based on the new paradigms.

This approach is very useful when attacking the high cost of a cross-party low ‘value-add’ process and probably offers the best approach to mutualising operations. However, when leading a change of this nature, you have to create an architecture for all members, including those that may move at a slower pace than other participants.

The consortium

A consortium is where a group of companies self-organise themselves to reimagine a business process using DLT. Processes are designed, built and then released to all participants. The classic examples here include the R3 ‘consortium of consortiums’ looking at all aspects of capital markets operations, or the various payment networks tackling cross-border payments.

As anyone who has worked with a consortium will tell you, the performance of these groups are highly variable. Their achievements are dependent on the motivations of the participants as to whether they are positive, neutral or indeed negative. Likening the logistics of running a consortium to herding cats is not entirely inappropriate. Having said that, to realise the vision of truly decentralised business processes, the notion of a consortium may be realistically be the only option.

The honeypot

Finally, is the example of two connected participants who find value in running a distributed ledger between them for a specific use case. As empirical value is delivered, other participants witness this and seek to join; as a result, the new business process evolves in an Agile way. Interestingly, this approach works in both decentralised and centralised models, although the latter requires careful bias control. An example of this could be where two banks agree on the interpretation of a regulation between themselves using a DLT. Knowing what the interpretation is and the fact that two other banks share that interpretation may be of interest to a third, such that they want to participate in the network.

In many ways these are just variations of a small consortium, however, in the world of cross-industry change it is sufficiently interesting to consider them separately.

Conclusions: managing change

Regardless of the model used, putting benefits realisation at the front and centre of the initiative is key to avoiding a ‘white elephant’ programme. There are many methodologies targeting this, but managing a Benefits Map (from Managing Successful Programmes) across all parties would be a good place to start. Organisations should be trying to avoid the classic pitfalls of many large-scale IT programmes, including: “build it and they don’t come”, “the underlying business changed whilst we were building”, or my personal favourite, “the upside doesn’t quite justify the eventual cost”. A ‘benefits-centric’ change programme approach will not magically solve these difficult problems, but it will highlight the issues and make it very hard to avoid addressing them. This is especially relevant where the emerging technology is a solution searching for a problem.

I am sure in the not too distant future that DLT will deliver dramatic change and efficiencies for many businesses, and that now is the right time for firms to embrace the technology in some form to ensure they are not left behind. There will be winners and losers, and firms need to ensure they evaluate the available options quickly. It is clear that the proven technology is the least of the problems to be overcome; as ever the biggest barrier to delivering true transformation may well be ensuring that all parts of the business are aligned and ready to embrace the change.