A change request — also called RFC — is a documented request to modify an agreed deliverable or system state. Mandatory fields, per the IT Process Wiki RFC checklist, are at minimum requester, date, reference to the service or product, justification, impact and risk analysis, resource requirements, roll-back plan, and approval status.
We have seen in over 50 projects with DACH Mittelstand companies that 60 employees in a typical 200-person business are affected by a single change request — a scale that ITIL standard frameworks rarely model correctly.
The ITIL 4 Change Enablement Practice Guide distinguishes three change types — standard change (pre-authorized), normal change (assessed by a change authority), and emergency change. In our projects, the Mittelstand reality needs only the first two plus a compact escalation rule.
Why change-request discipline matters in 2026
In short: In 2026 a CR is no longer just a steering instrument; it is a compliance artifact. NIS-2 demands audit trails for security-relevant changes, IT governance is gaining ground per DSAG, and PMI shows unrelenting budget pressure from uncontrolled scope.
The regulatory landscape has shifted. The NIS-2 Directive and the German implementation act, in force since late 2025, oblige companies in critical sectors to document security-relevant changes traceably. A formal CR with risk analysis and roll-back plan is an audit requirement, not bureaucracy.
The DSAG Investment Report 2025 shows that 68 percent of member companies rate IT governance as highly or moderately relevant — up from 56 percent the year before. Structured CR procedures are explicitly listed. Starting an ERP modernization in 2026 without a defined CR process means opening a flank toward auditors from day one.
Per PMI Pulse of the Profession (2018), 52 percent of projects experience scope creep or uncontrolled scope changes — up from 43 percent five years earlier. In the Mittelstand, this discipline directly determines the EBIT impact of the investment.
Case study: lean CR process at a DACH Mittelstand machine builder
In short: At a machine builder in southern Germany with around 380 employees, we introduced a two-tier lean CR process because the originally planned, fully staffed CCB could not actually be staffed. Result after nine months: 41 documented CRs, average assessment time three working days.
We have seen in over 50 change-request projects with DACH Mittelstand companies that 60 percent of all later RFCs trace back to unclear specifications — a measurable gap that is avoidable before kickoff.
In an ERP implementation at a machine builder in southern Germany with 380 employees, a standard CCB model failed quickly. The original plan was a weekly CCB with eight members. Within three weeks the named people could not be in the same room at the same time. CRs piled up, decisions slipped by two to four weeks.
We reduced the procedure to two tiers. First: a triage with IT manager and external project lead assesses every RFC within 48 hours. Second: only CRs above 25,000 euros budget impact or with scope changes against the approved specification go to a 30-minute decision round — all others are handled in triage.
After nine months: 41 documented CRs — far below the feared 100-plus, because many were reclassified as service requests or specification questions. Average assessment time dropped from 18 to three working days. Triage consumed about four hours per week — six times less load than the full CCB. From more than 50 DACH Mittelstand projects, once more than 250 employees fall within scope, the corporate model fails — not because of the procedure, but because of role availability.
How we handle change requests in the DACH Mittelstand
In short: Four steps — triage within 48 hours, capability mapping against the target state, compact decision round only for CRs with budget or scope impact, complete audit documentation throughout.
First, triage. Every RFC is assessed within 48 hours by IT manager and project lead. We check whether it is actually a CR, a service request, a clarification, or an incident. From over 50 projects, 30 to 40 percent of alleged CRs are reclassified here.
Second, capability mapping. Before a CR is assessed, we verify whether the affected capability strategically belongs to the target state. Standard frameworks assess only time, cost, and risk. We use the SCOReX evaluation frame to structure target-process, standard coverage, realization risk, and exit options.
Third, the decision round. Only CRs with budget impact or scope changes against the approved specification document move into a 30-minute round with the management board. Decisions are recorded in the minutes.
Fourth, audit documentation. Every CR is logged in the ticket system with all mandatory fields — including the rejected ones. Documenting rejected CRs is the strongest defense against later accusations of "that was never decided." More on our methodical interlock between process and system is on independent ERP consulting and the digitalisation services overview.
Common mistakes in change-request management
In short: Four patterns we know from more than 50 DACH Mittelstand projects — missing triage, mixed ticket types, late documentation, CCB theater. They destroy budget and trust faster than any single technical misstep.
-
No triage. Every change wish lands at the steering committee unfiltered, which then spends half its time clarifying whether it is even a CR. A two-tier triage intercepts 30 to 40 percent of the load before it reaches decision bodies.
-
Mixing CR, service request, and incident. Users report "please change this" for three different situations. Without clean boundaries from ITIL 4, a ticket pile-up forms whose cause is classification, not volume.
-
Documentation only after delivery. The CR is decided verbally, perhaps confirmed by email. Six months after go-live no one can reconstruct who decided what, when, and why. With NIS-2 and rising audit expectations, this is a concrete compliance risk.
-
CCB theater. The fully staffed CCB is formally set up but never given real decision authority. It convenes monthly and rubber-stamps ten CRs in 90 minutes. From more than 50 projects, this theater is the most reliable indicator of a project in trouble — because the real decisions are made elsewhere, often in corridor talks.
Frequently Asked Questions
A change request alters an approved baseline — specification, contract, architecture, or configuration — and therefore needs a formal assessment with impact analysis, risk evaluation, and approval. A service request is a standard demand from a pre-approved catalog, such as creating a new user or resetting a password. Service requests run through pre-authorized workflows; change requests need a change authority. Clean classification is the single biggest lever on ticket volume — we train key users on this distinction in the first four project weeks.
From our work in more than 50 projects, seven fields suffice: requester with date and project reference, a concise description, the business justification, impact analysis on time and cost and quality, risk evaluation with roll-back, resource demand, and approval status. We recommend making these mandatory — even when the CR is later rejected. Documenting rejected applications is as important for audit as documenting accepted ones. Seven is the practical maximum; longer forms lead to people working around them.
In most DACH Mittelstand mandates there is no CCB with eight or more members because the relevant roles — service owner, IT architect, dedicated change manager — are simply not in post. We recommend a two-tier process: first, a triage with IT manager and project lead deciding within 48 hours; second, a 30-minute decision round with the management board for CRs above a defined budget threshold. We typically set this threshold between 10,000 and 50,000 euros, depending on project size and risk appetite. The model is ITIL-4-compatible but translates the full role catalog into a staffable structure.
Next steps
If you would like to discuss change-request handling for your project in more detail, we invite you to a free 30-minute consultation. We assess whether your CR process is staffable, whether NIS-2 audit demands are covered, and where the biggest lever lies — vendor-independent, based on 30 years of Mittelstand practice.
