Establishing Source to Pay content goals is critical to benefits realization when implementing a Source to Pay system. As system usage is largely correlated with content, this needs to be something you think about up front. As an example, one of the assumptions behind benefits realization for a purchasing/buying module is that once you on-board users, they will start using the system for all of their applicable purchases. This assumption however, takes for granted that users have a pleasant and positive experience when first using the tool; that users will keep coming back instead of finding ways to buy “rogue”.
Apart from executing on a solid change management and training strategy, there is another way to ensure you are turning users into “believers”: relevant content. Continuing with our purchasing/buying module example, when users log in for the first time, it needs to be easier than ever for them to find and purchase the items they need.
What is Relevant Source to Pay Content?
Without the proper content, when you “open the doors” to your source to pay modules, they will look like an empty retail store. The design and process you’ve created might be top notch but without any “products on the shelves,” “customers” will quickly move on. Therefore, the amount of content available at Go-Live, when you first “open the doors” to users is an important consideration. However, it isn’t the most important one.
The relevancy of content for the user audience being on-boarded should be your main focus. In our physical store analogy, if you invite heavy metal rockers to a music store, but only have classical instruments available, you’re going to lose a big part of your initial audience. Your rocker will be thinking: “That store only sells classical music instruments. It’s not for me.” When you eventually do stock electric guitars, you’ll have to re-conquer the hearts and minds of that audience as you lost earlier on. Everyone knows you only get one first impression…
Similarly, if you’re on-boarding maintenance technicians to an enterprise S2P buying module but only have catalog items for office supplies, you’re going to quickly lose their interest as they will be looking for spare parts and contingent workforce items in the catalog. Therefore, it is paramount that you make specific, catered Source to Pay content available to the user groups who are on-boarding your solution on the first day they on-board if you plan to realize your business case.
So far, I’ve been using the catalog/buying example to illustrate the importance of content but the same goes for all other modules in a Source to Pay suite. Here’s is a list of the most important data elements to consider when implementing different modules of a source to pay suite:
Spend Analysis / Analytics
Enriched data. If you are implementing a spend analysis module, there are two main benefits. First, the ability to see a unified, centralized view of spend coming from multiple systems. Second, the ability to add contextual data to invoices/purchase orders and supplier data using a third-party enrichment processes and tools. Benefit #1 can be moot if you already have all your spend in a single system. However, benefit #2 can create tremendous value If you are enriching with meaningful, relevant information. This is not a given. To determine what meaningful information is, start by asking the question “What information are we always missing as we take strategic buying decisions?”.
As an example, if you have a large portion of your spend in non-PO invoices, meaningful data might be the addition of a commodity code (the same one as in your purchase orders) to invoice line items based on predetermined rules. These rules also need to be contextual to your business as the same suppliers could potentially match to a number of commodity codes.
For example, Siemens could be providing you materials that are related to a number of commodity codes related to mining, healthcare, food and beverage, etc. Blanket enrichment rules in this case will do you little good.
Sourcing
Template processes & documents. When you implement a sourcing module, you are primarily implementing a workflow tool. The goal is to first reduce the number of sourcing process variants that exist in your company to their most basic expression (perhaps that means there’s 12 sourcing process variants in your company, one per commodity – perhaps it means you have 3. There is no boilerplate answer here).
Then, once these variants are identified, they can be defined as process templates within your module. Supporting document templates (word docs, questionnaires, web forms, etc.) needed as inputs/outputs of different activities can also be integrated to the process template so they are available to users when they need them in their sourcing activities.
The relevancy part comes in as you decide which user groups will on-board the solution first. You want to ensure that when users on-board the solution, they have the relevant sourcing process templates to carry out their work. For example, if you are on-boarding an IT buyer, your IT sourcing process needs to be defined and executable in the tool.
Contracts
Template processes & documents. Much like a sourcing tool, a contract management tool is also largely a workflow tool which needs to be supported by relevant process templates that cover your legal contracting process. You’ll usually have less process variants in this module than in a sourcing solution.
Clause Library. One of the main benefits of a contract management tool is having a predefined clause library. If you can manage to upload clauses and substitute clauses that are pre-approved by your legal department in the library, a buying team can do most of the legwork of preparing the contract. By picking from these clauses so that the legal department is only reviewing the contract instead of building it, you remove the bottleneck that traditionally builds up around contract management activities in a corporate legal department. You can also use this mechanism to prevent the use of clauses that produce negative downstream impacts when you try to implement them in your buying system.
Relevancy comes in when you decide which clauses to tackle first. This is determined by simply asking: “Who will be using the contract management tool in our first deployment waves?”. The clauses for their contract types need to be covered at least minimally. Bonus points if you align this answer to your sourcing module deployment so users have relevant content for the whole of Source to Contract activities (i.e. IT contract clauses are added to the library first).
Legacy Contracts. In addition to a clause library to help build new contracts, you also want to ensure that relevant “old contracts” are housed in the tool. When negotiating a new contract, a buyer will always refer back to similar contracts to draw on winning clauses and strategies from the past. Therefore, when they search for these contracts within the tool, they need to find them. Ask yourself: “Who will be searching for old contracts via the tool? What will be the potential scope of their search? How does that translate to a list of contracts to upload to the tool?”
Do not underestimate the effort for this particular item. Often, old contracts are scattered across the enterprise on multiple different content management platforms (Sharepoint site, shared drive, bill’s hard drive, etc…) and not necessarily easy to round up.
Procure to Pay
Catalogs. As discussed previously in this article, relevant catalog content for users being on-boarded to a buying module is key to winning them over. Ensure you have the top items purchased by your user communities in the catalogs at Go-Live to create an engaged purchasing audience. If you can’t coordinate with a supplier to get a punch-out catalog enabled in time, fall back on the option of hosting the supplier’s item on an internal catalog in the meantime.
Policies. If you’re planning on doing any sort of guided buying, you’ll want to make sure that all relevant parts of your purchasing policy are explicitly documented in the workflows applicable to the user groups going live. If users try to purchase something and are restricted to certain suppliers because of policy, this should be apparent during the process. Pro tip – Different policy statements embedded in the tool should be numbered to facilitate reference to different parts of the policy during operations. If a user wants to contest a policy that’s being applied, give them an easy mechanism to do so: “I don’t agree with rule 1.1.3 that’s being applied at checkout”.
Key Search Elements. For catalog items, lots of guesswork is removed for the user (e.g. which supplier carries this item? What commodity code is applicable to this purchase?) However, for non-catalog purchases, users need to be able to quickly find the non-product information they are looking for when they search for it. This includes things like supplier data, commodity codes, general ledger accounts, cost centers, etc. A key change management activity as you collect user feedback through demos and tests is to get user input into the top pieces of important data for them. Get the list of all master data items from your implementation team and go through each piece of data with the business. What are the most used elements of data by user group? Will they have them available in the tool for their deployment? This is how you create a “wow factor” in buying modules.
Business Networks
Enabled Suppliers. If you are coupling your buying module with a business network implementation, you will be developing a strategy to on-board suppliers. In this strategy, you should correlate user groups to the most meaningful and relevant suppliers for your first on-boarding waves. Similarly to the buying module, you don’t want to prioritize the enablement of an office supplies supplier if you are on-boarding maintenance technicians in your first wave. Otherwise, the supplier might be enabled but there won’t be any transaction volume through the network.
Also, on this front, you should consider the complexity of your operations with a supplier when deciding how to enable them. If you’re doing lots of complex transactions with a supplier, the most value will be in having them fully integrated through a network. This is when your back end system has the ability to send documents directly to the supplier’s back end system without human intervention). However, this is also the most difficult and effort intensive way to enable a supplier as you need to design and define all the process variables needed to automate all of their transactions. Automation can’t exist without rules and rules can’t exist without process. If you try to enable suppliers without having defined a detailed transactional flow process, things will get chaotic. And a chaotic process automated results in automated chaos…
What is a Source to Pay Content Goal?
When you’ve identified the relevant content by module, you should come back to the volume question. How much relevant Source to Pay content should be made available to user groups to make a good first impression? This is key to starting the realization of your benefits. As a rule of thumb, I like to check if the Pareto Principle can apply in this situation. Will the top 20% of most used data give us 80% of what people need on a daily basis?
By far, the easiest way to get a sense of this is to have these conversations with your user group representatives. Ideally, when they understand what you are trying to do, you can ask them to give you their list of “must have” data from their current system (even if that system is manual…). Your master data lead can them integrate this information into their data conversion activities.
Then, for each user group, set a Source to Pay content goal by module/data element. This could be as simple as ensuring a certain amount of relevant data elements are available for each user group at Go-Live:
- Top 10 legacy contracts per commodity onboarded
- Top catalog 10 items by identified user group
- Top 3 suppliers enabled/integrated by user group
- Etc.
Putting in place and tracking these goals from wave to wave will ensure you’re not forgetting to consider key user groups that will help drive your business case benefits. If you are worried the importance of your Source to Pay content goals will fade as the project progresses, include this notion in your project’s guiding principles.
Why Is Source to Pay Content so Important?
It’s pretty clear that if you don’t provide an appropriate amount (quantity) of relevant content (quality) for the different user groups of your solution the first time they sign onto the new system, your planned benefits will not materialize as quickly as you’ve assumed.
You only get one first impression and working to cultivate a “second chance” is unlikely to be your priority when you turn your attention to rolling out your solution to subsequent user groups. Getting your Source to Pay content strategy right from the start is a subtle but critical success factor that contributes to benefits realization when implementing a Source to Pay tool. Make it a priority with your change management team and you won’t regret it.
———————————
What are your thoughts on critical data for S2P implementations? Did I miss any key data items? Do you see the importance of data in an implementation differently? Let me know in the comments.
If you liked this post, why not Subscribe
Last Updated on January 7, 2021 by Joël Collin-Demers
