ERP implementation is often treated as a technology project. In practice, the software is only one part of what determines whether a rollout succeeds.

In Part 1: Selecting an ERP while your business processes are still being defined, Fabian Schiltknecht,COO and Partner at Lowgile, explained how the client selected its ERP while still defining its business processes and requirements. Implementation began in January 2025, but the project followed an unusual setup: the client worked directly with the ERP vendor, without a separate system integrator or implementation partner.

In this second part, Fabian explains how the implementation team was structured, how workshops were used to design the future processes, and what it took to roll out the core ERP across an international organization within six months.

‍

1. What was unusual about the implementation setup?

The client worked directly with the ERP vendor rather than using a separate implementation partner or system integrator.

That had clear advantages. It removed an extra layer of cost and communication because the people configuring the system were also the people who knew the product in detail.

However, without a traditional implementation partner, someone still had to own those responsibilities, including coordinating process design, managing priorities, driving decisions, and keeping the different workstreams aligned.

The original intention was for the client to manage most of this internally. Once it became clear that the internal team could not run the implementation alongside its day-to-day operations, Lowgile took on the project management and coordination role.

2. How did you structure the implementation team?

Getting the right team structure in place was critical to making the implementation work.

The client appointed a dedicated project manager responsible for day-to-day execution, rather than relying solely on a senior sponsor who checked in periodically.

Two Lowgile consultants worked on the project full-time. In our experience, a small team working full-time can be more effective than a larger group contributing only a fraction of their time, because they retain context and maintain continuity throughout the project.

When we needed additional expertise, we brought in module specialists for specific topics rather than keeping them involved full-time.

The parent company was also engaged early in the process, with representatives from implementation, IT security, legal, and the finance team responsible for consolidation.

3. How did you establish clear responsibilities between the client, vendor, and Lowgile?

One of the most important early conversations was defining Lowgile’s role. We clarified responsibilities with both the client and the vendor so that each party understood what it was responsible for from the outset. Without that clarity, coordination, prioritization, escalation, and decision-making could easily become ambiguous.

Lowgile’s role was to manage and coordinate the project across the client and vendor teams while keeping stakeholders and workstreams aligned.

‍

4. How did you use workshops to design the future processes?

We used workshops to design the future business processes, with one session dedicated to each topic.
Before each workshop, we reviewed and documented the existing process to establish a clear baseline for the discussion.

During the session, we focused on three questions:

·        What does the process need to achieve?

·        How should the process work going forward?

·        How much of it can be supported by the ERP’s standard functionality?

In most cases, around 80-90% of the process could be handled using standard functionality.

The most important discussions therefore focused on the remaining 10-20%, where we had to decide whether to change the process or to adapt the system to accommodate a genuine business exception.

5. How did you decide whether to adapt the process or the system?

The key was distinguishing genuine business requirements from ways of

working that had simply evolved over time.

If the ERP’s standard functionality could support the required outcome,it generally made more sense to adapt the process than to customize the system.The more detailed discussions focused on areas where standard functionality didnot fully meet the client’s needs.

Accounts payable and accounts receivable were typical examples. Most of theexisting process mapped cleanly onto standard ERP flows, while a small numberof exceptions required closer consideration.

Those exceptions were where the real design work happened: Should the business process change, or did the system need to accommodate a genuine requirement?

Once these decisions were made, the vendor could configure the system while Lowgile coordinated the process and kept the different workstreams aligned.

6. How did you structure the rollout across functions and countries?

The rollout was divided into two functional phases.

The first covered the core ERP and mandatory modules, forming the foundation for everything that followed.

The second phase covered the business-specific modules that reflected how the company operated within its industry.

At the same time, the rollout spanned more than ten countries. In several markets, implementing the ERP was not actually the first step. Legal entities had to be established and assets transferred before the system could be rolled out.

As a result, the ERP rollout was closely tied to the wider process of building the organization. In some countries, the rollout depended as much on corporate and operational readiness as the software itself.

7. Why did you start with a smaller-scale go-live?

We began with one country, a reduced scope, and real transactions. That allowed us to see how the system and processes performed in a production environment before rolling it out more widely.

Any issues we identified during the first go-live were easier and less costly to fix before they were replicated across several countries.

‍

8. What role did user acceptance testing play before go-live?

Lowgile led the User Acceptance Testing (UAT) process. We collected and prioritized issues, then decided which had to be resolved before go-live and which could wait.

The mechanics were straightforward. The hard part was staying disciplined about prioritization.

By the time UAT begins, teams have already invested significant time and effort in the project, and they may tend to treat all outstanding issues as equally urgent. Someone needs to make clear decisions about what genuinely blocks go-live and what can wait.

Without this discipline, projects can easily lose weeks during the final stages.

9. How much of the implementation involved organizational change rather than technology?

A significant part of the project had very little to do with software configuration.

The client was still a young organization, moving from a startup-style setup toward a more established company with defined processes, stable operations, and clearer responsibilities.

An ERP implementation accelerates that transition because the system forces decisions that organizations can otherwise defer.

Who owns a particular process? What is the actual approval chain? If two teams use different methods, which one becomes the standard?

Those are organizational questions rather than technical ones, and they can be sensitive. Treating those questions as purely technical decisions only makes the implementation harder.

Change management and cultural issues therefore had to be addressed alongside the technical work.

10. How did you prepare the organization to operate the ERP without the project team?

Documentation and training were central to the handover.

The vendor provided good system documentation, but it explained the system itself. The client also needed a second layer that documented how its own processes integrated with the system: how the configuration behaved, which exceptions existed, and why key decisions were made.

For training, we used a train-the-trainer approach rather than training every user centrally. Internal trainers could then pass that knowledge onto their teams and continue doing so after the implementation team stepped back.

The objective was not simply to complete the rollout. It was to handover responsibility gradually until the organization could operate the system independently.

‍

Conclusion

This project showed that working without a traditional implementation partner does not eliminate the surrounding work. Project coordination, decision-making, stakeholder management, vendor alignment, and budget control still need clear ownership.

It also reinforced the importance of building the right implementation team. External support is not necessarily valuable because outsiders know more about the business. Its value can come from having people who work across departmental boundaries, stay focused on the project, and ask questions that may be harder to raise internally.

The core ERP went live six months after implementation began. The second phase, covering the business-specific functionality, followed soon afterward.

More importantly, we gradually handed over responsibility so that, by the time Lowgile stepped back, the organization could operate without depending on the project team.
‍

Let’s talk. If you are preparing for an ERP implementation or need additional capacity tomanage a complex rollout, we can help you structure the project, coordinate vendors and stakeholders, and support the transition into stable operations.

‍

 
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.

‍