RPA: Robotic Process Automation or Redistributed Process Automation

RPA, ML, and AI is all the rage these days, with RPA being the most mature technology. But just because it’s a mature technology, that doesn’t mean it’s a mature technology offering from the vendor you are considering, as powerful as they are purporting it to be, or even as general purpose as you might expect (especially if it relies heavily on ML or AI techniques).

In fact, like early spend classification technology, which was usually 60% auto-class and 35% behind-the-scenes manual-class by the hundred interns in the backroom (in India, Poland, or another outsource locale with a relatively high percentage of English-as-a-second-language speakers), a lot of the RPA technology being promoted today is in fact supported by, if not done by, humans behind the scenes.

This is especially true when natural language processing is involved, and doubly true when interpretation is involved. And it even comes in to play with something as simple as calendar scheduling. For example “book me an appointment with John Russell” next Wednesday is not often straight forward. John Russell the person, or John Russell the company? And the next calendar Wednesday, or the calendar Wednesday in the next week? (English speakers typically refer to the next calendar Wednesday as this Wednesday and the Wednesday in the following week as next Wednesday, but certain European cultures always refer to the next calendar Wednesday as next Wednesday.)

So imagine how much human intervention is required behind the scenes if you want to do document analysis or contract interpretation! Quite a bit. When it comes to document and contract processing, it’s one thing to break it up into sections and annotate what’s in the document, it’s another thing to interpret what each section means, and yet another to determine whether or not its enforceable, or even allowable, against a regulation or law.

Advanced RPA / ML systems can analyze a document or contract and break it up into relevant sections, identify the constituent components of each section (party, address, obligation, description, explanation, etc.), and make it easy to determine whether or not a section, entity, or value is contained within. With sufficient ontological definitions, training, and tweaking, these systems can get highly accurate.

But when it comes to interpretation, that’s different. It’s easy to determine that a document contains the phrase “the receiving party is bound to provide the sending party with a hold payment to be applied against the obligation of the sending party upon transmission”, but harder to figure out precisely what that means if the hold payment, receiving party, sending party, and obligations are specified elsewhere in the document. And then if you want to determine whether or not that obligation is in line with organizational policies or contract law in the jurisdiction of choice, that’s yet another level.

Really good tech might be able to sift the document and make probabilistic guesses as to what the hold payment is, what the obligation is, and maybe even what transmission means (providing to a courier, being received by a local courier, showing up at the recipients door if its a physical good, or confirmed receipt / acknowledgement if an electronic IP deliverable), but chances are it will be wrong a good percentage of the time and require human confirmation. And when it comes to interpretation, frankly, unless a human is reviewing the clause and given the most likely scenario, a random number generator mapped to an outcome table is likely to be just as accurate. (In other words, trusting RPA means you are rolling the bones.)

Thus, any RPA system that performs an advance task is likely not true Robotic Process Automation but in fact Redistributed Process Automation, even if the vendor doesn’t advertise it as such. But if you are curious, there are tells. How long does the system take to perform the task? An hour or two to process a document? Definitely RPA of the second category. Fifteen minutes or more to schedule that appointment? If both sides were using true RPA of the first type, it would take seconds, maybe a few minutes if there was limited bandwidth and email delay. And so on. Look at service times, customer counts, and what’s being heavily promoted. The truth is under the covers.

But redistributed process automation is not necessarily bad. It’s probably the most efficient use of your organization’s time, especially if the vendor has RPA-lite algorithms that can quickly determine what needs to be done by a human and what can be automated. Anything that saves your organization time and money while improving outcomes is a step forward, and as long as the vendor continues to reinvest its profits into system development, the system should get better over time.

But don’t buy RPA with eyes wide shut. Otherwise, you might not get what you are expecting. Or put too much faith into the system.

P2P: Points 2 Ponder when People are Pushing Off S2P Platforms

Years are passing and still not enough companies are using good, modern, fully electronic, Source 2 Pay Technologies when they should be. (We’re using technologies and not platform because it doesn’t necessarily have to be one platform from one vendor, as long as the S2C can be tightly integrated, even if by way of a third party like Per Angusta, and the P2P are tightly integrated and the S2C and P2P are integrated at the end points, that is sometimes the best solution for some companies.) Even worse, many of these companies have realized the importance of good Supply Management and adopted point-based Sourcing, Procurement, and/or and Supplier (Performance/Information/Risk) Management software. But that’s not enough. SI has been ranting for years about the fact that it’s Sourcing AND Procurement and that if you don’t implement the full cycle, you’re not only leaving savings on the table but failing to capture all of the value available to you.

Why are otherwise smart, moderately progressive, companies doing this? Because they have deep concerns that the platform won’t do what they need it to do and fears that the only reason these platforms exist is to eliminate their jobs the same way machines and automation have led to our manufacturing woes. And while they have good points, since some of the early solutions didn’t do everything they needed to do in order for the company to obtain the promised benefits, and since automation of any sort typically leads to elimination of workforce in the function, when you look at some of the current solutions and look at the goal of Procurement in the right light, their points are no longer valid. And this is true even if the platform has cognitive or auto-buy elements. There’s still only so much it can do, and so much more you have to analyze these days when doing high-dollar or strategic buys.

Nevertheless, if the points of trepidation are not addressed, the solutions won’t be considered, the function will not advance, and, vendors, you won’t survive. So, because SI encourages the proper use of technology platforms to increase efficiency, eliminate non-value-add tactical tasks, and augment the capability of your workforce (which is different from replacing it), SI is going to give the vendors building these solutions a helping hand by identifying the common trepidations, the solution requirements needed, and, as a result, the message you have to get across to calm the prospective buyer’s nerves (provided, of course, that you do have the solution requirements).

Trepidation # 5: It Won’t Save Money. There will always be exceptions to manage, suppliers who can’t use it, and administrative requirements and the costs will just be shifted.
Many early systems claimed big savings, typically in the 80% range, but never really delivered. The reality is that if the organization still has to support offline paper processes, still has to review all the invoices for errors, has to have an IT person administer the system, etc., the costs just shift. A modern S2P system has to support, and be usable by, all suppliers (and not just the top X that constitute 80% of spend), has to automatically detect errors and unmatched bids, invoices, and documents and has to be low, or no, cost to administer for the 80% savings to materialize. Otherwise, the buying organization won’t be able to achieve the 3X to 5X ROI the system is supposed to deliver and will not want it.

Trepidation # 4: We use X for purchase orders and / or Y for payables tracking and / or Z for Strategic Supplier Management. We can’t replace these systems.
A lot early systems expected that they would be the system of record for whatever the system did, and that all the system had to do was export the payments to a flat file for importing into the finance system. This is not the case. The platform has to integrate, in a straightforward manner, with the systems the buying organization uses for Purchase Orders and Inventory Management and Supplier Masters and the systems the buying organization uses for Accounts Payable.

Trepidation # 3: It Won’t Work For Us. Our Processes are Unique.
A lot of early systems followed the Henry Ford philosophy in that “you can have any colour as long as it’s black“. This doesn’t work for organizations that have distinct sourcing processes depending on the category type and value, distinct supplier relationship management processes depending on what the supplier supplies and where the supplier is located, distinct contract negotiation processes depending on contract value and risk, unique invoice approval workflows, distinct payment procedures, and different master-data storage policies. While the basic workflow is the same at a high level, it is different in the implementation across companies and the platform needs to support workflows that can be customized.

Trepidation # 2: Our Suppliers Can’t Use It / It’s Too Much Work for Our Suppliers
A lot of early systems took the view that “we have a portal that accepts EDI format and/or manual data entry and that’s good enough“. The problem is that supply organizations, like buying organizations, have different systems and different processes and, typically, don’t have the manpower to support a different bidding, data submission, and invoicing mechanism for each customer and, frankly, won’t. The system has to support the common processes and technologies used by suppliers in the buyer’s market. A few (small) suppliers can be given a single “portal” solution, but this has to be a minority.

Trepidation # 1: They Took Their Jobs and Now They Will Take Our Jobs!
A good S2P system with guided buying and auto-buy for low-dollar / non-strategic categories, which is exception-driven and requires a buyer to only manually review buys above a certain dollar amount, supplier approvals for key categories, and invoices that don’t match POs and / or exceed a certain dollar value, and which provides mechanisms all suppliers can use to submit electronically, should reduce the tactical invoice processing effort by 80% or more. This means that if the people doing the invoice processing had no other skills, then 4 out of 5 would lose their jobs. But if these are true procurement people, their job function would just be shifted to a more strategic role as redeploying these resources to spend more time on strategic supplier management, category management, and risk management would provide the organization with a value that (far) exceeded their cost. You don’t get rid of smart people just because you got a new system. You just ask them to deliver many times more, which they can do thanks to the new system.

I Write Alone …

While I wait for the World Cup to finish and your focus to return to work, here’s a classic from 2012:

I write alone, yeah
with nobody else
I write alone, yeah
with nobody else
You know when I write alone
I prefer to be by myself

Every morning just before breakfast
I don’t want no bad company
Just me and good buddy lonesome
That’s all I ever need
‘Cause I write alone, yeah
with nobody else
You know when I write alone
I prefer to be by myself

The other night I laid sleeping
And I woke up with inspiration
So I fired up my trusty Macbook
And I turned off dication
And I wrote alone, yeah
with nobody else
You know when I write alone
I prefer to be by myself

The other day I got invited to a circle
But I stayed offline instead
Just me and my trusty text edit
Spinning up a brand new thread
And I wrote alone, yeah
with nobody else
You know when I write alone
I prefer to be by myself

My fellow bloggers done give up on me
But I don’t feel inadequate
That the only ones hanging out with me
Are my dear old LOLCats
And we write alone, yeah
with nobody else
You know when we write alone
We prefer to be by ourselves!