How to Carry Out a 3- to 6-Month Transformation Without Overworking Your Operations Team
A practical guide to change management and digital transformation for B2B service providers in the DACH region who are implementing an IT rollout alongside their ongoing operations
Table of Contents
Most change management guidelines for digital transformation are written with large enterprises in mind: dedicated HR change teams, certified change managers, and the budget for structured adoption programs. A mid-sized B2B service provider operates differently. In a company of this size, the few people who understand the core operational process are usually the same ones who keep it running every day. Asking them to design the new system while simultaneously handling their full workload is the central challenge, and most guides never address this.
This is the structural tension at the heart of every operational transformation in the €10 to 50 million revenue range. For SMEs of this size, the change management challenge is neither cultural resistance nor a leadership issue. It is a problem of capacity planning. The team cannot halt operations to implement the new system, and the system cannot be implemented without the team. (Why internal teams often cannot build a core operational system on their own is a separate question that we address in the guide “In-House Development vs. Agency.”) The following pages describe how a well-structured implementation resolves this contradiction in practice.
Why Operations Teams Burn Out Faster Than Other Departments During an IT Rollout
Every department experiences disruptions during a digital transformation. Operations teams face a unique set of challenges that make burnout more likely than in other departments, for two structural reasons.
First: Operations-focused companies of this size rarely have flexibility in their core processes. They deliberately operate with lean structures, with little redundancy in the roles that keep day-to-day business running, so there is no reserve capacity to accommodate a months-long project on top of their normal workload. The broader context exacerbates this. The Gartner Workforce Change Survey found that, in 2022, the average employee experienced about ten planned organizational changes—up from two in 2016—while the willingness to to embrace change fell from 74 percent to 43 percent over the same period. A transformation doesn’t hit a well-rested team. It hits a team that’s already dealing with more change than it has in years. Harvard Business Review
Second: Operational staff are precisely the people whose knowledge is most urgently needed during implementation. Those who understand how pricing exceptions actually work, which customer agreements override the standard process, and why certain orders are processed manually rather than by the system are both the most valuable source of input for the new design and the most indispensable link keeping the current process running. Filling both roles at the same time is the fastest route to burnout and a common cause of implementation failure in companies of this size.
The three decisions that determine whether the team is exhausted
Before the first workshop is scheduled or a single line of code is written, management must explicitly make three decisions. These are not procedural decisions, but structural commitments that shape everything that follows.
Decision 1: One internal point of contact, not a committee. Every transformation requires a single, named internal point of contact on the client side: not a steering committee, not a project group, and not the operational team as a whole. This person serves as the primary point of contact for the implementation partner, participates in weekly coordination meetings, approves design decisions, and is responsible for internal buy-in. Shared responsibility turns every decision into a coordination task and consumes far more team time than necessary.
Decision 2: This person’s time must be formally protected. Appointing an internal manager while simultaneously leaving them responsible for their full operational workload is not a solution. Management must explicitly remove specific tasks from this person’s scope of work for the duration of the implementation—and do so in a visible way—so that the team recognizes that the company is making a genuine adjustment for the project and is not quietly increasing someone’s workload.
Decision 3: Tests are conducted using real orders, not fictional scenarios. The standard approach is to create hypothetical test cases and run the system against them. This produces reassuring results that fail at the first real exception. Tests must use real order types from day-to-day operations, including the exceptions that occur two to three times a month. Before testing begins, the internal manager defines five to ten order types: standard cases and the most common exceptions. This is a two-hour task that prevents weeks of crisis management after the go-live.
How to Plan the Next 3 to 6 Months: What the Operations Team Does and When
The most harmful pattern in a digital transformation is to fully involve the operations team throughout the entire implementation window. By the time the go-live date arrives, the team is exhausted before the hardest part even begins. The alternative is phased involvement: heavy at the beginning, when knowledge is being gathered; minimal during the build phase; and intense again during testing.
| Phase | Time period | Involvement of the Operations Team |
|---|---|---|
| Strategic Audit and Process Design | Weeks 1 through 4 | Just input. The partner takes the lead. The team provides access and answers questions. No responsibility for the outcome. |
| Build Phase | Weeks 5 through 14 | One person in charge internally. A weekly 1-hour update meeting. No committees. No full-team meetings. |
| Parallel testing with real orders | Weeks 15 through 18 | Limited in duration. 2 to 4 hours per week per tester. Structured scenarios based on real-world assignment types. |
| Phased Go-Live | Starting in Week 19 | One process at a time. A difficult transition with a fallback plan. No long-term parallel operation. |
| Stabilization After Go-Live | Weeks 20 through 28 | The team is fully responsible for the system. Partners are available to address any issues. No new features for at least 6 weeks. |
The core principle: The operations team’s involvement should be greatest at the beginning, when their expertise is incorporated into the design, and again during the testing phase. During the build itself, their involvement should be minimal and time-limited. The people who keep operations running should have no project obligations during this phase beyond the weekly coordination meeting with internal stakeholders.
The "multitasking" trap: the most common cause of exhaustion
The most common single decision that turns a manageable rollout into a nightmare is: “We’ll run both systems in parallel until we trust the new one.” That sounds prudent. In ERP practice, however, it is by far the most resource-intensive migration model, and its characteristic burdens are well documented: Operating both systems simultaneously means double data entry and the resulting employee burnout. Xserpconsulting
In practice, this means that the team processes each order twice. The experienced scheduler enters an order into the old system because he trusts it, and then enters it again into the new system because he was asked to. Those who process quotes first enter the information into the spreadsheet, then re-enter it into the new system. Within two weeks, this dual-system operation has effectively doubled the workload of the people who are already shouldering the heaviest burden.
Let’s take a typical example. A B2B service provider runs its old quoting process and a new quoting system in parallel for several weeks after the go-live, “until everyone is confident.” The most experienced scheduling manager—who is already the busiest person on the team—is now doing the work twice. Under this burden, the realistic risk isn’t a system failure, but rather her resignation—and the knowledge that leaves with her is precisely what the project was built upon. This is not a far-fetched scenario: ERP best practices repeatedly point to duplicate data entry, employee burnout, and the loss of a key person in the middle of the project as typical failure patterns associated with prolonged parallel operations, which is why phased approaches deliberately shorten the time window during which a single person is overburdened. XserpconsultingTechTarget
The alternative is a hard switchover with a specific fallback plan. On go-live day, the new system goes live. If it cannot handle a specific order type, only that order type temporarily reverts to the old process; the problem is logged and resolved, and everything else remains live. Suppose the new system cannot yet handle a single special case on the first day. That one type runs through the old process for one to two days, is resolved, and the rest of operations never reverts. Instead of weeks of parallel operation across all orders, you have one to two days of exception handling for a single order. This approach is more burdensome in the first 72 hours but significantly less so in the weeks that follow.
How to Tell Before You Start Whether Your Team Can Support the Transformation
Before you set a date for the first workshop, check for three indicators. They will tell you whether the team can handle the additional workload at all, or whether you need to free up capacity first.
First: Is there a documented backup plan for the key role in the process—usually planning or procurement? If the process exists only in the mind of a single person, that person is doubly burdened during implementation, and the project is at risk from the very beginning.
Second: Does this person already regularly work beyond their regular working hours? A team without a buffer cannot take on additional tasks such as knowledge documentation and testing without compromising the quality of ongoing operations.
Third: Are exceptions, special prices, and customer agreements currently handled based on verbal instructions and experience rather than documented rules? This is precisely the knowledge the new system must incorporate, and these are precisely the people who are the hardest to free up.
If all three indicate a heavy workload, the first step is not to launch the project, but to relieve the internal person in charge of some of their workload. In practice, this means appointing a substitute who will take over the person in charge’s routine tasks for the duration of the project—such as daily scheduling or approving quotes—not permanently, but only for the implementation window. This redistribution of tasks requires capacity in the short term, which is precisely why it is a decision for management—not the team. Only then does the transformation begin.
What to do now
If you are planning an operational transformation alongside ongoing operations, start by making these three decisions: appoint a specific internal person to be in charge, set aside formally protected time for that person, and conduct tests using real orders rather than fictional scenarios. Sequence the operations team’s involvement so that it is high at the beginning and during the testing phase, and minimal during the build. And avoid the parallel operation trap: A hard switchover with a clear fallback plan places a heavier burden on the team during the first 72 hours but significantly less in the weeks that follow.
Whether the investment will pay off at all is a separate question, and it should be addressed before the rollout, not during it. In our guide to the ROI of custom software, we explain how to build a solid business case based on your own operational data before a partner writes a single line of code.
If you want this clarity before getting started: The appleute Strategic Audit maps your operational processes, identifies where costs are concentrated, and provides a “current state” cost figure along with a scope definition and a payback estimate. A fixed-price, standalone engagement that delivers a document you can present to your CFO or executive team with confidence. If the numbers don’t support the investment, we’ll tell you that, too.
Arrange a free, no-obligation consultation with our team.
Arrange a free, no-obligation consultation with our team.
EN 
DE 
FR 
ES