Wann ein Fachkonzept vor Individualsoftware nötig ist

Ein Fachkonzept für Individualsoftware ist sinnvoll, wenn ein Vorhaben mehrere Rollen, Ausnahmen, Entscheidungen oder angebundene Systeme betrifft und die Beteiligten den Ablauf noch unterschiedlich beschreiben. Es verhindert nicht jede spätere Änderung, schafft aber eine gemeinsame Grundlage für Prioritäten, Aufwand und Umsetzung. Für einen kleinen, klar abgegrenzten Prozess reicht oft eine knappe Prozessbeschreibung mit Beispieldaten; für geschäftskritische Abläufe sollte die fachliche Klärung deutlich gründlicher sein.

Ein Fachkonzept ist keine lange Vorab-Dokumentation

Mit Fachkonzept ist hier keine möglichst umfangreiche Spezifikation gemeint. Gemeint ist eine verständliche Beschreibung dessen, was ein Prozess leisten soll, wer ihn ausführt, welche Informationen dabei entstehen und welche Regeln gelten. Sie soll Fachseite, Entwicklung und spätere Verantwortliche in die Lage versetzen, dieselbe Lösung zu meinen.

Der Umfang muss zum Risiko passen. Wenn zwei Mitarbeitende interne Notizen zu einem bestehenden Datensatz ergänzen, ist ein gemeinsamer Workshop mit einer kurzen Beschreibung häufig ausreichend. Wenn ein System Dokumente entgegennimmt, Prüfungen auslöst, Entscheidungen vorbereitet und Daten an weitere Systeme übergibt, reichen Annahmen aus einzelnen Gesprächen meist nicht aus.

Wichtig ist die Reihenfolge: Zuerst wird der fachliche Zweck geklärt, dann die passende technische Umsetzung. Wer früh über Frameworks, Masken oder einzelne Automatisierungsschritte spricht, kann unbemerkt ungeklärte Zuständigkeiten und widersprüchliche Regeln in Software übersetzen.

Daran erkennen Sie den Klärungsbedarf

Ein Konzept ist besonders angezeigt, wenn der heutige Ablauf auf Wissen einzelner Personen beruht. Typische Signale sind Rückfragen wie „Was passiert bei einem unvollständigen Fall?“, „Wer darf diese Entscheidung korrigieren?“ oder „Welche Angabe gilt, wenn zwei Systeme unterschiedliche Werte zeigen?“. Solche Fragen sind keine technischen Details, sondern bestimmen das Verhalten der Anwendung.

• Mehrere Teams oder externe Beteiligte arbeiten am selben Vorgang.
• Der Prozess enthält Freigaben, Prüfungen, Fristen oder Eskalationen.
• Daten werden zwischen bestehenden Systemen ausgetauscht oder mehrfach gepflegt.
• Fehlerhafte Entscheidungen können operative, finanzielle oder rechtliche Folgen haben.
• Es gibt viele Sonderfälle, aber keine gemeinsame Regel, wie damit umzugehen ist.
• Das Projekt soll schrittweise umgesetzt werden und braucht eine belastbare Reihenfolge für die erste Version.

Nicht nötig ist ein umfangreiches Fachkonzept allein deshalb, weil Software entwickelt wird. Ein Prototyp zur Erprobung einer Bedienidee, ein enges Importwerkzeug oder eine einmalige Datenbereinigung können bewusst schlank vorbereitet werden. Voraussetzung ist, dass Zweck, Abgrenzung und verantwortliche Entscheidungsperson klar sind. Auch dann sollte festgehalten werden, welche Annahmen noch offen sind.

Diese Inhalte sollten vor dem Bau geklärt sein

Ein brauchbares Konzept beschreibt nicht jede Schaltfläche. Es beantwortet die Entscheidungen, die später nur mit zusätzlichem Aufwand korrigiert werden können. Dazu gehören insbesondere Prozessgrenzen, Datenverantwortung und der Umgang mit Ausnahmen.

1. Ziel und Abgrenzung: Welches betriebliche Problem soll gelöst werden? Was gehört ausdrücklich nicht in die erste Ausbaustufe?
2. Akteure und Rollen: Wer startet, bearbeitet, prüft, entscheidet und verwaltet den Prozess? Welche Rolle darf welche Handlung ausführen?
3. Ablauf und Zustände: Welche Schritte durchläuft ein Vorgang? Welche Ereignisse ändern seinen Status? Wann ist ein Vorgang abgeschlossen, abgebrochen oder erneut zu bearbeiten?
4. Daten und Quellen: Welche Angaben werden erfasst, welche nur angezeigt und welches System ist für welche Information fachlich maßgeblich?
5. Regeln und Ausnahmen: Welche Bedingungen lösen Prüfungen, Hinweise oder Übergaben aus? Wie wird entschieden, wenn Informationen fehlen, widersprüchlich sind oder nachträglich geändert werden?
6. Schnittstellen und Betrieb: Welche Systeme müssen angebunden werden? Wer bearbeitet fehlgeschlagene Übertragungen, Rückfragen und Korrekturen im Alltag?
7. Abnahme: Woran erkennen die fachlich Verantwortlichen anhand konkreter Fälle, dass die erste Version ihren Zweck erfüllt?

Diese Punkte müssen nicht zwingend in einem einzelnen Dokument stehen. Ein Prozessdiagramm, eine Tabelle mit Zuständen, kurze Regelbeschreibungen und priorisierte Beispielvorgänge können geeigneter sein als Fließtext. Entscheidend ist, dass offene Fragen sichtbar bleiben und Entscheidungen eine verantwortliche Person haben.

Praxisbeispiel: KYC-Prozess nicht nur als Upload-Maske denken

Angenommen, ein Unternehmen plant eine KYC-Lösung mit Dokumentenscanner, Face Match und Liveness-Check. Ohne fachliche Klärung wirkt die Aufgabe zunächst wie ein Formular mit externen Prüfdiensten. Tatsächlich beginnt die entscheidende Arbeit bei den Regeln rund um das Prüfergebnis.

Das Konzept sollte zum Beispiel festlegen, wann ein Fall automatisch akzeptiert wird, wann ein Mitarbeitender prüfen muss und welche Informationen dieser für seine Entscheidung sieht. Ebenso wichtig sind Fragen nach unleserlichen Dokumenten, abgebrochenen Prüfungen, erneuten Einreichungen und nachträglichen Korrekturen. Falls das Ergebnis an ein CRM, ein Kundenportal oder ein internes Vorgangssystem übergeben wird, muss klar sein, welches System welchen Status führt und wie Übertragungsfehler behandelt werden.

Die technische Auswahl folgt daraus. Erst wenn die fachlichen Zustände, Rollen und Übergaben verständlich sind, lässt sich sinnvoll beurteilen, ob eine vorhandene Komponente genügt, welche Schnittstellen nötig sind und welche Prüfschritte protokolliert werden müssen. Das reduziert nicht den Bedarf an Tests, verhindert aber, dass zentrale Prozessentscheidungen erst während der Entwicklung zufällig entstehen.

So erarbeiten Sie die passende Tiefe in kurzer Zeit

Statt ein Konzept über Wochen im kleinen Kreis zu schreiben, ist ein strukturierter Abgleich mit den Menschen sinnvoll, die den Prozess verantworten und täglich ausführen. Fachwissen aus der Praxis ist besonders wertvoll, weil dort Umwege, Sonderfälle und informelle Übergaben sichtbar werden.

1. Wählen Sie einen konkreten Vorgang als Ausgangspunkt, nicht ein abstraktes Systemziel.
2. Lassen Sie den heutigen Ablauf anhand eines echten, anonymisierten Falls erklären.
3. Markieren Sie Medienbrüche, Wartezeiten, Doppelpflege, Entscheidungen und häufige Ausnahmen.
4. Definieren Sie den Zielablauf für eine erste Ausbaustufe und benennen Sie bewusst vertagte Punkte.
5. Halten Sie Regeln, Verantwortlichkeiten und Datenquellen in einer prüfbaren Form fest.
6. Prüfen Sie das Ergebnis mit zwei oder drei realistischen Beispielszenarien, einschließlich eines Ausnahmefalls.
7. Leiten Sie daraus einen umsetzbaren Zuschnitt ab und prüfen Sie erst dann Architektur, Integrationen und Aufwand.

Für die Abstimmung genügt häufig ein Arbeitsformat, das fachliche Beteiligte ohne Übersetzung lesen können. Technische Details wie Datenbanktabellen oder konkrete API-Endpunkte gehören erst dann hinein, wenn sie für eine Entscheidung nötig sind. Die Entwicklung kann daraus später technische Konzepte ableiten, ohne dass die fachliche Verantwortung verschwimmt.

Typische Fehlannahmen und ihre Folgen

Die verbreitete Annahme „Wir kennen den Prozess doch“ trifft oft nur für den Normalfall zu. Software muss jedoch auch mit Abweichungen umgehen: Ein Datensatz fehlt, eine Freigabe bleibt aus, ein externer Dienst antwortet nicht oder eine Entscheidung wird korrigiert. Werden diese Fälle ignoriert, entstehen sie später als Supportaufwand, manuelle Umgehung oder kostspielige Nacharbeit.

Ebenso problematisch ist ein Fachkonzept, das jede denkbare Zukunftsanforderung vorwegnimmt. Es verzögert Entscheidungen und führt leicht zu einer überladenen ersten Version. Besser ist eine klare Trennung: Was muss der erste produktive Ablauf zuverlässig können, was ist eine begründete Folgeausbaustufe und was bleibt vorerst nur eine Idee?

Ein weiterer Fehler besteht darin, die Fachseite nach der Übergabe an die Entwicklung aus dem Projekt zu nehmen. Fachliche Verantwortliche sollten offene Regeln entscheiden, Zwischenergebnisse prüfen und anhand echter Fälle abnehmen. Entwicklungsteams wiederum müssen Unklarheiten sichtbar machen, statt sie stillschweigend technisch zu interpretieren.

Entscheidung: Konzept, Kurzklärung oder direkt starten?

Starten Sie direkt mit einer kleinen Umsetzung, wenn der Ablauf eng begrenzt ist, nur wenige Beteiligte hat, keine kritischen Entscheidungen automatisiert und leicht zurückgebaut werden kann. Wählen Sie eine Kurzklärung, wenn das Ziel eindeutig ist, aber Rollen, Datenquellen oder einzelne Ausnahmen abgestimmt werden müssen. Ein ausgearbeitetes Fachkonzept lohnt sich, wenn der Prozess geschäftskritisch ist, mehrere Systeme verbindet oder spätere Fehlinterpretationen nur schwer korrigierbar wären.

Das Fachkonzept ist damit kein Selbstzweck und kein Ersatz für iterative Entwicklung. Es ist ein Mittel, um vor der technischen Festlegung die richtigen Fragen zu beantworten. OnLouis kann solche Klärungen mit Prozessverantwortlichen strukturieren und daraus eine umsetzbare Grundlage für individuelle Software, Integrationen oder interne Tools entwickeln.