When you think of automation on the shop floor you think robotics, IoT and AR/VR. On the other hand, when you talk to executives in white collar industries about automation, the conversation usually drifts to bots. Most SIs now have a Robotic Process Automation (RPA) practice area and most of their references tend to be in banking and other financial services verticals.
So, I was pleased to sit down with Dorothee Baas and have her describe their RPA journey at the recent Plex user conference. She leads Business Process Integration at a manufacturing company, Stant.
Stant, headquartered in Connersville, IN, is focused on thermal and vapor management products for automotive OEMs (many of the leading brands around the world), industrial OEMs (like Caterpillar) and auto aftermarket (channels like Walmart).
Stant used to be the largest producer of precision piano tuning pins and somehow then ended up as an automotive supplier. We just celebrated 120 years last year, so there was a big celebration and that felt good to be part of that history.
In North America, we have plants in Connersville,IN; Pine Bluff, AR and San Miguel de Allende, Mexico. We also have plants in the Czech Republic, China and at a joint venture in Korea. Rochester Hills, MI which is where I’m based is an administrative office.
Our RPA efforts so far have focused on two main areas : a) Accounts Payable invoice matching (Finance) , b) Accounts Receivable (Customer Service) sending invoices to customers. The AP bot is supposed to do all the upfront work and put invoices into buckets that need human attention (this has a price issue, that has a quantity issue etc.) and others which are ok to process. On the customer service side, we developed three small bots that simply email the accounts receivable invoices from the system out to the customer each night or print them at the local printer if the customer wants them in paper format. (The AP payback has been much higher and that is described below.)
We had a small AP employee group. They had to learn two ERP processes because in addition to Plex, we have QAD in one of our locations. They were struggling to keep up with the invoice matching. Plex has an approval workflow, but it was not being followed, and they were holding on to invoices. We had a huge backlog of invoices which were not being processed for weeks. So we started adding temporary workers because, what do you do when you need to catch up? You throw more people at the problem. Well, we also ended with high turnover in that temporary workforce.
At this point, our CFO decided to outsource the process, but my boss, the CIO suggested we also look at RPA. I remember it well. He came into my office and said, “Hey, what if I had a magic button that just takes all these invoices that come in through email and magically matches them and no one has to look at those?” I looked at him, and I threw him out of my office. True story. I said, “Okay. I like you, Andy, but I don’t have time for you right now because I’m trying to solve a problem here with finance and you need to just leave. I can’t listen to your rainbow, unicorn stuff.” Well he persisted. Couple of days later, Thirdware (a partner of the RPA vendor, Automation Anywhere and whose video describing the Stant project is available here ) was in our building showing us what other customers have done, explaining RPA. I was not convinced in the beginning because I didn’t understand it, honestly. I saw it as screen scraping. If everything is not perfect, then nothing will ever work.
They convinced me pretty quickly. Then we had a three-day workshop where we scoped out what we wanted to do. What are all the different main processes that we would need to program? Then, within ten weeks from me throwing my boss out of my office, we went live with a select group of suppliers. I think that we could have done it faster but, at the same time, remember; we had to also outsource. I was trying to train humans in doing this somewhere else in the country. There was just a lot of stuff going on, so I think we could have even done this faster than ten weeks.
Using the Pareto 80/20 principle, we focused on about 50 suppliers that sent us the most invoices, volume wise. In the end, Stant ended up with 3 bots – Bot 1: AP invoice matching bot, Bot 2: AP invoice Retry Bot (if Bot 1 could not find invoices to match on the first try) and Bot 3: AP manual invoice entry bot. The bots know to focus only on these suppliers. It has a preparation stage where it looks at emails from these suppliers. It scans for the keyword invoice, grabs the PDF attachments and sends them to an OCR reader (a tool called Doc Parser) which turns them into Excel sheets. The bot validates the entries in the spreadsheets – did the OCR grab the wrong source so the price field has a word in it? A price needs to be a number, ideally with decimals. Do all my lines add up to the total? It puts exceptions into buckets which need human review. The bot also renames the PDFs to our naming convention – location, supplier number, invoice number etc.
At this point, there are two piles of “These are the invoices I’m not going to even attempt to match, and here are the invoices that I will now attempt to match.” Taking that pile, it’s going to log into both of our ERP systems and try to find the matching receipt. It first checks if maybe someone already matched this invoice. Sometimes a supplier will send the invoice to the AP mailbox but, also, to a very specific accounts payable clerk. Maybe the clerk already did the matching and now the bot is also trying to repeat it.
Then it looks to make sure that it can find a unique record that matches that based on who the supplier is, the shipper number, combination, and it checks the currency. If it doesn’t error out there, now it’s going to actually go into the invoice in Plex or in XA, and it’s going to do all the work. The first thing it will do is overwrite fields. This is actually data entering. It will overwrite the invoice number because now we have an invoice number, or it’ll overwrite the date. Then there’s a field down here. It’s called printed invoice total. This is where the bot enters what the Supplier’s PDF totals, so the bot can see if there is a difference to the Plex calculated Total.
If it doesn’t match, the bot will go down into the line item level and compare each part number, quantity, and price between what Plex thinks and what the Excel sheet transcribed data from the supplier says. It will then know, “Ah! I have an issue with price,” or, “I have an issue with quantity,” or, in some cases, it doesn’t know.
The humans still need to do the legwork of trying to figure out if there is something incorrect. The bot would not know that, but it can do the prep work to tell you there is something incorrect. And I now have great tools to understand root cause of matching discrepancies by supplier.
The next graph shows the results across the 53 suppliers:
To adjust for timing differences or system unavailability, we programmed a second bot and that’s our retry bot where bot one just hands over, if it can’t find something, to bot two and says, “Hey, bot two, just try this again tomorrow. You have all the information. I already have everything transcribed. You just need to keep logging in every day and try to find the receipt. Just keep trying.”
The bot also sends email notifications every time it starts the process and every time it finishes the process. It sends it out to whoever I put in the distribution list, which is mostly the accounts payable group because I want them to own this. I want them to know your team member, the bot, just finished something and now you need to look at all these log files.
Two critical decisions
We decided early on the bot would be owned by the AP group, not IT. We wanted to make sure that they can help themselves after this is done and they can monitor the bot and have the bot be a part of their team. We wanted them to see the bot as an equal member within the business function that they could work with. That was the hard sell.
What we’re doing different is that we’re not only doing the analysis with the bot, but we’re also having the bot process it inside the system, which saves a lot of time. That’s the thing that I think we do in addition to maybe some other companies. A lot of customers I’ve talked to that use RPA use it to pull reporting, but none of them that I spoke with, even the banks or the big guys, use it for actually overwriting or data input, which I found interesting and I think it’s the whole security or SOX compliance that they’re worried about (as a private company, Stant does not need to worry about SOX). We use it for data entry and we use it to actually overwrite information. Our bots have security roles just like our humans. They have a user ID just like a human. Everything they do is captured. So, in the system, in my invoice, if they made a change, then in my change log it says the bot made this change on this date, just like it would log a human doing it.
Results and next steps
As the slide above shows, the invoice backlog went down to just 4 days, the initial savings are $ 50K a year, which should increase as more suppliers are covered and the bots do more tasks. The next graph shows potential other bot applications.
Credit: Stant for all images.
(Cross-posted @ Deal Architect)