[Inhaltsverzeichnis]Inhaltsverzeichnis anzeigen
IT-Projekte sterben nicht während der Implementierung. Sie sterben in der Definitionsphase — man sieht es nur nicht sofort, weil der Tod langsam ist. In den ersten Monaten sind alle stolz auf die Demo, das Team brennt Story Points ab, und das KPI-Dashboard leuchtet grün. Das Problem taucht erst im sechsten Monat auf, wenn das System einen realen Geschäftsprozess berührt und sich herausstellt, dass es das falsche Problem löst. Oder das richtige Problem auf die falsche Art. Discovery ist das Gegenmittel. Unter einer Bedingung: dass es richtig gemacht wird.
In den letzten acht Jahren haben wir Dutzende Discovery-Prozesse für Unternehmen zwischen 20 und 500 Mitarbeitenden durchgeführt. Die Muster wiederholen sich mit mathematischer Regelmäßigkeit. Dieser Text ist die Destillation dieser Muster in eine umsetzbare Form — keine Lehrbuchtheorie, sondern ein Framework, das in 10 Arbeitstagen Geschäftsentscheidungen produziert.
Warum Projekte in der Definitionsphase sterben
Ein FMCG-Kunde (Trockenfrüchte-Produzent, ~180 Mitarbeitende, 90 Mio. PLN Umsatz) kam mit dem Briefing für ein neues CRM, weil „der Wettbewerber Salesforce eingeführt hat und wir das auch brauchen”. Das Briefing hatte 14 Seiten Anforderungen, eins zu eins aus dem Webinar des Anbieters kopiert. Erste Frage im Kick-off: „Welche KPI soll dieses CRM verbessern?”. Antwort: Stille, dann „naja… Digitalisierung”. Das ist der Archetyp der ersten Ursache — ein vom Wettbewerber kopiertes Briefing. Sie kopieren die Lösung, ohne das Problem zu verstehen, das sie löst. Das Ergebnis: ein System, das wie beim Wettbewerber aussieht, aber nicht denselben Wert erzeugt, weil es nie an Ihre Realität angepasst wurde.
Die zweite Ursache ist auf Vorstandsebene weniger sichtbar: Das Briefing entsteht ausschließlich auf Basis von Gesprächen mit Führungskräften. Der Abteilungsleiter beschreibt, wie der Prozess „funktionieren soll”. Der Mitarbeiter, der diesen Prozess acht Stunden am Tag ausführt, weiß, wie er tatsächlich funktioniert — mit Workarounds, mit Shadow-IT-Tabellen, mit tribal knowledge, das nirgends dokumentiert ist. Systeme, die ausschließlich auf Basis von Managergesprächen konzipiert werden, beschreiben immer Fiktion. Die Implementierung stößt im vierten Monat auf die Realität, wenn Endanwender im UAT sagen: „So arbeiten wir nicht.”
Dritte Ursache: das Geschäftsziel wird von einer Feature-Liste überdeckt. Das Briefing enthält 87 Anforderungen, aber kein einziger Satz beschreibt, wozu dieses System in P&L-Kategorien entsteht. Funktionen sind Mittel, nicht Zweck. Wenn Discovery nicht die Frage stellt „Um wie viel Prozent soll die Marge steigen, die Kosten fallen, die Cycle-Time sinken?”, hat das Implementierungsteam kein Priorisierungskriterium. Jede Funktion wird gleich wichtig, das Projekt sprengt das Budget, und der Vorstand kann nicht beurteilen, ob er bekommen hat, was er wollte — weil er nie definiert hat, was er wollte.
Unsere Definition von Discovery — was es NICHT ist
Discovery ist kein Post-it-Workshop. Zwei Tage im Raum mit Flipchart erzeugen Empathie im Team, produzieren aber keine Geschäftsentscheidung. Eine Geschäftsentscheidung braucht Daten — Interviews mit 12-18 Personen, eine As-is-Prozessmap mit Zeit- und Kostenmetriken, einen Vergleich von drei Architekturszenarien. Ein Post-it ersetzt keine TCO-Analyse.
Discovery ist kein Technical Audit. Ein Technologieaudit untersucht das Bestehende — Codequalität, technische Schulden, Skalierbarkeit der aktuellen Architektur. Discovery untersucht, was entstehen soll und ob es überhaupt entstehen sollte. Das Audit beantwortet „Wie ist der Zustand?”. Discovery beantwortet „Was bauen wir, warum, zu welchen Kosten, mit welcher Rendite?”. Zwei unterschiedliche Prozesse, in Kundenbriefings häufig verwechselt.
Discovery ist keine Anforderungsliste. Ein Dokument mit 87 funktionalen Anforderungen ist ein Output der Implementierungsphase, nicht der Definitionsphase. Discovery produziert etwas Härteres: eine Go- / No-go- / Pivot-Entscheidung mit prognostiziertem Geschäftswert, TCO-Kostenmodell und Analyse von Alternativen. Die Anforderungsliste folgt aus dieser Entscheidung, sie ist nicht ihr Input.
Discovery ist eine Diagnose mit einer einzigen Aufgabe: eine Geschäftsentscheidung mit eindeutiger Begründung zu produzieren. Alles andere — Prozessmaps, Architektur, Schätzungen — ist Beweismaterial, nicht das Deliverable.
DoMoreSoft Discovery Framework — 5 Phasen erklärt
Wir haben das Framework benannt, nicht weil wir gerne Dinge benennen, sondern weil ein benannter Prozess replizierbar ist. Ein unbenannter Prozess stirbt mit der einen Person, die ihn „kann”. Fünf Phasen, zehn Arbeitstage, zwei Senior-Berater auf Do-More-Soft-Seite (Systemarchitekt plus Prozessberater), definierte Deliverables am Ende jeder Phase.
Phase 1 (Tage 1-2): Stakeholder-Map und Problemartikulation
Die ersten beiden Tage widmen wir der Kartierung des Schlachtfelds. Die Stakeholder-Map beantwortet vier Fragen: wer bezahlt für die Entscheidung, wer nutzt sie, wer ist ihr Opfer, wer hat Vetorecht. Diese Rollen fallen fast nie in einer Person zusammen, und jede ignorierte Rolle ist die häufigste Ursache des Projektversagens.
Aus dieser Beobachtung folgt eine konkrete operative Entscheidung: Parallel setzen wir uns mit dem Vorstand zur Problemartikulation und erzwingen eine Antwort auf „Woran erkennen wir, dass das Projekt erfolgreich war?” — in P&L-Metriken, nicht in Feature-Listen. Gibt es auf diese Frage in 48 Stunden keine Antwort, sind die folgenden Phasen sinnlos — Discovery hält an und kehrt zum Vorstand zurück, um eine Entscheidung einzuholen.
Output Phase 1: Stakeholder-Map mit markierten Interessenkonflikten, Problemstellung in einem Absatz, vom Projekt-Sponsor freigegebene Erfolgsmetriken mit Zielwerten.
Phase 2 (Tage 3-5): Anwender-Interviews — 12-18 Personen in mindestens 3 Rollen
Drei Tage Einzelinterviews. Keine Gruppeninterviews. Gruppeninterviews produzieren Konsens, und Konsens verbirgt die Wahrheit. Mindestens drei Rollen: Endanwender (Person, die täglich mit dem System arbeitet), Manager (Person, die auf Basis des Systems berichtet) und externer Stakeholder (Kunde, Partner, Regulierer). Jedes Interview dauert 45-60 Minuten, folgt einem strukturierten Skript und produziert ein Transkript, das nach Pain-Points, Workarounds und verborgenen Prozessen getaggt ist.
Output Phase 2: eine Basis von 12-18 Transkripten mit Problem-Taxonomie, Top-10-Liste der Pain-Points nach Häufigkeit, Shadow-IT-Map (Tabellen, private Makros, WhatsApp-Gruppen, die Prozesse ersetzen).
Phase 3 (Tage 6-7): Prozessmapping und Engpassidentifikation
Auf Basis der Interviews bauen wir eine As-is-Prozessmap mit Metriken — Anzahl der Schritte, Zeit pro Schritt, Punkte manueller Dateneingabe, Entscheidungspunkte, Transfers zwischen Systemen. In diesem Projekt hatte die As-is-Map 47 Schritte, die To-be-Map 12. Die Differenz zwischen As-is und To-be ist der Geschäftswert des Projekts, ausgedrückt in Arbeitsstunden und Betriebskosten. Parallel wenden wir unsere Methodik zur Engpassidentifikation an — 5 Engpasstypen, vom manuellen Umschreiben bis zum Over-Reporting.
Output Phase 3: As-is-Prozessdiagramm mit Metriken, To-be-Map mit identifizierten Engpässen, Engpassregister mit geschätzten Jahreskosten je Engpass.
Phase 4 (Tage 8-9): Architekturskizze und Kostenmodell
Zwei Tage für Geschäfts- und technische Architektur plus TCO-Modell. Der Architekt bereitet drei Szenarien vor: Build (Eigenentwicklung), Buy (Einführung eines Standardprodukts mit Konfiguration) und Hybrid (Standard-Core plus Custom-Module). Jedes Szenario erhält ein TCO-Modell über drei Jahre — Implementierungskosten, Wartungskosten, Kosten technischer Schulden und eine Skalierbarkeitsprognose. Das sind keine Schätzungen aus der Luft. Das sind Modelle, die mit unseren früheren Projekten derselben Klasse benchmarkt sind.
Output Phase 4: drei Architekturszenarien mit Komponentendiagrammen, TCO-Modell über drei Jahre je Szenario, Risikoanalyse mit Mitigationsplan.
Phase 5 (Tag 10): Entscheidungsreport mit drei Szenarien
Der letzte Tag ist Konsolidierung und Vorstandspräsentation. Der Entscheidungsreport folgt einer festen Struktur: Problemstellung, Diagnose (As-is-Map, Engpässe), drei Szenarien mit Empfehlung, ROI-/TCO-Modell über drei Jahre, Roadmap 90 Tage und 12 Monate. Die Präsentation dauert 90 Minuten — 30 Minuten Report, 60 Minuten Diskussion und Fragen des Vorstands. Am Ende der Sitzung fällt die Entscheidung: Go, No-go oder Pivot. Bei Go beginnen wir die Scoping- und Planungsphase der Implementierung — die Methodik teilen wir in MVP in 8 Wochen.
Output Phase 5: Entscheidungsreport (30-50 Seiten PDF), Executive-Summary-Präsentation, dokumentierte und unterzeichnete Vorstandsentscheidung.
Was der Kunde am Ende von 10 Tagen erhält
Die Deliverable-Liste ist immer gleich, weil wir sie nach mehreren Dutzend Discoveries konsolidiert haben:
- As-is- und To-be-Prozessmap mit Zeit- und Kostenmetriken je Schritt.
- Engpassregister mit Jahreskostenschätzung je Engpass.
- Drei Lösungsszenarien (Build / Buy / Hybrid) mit TCO-Modell über drei Jahre.
- Bewertung der technischen Schulden des Bestandssystems, sofern der Kunde bereits eine Lösung hat.
- Skill-Gap-Analyse des Teams — wer fehlt, um die neue Lösung zu betreiben.
- Empfohlene Roadmap: 90-Tage-Plan (Quartalsmeilensteine) und 12-Monats-Plan (strategische Jahresziele).
- Entscheidungsreport mit eindeutiger Go- / No-go- / Pivot-Empfehlung.
Case: Wie 10 Tage Discovery 6 Monate Entwicklung retteten
Ein FMCG-Kunde — Produzent und Distributor von Trockenfrüchten und Nüssen — kam mit dem Briefing „Wir brauchen ein neues CRM, das aktuelle bremst uns aus.” Das Briefing hatte 14 Seiten funktionaler Anforderungen. Anstatt sofort zu schätzen, haben wir 10 Tage Discovery vorgeschlagen. Interviews mit Vertrieb, Lager und Logistik zeigten etwas, was das Briefing nicht zeigte: Das eigentliche Problem lag nicht im CRM, sondern im Bestellflussprozess zwischen Vertrieb, Lager und Logistik. Das CRM funktionierte — aber jede Bestellung durchlief vier manuelle Datenübertragungen zwischen Systemen, was Verzögerungen und Fehler produzierte.
Empfehlung nach Discovery: Pivot. Statt ein neues CRM über sechs Monate für 300 Tsd. EUR zu bauen, schlugen wir eine Integrationsschicht vor — ein Synchronisationsmodul zwischen bestehenden Systemen — für 85 Tsd. EUR in 8 Wochen. Den Rollout beschreiben wir in der Terra Case Study und im narrativen Artikel „Terra — von Tabellen zum System”. Zehn Tage Discovery haben das Projekt vom Bau des Falschen zur Lösung des Richtigen verschoben. Ersparnis: sechs Monate Teamzeit und 215 Tsd. EUR netto.
Warum zwei Wochen und nicht zwei Monate
Discovery kann beliebig lange dauern — wir kennen Firmen, die es sechs Monate führen. In der Praxis fällt der Grenznutzen jedes zusätzlichen Tages nach dem zehnten Tag exponentiell. In den ersten 10 Tagen decken wir 80% des Problems auf. Die nächsten 10 Tage? Weitere 15%. Das ist keine Meinung — das ist ein Muster aus 50+ Discoveries, die wir in Domänen von FMCG über Automotive bis SaaS durchgeführt haben.
Der zweite Grund ist kulturell: Das Parkinsonsche Gesetz besagt, dass sich Arbeit auf die verfügbare Zeit ausdehnt. Über Monate gestreckte Diskussionen produzieren Analyse-Paralyse, keine Entscheidungen. Ein harter 10-Tage-Rahmen erzwingt Priorisierungsdisziplin — was nicht in 10 Tage passt, wird nie passen, weil es nicht so wichtig ist, wie es schien. Teams mit zwei Monaten Discovery produzieren 300-seitige Reports, die niemand liest. Teams mit 10 Tagen produzieren einen 40-seitigen Entscheidungsreport, den der Vorstand in 45 Minuten liest und auf dessen Basis er die Entscheidung trifft.
Discovery zu überspringen ist wie die Diagnose vor einer OP zu überspringen. Der Kunde will schnell unter das Messer. Eine Woche später operiert man die falsche Krankheit. Discovery ist keine Phase, die man weglassen kann, weil „dafür kein Budget da ist” — es ist die Phase mit dem höchsten ROI-Hebel im gesamten Projekt, um Größenordnungen höher als jede Implementierungsoptimierung.
ROI von Discovery — die konkrete Mathematik
Discovery-Kosten im DoMoreSoft-Modell: 15-25 Tsd. EUR für 10 Tage zweier Senior-Berater. Kosten einer falschen sechsmonatigen Implementierung: 200-400 Tsd. EUR im Rollout-Budget plus Opportunitätskosten — die sechs Monate, die das Business-Team mit dem falschen Projekt verbracht hat statt mit einer anderen Initiative.
Die Break-even-Arithmetik ist banal. Bei einem Implementierungsprojekt mit 300 Tsd. EUR Budget amortisiert sich ein Discovery für 20 Tsd. EUR, wenn es 6,7% Fehl-Scope vermeidet. In der Praxis reduziert Discovery den Scope um 15-30% (Funktionen, die kritisch erschienen, stellen sich nach Anwender-Interviews als überflüssig heraus) und reduziert das Risiko des vollständigen Scheiterns um Größenordnungen. Discovery hat immer einen positiven ROI. Die Mathematik spricht gegen jede Alternative.
Die Zahlen sind an unseren eigenen Projekten und Case Studies überprüfbar. Das Terra-Discovery sparte 215 Tsd. EUR. Discoveries für Händlergruppen sparten 120-380 Tsd. EUR je Rollout. Wir kennen kein einziges Discovery, das sich am Ende nicht zehn- oder mehrfach amortisiert hätte.
Wann Discovery unnötig ist
Wir sind Fürsprecher von Discovery, aber keine Fanatiker. Drei Situationen, in denen Discovery Kundengeld verschwendet:
Erstens: Sie haben bereits einen funktionierenden Prototyp mit echten Nutzern und validiertem Problem. Wenn Ihr Prototyp 200 aktive Nutzer hat, die für das Produkt bezahlen, ist das Problem am Markt validiert. Die nächste Phase ist Scoping und Skalierung, nicht Discovery. Discovery nach der Prototyp-Phase ist teuer und redundant.
Zweitens: Der Projekt-Scope ist ein einzelner Service auf einer bestehenden Plattform. Das Hinzufügen eines Reporting-Moduls zu einem uns bekannten System benötigt kein Discovery. Es benötigt eine 2-3 Tage lange Scoping- und Schätzungssitzung. Discovery ist ein Werkzeug für komplexe Probleme, nicht für jedes Ticket.
Drittens: Sie bauen etwas, das Sie in derselben Domäne bereits zweimal gebaut haben. Wenn wir als Do More Soft drei CRMs für Automotive ausgeliefert haben, liefern wir das vierte ohne Discovery — wir haben die Prozessmuster, die Architekturmuster und die Integrationsmuster. Discovery hat Wert in der Exploration. Wenn die Exploration erledigt ist, wird weiteres Discovery zum Theater.
In jedem anderen Fall — besonders wenn Sie einen fundamentalen Geschäftsprozess verändern, eine neue Domäne betreten oder Systeme integrieren, die bislang unabhängig lebten — lohnt sich Discovery. Immer.
Wir machen es selbst — unsere eigenen Produkte sind durch Discovery gegangen
Es ist einfach, Wasser zu predigen und Wein zu trinken. Deshalb ging jedes unserer eigenen Produkte, die wir im Venture-Builder-Modell gebaut haben, durch internes Discovery, bevor wir eine Zeile Code geschrieben haben. MoreSales — unser CRM/ERP für E-Commerce — entstand aus einem dreiwöchigen Discovery mit zehn E-Commerce-Unternehmen, die mit demselben Problem kämpften. MyCarApp — unsere Automotive-Plattform — entstand aus sechs Wochen Interviews mit Händlern, Werkslogistik und Endkunden.
Jedes unserer 12 Produkte ist Beleg dafür, dass Discovery auch auf unserer eigenen P&L funktioniert. Hätten wir Discovery übersprungen, hätten wir heute vier Produkte statt zwölf — denn der Rest wäre innerhalb von sechs Monaten nach Launch gescheitert und hätte keinen Markt gefunden. Das ist keine Heuchelei von „Wasser predigen und Wein trinken”. Das ist Skin in the Game — wir nutzen dieselbe Methodik, die wir Kunden lehren, und zeigen, dass sie bei uns funktioniert.
Discovery als höchster ROI-Hebel
Wenn Sie CTO oder Gründer sind und ein Projekt im Wert von 200 Tsd. EUR oder mehr planen, lautet die Frage nicht „Sollen wir Discovery machen?”, sondern „Wann?”. Die Antwort: ganz am Anfang, bevor die erste Zeile Code geschrieben wird, bevor der Architekt Diagramme zeichnet, bevor der PM das Backlog sortiert. Discovery sind 5-8% des Projektbudgets, die die verbleibenden 92-95% vor Fehlallokation schützen.
Unsicher, ob Ihr Projekt Discovery braucht? Schreiben Sie an office@domoresoft.com mit dem Betreff „Discovery check” — 30 Minuten Gespräch reichen, damit wir gemeinsam entscheiden, ob sich Discovery lohnt oder ob es einer der drei Fälle ist, in denen es übersprungen werden kann. Bevorzugen Sie ein strukturiertes Format, nutzen Sie unseren Konfigurator — vier Minuten. Beide Wege führen zu demselben Gespräch, in dem wir entscheiden, ob es Sinn ergibt weiterzugehen. Es ist die erste Entscheidung, die es wert ist, bewusst getroffen zu werden — denn jede folgende hängt davon ab.
FAQ — Discovery kompakt
Was bedeutet Discovery-Prozess im Software-Development?
Eine strukturierte Phase vor der Implementierung, deren Ziel nicht das Niederschreiben von Anforderungen ist, sondern eine Geschäftsentscheidung: Go, No-go oder Pivot. Im DoMoreSoft-Modell dauert sie 10 Arbeitstage, umfasst 12-18 Stakeholder-Interviews, As-is-/To-be-Prozessmapping, drei Architekturszenarien und ein TCO-Modell über drei Jahre.
Was kostet Discovery im Verhältnis zum Gesamtprojekt?
5-8% des Implementierungsbudgets. Bei einem Projekt im Wert von 300 Tsd. EUR kostet Discovery 15-25 Tsd. EUR und amortisiert sich, wenn es 6,7% Fehl-Scope vermeidet. In der Praxis reduziert es den Scope um 15-30%.
Warum scheitern 90% der IT-Projekte ohne Discovery?
Weil das Implementierungsteam ohne Discovery am falschen Problem arbeitet oder am richtigen Problem auf die falsche Art. Drei Archetypen: ein vom Wettbewerber kopiertes Briefing, Gespräche nur mit Führungskräften, ein durch eine Feature-Liste verdrängtes Geschäftsziel.
Wie unterscheidet sich Discovery von einem Technical Audit?
Ein Technical Audit beantwortet die Frage „Wie ist der Zustand?” eines bestehenden Systems. Discovery beantwortet die Frage „Was bauen wir, warum, zu welchen Kosten und mit welcher Rendite?”. In einem Projekt, das beides benötigt, ist das Audit ein Input für Phase 3 von Discovery — kein Ersatz dafür.