Robotic Process Automation is fast becoming an accessible, affordable choice for many organisations.

But how can it support procurement, and where is it headed? Steps 4 Consulting founder Richard Bell explains the process and potential of RPA.

 

Richard, what is Robotic Process Automation? 

Robotic Process Automation (RPA) is the use of a computerised tool that carries out repetitive, typically clerical tasks involving a transfer of information between applications. What it is not, is a physical robot that you might see, for example, in a car plant. In terms of a mental picture, it simply takes over the desk top activities which are inside the computer.

For example, consider an accounts payable routine: a vendor emails a PDF to an accounts payable department. The information would then be read by the accounts payable professional and moved from the PDF into an ERP, such as Oracle or SAP, where the invoice will be checked. In the case of RPA, the robot will be trained to open the email, open the pdf, retrieve the relevant information, login to the ERP, and input the data. It goes through the same process that a human would.

Another important point to make is that it operates at a user interface level; in the past people may have experienced automation programmes that need to be integrated by the IT department. RPA simply takes the applications that we use every day, whether that’s Outlook or Excel or Word, and automates with the user interface. Because it operates at a user level, the programming skills needed to set up an RPA are less complex than the skills needed for traditional application interfaces.


Why should companies consider using RPA within their procurement function?

It’s common for procurement teams to find they are spending too little time on growth-enhancing activities, due to a lot of time being spent on processing tasks (transferring information between systems). By taking over these processing tasks, RPA enables procurement professionals to improve their focus and efficiency, spending more time on cognitive activities which, in today’s world, remain the domain of humans.

One such cognitive activity is working with stakeholders to understand their business needs. It is important to meet face to face: to read their body language and understand their thought processes. Similarly, when conducting market research to find innovative products, humans can think laterally to discover a completely different, innovative route to attain business objectives.

RPA can also reduce supply chain risk. Robots work faster than humans, and at a lower cost. A human might carry out a contract renewal process once a year, but a robot could carry it out once a week, once a month; however frequently you require.

Almost anything that a human can do on a PC, the robot can take over without the need for IT department support.

If a vendor must sign up for a 12-month contract, they might be supplying a product that has exposure to fluctuations that cannot be forecast, for example commodity or currency fluctuations. This means that when they calculate prices, vendors need to build a risk premium into the quote. By setting up a robot to carry out the contract renewal more frequently, you’ll not only save time, but the risk premium may be greatly reduced.

Finally, RPA can integrate with third party services for which no traditional application interface exists. Computerised activities such as container optimisation, or the scheduling of transport, can be integrated into the robotic process without the IT departments of each party needing to collaborate. As an example, a bank’s letter of credit department may not provide an electronic interface which you as a buying organisation can take advantage of. But with RPA, so long as the bank has a webpage or PDF application form, the robot can take over. The breadth of activities that would normally be considered in scope for an automation programme is greatly expanded. Almost anything that a human can do on a PC, the robot can take over without the need for IT department support.


What does the implementation process look like, and how would an organisation decide which roles to introduce RPA to?

The beauty of RPA is the ability to implement change gradually. Looking at a traditional application integration, it’s usually highly specialised and often carried out as part of a major project. Because RPA can be introduced to automate small, individual tasks, the recommendation is to begin implementing on a small scale, and become familiar with the process before developing it any further.

Procurement professionals might start out with something as simple as having vendor email attachments downloaded and filed into a specific folder. This might take an hour or two to set up and may only save you ten minutes a day, but it’s a starting point, allowing you to feel your way into RPA.

From there you could move on to the retrieval of sale and inventory data from the ERP, and the analysis of that data to prepare a demand forecast. This would take a few days to set up, but once it’s in place for one product it can easily be adapted for other commodities and services.

In a few simple steps, you’ve automated the entire vendor selection cycle.

As a next step, you could integrate that demand forecast with an online vendor qualification and reverse auction tool. This means you are now automating negotiations. As a further step, you might move to automate setup and issue of the purchase order. In a few simple steps, you’ve automated the entire vendor selection cycle.

When considering how a procurement team would implement an RPA strategy, I would liken it to the Six Sigma methodology. In Six Sigma, for tasks requiring complex statistical analysis, you have ‘black belts’ who are experts. After the black belts, you have ‘green belts’, which in their everyday jobs are adopting Six Sigma, but can refer to the black belts for more technical support. I believe the best way to implement RPA is to take the same approach. You would have procurement professionals who in their everyday work are trained to automate tasks, with an expert to support the more complex programming elements.

Using this approach, you don’t need to rely on your IT department: the language used in RPA is less complex than earlier forms of programming, making it more accessible. In my experience, IT usually have a long list of requests that they are working through, so you may not see procurement activity automated for a long time. Obviously if you’re taking the small steps approach, you won’t want to wait eight months or so to automate the filing of email attachments. The ease of use combined with not having to spend time ensuring that IT professionals understand the context of the task, makes it more efficient to have the procurement professionals directly working with the RPA development tools.


With the introduction of new technology, it’s not uncommon for an organisation to face challenges and resistance. How can these issues be addressed with the introduction of RPA?

It’s important to recognise that by embedding the implementation of RPA into activities of the procurement department, professionals will be driving the change rather than having change imposed from outside.

RPA doesn’t necessarily represent a threat to procurement professionals. A professional may be working 10 or 12 hours a day because they have too great a workload; RPA can provide the support that will enable a shorter working day. Senior managers are likely to be more receptive to bringing in a robot that can be used for multiple tasks, than to recruit new staff with all the obligations entailed.

Professionals leading the change need to understand that jobs will become more engaging.

The developed world is facing an increased ageing population, so if team members are coming up for retirement, it may be advisable to replace some of the activities of those people with RPA. In the 12 months preceding retirement, the team member’s knowledge can be transferred to a robot, with the assistance of an RPA green belt procurement professional. This embeds the experience and knowledge that person has gained over their career into both the robot and the green belt.

If there was still a necessity for humans to take over cognitive tasks from the retiring colleague, activities can be reallocated. A company may spread the workload of the person who’s retiring by further automating some of the green belt’s processing tasks. This means you will have full use of a robot, and the green belt can oversee the robot whilst focusing on cognitive work.

When building a larger RPA programme, human resource professionals need to be closely involved. Communication is critical from the start, and the professionals leading the change need to understand that jobs will become more engaging; for most people it’s more interesting to interact with people than move information between systems. The required skills will almost certainly change, with more emphasis on the cognitive skills and less on conducting the process.

Business leaders will need to understand how this change enables them to have greater focus on core activities and grow the business.


As debate around 'the future of work' continues, how do you see RPA developing, and what place will it have within procurement in the future?

In terms of procurement, I see it moving from RPA covering the procurement cycle, into also covering the bidding from the vendor’s side. In this scenario, you would have robots on both sides as the buyer and the seller, conducting the negotiation. From the human seller’s point of view, they will need to put their cognitive input into the process early to influence the scope of services and specification required to. By the time it reaches final negotiations, vendors will have little chance to get their point across to customers because the robots will be interacting. It has always been best practice for procurement professionals to determine their strategy well before negotiations take place; RPA will enforce this best practice!

The use of big data will be essential in understanding underlying drivers of trends in pricing, and volumes of procured products and services. Whole life cost is often driven by complex systems, and to date we have struggled to truly understand it. Major price movements may be determined by factors such as technological change, macro economics and geopolitics. The more data we have, the more we can predict fluctuations in pricing, meaning we’ll be able to make more informed procurement decisions. In short, access to big data and sophisticated analysis tools will enable us to identify correlations between factors which drive whole life cost. With this knowledge, business forecasting and planning will become significantly more reliable than at present.

We are also seeing the implementation of the internet of things, with many sensors embedded in equipment. Consider sensors: when you’re driving, your main sensors are your eyes. This is limiting if you are turning left; you need to look out for hazards on the right, but you only have one set of sensors. The beauty of a self-driving car is you can put sensors wherever you need them to be.

Ultimately, whichever processes are carried out by robots, humans will always be needed to socialise the solutions.

Similarly, the proliferation of sensors in business equipment and materials will significantly improve decision making, which will benefit operational capabilities and levels of customer service. Vendor contracting will be quite different. Until now we have had a basic set of vendor performance measures: do they deliver on time, do major components fail within the warranty period etc. The embedding of sensors in many areas will mean that contracting will be based on much more detailed data, enabling minor failures to be remedied long before a major component fails. Moving forward, RPA will be able to manage vendor contract management, which I would currently consider to be a cognitive activity.

The next development will be around new products and specifications. Although there is some ability to automate the communication of specifications into the procurement cycle, the actual development of new specifications is still an area that humans lead on. At a very basic level you can automate it from web based information, but I think in the future we’ll see AI enabling vendor systems to talk to buyer systems, to develop specifications.

AI may produce completely different solutions which a human would never have thought about, which could be a great benefit, or a hindrance, depending on the initial set-up. One far-fetched robot doomsday scenario is that if a robot is programmed to produce, for example, the best possible paperclip, the robot will put a human to sleep to extract metal fillings to make the paperclips. As humans, we have evolved to solve problems in a certain way. A robot doesn’t have this same conditioning, so the setup and feed of data into a robot will be critical to determine the success, or failure, of AI driven solutions. When considering consumer goods, I think that ultimately, whichever processes are carried out by robots, humans will always be needed to socialise the solutions.

How much further can computing go? In the mid 60s Moore’s law was developed and predicted that computing power would double every one to two years. Until now that has proven to be the case.

To give you an idea of where we are and how much further computing can go, consider the rice and chessboard fable. Legend has it that the inventor of Chess took his new game to the king, but the king wanted to tell everyone that he himself invented the game. The inventor agreed, on one condition. He requested that the king put a grain of rice on the first square on day one, two grains on the second square on day two, four grains on the third square, and so on, doubling it every day. The king thought this was an excellent deal and agreed. But as it turned out, at 18.5 million trillion grains of rice, the King had been duped since he could not possibly deliver, and executed the inventor. In terms of computing power, it works in the same way. It is believed that we entered the second half of the Chess board in 2013… we live in interesting times!

 

Richard Bell is the former Procurement Director at Averda and founder of Steps 4 Consulting where he has developed a system which uses robotics to automate the procurement cycle.