Eine Anforderung ist noch keine Lösung.

Viele digitale Projekte starten mit vermeintlich klaren Anforderungen. Tatsächlich sind es oft schon vorweggenommene Lösungen. Genau das macht Projekte unnötig teuer und komplex.

„Wir brauchen einen Login.“

„Wir brauchen eine App.“

„Wir brauchen ein neues CMS.“

„Wir brauchen eine Schnittstelle.“

Solche Sätze klingen nach Anforderungen.

Sind sie aber meistens nicht.

Sie beschreiben bereits eine Lösung.

Und genau dort beginnt eines der häufigsten Probleme digitaler Projekte: Die technische Antwort steht fest, bevor sauber geklärt wurde, welches Problem eigentlich gelöst werden soll.

Eine gute Anforderung beschreibt zuerst den Bedarf

Nehmen wir ein einfaches Beispiel:

Kunden sollen sich einloggen können.

Das klingt konkret. Ein Entwickler kann damit etwas anfangen. Man kann Aufwand schätzen. Man kann über Authentifizierung, Benutzerkonten und Passwort-Reset sprechen.

Aber warum sollen sich Kunden überhaupt einloggen?

Vielleicht sollen sie ihre Bestellungen wiederfinden.

Vielleicht brauchen sie personalisierte Preise.

Vielleicht sollen bestimmte Dokumente nur für registrierte Nutzer verfügbar sein.

Vielleicht möchte das Unternehmen lediglich vermeiden, dass Kunden bei jeder Bestellung ihre Daten neu eingeben müssen.

Je nachdem, welches Problem dahinterliegt, kann ein Login sinnvoll sein.

Oder völlig unnötig.

Die eigentliche Anforderung lautet also nicht automatisch „Login“.

Sie könnte lauten:

Wiederkehrende Kunden sollen ihre bisherigen Bestellungen einfach einsehen können.

Erst danach beginnt die Frage nach der passenden Lösung.

Lösungen im Anforderungskatalog machen Alternativen unsichtbar

Je früher eine technische Lösung festgeschrieben wird, desto enger wird der Denkraum.

Aus „Wir brauchen einen Login“ entstehen sofort Folgefragen:

  • Welches Identity-System?
  • Welche Passwortregeln?
  • Brauchen wir Zwei-Faktor-Authentifizierung?
  • Wie funktioniert Account Recovery?
  • Wie werden bestehende Kundendaten zugeordnet?
  • Welche Daten dürfen gespeichert werden?
  • Wer betreibt das System?
  • Welche Schnittstellen sind nötig?

Das kann alles notwendig sein.

Aber vielleicht hätte eine einfachere Lösung das ursprüngliche Problem ebenfalls erfüllt.

Ein Magic Link.

Ein Bestelllink per E-Mail.

Eine anonyme Vorgangsnummer.

Eine bessere Suchfunktion.

Oder gar keine neue Funktion, sondern ein verbesserter bestehender Prozess.

Wer die Lösung zu früh festlegt, diskutiert irgendwann sehr effizient über die falsche Sache.

Das Problem betrifft nicht nur Fachbereiche

Vorweggenommene Lösungen entstehen an vielen Stellen.

Ein Fachbereich fordert ein neues Feature, weil ein Prozess heute umständlich ist.

Marketing fordert ein neues Tracking-Tool, weil Daten fehlen.

IT empfiehlt eine bestimmte Architektur, weil sie gut in die bestehende Landschaft passt.

Eine Agentur schlägt ein neues CMS vor, weil das aktuelle System Grenzen hat.

Ein Softwareanbieter zeigt ein Modul, das scheinbar genau das Problem löst.

Keine dieser Perspektiven ist automatisch falsch.

Schwierig wird es erst, wenn eine Empfehlung zur Anforderung wird, ohne dass Problem, Ziel und Alternativen sauber voneinander getrennt wurden.

Drei Fragen, die vor jeder Lösung stehen sollten

Bevor über Systeme, Features oder Anbieter gesprochen wird, helfen drei einfache Fragen.

1. Was soll sich konkret verbessern?

Nicht: „Wir brauchen ein Dashboard.“

Sondern zum Beispiel:

Die Vertriebsleitung soll jeden Montag erkennen können, welche Produkte hinter dem Monatsziel liegen.

Damit wird aus einer Lösung ein überprüfbares Ziel.

2. Für wen besteht das Problem?

Viele Funktionen entstehen aus interner Sicht.

„Wir möchten Kundendaten zentral speichern.“

Das kann sinnvoll sein. Aber wer profitiert davon konkret?

Der Kunde?

Der Vertrieb?

Der Support?

Das Controlling?

Je klarer die betroffene Rolle ist, desto leichter lässt sich später bewerten, ob eine Lösung tatsächlich hilft.

3. Woran merken wir, dass das Problem gelöst ist?

Eine Funktion ist kein Erfolgskriterium.

„Das neue Portal ist live“ sagt nur, dass etwas gebaut wurde.

Interessanter ist:

  • Bearbeitungszeit sinkt.
  • Supportanfragen gehen zurück.
  • Kunden können einen Vorgang ohne Rückfrage abschließen.
  • Daten sind vollständig genug für eine Entscheidung.
  • Ein manueller Zwischenschritt entfällt.

Erst solche Kriterien machen eine digitale Maßnahme steuerbar.

Gute Anforderungen lassen technische Lösungen offen

Das bedeutet nicht, dass Technik keine Rolle spielt.

Natürlich müssen Anforderungen irgendwann konkret genug werden, damit Entwickler sie umsetzen können.

Aber die Reihenfolge ist entscheidend.

Zuerst:

Problem. Ziel. Nutzer. Rahmenbedingungen. Erfolgskriterium.

Dann:

Lösungsoptionen.

Und erst danach:

Technische Umsetzung.

Diese Trennung wirkt banal. In der Praxis spart sie jedoch erstaunlich viel Aufwand.

Denn plötzlich lassen sich Optionen vergleichen, statt nur Varianten derselben vorgegebenen Lösung zu diskutieren.

Ein Dienstleister sollte Lösungen empfehlen dürfen

Unabhängige Auftraggeberkompetenz bedeutet übrigens nicht, Agenturen oder Entwickler auf reine Ausführung zu reduzieren.

Im Gegenteil.

Gute Dienstleister sollten Lösungen vorschlagen.

Sie sollten widersprechen.

Sie sollten bessere Wege aufzeigen. Damit das funktioniert, braucht es allerdings mehr als Tickets und Freigaben: gute Agentursteuerung schafft auf Auftraggeberseite den notwendigen Rahmen.

Damit das funktioniert, brauchen sie aber einen Auftraggeber, der nicht nur eine fertige technische Bestellung übergibt, sondern das zugrunde liegende Problem erklären kann.

„Baut uns einen Login“ lässt wenig Raum.

„Wiederkehrende Kunden sollen ihre vergangenen Bestellungen ohne Supportanfrage finden können“ öffnet dagegen die Diskussion.

Und genau dort kann echte Expertise entstehen.

Der Unterschied klingt klein. Finanziell ist er es nicht.

Viele unnötige Kosten in digitalen Projekten entstehen nicht durch schlechte Umsetzung.

Sie entstehen dadurch, dass sauber umgesetzt wird, was nie sauber hinterfragt wurde.

Eine technische Lösung kann hervorragend programmiert, perfekt getestet und pünktlich veröffentlicht werden – und trotzdem am eigentlichen Bedarf vorbeigehen.

Deshalb ist eine meiner wichtigsten Fragen in digitalen Projekten sehr einfach:

Ist das wirklich die Anforderung – oder sprechen wir gerade schon über die Lösung?

Diese Trennung kann den gesamten weiteren Projektverlauf verändern.

Digital besser entscheiden beginnt oft genau dort.

Von der Frage zum Projekt

Du erkennst die Situation aus deinem eigenen Projekt?

Dann lohnt sich der Blick auf die konkrete Situation: von der unabhängigen Zweitmeinung bis zur laufenden Steuerung auf Auftraggeberseite.

Bereit für klarere Entscheidungen?

Digital besser entscheiden.

Du musst nicht jede Technologie verstehen. Aber jemand auf deiner Seite sollte den Überblick behalten.

Digital. Auf deiner Seite.

VIERZWO

Unabhängig
Pragmatisch
Auftraggeberseite