22 steps to Automate almost anything. How to go from a NOOB to an Automation PRO
Relying on existing staff who are inexperienced in automation is understandably seen as far too risky without expertise on hand.
· What if the automation solutions that team deliver aren’t robust and full of bugs?
· What if their delivery is too slow?
· What if the bots are built wrong and wreak havoc?
It’s a valid concern, but let’s look at the alternatives. You could hire a small team of experts, but this is expensive and becomes more so as the demand for automation increases.
If you had the budget for a large external team, this would require considerable onboarding time to get acquainted with stakeholders, business processes, cultures, and applications. If you’ve every onboarded a large external team before you’ve probably experienced the chaos that can ensue.
Empowering your staff to do it themselves, in a repeatable and controlled manner, may be your best bet. It could even be much faster in the long run and keep spend down. Lean IA as actually reduced the implementation of automation into just 22 repeatable steps. Following these steps can allow your team to execute automation company-wide programs and projects like professionals.
In these 22 steps, there are four stages: STARTUP, PROJECT, DEVELOPMENT, LAUNCH.
This is the first stage. Depending on how far along your team is in the automation process, you’ve already done these steps, but it’s best to double check that your team have done these right and you have everything in place
Make sure you have a list of your key stakeholders, the directors, key influencers like HR, IT and Change management. This is so you know who to speak with to get alignment for your automation program.
Understand the objectives and main pain points of your key stakeholders. You will be able to use the things that are teams struggling with to get buy-in and show how your solutions can solve this. Otherwise, without buy-in and alignment these same stakeholders could become blockers later down the line.
Have a high-level process of the end-to-end process of your department or team that your program will cover. This will help you understand how sub-processes fit together into this high-level end-to-end process
Identify the end-to-end process experts. Who in the business can help you connect the dots? This may not just be one person but may be a collection of a few people, who can help you paint that picture and knit the different bits together the end-to-end workflow.
Create a team and department structure, maybe your company already has an “Org chart”. This can show you the teams and sub-teams within each departments and business unit, as sometime this isn’t very clear and straightforward, especially in large corporations.
With this structure you can see how different teams interact and communicate with each other. This will be valuable for root cause analysis as large processes typically run through several departments and teams, and as you build different automated solutions, you will be able to join them up into larger, transformational end to end solutions.
Now it’s time to gather the high-level information about the departments, the teams, and the types of activities they do. This will be used to paint a company-wide map of automation opportunities
Use data analytics to analyse and present the data collected to give a clear picture of where the opportunities throughout your business are and convey this back to the senior leadership team. Pareto charts and Opportunities maps in the form of Bubble charts are help demonstrate where the highest value areas of the business or department are, so that you can guide your team on where to focus attention.
Knowing where the opportunities are is one thing but working with the business to prioritize these opportunities in the right order is vital for a successful rollout. Your data analytics should make it obvious which teams should be targeted first for your automation program and which processes definitely should be left to last. Business leaders typically have the final say on the order of attack when creating your enterprise automation roadmap, as they have their corporate objectives to consider, however this should be based on your data-backed recommendation which used the data collected to build momentum gradually and progressively.
The worst thing would be to go for the big fish right at the start which takes too long to implement and stalls momentum as teams lose faith and motivation (which does happen far too often with new automation teams). It’s advisable to start small, building my momentum slowly as your team matures. This will give you the best chance of a successful roll out
With a target team or business area to focus on you have a finite area to easily gather more detailed process data. It would waste a lot of time collecting data on teams which don’t have many opportunities for automation.
Gathering process details will help you to find ‘Quick wins’ (processes which are both easy to automate and deliver significant savings). You will be able to filter all automation suitable processes and create a large backlog of projects.
Out of all the processes that are most suitable for automation you can create a shortlist of the best processes from the best team, from the best department. which will give the highest returns.
Maybe you have 20, 30, 50 processes in your backlog which is suitable for automation. You want to prioritize the best processes in your chosen and create that short list.
Very quickly in about 10 to 11 steps, your team will be able to scan your entire division or company and generate a shortlist of the highest value opportunities to automate.
Run cost benefit analysis calculations to confirm that these projects have the high Return on Investment you expect. Compare the cost savings and benefits from automation to the costs to build the solution (including the cost of running the automation, the hidden costs of servers and maintenance etc).
With cost benefit analysis you can prove that you’re working on the most impactful projects, and you will be able to confidently estimate how much savings you’re projects will deliver to the business.
To start an Automation project, start putting together a Process Definition Document (PDD) to capture all the details of the As-Is process (the current situation), as well as the problem statement and inefficiencies that need to be solved.
Map out the as-is process, what the team does right now? This would require walking through the process with the process experts to learn of exactly what the process is. There are two parts to this. The second involves re-engineering the process and map out what the solution will look like.
You should use lean thinking first to streamline the process as you don’t want to just automate a bad process.
Create keystroke document to detail exactly what the robot aka Bot should do. Robotic Process Automation (RPA) uses the User Interface similar to you or I would, clicking on buttons and typing keystrokes. The keystroke document must capture precisely what the Bot clicks and what it types, as well as all other actions and decisions the robot will need to make.
Refine the PDD with the future state defined. The Automation Analyst liaises between the developer and the process expert(s) to make sure that the developer has everything they need to build the correct solution that will meet all in-scope requirements.
Make sure the document is clear, complete and unambiguous, and the automation will be fit for purpose
The developer now creates what’s called a solution design document (SDD). This is where they convert the Process Definition Document (PDD) into a more technical document showing the Bot’s architecture.
This is to make sure you have a test plan in place that mirrors the user stories (what the users wants the automation to do), and start gathering test data. Create acceptance criteria around each user story to define how to test something and how to know whether it was successful or not. But don’t just test that it did what the user wanted to do (e.g. it successfully logged in), but for robustness, also test the negative cases. For example, how did the bot react when it didn’t have the correct credentials?
You want to test that the robot is capable of handling errors and exceptions correctly (both known and unknown exceptions). You can’t program for every specific scenario, so anything outside of the scenarios that you’ve determined are dealt with correctly, and preferably the process experts are notified so that they can manually process anything that wasn’t automated.
Whether you’re hiring a developer, or you’ve trained up an existing staff member, here are six standard development best practices which you should check on every development. They are agnostic to whatever platform you’re using
· Documentation — Adequate knowledge transfer so any developer can understand how to modify or support the bot.
· Modular code / reusability — Segment the bot into components for steps (e.g. log in/out, data validation, etc.), this makes it clear in the logs where the issue happened.
· Error handling and logging — The bot notes the outcomes after completing each step in the process. If there’s an error, it can reference in which component the error occurred.
· Commenting/readability — Well-laid-out code so the logic is clear, and well commented so someone else can read what each section does, and why certain logic was used.
· Variables and referencing — Variables represents some value which can be referenced in several places in the code; however, the developer only needs to make the change to the variable to ensure that the value has changed everywhere.
· Test planning — Having a structured approach to testing saves time. Testing of each component individually, then as a whole, is easier to fix than building and testing the whole thing at the end and then having to look through the whole process to find the issue. Also, it’s advisable to test to failure rather than test to success. The tester (preferably a developer other than the original builder) should try to break the bot, using various scenarios and bad data. This should be done even before UAT.
· Something I like to call User flexibility — This is designing the robot in a way such that the user can make small changes to the process without the need for the developer — e.g. creating an Excel spreadsheet and data table which could be updated for the robot to process new information, as shown in image above or allowing for several spreadsheets to come from different sources and still all be processed by the same bot.
Once the developer and build and testing the automation (preferably peer tested too), now it’s time to see if it really is fit for purpose. User Acceptance Testing tests whether the users are happy with the finished build. This is whether the user triggers the bot, reviewing the actions and outputs (with the support of the automation analyst) and the process owner and key stakeholders sign off that the automation works as they expected, and it’s passed all the test cases.
If there are any errors, the team will create a log of bug fixes for the developer to fix so that it passes all acceptance criteria.
This is only the beginning
You may think that launching the bot is the end of your automation team’s roles but this is just the start, as the next few steps are there to confirm that the last 20 steps were executed successfully and you now have a robust automated solution running in your business
This step is often missed by new automation teams; however I believe this is probably the most important step. Hyper care, which is also called warranty period or post go live support, is the transition period from being an Automation project to becoming BAU (business as usual). This is where your Automation team (automation analyst, developer, support and the process expert) are all keeping a close eye on the newly launched process.
The purpose is to quickly fix any unexpected issues that may arise (it’s not uncommon for automation to act differently in the live environment even when it acted perfectly in the test environment), and also, for more critical processes, you can slowly scale up the automation. For example, if it was a financial process, you could have the new automation only handle transactions less that $100, and then less than $1000 and so on. Or if it’s to do with customer service, you can assign only 100 cases a day, then 1000 cases.
By slowly rolling out workload to the Bot this minimises the damage is anything went really wrong, until you have full confidence in the automation. Other ways to give the business more confidence, before you leave the bot on its own, is to extend the Hypercare period from 2 weeks to say 4 or 6 weeks. So financial services companies have this period months long.
If your new team has successfully completed the last 21 steps you should definitely celebrate this. You now have a robust Bot in your business delivering value and you still have more great opportunities on your backlog. But then again, is your Bot actually delivering value?
Benefits realization is the whole purpose of why you’re doing automation. You shouldn’t be just automating for automation’s sake, you want to deliver a real benefit. The business leaders will want to know did it actually make an improvement and meet user expectations? You need to measure the benefits and the KPIs now that you’ve launched and compare this to what you measured before, to prove that it added value.
BONUS: Step 23
As a Continuous Improvement Analyst at heart, my favourite step is enhancements. You’ve launched your automation; you’re delivering benefits and everyone’s happy. But what other new technologies and Artificial Intelligence capabilities can you plug into your automations to do more?
Once you’ve completed the START UP steps, you can keep looping back through the PROJECT-DEVELOP-LAUNCH steps to create more automated solutions. With many automated processes throughout your business, you may now be in a position to build a big business case for why your business would benefit from purchasing a ChatBot licence.
Maybe now you can evidence that 20 of your automated solutions would be able to provide 20% more value if you purchased Optical character recognition (OCR) to pull data from invoices and scanned images, instead of staff manually inputting this data into your automated workflows.
I’m excited that you will be entering into the world of Intelligent Automation once you reach step 23. If you want to learn more about these steps and topics around Intelligent Automation in your workplace, subscribe to my YouTube channel Tony IA (Intelligent Automation, Simplified) for videos created weekly, to simplify intelligent automation for business leaders and professionals who are new to automation to level-up your knowledge. Become empowered to optimise your business and discover new technologies, in a lean and accelerated way.
You can also learn more about the expanded 36 steps in my blue book of secrets, Business @ the Speed of Bots: The AEIO YOU method HOW TO IMPLEMENT ROBOTIC PROCESS AUTOMATION THAT SCALES. Get ready for the new digital transformation age for more information. The foreword is written by Guy Kirkwood, who is ex-chief evangelist at UiPath, and a very well-known advocate of RPA with over 20 years of experience in outsourcing.
To help you reach your goals by keeping up-to-date on Intelligent Automation news, new articles and videos…