Automating a 'hated task' at trainmaker Alstom

Bots against boredom

Mechanics were frustrated at having to manually copy and paste information from emails into the ERP to raise service orders before they could wield their spanners. A perfect job for a bot, then.

Bots. They work 24 hours a day, seven days a week, 52 weeks a year. They are never ill, hungover or in a bad mood. Give them a job and they'll do it over and over again. Which is a double-edged sword, said Duncan Boyer, operational systems integration business partner at train manufacturer and maintainer Alstom Group. You need to be really careful about the jobs you give them.

"If you don't know the process you make mistakes, and the bot will keep making mistakes. But if you do know the process, the bot will keep winning for you."

The ideal task for a bot is one that's repetitive, standardised, time-consuming and tedious for the people that have to do it. To avoid side effects, it's also discrete and self-contained with minimal overlap with other systems.

Boyer and his colleagues identified one such task in the Nottingham tram depot. Mechanics, fielding repair requests from the tram operating company, had to copy and paste the details of the ticket into the SAP ERP system and from there generate a service notification and a service order. Only after that could they get on with the repair job. They saw this as pointless admin, not part of their job. It made already tight schedules even tighter, requiring up to an hour of their day, and they complained repeatedly about it.

"It was such a hated task, they didn't want to do it," Boyer told the audience at a recent UK/I SAP User Group event. "And the repetitive nature makes it a perfect candidate for an RPA bot."

Know the process

For success with RPA, understanding the process that you want to automate is crucial. The bot will only perform as instructed, so it's essential to have a deep understanding of the task at hand. "If you're not doing this every day, seek out those people who are because they will know what goes wrong, they will know what goes right," Boyer advised.

As a first step, he spent a week watching operatives and recording their screens as they laboriously copied and pasted information from emails into SAP and generated service orders. He spent and a further week transferring these learnings into flow diagrams. These were then passed to the development team who, over the next month, created the prototype bot using Automation Anywhere software.

Expect initial resistance

User acceptance is the hardest parts of integrating a bot into the workflow, Boyer said. As much as they'd hated the task, having it performed automatically by a bot spooked some of the mechanics.

"Some people don't like change, especially when it's an AI tool coming to take away part of your job," he explained.

Resistance will be all the stronger if "human - bot collisions" are not dealt with promptly. One example: as part of the process, the bot flagged repair emails as "unread". Recognising some of these emails, a human operative, who had already read them, changed the flag to "read", meaning the bot failed to consider them.

Fortunately, the issue was spotted and quickly fixed, but it underlines the importance of continuous monitoring and developer engagement post launch. Not every potential collision will have been foreseen. Nevertheless, it's important to catch as many as possible before go-live, testing the bot with faulty data in order to check the failure paths.

Another problem arose because of different screen configurations. For some users, the buttons were not where the bot expected them to be. Again, this was an easy fix, but not something that was spotted in development.

Above all, it's essential to resist pressure from developers and stakeholders to launch before it's ready, Boyer cautioned. "Don't be pushed into signing off something which doesn't work."

Other things to look out for are licensing arrangements - the Alstom bot has its own Outlook account - and regulatory requirements. For example, automating financial processes may fall foul of the rules.

Verify then trust

Boyer set up a system in PowerBI to monitor for unexpected behaviour and unforeseen collisions, and to make sure human intervention was possible when the bot couldn't process a request, for example when vital information was missing or misconfigured. Designers also need to ensure it can be easily adapted to meet changes in the systems it works with, such as Outlook and SAP.

That done, though, it's important to trust the bot to get on with its job and to deliver the benefits for which it was designed.

The main win, according to Boyer, has been increased job satisfaction. Initial objections overcome, the mechanics no longer have to spend time on a task that interfered with their core activities.

Alstom has not performed a full financial analysis of the bot project, which cost around £10,000 and took 6 months to implement, but at a saving of 30-60 minutes per mechanic per day, payback should be reasonably swift.

The 24/7/365 nature of the bot means that if a request comes in at night or on a public holiday, the service order will be generated meaning a mechanic can get straight to the problem. And because it takes away some of the vagaries of human input, the quality of the records has improved.

Boyer has been visiting other train and tram depots to record their business processes and assess their suitability for bot integration.

"Now that we've deployed this at Nottingham other train depots have seen it, and they're saying, ‘I want one of those too'," he said. "And that's a nice thing."