Ein technisches Konzept übersetzt Aufgaben und Qualitätsanforderungen in einen begründeten Lösungsentwurf. Es muss zeigen, was geplant ist, welche Annahmen noch offen sind und wie die spätere Lösung geprüft werden soll.
1. Die Entscheidung benennen, nicht nur das System
Ein Konzept soll eine konkrete Entscheidung ermöglichen. Dazu gehören der betrachtete Umfang und die ausdrücklich nicht behandelten Teile. Ein Entwurf für eine Dokumentensuche ist nicht automatisch eine Architektur für das gesamte Unternehmen. Beginnen Sie mit den wichtigsten Nutzern, Eingaben und Ergebnissen. Kennzeichnen Sie, welche Randbedingungen bereits feststehen und welche erst geprüft werden. So können Leser unterscheiden, ob eine Aussage Anforderung, Vorschlag oder bestätigte Tatsache ist.
2. Anforderungen so schreiben, dass sie testbar werden
„Schnell“, „sicher“ und „benutzerfreundlich“ reichen für eine Abnahme nicht aus. Beschreiben Sie die relevante Aufgabe, die Nutzerrolle und das beobachtbare Ergebnis. Ergänzen Sie Mengen, Antwortzeiten und Fehlerbedingungen, soweit diese tatsächlich vereinbart werden können. Unbekannte Werte erhalten einen Prüfauftrag. Bei KI muss außerdem feststehen, woran fachliche Qualität beurteilt wird. Ein technisch korrekt ausgeführter Modellaufruf sagt noch nichts darüber aus, ob seine Antwort brauchbar ist.
Weitere Formate
Die Textfassung bleibt für technische Workflows und KI-Arbeitsaufträge verfügbar.
3. Datenfluss und Grenzen sichtbar machen
Zeichnen Sie die beteiligten Anwendungen und ihre Verbindungen. Ergänzen Sie Quelle, Verarbeitung, Speicherung und Ausgabe. Ein einzelner Kasten „KI“ verbirgt häufig mehrere Rollen: Dokumentaufbereitung, Suche, Modellaufruf und nachgelagerte Aktionen. Benennen Sie die jeweiligen Zugriffsrechte. Dasselbe gilt für klassische Software: Das führende System einer Information und der erlaubte Änderungsweg müssen erkennbar sein. Eine lesbare Übersicht ist wichtiger als eine möglichst beeindruckende Menge technischer Symbole.
4. Architekturentscheidungen begründen
Wesentliche Entscheidungen erhalten einen kurzen Nachweis: Ausgangsfrage, betrachtete Optionen, Gründe und Konsequenzen. Dazu kann die Wahl zwischen einem vorhandenen Programm, einer Erweiterung und einer individuellen Anwendung gehören. Ebenso relevant sind Cloud oder lokale Verarbeitung, Integrationswege und benötigte Betriebsrollen. Ein verworfener Ansatz sollte nicht wortlos verschwinden; sein Nachteil kann später wieder relevant werden. Verwenden Sie Entscheidungsprotokolle, um Wissen zu erhalten, statt es ausschließlich in Gesprächen zu lassen.
Weitere Formate
Die Textfassung bleibt für technische Workflows und KI-Arbeitsaufträge verfügbar.
5. Betrieb und Fehlerfälle nicht an den Schluss verschieben
Benennen Sie, was nach der Bereitstellung geschehen muss: Aktualisierungen, Sicherungen, Wiederherstellung, Lizenzen und technische Überwachung. Bei einem Fehler braucht es einen verantwortlichen Empfänger und genügend Informationen zur Bearbeitung. Für KI-Systeme kommen fachliche Qualitätsänderungen hinzu. Ein neues Modell oder eine geänderte Wissensquelle muss nicht dasselbe Verhalten zeigen wie die zuvor geprüfte Konfiguration. Vereinbaren Sie deshalb, welche Änderungen erneut bewertet werden.
6. Konzept und Angebot gegeneinander prüfen
Ordnen Sie jedem wichtigen Ergebnis einen Liefergegenstand und einen Nachweis zu. Prüfen Sie, ob externe Leistungen und Kundenzuarbeit tatsächlich berücksichtigt sind. Ein auffällig günstiges Angebot kann einen kleineren Umfang beschreiben, ohne technisch falsch zu sein. Erst ein vergleichbarer Betrachtungsraum erlaubt eine sinnvolle Bewertung. Trennen Sie dabei Korrekturen im vereinbarten Umfang von neuen Anforderungen.
| Frage | Benötigter Nachweis |
|---|---|
| Was entsteht? | Konkrete Funktion, Unterlage oder Konfiguration. |
| Was wird vorausgesetzt? | Zugänge, Daten, Schnittstellen und zuständige Rolle. |
| Woran wird geprüft? | Testfall mit erwartetem Ergebnis. |
| Wer entscheidet? | Benannte Abnahme- und Betriebsverantwortung. |
7. Einen fachlich verantworteten Übergabestand schaffen
Eine Übergabe bündelt Entscheidungen, offene Fragen, bekannte Grenzen und nächste Arbeitspakete. Sie ist nicht einfach eine Sammlung generierter Texte. Der technische Entwurf wird anhand der verfügbaren Informationen geprüft; fehlende Nachweise werden nicht als erledigt markiert. Spezialisierte Sicherheits- oder Rechtsfragen benötigen den passenden Prüfrahmen. Ein guter Konzeptstand macht genau sichtbar, was die nächste umsetzende oder entscheidende Person noch klären muss.
Arbeitsbeispiel: die Methode konkret anwenden
Ein fiktiver Auftrag soll eingehende Formulardaten in ein Kundenprogramm übertragen. Im ersten Entwurf steht lediglich „Anbindung per API“. Im überprüften Konzept werden zusätzlich der führende Kundenschlüssel, Pflichtfelder, der Umgang mit doppelten Eingängen und eine fehlende Bestätigung beschrieben. Das Testpaket enthält einen gültigen Eingang, eine Wiederholung und einen API-Ausfall. Erst wenn die erwarteten Ergebnisse für alle Fälle vereinbart sind, lässt sich ein Entwicklungsangebot sinnvoll gegen den Bedarf prüfen. Die Daten und Ergebnisse dieser Beschreibung sind ein Arbeitsbeispiel, keine Kundenreferenz.