Bringing staff along with new workflows: a rollout plan

A new system rarely changes only the screen layout. It changes who learns what and when, who approves things, in which order work happens and how someone knows a case is finished. The old workflow had settled over years and contained rules written down nowhere: which order jumps the queue despite the list, which customer gets a call before delivery, which figure is worth checking twice because experience says it causes trouble. Introduce a new workflow without knowing those unwritten rules and you do not get a better process, you get a second process alongside the old one — with the team deciding case by case which of the two to follow.

The second reason is time. A changeover falls into day-to-day operations; the orders do not shrink because a system changes. Planning a rollout without released hours pushes learning into the margins of the day, where a backlog is already being cleared. Surveys by Bitkom and the German Chambers of Commerce (DIHK) regularly name lack of time and lack of staff among the obstacles to digitisation in mid-size companies — in daily practice it shows up exactly here: the technology is in place, the hours for relearning are not. That is a planning error, not a motivation problem.

The third reason is where the design came from. A workflow drawn up in a meeting and announced afterwards carries the perspective of people who do not perform it. A workflow designed without the people who run it will not be carried by them — not out of defiance, but because it fails in places that cannot be seen from a distance. That is why involvement belongs at the start of a project and not in the training week shortly before go-live.

A key person is the place in the company colleagues turn to with a question without it becoming a formal case. They know the new workflow earlier than others, but above all they know the old one from their own work. That rarely makes the manager or the person who looks after the systems a good fit; it points to someone who performs the case daily and whom the team listens to. Two people per converted workflow have proven workable (project experience) — a single one drops out through holiday or illness, and the role should not turn go-live into a single point of failure.

For the role to hold, it needs equipment. That means access to the new system ahead of everyone else so real cases can be walked through in advance, a fixed time budget in the roster for the first weeks, a short line to the people building the solution without several layers in between, and the explicit right to postpone go-live when a workflow visibly does not run through. Naming the role without those four things hands out a title rather than creating a function.

Two mistakes are common. The first: the role is assigned without asking first. Someone who does not want it will not fill it, and the team notices within days. The second: the key person becomes a complaints desk. They collect frustration but have no way to change anything. Both are avoidable by offering the role rather than ordering it, and by making sure questions demonstrably lead to changes — including small, visible ones.

Between the last day of the old path and the first routine day of the new one lies a phase in which both apply at once. That phase needs an end date. A parallel run without a fixed cut-off is not a safety net but double work with two data sets that drift apart; after a few weeks nobody knows which one counts. Two to four weeks are sufficient in most cases (project experience), and the date is set before go-live — not as a threat but as a planning figure for everyone.

During this time a short fixed round helps: ten minutes each morning going through the previous day questions and irregularities. It replaces the round-robin email nobody reads and makes visible whether the number of open points is falling. The tone matters: mistakes in this phase point to gaps in the workflow, not to incompetence. Measuring individual processing times during the transition produces clean figures and no more feedback.

The sequence can be steered too. Starting with one team, one branch or one order type is almost always better than starting with everyone at once: the volume of simultaneous questions stays manageable, the key people remain reachable, and the second group benefits from an already corrected quick guide. The price is a longer overall duration and a period in which two paths exist side by side — usually the better trade.

The weeks after go-live decide whether the new path becomes routine. The most important building block is mundane: questions need an address. A named mailbox, a shared number or a short entry in a common list — combined with a committed response time, for instance by the next working day. Without an address, questions land with whoever is nearby, get answered differently each time and create the second version of the truth the project set out to abolish.

Questions should be logged and roughly classified: handling, subject rule, access rights, filing. That classification takes seconds and after four weeks gives a picture of where the workflow has not settled yet. When the same question comes up repeatedly it is not a handling error but a gap in the workflow or the quick guide. A simple log is enough for this; it needs to be neither a tool nor a report.

After roughly four weeks comes a short review with the key people: which points are closed, which remain open, which change to the workflow is needed? Agreed changes get a date, and the quick guide is updated in the same place. Whatever runs permanently after that — incident handling, updates, small adjustments — belongs in structured IT operations rather than in the remaining time of a project phase.

The larger share of a successful rollout sits with the company, not with the technology. Dates, responsibilities and example cases can all be prepared before the build starts. A company arriving with three real cases per workflow, two named key people and an end date for the old path starts under considerably better conditions than one clarifying those points during changeover week. None of it requires outside support.

An honest choice of date helps just as much. Stocktaking, year-end closing, a seasonal peak or a week short on staff are poor moments to start, however well prepared the project is. Postponing by two weeks costs little; starting during the peak costs trust that is hard to win back later. Where an automation affects several areas at once, it is worth asking additionally which area should go first.