Digital transformation is a phrase that has become a mantra for nearly every organization. The essence of digital transformation can vary significantly from business to business, but one of the bedrock principles is it makes them more dynamic, nimble and able to benefit from collaboration—both formal and informal. For documentation around software systems, however, digital transformation often means little beyond creating them electronically. The systems evolve so quickly that the documentation is often quickly obsolete.
Blueprint Software Systems, a 15-year old company created to help businesses create dynamic business requirements and functional design documents, saw an opportunity to bring the same dynamism to RPA design. Charles Sword, the company’s chief revenue officer, points out that the first step in that process is often a simple Word template to capture design requirements.
Sword recently sat down with RPA Today to discuss trends he has seen growing in RPA, common pitfalls for companies deploying RPA, and how a dynamic design environment for RPA—designing things visually, rather than using static text documentation—could benefit RPA users going forward.
RPA Today: So, if I don’t want to start with static documents, where should I start?
Charles Sword: People have purpose-built tools to design complex technology. We just applied that idea to RPA. We have a digital blueprint that allows you to define a process fully, with great detail and precision. But more than that, it’s not a static artifact. It can be transformed into many of the downstream work products that you need to actually build technology.
So, as opposed to a developer sitting down and reading through a big, thick design document and having to figure out what they want them to build, we actually pre-populate all of the process flows, all of the major business objects, all of the major actions that have to happen in much of the parametrization of each step or each task within that process flow. The task for the developer is really just stitching it all together and testing it. And testing is one of the gaps that we think is significant in RPA. It’s part of the reason these solutions are so brittle and fault prone.
RPA Today: The failures and exceptions are a major frustration point for a lot of people. What is the typical error rate for a document-based workflow?
Charles Sword: This is not our data, but it’s interesting data and it’s been measured over decades. The industry has a really good handle on that number and it’s somewhere between 35 and 40 percent.
There’s typically no holistic architecture around an automation environment. Automation A gets built one way, automation B gets built another. There’s not a lot of standards and practices applied to that, which can lead to variability in quality.
The industry has to raise the quality of these automations. It’s the Achilles heel of RPA right now. We think we provide a piece of that—better design through better collaboration and communication about what needs to get done. We’re raising quality in order to deliver more business value, and I think you’ll see more of that, not only from the process discovery folks, but folks like ourselves, and even the RPA vendors.
RPA Today: From the end user’s perspective, where is the revenue opportunity in RPA—attended or unattended?
Charles Sword: It definitely depends on the maturity of the organization. There’s always low hanging fruit in organizations if they’re early on in their journey. As you go down that path and begin to scale your program not only in terms of the sheer number of automations you have, but in the individual complexity of any of them—and the attended bots are more complex by definition—those are often some of your best opportunities. But, it’s not usually where people start.
There’s also a fair bit of variation in the RPA vendors and the tools they have available to do attended or unattended automation. Which leads to another conclusion. One of the things that we see happening this year is there will be more migration between platforms than ever before.
RPA Today: Why?
Charles Sword: Frankly, there’s no good way to migrate from platform A to platform B other than just sitting down and manually rebuilding all the automations. And, there’s not a great business case behind that. One of the things we brought to market this year is an automation migration capability, having the ability to reverse engineer bots from any platform and then to push them out to any platform.
In the second half of this year, I think you’ll see two things happen. There’ll be platform consolidation within particular accounts where people have bought some of vendor A, some of vendor B, which happens in big organizations all the time. As they look to create CoEs and have a more efficient environment, you’ll see platform consolidation within accounts. And, more broadly, you’ll just see a highly competitive battle between the major platform vendors to grab market share and accounts from each other.
There’ll be a lot of big migrations that happen over the course of the next 18 months. And don’t leave Microsoft out of that. People have been waiting for Microsoft to make its mark in the space. Their recent announcement is the beginning of that manifesting itself.
RPA Today: Why is there incompatibility with version upgrades and why do you think some of the vendors are doing this?
Charles Sword: It’s hard to speak for them. But, I can tell you it’s causing angst that’s fueling the migration story we just mentioned. When you make it hard to upgrade to the latest and greatest, it creates a moment where folks can now consider alternatives.
While I can’t be too specific, we’re pulling together an industry consortium with a lot of the process discovery folks and at least one of the major RPA vendors to try to prevent that very challenge. One of the big problems is there are no standards within automation today. We want to drive industry standards for how these things are designed so that there is portability between solutions.
We think there’s an opportunity to do that here. Certainly, you need the right players on the board. So, we’re trying to pull together all the right folks and drive forward a standard. We think it’s to the benefit of not only our end customers, but also to the industry as a whole so we can build better solutions.
If you liked this article, please sign up to RPA Today! Registrants will receive our free weekly RPA newsletter updating you on the most recent developments in the Robotic Process Automation, Intelligent Automation and AI space. In addition to news updates, we will also provide feature articles (like this one) with a more in-depth examination of RPA issues for end users and their enterprises.
