Das Gebot der Stunde ist klar: „Wir brauchen ein neues ERP-System." Vielleicht läuft der Support für dein aktuelles System aus. Vielleicht sind die Prozesse so verbogen, dass niemand mehr durchblickt. Oder du startest als wachsendes Unternehmen zum ersten Mal mit einem richtigen ERP. Das Ziel ist klar – aber wie kommst du von einem weißen Blatt zu einer Ausschreibung, die dir am Ende auch wirklich das liefert, was du brauchst?
In den vergangenen Jahren habe ich verschiedene mittelständische Unternehmen durch agile Ausschreibungsprozesse begleitet. Dabei zeigte sich immer wieder ein wiederkehrendes Muster: Die klassische Vorgehensweise – monatelanges Lastenheft schreiben, dann ausschreiben, dann hoffen – funktioniert bei komplexen IT-Projekten nur noch bedingt. Die Welt hat sich weitergedreht, aber viele Ausschreibungsprozesse nicht.
Natürlich braucht ein Unternehmen mit 150 Mitarbeitern keine Agile Release Trains und keine PI-Plannings mit 100 Teilnehmern. Aber die Denkmodelle und Methoden, die SAFe im Lean Portfolio Management beschreibt, sind auch für kleinere Organisationen erstaunlich nützlich – besonders dann, wenn es darum geht, ein großes Vorhaben wie eine ERP-Ausschreibung so zu strukturieren, dass am Ende ein agiler Werkvertrag möglich wird.
📌 Das Dilemma: Genug wissen, um auszuschreiben – ohne alles zu wissen
Hier liegt das fundamentale Problem, mit dem du als IT-Leiter kämpfst: Für eine seriöse Ausschreibung brauchst du genug Substanz, damit Anbieter kalkulieren können. Gleichzeitig weißt du heute noch gar nicht, wie deine Prozesse in zwei Jahren aussehen sollten – und ehrlich gesagt wissen das deine Fachbereiche auch nicht. Das klassische 200-Seiten-Lastenheft suggeriert eine Präzision, die in der Realität nicht existiert.
Die gute Nachricht: Es gibt einen Mittelweg. Einen, der dir genug Struktur für eine belastbare Ausschreibung gibt, aber gleichzeitig die Flexibilität erhält, die du während der Implementierung brauchen wirst. Dieser Weg führt über das, was im Scaled Agile Framework als Lean Portfolio Management bezeichnet wird – angepasst auf die Realitäten eines ERP-Projekts.
🎯 Phase 1: Die strategische Verankerung
Bevor du auch nur eine einzige Anforderung aufschreibst, musst du verstehen, warum dein Unternehmen überhaupt ein neues ERP braucht. Das klingt banal, wird aber erstaunlich oft übersprungen. Die Folge: Anforderungslisten, die technische Wünsche sammeln, aber keinen roten Faden haben.
Beginne mit dem, was SAFe als Strategic Themes bezeichnet – die drei bis fünf übergeordneten Ziele, die deine ERP-Investition treiben. SAFe empfiehlt, diese Themes im OKR-Format (Objectives and Key Results) zu formulieren. Das hat einen praktischen Grund: OKRs zwingen dich, nicht nur das Ziel zu benennen, sondern auch messbare Ergebnisse zu definieren, an denen du Fortschritt erkennst.
In der Praxis sehen solche Strategic Themes dann so aus: Das Objective „Schnellere Auftragsabwicklung" wird konkret durch Key Results wie „Durchlaufzeit von Auftragseingang bis Auslieferung um 30% reduzieren" oder „Manuelle Dateneingaben um 50% reduzieren". Diese Struktur hilft dir später enorm – sowohl bei der Priorisierung von Anforderungen als auch bei der Erfolgsmessung nach Go-Live.
Alternativ – oder ergänzend – lässt sich auf dieser Ebene auch mit Capabilities arbeiten. Capabilities beschreiben, welche Fähigkeiten das Unternehmen entwickeln muss, um seine strategischen Ziele zu erreichen. Für ein ERP-Projekt könnte das heißen: „Fähigkeit zur Echtzeit-Transparenz über alle Lagerbestände" oder „Fähigkeit zur automatisierten Compliance-Dokumentation". Der Vorteil: Capabilities sind lösungsneutral formuliert und lassen dem Anbieter Spielraum, wie er diese Fähigkeit technisch umsetzt. In der Praxis erlebe ich oft, dass eine Kombination aus beiden Ansätzen am besten funktioniert – OKRs für die messbaren Ziele, Capabilities für die notwendigen Fähigkeiten.
Für die Dokumentation und das laufende Tracking deiner Strategic Themes haben wir ein kostenloses OKR-Tool entwickelt, das speziell auf die Bedürfnisse von Projektteams im Mittelstand zugeschnitten ist. Es ersetzt keine umfassende Strategiesoftware, aber für die Zwecke der ERP-Anforderungserhebung ist es völlig ausreichend.
Warum ist das wichtig? Weil du später, wenn ein Anbieter dir erklärt, warum Feature X unbedingt sein muss, prüfen kannst: Zahlt das auf unsere Strategic Themes ein? Wenn nicht, ist es Nice-to-have, nicht Must-have.
Für diese Phase brauchst du zwei bis drei Workshops mit der Geschäftsführung und den Bereichsleitern. Nicht mehr. Die Versuchung ist groß, hier schon in Details abzugleiten – widerstehe ihr.
🛠️ Phase 2: Prozesslandkarte und/oder Value Streams
Jetzt wird es konkreter, aber noch nicht zu konkret. In dieser Phase erstellst du eine Übersicht deiner Kernprozesse – nicht als detaillierte Ablaufdiagramme, sondern als End-to-End-Prozesse auf hoher Flugebene. Hier treffen zwei Welten aufeinander, die du kennen solltest.
Die traditionelle Prozesslandkarte ist ein etabliertes Verfahren im Geschäftsprozessmanagement und fester Bestandteil der ISO 9001 Norm. Sie strukturiert die Organisation in Management-, Kern- und Unterstützungsprozesse und zeigt deren Wechselwirkungen. Viele mittelständische Unternehmen im DACH-Raum haben bereits eine solche Prozesslandkarte – oft aus der ISO-Zertifizierung oder früheren QM-Projekten. Sie ist dokumentationsorientiert und eher statisch.
SAFe denkt anders: Dort arbeitest du mit Value Streams – dem Fluss von Wert vom Auslöser bis zur Lieferung an den Kunden. SAFe unterscheidet zwischen Operational Value Streams (wie du Wert für Kunden schaffst) und Development Value Streams (wie du Software/Lösungen entwickelst). Der Fokus liegt auf Flow, auf dem kontinuierlichen Fluss von Wert, nicht auf statischen Prozessboxen.
Die pragmatische Brücke: In der Realität kannst du beides nutzen. Wenn dein Unternehmen bereits eine Prozesslandkarte hat, ist das ein guter Startpunkt. Nutze sie, um die relevanten End-to-End Value Streams zu identifizieren. Typischerweise kristallisieren sich vier bis sechs dieser Wertströme heraus: Order-to-Cash (vom Kundenauftrag bis zum Zahlungseingang), Procure-to-Pay (vom Bedarf bis zur Lieferantenrechnung), Record-to-Report (von der Buchung bis zum Jahresabschluss), und je nach Branche Hire-to-Retire, Plan-to-Produce oder ähnliche.
Lass uns ehrlich sein: Dein Ziel ist nicht, SAFe einzuführen. Dein Ziel ist eine gute Ausschreibung. Dafür nutzt du bewährte Methoden aus dem Framework – aber du zwängst dich nicht in eine komplette Transformation.
🔧 Das konkrete Vorgehen, wenn du mit einer Prozesslandkarte arbeiten möchtest
Wenn dein Unternehmen bereits eine Prozesslandkarte aus der ISO-Zertifizierung oder früheren QM-Projekten hat, ist das dein bester Startpunkt. Du musst das Rad nicht neu erfinden.
Schritt 1: Identifiziere in deiner bestehenden Prozesslandkarte die vier bis sechs Kernprozesse, die dein ERP-System abbilden muss. Fokussiere dich auf die Prozesse, die tatsächlich vom neuen ERP betroffen sind – nicht alle Prozesse aus deiner Landkarte sind relevant.
Schritt 2: Dokumentiere für jeden dieser Kernprozesse auf maximal einer Seite:
- 🔹 Den aktuellen Zustand (grob skizziert, keine Details)
- 🔹 Die wesentlichen Schmerzpunkte (konkret benannt)
- 🔹 Wo Medienbrüche entstehen
- 🔹 Wo Informationen oder Material unnötig lange warten
- 🔹 Welche manuellen Eingriffe vermieden werden sollen
Schritt 3: Benenne für jeden Kernprozess einen Process Owner aus dem Fachbereich. Diese Person sollte:
- 🔹 Den Prozess end-to-end verstehen
- 🔹 Entscheidungsbefugnis über mehrere Abteilungen hinweg haben
- 🔹 Bereit sein, regelmäßig Zeit für das Projekt zu investieren
Der Process Owner ist später dein Ansprechpartner für alle Fragen zu diesem Prozess – sowohl während der Anforderungserhebung als auch in der Implementierung. Das ist nicht die Person, die den Prozess am detailliertesten kennt (das ist oft ein Sachbearbeiter), sondern die Person, die Entscheidungen treffen kann.
🔧 Das konkrete Vorgehen für Value Streams
Wenn du dich für den Value Stream-Ansatz entscheidest (oder wenn dein Unternehmen keine bestehende Prozesslandkarte hat), ist das Vorgehen ähnlich strukturiert, aber mit einem anderen Fokus:
Schritt 1: Identifiziere die drei bis fünf wichtigsten Operational Value Streams in deinem Unternehmen. Das sind die End-to-End-Wertströme, die für deine Kunden relevant sind. Für ein produzierendes Unternehmen könnte das sein: „Von der Kundenanfrage zum gelieferten Produkt", „Vom Materialbedarf zur Verfügbarkeit", „Von der Idee zum Produktportfolio".
Schritt 2: Dokumentiere für jeden Value Stream auf maximal einer Seite:
- 🔹 Trigger: Was startet den Value Stream?
- 🔹 Value: Was ist das erwartete Ergebnis für den Kunden?
- 🔹 Delays: Wo wartet Material, Information oder Arbeit unnötig lange?
- 🔹 Bottlenecks: Wo ist der Flow eingeschränkt?
- 🔹 Waste: Welche Aktivitäten schaffen keinen Wert?
SAFe bietet für diese Analyse das Value Stream Mapping – eine Methode, um den Ist-Zustand zu visualisieren und Optimierungspotenziale zu identifizieren. Du musst das nicht in aller Tiefe durchführen, aber das Denken in Delays und Bottlenecks hilft dir enorm, die richtigen Anforderungen zu formulieren.
Schritt 3: Benenne einen Value Stream Owner – die Person, die für die End-to-End-Performance dieses Wertstroms verantwortlich ist. Das ist oft schwieriger als es klingt, weil Value Streams typischerweise mehrere Abteilungen durchlaufen. Aber genau deshalb ist die Rolle so wichtig: Sie zwingt dich, über Silogrenzen hinweg zu denken.
In der Praxis läuft es oft auf dieselben Personen hinaus – deine Bereichsleiter werden sowohl Process Owner als auch Value Stream Owner sein. Der Unterschied liegt im Denkmuster: Bei Prozessen denkst du in Aktivitäten und Verantwortlichkeiten. Bei Value Streams denkst du in Fluss und Wertschöpfung.
🔄 Phase 3: Von Prozessen zu Epics
Jetzt wird es konkret – aber anders, als du es vielleicht gewohnt bist. In dieser Phase verdichtest du deine Prozess- oder Value Stream-Analyse in sogenannte Epics. Ein Epic ist im SAFe-Kontext eine größere Initiative, die erheblichen Wert liefert und typischerweise mehrere Sprints umfasst.
Für ein ERP-Projekt könnte ein Epic heißen: „Automatisierte Auftragsabwicklung ohne manuelle Dateneingabe" oder „Echtzeit-Transparenz über alle Lagerbestände mit automatischen Bestellvorschlägen". Nicht zu klein (das wäre eine User Story), nicht zu groß (das wäre ein ganzes Programm).
SAFe schlägt vor, für jeden Epic einen Lean Business Case zu erstellen – eine kompakte Beschreibung (zwei bis drei Seiten), die folgende Fragen beantwortet:
- 🔹 Problem: Welches konkrete Problem löst dieser Epic?
- 🔹 Solution Hypothesis: Welche Lösung schlagen wir vor?
- 🔹 Benefits: Welchen messbaren Nutzen erwarten wir?
- 🔹 Cost of Delay: Was kostet es uns, wenn wir das nicht umsetzen?
- 🔹 Success Criteria: Woran erkennen wir, dass es funktioniert?
Klingt aufwändig? Ist es nicht. Für die meisten Epics reicht eine halbe Seite. Das Entscheidende ist: Du zwingst dich, in Business Value zu denken, nicht in technischen Features. „Wir brauchen eine Schnittstelle zu SAP" ist kein Epic. „Automatischer Abgleich der Kundenstammdaten zwischen CRM und ERP zur Vermeidung von Dopplungen" ist ein Epic.
Typischerweise kristallisieren sich für ein mittelständisches ERP-Projekt zehn bis zwanzig solcher Epics heraus. Nicht hundert. Wenn du mehr hast, bist du zu detailliert. Die Details kommen später – in den Fit-to-Standard-Workshops mit dem ausgewählten Anbieter.
Für jeden Epic vergibst du eine vorläufige Priorität basierend auf dem WSJF-Modell (Weighted Shortest Job First): Business Value, Time Criticality, Risk Reduction, und Effort. Du musst das nicht wissenschaftlich berechnen – eine grobe Einschätzung auf einer Skala von 1 bis 5 reicht vollkommen.
Das Ergebnis dieser Phase ist dein Epic Portfolio – die priorisierte Liste der Initiativen, die dein neues ERP ermöglichen soll. Das ist der Kern deiner Ausschreibung.
🚧 Brownfield vs. Greenfield: Eine wichtige Weichenstellung
Bevor du weitergehst, musst du eine fundamentale Entscheidung treffen, die deinen weiteren Weg bestimmt: Migrierst du ein bestehendes System oder startest du auf der grünen Wiese?
Bei einer Migration (Brownfield) hast du einen riesigen Vorteil: Du weißt, was funktioniert. Deine Anforderungserhebung konzentriert sich auf die Deltas – was soll anders werden? Wo sind die Lücken? Der Aufwand für die Erhebung ist deutlich geringer, aber die technischen Komplexitäten der Datenmigration kommen hinzu.
Bei einer Neueinführung (Greenfield) hast du die Chance, Prozesse neu zu denken. Das ist gleichzeitig Fluch und Segen. Die Versuchung ist groß, jeden Sonderwunsch der letzten 20 Jahre wieder einzubauen. Widerstehe. Nutze die Gelegenheit, radikal zu hinterfragen: Brauchen wir diesen Prozess wirklich so?
In beiden Fällen gilt: Dokumentiere explizit, welche Epics Standardprozesse abbilden (FIT) und welche Abweichungen erfordern (GAP). Diese Unterscheidung wird später für die Kalkulation der Anbieter entscheidend sein.
📋 Die Ausschreibungsunterlagen
Jetzt kommt der Teil, der dich wahrscheinlich am meisten interessiert: Wie sehen Ausschreibungsunterlagen aus, die für einen agilen Werkvertrag geeignet sind?
Der klassische Ansatz – detailliertes Lastenheft, Festpreis, fertig – führt bei ERP-Projekten in eine Sackgasse. Entweder der Anbieter kalkuliert so viel Risikopuffer ein, dass du deutlich zu viel zahlst. Oder er kalkuliert knapp und finanziert sich später über Change Requests. Beides ist nicht in deinem Interesse.
Der alternative Ansatz, den ich empfehle, besteht aus vier Dokumenten:
Das erste Dokument ist die Projektvision mit Strategic Themes. Zwei bis drei Seiten, die beschreiben, warum du dieses Projekt machst und woran du Erfolg misst. Dieses Dokument liest der Geschäftsführer des Anbieters – nicht der Vertriebsmitarbeiter.
Das zweite Dokument ist deine Prozesslandkarte oder Value Stream. Deine dokumentierten End-to-End-Prozesse (Order-to-Cash, Procure-to-Pay, etc.) – jeweils mit den konkreten Problemen, die gelöst werden müssen. Wenn du bereits eine Prozesslandkarte aus der ISO-Zertifizierung hast, arbeite damit weiter und ergänze sie um die identifizierten Delays und Bottlenecks. Das reicht vollkommen aus.
Das dritte Dokument ist das Epic-Portfolio mit Lean Business Cases. Dies ist der Kern deiner Ausschreibung. Für jeden Epic: Problembeschreibung, erwarteter Nutzen, Erfolgskriterien, Abhängigkeiten, vorläufige Priorität. Keine detaillierten Soll-Prozesse, keine Bildschirmmasken-Beschreibungen.
Das vierte Dokument beschreibt die Rahmenbedingungen und Spielregeln. Hier definierst du, wie ihr zusammenarbeiten wollt: Welche Rollen erwartest du vom Anbieter? Wie oft soll deployed werden? Wie geht ihr mit Änderungen um? Welche Entscheidungsbefugnisse hat wer?
Explizit nicht Teil der Ausschreibung ist ein 200-Seiten-Lastenheft mit Soll-Prozessen. Diese Details erarbeitest du gemeinsam mit dem ausgewählten Anbieter in sogenannten Fit-to-Standard-Workshops während der Implementierung.
⚙️ Das Vertragsmodell
Hier wird es juristisch – und hier scheitern viele agile ERP-Projekte, bevor sie richtig begonnen haben. Das deutsche Vertragsrecht kennt keine „agilen Verträge". Du musst dich entscheiden: Werkvertrag (du zahlst für ein Ergebnis) oder Dienstvertrag (du zahlst für Zeit und Aufwand). Die rechtliche Einordnung bleibt komplex – das OLG Frankfurt ließ die Zuordnung 2017 offen und tendierte zu einem typengemischten Vertrag.
In der Praxis hat sich ein Hybridmodell bewährt, das als „Agiler Festpreis" bekannt ist. Die Grundidee: Du definierst einen Gesamtrahmen (Budget und grober Scope) und vereinbarst, dass die Details iterativ in Sprints erarbeitet werden. Jeder Sprint hat ein festes Budget und liefert ein vereinbartes Increment. Nach jedem Sprint habt ihr beide die Möglichkeit, den Vertrag anzupassen oder zu beenden.
Zwei Mechanismen sind dabei entscheidend. Der erste heißt „Change for Free": Innerhalb des Gesamtbudgets kannst du Anforderungen tauschen, solange der Aufwand vergleichbar ist. Du willst Feature A nicht mehr, dafür Feature B? Kein Problem, solange der geschätzte Aufwand ähnlich ist.
Der zweite Mechanismus heißt „Money for Nothing": Wenn du nach Sprint 10 merkst, dass du bereits genug Wert geliefert bekommen hast, kannst du das Projekt vorzeitig beenden. Der Anbieter behält einen Teil des eingesparten Budgets, du behältst den Rest.
Lass diese Verträge von einem IT-Rechtler prüfen, der agile Projekte versteht. Das kostet ein paar tausend Euro und erspart dir potenziell hunderttausende in Streitigkeiten.
⚠️ Die Realität: Was in dieser Roadmap nicht steht
Sie ersetzt nicht die politische Arbeit. ERP-Projekte scheitern selten an der Technik – sie scheitern an Menschen, die sich nicht einigen können oder die das Projekt nicht wollen. Wenn dein Vertriebsleiter das Projekt torpediert, hilft dir die beste Anforderungserhebung nichts.
Sie garantiert keinen Erfolg bei der Anbieterauswahl. Auch mit perfekten Ausschreibungsunterlagen kannst du den falschen Anbieter wählen. Die Chemie muss stimmen, die Branchenerfahrung muss passen, die Schlüsselpersonen müssen verfügbar sein.
Sie macht das Projekt nicht kürzer oder billiger. Agile Methoden sind kein Zaubermittel. Sie machen Projekte transparenter und anpassungsfähiger – aber nicht automatisch schneller oder günstiger. Eine McKinsey-Studie zu agilen ERP-Implementierungen zeigt allerdings messbare Vorteile: etwa 10% geringere Projektkosten und 20% höherer Programmwert – wenn die Voraussetzungen stimmen.
👥 Für wen ist dieser Ansatz geeignet – und für wen nicht?
Dieser Ansatz funktioniert gut für mittelständische Unternehmen mit 50 bis 500 Mitarbeitern, die bereit sind, sich auf eine partnerschaftliche Zusammenarbeit mit dem Anbieter einzulassen. Er funktioniert gut, wenn du Entscheider hast, die regelmäßig Zeit für das Projekt investieren können.
Er funktioniert weniger gut, wenn deine Organisation stark reguliert ist und detaillierte Vorab-Dokumentation zwingend erfordert. Er funktioniert weniger gut, wenn deine Beschaffungsabteilung auf klassische Festpreis-Ausschreibungen besteht und keine Flexibilität zeigt. Und er funktioniert nicht, wenn dein Management das Projekt an die IT delegieren will und selbst nicht involviert sein möchte.
📚 Weiterführende Ressourcen
Wenn du tiefer einsteigen möchtest, empfehle ich folgende Quellen:
Zum Thema SAFe und ERP hat SAP gemeinsam mit Scaled Agile im Oktober 2024 ein offizielles SAP Activate + SAFe Playbook veröffentlicht, das die methodische Integration beider Frameworks standardisiert. Für öffentliche Auftraggeber bietet das Forum Agile Verwaltung ein Muster für agile Softwareverträge mit EVB-IT-Kombination.
Zur rechtlichen Vertragsgestaltung gibt es mittlerweile fundierte Praxisleitfäden der BITKOM für interessengerechte IT-Verträge. Das Standardwerk zum Agilen Festpreis ist „Der agile Festpreis" von Opelt, Gloger, Pfarl und Mittermayr (Hanser Verlag, 4. Auflage 2023).