Selecting an ERP is often presented as a linear process: define the business processes, translate them into requirements, evaluate vendors, and select the system that fits best. In practice, however, companies do not always have that luxury.

For the client, a newly formed company, ERP selection had to begin while its processes and requirements were still being defined. The operational model was understood, but many of the processes had not yet been finalized.

Fabian Schiltknecht, COO and Partner at Lowgile, supported the client through the ERP selection, vendor evaluation, contract negotiation, and preparation for implementation.

In this first part, he explains how the project was structured when neither the requirements nor the future operating processes were fully defined, from initial requirements through vendor evaluation and preparation for implementation.

1. What made this ERP selection more complex than usual?

The main challenge was that the client did not yet know exactly what it needed from the ERP and how a fully functional system could support their business processes. The company had a clear idea of how the operational side of the business should work, but the underlying business processes were still being defined. At the same time, the ERP selection could not simply be postponed until every process question had been resolved.

As a result, requirements definition and system evaluation had to run in parallel. There were still many open questions when we had to start assessing possible solutions.

Our role, therefore, was not only to compare ERP systems. We also had to actively guide the client in understanding what the future system needed to support.

2. How did you define requirements when the business processes were still evolving?

We started by creating a high-level overview of business requirements.

At that stage, the goal was not to produce a detailed specification. Instead, we focused on identifying the most critical requirements: the minimum set needed to evaluate the available ERP systems in a meaningful way.

We developed this initial view through interviews with the CEO and the Finance team.

As the evaluation progressed, we refined and expanded several of the requirements. However, we deliberately avoided going into too much detail too early, because we also wanted to understand how ERP vendors would address the client’s needs and what established practices their systems already supported.

3. Why did you deliberately avoid defining every requirement in detail?

The client was interested in the best practices already embedded in the ERP systems.

For that reason, we did not want to define every process in detail upfront and then expect the selected ERP to replicate them exactly. The client was open to adapting its future processes to the system where appropriate.

That distinction mattered because, if every workflow had been fully designed before assessing the available systems, the client could have limited its ability to leverage established functionality and practices already supported by the ERP.

The requirements therefore needed to be detailed enough to enable a structured evaluation, while leaving room for the business processes to evolve as the client gained a better understanding of the available solutions.

4. Why was industry-specific functionality such an important part of the ERP evaluation?

The client operated in a niche, asset-heavy sector, so the ERP needed to support more than standard accounting requirements. Contract management and the asset ledger had to interact closely.

This relationship between the operational and financial sides of the business made the evaluation more complex. A system could not simply perform well as a conventional finance ERP; it also had to support the client’s specific operational requirements.

For that reason, the market scan focused on ERP solutions offering relevant industry-specific functionality.

5. Did you consider more than one system architecture?

Yes. There were two possible approaches.

The first was a two-tool strategy. Under this model, the client would use a classic ERP for its core functionality and a separate specialist system for industry-specific requirements. The two solutions would then need to be connected through an integration layer.

The second option was an all-in-one approach, in which a single ERP provided the required industry-specific functionality natively.

The two-tool approach could address the specialist requirements through a dedicated application, but it also introduced greater architectural complexity because of the required integration between systems.

The all-in-one approach reduced that complexity, but it depended on finding an ERP that could support the required industry-specific functionality within a single system.

Both options needed to be assessed as part of the wider evaluation.

6. How did you narrow the ERP market down to the final candidates?

We started with a broad vendor landscape, including the ERP already in use at the client's parent company. Given the group context, that solution was a natural candidate, and we reviewed it in detail against the new organization's requirements before concluding it was not the best fit for the subsidiary. The list was then reduced through several evaluation stages.

There were two internal evaluation rounds. We assessed the vendors against both functional and non-functional criteria, while also looking at factors such as vendor size and the complexity of the proposed solution.

Following the internal evaluation rounds, four vendors were selected for more detailed workshops and demonstrations.

7. What did the detailed vendor workshops involve?

The workshops brought together a broad group of stakeholders from the client side. Participants included finance professionals, industry experts, the CEO, the deputy CEO, and the legal team.

That was important because the ERP decision affected different parts of the organization and could not be evaluated from a single perspective.

After each workshop, we collected structured feedback. This gave us a consistent basis for comparing the vendors rather than relying only on individual impressions. Based on that evaluation, two of the four vendors were selected for additional workshops.

8. What happened once the field had been reduced to two vendors?

The next evaluation round took approximately two to three weeks.

At that point, the assessment went beyond the functionality demonstrated in the vendor workshops to include more detailed discussions on costs and implementation planning.

This was important because selecting an ERP is not only about identifying whether a system can meet business requirements. We also needed to understand what implementation would involve, how the project would be structured, and what the wider delivery implications would be.

9. How involved was Lowgile in the commercial and legal negotiations?

We supported the client throughout both commercial and legal negotiations by working directly with the vendor and coordinating with the client’s legal department on matters such as licensing and module selection.

The negotiation process took at least three months, making it a significant part of the overall ERP selection process.

Selecting a preferred vendor was therefore only one step toward implementation; the commercial and legal details still had to be finalized before the project could move forward.

10. How did you prepare the project for implementation once the vendor had been selected?

Once the vendor had been selected, the focus shifted to setting up implementation teams on both sides.

We defined the project governance structure across the client and Lowgile teams, clarified roles and responsibilities, and identified where additional hiring was required.

Once the project team was in place, we started joint workshops with the vendor to align requirements and functional areas. The vendor also needed a structured approach to working through the requirements before implementation began.

Conclusion

This project shows that ERP selection does not always begin with a fully defined process landscape and a complete set of requirements. In this case, the selection process had to develop alongside the business processes themselves.

By the time the project was ready to move to the implementation phase, the client had progressed from a broad set of open questions to a selected vendor, a defined project team, and a clearer understanding of the requirements the new system needed to support.

Part 2 will look at what happened once the project moved from ERP selection into implementation.

Let’s talk. If you are evaluating ERP options or defining the requirements for a future system, we can help you structure the process, assess the available solutions, and prepare for implementation.

About Fabian Schiltknecht:

Fabian Schiltknecht is COO and Partner at Lowgile.

He has more than a decade of experience leading complex client delivery programs and has previously worked in professional services, IT project management, and application management.

‍

‍