Magnus Bergfors is now a Spend Matters analyst.In my Spend Matters PRO series on five tips to think about before you invest in procurement technology, we covered the need to identify the root cause for why you want to invest in procurement technology. In this installment, we will look at the next two recommendations.
To recap the five tips are:
- Identify business objectives
- Don’t try to do everything at once
- Focus on the basics first
- Select a solution and vendor that meets your requirements
- Review and redesign processes, and perhaps even your organization, as part of the preparation and implementation
In today’s complex, confusing market it is important to identify your business’ key needs, as discussed in the previous post. However, you also need to decide in which order to invest in and implement your new solution across departments or functions. This is obviously less of an issue if you are investing in a single solution or module. But, even in this case, it might make sense to start small, with a single business unit or country, if the change in process or way of doing business is significant.
It’s also important to make sure the basics are addressed before looking at some of the more advanced features that vendors like to market.
You might be thinking: “But I haven’t even invested in anything yet?!?”
Well, if you don’t consider these points before you do invest, you are more than likely to over-invest, both in the number of modules in the near term but likely also in the number of licenses (or allowed spend, whatever metric the vendor prices their solutions in). So let’s look at this in more detail.
Don’t try to do everything at once
Investing in procurement technology is almost always part of a larger transformation project (or should be) unless it’s a straightforward replacement (depending on adoption rates and how the solution has been used this might also require some transformation).
This means that besides the technical implementation (integration, configuration, etc.) of a new tool there are also significant change-management needs, something that is surprisingly often not included in timelines for implementations.
Properly implementing even a single module requires not only technical resources but also subject matter expert resources to help define processes and workflows to be fed into configurations. And these SMEs usually come from the line of business — so how much of their time can they realistically spend on an implementation and still do their day job?
Realistically, if you are planning to implement more than one module, you need to plan for six months or even more for each module, and it’s usually not a good idea to implement more than one or two modules at a time.
This means that your contract ideally should be structured accordingly.
However vendors usually bundle multiple modules together in suite deals with significant discounts provided that you sign up (and start paying) for everything at once. If the discounts are large enough this can still be a good idea, provided you can resist trying to implement too much at once. There’s significant pressure to start using everything quickly because you are already paying for it, and that can lead to rushed, suboptimal implementations that reduce the long-term value.
If you are planning a larger implementation with hundreds or even thousands of users, it might be wise to consider how many users you realistically can train and expect adoption from in the first year. This is even more important to consider for more complex modules like e-procurement, which require identification and onboarding of suppliers as well as internal stakeholders, or a module for contract lifecycle management (CLM), which requires identification of contract types and associated workflows as well as locating all existing contracts.
Focus on the basics first
With all the hype around RPA, artificial intelligence and advanced analytics, it’s easy to think that these technologies will be the answer to all of your problems. But AI still has a long way to go before living up to all the promises, and as my fellow analyst Michael Lamoureux points out, the term is being used quite liberally.
Further, the AI technologies need data to train on and work with. In some cases, vendors are starting to exploit the benefits of multi-tenant SaaS solutions to enable sharing and aggregation of data across their entire customer base. But even so, if you want a solution to be attuned to your own organizations behaviour and circumstances, you need to train it on your own data. This is even truer for analytics — after all you want to analyze your own data (even if there is value in analyzing other organizations data as well, for benchmarking and risk management purposes for example).
RPA, or robotic process automation, is another popular approach to solve all your issues. While it’s often confused with AI or seen as some sort of “AI light,” there is nothing intelligent at all about RPA. It’s basically an Excel macro on steroids and can be programmed to do specific tasks. But since it’s just a program, the tasks have to be predictable and repetitive. RPA will not learn and will only do exactly what it’s programmed to do. If anything falls outside the defined parameters, it breaks down.
So you need to make sure to start with the basics and make sure that you are collecting your own data. How much invoice information do you have available in machine readable formats? Are your contracts stored digitally? Do you capture performance data on your suppliers?
While AI and RPA can help you extract and transfer data, the best approach is to design your processes right to make sure data is captured electronically from the origin. RPA in combination with AI (typically some form of data vision and natural language processing) can be of help, but make sure that you don’t embed suboptimal processes. (I think we all have experience of Excel sheets that have grown into unmanageable beasts …)
So in conclusion, don’t be overambitious — do one thing at a time and do the basics right. Learn to walk before you try to run!
