How to Rescue a Failed Digital Procurement Transformation

Digital transformations of procurement fail just like any other digital transformation: frequently.

There is a way to turn these situations around, though.

What Is Digital Transformation?

Here is CIO :

“Additionally, companies often forget that a digital transformation is doing two things at once: digitizing your backbone as well as automating and simplifying by ideally, reusing components or processes.”

Pulling this apart, there is an underlying core technology. There may be, for example, a database that is the single source of truth. Think of it as a general ledger for enterprise applications. A digital backbone may include an inter-application messaging system. This is a technical resource.

Sitting on top of it are the applications themselves. In the most primitive incarnation, we can imagine a combination of email and spreadsheets used to manage a workflow. Or it might include some legacy applications, either built in-house or potentially the long-deprecated modules for an enterprise resource planning system. This is the business toolkit.

Why transform digitally?

Companies put into place new systems for two reasons: to improve operational efficiency, or to give staff the ability to do new things. We want novelty because it can open up opportunities for new products or new revenue streams or new combinations of things and people that will create value.

Why has there been so much pressure to transform digitally?

We are emerging from a fifteen-year period of extraordinary monetary policy that fostered an environment of experimentation by making it easier to take risk financially, leading to a self-reinforcing cycle of trying new approaches. When your competitors are putting in place new ways of doing things, the pressure is difficult to withstand. When everyone around you is pushing the boundary, it is insurmountable.

The accelerating pace of change forces companies to improve business outcomes.

Almost All Digital Transformation Projects Fail

According to Forbes:

“In 2016, Forbes assessed the risk of failure in digital transformation to be 84%. According to McKinsey , BCG , KPMG and Bain & Company , the risk of failure falls somewhere between 70% and 95%.”

Consulting firms are predisposed to tell you how to avoid such an outcome. But there are two other questions we could ask.

Why do transformations fail?

Assuming that the project has run off the rails, how can we fix it?

Being able to rescue the ship (and ensuring that it can sail off without incident) requires understanding why and how it has hit the shoals. We want to design a solution that addresses the core problem.

Digital Transformations Fail Because They Optimize the Wrong Objective Function

There are two dimensions to a digital transformation: the technology implementation and the cultural change.

Technology implementation is a fixed, finite engineering problem. The company’s IT department must optimize the installation of the designated toolset subject to the constraints of time, budget, and existing infrastructure. The team must make decisions about how to plug it into the current fabric of software and hardware. All of this factors into the decision about what system to buy.

Forbes talks about the “shiny toy problem”. Are you purchasing the system that is the right solution for your problem, or are you buying something because it is marketed well and it seems to be gaining traction in the marketplace? CIO refers to “delighting” the customer. Here the customer is the internal users you want to embrace the new approach. Does the user experience excite them??

Who is running the project? If IT dominates the conversation, does it devolve into an exercise in integrating the new tool with the current architecture as elegantly as possible? Are they taking into consideration what the business user wants? Do they even understand the business problem?

It is easy to understand why IT might take over. They can measure success. Did the team select and integrate a system that didn’t blow up the company’s existing infrastructure? Did they do so on-time and under budget? Did they get the system to function the way the vendor designed it to work?

These are necessary conditions for success, but they are far from sufficient for getting value-for-money.

A successful project means users embrace the new technology’s features to obtain the best business result. They do not deem a project successful because they can use the features the way the vendor intended, necessarily. Users exist in a context and success is judged within it.

Cultural change represents an indefinite business problem requiring strategic insight into the business and soft skills. Enterprise leadership must solve for the business outcomes they hope to achieve subject to the constraints of overall strategy and the people on the team. Ideally, this is seen to be critical in the decision about what system to purchase.

When we see the lists of problems as described in Forbes, CIO, Kissflow , and Archdesk , this is where the meat of the matter resides.

We can boil it down to several categories of failure: misalignment, poor leadership, and fear.

Forbes addresses the question of alignment by which we refer to the degree to which the solution solves the business problem. IT solves a technology problem (i.e., upgrading the digital backbone), but if the digital transformation will work as change, then the project must address the needs of the end users.

The CFO wants to know if this project has a positive net present value. Do the economics of using the toolset lead to lower costs or higher revenue that will generate increased margins over time? Does the project avoid a degradation in margins in the future the company might expect if they were to stand still? Is the company optimizing profitability or is this a question of politics?

In a world dominated by managers, it is no wonder that leadership capable of handling complex projects such as these is in short supply. Leadership here means getting people to do what they may not want to do, given the stickiness of legacy systems and current business processes. This involves frequent and consistent conversations with every stakeholder as to why this project is vital for the company’s future success and how it will extend their capabilities and capacities in a meaningful and fulfilling manner.

Engineers can handle the minutiae; these are important, no doubt. Make no mistake about it. It is also true that nobody buys into change because an engineer prattled on about overcoming the challenges of some abstruse coding problem or the elegance with which they set up the database. Often, engineers gain personal meaning from solving difficult technical puzzles; this may coincide with the business case, or it may not.

Leaders need to tell stories about what the user experience will feel like in the future universe once this system is in place, tales of how much easier life will be for businesspeople to do their jobs, and of how much more they can accomplish. People want to be effective. They also dislike friction. The best kind of digital transformation removes obstacles. Successful projects help line up what the individual sees as progress with what the enterprise needs. It is a fundamentally emotional exercise.

It is not only the rank-and-file the leaders need to address. Management needs to buy-in at every stage. The C-Suite must see this project as something that advances its strategy. There is the base calculation of net present value, of course. But the best projects have a net perceived value to all stakeholders.

People buy into change because it sets them up for success.

This is why addressing fear is vital.

Here is Archdesk:

“… employees can also fear that new technologies can take over their jobs, making them redundant.”

Leadership here is paramount. The absence of communication creates an environment of uncertainty. Not only do employees fear the consequences personally, there is a natural concern that the new approach will be worse than the old one. Better the devil you know is a powerful sentiment. When there is lack of information, then the anticipation of what the new regime will look like can create its own doubts. Leadership needs to be constant in working with users to identify their worries and in addressing them, incorporating feedback, and highlighting that transformation is a process, not a discrete event.

Relentless focus on the business and the users is a magic salve for transformation projects.

How Do You Fix a Broken Transformation?

If the thesis of this blog post is correct, the digital backbone is in place. The underlying data infrastructure works the way it is supposed to work, but the issues arise at the application layer, either in getting different related software tools to interact efficiently or, more likely, in having the users embrace the new approach in ways that improve business outcomes.

The way to fix a broken transformation may, paradoxically, involves adding new applications.

The new applications can act as a “skin” on top of the functioning infrastructure and as a type of middleware that fixes the connectivity issues.

HBR talks about the three stages of successful digital transformation : “simplifying and digitizing existing processes and functions”; “enterprise-wide transformation” involving “complex cross-value-chain change”; and “new business creation.”

The first job of the skin is to take the pre-existing processes and functions and transition them to the new environment by designing the right user experience and plugging it into the data infrastructure. This may be the core failure of the digital transformation such that success here is a home run.

Get this right and you reduce fear.

The second job of the skin is to make it easier for the new overlay to plug together different systems, breaking down departmental silos and converting value chains into value networks. Not everyone buys in, but many will.

Get these two jobs right and the third stage takes care of itself. As users embrace the new setup, opportunities to create new businesses or cut costs will emerge.

If the transformation failed because it was driven by IT and lacked proper leadership, the kind of fix discussed here can work. The engineers would have ensured that the bones of the data structure were solid. This only makes the introduction of another layer more attractive. It can be economically appealing if the business model for the new layer is the right one.

This is what we have built at EdgeworthBox . It is a complementary application layer that is agnostic to the underlying architecture and one that can engage business users, while integrating with underlying infrastructure layers in the procurement technology stack. Our elastic procurement? business model makes the economics of transformation attractive.

Give us a shout . We’d love to talk to you.