Imagining the future of Procurement technology…
As usual, a couple of recent articles that have nothing to do with Procurement made me think about the direction of Procurement technologies and a potential disruptive approach!
Jan. 16: I edited the article and added references to Microsoft's Cortana after reading the Feb. issue of Fast Company that contains an article on it. That also had the consequence of having me to replace "Procurement Messenger" by "Procurement Assistant" because it conveys a more accurate image of the concept.
Procurement technologies are a platform.
“A platform is a business model that creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers.” Source
The first article, and actually, the one that triggered my “thought process” is about the challenges that the stars of the “sharing economy” face regarding not fully controlling their user experience:
That made me thing about the “platform” experience and about the fact that, Procurement solutions, are, to some extent, comparable to the companies mentioned in the article above. They put the buy-side and sell-side in contact and have no influence (or a very limited one) on the quality of the interactions. Therefore, like mentioned in the article, they may suffer from poor experiences that have nothing to do with the platform itself. But, since the relationship happens on the platform, users may put the blame on the platform.
Platforms and their evolution.
The point above is important because, when you look at Procurement technologies as platforms, you focus on the interactions, the communication between parties. Which leads to the other sources of inspiration for this article: the evolution of instant messaging (IM) towards… platforms. Facebook is leading the initiative by enriching its messenger with capabilities of a personal assistant with functionalities to perform actions (more or less automated).
Example of Facebook’s Messenger (M) as more than a simple chat:
Another example is Slack that has gained tremendous traction in the last months.
Then, there is the whole trend of assistants like Apple’s Siri and Microsoft’s Cortana.
What is interesting in the evolution of IM is that it can deliver value beyond the original value proposition (chat) and do it in an efficient way by using automation and artificial intelligence (AI). The result (or, at least, the intended one) is a pretty smooth interaction in natural language. Very far from the “unnatural language” of many Procurement solutions used at work. (Actually, the point can be extended to almost every apps used at work.)
The Procurement Assistant!
Before looking at some possibilities and use cases, I have to admit and acknowledge that some Procurement solutions are already implementing some of the concepts of the “Procurement Assistant”.
This is, for example, the case of Tradeshift:
But, my point is to go even further by using the most of the potential of new technologies to have a user experience entirely embedded in a messenger application. Yes, it would mean the disappearance of Procurement applications (at least the front-end) but it would bring tremendous value: usage and implementation. Regarding implementation, the “only” thing required would be a standard tool already available in most companies: an IM client!
Use case 1: indirect procurement, demand management.
Someone in your company needs to buy “something”.
Today that person is either writing/emailing/calling… Procurement or has to connect to the internal eProcurement tool to perform a search. Then based on how the solution works and how clear and precise are the search terms, she will find (or not) a result or initiate a free text request.
Let’s look at the same scenario, but happening with the Procurement Assistant, in a conversational style.
Requester (R): Hi,
Procurement (P): Hi, what can we do for you?
R: Well, I need a new computer.
P: Can I ask you why? *
R: Mine is old, at the end of its leasing.
P: OK, do you confirm that you have a Dell PC XYZ?
R: Yes. This is what I currently have.**
P: Thanks for the confirmation. We no longer have this model on offer, but we have the following two options that are very close:
…
Characteristics of this conversation:
- Initiated by Requester (on-demand),
- Natural language,
- Conducted, at least at the beginning, by a bot,
- Dynamic, at various moments, it could have gone another way, see below.
Some highlights of the conversation:
* Based on the answer to that question, reminders on the company’s rules could be given.
** This part of the discussion is based on integration between the Procurement Assistant and the asset management tool. It also shows that if the information about which PC the requester currently has is not known, a conversation is a great way to capture info to re-use it later. This could be useful to capture, for example, preferences like cost center, delivery address…
Use case 2: complex interactions, reaping benefits from technology and people
You may think that this could only apply to simple requests. Well, maybe not. Especially if, like Facebook’s M, you associate real humans to the Procurement Assistant.
The idea is that, as in the 1st use case, the conversation starts by involving a bot. The bot would collect information on the requester’s needs by using questions based on the type of purchase. These questions being either defined beforehand by Procurement and “programmed” into the bot or the result of the bot’s learning process.
Yes, the Procurement Assistant would learn from… humans. How? Well, imagine that the bot reaches a point where it fails to understand the request. It would then smoothly handover to a Procurement Officer who would take over the conversation. Based on the conversation between the requester and the Procurement officer, the Procurement Assistant would learn the key “questions” to ask next time!
Use case 3: Approvals (and any collaborative process).
The conversation of use cases above would eventually end-up with the requester selecting what he needs. Thanks to information gathered during the conversation or thanks to information gathered in previous conversations, the remaining parameters of the request would be defined or confirmed (delivery date & place, cost center, …). Then, it would move forward to the approval process. It would also happen via messenger; variants of the conversation being based on level of transparency:
- Full transparency: the approvers will be added to the conversation. It becomes a group discussion
- No transparency: the Procurement Assistant opens a new conversation, 1 conversation per approver. The requester being informed of the decision when it happen.
P: So, now we have to submit your request to approval. Based on internal rules, your manager (M), Mr. X has to approve.
Mr X. is invited to the conversation (the Procurement Assistant knows if a person is available or not via presence indicators and status. In case of unavailability, an alternate process (approval by email) would be launched.
P: Hi Mr X.
The Procurement Assistant makes a quick recap of the request.
M: What’s my remaining budget?
P: Well, based on all requests since the beginning of the year, your budget is sufficient. Here is a snapshot of your actuals:
M: Then, I approve.
P: Noted, thanks. We’ll proceed with the request.
Characteristics of this conversation:
- Natural language
- Rich: the answer from the bot on budget could provide KPIs / graphs… It obviously implies an integration with budget and actuals.
- Dynamic: in case the manager refuses or needs clarifications and if this is a group conversation, the discussion between the manager and the requester could happen live. The Procurement Assistant would “listen” to keywords (approve, refuse, change…) and interact with the parties until the conversation leads to a decision.
Use case 4: Proactivity
The role of the Procurement Assistant would be more than just a passive one. Various events could trigger it to initiate discussions with the right party. This proactivity could be triggered by:
- events (PO confirmation by a supplier that differs from initial conditions, deadlines of various scheduled activities…)
- evolution in trends detected with predictive analytics (ppm, leadtime…)
Here is an example of such a discussion related to Goods Receipts (the example is in indirect where Goods Receipts are not centralized and rely on requesters to perform an action):
P: Hi, Mr X. Do you have a few minutes to clarify a point related to goods you ordered?
X: Sure!
P: OK, so you have ordered a new PC and based on the Purchase Order, you should have received it yesterday. My question is: did it arrive?
X: Yes!
P: Perfect! This is noted and registered! Any issues in the delivery?
X: Actually, yes. The box was broken and when I opened it the PC is a bit damaged. It works, but since it is a new one, I would expect a PC without damages.
P: OK, so we can initiate a complaint to the supplier and ask for a replacement.
…
Characteristics of this conversation:
- Initiated by The Procurement Assistant
- Natural language
- Context-aware (the Messenger has the information on the Purchase Order so when the Good Receipt is done, it knows to which PO and position it has to be done)
- Dynamic, at various moments, it could have gone another way, see below.
- Source of knowledge (any information on the quality of the delivery would be logged and used as part of the supplier’s assessment)
Potential variations in the discussion:
- If the person had not received the goods, then the bot could have sent a request to the supplier to clarify the new delivery date or directly add the supplier to the conversation to have him and the requester agree on a new deadline. While listening to the conversation and based on the agreement between the two, the Procurement Assistant would update the PO directly.
- Similarly, the point on the goods being damaged could trigger a group discussion.
How to make it happen?
Well, the visible part of the Procurement Assistant is an already existing technology: Instant Messaging. It would be either using already available platforms or used a proprietary one. The most difficult part is actually hidden. It has to do with the “bot”. But, considering progress in technology (language, AI, machine learning…) this is something that is more and more feasible.
Solution providers may not have to develop all of this fully internally! They could tap into already existing intelligent systems. The story below illustrates how IBM’s Watson can be leveraged as Mike Brandt demonstrated:
Too good to be true?
To conclude, all the above may sound scary and be reminiscent of HAL 9000!
But, some of the points above will end-up in Procurement Technology. One day or another.
Better be ready!
“Technology is not just about simple siloed and “empty” packaged apps automating incrementally improved processes. It’s not just a workflow enabler. Rather, as value chains go digital and begin getting “disrupted,” that, by definition, will have to radically alter those who are the architects and orchestrators of those value chains.” —Spendmatters
If you enjoyed this, please scroll down and click the “recommend” or “share button”.
If you have your own “perspectives”, just use the “response” feature.
