Implementing first Sourcing and then P2P or the other way round ? My 2cts.
It is a good day, you have subscribed or purchased your Source -to-Pay solutions. Now, is a good time to think about implementation sequencing, that is, if you have not yet.
These as probably the criteria, you wish to consider:
- Business case and its value levers
- Project sponsorship
- Adoption path
- Regional limitations
- Project timeline
- Available resources both internally and contracted
- Concurrent IT projects as ERP implementations
The business case is built on value levers which both size the opportunity and aim at specific objectives. Companies typically opt for a combination of objectives which could be any of the following: out-of-pocket savings, procurement efficiency, compliance, user empowerment or again standardisation. The specific combination of objectives will drive the prioritisation of deployment. A company aiming at standardisation, will probably opt to deploy P2P first and later Sourcing while one choosing to pursue out-of-pocket savings, will prioritise Sourcing.
It goes without mentioning that, deploying Sourcing has typically a shorter timeline as it mainly affects teams of professional buyers, while a P2P implementation involves a much larger user base and is usually cross functional and operational.
There is some value though, in paying consideration to the project sponsorship with regard to the implementation sequence. The project sponsor(s) typically drive the overall vision and governance of the project and is responsible for it’s delivery.
Hence, a project sponsor from the IT function, might be more mindful of the overall IT strategy of the company and therefore of the integration of the solutions within the overall IT landscape, than a project sponsor from S2P, who might be more focused on reach, depth and visibility provided by the solutions from an operational perspective.
As a result, the sequence of deployment might be influenced, if not driven by the type of sponsorship of the project. In real life, it does occur that project sponsors from IT, are confronted with some resistance from the business as their automation, standardisation and digitalisation priorities collide with the short/mid-term objectives of the individual LoBs or functions. The consequences of these issues are long lasting and pervasive:
- The business requirements and limitations are not well shared and therefore not well translated into set-ups and configuration of the solution(s).
- Even, when they are well shared, the adoption path is a difficult one, as the view from an IT perspective does not always mirror that of the users and the business, where the actual change needs to occur.
It might therefore be a best practice, to have a co-sponsorship to IT, with Sourcing and Procurement co-sponsors as S2P is a multi-stakeholder implementation.
One last consideration, is to onboard Finance and AP as early as possible, as these functions will benefit indirectly from any S2P solution deployment and are the ones, validating the financial outcomes of the project. Under an IT sponsorship, it makes sense to implement P2P first, as this is the solution with the higher integration requirements within the IT landscape. Under a CPO sponsorship, the first implementation will typically be Sourcing and COOs generally have a preference to starting with P2P, as it ensures compliance, efficiency and bottom-line (P&L) results, by capturing the savings achieved in daily operations.
Companies with regional/global programs often struggle with regard to sequential deployment across their geographies. Companies are often piloting S2P, starting within a country or region, ideally representative enough to provide a blue print for further deployments. I find that often, companies choose the pilot on different criteria such as size, complexity, supplier marketplace, IT landscape. While these decision criteria are valid, they should not preclude the fact that a pilot has to be replicable and comprehensive: It is meant to test and validate your vision, your strategy and your business objectives in all their components. At the end of it, hopefully, to understand what worked, what did not and more importantly why.
The main selection criteria with regard to where to deploy, first, second etc… in my view, are not the spend, the number of transactions, the number of suppliers or again the number of spend categories but rather, in a cloud environment, as opposed to one on premise, is that another criteria might be more crucial: Human resources impact. Implementing S2P solutions is always accompanied by a need for change management.
At the centre of all S2P implementation, there is a need to focus on the users, as without adoption by them, there cannot be a successful deployment. Hence, it is my advice, to deploy by Sourcing categories segmenting these with regard to:
There is no impediment to start implementing Sourcing with a larger geographical scope (as the need for integration within the larger IT landscape is reduced until the award phase), thus allowing to capture savings early and fast on a larger spend base.
While for P2P, I recommend a segmentation by function(s) because of the particular knowledge and insights, these functions have about the specific configuration requirements of buying channels and invoicing processes. The order of implementation could be driven by the buying channel complexity and diversity.
- HQ functions are easier to onboard for P2P than,
- Plants or,
- Distribution centres or,
- Specialised subsidiaries
It is also true that functions such as:
- Facility Management
have more stable, structured and thus “tried and tested” buying channels such as catalogues, invoice against relatively simple contracts, tactical sourcing or marketplace purchases as opposed to more complex ones; such as complex contracts and Service Entry Sheets and therefore are,
easier to onboard than:
- Marketing or,
which have a more complex and diversified, specialised that is a less “commoditized” spend portfolio.
The supplier management and integration requirements are also less demanding for the earlier functions than for the latter ones. The supplier base is also generally more “cloud mature”.
With regard to the project timeline, in my experience, it is faster to implement first, Sourcing and then P2P, then to try to implement P2P first. The reason being that, an implementation with the end in mind is easier then trying to reverse engineer your Sourcing to meet you P2P set-up, typically more integration intensive and more operational at the outset. Having said the above, it can be of benefit to start with P2P which will drive compliance to buying channels in Sourcing, in a later phase. It has to be considered that a rigid P2P, can be detrimental to the creativity of Sourcing and Source-to-Value speed, if implemented first, thus foregoing part of the added value of a flexible and sophisticated Sourcing solution.
Lastly, the resources required to deploy the Sourcing solution are significantly lower in number, than the ones required to implement P2P. This means that in a context of limited/insufficient resources, it might be smart to implement Sourcing (incl. simultaneously with P2P) and proceed by function, or category to generate bottom line results that build the case and finance additional resources to support a later larger implementation scope.
Often, customers have many IT implementations running concurrently. in this configuration what is important to consider are the integration needs of the respective Sourcing or P2P solutions. Typically, Sourcing requires less integration, therefore again, starting the S2P project by implementing Sourcing the better option.
Sourcing for all the reasons here above would have my preference in terms of implementation in a S2P implementation context:
- Smaller and specialised user pool
- More standardised business requirements
- Less IT integration needs therefore more cloud suitable
- Less supplier integration need
- Less operational impact but,
delivering the potential value and savings which can finance a more complex, resource intensive and lengthier P2P implementation.