In this article, we present the opposite of the “best practices” to illustrate what one should not do or assume when approaching a Source-to-Pay digital transformation project. These anti-tips are the fruit of 17 years of experience of implementing Source-to-Pay solutions.
Anti-Tip # 1: Preparing your data is a waste of time
The quality of supplier data has little impact on the success of Source to Pay projects and on the optimal use of deployed solutions. Before one starts, it is not necessary to check that the supplier data is reliable and usable, or to plan a clean-up and an enrichment phase of the supplier database. One will have plenty of time to make corrections on the fly when reconciliation problems between orders and invoices begin to occur… In summary, why do things well from the beginning when one can correct everything later, even if it costs a lot more in time and effort?
Anti-Tip # 2: One can sit back and relax, the integrator will take care of everything
Once the supplier and Source-to-pay solution are chosen, the mission is over. At this time, the integrator takes charge of the project and will pilot it. Intervention or input from the buyer organization will not be needed. Therefore, there is no need to organize exploratory workshops with all stakeholders and identify the strategic axes and preliminary actions to be carried out, such as the definition of the target processes.
Our (anti) advice: do not waste time! Start without studying the operation modes and the needs of each team. Users will have plenty of time to communicate their change requests after the solution is implemented. And in the end, the effort and the cost of required corrections will simply be astronomical, so what?
Anti-Tip # 3: Do not think about changing the purchasing process, the existing one still suits the needs. It has been in place for many years so why try to improve it?
The best approach is to replicate processes that one manages manually and in multiple applications. Thus, one will view the data exactly as in the Excel files. No change! This eliminates the need to adjust existing processes, or to create new ones, such as updating the vendor repository. Seeing data on a spreadsheet is more than enough. No one needs all the features of a Source to Pay solution, such as managing catalogs or tenders. Better keep our old habits even though they are inefficient, don’t you think?
Anti-Tip # 4: Do not hesitate to ask for specific developments
From experience, our (anti) advice is to make maximum use of specific or custom developments. This will allow to tailor the application to one’s particular needs and to exactly replicate the existing processes. Even if adding these benefits may slow down the project a bit (actually a lot more than one may think), one will be assured of having a truly unique application that will not take advantage of the new features developed by the solution provider.
You have chosen the best platform which already incorporates best practices. But surely all of your existing processes will be much more efficient and refined. In calculating the total cost of ownership (TCO), do not forget to plan an additional budget to redo these developments with each version upgrade of the Source-to-Pay platform.
Anti-Tip # 5: Remember to change your purchase organization during the project
Before you start the project, you simply do not need to think about the revisions on the purchasing department organization, the relevance of the supplier evaluation criteria, the data governance or the choice of KPIs.
One can easily change the organization during the project without any impact on the implementation cost or schedule. The internal teams will certainly be a bit stressed since they now have to manage two projects at the same time, but this will have no impact on the satisfaction or the end-user acceptance of software solution…. (unless it does…)
Anti-Tip # 6: Do not worry about the availability of the project team
Validating the availability of teams before establishing the deployment schedule is not essential. It is also useless to include project-specific tracks in the workload by planning to move or delegate tasks that one can’t manage. The same goes for the IT department. Source to Pay projects are initiated and led by business departments. One will call the IT department when the time comes, especially for the development of the interfaces. Since IT has no other projects underway, it can respond immediately to this request, right?
Anti-Tip # 7: Deploy everything at the same time. Employees love the big bang!
In the vast majority of cases, it is not recommended to break the project into manageable pieces and to start with a simple and well-defined scope, such as the purchase requisition, the SRM module or the management of tenders. Changing everything overnight, adapting to new software, and managing the ongoing daily tasks at the same time is not a problem for you or your users. On the contrary, they embrace the change especially when it is radical and unannounced. Support during deployment (hotline, training, e-learning …) is totally superfluous.
Anti-Tip # 8: Worries are over after the solution is in place
On the day of ’Go-Live’, one can consider the project finished! It is rare to make adjustments or changes after deployment. As one has not prepared the project scope in advance and deployed everything at once without supporting the users, one has to lay aside all expectations of an optimal ROI anyway. Creating a community of users, promoting knowledge exchanges with the key users or setting up data governance are, therefore “worst practices”. Joining in a process of continuous improvement requires too much time and investment for teams who surely have better things to do. There will surely be a time to consider changes in a year or two … (and re-start the whole project with a new approach)