Greenfield-Implementierung – ERP komplett neu aufbauen

Brownfield konvertiert das bestehende System technisch weiter und ist meist schneller und günstiger, während Greenfield das ERP komplett neu aufsetzt und damit sauberer, aber aufwändiger ist. Greenfield empfiehlt sich vor allem, wenn Altsysteme stark individualisiert, die Datenqualität niedrig oder die Prozesse grundlegend überholungsbedürftig sind, Brownfield eher bei gut gepflegten Systemen mit knappem Zeitfenster. Als pragmatischer Mittelweg gilt die selektive beziehungsweise Bluefield-Migration, die bewährte Teile übernimmt und andere neu aufbaut. Marktbeobachtungen zeigen einen Trend zu solchen hybriden Strategien, eine pauschal 'richtige' Wahl gibt es nicht – sie hängt von Datenqualität, Sonderlösungen und Zeitdruck ab.

Belastbare Pauschalpreise gibt es nicht, da die Kosten stark von Unternehmensgröße, Branche, Anzahl der Standorte und gewünschten Anpassungen abhängen. Im Mittelstand bewegen sich umfangreiche Greenfield-Projekte (etwa auf SAP-S/4HANA-Niveau) häufig im einstelligen Millionenbereich, in Konzernen können sie deutlich höher liegen. Wichtig ist, dass die Softwarelizenzen meist nur einen kleineren Teil der Gesamtkosten ausmachen – Branchenschätzungen verorten sie oft bei rund einem Viertel bis einem Drittel –, während der Großteil auf Implementierung, Customizing, Datenmigration, Schulung sowie die anschließende Stabilisierungs- und Hypercare-Phase entfällt. Wegen des kompletten Neuaufbaus liegt der Anfangsaufwand bei Greenfield in der Regel höher als bei einer technischen Brownfield-Konvertierung.

Die Dauer schwankt erheblich und reicht von wenigen Monaten bis zu deutlich über einem Jahr, abhängig von Scope, Datenqualität und Integrationskomplexität. Einfachere mittelständische ERP-Einführungen liegen oft im Bereich von etwa drei bis zwölf Monaten, während umfangreiche Greenfield-Projekte mit vielen Standorten oder hohem Anpassungsbedarf – etwa auf SAP-S/4HANA-Niveau – häufig zwölf bis achtzehn Monate oder länger beanspruchen. Greenfield-Projekte tendieren dabei eher zum längeren Ende, weil Prozesse, Konfiguration und Datenmodell von Grund auf neu erarbeitet werden müssen. Realistische Test-, Schulungs- und Change-Phasen einzuplanen ist erfolgskritisch, denn ein zu enger Zeitplan ist eine häufige Ursache für Projektprobleme.

Anders als bei einer vollständigen Übernahme migriert man bei Greenfield bewusst selektiv und übernimmt in der Regel nur bereinigte Stammdaten sowie aktive Bewegungsdaten wie offene Posten und Salden. Historische Belege und nicht mehr benötigte Datenbestände werden meist nicht ins neue System überführt, sondern in einem Archivsystem oder Data Lake vorgehalten. Dieser Ansatz erlaubt einen Start mit hoher Datenqualität, erfordert aber eine sorgfältige vorherige Datenbereinigung und klare Entscheidungen, was wirklich gebraucht wird. Zu beachten ist, dass wertvolle historische Informationen verloren gehen können, wenn die Archivierungs- und Zugriffsstrategie – auch im Hinblick auf gesetzliche Aufbewahrungspflichten – nicht von Anfang an mitgedacht wird.

Greenfield ist besonders dann sinnvoll, wenn ein über Jahre gewachsenes Altsystem so viele Sonderlösungen enthält, dass Wartung und Updates unverhältnismäßig aufwendig geworden sind. Auch bei grundlegend veränderten Geschäftsmodellen, im Zuge von Cloud- oder SaaS-Strategien oder wenn Prozesse ohnehin neu gestaltet und vereinheitlicht werden sollen, spielt der Neuaufbau seine Stärken aus. Er ermöglicht es, konsequent die Standardfunktionen und Best Practices einer aktuellen Software zu nutzen und technische Altlasten abzulegen. Voraussetzung ist allerdings die Bereitschaft der Organisation zu spürbarer Veränderung sowie ausreichend Ressourcen für Change-Management und Schulung.

Der größte Nachteil ist der höhere Aufwand: Greenfield bedeutet längere Laufzeiten, mehr Anfangsinvestition und intensiveres Change-Management als eine technische Konvertierung. Weil sich Arbeitsweisen spürbar ändern, sind Schulung und Mitarbeiterakzeptanz erfolgskritisch, und ein Big-Bang-Umstieg birgt das Risiko von Betriebsunterbrechungen. Da bestehende Anpassungen und historische Daten nicht automatisch mitgenommen werden, besteht zudem die Gefahr, implizit wichtige Sonderlogik oder wertvolle Verlaufsdaten zu verlieren, wenn sie nicht bewusst rekonstruiert oder archiviert werden. Diesen Risiken stehen die langfristigen Vorteile schlanker, standardnaher Prozesse gegenüber, weshalb eine ehrliche Abwägung von Aufwand, Risiko und Nutzen am Anfang stehen sollte.