Automated processes, such as voice-based tech, can provide big cost savings -- but you have to follow design and implementation best practices to reap the benefits. Here are some pointers for getting it right.
Process automation is great if it saves time and reduces error. But if it doesn't "fit right" in a business process, it can be tough to get around. Just ask anyone who has ever wrestled with a voice attendant! Fortunately, certain best practices allow you to get the most out of process automation. Here are 10 of them.
1: Keep it simple
The more complex a process automation project becomes, the more points of failure begin to appear and the harder it is to debug. Automation works best when there are simple data handoffs and you don't try to do too much.
2: If it's voice automation, be monosyllabic!
Warehouses that are moving to voice-based technology say that single-word voice commands like "Next" or "Stop" work best in automation. It's easier for voice-based automation to handle different accents and to accurately decipher words when fewer words are used. It can then translate them into a digital format that can be passed into systems for further automation and tracking.
3: Identify the best business cases for automation
An executive who signs off on an automation technology purchase order expects a tangible return on investment to the business, so sharpen up the business case for the automation and what it is going to deliver before you fund it.
4: Think about your ergonomics and your manual intervention points
It is all too easy to get caught up in the beauty of automating something... and to forget about the fact that humans still depend on (and must interact) with this automation. Part of your process design should include the end-to-end exchange between human beings and the automation. What human touch points (if any) will the automation include? Will there be times when a manual override is necessitated? What if humans decide they want to intervene? Are there sufficient "interrupt" points in the automation to facilitate this?
5: Don't forget about failover
People like to take over and make their own decisions when the automation recommends a system shutdown and failover. From a technology standpoint, there is an abundance of automation and analytics that can effect failovers -- but major system failovers also require lengthy explanations to customers, investors, and the board. This is why the managers responsible for them like to be the ones to push the button.
6: Define your system alert conditions
If the automation is going to issue alerts, carefully determine the conditions that will trigger them. You should also identify who is to receive these alerts and the action they can take to intercede in a specific situation.
7: Document and/or revise system and operating procedures
Moving to automation means that business and system workflows will inevitably change. As part of the work, there should be a project task for updating operating and system procedures so both IT and business staff stay current with the automation. As a last step, these revised operating and system procedures should be tested by staff to ensure that they work in practice before any automation goes into production.
8: Use standard application programming interfaces (APIs)
If you're planning to integrate automation into an existing system or systems, use standard APIs to effect the data passes between systems whenever possible. This eliminates the need for custom code and interface design and maintenance.
9: Test systems before cutover
System testing should be performed to a written script that takes the automation through all the possible scenarios it could be involved in.
10: Test operating and business processes
It's surprising how often IT automation plans fail to include actual trials of the new automation within the fabric of the business itself. If your business is finance, for example, does the automation work as perfectly in loan origination as it does in credit card approvals? Every business scenario that employs the automation should be thoroughly tested, debugged, and signed off on by the end user before it goes into production. If the automation is a customer touch point (like a voice attendant), these operational tests should include a test group of outside customers so you can verify that the new customer experience is a positive one.
- 10 projects IT should stop putting off
- 10 ways IT can hit the ground running in 2015
- CIOs: Don't fall prey to these10 common mistakes
- 10 reasons why enterprises should use a startup
- 10 bad technology decisions that can come back to haunt you
How do you approach process automation in your organization? Share your advice with fellow TechRepublic members.