ERP specifications and proofs of concept – getting the best of both worlds

Post initially published on June 28, 2018, then updated on February 14, 2020 In these days of business digitalization, the pressure on information systems and their component applications has never been so intense. Senior management and IT departments are constantly trying to adapt to developments in their ecosystem, and this quickly affects operational processes. This being so, choosing an ERP system that will take charge of all operations in an integrated way is an extremely attractive option, so care must be taken with the selection process, in particular the traditional stage of producing specifications before the ERP benchmarking as such. It certainly would be a high-risk approach to make a decision based on flashy demonstrations rather than on a diligent confirmation of the chosen solution’s ability to fit with the company’s business models in order to effectively support its development strategy. To this end, producing an ERP specification often appears vital, but is the time it takes always compatible with senior management’s requirements in terms of speed and agility for the project? IT departments and senior management tend to agree that quick wins are the preferred approach in modern business. Producing an impeccable specification taking several months is pointless when requirements can easily change over the course of those same few months, and economic environments are volatile, to say the least. The idea of “proof of concept” (PoC) consequently seems a more innovative approach than an ERP spec, but what does one actually entail? How can the specification stage be made more agile?

Clearly determine the direction of travel for the business before the ERP specification:

Implementing ERP is an opportunity to bring users together around integrated operational processes, and it can become highly influential over the corporate culture. Involving the business departments in producing specifications is therefore essential, but our experience in ERP project implementation shows us that the traditional approach of listing the required functionalities by grouping them by management areas is inadequate, or even downright unsuitable in view of the speed and agility demanded by senior management… ERP specifications need to take on a new format, one that takes a step back to drive a more strategic view based on requirements expressed by business departments. These business departments must, of course, communicate their strategy directions, their target areas for improvement and the necessary organizational changes, but with the aim of pinpointing the real challenges and objectives related to the ERP implementation. A successful ERP project is driven by the functional areas and is managed to meet strategic objectives.

ERP specifications and functional coverage

While collecting functional requirements is important to ensure the project is run on the basis of the challenges to be met, an ERP specification means it is still possible to assess differences in functional coverage when different solutions are compared, and it encourages the adoption of objective and relevant selection criteria. This is why the quest for agility should not rule out formal recording of functional requirements, just not necessarily as has always been done in specifications. A more groundbreaking approach could bring benefits, as we are about to see… In its search for an ERP solution, the core of its information system, a business must use a business-oriented approach and favor solutions that are designed for its particular industry. This is why the key macro-processes should be reviewed focusing on their special features, and given a clear description in the specification. Ideally, the desired functionalities should be organized by key processes, stating the expected benefits, rather than as a list of requirements, which often falls into the trap of resembling a wish list. This avoids businesses and integrators having to work on ERP specifications where it is difficult to distinguish between functionalities linked to genuine strategic objectives and those resulting from subjective demands, along with all the risks that this entails in terms of identifying bespoke developments that might be necessary, and anticipating the associated costs to avoid unpleasant financial surprises along the way.

The advantages of a PoC (Proof of Concept)

As mentioned earlier, senior management now tend to favor more agile approaches to shorten ERP project lead times. As a result, the idea of proof of concept (PoC) is gradually playing a larger role in choosing a solution. While a specification can serve to give structure to the selection process, a PoC confirms the ability of the business and the integrator partner to successfully complete the project together. Based on a checklist of essential requirements and the main objectives set for the ERP project, the integrator can conduct a preliminary study and begin to model it. The ability of the business to test the water in this way makes for more effective buy-in and more appropriate selection than if it had to wait for the specifications to be finished. Proof of concept essentially consists of building a “model” using the business’ actual data, so that product demonstrations are closer to reality, being based as they are on the firm’s key processes and real data. This reassures the business managers involved in solution selection, as they can better compare ERP systems and better assess how end-users will use them… Obviously, producing a PoC takes time and effort, both for the business and the integrator. It is consequently unreasonable to think about producing one for all the ERP systems being considered, so it is preferable to arrange for a run-off between two shortlisted bidders to compare them in detail. Equally obviously, if the ERP specification already presents functionalities on the basis of key processes and if sample data sets have already been prepared, producing a PoC will be a great deal easier. As an expert integrator of Microsoft Dynamics 365 ERP and SAP S/4HANA, we regularly produce proofs of concept between these two particular solutions as they are often the final two in ERP competitive tendering procedures.

ERP specifications must also include the financial aspects: TCO and ROI

While using proof of concept ensures ERP product demonstrations are more practical for business departments, the costs still have to be evaluated.

Determining the total cost of ownership for an ERP project

As regards evaluating the costs of different ERP solutions, the ideal approach is to assess the total cost of ownership (TCO), taking a depreciation period of 8 to 10 years, reflecting the actual lifespan of a corporate ERP system.

Determining the expected benefits and the return on investment

Determining the benefits and the return on investment (ROI) expected from the project are decisive factors in a comprehensive financial evaluation. The aim of investing in an ERP project is that it supports the development of the business and strengthens its capacity to bring about significant improvements and generate competitive advantages. To this end, the specification or the PoC has to identify the processes that will be directly affected by the implementation of the new ERP system, and the benefits it is intended to achieve need to be evaluated:

• Quantitative benefits: greater reliability in production times, shorter order cycles and delivery lead times, faster processing of customer complaints, improved forecasting including visibility over stocks for example, reduced IT running costs, etc.
• Qualitative benefits: shorter time taken to make operational decisions, increased customer satisfaction, SLAs met, faster financial month-end processing, improved employee productivity, etc.

To sum up: ERP specifications and proof of concept are both vital

In these days of cloud-based ERP systems and the continuous quest for more agility, it is more important than ever to adopt an innovative approach to selecting ERP software. By producing an ERP specification that anticipates a proof of concept run-off between two shortlisted products, you are guaranteed to get your ERP project off to a great start… Including both a specification step and a PoC step should not inevitably make the project lengthy. This is why we suggest the TVH Consulting ERP benchmarking of Microsoft Dynamics 365 and SAP S/4HANA ERP systems to save you time and reduce the main risks involved in selection, by using a facts-based comparison of aspects such as functional fit, operational suitability, technical suitability, implementation and roll-out strategy, internal and external teams and workloads, change management effort, TCO and ROI targets, etc.