Process optimization, and the closely related idea of continuous improvement, is a crucial underpinning of any intelligent automation project, a point that Maarten Schot drove home with authority in my discussion with him for a recent episode of my Unstructured Unlocked podcast.
Schot is a continuous improvement and automation expert with deep experience in the chemical manufacturing field. In addition to discussing the role of process improvement in automation efforts, we also delved into topics around automation centers of excellence (COEs), including where in the organization the COE should sit.
Listen to the full podcast here: Unstructured Unlocked episode 4 with Maarten Schot
Effective process automation requires optimization
When Schot was responsible for robotics at a large chemical and paint company, he was charged with automating numerous back office processes. At first, automation was seen as something of a silver bullet, but the company came to realize it had to be part of a larger continuous improvement program.
That involved examining each process to determine what could be taken out of it, or to “eliminate stuff,” as he put it. The goal was to standardize each process, simplify it – and then automate.
“That’s instead of just saying, ‘Hey, let’s throw some automation at a process that’s not so good.’ And then we sit there and wait for the savings to roll in,” Schot said. “They don’t.”
No, they don’t – because bad processes are bad whether robots are doing them or people. Yet, as Schot pointed out, sometimes optimizing processes ahead of applying automation is not a popular undertaking.
“Vendors will say, ‘We can just automate this in 12 weeks for sure,’ But you have to do some work [ahead of time],” he said.
One pointed example he gave had to do with automating invoice processing for his multinational firm. When he tried to determine what the existing process for invoice posting looked like, he found “we had like 70 versions.”
Related content: Unstructured Unlocked podcast episode #1: more reasons AI projects fail and how to ensure yours don’t
Automation requires process details
So job one is to decide the process that everyone will follow. And that shouldn’t be dictated if you ultimately want business buy-in, so it requires working with the business to come to an agreement. And for automation to be effective, the process must be laid out in extreme detail, with a purpose behind each step.
“Why do you drink coffee with your right hand? That’s kind of the level you need to go to,” Schot said.
To illustrate why that level of detail is required, Schot recounted paint manufacturing recipes that said things like, “mix to a yogurt-like consistency.” Relevant employees in one plant understood what that meant but when the recipe was sent to another plant, it was a different story.
“There’s loads of types of yogurt, right? Thick, thin, with flakes in it or whatever,” he said. “So when that process got transferred to a different site, the consistency of the paint wasn’t good anymore.”
It’s a great point. Even in large manufacturing processes, there’s so much knowledge in people’s heads that it’s important to accurately capture it before codifying it in a process that you then want to automate.
Doing that requires getting those front-line employees involved in the process automation project. That can be a positive because it may well get them using skills they do not otherwise exercise.
“I’m strong believer that people come to the shop floor or workspace and they use probably 40% of their skills instead of 80% or 90%,” Schot said. “They’re like the financial chairman of their local football or soccer or rugby club.”
Related content: AECOM intelligent automation exec makes the case for agile development
Determining where the automation COE belongs
Another challenge Schot discussed was deciding where the COE belongs in the corporate structure.
In his position in one chemical company, the COE was born when an automation project was completed. “The project stopped and we start being a real department,” he said. “All the knowledgeable people went away. So we basically had to start again.”
Political battles ensued over where the automation COE belonged, with IT saying it should be in its purview while the COE leaders saw it the other way around. He spent time convincing IT leaders that his group wasn’t there to mess with their applications while trying to appease business groups that wanted automation delivered yesterday.
In a culture where much depends on trust, his job required a lot of relationship development and education on what the automation COE was all about. The technology part – automating a couple of SAP variants – was not the issue. “It was getting people on board because they didn’t really know what we were trying to do,” he said.
In the end, the COE wound up being part of the shared services unit within the finance group, which is where IT sat. That sometimes made it difficult for the COE to show the value of the investments it was making.
The biggest beneficiary of its invoice process automation project, for example, was the procurement group – because automation made suppliers happier. So, while Schot’s automation COE was creating and incurring the cost, another unit was realizing the benefit.
That’s not an uncommon scenario, given COEs tend to work with various business units. It takes careful tracking and ROI analysis to show any costs incurred by the COE are justified, and/or an effective chargeback mechanism.
Those are some of the highlights from my conversation with Schot, but there’s plenty more in the full Unstructured Unlocked podcast. You can read a transcript here or listen to the episode (no. 4) on your favorite platform, including:
