Ein Freigabeportal.
Ein klarer Lieferumfang.

Ein vollständiger Vorgang.
Von Anfang bis Ende.

Im Beispiel erhält ein Unternehmen eine deutschsprachige Web-Anwendung für bis zu 50 benannte Nutzer. Ein Antrag enthält Titel, Begründung, Kostenstelle, geschätzten Nettobetrag in Euro und gewünschten Termin. Jede Einreichung bekommt eine eindeutige Nummer.

• Erfassen: Entwurf speichern, eigene Anträge wieder öffnen und vollständig einreichen. Fehlende Pflichtangaben werden am jeweiligen Feld erklärt.
• Prüfen: Die zuständige Person sieht die eingereichten Anträge ihrer Kostenstelle und kann sie freigeben, begründet zurückgeben oder begründet ablehnen.
• Nachverfolgen: Listen mit Filtern nach Status, Kostenstelle und Zeitraum; ein Verlauf mit handelnder Person, Zeitpunkt und Entscheidung.
• Weitergeben: Der Einkauf sieht freigegebene Anträge, exportiert sie als CSV und bestätigt anschließend ausdrücklich ihre Übernahme. Ein Export allein setzt keinen Übernahmestatus.
• Benachrichtigen: E-Mail-Hinweise auf neue Aufgaben und Entscheidungen. Das Portal bleibt der verbindliche Bearbeitungsstand; E-Mail-Ausfälle sind sichtbar und wiederholbar, ohne die Fachaktion nochmals auszuführen.

Nicht enthalten: ERP-Anbindung, Lieferantenbestellungen, Zahlungen, Dateianhänge, historische Datenmigration, mehrstufige Betragsfreigaben, Mehrsprachigkeit und eine native App. Diese Punkte werden nicht stillschweigend zum fertigen Portal hinzugerechnet.

Vorausgesetzt werden eine geeignete Test- und Betriebsumgebung, ein bereitgestellter Unternehmenslogin über OpenID Connect sowie ein freigegebener E-Mail-Versandweg. Die Einrichtung eines neuen Identitätsanbieters gehört nicht dazu. Fehlende Voraussetzungen werden vor der Entwicklungsfreigabe geklärt.

Wer darf welchen Schritt ausführen?

Antragstellende sehen ihre eigenen Anträge und bearbeiten nur Entwürfe oder zurückgegebene Vorgänge. Freigebende entscheiden ausschließlich für zugeordnete Kostenstellen und niemals über eigene Anträge. Dafür ist eine andere freigabeberechtigte Person zu benennen; ohne sie bleibt die Einreichung gesperrt und erklärt den fehlenden Zuständigkeitsweg.

Der Einkauf übernimmt freigegebene Anträge. Administrierende verwalten Rollen und Zuordnungen, erhalten dadurch aber kein fachliches Freigaberecht. Rechte werden bei jeder Aktion und jedem Datenabruf geprüft, auch bei direktem Aufruf einer fremden Antragsnummer.

Der Ablauf lautet: Entwurf → Eingereicht → Freigegeben oder Abgelehnt. Alternativ geht ein eingereichter Antrag zur Korrektur zurück und wird danach erneut eingereicht. Freigabe und Ablehnung sind unveränderliche Entscheidungen über die jeweilige eingereichte Fassung. Nachträgliche Änderungswünsche werden als neuer, mit dem ursprünglichen Vorgang verknüpfter Antrag erfasst.

„Vom Einkauf übernommen“ ist ein zusätzlicher Bearbeitungsstand eines freigegebenen Antrags. Er bedeutet weder „bestellt“ noch „bezahlt“. Auch eine später geänderte Rollenzuordnung ändert keine bereits dokumentierte Entscheidung.

Drei prüfbare Lieferstände.

1. Ablauf und Zugang: Rollen, Beispieldaten und offene Entscheidungen festhalten; Unternehmenslogin und E-Mail-Weg im Testsystem prüfen. Erst damit ist die Grundlage für eine belastbare Aufwandsschätzung vorhanden.
2. Durchgängiger Kern: Einen Antrag erfassen, einreichen, zurückgeben, erneut einreichen, freigeben und durch den Einkauf übernehmen. Bereits dieser Zwischenstand enthält Rechteprüfung, Verlauf und Schutz vor doppelter Verarbeitung.
3. Abnahme und Übernahme: Listen, Export, Fehlerfälle und vereinbarte Belastung prüfen; dokumentierten Stand bereitstellen, Rückweg und Wiederherstellung erproben und die Übergabe durch eine zweite Person durchführen.

Jeder Zwischenstand benennt Version, Testumgebung, funktionierende Abläufe und offene Mängel. Für ein vereinbartes Aufwandspaket gehören verbrauchter Aufwand, verbleibende Schätzung und Gesamtprognose zusammen. Ein zusätzlicher Freigabeschritt wird vor Umsetzung als Änderung bewertet; notwendige Fehlerkorrektur wird nicht automatisch zum Zusatzauftrag.

Das Beispiel nennt bewusst keinen pauschalen Preis oder Liefertermin. Zugangssystem, Betriebsumgebung, Rechteumfang und fachliche Ausnahmen müssen dafür konkret bekannt sein.

Der Nachweis endet beim gespeicherten Ergebnis.

Alle folgenden Fälle sind vorgeschlagene Prüfkriterien, noch keine durchgeführten Tests. Zum Protokoll gehören Testdaten, Rolle, Version, Schritte, erwartetes und tatsächliches Ergebnis sowie offene Abweichungen. Zeta prüft vor der fachlichen Kundenabnahme selbst.

A · Ein Antrag erreicht den Einkauf

Eine Mitarbeiterin speichert einen Entwurf über 850 Euro, öffnet ihn erneut und reicht ihn ein. Die zuständige Person gibt ihn frei. Der Einkauf findet genau diesen Antrag, exportiert ihn und bestätigt die Übernahme. Nach Neuanmeldung sind Betrag, Entscheidung und Übernahme unverändert vorhanden; im Verlauf stehen die jeweiligen Personen und Zeitpunkte.

B · Rückfrage und erneute Einreichung

Ein Antrag wird mit Begründung zurückgegeben. Die antragstellende Person korrigiert den Betrag und reicht erneut ein. Geprüft wird die neue Fassung; die ältere Fassung und Rückgabe bleiben im Verlauf nachvollziehbar. Ein bereits freigegebener Antrag lässt sich nicht nachträglich überschreiben.

C · Eigene oder fremde Anträge

Eine Freigabeperson versucht, den eigenen Antrag zu genehmigen; eine andere Nutzerin ruft eine fremde Antragsnummer direkt auf. Beide Zugriffe werden passend verweigert, ohne fremde Inhalte preiszugeben oder eine Entscheidung zu speichern. Eine Administration ohne zusätzliche Fachrolle kann ebenfalls nicht freigeben.

D · Doppelklick und konkurrierende Entscheidung

Ein doppeltes Einreichen erzeugt nur einen eingereichten Vorgang. Zwei Berechtigte öffnen dieselbe Fassung; eine Person gibt frei, die andere versucht anschließend abzulehnen. Nur die erste gültige Entscheidung wird gespeichert. Die zweite Person erhält einen verständlichen Hinweis auf den inzwischen geänderten Stand.

E · Verbindung oder Benachrichtigung fällt aus

Die Verbindung wird nach dem Absenden unterbrochen. Nach Wiederverbindung prüft die Anwendung den vorhandenen Vorgang, bevor erneut gesendet werden kann. Schlägt nur die E-Mail fehl, bleibt die gespeicherte Entscheidung gültig und im Portal sichtbar. Die Benachrichtigung wird getrennt erneut versucht; es entsteht keine zweite Entscheidung.

F · Leere, ungültige und größere Bestände

Leere Listen zeigen einen verständlichen Hinweis. Fehlende Kostenstelle und ungültige Beträge verhindern die Einreichung. Mit synthetischen 5.000 Anträgen und zehn gleichzeitig arbeitenden Nutzern werden Listen und Filter in der vereinbarten Testumgebung geprüft: als Beispielziel höchstens zwei Sekunden für 95 Prozent der Aufrufe. Messweg und Datenumfang gehören ins Protokoll; Unternehmenslogin und E-Mail-Laufzeiten werden getrennt ausgewiesen.

G · Einkauf bestätigt bewusst

Ein CSV-Export enthält nur die ausgewählten freigegebenen Vorgänge und korrekt formatierte Werte. Nach Export und erneuter Anmeldung ist noch kein Antrag als übernommen markiert. Erst die ausdrückliche Bestätigung setzt diesen Stand, dokumentiert die Person und verhindert eine unbemerkte doppelte Übernahme.

Abnahmeentscheidung: Rechteverletzungen, falsche Entscheidungen, Datenverlust oder doppelte Verarbeitung blockieren die Freigabe. Andere Abweichungen werden mit Auswirkung und vereinbartem Umgang festgehalten. Ein Bildschirmfoto, HTTP 200 oder eine erfolgreiche Demo allein ersetzt keinen bestandenen Ablauf. Vertragliche Abnahmeregeln werden gesondert vereinbart.

Eine zweite Person muss übernehmen können.

Zum vereinbarten Lieferpaket gehören Quellcode mit Versionshistorie und Release-Kennung, Build- und Bereitstellungsanleitung, Datenbankschema und Migrationen, Konfigurationsübersicht ohne Geheimnisse, Komponenten- und Lizenzübersicht, Rollenbeschreibung, Testprotokoll, bekannte Einschränkungen und eine kurze Bedienungsanleitung. Nutzungsrechte und Zugriffsübergabe werden vorab vertraglich festgelegt.

1. Neu aufbauen: Eine vorgesehene Vertretung baut die bezeichnete Version in einer getrennten Umgebung anhand der Anleitung auf. Auch Datenbankinitialisierung und notwendige manuelle Schritte werden ausgeführt. Die Erstautorin übernimmt nicht verdeckt die fehlenden Schritte.
2. Wiederherstellen: Synthetische Anträge, Rollen und Verlauf sichern; in eine isolierte Umgebung zurückspielen und mit dem Ausgangsbestand vergleichen. Benötigte Schlüssel und geschützte Konfiguration gehören zum Wiederherstellungsplan. Anschließend Login und ein vollständiger Freigabeablauf prüfen.
3. Rückweg prüfen: Ein fehlgeschlagenes Update samt Datenbankänderung durchspielen. Ein altes Programm allein reicht nicht, wenn es das neue Schema nicht versteht. Bei einer Rücksicherung mögliche seitdem erfasste Vorgänge berücksichtigen; keine stillen Datenverluste akzeptieren.
4. Verantwortung übernehmen: Betrieb, Updates, Zugriffsverwaltung, Sicherung und Störungsmeldung mit benannten Zuständigkeiten übergeben. Noch benötigte Hilfe und Abhängigkeiten bleiben sichtbar.

Die Übergabe gilt in diesem Beispiel erst als technisch nachgewiesen, wenn die zweite Person Aufbau und Wiederherstellung erfolgreich durchgeführt hat. Ein ZIP-Archiv oder ein Dokumentationslink allein genügt nicht. Noch fehlende Kundenumgebungsprüfungen bleiben ausdrücklich offen.

Nach der Bereitstellung beginnt der Alltag.

Vor dem Start bestätigt die fachverantwortliche Person die Abläufe und Zuständigkeiten, die IT den Betriebszugang und die vorgesehene Betriebsrolle die Übernahme. Zunächst nutzt eine Kostenstelle das Portal. Für diese Vorgänge ist festgelegt, ab wann das Portal statt der alten Liste verbindlich ist; parallele widersprüchliche Freigaben werden vermieden.

Sicherungsintervall, Aufbewahrung, tolerierbarer Datenverlust und Wiederanlaufzeit werden vor Produktivsetzung gemeinsam bestimmt und technisch geprüft. Ebenso müssen Meldeweg, Betreuungszeiten, Wartung und Zugriffsende für nicht mehr benötigte Konten geklärt sein. Entwicklung allein umfasst keine pauschale Rund-um-die-Uhr-Betreuung.

Ergebnis des vereinbarten Pakets: ein nutzbarer, geprüfter Freigabeablauf sowie eine praktisch nachvollziehbare Übergabe. Eine ERP-Anbindung kann später folgen, ist aber keine Voraussetzung dafür, dass dieses abgegrenzte Paket seinen Zweck erfüllt.

Auch diese Ergebnisbeschreibung ist fiktiv. Sie ist kein Nachweis einer realisierten Anwendung und keine Zusage gleicher Konditionen für andere Projekte.