„Wir brauchen eine Auftragsverwaltung.“ Damit ist die Aufgabe benannt, aber noch lange nicht beschrieben. Wer legt einen Auftrag an? Wer darf ihn freigeben? Und was passiert, wenn sich nach der Freigabe noch etwas ändert?
Bevor ich Formulare baue, brauche ich Antworten auf diese Fragen. In den Antworten steckt meist mehr Arbeit als in den Eingabefeldern selbst.
Wie wird heute gearbeitet?
Ein Lastenheft ist ein guter Anfang. Daneben lohnt sich ein Blick darauf, wie die Beteiligten ihre Arbeit tatsächlich erledigen. Wer bekommt welche Information? Wo wird etwas doppelt erfasst? Welche Ausnahme kommt so oft vor, dass sie eigentlich zum normalen Ablauf gehört?
Mir hilft dabei mein Einblick in Industrie, Bau, Handwerk und die Abläufe eines Hosting-Unternehmens. Die Begriffe unterscheiden sich. Übergaben, Zuständigkeiten und Rückfragen spielen aber überall eine Rolle.
Ein Beispiel: Für die Werkstatt kann ein Auftrag fertig sein, sobald die Arbeit erledigt ist. Für die Verwaltung fehlen vielleicht noch Unterlagen oder eine Freigabe. Wenn die Software dafür nur einen einzigen Status „fertig“ kennt, sind Missverständnisse schon angelegt.
Was bedeutet ein Begriff im konkreten Betrieb?
Bei Begriffen wie „Auftrag“, „Buchung“ oder „Freigabe“ lohnt sich genaues Nachfragen. Wer darüber spricht, sollte dasselbe darunter verstehen. Das gilt für die Oberfläche ebenso wie für das Datenmodell.
Domain-driven Design, kurz DDD, hilft mir dabei, diese Fachlichkeit im Code abzubilden. Zu einem Auftrag gehören Regeln: welche Änderungen erlaubt sind, wer sie ausführen darf und welche Folgen sie haben. Die sollten sich im Modell wiederfinden.
Wie aufwendig die Architektur dafür sein muss, hängt vom Projekt ab. Stecken fachliche Entscheidungen verstreut in Formularen und Datenbankabfragen, wird jede neue Regel aufwendig. Dann müssen erst alle betroffenen Stellen gefunden werden.
Was muss die Oberfläche im nächsten Schritt zeigen?
Mit Laravel, Livewire und Filament lassen sich Verwaltungsoberflächen zügig umsetzen. Die Technik nimmt einem aber nicht die Entscheidung ab, was auf einem Bildschirm stehen sollte.
Jemand, der einen Auftrag freigibt, braucht andere Informationen als jemand, der Material dazu erfasst. Wenn beide dieselbe lange Feldliste sehen, müssen sie sich ihren Arbeitsschritt jedes Mal selbst zusammensuchen.
Deshalb schaue ich mir lieber einzelne Aufgaben an: Was braucht die Person gerade? Was darf sie ändern? Welche Rückmeldung benötigt sie danach? Daraus ergibt sich oft eine übersichtlichere Oberfläche.
Wenn Buchhaltung und Software aufeinandertreffen
Bei Angeboten, Rechnungen und Zahlungen kommen Fragen dazu, die sich nicht allein über die Bedienoberfläche lösen lassen. Beispielsweise, welche Daten nach einer Freigabe noch geändert werden dürfen und wie eine Korrektur nachvollziehbar bleibt.
Hier hilft kaufmännisches Verständnis, die richtigen Rückfragen zu stellen. Die fachlichen Vorgaben müssen mit den zuständigen Personen geklärt werden. Im Datenmodell können sie dann von Anfang an berücksichtigt werden, statt später als Sonderfälle dazuzukommen.
Den Ablauf gemeinsam durchspielen
Beim Testen gehören für mich auch die Rückfrage, die abgelehnte Freigabe und die nachträgliche Änderung dazu. An diesen Stellen zeigt sich, ob die Anwendung zum Arbeitsalltag passt.
Wenn die Beteiligten ihren eigenen Ablauf darin wiedererkennen und mit den Ausnahmen zurechtkommen, ist das für mich ein guter Maßstab.