Digitale Transformation im deutschen Mittelstand: Was wirklich funktioniert

Ein Werkzeugmaschinenhersteller in Baden-Württemberg mit 400 Mitarbeitern und 60 Jahren Betriebsgeschichte beschließt, dass es Zeit ist zu digitalisieren. Der Vorstand genehmigt ein Budget. Ein Projektleiter wird eingestellt. Ein SAP-Implementierungspartner wird hinzugezogen. Achtzehn Monate später ist das Projekt über dem Budget, drei Schlüsselmitarbeiter haben aus Frustration gekündigt, und das Produktionsplanungsteam nutzt immer noch die Tabellenkalkulationen, die es vor Beginn der Transformation verwendete.

Diese Geschichte ist nicht ungewöhnlich. Die digitale Transformation im deutschen Mittelstand scheitert häufiger, als sie gelingt – nicht weil die Technologie falsch ist, sondern weil das Standard-Playbook für Großkonzerne oder Silicon-Valley-Startups geschrieben wurde, von denen keines einem familiengeführten Fertigungsunternehmen mit 200 Mitarbeitern in Thüringen ähnelt.

Nach der Zusammenarbeit mit mittelständischen europäischen Unternehmen bei Modernisierungsprojekten sehen die Muster, die konsistent erfolgreich sind, ganz anders aus als die beraterzentrierten Big-Bang-Ansätze, die Budgets verschlingen und Post-mortems erzeugen. Dieser Beitrag teilt, was tatsächlich funktioniert.

Warum das Standard-Playbook im deutschen Mittelstand scheitert

Frameworks für digitale Transformation, die für DAX-40-Unternehmen oder US-Technologie-Startups geschrieben wurden, teilen eine Reihe von Annahmen, die für typische Mittelstandsunternehmen nicht gelten. Sie setzen den Zugang zu großen internen IT-Teams voraus, die Bereitschaft zur vollständigen Migration in die Cloud, eine Kultur, die mit organisatorischer Disruption umgehen kann, und die Fähigkeit, den Kernbetrieb während des Übergangs zu pausieren.

Mittelstandsunternehmen haben typischerweise das Gegenteil: eine kleine IT-Abteilung (oft ein oder zwei Personen), deren Hauptverantwortung darin besteht, bestehende Systeme am Laufen zu halten, eine tiefe Skepsis gegenüber Cloud-Anbietern auf Basis von DSGVO-Bedenken und Anforderungen an die Datensouveränität, eine Unternehmenskultur, die Stabilität und lange Betriebszugehörigkeit schätzt, und Produktionsabläufe, die absolut nicht unterbrochen werden dürfen.

Das ERP-System ist der Schwerpunkt im Zentrum jeder Mittelstands-IT-Landschaft. Unternehmen in Fertigung, Logistik und Handel betreiben ihre Kernprozesse seit Jahrzehnten über SAP, Sage, proAlpha oder branchenspezifische Systeme. Anders als ein Startup, das seinen Stack frei wählen kann, trägt ein Mittelstandsunternehmen 15 Jahre Geschäftslogik, Stammdaten und Kundenhistorie, die in diesem ERP eingeschlossen sind. Jede digitale Transformation, die das ERP nicht berücksichtigt, endet als isolierte Insel, die die Organisation schließlich aufgibt.

Die DSGVO fügt eine weitere, oft unterschätzte Einschränkung hinzu. Mittelständische deutsche Unternehmen, die andere deutsche Unternehmen bedienen, operieren unter strengen Auslegungen der Datensouveränität – besonders in Branchen wie Medizintechnik, Finanzdienstleistungen und Lieferketten des öffentlichen Sektors. „Verschieben Sie es einfach zu AWS“ ist keine geradlinige Antwort, wenn die Rechtsabteilung Bedenken bezüglich der Zuständigkeit des US CLOUD Act hat und die Enterprise-Kunden Auftragsverarbeitungsvereinbarungen haben, die EU-basierte Rechenzentren vorschreiben.

Die Herausforderung der ERP-Integration

Um das ERP herum zu bauen, statt es zu ersetzen, ist das Muster, das funktioniert. Mittelstands-ERP-Systeme enthalten jahrzehntelange Betriebsdaten und Geschäftsregeln, deren Konfiguration Jahre dauerte. Sie herauszureißen, um neu anzufangen, ist ein mehrjähriges Projekt mit sehr hoher Ausfallrate. Die Unternehmen, die erfolgreich sind, behandeln das ERP als dauerhaften Bestandteil und bauen eine moderne Integrationsschicht darum herum.

Das architektonische Muster, das hier funktioniert, ist die API-First-Integration: das Erstellen einer sauberen Schnittstelle zwischen Legacy-ERP-Daten und neuen digitalen Fähigkeiten. Statt direkter Datenbankverbindungen zu ERP-Tabellen – die spröde Abhängigkeiten schaffen und die Support-Verträge des Anbieters verletzen – stellt eine dedizierte Integrationsschicht die von den neuen Systemen benötigten Daten über versionierte APIs bereit.

Für SAP-Landschaften bedeutet das typischerweise, SAPs OData-APIs oder BAPIs als Source of Truth zu nutzen und einen PHP/Symfony-Adapter-Dienst zu bauen, der zwischen dem Datenmodell des ERP und dem Format übersetzt, das moderne Webanwendungen erwarten:

// ERP-Adapter-Dienst: übersetzt SAP-Materialdaten in eine saubere API
class SapMaterialAdapter
{
    public function __construct(
        private readonly SapODataClient $sapClient,
        private readonly CacheInterface $cache,
    ) {}

    public function getMaterial(string $materialNumber): MaterialDto
    {
        $cacheKey = 'sap.material.' . $materialNumber;

        return $this->cache->get($cacheKey, function () use ($materialNumber) {
            $sapData = $this->sapClient->get(
                '/sap/opu/odata/sap/MM_MATERIAL_SRV/MaterialSet',
                ['$filter' => "Matnr eq '{$materialNumber}'"]
            );

            return new MaterialDto(
                id: $sapData['Matnr'],
                description: $sapData['Maktx'],
                unit: $sapData['Meins'],
                stockQuantity: (float) $sapData['Labst'],
                price: Money::of($sapData['Stprs'], $sapData['Waers']),
            );
        });
    }
}

Dieses Adapter-Muster erfüllt zwei Zwecke: Es schirmt die moderne Anwendung vom ausschweifenden Datenmodell von SAP ab und stellt eine Caching-Schicht bereit, die verhindert, dass das ERP von Echtzeit-Web-Traffic überlastet wird. ERP-Systeme wurden nicht dafür konzipiert, als Backends für interaktive Webanwendungen zu dienen; der Adapter fängt diese Diskrepanz ab.

Für DATEV-integrierte Unternehmen (häufig in buchhaltungs- und steuerlich sensiblen Branchen) gelten ähnliche Prinzipien – DATEVs DATEV-Daten-Export und REST-APIs bieten strukturierten Zugang zu Finanzdaten, die über eine saubere Service-Schicht bereitgestellt werden können, ohne direkten Datenbankzugriff zu erfordern.

Phasenweise Rollouts, die das Geschäft nicht stoppen

Der größte Fehler in Mittelstandsprojekten besteht darin, die erste Phase zu breit zu fassen. Ein Unternehmen, das versucht, Beschaffung, Produktionsplanung und Kundenservice gleichzeitig in einem einzigen Projekt zu digitalisieren, schafft ein Koordinationsproblem, das die Kapazität des internen Teams zur Bewältigung von Veränderungen überfordert.

Der phasenweise Ansatz, der konsistent funktioniert, beginnt mit einem einzelnen, schmerzhaften Prozess, der einen klaren Vorher-Nachher-Vergleich hat. Nicht der strategisch wichtigste Prozess – der, über den sich die Leute im täglichen Betrieb am meisten beschweren. In Fertigungsunternehmen ist das oft die Abfrage des Auftragsstatus: Vertriebsmitarbeiter rufen die Produktion an, um zu fragen, wo ein Kundenauftrag steht, die Produktion prüft eine Tabelle und ruft zurück. Es ist manuell, fehleranfällig und allgemein als Zeitverschwendung anerkannt.

Der Aufbau eines Web-Portals, das den Echtzeit-Auftragsstatus aus dem ERP bereitstellt, dauert vier bis acht Wochen. Es ist technisch handhabbar, weil die Daten im ERP liegen und die Abfrage einfach ist. Die geschäftliche Wirkung ist unmittelbar und sichtbar. Und es beweist – intern, gegenüber Skeptikern in der IT-Abteilung und im Management –, dass der neue Ansatz funktioniert, ohne den Kernbetrieb zu stören.

Dieser erste Erfolg schafft das organisatorische Kapital für die zweite Phase. Stakeholder, die skeptisch waren, werden zu Befürwortern, weil sie die erste Lieferung funktionieren sahen. Die IT-Abteilung, die das Projekt anfangs als Risiko für die von ihr gewarteten Systeme sah, hat nun einen Referenzpunkt dafür, wie sich die Integrationsschicht verhält. Die dritte Phase ist aus demselben Grund einfacher als die zweite.

Diese Abfolge entspricht eng dem Strangler-Fig-Muster, angewendet auf Prozessebene statt auf Code-Ebene: Lassen Sie die neue Fähigkeit um den bestehenden Betrieb herum wachsen, ein abgegrenzter Prozess nach dem anderen, bis die digitale Schicht die wichtigsten Interaktionen abwickelt.

Hybrid On-Premise/Cloud: Die Architektur, die passt

Für die meisten Mittelstandsunternehmen in Deutschland ist eine vollständige Cloud-Migration nicht das richtige Ergebnis – zumindest nicht kurzfristig. Das ERP bleibt On-Premise. Operative Kerndaten bleiben im eigenen Rechenzentrum des Unternehmens oder in einer Co-Location-Einrichtung. Die DSGVO-Compliance-Position ist gut verstanden und vertretbar.

Was funktioniert, ist eine hybride Architektur, in der die neuen digitalen Fähigkeiten in einer deutschen oder EU-basierten Cloud laufen (Deutsche Telekom OTC, Hetzner oder deutsche AWS/Azure-Regionen mit entsprechenden AV-Vereinbarungen), während ein Integrationsdienst das On-Premise-ERP und die cloud-gehostete Anwendungsschicht überbrückt.

Die Integrationsbrücke ist eine Schlüsselkomponente: ein leichtgewichtiger Symfony-Dienst, der On-Premise deployt wird und eine sichere HTTPS-API bereitstellt, die von der cloud-gehosteten Anwendung konsumiert wird. So bleiben die ERP-Daten On-Premise – sie verlassen das Netzwerk des Unternehmens nie in Rohform –, während sie modernen Web-Schnittstellen zur Verfügung stehen.

# Nginx-Reverse-Proxy für On-Premise-Integrationsdienst
# Nur über VPN oder dedizierte Standleitung zur Cloud-Umgebung erreichbar
server {
    listen 443 ssl;
    server_name erp-bridge.internal.example.de;

    ssl_certificate     /etc/ssl/certs/internal-cert.pem;
    ssl_certificate_key /etc/ssl/private/internal-key.pem;

    # Nur auf den IP-Bereich der Cloud-Anwendung beschränken
    allow 10.0.0.0/8;
    deny all;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Authorization $http_authorization;
    }
}

Diese Architektur erfüllt rechtliche und IT-Sicherheitsanforderungen (Daten bleiben On-Premise), während sie es den neuen digitalen Fähigkeiten ermöglicht, auf moderner, skalierbarer Cloud-Infrastruktur zu laufen. Die Cloud-Anwendung kann ohne On-Premise-Hardware-Beschränkungen deployt werden; der On-Premise-Integrationsdienst ist ein kleiner, wartbarer Dienst statt eines vollständigen Anwendungs-Stacks.

Für Digitale-Transformation-Projekte mit dieser Architektur dient die Infrastrukturgrenze auch als natürliche Sicherheitsgrenze: Alle Daten, die von On-Premise in die Cloud übergehen, werden explizit aufgezählt und explizit autorisiert, was sowohl die DSGVO-Dokumentation als auch interne Audit-Trails vereinfacht.

Senior-Entwickler in Deutschland finden und mit ihnen arbeiten

Mittelstandsunternehmen stehen bei der digitalen Transformation vor einer strukturellen Talentherausforderung: Die Entwickler mit den Fähigkeiten, die Integrationsschichten und modernen Webanwendungen zu bauen, die diese Projekte erfordern, konzentrieren sich auf Berlin, München und Hamburg, während viele mittelständische Industrieunternehmen in kleineren Städten und Regionen ansässig sind.

Internes Einstellen für ein einmaliges Transformationsprojekt ist ohnehin oft der falsche Ansatz. Ein Team, das für ein 12-monatiges Digitalprojekt eingestellt wird, schafft eine Management-Herausforderung, sobald das Kernprojekt abgeschlossen ist. Beratungspartnerschaften – ob mit Berliner Firmen oder regionalen Systemintegratoren – verschaffen dem Unternehmen Zugang zu Senior-Expertise ohne den Einstellungsaufwand.

Das Engagement-Modell, das für Mittelstandskunden funktioniert, ist kein großes Beratungsprojekt mit einer hundertseitigen Präsentation und einer Drei-Jahres-Roadmap. Es ist eine praxisnahe, eingebettete Zusammenarbeit: ein Senior-Entwickler, der direkt mit dem internen IT-Team arbeitet, die Integrationsschicht und modernen Anwendungskomponenten baut und dabei Wissen überträgt, das das interne Team in die Lage versetzt, das Gebaute zu warten und zu erweitern.

Wissenstransfer ist nicht optional – er ist das Ausstiegskriterium. Ein Mittelstandsunternehmen, das ein Digitalisierungsprojekt abgeschlossen hat, das Ergebnis aber ohne fortlaufende externe Beratung nicht warten kann, hat sich nicht wirklich transformiert; es hat eine Abhängigkeit erworben. Jedes Engagement sollte damit enden, dass das interne Team das Gebaute besitzt, mit Dokumentation und direktem Training zur Architektur und zur Codebasis.

Was die erfolgreichen Projekte gemeinsam haben

Betrachtet man Mittelstands-Digitalisierungsprojekte, die messbare Ergebnisse lieferten, treten mehrere Muster konsistent auf.

Aktives, nicht zeremonielles Executive Sponsorship. Projekte, bei denen ein Geschäftsführer oder COO an monatlichen Steering-Sitzungen teilnimmt – nicht nur Statusberichte erhält –, kommen schneller voran und stoßen auf weniger organisatorische Blockaden als Projekte, bei denen die Führung an einen Projektleiter übergibt und sich zurückzieht.

Eine definierte Ergebnismetrik für die erste Phase, vereinbart vor Projektbeginn. „Digitalisieren Sie unseren Auftragsprozess“ ist ein Projekt. „Reduzieren Sie Auftragsstatus-Anfragen von 40 pro Tag auf weniger als 5 pro Tag innerhalb von 90 Tagen“ ist ein Lieferergebnis mit einer Messung. Mittelstandsunternehmen reagieren gut auf konkrete, operative Ziele statt auf abstrakte Transformationsziele.

Ein interner Champion aus dem operativen Bereich, nicht nur aus der IT. Die Person, die den schmerzhaften Prozess tief versteht – der Betriebsleiter, der Logistikmanager, der Vertriebsleiter –, ist für den Projekterfolg ebenso wichtig wie das technische Team. Sie liefert die Bodenwahrheit darüber, wie der Prozess tatsächlich funktioniert (was meist anders ist als der dokumentierte Prozess), sie validiert, dass das neue Tool das Problem wirklich löst, und sie treibt die Akzeptanz bei den Menschen voran, die es täglich nutzen werden.

Ein realistischer Scope für die erste Phase. Die digitale Transformationsambition kann groß sein. Das erste Lieferergebnis sollte klein genug sein, um in acht bis zwölf Wochen abgeschlossen zu werden, und spezifisch genug, um klar als Erfolg oder Misserfolg bewertet zu werden.

Fazit

Die digitale Transformation im deutschen Mittelstand ist kein Technologieproblem. Die Technologien – moderne Web-Frameworks, Cloud-Infrastruktur, API-Integration – sind ausgereift und gut verstanden. Die Herausforderung besteht darin, sie im spezifischen Kontext mittelständischer deutscher Unternehmen anzuwenden: das ERP als unverrückbarer Anker, die DSGVO als echte Einschränkung statt als Ausrede, die vorsichtige IT-Kultur als Feature statt als Bug und die operative Kontinuität als absolute Anforderung.

Die Muster, die funktionieren – inkrementelle Rollouts, API-First-ERP-Integration, hybride On-Premise/Cloud-Architekturen, praxisnaher Wissenstransfer –, sind nicht glamourös. Sie eignen sich nicht für beeindruckende Konferenzpräsentationen. Aber sie erzeugen funktionierende Software in der Produktion, Geschäftsprozesse, die sich tatsächlich verändert haben, und interne Teams, die das Gebaute aufrechterhalten können.

Wolf-Tech hat mit europäischen mittelständischen Unternehmen an genau diesen Herausforderungen gearbeitet – beim Bau der Integrationsschichten, beim Design der phasenweisen Rollouts und bei der praxisnahen Legacy-Code-Optimierung und individuellen Softwareentwicklung, die digitale Transformation konkret statt theoretisch machen. Wenn Sie ein Mittelstands-Modernisierungsprojekt planen oder mitten in einem stecken, kontaktieren Sie uns unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io für ein kostenloses Erstgespräch.