Jiffy RPA – Growing your Business, Bot by Bot
A Boston Consulting Group (BCG) survey of over a hundred businesses revealed a sobering statistic: in the past fifteen years, “the amount of procedures, vertical layers, interface structures, coordination bodies, and decision approvals needed in each of those firms has increased by anywhere from 50% to 350%.” This should probably explain why most of your time at work goes into finding the data you need to create those meaningful insights you were actually hired for!
As we mentioned in one of our earlier pieces, telecom has been one of the most dynamic industries — read, disruptive and disrupted — in the past couple of decades. Practically every form and factor associated with telecom has been turned on its head at least once, hasn’t it? We’ve gone from landline services to mobile phones to wireless landlines; we’ve seen content become one of the main revenue drivers along with the core services and products; we’ve seen costs drop and consumption soar, and we’ve seen traffic the likes of which Graham Bell could never have imagined possible.
And this dynamism has extended into the business model of each and every company operating in this space as well. At one end of the spectrum, you have fully-integrated, self-sufficient telecom companies who own every critical component of their value chain. At the other end, you have telecom operators who own practically nothing except the rights to transmit over a frequency band and customer data. Most companies fall in between, however, and will certainly benefit from a switch to robotic process automation (RPA).
RPAs for Telecom
RPAs consist of arrays of bots. A bot is a software program that mimics a repetitive, robotic function that requires low levels of applied intelligence — in the conventional sense of the term — but high speeds at consistently near-perfect accuracy. While first-gen RPAs were notorious for failing to scale up or interoperability, modern ones can perform flawlessly under different conditions. In terms of speed, scope or capabilities, they can be scaled up or down through simple, easy-to-operate interfaces. For a complex industry like telecom, this is possibly as simple as it can get without compromising on data security.
An RPA can easily plug into different types of enterprise software, even those running on other technology frameworks, as long as there is an interface – any interface – it can be given access to. Data can be consolidated from across different formats such as excel sheets, web pages, emails, OCR-compatible sheets, screens and other ad hoc implementations. Additional validations can be programmed in for every format and at every stage as needed.
This means that an RPA for telecom can process data not just from internal sources but also from external third-party sources. This allows a level of inter-operability without ever risking contamination of data since the two disparate systems are never connected to each other.
Minimal Scripting, Maximum Automation
With purpose-built RPAs the norm these days, there is a greater degree of freedom when it comes to modifying an RPA to suit a particular firm’s systems. For instance, an RPA built specifically for the telecom industry knows what information to look for, how different data sets will work together and what reports will be relevant to an employee of a telecom firm. Competing firms A and B might differ in the finer points of how they implement the same RPA solution – for instance, the data formats, sources, conditions, etc. – but they will be expected to adhere to the same regulatory and reporting rules and formats as anyone else from within the same industry.
Since RPAs are highly automated systems, it is possible to set up the generation and sharing of regular reports to specific employees, an activity that can otherwise require a dedicated resource – or at the very least, a significant amount of time and effort from a resource who could have been better utilized on another task. Bots can also be tuned to listen in to specific events and trigger appropriate responses based on the context.
Range of Functions
A good RPA solution should be able to work on and process data for various departments across the organization. The Finance and Accounting (F&A) team, for instance, will need to collate sales, collections, procurement, expenses and incentives, cash flows and vendor setup. For the IT team, the RPA should manage tickets, alerts and the entire help desk system. Legal should be able to call upon the RPA for reports on contracts (especially those slated for renewal and/or renegotiation), digitization and even discover precedents and citations that can be relevant to the issue at hand.
Thanks to its modular architecture, it is easy to distribute an RPA across as wide an organizational net as needed. It can be run on hundreds and thousands of terminals, independently and in tandem with each other. Advanced bots integrate artificial intelligence and machine learning, creating a robotic process that’s not just automatic but also (largely) self-piloting. Such an RPA can handle exceptions, even those it may not have encountered previously.
The Horizon Conundrum
It’s not too much of a stretch to state that an RPA’s limitations are like geographical horizons – just when you think you’ve explored all that an RPA is capable of, you discover another feature, another possibility. RPA implementations continue to evolve every day, becoming faster, more powerful, more intuitive both as a unit and in its constituent bots. At the end of the day, though, it’s what you use it for that matters… to help you with as much, or as little, of your business as you want.