Category Archives: Process Transformation

The Back Office. It Will Power Platform Evolution As Well.

Originally posted on the Synertrade blog in October, 2018.

A few months ago we penned a piece on the back office and how it powers platforms. We indicated that the only way a platform could deal with the facts that

  1. (Procurement) workflows are not static and change over time, whether or not you want them to or not;
  2. the type of data you need to ingest, as well as the quality and representation thereof changes over time; and this means that
  3. RPA requirements also change over time

is if such a platform had a great back office. A back office with functionality that allows you to do more than just define users, look and feel, and the categorization schema. A back office that allows an administrator to update the master schema, data harmonization rules, organizational hierarchy, workflow processes, approval chains, and RPA workers. And so on.

But this is just platform maintenance. A platform needs to evolve over time. As per Sourcing Innovation’s recent series on 2020 is Fast Approaching — Better Get on Your Tech Capabilities (Part I, Part II, Part III, and Part IV), 2020 is almost here and the magnificent picture of Procurement in 2020 that all the big analyst firms and thought leadership vendors painted between 2008 and 2013 (check the modern Wayback Machine if you don’t remember, unless you have the original WABAC machine) has not materialized. To be blunt, the picture today, for the most part, is not much better than it was ten (10) years ago. There have been few advances in platform capabilities, although there has been considerable advances in usability and integration. Source to Pay offerings, non-existent in the best-of-breed focussed world (where there were a couple of S2C and a couple of P2P offerings) of a decade ago, are now the norm. And they are quite useable. But are they more powerful?

Consider the eight capabilities mentioned in Sourcing Innovation’s recent posts which were supposed to be, more-or-less, common place. How many does your platform have? Maybe a couple if you are lucky. Maybe. But let’s review the capabilities you should have.

  • True Invoice Automation (with human intervention necessary on less than 2%)
  • Supplier Identification
  • Automated Supplier Discovery
  • RFX Process Automation
  • Should Cost Modelling

If your platform doesn’t have these capabilities, or doesn’t have them to the extent it should (and we can guarantee no platform yet has all of these capabilities to the extent it should, the best you can hope for is a platform actively working towards the goal), the only way you’re going to get them is if the platform has built-in foundations for evolutionary capabilities.

What are these necessary capabilities?

As previously discussed, workflow automation, schema extensibility, and RPA (robotic process automation) are key. But so are open integration (and a fully exposed and extensible API), unlimited supplier (pool) access, and extensible cost and product modelling. These are key capabilities that many platforms are missing, and, key capabilities that, when present, are found in a back-office that powers the platform. (And that’s why the back office will power platform evolution too.)

Most platforms, even those that tout integration, don’t have truly open integration. There is a limited API, and if the external platform or data feed can’t map to it one-to-one, there is no true integration — only what can be mapped.

Most platforms have their own S-MDM (Supplier Master Data Management) capability and some either offer their own network or integrate with one. But it’s still very closed. Right now there are a number of networks, a number of directories, and a number of collective initiatives out there, each of which is controlled by a vendor using a different (often proprietary) technology. There’s no real openness. A vendor must commit to not building its own network of any kind, but integrating with whatever network its suppliers are on that they want to use.

Only a few platforms have should-cost modelling and bill of materials capability even today — even though, at some point in the supply chain, every product is a bill of materials and every service is a collection of task-based service offerings. Only a platform that allows these common components to be defined and re-used is going to provide an organization with evolutionary offerings.

So when you go out to select your S2P platform, if you want a best-of-breed platform that will not only offer the best of what’s available today, but meet your needs tomorrow, be sure to select one with a back-office capability that, in addition to the key requirements outlined last time, also allows for true open integration, for true supplier network/portal interoperability, and true, composable, bill-of-material based should-cost modelling capability. Otherwise, there will be limits to what the platform can do and you will never get a true strategic offering from the vendor and never, ever, reach cognitive support capabilities.

RPA – More Useful Than It Sounds!

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.

Workflow Management: The Unsung Villain? Or The Unsung Hero?

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.