Category Archives: Technology

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.

GDPR Just Made The Best Argument for Making Your Data — And Applications — Available Online 24/7 Even Better!

Seven years ago SI published a short article that stated <i>if your data isn’t immediately accessible online, either behind your firewall or behind someone else’s firewall or in the cloud, when your employees need it, then they are going to download it to their machines. If their machine is a laptop, and the data is not securely encrypted, and the laptop is stolen then … it could cost your organization 1 million (or more)</i> based upon research conducted by ZoneAlarm. There were a host of reasons for this including fraud costs (if financial information was stolen), lawsuits (if personal data was stolen), market loss (if trade secret data was stolen and sold to your competitor who then got a jump start on a competing product), and so on.

However, GDPR has upped the cost of a breach. Given that a single violation could result in a fine equal to 4% of your organization’s annual revenue, that could be a 4 Million, 40 Million, or even a 400 Million fine. And it’s not unreasonable to think that the EU could slap that size of a fine on you if you didn’t have any controls or policies around personal data and didn’t even notice when a junior HR employee decided to download your entire corporate directory to his laptop to do “statistical processing” on the weekend, didn’t bother to even encrypt the data, left the laptop at the bar where he stopped for a drink on the way home, where it got stolen, and the entire corporate directory, complete with SIN numbers and banking information, ended up on the dark web Saturday morning.

But if your data is online 24/7, and all of your applications your employees need to process that data is online 24/7, then they have no need to download the data, and if it’s easier to do it online than download, they won’t even try.

And don’t say its insecure to put your data and applications online. Don’t forget that as long as you have an internet connection coming in (and you do), your data is online whether you like it or not, and if the appropriate security precautions aren’t in place, any script kiddie who wants it can get it.

And unless you are an IT SaaS solutions provider, chances are your internal security controls are not as strong as the security controls the provider has put in place. Offering data and application security is part of their core business, it’s not part of yours. You can be sure they have strong encryption in place, multiple firewalls, DDoS detection capability, deep logging capability, penetration attempt detection, and other security controls that you likely don’t have.

Also, modern SaaS providers support private database instances (so if someone hacks your competitor, you don’t get hacked), private application instances (on your own private virtual machine that can be configured to only be access through your own private VPN), and deep security controls around users and roles.

So unless you plan on going 100% offline, and keeping all your data on machines only accessible on servers in highly secure facilities surrounded by Faraday cages, it’s probably safer for your organization to go 100% online.

M&A Has Been Mad. Platforms Will Disappear. But There Will Be More Than One. But Who?

We’ve been writing a lot about M&A lately, including, but not limited to, our pieces on:

because M&A is still going strong. (And, as per our recent post on The Hidden Value of SI Association, SI is acutely aware of this because this is how it loses its customers. SI works with these companies, helps them become known and successful [through a focus not on buzz but actual education, process improvement, and appropriate roadmaps], they get noticed by cash-rich firms, who then buy them, and in many cases, strip out the management teams and/or consultants.)

We’ve also noted that not only will some platforms have to disappear (to make the mergers successful) but that (in our recent piece on One Vendor Won’t Rule Them All … And One Ring Won’t Bind Them), due to the wide range of needs that organizations need and the different process that are used around the globe in organizations headquartered in different regions and run by different cultures.

But that being said, now that Sourcing and Procurement technology is starting to become more mainstream — and the majority of organizations are looking for analytics, procurement automation, and supplier program management — those organizations that are looking for their first platform (as well as the early adopters of first generation platforms that are now almost a decade behind) are trying to figure out who they should look at and, more importantly, what product lines they should look at (now that some organizations have as many as three different product lines for Procurement under one organizational roof).

This is hard to predict, especially since the Fortune 500 is in more flux than it’s ever been. It used to be if you were on the list, you were on the list for years (if not decades) and changes were subtle. Now a company can make it one year and as a result of one major disruption or media fiasco, be in bankruptcy the next year (and disappear from the list). And while most of the companies in our space are not on the Fortune 500, these companies are now being bought by the big enterprise software giants, including SAP (with a market cap over 100B), that are.

And the instability in enterprise software companies amplifies they smaller they are, and when the biggest stand-alone public company in our space has a valuation of a mere 2.5B and the largest private company in our space would likely get a valuation in the same range, you can see where we are when the average large company has revenues that you have to round up to 100M and the average BoB vendor rounds to the 10M range.

But the platforms provided by some companies, due to the immense value they offer, will survive, even if under a different name, as part of a different platform, under a different company, held by a different holding co, whose name may change three times over the next decade. And who will they be?

Simply put, they will be those platforms that are the hardest to replicate and offer the deepest capabilities that are key to value identification, like optimization, advanced predictive and prescriptive analytics, cognitive process automation, semantic risk identification and monitoring etc — whether the platform is a standalone best of breed platform in a financially stable 10M company or part of a suite of a larger 100M company or just one module in a suite in stable of suites in a 1B enterprise. So don’t try to guess which vendor will survive, instead focus on what platform will survive — and chances are you will be setting your organization up for success.

RPA: Are We There Yet?

Nope. Not even close. And a recent Hackett study proves it.

Earlier this month, The Hackett Group released a point of view on Robotic Process Automation: A Reality Check and a Route Forward where they noted that while early initiatives have produced some tangible successes, many organizations have yet to scale their use of RPA to a level that is making a major impact on performance, likely because RPA has come with a greater-than-expected learning curve.

Right now, mainstream adoption of RPA is 3% in Finance, 3% in HR, 7% in Procurement, and 10% in GBS – Global Business Services. Experimentation (referred to as limited adoption) is higher, 6% in HR, 18% in Finance, 18% in Procurement, and 29% in GBS, but not that high, especially considering the high learning curve for the average organization will end up with a number of these not continuing the experiment.

Due to the large amount of interest, Hackett is predicting that, within 3 years, RPA will be mainstream in 11% of HR Organizations, a 4X increase, 30% of Procurement, a 4X increase, 38% of Finance, a 12X increase, and 52% in GBS, a 5X increase, as well as increases in experimentation. Experimentation will definitely increase due to the hotness of the topic, but mainstream adoption will require success, and as Hackett deftly notes, successful deployment requirements have certain key prerequisites too:

  • digital inputs
  • structured data
  • clear logical rules can be applied

And when the conditions are right, organizations:

  • realize operational cost benefits
  • have less errors and more consistent rule application
  • benefit from increased productivity
  • are able to refocus talent on higher-value work
  • strengthen auditability for key tasks
  • have enhanced task execution data to analyze and improve processes

But this is not enough for success. Hackett prescribes three criteria for success, which they define as:

  • selecting the right RPA opportunities
  • planning the journey
  • building an RPA team or COE

and you’ll have to check out Robotic Process Automation: A Reality Check and a Route Forward for more details, but is this enough?

Maybe, maybe not. It depends on how good of an RPA team is built, and how good they are at identifying appropriate use cases for RPA, and how good they are at the successful implementation. Success breeds success, but failure eliminates the option of continued use of RPA, at least until a management changeover.