Briefing: Schaubild „Systemübersicht mit Forschungskern"
Dieses Dokument ist vollständig und ohne weiteres Projektwissen verwendbar. Alle Beschriftungen sind wörtlich zu übernehmen — bitte keine Texte umformulieren oder ergänzen, die Formulierungen sind mit dem Antragstext abgestimmt.
1. Kontext (für Sie als Ersteller:in)
Busflow ist eine Software für Busreiseveranstalter: Buchung, Sitzplatzvergabe, Disposition von Fahrzeugen und Fahrern, Bezahlung, Fahrgast-Kommunikation und steuerliche Abrechnung — auch wenn Geräte unterwegs (im Bus, im Funkloch) zeitweise ohne Internetverbindung arbeiten.
Die Grafik ist Anlage zu einem Antrag auf Forschungszulage (deutsche steuerliche Forschungsförderung). Ein Gutachter der Bescheinigungsstelle prüft: Was an diesem Projekt ist gewöhnliche Softwareentwicklung — und was ist echte Forschung und Entwicklung mit ungewissem Ausgang? Genau diese Trennlinie soll die Grafik ziehen.
Die Kernidee: Wir zeigen das gesamte System bewusst in Grau („das ist verfügbare Standardtechnik, das behaupten wir nicht als Forschung") und heben nur vier Stellen farbig hervor — die Stellen, deren Ergebnis zu Projektbeginn nicht vorhersagbar ist. Das ehrliche Zugeständnis im Grauen macht die vier farbigen Stellen glaubwürdig.
2. Format und Zielbild
- Eine Seite, DIN A4 quer, Export als PDF (zusätzlich die editierbare Quelldatei mitliefern).
- Erfassbar in unter 30 Sekunden: ein Betrachter ohne IT- und Steuerwissen muss sofort sehen: „Das meiste ist Standard — an diesen vier Stellen ist das Ergebnis offen."
- Flaches, schematisches Diagramm (Kästen, Linien). Keine Fotos, keine Cliparts, keine 3D-Effekte, keine Icons mit Eigenleben. Ein kleines stilisiertes Bus-Piktogramm bei der Fahrer-App ist erlaubt, mehr Illustration nicht.
3. Titel und Legende (wörtlich übernehmen)
Titel (oben):
Busflow — Systemübersicht: Standardtechnik und Forschungskern
Legende (unten, zwei Einträge):
▢ grau — Stand der Technik: verfügbare Standardtechnik, keine Forschung ▣ farbig — Forschungskern: Ergebnis war zu Projektbeginn nicht vorhersagbar
4. Aufbau: drei graue Schichten
Alle folgenden Komponenten in Grautönen (z. B. zwei bis drei abgestufte Grauflächen auf Weiß), Beschriftungen wörtlich:
Schicht 1 — Kanäle und Endgeräte (oben):
- „Webbuchung (Kunde)"
- „Büro / Telefon (Veranstalter)"
- „Agentur / Reisebüro"
- „Fahrer-App: Einlass-Scan, Bordverkauf" ← an dieser Komponente sitzt später Hervorhebung 2
Schicht 2 — Anwendungsschicht (Mitte):
- „Buchungs- und Kundenverwaltung (Standardfunktionen)"
- „Disposition: Fahrzeuge und Fahrer einplanen"
- „Zahlungsabwicklung (externer Anbieter)"
- „Rechnungs- und Belegerstellung"
- „Nachrichtenversand an Fahrgäste (E-Mail/SMS)" ← davor sitzt später Hervorhebung 4
- „API-Schicht (GraphQL/Hasura)" — Technologienamen hier bewusst nennen: sie zeigen, dass Standardtechnik verwendet wird
- „Web-Oberfläche (Vue)"
Schicht 3 — Datenschicht (unten):
- „Datenbank (PostgreSQL)"
- Innerhalb der Datenbank zwei sichtbar voneinander getrennte Bereiche zeichnen, beschriftet „Daten Busunternehmen A" und „Daten Busunternehmen B", mit der Unterschrift „strikte Trennung der Daten verschiedener Kundenfirmen" ← über diese Trennlinie hinweg sitzt später Hervorhebung 3
- „Protokollierung"
Verbindungslinien schlicht: Endgeräte → Anwendungsschicht → Datenschicht. Die Fahrer-App-Verbindung zur Anwendungsschicht gestrichelt zeichnen und mit „zeitweise ohne Netz" beschriften.
Wenn der Platz knapp wird: graue Komponenten zusammenfassen oder weglassen — niemals die vier Hervorhebungen kürzen.
5. Die vier Hervorhebungen (der eigentliche Inhalt)
Jede Hervorhebung ist ein farbiger Kasten (eine einzige Akzentfarbe für alle vier, z. B. ein kräftiges Orange) mit drei Textebenen:
- Kennung + Titel (fett)
- Ungewissheit — beginnt immer mit „Ergebnis zu Projektbeginn nicht vorhersagbar, weil …"
- Abgrenzung — kursiv, beantwortet „Warum nicht mit Standardmethoden lösbar?"
Texte wörtlich übernehmen:
Hervorhebung 1 — die größte und zentralste, ca. doppelt so prominent wie die anderen drei. Position: in der Anwendungsschicht, zwischen Buchungsverwaltung, Zahlungsabwicklung und Datenbank.
AP2 — Preis- und Margenermittlung unter zeitlicher Datenunvollständigkeit
Ergebnis zu Projektbeginn nicht vorhersagbar, weil offen ist, ob sich früh erzeugte, rechtsverbindliche Zwischenwerte nachweisbar dem erst nach der Reise feststehenden Endwert annähern lassen — ein negatives Ergebnis ist möglich.
Standardverfahren der Bilanzierung korrigieren Schätzwerte nur Buchung für Buchung. Hier verteilt ein Storno die Fixkosten über viele Buchungen neu, und gedeckelte Einzelmargen machen die Summe nicht-linear.
Hervorhebung 2. Position: auf der gestrichelten Verbindung zwischen Fahrer-App und Anwendungsschicht.
AP3a — Datenabgleich nach Netzausfall
Ergebnis zu Projektbeginn nicht vorhersagbar, weil unklar ist, ob Konflikte — etwa ein offline gescanntes, inzwischen storniertes Ticket — regelbasiert auflösbar sind, ohne die gesetzliche Unveränderbarkeit der Daten zu verletzen.
Übliche Abgleichverfahren werden ohne durchgehende Verbindung nur „irgendwann gleich" und dürfen Daten überschreiben — beides ist hier ausgeschlossen.
Hervorhebung 3. Position: in der Datenschicht, über der Trennlinie zwischen „Daten Busunternehmen A" und „Daten Busunternehmen B" — der Kasten überspannt beide Bereiche sichtbar.
AP4 — Mandantenübergreifende Prüfung der Lenk- und Ruhezeiten
Ergebnis zu Projektbeginn nicht vorhersagbar, weil offen ist, ob die gesetzliche Ruhezeit-Bilanz eines Fahrers, der für mehrere Busunternehmen fährt, berechenbar ist, obwohl das Datenmodell nur die Daten je eines Unternehmens sieht.
Die strikte Datentrennung verbietet genau den Zugriff, den die Prüfung braucht — und darf trotzdem nicht aufgeweicht werden.
Hervorhebung 4. Position: in der Anwendungsschicht, als Prüfstufe vor dem Kasten „Nachrichtenversand an Fahrgäste" (Pfeil läuft durch die Hervorhebung hindurch).
AP6 — Geprüfte KI-Ausgaben für kritische Inhalte
Ergebnis zu Projektbeginn nicht vorhersagbar, weil offen ist, ob sich erfundene Ausgaben von KI-Sprachmodellen durch mehrstufige Prüfungen so weit senken lassen, dass weder falsche Datenbankeinträge noch falsche Aussagen in sicherheitskritischen Fahrgastnachrichten entstehen.
KI-Sprachmodelle liefern keine garantiert richtigen Ausgaben; ohne Prüfverfahren gelangen erfundene Inhalte ungefiltert in Datenbank und Nachrichten.
6. Gestaltungsvorgaben
- Farben: Weiß als Grund, zwei bis drei Grautöne für das System, eine Akzentfarbe für alle vier Hervorhebungen. Keine weiteren Farben.
- Schrift: eine serifenlose Schrift; Fließtext in den Hervorhebungen nicht unter ~9 pt. Alles muss im A4-Ausdruck ohne Zoomen lesbar sein.
- Sprache: durchgehend Deutsch. Englische Begriffe nur dort, wo sie oben wörtlich vorgegeben sind (GraphQL/Hasura, Vue, App, API).
- Nichts hinzuerfinden: keine zusätzlichen Komponenten, Pfeile oder Texte über dieses Briefing hinaus. Bei Platzproblemen oder Unklarheiten bitte rückfragen statt improvisieren.
7. Abnahmekriterien
Die Grafik ist fertig, wenn:
- Beim ersten Blick die vier farbigen Kästen ins Auge springen und alles andere sichtbar zurücktritt.
- AP2 (Hervorhebung 1) erkennbar das Zentrum ist — größter Kasten, zentralste Position.
- Alle Texte exakt den Vorgaben aus Abschnitt 3–5 entsprechen.
- Eine fachfremde Person nach 30 Sekunden den Satz wiedergeben kann: „Das meiste ist Standardtechnik, an vier Stellen ist das Ergebnis offen."
- PDF (DIN A4 quer, eine Seite) und editierbare Quelldatei vorliegen.