5S Approach - Software & Supplier Selection through Strategy Translation and Scenario Thinking

In the bestseller "Does a CEO visit the IT doctor", Wolter Toet warns about the pitfalls when selecting and implementing new business software. The biggest danger is that you take your existing business processes, old habits and ingrained requirements and wishes as the starting point for the future situation. Sin! After all, the possibility of creating a new IT landscape and flexible processes greenfield offers plenty of opportunities.

Michel Hoeijmans, Principal Consultant at Improven, points out that a good ''fit'' between strategy, information provision, process and IT is crucial. And this is where you can be well prepared.

"Over the past three years, I have seen a shift to the cloud among the clients I supervise. The cloud is hip. However, vendor requirements for cloud-based ERP software are totally different from those of on premise. The demand for customisation is also decreasing," Hoeijmans said.

It is also palpable and observable that the number of ERP vendors is declining and congregating around a few major players in the market. And yet this market is still significant. What should you pay attention to when you, voluntarily or compulsorily, switch to a new, robust and future-proof ERP environment that is also well connected to the rest of your IT landscape? Michel Hoeijmans shares his experience with a pragmatic selection approach.

5S approach 'Software & Supplier Selection through Strategy Translation and Scenario Thinking

"In 2015, we started using the 5S approach 'Software & Supplier Selection through Strategy Translation and Scenario Thinking'. We have sharpened this method considerably in recent years, prompted by trends such as Cloud, Agile, standardisation and low and no code solutions.

We always start first with a feasibility study on the business case. We measure how attainable the requested improvements and savings are and whether the selection actually achieves these objectives. If the outcome is positive, we proceed to step 2: the strategy session. However, it often happens that we first go back to the drawing board with the client and adjust the business case.In the strategy sessions, one or more interactive workshops, we use the Business Model Canvas (BMC) to identify the right strategic, IT and IV principles and processes. We then group the desired processes, functions and roles creatively and sharply. This creates insight into the required functionality, which we translate into desired requirements - which we look for in one or more standard packages. On this basis, we work out a number of application replacement scenarios

We write out the processes from the BMC together with the customer in the form of Use cases. Naturally, we work out the chosen scenario here, with the customer's dream scenario (the ideal process) in mind. The use cases describe the most important sub-processes, activities and system requirements, which we further supplement with our best practices from the market.

Once we have identified and described all use cases, we look in the market to see which vendors and software best suit the organisation, in terms of size, culture, price, etc. In an RFP (request for proposal), we ask selected vendors to prepare a Use Case Demonstration. In this section, we address the 'what' question. The supplier demonstrates how it solves the customer requirement in practice within its software. During the demo but also in the assessment of the request for proposal, we test on the basis of a standards framework. This consists of measuring the Organisational Fit. During the selection process, we also take into account any bottlenecks that may occur in a process. Essential in the choice of a package will be the extent to which the management of your organisation and the expected (market) developments can be supported with the package. We describe this in a fit-gap analysis.

What should you pay attention to?

On average, you replace an ERP system once every ten years. So it needs to be good now, but you also want to be able to accommodate future organisational developments in it. We test and describe the supplier and software on the following aspects:

• Process Fit how well the software supports the desired processes
• User Fit Is it a system that users can and want to work with?
• Data Fit Can the system support all required data?
• Technical Fit Is the system easy to fit into your IT architecture? Does the system interface easily with other applications?
• Strategic Fit How well are your strategic objectives supported and does the system support the business case?
• Vendor Fit Does the method and supplier suit you?
• Price Fit Does the system fit within the pre-established budget from the business case?

After the initial selection, we determine whether it is useful and desirable to organise a 'deep dive' with the preferred vendor on a few processes. This often creates more insight into the software itself and its effect on the processes.

Software selection does not stop with the choice. It only stops, the moment a contract is concluded and the supplier's proposed implementation plan is approved. Ask your supplier to draw up a thorough plan of action in advance! How do they expect to set up the system, given their own commitment but also the commitment of your organisation. Also have them describe how they expect to successfully implement the system. Formally record these agreements during the contract phase and weigh the implementation plan in the selection.

Consider ERP package selection as a project

Consider selecting an ERP System as a project and set up a formal project organisation for this purpose. After all, buying a package alone won't get you there! Consider, for instance, the implementation of the package (the costs of which can be even higher than the purchase price) and the impact of the system on the rest of the organisation. Therefore, implement and select with management in sight. This can be done by involving the management organisation and key users in the project at an early stage and having them actively participate in drawing up the Use Cases. Pay sufficient attention to describing the non-functional requirements so that the desired ERP system matches the current and future ICT policy.

In conclusion. Replacing an ERP system is not just an IT matter but primarily a project that requires the support and staffing from the business."