In the previous article, we set out a sequence of steps required for updating the procurement business process with state-of-the-art technology. Now, let’s look at the typical mistakes made by automation initiators.
1. Using IT-solutions for process bureaucratization. In a number of projects still at the goal-setting stage, catchphrases such as “not allow”, “forbid”, “deny”, “prevent”, etc. tend to be used, aimed at eliminating fraud (various types of machinations) using IT tools. In our experience, this approach is inefficient because it complicates the work process of conscientious employees. As a result, there is significant resistance to implementing an IT tool, and attempts to do so are futile: no one uses the solution, or it’s mainly used to reflect actual transactions (so-called “retroactive requests”). It turns out that the money spent on automation has been thrown down the drain.
Fear of fraud is a poor adviser when it comes to automation: those looking to steal will find a way to do it. This issue should be addressed through other means; meanwhile, for implementing process solutions it’s worth thinking about user-friendliness and functionality first.
2. Involving back-to-back or third-party services. Companies involve employees in automation processes who are not directly related to procurement, and who are altogether not happy with having to sort out procurement systems. For example, at the stage of compiling a list of potential suppliers for sourcing, a security team is included in the approval process. Such types of installation complicate the process and prevent the establishment of competitive environment among the pool of suppliers. Of course, if necessary, the related services can and should be invited in an observer capacity, but they should do so without blocking automated processes.
The reverse can occur: non-core departments seek to supplement the system with functionality required solely by them and, as a result, a system becomes unnecessarily cumbersome.
3. Incorrect roles and responsibilities matrix. The role of initiator and purchaser is given to one and the same person. A marketing specialist will not be able to perform a process in the system that is not core to him with a high degree of proficiency. The task of this specialist is to ensure that POS-materials are of good quality and on-brand, rather than thinking how to organise the sourcing and supplying process.
However, owing to job losses in a time of crisis, what might seem like an additional workload for the initiator is a better solution than working with no system at all. As such, there is at least a transparency and understanding of the criteria by which the POSM contractors have been chosen, and how the cost of their offerings have changed over the course of bidding.
4. Reducing procurement roles in the automation process. For efficient automation, a company must have a strong procurement function. Without it, any attempt to automate the procurement business process will seem unsuccessful: no other function is capable of ― and nor are they interested in ― its competent execution. Who will control the master data for suppliers and materials? Who can develop categorization? Who will set up templates for sourcing events and contracts? Procurement is a cross-functional process, but there should be one leader and “owner”.
5. Developing a tool for certain categories of purchases. A company is trying to find an optimal solution for certain purchase categories (e.g. IT), while not including all other purchases in the process. When the time comes to implement a proven tool in the other categories, it turns out that it needs serious revision. Thus, the rule of “single window for all purchasing activities” is violated.
6. Custom development. Some companies like custom development because it looks cheaper in the short term and allows building the system that supports existing business processes. Yet the automation initiators don’t take into account the fact that any “self-made” tool will be out-of-date in 2-3 years, and will cost you a lot of investment to keep it updated. Moreover, the employees who have initiated the automation may leave the company and new employees might not be happy with the old process. But it will be costly to change the system to suit their needs. Whereas the cloud solutions may be built in optimal business processes that do not depend on people.
7. Prioritizing a tool by price. Let’s take the Russian ETPs (electronic trading platforms), for example: they are much cheaper than their foreign analogues, and seem to be more advantageous at first sight. Meanwhile, global procurement solutions (Scanmarket, SAP Ariba, and others) don’t charge a fee to vendors for participation in bidding. Therefore, the cheapness of domestic ETPs has a downside: suppliers don’t want to pay for participating in bids which decreases the competition. Those who logon, are incorporating the cost of using the platform into the price of their offering. As a result, savings on tools turn into an inflated price for the goods and services being purchased. A point to keep in mind is that a quality procurement automation system pays for itself many times over, owing to its more advanced functionality. And conversely, having saved on a tool initially, in the long run you can fail to reap any benefits from it.
8. Trying to implement everything at once. In dealing with one company, we came up against the fact that the procurement service demanded a single solution for automation of sourcing and the P2P-process. Such an approach dramatically reduced the number of vendors competing to deliver these solutions. There are not so many products in the market that are equally effective in both business processes, hence why they appear so much more expensive.
Say you also want the tool to be integrated with ERP. The ERP-system is not adapted for the procurement process: vendors are often duplicated, there’s no correct categorization, and material and vendor master data are entered haphazardly. Cleansing of master data can prove a arduous task. It’s much safer operating in an independent system where the necessary functions are clearly specified, the data is controlled by purchasers, and the probability of system failures during synchronization is much lower.
However, a large number of specialised systems with their own master data is also not necessarily a fool-proof way out of the situation. Therefore, in the long run a convenient solution could be the IT product lines from the same manufacturer, in which a system refers to common unique master data or the creation of a interface which enables data exchange between the procurement system and the ERP. But this is not the first thing to do – the interface can be built after you make sure that the system works as planned and the interface will enhance its usage.
9. Preparing specs not just by yourself, but with the help of software vendors. Naturally, a vendor will formulate specifications in such a way as to ensure that, when choosing a partner, you end up picking them. Here, there is a clear conflict of interests. In addition, it should be remembered that vendors incorporate risks into their quotations, whereby competition is sharply reduced, while the proposal cost is inflated. To avoid such a scenario, we strongly recommend:
- Laying out system requirements in your own words;
- Not indicating software technical data in the spec, but instead, business objectives that it must meet, performance requirements and safety regulations. What value do you want to achieve by implementing the system? Vendors/consultants themselves must demonstrate how exactly they will be able to deliver those goals;
- Not narrowing down the range of applicants prematurely. Both the suppliers of niche cloud-based solutions and developers of stand-alone products, as well as with the leading companies providing integrated solutions should be entered into the vendor pool. By comparison and testing it may be revealed that an option, to which you were initially leaning, is less effective and user friendly than the competitive offers.
10. Increasing functionality and the number of participants. Even the most technologically-advanced companies are not immune from making this mistake. When automating procurements, company representatives may say: “I want to be able to upload a comprehensive procurement plan into the system“, or “I would like the tender panel to prepare and approve tenders in our system”. Acquiring powerful software, they set up a lot of intricate processes for it, but overlooked the fact that, that the more complicated functionality of a system, the higher the probability that it will not be that popular to use. And the point here is:
- Procurement departments have a vast workload, and if you ask employees to enter redundant data into the system or perform too many activities in it, they will sabotage it, regardless of its effectiveness;
- The majority of indirect purchases are done by the initiators themselves, and transparency and competition for them are not as important as for the purchasers. Initiators will vehemently oppose the implementation of a new system, and a sophisticated functionality would be an additional argument in their favour. A series of complaints will follow from the stakeholders relayed through IT Directors, HR and marketing managers. As a result, senior management will meet them and resolve to make purchases without using the system. One such exception would be sufficient in ensuring that over time, use of a tool fizzles out;
- Tender panels consist of high-ranking highly-specialised professionals. Forcing them to get acquainted with a system used by purchasers will be extremely difficult. Therefore, it’s better if a strategic sourcing solution is used by those who need it for decision making, analytics and monitoring. Meanwhile, reports to the tender panel can be prepared based on the data from the system offline. Another solution is providing tender panel participants with the option to observe the relevant sourcing event in the “spectator mode” whereas the strategic sourcing specialist will run the event online.
Of course, when it comes to e-procurement systems (electronic catalogues, purchase orders, purchase orders, invoices), it is imperative that the system can be used by all employees, regardless of job position, since the target here is coverage, compliance, and a single point of contact for all orders. And if the system functionality is simple and intuitive, no one should have any problems.
11. Using two or three e-platforms all at once. This happens when the organization lacks a single leader for procurement. Each business unit is lobbying its solution, users cannot decide which platform to use and when they need to use it, and the company has to bear additional costs (let’s face it – losses). Furthermore, using multiple ETPs makes cost analysis more difficult, since the purchase data is being gathered from different external sources, and each solution uses unique standards, for example, its own type of categorization and master data.
12. The tool has been acquired, but is not used properly. This is the most common mistake, so let’s have a closer look at its causes:
Lack of control after implementation. The costs of expensive software are recouped only if the tool is widely used for its intended purpose; otherwise, employees will happily forget about it. To avoid this mistake, you should develop clear and binding rules for all participants in the process. Make an effort and specify the procedures that necessitate using the e-platform for all bids over the threshold amount. For example, “all purchases over 500 thousand roubles are to be fulfilled via the e-auction process”, “purchasing furniture and stationery must be done strictly through e-catalogue”, etc. While you are establishing the procedures, impose sanctions for non-compliance (or improper execution). Assign system users specific targets to cover company automation tool costs:
- the required share of spend sourced through e-auctions/eRFx;
- share of spend (or orders) with no upfront creation of a purchase order;
- share of spend entered through e-catalogues
Localization problems. Failure to use implemented tools is typical for the Russian divisions of international companies. Sometimes a global tool is too complicated or not adapted for the Russian market at all. For example, the interface of the tool is not translated to Russian language and it’s difficult for Russian suppliers to operate in such a system. Then the procurement department persuade the company’s management that it’s better to do things the old way – with Excel. In other cases, the tool is purchased by a global office, transferred to the regional offices, but local management is not aware of the need for it and sabotage its implementation, while the leaders of the global procurement function proceed to turn a blind eye. That, however, is not a surprise: the Russian branch of the business occupies only a small share of the total revenues of international companies, so few of them seek to implement global business process standards in Russia.
Lack of training and promotion. A case study: a large international manufacturing company acquired a license for an e-sourcing tool for three years and at implementation trained several key users in each business unit (country). Over the course of time these employees left and were replaced by new staff, but no one took charge of training them to use the system. It’s no surprise that, with such negligence and acquiescence on the management’s part, the employees weren’t motivated to use the tool.
We hope, with the help of this checklist you’ll be able to avoid typical mistakes made in the automation cycle. If you have points you’d like to add our list or want to tell us about your own company’s experience, we’d love to hear from you!