Ein einseitiges Briefing für ein maßgeschneidertes Dispositions- und Abrechnungssystem

Was Entwickler tatsächlich von Ihnen brauchen: Eine Seite, kein Pflichtenheft

Der Projektumfang (Scope) bestimmt, was eine Entwicklung beinhaltet und was sie bewusst auslässt. Eine Formulierungshilfe – kein vorgeschriebenes Format – ist eine einzige Seite, deren endgültige Form mit der Agentur vereinbart wird. Eine mögliche Struktur umfasst vier Blöcke: eine Prozesslandkarte des aktuellen Ablaufs, fünf bis acht User Stories, Pass/Fail-Akzeptanzkriterien für jede Story sowie einfache Rahmenbedingungen und eine „Nicht in v1“-Liste. Betrachten Sie diese Blöcke als illustrativ, nicht als das Briefing selbst.

Niro Digital hat keine Fallstudie aus einem vergleichbaren Betriebs- oder Logistikprojekt bereitgestellt. Dieses Arbeitsblatt und das ausgearbeitete Beispiel sind daher eine allgemeine Formulierungshilfe und eine konstruierte Veranschaulichung, kein Beweis dafür, dass die Struktur aus realisierter Kundenarbeit stammt. Der von Niro Digital angebotene Service für maßgeschneiderte Software beschreibt die entwickelten Systeme als CRMs, Dashboards, Mitarbeiter-Tools und Logistiksysteme, die genau auf die Arbeitsweise eines Unternehmens zugeschnitten sind. Sie können diese Beschreibung auf der custom software development page nachlesen.

Zuerst: Skizzieren Sie einen Auftrag vom Telefonat bis zur Rechnung

Dieser Artikel ist ein allgemeines Arbeitsblatt zur Vorbereitung, kein Erfahrungsbericht aus der Projektabwicklung von Niro Digital. Wählen Sie einen wiederkehrenden Auftrag und verfolgen Sie ein einzelnes Beispiel davon, nicht die geschäftigste Woche. Notieren Sie für jeden Schritt vier Dinge: Wer etwas tut, welche Daten gelesen oder eingegeben werden, welches Tool oder welchen Kanal sie nutzen und wo Arbeit liegen bleibt oder Daten erneut eingegeben werden. Kein Diagramm. Eine Zeile pro Schritt reicht völlig aus.

Die ausgefüllten Zeilen unten sind eine konstruierte Veranschaulichung für Sie, keine Beschreibung einer Kundenbeziehung von Niro Digital; tragen Sie Ihre eigenen Schritte und Tools ein.

Zählen Sie die Duplikate und Wartezeiten; das sind Ihre Ziele für die Automatisierung.

Lassen Sie die Kosten pro Berührung entscheiden, was in v1 einfließt

Eine Berührung (Touch) ist jedes Mal, wenn eine Person Daten liest, eingibt oder kopiert. Bewerten Sie jede Berührung danach, wie oft sie vorkommt, wie lange sie dauert und ob die Daten bereits an anderer Stelle existieren.

Unter Verwendung der konstruierten Veranschaulichung, nicht Ihrer realen Zahlen: Wenn die erneute Auftragserfassung 10 Minuten pro Auftrag dauert und das Büro 12 Stunden pro Woche mit dem Kopieren abgeschlossener Aufträge verbringt, sind diese 12 Stunden bezahlte Arbeitszeit für das Verschieben von Daten, die bereits im Auftragsblatt vorhanden sind. Wenn die Rechnungsstellung eine Woche wartet, weil der Lieferstatus nur per Telefon eintrifft, finanziert diese Wartezeit die Lücke. Ersetzen Sie jede Zahl durch Ihre eigenen gemessenen Werte, bevor Sie eine Entscheidung treffen.

Betrachten Sie die drei Bewertungen als optionale Fragen für ein Gespräch mit der Agentur, nicht als feste Regel, die über v1 entscheidet. Fragen Sie, welche Berührungen am häufigsten vorkommen, am längsten dauern oder bereits vorhandene Daten kopieren, und welche davon eine Agentur innerhalb Ihres Budgets von €20,000–€30,000 zuerst automatisieren würde. Bitten Sie darum, die Kosten für diese Kandidaten zu schätzen, bevor der Projektumfang festgelegt wird. Vergleichen Sie diese Obergrenze mit den indikativen Preisspannen, die Niro Digital auf seiner Preisseite veröffentlicht; diese Spannen spiegeln typische Projekte wider. Siehe die pricing page.

Schreiben Sie nun fünf bis acht User Stories in Geschäftssprache

Eine User Story ist ein einzelner Satz in der Form: „Als [Rolle] möchte ich [etwas, das das System tut], um [Geschäftsergebnis] zu erreichen.“ Sie wird Story genannt, weil sie eine Aufgabe aus der Sicht einer Person beschreibt, nicht weil sie vage sein darf. Ein Briefing für Disposition/Abrechnung könnte solche Stories enthalten:

• Als Disponent möchte ich, dass sich der Auftragsstatus aktualisiert, wenn ein Fahrer die Lieferung bestätigt, damit ich abrechnen kann, ohne auf einen Anruf zu warten.
• Als Büroadministrator möchte ich, dass bei Bestätigung der Lieferung ein Rechnungsentwurf aus den Auftragszeilen erstellt wird, damit ich denselben Auftrag nicht erneut in die Abrechnungsdatei eintippen muss.
• Als Inhaber möchte ich sehen, welche Aufträge mit den Fahrern unterwegs und welche ausgeliefert sind, damit ich Kunden antworten kann, ohne den Disponenten anzurufen.

Schreiben Sie nur die Stories, die eine Berührung, eine Wartezeit oder einen Fehler aus Ihrer Prozesslandkarte entfernen. Wenn Sie mehr als acht haben, verschieben Sie die überzähligen jetzt auf die „Nicht in v1“-Liste.

Machen Sie aus jeder User Story einen Pass/Fail-Test, den der Entwickler demonstrieren kann

Akzeptanzkriterien sind die Bedingungen, die Sie in einer Demo testen: Jedes Kriterium wird entweder bestanden (Pass) oder nicht bestanden (Fail), ohne Ermessensspielraum.

Bitten Sie den Entwickler in der Demo, jedes Kriterium mit einem Beispielauftrag durchzuspielen. Wenn einer von Ihnen darüber diskutieren muss, ob es bestanden wurde, schreiben Sie es um. Wenn Sie [X] nicht selbst festlegen können, vereinbaren Sie es vor der Unterschrift mit der Agentur.

Diese Pass/Fail-Gewohnheit entspricht der von Niro Digital veröffentlichten KI-Automatisierungsdoktrin: „Wir vertrauen Modellausgaben niemals blind. Jede Automatisierung wird mit deterministischen Verifizierungsprüfungen, Budgetobergrenzen und menschlichen Freigabeschritten für unumkehrbare Aktionen ausgeliefert. Wir bauen Systeme, in denen KI-Ausgaben als Behauptung behandelt werden, die Prüfungen bestehen muss, bevor sie als erledigt gilt.“

Benennen Sie die Rahmenbedingungen in einfacher Sprache

Dies sind Rahmenbedingungen, keine Funktionen. Ein Entwickler benötigt sie, um den Aufwand abzuschätzen, aber Sie können sie so formulieren, wie Sie es einem Kollegen erklären würden.

• Benutzer und Geräte: Zum Beispiel acht Büroangestellte am Desktop, Fahrer mit Telefonen während der Touren.
• Geschwindigkeit: Nachdem der Fahrer die Lieferung bestätigt hat, sollte der Disponent dies bei normaler Büronutzung innerhalb von [X] Sekunden sehen; schreiben Sie das Demokriterium so und nicht als „sofort“. Die Eingabe eines Auftrags darf das Büro nicht blockieren. Legen Sie [X] selbst fest; wenn Sie das nicht können, vereinbaren Sie es vor der Unterschrift mit der Agentur.
• Rollen: Disponenten sehen alle Aufträge, Fahrer sehen nur ihre zugewiesenen Touren und der Buchhalter sieht die Rechnungs- und VAT-Felder.
• Dateneigentum: Sie besitzen die Daten und können sie in einem gängigen Format wie CSV exportieren.
• Sicherheit und Datenzugriff: Legen Sie fest, wer auf Kunden-, Liefer- und Rechnungsdaten zugreifen darf, ob der Zugriff beim Ausscheiden von Mitarbeitern entzogen werden muss und welche Backups und Wiederherstellungen Sie erwarten. Bitten Sie die Agentur, vor der Entwicklung zu klären, welche GDPR- und Sicherheitsanforderungen gelten; dies ist keine Rechts- oder Compliance-Beratung.
• Rechnungsstellung und VAT: Listen Sie auf, welche Felder die Rechnung enthalten muss, und besprechen Sie diese mit Ihrem Buchhalter. Lokale Rechnungsstellungs- und VAT-Regeln ändern sich, und dies ist keine Steuerberatung.

Schreiben Sie die „Nicht in v1“-Liste, bevor Sie irgendetwas unterschreiben

Betrachten Sie die Liste als schriftliche Abgrenzung des Projektumfangs für die Diskussion mit einer Agentur, nicht als Entscheidungsregel. Formulieren Sie jeden Punkt als „nicht in v1, später möglich“. Beispielhafte Ausschlüsse:

• Nicht in v1: Automatische Routenoptimierung – der Disponent teilt die Touren weiterhin manuell zu; das System erfasst die Zuweisung.
• Nicht in v1: Eine vollwertige Fahrer-App – Fahrer nutzen eine einfache mobile Seite für den Lieferstatus, nicht für Navigation oder Fotofunktion.
• Nicht in v1: Komplexe Finanzanalysen – geben Sie sich mit einer Liste fälliger Aufträge und ausgestellter Rechnungen zufrieden, statt eines Dashboards für die Marge pro Route.

Beschränken Sie sich auf drei bis fünd Ausschlüsse. Wenn eine Funktion später unverzichtbar wird, wird sie zu einem Change Request, nicht zu einem Fehler.

Ihr einseitiges Briefing

Kopieren Sie den folgenden Block auf eine einzige Seite und nutzen Sie ihn als Formulierungshilfe: Eine mögliche Art, ein erstes Gespräch über Anforderungen zu strukturieren. Dies ist nicht die einzige Form, die ein Briefing annehmen kann, und Sie vereinbaren die endgültige Form mit der Agentur. Wireframes, Screendesigns oder Datenbankschemata werden in dieser Phase nicht von Ihnen erwartet.

• Sicherheit und Daten: Legen Sie fest, wer auf Kunden-, Liefer- und Rechnungsdaten zugreifen darf; ob der Zugriff beim Ausscheiden von Mitarbeitern entzogen werden muss; und welche Backups und Wiederherstellungen Sie erwarten. Bitten Sie die Agentur vor der Entwicklung zu klären, welche GDPR- und Sicherheitsanforderungen gelten. Dies ist keine Rechts- oder Compliance-Beratung.

Das Arbeitsblatt für Disposition/Abrechnung und das ausgearbeitete Beispiel in diesem Artikel sind konstruierte Veranschaulichungen für den Leser, keine Beschreibung einer Kundenbeziehung von Niro Digital oder eines gemessenen Ergebnisses.

Nutzen Sie das One-Pager-Briefing, um das Angebot einer Agentur zu prüfen, und fragen Sie dann nach dem Change-Management

Ein Angebot sollte das Briefing beantworten, nicht ersetzen. Bevor Sie unterschreiben, prüfen Sie vier Dinge: Es beschreibt Ihr tatsächliches Problem, es listet die Annahmen auf, die die Entwickler treffen, es trennt den festen Projektumfang von Extras und es nennt das, was nicht enthalten ist.

• Welche Annahmen treffen Sie über unseren aktuellen Prozess?
• Was ist in der Schätzung nicht enthalten?
• Wenn wir nach dem Kick-off einen fehlenden Schritt entdecken, wie wird eine Änderung kalkuliert und freigegeben?
• Können Sie jedes Akzeptanzkriterium demonstrieren, bevor die Abschlussrechnung fällig ist?

Change-Management (Change Control) ist lediglich der vereinbarte Prozess zur Entscheidung darüber, was passiert, wenn sich eine Anforderung ändert: Was wird aufgeschrieben, wer gibt es frei und wie verschiebt sich das Budget. Anforderungen werden sich nach dem Kick-off weiterentwickeln; das ist normal. Das Risiko ist nicht die Entdeckung neuer Anforderungen, sondern die grenzenlose Entdeckung.

Nehmen Sie das One-Pager-Briefing mit in das nächste Gespräch mit einer Agentur. Wenn Sie möchten, dass Niro Digital es prüft, nutzen Sie das contact form und erwähnen Sie, dass Sie ein einseitiges Briefing vorbereitet haben. Der Zweck dieses Telefonats ist es zu prüfen, ob der Projektumfang in Ihr Budget passt und welcher Schritt zuerst digitalisiert werden sollte – nicht, Ihnen auf der Stelle ein System zu verkaufen.