Digital Transformation Journey

Now we all know that RPA saves money. It cuts down on employee time spent on tedious tasks. It makes business processes move along more quickly. But, what does RPA cost? This is a critical question that anyone contemplating RPA must think through as thoroughly as possible. The costs will vary greatly depending on a range of factors. It is possible to arrive at a realistic budget estimate, however, if one considers all of the cost elements that go into an RPA project. At the outset, it makes sense to separate the costs required to launch RPA from the project-by-project and BOT-by-BOT costs that come once the platform is up and running. The cost of the automated BOT implementation depends on variety of factors like the complication of the BOT (multiple conditions, multiple checks, and multiple operations or just one streamlined process), time and efforts spent on the initial business processes analysis, initial setup and programming required and, finally, costs of all APIs and apps used

Companies in every major industry are turning to semiautonomous computers (better known as BOTs) to automate large- and small-scale business processes. This technology replaces human intervention in back-office operations, improving operational efficiency, reducing costs and increasing margins. However, organizations cannot employ this technology effectively unless the BOTs are engineered properly. And one of the most important component of this BOT engineering is Exception handling or in simple words right categorization of the errors and then developing solutions around the same to deal with those errors to meet the expectations of the RPA owner. Occasionally, in the course of its work, an RPA BOT definitely encounter a situation it was not programmed to handle – and, in those cases, it will stall. Those cases can be for foreseeable reasons – security or access constraints – or it can be for unforeseeable reasons – like missing or incorrect data. Increasingly, RPA developers are ab

It is normally viewed that one of the advantages of BOTs is their consistency. BOTs do exactly what they are calibrated/ programmed to do, and this provides consistency and repeatability or even eliminating unpredictability in how a process is performed.  However, reduction in unpredictability can be both good and bad, depending upon how we interpret our process performance data, and how we apply it towards this reduction in unpredictability. No doubt, automation eliminates unpredictability or variation. While humans may perform a task with a wide range of skills, BOTs are much more consistent, but they will perform the task the same way each time, every time, unless an exception is experienced.  Hence, modeling process performance based upon average process cycle times can often lead to suboptimal choices in process, and suboptimal performance expectations. Operating metrics are often used to identify processes worth automating. It is common to select target processes based upon their

As we all know RPA takes the robot out of the human. In general terms, RPA is a type of software that mimics the activity of a human being in carrying out a task within a process and freeing them to do other tasks requiring human strengths. RPA projects follow Robotics development life cycle (RDLC), very similar to software development life cycle (SDLC), like any IT project. After the process prioritization and requirement gathering stages, the most important phase of RPA development is solution designing. We should give a sufficient amount of time to solution design before any implementation/coding happens because the success & failure of the deployment heavily depends on it. Also let’s make sure that each identified automated process should have a solution design document. While designing the solution we should always keep note of these few points… Trigger Point: Before any real coding or development happens, think about how the BOT will be triggered in the future. It is importa

Someone said very rightly – “Automation is good, so long as you know exactly where to put the machine.” In all my previous blogs I wrote about BOT failure, ROI Modelling, Cost saving, RPA Governance, CoE, POC, POV etc. But then I realized that before taking a deep dive into any of these subjects, first we need to have a right RPA process identification & prioritization methodology in place. Everybody across the industry agrees that Robotic process automation (RPA) can make a big difference for organizations tormented by repetitive routine processes – the kind that suck up the productivity of people whose time would be better put toward more important work. But many are confused by what seems to be a deceivingly simple question — which are the right processes for RPA? The poor choice of process for initial pilot is the leading root cause for failure to meet customers’ expectations. Robotic Process Automation (RPA) doesn’t suit every process and in majority of cases we don’t have

We keep reading and as business leaders claim that Robotic process automation (RPA) has made great strides in fulfilling its promise to the marketplace. RPA has positioned as a no-code end-user computing tool, owned, and operated by many business functions, that automates routine work tasks with quantifiable business results. Now, businesses have a digital workforce in the form of powerful new end-user computing tools positioned and priced attractively to operations and finance leaders. It has the power to reduce the dependency on traditional automation delivered by IT, improve productivity and accuracy, reduce operational risk, and enable redeployment of expensive human resources to tasks that add more value. But how far this claim is true or close to the reality need to be rechecked... We all know that RPA maturity model is designed across industry around two key components - the first one around RPA strategy or RPA operations and second is the levels of RPA Maturity that can be used

The Robotics Process Industry is known for introducing & adopting several terms in its journey so far like - AI, IA, CoE, CV, CNN, DL, ML, NLP, NLG, iOCR, POV, POC, RNN etc. One term that is quite high in the list is “Proof of Concept”, or POC. POCs are not special to Robotics Process Automation, but very unusual if the RPA project doesn’t start with a POC. In general, a proof of concept (POC) serves as a stimulant for those businesses looking to leverage the RPA technology to improvise their business process outcomes. A POC can be built for one entire process or a small part within the process. Now a days the most surprising thing is that every company that is planning to use RPA technology believes religiously that they must start the work with a POC so that they can ensure and can see themselves that BOT software is working before full blown deployment. To a large extent this is justified, given the exceedingly high failure rate of the RPA projects. But it is bit difficult to ac