Originally posted on the Synertrade blog in May 2018.

When you hear RPA, Robotic Process Automation, you probably think of assembly line automation or, if you’re a bit more modern in your thinking, automated invoice scanning and OCR transformation to e-Invoices, and then roll your eyes back in boredom. And that would be quite understandable if that was all RPA was, but RPA is a lot more than that today.

RPA, which might be better understood as BPA — Business Process Automation — and refers to any technology-based business process automation that uses software robots or AI, has advanced considerably since the early days where it started out as primitive screen scraping technology and then, in Supply Management, advanced to document digitization.

We’ve gone from only a few players in the RPA space to dozens of vendors from AntWorks to Verint that provide solutions for industries ranging from Aerospace to Waste Management (because everyone can take advantage of efficiency) that literally automate every data-driven tactically oriented non-value add process you can think of. This process automation includes healthcare processes (electronic health records maintenance and automation, automated online appointment scheduling, billing and insurance provider management, etc.), workforce automation (on-boarding, job assignment, automated scheduling, automatic timesheet creation, review and submission, etc.), accounting (accounts payable automation, expense submission and processing, automated production of reports and balancing, etc.), compliance (workforce vetting, certification and certificate management, regulatory reporting, etc.), banking (front-end and back end process integration, document management, loan application processing, chatterbots, etc.), travel (guest profiling, automatic rate management, automated BI and reporting, robotic concierges, etc.), and so on. Pick any industry and you will find at least a handful of providers offering at least a few automation services.

But you probably only care about how RPA can help you. Well, if you believe the new breed of vendors selling fledgling cognitive procurement solutions, it’s the miracle cure that will solve all your procurement woes. No more transactional headaches, no more off-contract buys, no more surprises that could be predicted from data, and so on. But we’ve all be around long enough to know it’s not that good, at least not yet.

However, it has come along way since the early days and can solve the vast majority of your transactional headaches. Think about all the time-consuming, low-value transactional steps you do throughout the Source-to-Pay process. Centralizing, cleansing, and categorizing data for spend analysis. Collecting market data for market intelligence. Creating and populating expected / should cost models. Instantiating RFXs and Auctions from existing data. Populating optimization models from collected bid and business constraint data. Drafting contracts from templates, selected bids, and e-Negotiation submissions. Automated purchase order creation and submission based on buying schedules, inventory levels, and point-of-sale trends. Automated invoice receiving and m-way matching. Automated queueing for payment and dynamic / early payment discounting based upon matching, supplier acceptance, and cash-flow analysis. Powerful guided buying inside of the catalog, guiding an organization employee as to whether they buy from a catalog, send a request to the Procurement help-desk, or just go down to the local office supplies store or book their own travel. Powerful guided buying outside the catalog that determines whether a need should be a catalog buy, should be a 3-bids-and-a-buy RFX, or should be a strategic sourcing event. And so on.

But it’s even more than that. Fundamentally, it can be the glue that holds your Source-to-Pay process together, allows you to improve your processes, and even allows you to improve your systems worry and headache free. One of the great things RPA has become really good at is data mapping and even federated cross-system master data management.

This means that if you want to, you can use RPA to glue together a collection of best of breed systems to make a virtually integrated system from a data perspective. But it also means that you can easily migrate from a rag-tag collection of systems to a new integrated suite just as easy by using RPA to map and merge all of the relevant data to a single, central, schema that powers a modern Source-to-Pay suite that can be the foundation for all of your day-to-day Source-to-Pay activities. And, of course, you can easily map that mess of a data store that your first-generation Source-to-Pay system runs on to a more modern Source-to-Pay system quickly and easily, even if you’ve built up tens of millions of transaction records, millions of supplier records, hundreds of thousands of employee and contractor records, tens of millions of product and service records, and so on.

A modern RPA can easily crawl classic schemas, identify best mappings to a new schema, auto-define rules for data normalization, amalgamation, and enrichment, and flag only those situations that actually need human review and then literally automate all of the data migration. What used to take months or years can be accomplished in weeks or even days. That’s the true power of RPA, and a power that should not be overlooked.

Originally posted on the Synertrade blog in May, 2018.

In our last piece we discussed the topic of data harmonization and how it’s much more involved than one may think. It requires the ability to normalize, cleanse, enrich, and structure disparate, duplicate, data across a multitude of sources of various quality. And sometimes it’s not even apparent, even after mappings and enrichment, that two records actually refer to the same entity.

As you might have guessed, data harmonization is not the only struggle that is harder than one might think. Another struggle all organizations face in the back office is workflow management, and in Supply Management, this struggle is especially acute. Why? A number of reasons, including:

1. Workflow processes cross departments.

Think of just the sourcing process. Typically, a buyer is sourcing for another department. The department defines the specs, the buyer puts together a sample RFX, it goes back to the department for comment, comes back to the buyer for updates, goes back to the department for approval, gets posted. When responses to the RFI come in, the buyer evaluates price options, but the stakeholder department evaluates non-price options. Jointly defined weightings are applied and a set of suppliers are selected for an RFP. The joint process is repeated and then, in a short process, one or more suppliers are selected for an award. A contract offer is prepared, and Legal needs to be involved. And this is just simple sourcing. Source to Pay processes often cross the majority of departments in an organization.

2. Workflow processes cross organizational boundaries.

With Sourcing, and even Source-to-Pay, much of the process is internal. The only parts of the process that are external are suppliers submitting responses. But when you get to supplier development, joint product development, and other supply management controlled processes, the process is not easily contained within the four walls of the organization. In supplier development, both parties have to agree upon scorecards, issues, and development options. Then work together on creating a development plan. Both parties have to follow the plan, provide updates, report additional issues, provide resolutions, and so on. This is just one example where workflow processes clearly cross organizational boundaries.

3. Workflow processes vary by category.

It’s pretty obvious even to non-buyers that the process for buying office suppliers is different from the process for buying custom printed FPGAs from the process of acquiring temporary consulting services for the IT backbone upgrade. So, you can’t just implement a sourcing workflow and expect to follow it every time. The same goes for supplier development, product development, opportunity analysis, and other projects that Supply Management will undertake regularly.

4. There are always exceptions.

No matter what the process, there will be exceptions. For example, if a buy needs to be made above a buyer’s threshold, there will be extra approvals. If shipping needs to be expedited, not only will the carrier need to be changed along with the mode, but extra approvals will need to be involved in the process. Supplier development will be according to the issue — quality, delivery, warranty response, etc.

When one sits down and maps out all of the workflow requirements of just the daily processes, workflow management quickly becomes the unsung villain of supply management. Not only are there no well documented process maps for the majority of processes, whose descriptions, if they exist at all, are embedded within category (strategy) documents, but there is generally little to no platform support for these processes. And the more process centric a Supply Management process tries to get, the more difficult tasks become. Process, and workflow management, becomes the villain of daily life.

But with a modern Source-to-Pay platform with proper embedded workflow management, at least for day-to-day buying and supply management activities, workflow management, and the proper processes it enables, can become the unsung hero of daily life. The ability to define customized sourcing and procurement workflows, for every category,
as well as exception workflows, that capture the full strategy and business process requirements, not only eliminates the villainous hassles that workflow management can create when a system doesn’t support it, but makes it the unsung hero of a Supply Management platform, as the buyer doesn’t have to worry about trying to remember and force-fit processes, but simply has to walk through the processes laid out in the system.

So when you are looking for your next Source-to-Pay platform, be sure that the platform, or at least one component of, contains powerful workflow definition and management features that can be configured by senior buyers to support buyers and system users in their daily activities. The difference between this and the status quo will be the difference between light and day.