In this article, Michael Lamoureux explains why an agile back office functionality is key to your long-term Supply Management success.
A few months ago we wrote a piece on how workflow management (link) has quickly become the unsung villain of supply management because those processes cross departments, organizational boundaries, vary by category, and always, and we mean always, come with exceptions. This was just after we asked if you had a data quartet that could carry a tune because, in reality, data harmonization is much more involved than many vendors would like you to believe.
Furthermore, just before data harmonization, we told you about RPA, Robotic Process Automation, and how it is more useful than it sounds. In fact, for many organizations, its much more useful than fledgling AI or ML as senior sorcer(er)s can often achieve marvelous results with the application of their true intelligence, provided they have the time to apply it on the right categories and give those categories the degree of due care they require.
Most importantly, we noted that if you didn't have a modern Source-to-Pay platform, you didn't have good data harmonization, workflow management, or RPA, and, as a result, it was a continual effort to load data in for spend analysis or spend tracking, even harder to adapt sourcing processes to changing markets or organizational needs, and you could forget about ever increasing efficiency on a go-forward basis. And all this is very important because of what we didn't tell you. You probably already know some of these points, but they still need to be addressed.
1) Workflows are not static and change over time, whether or not you want them to.
Finance, management, external stakeholders like to change the rules, regardless of whether or not it means another visit from Phil, the Prince of Insufficient Light, whether or not it makes any sense, and, sometimes, despite being informed of the fact that the change is (just as) likely to lead to worse outcomes from a sourcing event (and not better). But if your system was configured by the vendor for one set of (relatively static) workflows, then what do you do?
2) The type of data you need to ingest, the quality, and most important the representation thereof changes over time.
The data entry contract is shifted to a new, lower cost provider in a lower-cost regime, that speaks even less of your language than the last provider (high school equivalence is no longer a requirement), takes even less care in transcription, and those that do have a good language understanding like to define their own abbreviations for line items and product / service descriptions. All of a sudden all of your invoices, work orders, time sheets, etc. look completely different from what you were getting before and all those human verified rules start to fail. What do you do?
3) As a result, RPA requirements change when documentary formats and requirements change, workflows change, and data elements change and the RPA either becomes less useful or breaks down completely.
And all of a sudden your sorcer(er)s lose their magical assistants and have to spend all their time gathering their own ingredients, dealing with derelict vendors, and keeping the castle records instead of working on new spells for sourcing success.
Unless, of course, the workflows can be altered as the processes change, the data processing rules can be modified as the data changes, and the RPA assistants can be tweaked to understand, and deal with, the new requirements as they arise.
This is only possible if the system has a powerful back office functionality that allows you to do more than just define users, look and feel, and the categorization schema. The only way the system can be kept up to date in the real world is if the back office allows an administrator to update the master schema, data harmonization rules, organizational hierarchy, workflow processes, approval chains, and RPA workers that automate the parts of the processes that can be automated, with override rules as to when to alert a human supervisor. In addition, the back office must make it just as easy to define new, alternate, schemas and taxonomies for comparative "what if" analysis scenarios, new enrichment rules to link in new data sources, new workflow processes (to extend the system capability over time), new approval chains (for new / refined category definitions, for example), and new RPA workers as more tasks become common and capable of being automated.
And this true whether or not the organization intends to make any changes on their own or have the vendor do it, and whether or not there is a contract for the vendor to do it. The reality is that if the system wasn't designed to allow quick and easy changes like this, the amount of changes that will be possible upon implementation will be very limited, extremely time consuming, and often too costly for an organization to actually green-light on top of the software fees.
Just because you can re-code a workflow doesn't mean it's an easy thing to do if the workflow wasn't abstracted to a level that made definition configuration instead of low-level 3GL coding.
The same goes with data harmonization and RPA. So it doesn't matter whether or not you ever intend to use the back office, or even how it looks (it can be the ugliest interface you've ever seen because only the admin will be using it and only as necessary), it just matters that it exists (and can get the job done).
So don't overlook an in-depth evaluation of back-office capability next time you upgrade your Supply Management platform. It's key to your long-term Supply Management success.