Don't launch your bot WITHOUT these 5 things?

If your automation team has just finished building an automated process and you're soon to launch…

WAIT!

I want to cover five things you MUST have in place after the automation has been developed but before you launch it into production

I urge you and your team to tick off all five things otherwise you could be heading towards a world of frustration, that will cost you later on in expensive change requests and it will have your end users feeling very disappointed.

?

If your new automation team has built its first automated process, then you've already come a long way; you've found the opportunities, you've designed it, built it, and you've tested it. These tips will make sure that what you've built is fit for purpose meets expectations

?

?

#1 User Acceptance Testing (UAT)

The purpose User acceptance testing or UAT makes sure that the end users who will be using or interacting with your automation are happy with how the automation works and with the outputs of the automated process.

Without this you won't be able to evidence that you've delivered what the user has asked for and there might have been some misunderstandings that wasn’t captured correctly in the analysis stage. If the automation doesn't work or if it's not fit for purpose then the end users just won’t use it, and your automation will be sitting there not delivering any value.

Granted, your analyst team should have carried out a detailed assessment right at the start so hopefully no major issues should arise at this point, however if you’ve got into a stick situation at UAT stage, it would be good practice going forward to have your business analyst create a list of user stories, whilst reviewing the process and the need for automation with the process owner, so that during the UAT stage you can tick off these user stories (in the form of test cases) to have no doubt you’ve met the requirement.

With user stories, the user lists exactly what they do or what they want the robot to do for example

“as a user in the {type of user: e.g. operations team} I want to be able to {do something: log into the application}, so that I can {achieve something: access the customer profile}”.

With your list of user stories these can become test cases, with some acceptance criteria wrapped around each user story describing how to confirm the test was passed. E.g. was the correct email and password entered, and was the robot able to get into the application?

A good acronym to use to ensure your test plan is accurate is SIPOC:

• ·???????Supplier - where should the information come from?
• ·???????Input – what does the input format look like?
• ·???????Process - what are the actual process steps the robot should do?
• ·???????Output – what does the output data look like (maybe it's in the form of a pdf or an email)
• ·???????Customer - who is that information going to (or where is the output data stored)

With a robust test plan in place, the process expert/end user can tick off the test and sign off the UAT that the automation meets their expectations ?allowing the business to confidently make a Go-Live decision.

?

#2 Hyper care, Post Go-Live Support

The User acceptance testing is performed in the test environment, a simulation of real life, however once the automation is launched you will need what’s called a Hyper care phase, and is also called Post Go-live support (PGLS) or warranty period. This is when you've launched the automation into the live environment, and it is now processing live data and performing real life scenarios.

This phase may be just one to two weeks though it could run longer if it's a more a very critical business process. The purpose for this is to have your automation team (Developer, Analyst and Support Engineer) babysitting the automation to quickly resolve any issues if anything goes wrong. The reason being, it is not uncommon for the robot to behave differently in the live production environment to how it behaved whilst in the test environment, no matter how well you tested the automation. There are many reasons for this (unexpected data formats, new/unknown scenarios or a slightly news application version). Without this step, if your process is financial or interacting with the end customer or clients letting automation loose start after launch could be detrimental both financially and reputationally.

Taking this caution furth, it’s advisable to take a phased approach. Be that with:

• ·???????Volume: start with giving the robot 10 cases a day, then 100, then 1000 – rather than the full volume of inquiries on day one
• ·???????Financial: start the robot with only transactions under $10 then up to $100 then under a thousand dollars.

Slowly scale up gives your development team and support teams enough time to catch any errors, fix any bugs and quickly respond whilst limited potential damage being caused.

Once the Hypercare period is complete the business and automation team should have some predetermined exit criteria agreed, as there may be new exceptions and ideas for refining the automation, but the exit criteria can help avoid scope creep.

?

#3 Automation Instructions

Automation instructions is generally a forgotten step in new automation teams, where they walk the process owners through the automation, but nothing is documented for the business to refer back to at a later date. What if the staff get a new team member, what if the original process owners on the project move on – the business still needs to know how to interact with the automation and who to speak with if/when something goes wrong.

This document is like a work instruction or a user manual for the user to know how to use this automation. After the hyper-care is complete, the business will need to manage this automation and so the document should have all the information to do so:

• ·???????how it is triggered or when it is scheduled
• ·???????High level understanding of what the bot does behind the scenes
• ·???????how the user gets notified when the robot starts or completed the work
• ·???????How the user is alerted when something goes wrong
• ·???????there may also be some do's and don'ts, (for example if the user cannot go into a folder whilst the robot is using it)
• ·???????who they need to call or email to fix something

?

Get agreement from the business team(s) that the document is clear and unambiguous. Better yet, have the user use this during the Hyper-care stage

?

#4 Benefits Tracking

Benefits tracking is the whole purpose for this project, as it answers the question “Did the automation actually deliver value, was it worthwhile, did it actually make an improvement? How accurate were we from our Business case prediction?”

If you don't track or measure the benefits and savings after you’ve delivered the automation then how would you even know that an improvement was made? You need to measure BEFORE (capturing the key performance indicators during the analysis phase) and AFTER to see if the KPIs changed.

Did errors reduce, did turnaround time shorten, did accurate improve?

Some measures are difficult to determine such as customer satisfaction or staff morale, however if that’s the metric that needs to be improved we cannot assume that just because we automated it and put AI on a process it will make a positive impact.

?Best to brainstorm with staff teams (and IT) in a workshop what mechanism you will need to put in place to measure this and the continually track the benefits going forward into the future. Can we pull data logs from the system? Can we just use the robot’s logs?

Some benefits can dwindle away as time goes by. Some benefits over time can drastically change, for example if a process has more errors or exceptions which require the staff to handle, this will reduce the actual benefit the automation is providing.

?

#5 Enhancements

Remember Process Automation, be that RPA or Intelligent automation is not a one and done thing, it should be continuous improvement. After you've automated your processes, you will want to circle back maybe because there's new technology on the market, the technology you’re using has moved along or potentially your business or team has bought new technology that can extend the scope of your automated processes.

With any luck, during your discovery stages and workshops, you should have a long list of potential projects that you had put aside, that can now be executed or improved on with these new technologies. You could approach the budget holder to say “we've discovered 20 use cases that we can enhance if we bought a chatbot or OCR (Optical character recognition) or machine learning etc”

?

Thanks for reading, if this resonated with you I'd love for you to hit that like button and share this newsletter for your colleagues to subscribe, so that they too can get notified of my weekly articles.

---

If you're like us then you've probably had enough of the common challenges and stresses of RPA and AI projects. Our tool, AutoLyst, streamlines the running of projects and boosts efficiency, to deliver faster, and discover more opportunities. Book a demo at?https://calendly.com/tony_leania ?or, as you're a newsletter subscriber, you can?try it for free ?[use code:?linkedin_news]

We're dedicated to helping analysts, project/program managers, and consultants like us succeed in this space. Reach out if you have questions.

You can also learn more from my book,?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 the Chief Evangelist at UiPath, and a very well-known advocate of RPA with over 20 years of experience in outsourcing.

?

BECOME AN AUTOMATION SUPERHERO

#1 strategy for accelerating your career in the world of Process Automation and Intelligent Automation to become an expert your team and business can turn to for guidance