Software Usability – what is important for the procurement function?

Our new research paper “ What Does Usability Really Mean? Making Software Selection Decisions and Getting Behind the Rhetoric” can be downloaded (free on registration) here. It considers the very topical angle of “usability” in terms of business software, particularly that of interest to the procurement community.

We look in the paper at usability from the perspective of different stakeholders – users, suppliers and of course procurement people.  Here is the section that looks at that particular aspect – but do take  take a look at the whole paper.


 Procurement usability

As explained above, the procurement function often does not get too involved in individual transactions through the procure-to-pay (P2P) process. But the function and its leadership must take a real interest in the technology that underpins the process. That means being concerned about the spend owner usability issues outlined above, but there are also other issues to consider, more specific to procurement objectives and tasks.

Procurement will probably “own” the suppliers and contracts that will populate the P2P system, so it has a real interest in supplier adoption – how easy it is for suppliers to register, provide relevant information needed for the trading relationship, and generally get set up to start doing business.  When you’re considering a new procurement system, talk to your suppliers – large and small. Most will have transacted with a variety of systems and could have valuable insights into their usability.

Spend governance may lie under the procurement or finance team’s control, but is important in either case. That includes definitions of who is allowed to buy what, from whom, and via which approval processes. Routing of requisitions and orders to receive the appropriate sign-off; visibility of different contracts or suppliers on the system; access to catalogues; these are all key elements within the governance process.

Another aspect of usability comes into play around catalogue management. Users are likely to be buying through such tools, so the ability to manage and easily configure catalogues to enable users to buy from the appropriate suppliers (generally chosen by the procurement team) is vital. Procurement and finance may also wish to control which goods and services are available to users within each catalogue, which again makes flexible configuration a key element of usability for procurement.

Then there are issues around organizational structures. Most large organizations go through major structural changes around every three years. What does that do to the schedule of budgets, named budget-holders, divisional structures, approval routing and so on? Will making the necessary adjustments to the spend governance regime (routing of approvals and management of sign-off limits, for instance) be an expensive nightmare every time the CEO decides to shuffle the pack?

What procurement (or finance) needs is the ability to reflect these changes quickly and easily – and without extensive IT involvement. Typically when an IT request is required, it takes a long time for change to happen because IT resources are scarce, and they are juggling many projects with seemingly more important priorities. Sometimes users are quoted five or even six figure sums by software providers to make relatively small configuration changes to systems. So usability in this sense is all about the internal “system administrators” being able to set up the system easily and make changes to profiles, approvals and content without expensive provider intervention.

Share on Procurious

First Voice

  1. Market Dojo:

    Interestingly I was recently asked should the software change to the users processes or should the users processes change to the software.

    Historically with large on premise applications the user had to change their processes to fit the software , or they would need to spend large sums of money having a bespoke development on top of the existing software functionality.

    However, with the advent of this new breed of SaaS applications (Salesforce leading the way!), the actual reality is now much different.

    Firstly these applications are designed with the end user in mind so they are more aligned to the end users needs in the first place. Secondly they also have a degree of customisation in them to also bespoke them in some way to your needs. Thus you can have software which does not need to be made especially for you and you don’t need to change your way of working.

    Also if developments are needed, the cost generally for these developments is much less and also will be rolled out to all (SaaS – Multi tenancy) and thus benefit the entire customer base. The design of any new developments need to be carefully integrated so the software becomes feature rich without losing usability.

    The other interesting point to note is that since so many companies can and will use the same software platform, the USP in the companies process and how they gain advantage is no longer in what software they use (as so many will use the same piece of software) but in how they use it. This is most obvious when you look at engineering companies and how they use simulation software, no longer do they try to make their own, but all generally use the same ones and it is how they use it which gives then the advantage.

Discuss this:

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.