User adoption in purchasing software – where is the problem?

The 100% user adoption is part of every ROI calculation, which is usually created before the decision to purchase a procurement solution. From this point of view, it is already in focus before the actual software decision, yet it often does not receive sufficient attention in the further process.

What is User Adoption?

User adoption is the process by which new users get used to a product or service and decide they want to continue using it. Users only accept a product if it helps them achieve a goal - whether it's making it easier to send RFQs to suppliers or ordering tools more quickly from a web store.

Sometimes attempts are made to influence user adoption by providing appropriate targets in a objective agreement as part of their salary. However, this is often not sustainable because users do not use the tool voluntarily.

Now, most of the time, not only is new software being introduced, but at the same time the process is being redesigned or at least modified, which means for the end user, not only do they have to get used to the software, but at the same time they have to get used to the new process.

Of course, purchasing managers and the colleagues responsible for new tools and processes know this. Sometimes, however, the conclusion is the wrong one. Namely, it is assumed that it is better to change the process as little as possible so that the user only must get used to the new software and not to a new process design. This often poses a problem in the software implementation process when the software cannot map one process or another exactly as it did in the past.

What is the best strategy for high user adoption?

There is no one magic formula, a high level of user adoption is rather the interaction of many factors. Let us list a few:

1. Clear definition of project goals: as soon as the introduction of software is decided, the goals of the software implementation should be clearly communicated. Statements such as "we will completely automate the processes" should be avoided as they often do not correspond to reality and create expectations among the end users that result in long and costly project implementations. Instead, realistic KPIs that are to be achieved should be placed in the foreground. Sometimes it is also advantageous to communicate right at the beginning that the project will be implemented using an agile methodology and that there will therefore only be a minimal variant (an MVP - Minimal Viable Product) at the beginning, but the end users will be involved in the optimization.
2. Project marketing is much more important than is often assumed. Project marketing also includes communication to other departments, suppliers and partners who will later be involved in the project. For project marketing, give-aways should also be produced that make the project appear omnipresent and thus increase the awareness of the users.
3. Involving end users in the decision-making process: if the users are involved in the decision-making process, this usually increases subsequent acceptance. However, it is important here that the end users do not evaluate technical features, but rather the look and feel of the software. In practice, it has been shown that it is best if the potential provider of the solution presents certain processes in the software or - even better - the end users can try out these processes themselves for a limited time. If they find their way around on their own and without support, we can rightly say that the software's usability is good.
4. Evaluation of the software usability: Solutions with good usability can be operated by users without online help or external assistance like amazon or facebook, which is especially important when it comes to processes where the end user does not operate the software every day (and can thus forget how the operation works). If the software vendor presents the solution, you should only evaluate what you actually see and not assume that the vendor "can do it anyway". After all, the question is not whether the vendor supports a particular process, but how easy that process support is for the end user. Most procurement solutions on the market already have BPM functions integrated (business process management solutions map workflows very generically) with which you can map almost any process, but the operation is often so complicated that later in practice the process is not used, which of course must be avoided. In addition, the creation and maintenance of these workflows should also be tested and evaluated, since not only the usability for the end user but also for the key users and project managers must be evaluated. If the customer cannot simply maintain functions himself but always needs an external partner, the costs in ongoing operation will increase significantly (which in turn has a significant impact on project KPIs and ROI).
5. Evaluation of interfaces: this point has 2 components, namely the interfaces to external systems (like ERP systems) and the internal interfaces (in the application itself). Interfaces to external systems should be automated and standardized to the extent that duplicate inputs are to be avoided. Interfaces via APIs (Application Programming Interface) are preferable, but if there are no API interfaces RPA (Robot Process Automation) can also be considered. The "internal" interfaces are often underestimated and therefore a hurdle in the project. Many vendors have expanded their product portfolio via acquisitions and these acquisitions are often insufficiently integrated, resulting in a different user interface or complex data synchronizations, which often has a very negative impact on usability for the end user and thus user adoption.
6. Dedicated internal project owners: here we come to the next point, namely the internal administrators. Larger companies have dedicated teams for Tools & Processes or even so-called Centers of Excellence (CoE) that deal with process improvements and tool implementations on an ongoing basis. If such a larger, experienced team does not exist, it must be avoided that the person responsible for the project is a new employee in the company who does not know the internal processes and the end users, as this can lead to difficult project situations. Since direct discussion between the tool provider and the end users is to be avoided, the project manager must map the company's own processes to the capabilities of the tool provider and not only accompany the internal change process, but also take responsibility for it. In order to be able to lead the discussion with the end users about the extent to which a process change makes sense or not, knowledge of the internal processes is absolutely essential.
7. Redesigning processes and considering the capabilities of the provider: every established tool provider on the market can map a certain process simply and leanly or in a complicated way. Projects where the tool provider offers to map all customer requirements are often not effective because these projects often take a very long time and exceed the project budgets. It is important here to have project managers on the side of the tool provider who, based on their experience, also say "no" to customer requirements and project managers on the customer side who also accept this "no".
8. Short project durations: the project duration is an often underestimated criterion for user acceptance. Projects that last longer than 6 months are often critical because the positive spirit is lost. Projects that last longer than 12 months are often not successful because no one believes in success anymore and you get lost in many endless discussions. It is important here to divide the project into several sub-steps and start with the team that is most likely to support the change process. This is more promising than the rollout that starts with the largest category or the largest region. The most successful projects today are implemented in an agile way, i.e. in small iteration loops, where you start with an MVP (Minimal Viable Product), actually use this MVP variant for at least 3 months, and schedule the next optimization loop only after this 3-month learning curve has expired.
9. Dedicated support by internal employees (e.g. the CoE team): especially in the initial phase right from the go live of the project, an internal support team should be available, supported by external hypercare. The focus here should be on short response times as it is important, especially at the start of the project, that end users receive feedback quickly. If end users do not receive support in this phase, they will not use the tool and will immediately form a negative opinion, even if this is only based on ignorance. This negative mood is difficult to convert into a positive spirit later on.
10. External project support from people who have already successfully implemented such projects can be extremely helpful in many respects. We are not talking about typical consulting companies here, but about former purchasing managers who have successfully established projects in their own companies in the past and are very familiar not only with the technical side, but also with stakeholder management and project marketing. The advantage of such people is that they can ask critical questions more easily and are not really committed to anyone (apart from project success) during the change management process. External consultants enjoy the reputation of users as experts who can be trusted, who have seen many different scenarios and can bring in new ideas and methods. This has the further advantage that the internal team no longer has to invent everything themselves but can draw on experience in the form of templates.
11. Consideration of end-user requirements only within the framework of the KPIs defined at the start of the project: if new customer or end-user requirements arise during the project, these are to be mapped with the KPIs defined at the start of the project. How is this to be understood? In the case of new requirements, it should be checked whether these requirements have a significant impact on the KPIs, otherwise the new requirements should be rejected, as they only mean additional effort in the project implementation without any great benefit. It is normal for additional requirements to emerge during the project that were not known or insufficiently communicated at the start of the project. Especially if these requirements concern special processes that only occur in 10% or 20% of the cases, it is actually easy to calculate whether or not implementing these requirements will have a significant impact on the project's KPIs. An example: Approval processes in the eProcurement process often have complex characteristics, but very few of them actually add value, they only reflect existing reporting guidelines.

How do you secure user adoption in the long term?

Software can only be introduced sustainably if the users themselves recognize and promote the benefits of the solution. In order to be able to prove the benefit of use, KPIs should be measured at regular intervals and communicated internally, since these KPIs are independent of the users' "feeling" as to whether the use of the software offers added value or not. Communication based on clear facts usually makes a major contribution to internal opinion-forming.

Internal support from users who have fewer problems with a change process and are IT-savvy is also important. Indirectly, the employees pull the others along with them, since they also provide a "proof-of-concept" with the increased use that the savings or KPIs once planned can actually be realized.

Key Takeaways:

User adoption is not only a question of the usability of the software and the support of the end user in the correct operation, but a question of the correct change management.

The internal project manager is responsible for at least 50% of the project's success, as they are responsible for project marketing, project KPIs, project duration, and the scope of change management.

The usability of a software should be examined in detail in advance for the processes to be implemented. End users must be included in this examination, and the internal and external interfaces and their influence on potential user adoption must always be evaluated.

External experts can have a significant impact on success by accelerating internal discussions, reducing project effort, and increasing user adoption through the right internal communication and training. As an example, we would like to mention Jacob Gorm Larsen, former Director of Digital Procurement at Maersk and founder of Moneyball CPH, or Nico Bac, Senior Director Purchasing at P&G and founder of Digital Procurement Now who have exactly this experience.