Do Applications Need a "Botrance"?
Being an RPA vendor, I spend a lot of time thinking about ways to improve our platform for RPA practitioners. What can we do to make bots easier to build, automations more durable, production environments more scalable, and analytics more actionable? However, up until recently, I spent little time thinking about the impact our platform has on the applications upon which we intrude. The word “intrude” may seem a little harsh, but let’s face it, when was the last time a webmaster or application software vendor enthusiastically proclaimed; “Bots Are Welcomed Here”? Though not designed to deter RPA bots specifically, one need look no further than CAPTCHA, reCAPTCHA, honeypots or flat out bans of bots in T&Cs to figure out that bots are generally not welcomed. Why is that? It’s simple, bots create uncertainty.
No doubt, RPA is a productivity, accountability, and opportunity-creating boon for organizations that take it seriously. Those that look past the hype, apply it where appropriate, and take the time to do it right. And while it’s often true organizations engaging in RPA are automating their own applications, where the benefits of RPA clearly outweigh any potential toll it takes on their systems, it’s also important to recognize RPA often integrates systems that are not under the RPA practitioner’s control. And this is where the uncertainty and, yes, tension, originates.
The customer experience revolution is proving that successful organizations can only become and remain successful by, as Seleste Lunsford, Chief Research Officer at CSO Insights puts it, “align with the external, not the internal”. In other words, as it applies to this discussion, successful organizations must do business the way their customers want to do business. They must speak their language and satisfy their needs which includes, providing integration interfaces they want to use. And if that means welcoming bots, I say; “So be it”. But how? How do we do it in a way that gives the RPA practitioner agility and flexibility while providing the application provider stability, predictability and security? It requires cooperation.
Wait a second. Isn’t the allure of RPA that it can be used to integrate and automate processes and systems as we find them? If both ends of the transaction coordinate their efforts, doesn’t that negate the need for RPA? Isn’t what APIs are for? Not at all, because as I wrote in a prior post entitled; “RPA vs Native Integration”, there are lots of reasons organizations select RPA over native integration. many of which have nothing to do with the mere existence of an API. Trust me, I would love to live in a world flush with standards-based interfaces that allow for the frictionless flow of information and intermingling of processes across organizational lines. I’d love to live in a world where every business has an API that external organizations can “plug into” to transaction business. Heck, I’d settle for that within my own organization, let alone the rest of the world. But realistically, though we’re getting better at these things, neither is happening any time soon and we’ve got real problems to solve today. And so, the bots keeping increasing their ranks.
It seems to me that rather than spending time and effort trying to keep customers and partners from doing what they clearly want to do, which is integrate systems through RPA where applicable, application providers are better served embracing the challenge and welcoming the bots. In fact, I recommend they go as far as creating a “botrance” (bad name, I know), or a bot-friendly interface that makes systems easier to integrate, improves performance and reliability, in return for delivering providers the control and predictability they need. This could start as simply as making applications more “accessible” by design and incorporating assistive technology APIs a priority. This approach would also have the added benefit of making applications more accessible to folks with disabilities. Further, providers may want to consider creating a “technology contract” with RPA practitioners (a la WSDL or Swagger), where streamlined alternative UI interfaces are defined and explained along with a set of rules that define how the provider will monitor, throttle, and secure access. In other words, the provider offers a more RPA-friendly and reliable interface (probably separate and apart from the human interface, though a single source Responsive Design approach may help as it did for universal mobile access), in exchange for a promise to use a channel the provider is better prepared to manage. No doubt this will cause more work for the provider, but if it delivers a better customer experience in a way the provider can manage, I believe it will be worth the effort.
I’m not smart enough to know what the exact solution is but I see the storm clouds gathering and think a little thought now will head off a world of hurt and chaos down the road. And it just might help solve that scalability problem about which so many smart folks like to write of late. Am I nuts in thinking we'd all benefit from defining a set of rules of the RPA road? Am I exaggerating the problem? Maybe. However, if there's a solution to be had, I want to be part of it. How about you?