Your organization has made the decision to invest in a Source-to-Pay (S2P) technology and you have been asked to lead the selection project.  The selection of a technology is typically a large investment, and you will be establishing a provider partnership that will last many years – it is critical that you select the right technology and partner.  Recognizing this, you sit down to start thinking about your approach and quickly realize that selecting a S2P technology is a complex project that requires you to understand the needs of stakeholders throughout your organization along with the current functionality and capabilities of the S2P technology providers in the marketplace. How should you go about pulling together all of the information you need to effectively go to market? What questions do you need to ask of providers?  Do you have a sufficient understanding of the technology to ask the right questions? How do you evaluate and compare the technologies?

So where do you start?  Given the criticality and complexity of selecting a tool, we are often engaged to guide clients through the selection process.  When we do a S2P Technology Selection project for a client, we work in two phases. Phase I is the Requirements Gathering Phase and Phase II is Technology Evaluation and Selection.

In part one of this blog, we will explore the Requirements Gathering Phase.

Current State Mapping

The first step in the selection process is to understand your current state for technology and processes. 

Technology – Prior to selecting a technology, you should first map your existing Procurement technologies. Mapping them will help you to understand which technologies will remain (and which won’t), and what integrations (if any) you may need to plan for.  This is important to ensure that you can clearly articulate these requirements to the market, giving providers a clear picture of your integration plans so they can confirm their capability and experience working with your current technologies.  

Process – Similar to technology, you should map your current procurement processes to help identify which processes you want to enable through technology.  Many companies make the mistake of thinking a technology will “fix” lacking procurement processes.  This is not true – technology is not a magic solution – if you have poor processes prior to technology then you will simply enable poor processes. Mapping your current processes will force you to evaluate where you are and identify where you need to improve your processes prior to implementation. Doing this now gives you ample time to improve your process prior to the implementation of a tool.

Future State Vision

Before meeting with your stakeholders, develop a future state vision of what a S2P technology environment will look like at your organization.  This vision should clearly show which modules you plan to acquire and implement (scope), how they will either replace or integrate with current technologies, a draft project timeline for both selection and implementation, and should clearly demonstrate how the project will improve the organization. It is key is make sure that you understand what is possible with technology and that you don’t create a future state vision that isn’t achievable.  A clear understanding of the future state will help stakeholders understand the project, how it will impact them, and provide a defined structure to guide the requirements gathering phase.

Requirements Gathering

Once you have developed the current and future state maps, it is time to think about requirements gathering.  The purpose of this part of the process is to ensure that you understand what the technology can and can’t do in relation to what you want it to do.

This is a critical step in preparing to go to market.  Before you can select a technology that will benefit your organization, you should understand what your stakeholders need the tool to do.  This should be looked at on a module by module basis and include feedback from all regions and business units that will utilize the tool.  Some requirements to consider include:

• Process Enablement
• Module Functionality
• IT Requirements & Security
• Integrations
• Reporting
• Languages
• Currencies
• Project Management & Tracking

When we help a client with requirements gathering, we facilitate interactive workshops for each module included in their plan.  During these workshops, we cover the functionality of each module and extract requirements from the stakeholders keeping the principles above in mind.

When we work with stakeholders, we utilize several principles to keep stakeholders focused on actual requirements.  This includes:   

1. Needs vs. Wants: Most importantly, you want stakeholders focused on needs and not wants. I want a Ferrari to drive around town – but I need a Toyota.  It is easy for stakeholders to gravitate towards wants, however keep in mind that they will likely add cost and complexity to the implementation and use of the selected tool.
2. As you go through requirements gathering it can also be easy for stakeholders to begin to think about design. You will need to steer them away from this and keep them focused on requirements - design will come during the implementation.
3. Stakeholders will also want to focus on their day to day world. They will likely want to discuss category or department specific challenges.  While you should hear them out to determine if these are valid requirements, it is important to keep stakeholders focused on process.  Trying to accommodate the exceptions will only add complexity and cost.
4. A final thing to remember is that you want to avoid creating custom requirements. Many of the tools available in the marketplace today are configurable, but not necessarily customizable.  Customization adds cost and many challenges down the road and should be avoided.  Most clients work with the principle that there will be no customization to allow for seamless upgrades and lower total cost.

1. Create a Book of Requirements – This document should spell out the requirements, module by module and be listed as statements that the supplier can provide a “Yes” or “No” response to. For example, one of the requirements identified during the requirements gathering session is that the Sourcing module must be able to allow bids in Chinese Yuan.  Our requirement would therefore be: “Sourcing tool has the ability to allow bidding in Chinese Yuan”. The provider would answer “Yes” if this is true or “No” if they do not meet the requirement.  In cases where they do not meet the requirement, they are given the opportunity to explain. This will allow you to quickly identify (through “No” answers) gaps in the providers tool.

In addition to requirements for each of the modules, a section for IT requirements (data security, privacy compliance, downtime, etc.) and a general section to cover requirements that go across modules or from other areas of the organization should be included.

Keep in mind that some requirements may be better suited as an RFP question and should be added to the RFP question section for that module.

2. RFP Documentation – In addition to communicating requirements, putting together a robust RFP is key to getting the information you want from providers.

Given our experience helping clients select S2P technologies, we have developed very robust processes and documentation that capture most activities that should completed during the requirements gathering phase.

Now that you have gathered all of your requirements and prepared all of your RFP documents, you are ready to go to market.

In Part 2 of our S2P Tech Selection blog, we will focus on Phase 2 – Evaluation and Selection of the S2P Technology process.  We will examine some of the challenges of going to market for technology, how to evaluate the RFP responses with weighting and scorecards, down selecting, and utilizing use cases to make provider demonstrations more relatable to your organization.