Every 10 years or so companies need to reconsider their supply chain planning tool investments. The need to reconsider may be fueled by evolving customer demand, or the desire to get the latest features or because of increased focus on supply chain operations from executives. Whatever the reason, when you do consider new tools, here are the four things you should and should not do in a supply chain software selection. Selecting the correct vendor and software is crucial in driving efficiency within your company and staying healthy.
Incorporate the selection steps into a broader change management process. Too often clients will use a small, disconnected team to select and neglect the change management possibilities. Typically, we see a core team with representatives from the impacted domains, IT, and sometimes finance. That core team should also represent the different business units and/or geographies. However, when it gets to reviewing vendor demonstrations, why not invite all the stakeholders? Get as many constituents as possible to see the results. Also, progress reports should be shared broadly.
Put too much weight on the vendor’s pricing in early rounds of discovery. If a price is not requested during an RFP round, the software vendors will not believe you are serious. However, we caution against putting too much weight on the price responses. A component of any pricing endeavor is an amount of risk, in an RFP round most vendors will not know enough about your supply chain to reduce the risk, and hence cut the price. You are looking for a long-term relationship, and like a lasting relationship some understanding will go a long way to achieving the best for all parties.
Use a comprehensive scoring device to make the decision. Too often companies begin a software search but lack a decision support tool to focus on for the outcome. We recommend a transparent scoring mechanism that can be shared to assist with communication of results and outcomes. Moreover, the scorecards show how the communities are impacting the outcomes – their voices are being heard. Finally, if some constituent communities have outcome agendas, using this technique dulls the impact of a loud or fractious stakeholder.
Under communicate with your vendors. Too often clear communication between the vendors and the client is choked off, and both parties are at fault. When the vendors are speaking with potential buyers, they are always selling which can become annoying and off-putting. The buyers often turn over the interface of communication to a procurement resource who doesn’t know the subtleties of the supply chain issues and may boil the interaction down to a simple best price transaction. A lack of communication injures the selection process and subsequently the transformation. At IBP2, we learn your supply chain needs and translate them into aspects that are important for the software vendor to understand. And the communication is regular which keeps the vendor interested and subsequently, their desire to negotiate greater.
Drive the demonstrations phase by providing differentiated use cases for each vendor. Too often companies allow vendors to just “show you demand planning” rather than show how they can resolve an existing supply chain issue. Any vendor worth their salt can do a best-fit forecast, so let’s not spend time reviewing it. Moreover, vendors will learn more about your needs during this phase. For instance, many vendors now have multiple software options to resolve similar problems. Rather than dictating which software you need from their catalog, the use cases can dictate in far more texture than a functional requirement list.
Allow IT to run the selection process. The most important aspects for a selection are the current and future functions of the supply chain software. Most (not all) integration issues have been resolved over the last two decades. So, the need to have IT drive a selection has greatly reduced. For long term sustainable transformation, find the features, functions, and usability you need first. IT needs to be involved in the selection, and they should have a level of input, but they shouldn’t be able to champion one software over another against the business.
Use the RFP as a mechanism to explain the problem clearly. RFPs are a great tool to explain the nature of the problem to be resolved, its scale and scope. We also ask vendors for industry relevant reference (only company names) and then for miscellaneous responses. Because the request is aiming towards a 10+ year commitment between both parties, we request information that allows us to gauge the level of interest the software vendor has in the business.
Request reference check contacts too early in the process. In the RFP, we typically request reference companies, but not names or contact information. This is way too early in the process for reference checks. It is way to early for a couple of reasons – first, before speaking with a reference you should know much more about the vendor, and second, items you believe are important to you may not be to the vendor. Finally, how open would you be to being a reference for a software vendor every time they are in an RFP cycle?
When you are ready to begin this journey, consider using IBP2 as your partner. We will run the search efficiently and effectively, but most importantly the investment in us will typically have over 500% ROI in five years.
Comentarios