As we move forward with digital transformation, we must never lose sight of the fact that everything digital is still touched by a human hand, head and a heart. Even machine learning happens as a result of some interaction with a human.
That is the underlying philosophy of human-centric design. No matter how good the technology is, what ultimately matters is whether the various stakeholders or personas use it – and to what extent they will not only benefit from it, but tangibly experience that benefit.
For human-centric design to be effective, one must understand how human beings want to interact with systems, services, processes and functions, as well as understand that stakeholders judge the quality and ease of use of these entities based on entirely different, and often conflicting criteria.
The main aim is to ensure that their experience of the product is a positive one.
If we now apply this philosophy to procurement, or more broadly the entire source-to-settle continuum, let’s think of all the different personas we are trying to please and bring on board.
- What are their motivations?
- What upsets them?
- What would make their life easier and more rewarding?
- And, equally important, what is of no direct interest to them, but they should be aware of?
The best place to start would be with us – the procurement community.
What we all probably care about most is demonstrating the value we generate for our organisations – getting the best deals, making savings, identifying good suppliers, and ensuring that buying is on-contract, and compliant.
Next, we have the suppliers.
They want to be able to engage with our businesses – with end users and with procurement – and have an equal opportunity to win contracts. They would like buying organisations to remove any barriers to this happening easily, and of course, they want to be paid for the products they supply and the services they render as quickly and effortlessly as possible.
The third persona, the users of the products and services, on the factory floor, in a clean room or in an office, have an entirely different perspective – just wanting to get what they need when they need it. Price doesn’t really figure, and compliance, from the end user’s perspective, simply reads as obstacles that have to be overcome (even if most of the time user departments are unaware, or only superficially aware, of any compliance issues).
Then, when the invoice comes in and the correct procedures have not been followed, issues arise for our fourth persona, people who work in accounts payable, and finance. These days, this is likely to be an outsourced service, and with that comes certain rules that have to be applied.
Having placed ourselves into the shoes of these personas, it is now that all the pieces have to be pulled together. Procurement says an item was bought off contract. The supplier says, “That is not my problem, I want to be paid!” The end user says, “I didn’t know about the contract, I just needed the product in a hurry.”
All of which means it can take hours to resolve and reconcile even a trivial invoice – leaving finance people feeling really battered and bruised by it all.
Building cross-functional empathy
Of course, this is something of an oversimplification, because there are many other personas with their perspectives, such as risk managers, quality control, CSR and so on. A human-centric design workshop may need to consider thousands of different data points in a large and diverse organisation.
The point is to look at processes, systems and structures from all of these perspectives with empathy for all of the personas involved.
For example, making it easier for shoppers to find contracts, and easier for suppliers to get on the shortlist. Taking away the pain for any one of them, takes away pain for others: if buying on-contract is easy, everyone wins.
By going through this exercise, we are able to build an appreciation of how everyone contributes to the success of the business, and that’s a win in itself.
In addition, we are able to provide a much more powerful project blueprint for the technology implementation, which in turn will boost system uptake post-implementation, and with it, return on investment.
Thirdly, we can create a clear communication strategy that has meaning to all of the stakeholders and supports a smoother process of change management: this is what you said you want, this is how we plan to give it to you, and this how the behavioural changes will impact the business.
Human-centric design builds empathy across the barriers within the process – and that really unlocks value, because everyone gets what they need. Everyone gets what we call a “delightful gift”.
A human-centric design workshop thus builds a picture of all the needs and wants within an organisation: it breaks down departmental barriers and siloed thinking to achieve greater alignment, eliminating or minimising the unintended consequences of measuring performance based on conflicting departmental or functional goals.
Another outcome of human-centric design is the redesign of KPIs to reflect cross-functional and cross-process objectives, so that we are collectively accountable. For example, paying suppliers on time should not be a KPI for finance and AP alone; events and behaviour upstream have an impact on how fast an invoice can be settled.
Finally, I strongly believe that procurement technology vendors who take the time to address the needs of this entire ecosystem, going through the trouble of ensuring that all relevant personas are given maximum vocal input into system design and prototyping, extending far beyond the commissioning or paying customer, will be those who thrive in future.
About the author: Madeleine Joubert is a transformation leader of multi-disciplined teams that design, build, and deploy innovative solutions using human-centric design principles at the intersections of finance, supply chain, and procurement. Madeleine has a PhD in Finance and Financial Management Services and lives in Greater London.
Madeleine will be speaking at our Procurement with Purpose Panel Debate on 29 July.