In January 2020, Benjamin Fourier joined Fluxym to develop an offer and an Advisory team.
The development of the Advisory division has enabled Fluxym to support its clients on all aspects of their Source-to-Pay projects: the implementation of Ivalua or Basware solutions, but also the definition of the roadmap, the optimization of business processes, project management, and change management.
According to you, drafting specifications is necessary but not sufficient to start a purchasing digitization project the right way. For what reasons?
This is something we have noticed as an integrator of Source to Pay solutions. When we start a project and ask our customers business questions, it is not uncommon for them to send us back their specifications.
Of course, this document is essential since it defines the desired solution (the target). But implementing a Source-to-Pay solution requires addressing a certain number of business topics (how to reach the target), especially around processes, data and organization. That’s why the client and its integrator often find themselves confronted with a large number of unanswered questions when approaching the design phase.
That is why at Fluxym we recommend (and systematically suggest) a scoping phase at the beginning of a purchasing digitization project. The first question we ask our client is “What for?” This may seem a bit basic but it allows us to identify priorities and detail the needs the tool will provide a solution for.
What are the risks when starting a project without this framing phase?
The first risk (and not least!) is to set the wrong goal and discover unstated expectations along the way that could drastically change the direction of the project. It was the case with one of our clients who considered the supplier invoices digitization as the main objective of their project. However, after our framing mission, it turned out that the real issue for the trades and accountants was to match purchase orders against invoices linked to several systems.
Involving all the stakeholders of the project as early as possible encourages exchanges between functions (purchasing, finance, IT, etc.) and the identification of the real pain points. This results in a better sharing of goals and facilitated adoption.
The second risk concerns planning. Once you have selected your tool (and purchased it), it is tempting to start your project right away to achieve your goals as quickly as possible. Be careful, however, not to neglect needs analysis: you will have to make design decisions with the integrator on the basis of defined needs and shared target processes. If during the design workshops the project team doesn’t know what they want to put in the tool, there will be blockages and the project will fall behind for sure.
What is the right method to (re)define your business processes?
During the preparation phase, the most important thing is to talk business before talking about the solution and to ask yourself the right questions:
- What are the existing processes?
- Which ones are working and should be kept?
- What are the target processes to integrate or optimize in the new platform?
- What are the pain points? What are the redundant tasks?
- Or simply: how do we want to work tomorrow?
The questions are countless and can become particularly complex in organizations comprising several sites, several business units and/or several businesses.
Recently, we carried out a Source to Pay solution deployment project based on a core model and a deployment on 34 international entities. Even though we received very precise specifications on what was expected, we carried out a framing phase with the client. In this case, the objective was to standardize the purchasing policy and harmonize the approval processes.
Finally, we must not forget that these digitization projects go hand in hand with a global transformation of organizations. Anticipation and measurement of impacts on human resources and organizations must be taken into account as early as the preparation phase.
Therefore, change management is obviously essential, but more broadly the target operating model must be defined in parallel with the processes.