Another one of these “buzzwords”…What does it really mean in simple terms? How does that inform the adoption strategy ?
In a portfolio of Source-2-Pay solutions the adoption path and speed vary greatly. While adoption is generally good and relatively quick with regard to Sourcing or Supplier Management solutions (traditionally called “upstream), the so-called “downstream” adoption (that is Buying and Invoicing) is much harder and slower to come by. Why is that ?
The prime reason is that buyers are paid to source and potentially to manage suppliers properly, it is their core business and MBOs are based on what they achieve in this area.
Buyers thus have a vested interest in using the solution as they expect the solution to deliver key core benefits;
1)source what they already source and new/additional spend faster and more frequently
2)source with better results e.g. savings, competitiveness
3)source based on better sourcing and evaluation/award strategies.
The name of the game in achieving adoption of a sourcing and/or supplier management solution is the “Push”. The more content, the more pre-configured sourcing options (RFX, Auctions, Auction types, optimisation scenarios, scoring matrices etc…, the more monitoring/reporting options (dashboards, reports, feeds, integration with downstream etc…) are made available to the buyers the more likely they are to make good on 1. This is the “Push”.
However, at the same time, the solution and the company pre-formatted content/set-up need to offer enough possibilities for the buyers to be creative, to wander, to try and thus learn from what buyers create in this respect to feed the “Push” through a “Pull”: Continuous improvement.
An illustration of this: A buyer creates a Japanese Auction for the first time for a particular category. It goes very well. This is the opportunity to learn from it and 1)reapply it to other suitable categories 2)offer it as part of a standard configuration to the other buyers. The content creates itself with usage. This is the “Pull”.
On the other hand, in Buying or Procurement the situation is quite different: casual users, functions outside of Sourcing, departments and other budget holders do not have procuring, buying, requesting as their core business. It is an ancillary task or activity to the core activity and sometimes even an administrative burden with little or no value to them.
A random user buys office supplies not because she enjoys it but rather because without it, she cannot perform to satisfaction the activity for which she is paid for and need to deliver against.
An HR budget holder for trainings is paid to ensure the design, relevance, efficiency, and satisfactory delivery of trainings within the budget rather than issuing Purchase Requests (PRs), Purchase Orders (POs) with “imposed” suppliers and reviewing invoices thereof.
While procurement or IT professionals tend to look at adoption of Buying by looking at a number of transactions, spend under management, compliant spend and PR2PO cycle as well as other measures this is absolutely not the perspective of the users and functions.
Users look at it from a need coverage perspective: Can I find all or most of what I need to perform my duties, activities and achieve my goals fast, easy, with entering minimal data, in one place with minimal administrative hassle.
Let’s translate this into features (non exhaustive list here below):
- Optimised search results using my jargon: when looking for a monitor users search for “screen”, when looking for pens in French users search for “bic”, a brand, in Germany looking for tape, users look for “tesa-film”, a brand…
- Tiles by categories also help to take user quickly and unequivocally to where what she is looking for is
- Translates into pictures
- Translates into when I cannot find what I am looking for there is an option within the same tool – e.g. eforms or I am guided as to where to find what I am looking for
- Description is self-explanatory and covers key attributes/choices
- In the same place that is in the same solution
- With minimal administrative hassle translates into the approval flows are in place, I get a feedback from the supplier(s), I can add supporting documentation or I am required to etc…
What does it mean? For the people implementing the solution, there is a fine balance to strike between between economies of scale and user satisfaction.
What does this balance mean?
- Make available high volume/high value commodity items e.g. office supplies, IT, furniture, spare parts etc… the “usual suspects”. This will allow you to meet your business case.
- Ponder the decision to go for punch-out catalogues (which allow for limited opportunities for optimised searches, jargon etc…) vs. implementing internal catalogues, (incl. maintained by suppliers) which favour user satisfaction if only from an interface point of view. This will allow you to increase user satisfaction
- Balance for the need for control that is placing restrictions and limitations (of which there is an endless list) at the beginning of the program against the need for user engagement, that is freedom. You can always restrict it later if abused.
- Look at user coverage and aim at having a broad range of spend categories on offer even if behind the “tile” you offer only 1 or 2 choices… The objective is to have users ask you to include more items under the tile.
- While you are looking at spend coverage, run in parallel an experiment with a “mature” function such as HR, FM, MRO, IT to see how much coverage and thus user satisfaction you can achieve: Learn and replicate.
How does it translate in real life? Enable 50 categories with the following characteristics within the first 12 months:
- High transaction categories 5: catalogues
- Low volume categories: 10 (Spot Buy* for example)
- One selected function specific categories: 20 (Contracts, BPO, Release contracts)
- Categories with 1-5 items e.g. “make life easier categories”: 15 such as business cards, subscriptions, gifts, trainings, translations, software subscriptions through eforms.
This might strike the right balance for the casual user but also provide a successful pilot and proof of concept for the functions.
The “Pull” effect should happen then: whereby users ask you to include items and services into the offering and whereby IT becomes a customer delivery system to the business.