Magnus Mondays — When Procurement Tech Projects Fail

Magnus Mondays — When Procurement Tech Projects Fail

A big IT project has been all over the news in Sweden recently. Two regions (a region is a fairly large public entity that is responsible for public healthcare and public transportation) have bought a new healthcare administration system. It’s fair to say that it has been a failure as some hospitals have reverted to pen and paper because of the risks to patient safety. The entire implementation has now been paused until further notice.

This got me thinking about the many failed procurement technology implementations I’ve come across over the years. While this is a big topic and there is a myriad of factors that come into play, I’ve noticed three main issues — having the wrong expectations, integrations, and poor/lack of change management. So, in today’s article we’ll have a look at these.

Expectations

One of the biggest problems is having the wrong expectations. A good example of this is the early days of spend analytics. The solution providers demoed solutions that were able to granularly classify spend down to the third or fourth level of a category tree. The problem? It assumed that the procurement organizations had more or less perfect data to work with, including invoice/PO-line descriptions. To a certain degree, this remains an issue, but improvements in optical character recognition and more use of e-invoicing and digital POs, etc., have improved both the amount of data available and the quality of that data.

Another example is when buying organizations assume that all indirect spend can be bought through a P2P or eProcurement solution. While it’s theoretically possible (and a lot of requisitions/POs created when the invoice arrives), it will require a lot of work, and you will end up with many unhappy end users.

It can be argued who’s at fault here, the buyer for making faulty assumptions or the seller for “overselling” their solution or not being clear on what it can and can’t do. We are often quick to blame the latter but at the same time it’s critical for the buyer to do their due diligence. Ask clarifying questions and don’t settle for vague sweeping answers. Make sure you know exactly what is required to reach the demoed results and that you understand the limitations of the solution(s). Talk to references that are using it for the same purpose that you are intending to use it. If possible, use pilots as a way to test solutions. Using a pilot approach allows you to try it out without a significant investment.

Integrations

Integrations have been the bane of IT implementations since the dawn of time. Over the last couple of years, great improvements have been made with integration platforms, no-code/low-code interfaces, APIs, and so on. But integrations require (at least) two solutions to work with each other and even if your brand-new cloud-based procurement solution has all the latest and greatest integration capabilities, your 30-year-old ERP system probably doesn’t.

Understanding the difference between “need to have” and “nice to have” integrations is important. Focusing on the “need to have” integrations — which are fewer than you might think — will increase the likelihood of a successful implementation drastically. Additional integrations can be added later if there is a business case to support them.

Change Management

Change management is a huge topic and there are people that work with nothing else. What approach to take depends on the target audience and the nature of the change. I’ve always been a proponent of a mandatory usage approach when it comes to eSourcing, for example. On the other hand, I’m not a fan of companywide “No PO, No Pay” mandates.

The difference here is that the first primarily affects a limited number of employees in the same department (or related departments). It’s easier to train and explain the value of the new approach and solution to fewer people, who also should understand this as it’s part of their job. In the second case, it affects far more people who are not procurement experts. Not to mention the fact that in plenty of cases, a PO adds no value for the end user or the process.

The ability to understand the impact of the change, who it impacts, and capability to train and communicate with users are skills that many procurement departments are lacking. Change management might seem obvious and straightforward but is almost always overlooked and underprioritized. For many organizations, it makes sense to look for outside expertise and help in this area.

This is by no means an exhaustive list of the issues that can derail a procurement technology implementation, but if you address these, then the likelihood of project success goes up significantly.

As always, if you have any questions or need assistance, don’t hesitate to reach out to us at Ardent Partners.

RELATED TOPICS