Zehn Fragen, die aus einer guten Idee ein belastbares Projekt machen.

1.1 Einfache Erklärung

Ein Prozess ist eine wiederkehrende Folge von Arbeitsschritten, die zu einem bestimmten Ergebnis führt. Eine Kundenanfrage zu bearbeiten ist beispielsweise ein Prozess:

1. Die Anfrage geht ein.
2. Jemand liest sie.
3. Die enthaltenen Angaben werden geprüft.
4. Die Anfrage wird einer zuständigen Person zugeordnet.
5. Fehlende Angaben werden nachgefragt.
6. Eine Aufgabe oder ein Kundeneintrag wird angelegt.
7. Später wird geprüft, ob der Vorgang erledigt wurde.

Prozessautomatisierung bedeutet, dass ein Teil dieser Schritte von Software ausgeführt wird. Die Software reagiert auf ein festgelegtes Startsignal, verarbeitet Informationen nach beschriebenen Regeln und erzeugt ein bestimmtes Ergebnis.

Automatisiert wird also nicht einfach „die Büroarbeit“, sondern ein klar begrenzter Ablauf.

1.2 Die sieben Bestandteile eines automatisierbaren Ablaufs

Fast jeder geeignete Ablauf lässt sich mit sieben Fragen beschreiben:

Bestandteil	Einfache Frage	Beispiel
Startsignal	Wodurch beginnt der Ablauf?	Eine E-Mail geht ein.
Eingangsdaten	Welche Angaben liegen vor?	Name, Firma, Nachricht und Anhang
Arbeitsschritte	Was geschieht heute von Hand?	Lesen, zuordnen, übertragen
Entscheidungen	Wo muss zwischen mehreren Wegen gewählt werden?	Serviceanfrage oder Angebotsanfrage?
Ergebnis	Was soll am Ende entstanden sein?	Geordneter Vorgang mit Aufgabe
Ausnahme	Was geschieht bei einem Sonderfall?	Unlesbarer Anhang wird zur Prüfung vorgelegt.
Messwert	Woran erkennt man den Erfolg?	Zeit bis zur Zuordnung

Fehlt einer dieser Punkte, ist der Ablauf meist noch nicht ausreichend verstanden. Dann sollte nicht sofort programmiert werden.

1.3 Verschiedene Stufen der Automatisierung

Automatisierung ist kein Alles-oder-nichts-Schalter. Es gibt mehrere sinnvolle Stufen:

Stufe 1: Unterstützung

Die Software sammelt Informationen, der Mensch führt die eigentliche Arbeit aus. Beispiel: Alle offenen Anfragen werden morgens in einer Übersicht angezeigt.

Stufe 2: Vorbereitung

Die Software erledigt Vorarbeiten. Beispiel: Kontaktdaten werden aus einer E-Mail ausgelesen und als Entwurf für einen Kundeneintrag vorbereitet.

Stufe 3: Ausführung mit Freigabe

Die Software bereitet das Ergebnis vollständig vor, darf es aber erst nach einer menschlichen Bestätigung verwenden. Beispiel: Eine Rückfrage wird formuliert, aber erst nach Prüfung versendet.

Stufe 4: Selbstständige Ausführung in engen Grenzen

Eindeutig geregelte und risikoarme Schritte werden ohne einzelne Freigabe ausgeführt. Beispiel: Ein freigegebener Dateianhang wird nach festen Regeln umbenannt und in einen Projektordner verschoben.

Stufe 5: Weitgehend selbstständiger Gesamtprozess

Nur Ausnahmen werden einem Menschen vorgelegt. Diese Stufe ist möglich, erfordert aber stabile Regeln, gute Daten, ausführliche Tests und geringe Folgen bei einem Fehler. Für neue Kundenprojekte ist sie normalerweise nicht der Einstieg.

1.4 Ein durchgehendes Beispiel

Ein kleiner Elektrobetrieb erhält Anfragen an eine gemeinsame E-Mail-Adresse. Heute liest eine Bürokraft jede Nachricht, kopiert die Kontaktdaten in eine Tabelle, legt einen Ordner an und informiert den zuständigen Mitarbeiter.

Eine Automatisierung könnte so arbeiten:

1. Nur Nachrichten an die festgelegte Adresse werden verarbeitet.
2. Absender, Betreff, Nachricht und Anlagen werden übernommen.
3. Offensichtlicher Werbemüll wird aussortiert.
4. Die Art der Anfrage wird bestimmt.
5. Pflichtangaben wie Ort, gewünschte Leistung und Erreichbarkeit werden geprüft.
6. Ein neuer Vorgang wird angelegt oder einem vorhandenen Vorgang zugeordnet.
7. Eine zuständige Person erhält eine Aufgabe.
8. Bei fehlenden Angaben wird eine Rückfrage vorbereitet.
9. Jede Ausführung wird mit Ergebnis und Fehlerstatus protokolliert.

Wichtig ist: Nicht alle Schritte müssen künstliche Intelligenz verwenden. Das Speichern einer E-Mail-Adresse, das Setzen eines Fälligkeitsdatums oder die Prüfung eines Dateityps funktionieren zuverlässiger mit festen Regeln.

1.5 Welche Abläufe eignen sich?

Ein guter erster Ablauf:

• tritt mindestens mehrmals pro Woche auf,
• folgt überwiegend denselben Schritten,
• verwendet bereits digitale Daten,
• verursacht heute erkennbar Zeitaufwand oder Fehler,
• besitzt ein klar beschreibbares Ergebnis,
• hat eine verantwortliche Person,
• lässt sich bei einem Fehler vorübergehend wieder von Hand ausführen.

Schlecht geeignet sind zunächst Abläufe, die selten auftreten, ständig anders ablaufen, fast nur aus persönlicher Beurteilung bestehen oder bei denen ein einzelner Fehler schwere rechtliche, finanzielle oder gesundheitliche Folgen haben kann.

1.6 Der häufigste Denkfehler

Der häufigste Fehler ist, eine vorhandene Unordnung einfach schneller machen zu wollen. Wenn Verantwortlichkeiten unklar sind, Daten fehlen und jeder Mitarbeiter nach eigenen Regeln arbeitet, überträgt eine Automatisierung diese Probleme lediglich in Software.

Deshalb gilt:

Erst den Ablauf verstehen und vereinfachen, dann geeignete Schritte automatisieren.

Manchmal ist die beste Verbesserung keine neue Software, sondern ein einheitliches Formular, eine klare Zuständigkeit oder eine überflüssige Freigabe weniger.

1.7 Bedeutung für Konstellarum

Konstellarum verkauft keine allgemeine „Automatisierung“, sondern einen benannten Ablauf mit festem Anfang und Ende. Im Angebot sollte deshalb stehen:

• welcher Vorgang bearbeitet wird,
• welche Programme beteiligt sind,
• welche Schritte automatisch erfolgen,
• welche Entscheidungen beim Menschen bleiben,
• welche Sonderfälle ausdrücklich nicht enthalten sind,
• woran der Erfolg gemessen wird,
• wie der manuelle Ersatzweg aussieht.

Damit wird die Leistung für den Kunden verständlich, prüfbar und abnehmbar.

1.8 Kurze Prüfliste

Ein Ablauf ist ausreichend beschrieben, wenn folgende Fragen beantwortet sind:

• Was startet ihn?
• Welche Informationen werden benötigt?
• Welche Schritte sind immer gleich?
• Welche Ausnahmen kommen vor?
• Wer entscheidet bei Unklarheit?
• Was ist das gewünschte Ergebnis?
• Was passiert bei einem technischen Fehler?
• Welche Zahl zeigt später eine Verbesserung?

---

2.1 Der grundlegende Unterschied

Eine feste Regel arbeitet nach einem eindeutig vorgegebenen Zusammenhang:

Wenn Bedingung A erfüllt ist, führe Handlung B aus.

Beispiel: Wenn eine Anfrage das Feld „Wartung“ enthält, lege sie in der Aufgabenliste „Service“ ab.

Künstliche Intelligenz wird eingesetzt, wenn Inhalte nicht immer gleich aufgebaut sind und eine sprachliche oder inhaltliche Einordnung benötigt wird. Beispiel: Ein Kunde beschreibt in freier Sprache, dass eine Maschine ungewöhnliche Geräusche macht und gelegentlich ausfällt. Ein Sprachmodell kann daraus die wahrscheinliche Kategorie „Störung“ ableiten und die genannten Symptome zusammenfassen.

Der wichtigste Unterschied lautet:

• Eine feste Regel ist bestimmt: Gleiche Eingabe und gleiche Regel ergeben dasselbe Ergebnis.
• Ein KI-Modell ist wahrscheinlichkeitsbasiert: Es erzeugt ein plausibles Ergebnis, kann aber trotz verständlicher Eingabe falsch liegen.

KI versteht einen Text nicht auf dieselbe Weise wie ein erfahrener Mitarbeiter. Sie berechnet, welches Ergebnis anhand ihrer Verarbeitung wahrscheinlich passt. Das kann sehr nützlich sein, ist aber keine Garantie für Wahrheit oder Vollständigkeit.

2.2 Welche Aufgaben gehören zu festen Regeln?

Feste Regeln sind vorzuziehen, wenn etwas eindeutig prüfbar ist:

• Ist ein Pflichtfeld leer?
• Entspricht eine E-Mail-Adresse einem zulässigen Aufbau?
• Ist die Datei größer als die erlaubte Grenze?
• Ist das Fälligkeitsdatum überschritten?
• Existiert bereits ein Datensatz mit derselben Kundennummer?
• Darf diese Benutzerrolle auf den Ordner zugreifen?
• Wurde eine Nachricht bereits versendet?
• Liegt der Rechnungsbetrag über einer Freigabegrenze?

Auch Berechnungen, Fristen, Nummernkreise und Zugriffsrechte gehören grundsätzlich in feste Programmlogik und nicht in eine freie KI-Antwort.

2.3 Welche Aufgaben können für KI geeignet sein?

KI kann sinnvoll sein, wenn Sprache oder uneinheitlich aufgebaute Informationen verarbeitet werden müssen:

• freie Nachricht einem Thema zuordnen,
• längeren Text zusammenfassen,
• Angaben aus unterschiedlich formulierten Dokumenten herausarbeiten,
• einen Antwortentwurf nach einer freigegebenen Vorlage erstellen,
• ähnliche Formulierungen erkennen,
• einen unübersichtlichen Text in eine feste Datenstruktur übertragen.

Selbst dann sollte die KI eine kleine, genau beschriebene Aufgabe erhalten. „Bearbeite die gesamte Kundenanfrage“ ist zu ungenau. „Lies aus der Nachricht Name, Rückrufnummer, Ort, gewünschte Leistung und fehlende Pflichtangaben aus“ ist wesentlich besser prüfbar.

2.4 Das sinnvolle Zusammenspiel

In einem zuverlässigen Ablauf liegt die KI zwischen festen Kontrollen:

1. Regeln vor der KI: Zulässige Quelle, Dateityp, Größe und Pflichtangaben werden geprüft.
2. Kleine KI-Aufgabe: Der Text wird eingeordnet oder zusammengefasst.
3. Regeln nach der KI: Das Ergebnis muss dem vorgeschriebenen Aufbau entsprechen.
4. Plausibilitätsprüfung: Unmögliche oder widersprüchliche Werte werden abgelehnt.
5. Risikoprüfung: Bei Unsicherheit oder hoher Tragweite wird ein Mensch eingeschaltet.
6. Erst danach folgt eine Aktion: Speichern, Aufgabe anlegen oder Entwurf anzeigen.

Beispiel: Die KI liest aus einer Nachricht einen gewünschten Termin aus. Eine feste Regel prüft anschließend, ob das Datum überhaupt existiert, in der Zukunft liegt und innerhalb der Geschäftszeiten liegt. Die KI darf nicht selbst bestimmen, dass der Termin verbindlich zugesagt ist.

2.5 Eine einfache Entscheidungshilfe

Frage	Wenn „Ja“	Wenn „Nein“
Lässt sich die Aufgabe vollständig mit klaren Bedingungen beschreiben?	Feste Regeln verwenden.	KI kann geprüft werden.
Muss freie Sprache verstanden werden?	KI kann hilfreich sein.	Meist reichen Regeln.
Ist das Ergebnis mathematisch oder rechtlich eindeutig?	Nicht der KI überlassen.	KI-Einsatz eventuell möglich.
Hätte ein Fehler erhebliche Folgen?	Menschliche Freigabe vorsehen.	Eng begrenzte automatische Ausführung denkbar.
Kann das Ergebnis automatisch geprüft werden?	Automatisierung wird sicherer.	Mehr menschliche Prüfung nötig.
Gibt es genug typische und schwierige Testfälle?	KI-Leistung kann bewertet werden.	Erst Daten und Beispiele sammeln.

2.6 Unsicherheit sichtbar machen

Eine KI kann sehr überzeugend formulieren und trotzdem falsch liegen. Deshalb darf ein freundlich geschriebener Text nicht mit einem sicheren Ergebnis verwechselt werden.

Unsicherheit lässt sich praktisch behandeln durch:

• festgelegte Kategorien statt völlig freier Antworten,
• vorgeschriebene Ausgabeformate,
• Quellenangaben bei wissensbezogenen Antworten,
• Vergleich mit vorhandenen Stammdaten,
• Markierung fehlender oder widersprüchlicher Angaben,
• Weiterleitung unbekannter Fälle an einen Menschen,
• regelmäßige Stichproben bereits automatisch bearbeiteter Fälle.

Eine vom Modell ausgegebene Prozentzahl für „Sicherheit“ ist dabei nicht automatisch verlässlich. Entscheidend ist die tatsächlich gemessene Fehlerquote an realistischen Testfällen.

2.7 Beispiel: Angebotsanfrage

Eine Nachricht lautet: „Wir brauchen an unserer Anlage vermutlich einen neuen Umrichter. Können Sie nächste Woche vorbeikommen? Bilder sind angehängt.“

Die Aufgabenverteilung könnte sein:

• KI: Erkennt „Service/Anlagenprüfung“, fasst den Bedarf zusammen und findet den Zeitwunsch.
• Feste Regel: Prüft, ob Kontaktdaten, Standort und Anlagentyp vorhanden sind.
• Feste Regel: Verhindert, dass Anhänge mit unzulässigem Dateityp geöffnet werden.
• KI: Formuliert eine Rückfrage zu den fehlenden Angaben.
• Mensch: Prüft die Rückfrage und entscheidet, ob ein Termin angeboten werden kann.
• Feste Regel: Protokolliert den Versand und setzt eine Erinnerung.

Damit wird KI dort eingesetzt, wo Sprache flexibel ist. Verantwortung, Berechtigungen und verbindliche Zusagen bleiben fest geregelt.

2.8 Bedeutung für Konstellarum

Konstellarum sollte für jeden KI-Schritt dokumentieren:

• Warum reichen feste Regeln nicht aus?
• Welche genaue Aufgabe erhält das Modell?
• Welche Daten werden übermittelt?
• Welches Ausgabeformat ist erlaubt?
• Welche Fehler sind bekannt?
• Wie wird das Ergebnis geprüft?
• Wann wird ein Mensch eingeschaltet?
• Was kostet ein Aufruf ungefähr?
• Wie kann das Modell später ausgetauscht werden?

Das freiwillige KI-Risikomanagement-Rahmenwerk des US-amerikanischen NIST empfiehlt, Risiken über den gesamten Lebenszyklus zu steuern, zu messen und menschliche Aufsicht passend zum Anwendungsfall festzulegen. Es ist kein deutsches Gesetz, bietet aber eine brauchbare methodische Orientierung. [Q1]

2.9 Kurze Prüfliste

• Kann der Schritt mit festen Regeln gelöst werden?
• Ist die KI-Aufgabe klein und eindeutig beschrieben?
• Kann eine falsche Ausgabe erkannt werden?
• Gibt es typische, schwierige und absichtlich fehlerhafte Testfälle?
• Ist festgelegt, was bei Unsicherheit geschieht?
• Darf die KI nur vorbereiten oder auch handeln?
• Sind Datenumfang, Kosten und Anbieter dokumentiert?

---

3.1 Was ein Pilot ist

Ein Pilotprojekt ist ein begrenzter Praxistest vor der vollständigen Einführung. Dabei wird nicht nur gezeigt, dass eine Idee technisch grundsätzlich funktioniert. Es wird geprüft, ob sie mit realistischen Daten, echten Sonderfällen und den Arbeitsbedingungen des Kunden zuverlässig genug arbeitet.

Der Pilot beantwortet vor allem vier Fragen:

1. Löst die Automatisierung das richtige Problem?
2. Funktioniert sie technisch unter realistischen Bedingungen?
3. Wird der Ablauf von den Beschäftigten verstanden und angenommen?
4. Ist der Nutzen groß genug, um Einrichtung und laufenden Betrieb zu bezahlen?

Ein Pilot ist damit weder eine kostenlose Vorführung noch bereits das fertige Produktivsystem.

3.2 Abgrenzung ähnlicher Begriffe

Begriff	Zweck	Typische Daten	Darf verbindlich handeln?
Vorführung	Idee anschaulich zeigen	künstliche Beispieldaten	Nein
Technischer Versuch	Einzelne technische Frage klären	Testdaten	Nein
Pilot	Gesamtannahmen in begrenztem echten Einsatz prüfen	Testdaten und ausgewählte Echtdaten	Nur innerhalb klarer Grenzen
Produktivbetrieb	Regelmäßige Arbeit des Unternehmens unterstützen	Echtdaten	Nach vereinbarten Freigaberegeln

Diese Unterscheidung verhindert falsche Erwartungen. Eine ansprechende Vorführung kann ideale Daten verwenden und alle Sonderfälle auslassen. Ein Pilot muss gerade zeigen, wie das System mit unvollständigen, doppelten oder ungewöhnlichen Vorgängen umgeht.

3.3 Ein Pilot braucht eine enge Grenze

Der Umfang sollte in einem Satz beschreibbar sein, zum Beispiel:

Der Pilot verarbeitet vier Wochen lang ausgewählte Angebotsanfragen aus einem Postfach, übernimmt sechs festgelegte Angaben in eine Testtabelle und bereitet bei fehlenden Angaben eine Rückfrage zur menschlichen Freigabe vor.

Damit sind mehrere Grenzen gesetzt:

• ein Eingangskanal,
• eine Anfrageart,
• eine begrenzte Laufzeit,
• eine festgelegte Zahl von Datenfeldern,
• ein Zielsystem,
• keine selbstständige externe Kommunikation.

Wenn gleichzeitig E-Mail, Websiteformular, Dokumentenablage, Angebotserstellung, Kalender und Rechnungswesen umgebaut werden, ist es kein kleiner Pilot mehr.

3.4 Erfolg vor dem Start definieren

Der Pilot darf nicht erst im Nachhinein danach bewertet werden, ob er sich „gut angefühlt“ hat. Vor dem Start werden messbare Kriterien festgelegt.

Beispiel:

• mindestens 90 Prozent der vorgesehenen Anfragen werden technisch verarbeitet,
• mindestens 85 Prozent werden richtig eingeordnet,
• keine Nachricht wird ohne Freigabe versendet,
• ein Vorgang wird niemals doppelt angelegt,
• die durchschnittliche manuelle Bearbeitungszeit sinkt von 20 auf höchstens 10 Minuten,
• jeder Fehler erscheint innerhalb von fünf Minuten in einer Meldung,
• die gesamten externen Nutzungskosten bleiben unter 20 Euro.

Diese Werte sind nur Beispiele. Die sinnvollen Grenzen hängen vom Prozess und von den Folgen eines Fehlers ab.

3.5 Die fünf Phasen eines Piloten

Phase 1: Ausgangslage erfassen

Der bisherige Ablauf wird beobachtet und gemessen. Ohne Ausgangswert kann später keine Einsparung nachgewiesen werden.

Phase 2: Testfälle festlegen

Es werden normale Fälle, Sonderfälle und fehlerhafte Fälle gesammelt. Dazu gehören etwa fehlende Telefonnummern, mehrere Anliegen in einer Nachricht, doppelte E-Mails, ungewöhnliche Anhänge und Antworten auf alte Vorgänge.

Phase 3: Geschützter Test

Die Lösung arbeitet zunächst mit künstlichen oder kopierten Testdaten. Externe Nachrichten und Änderungen an echten Datensätzen sind gesperrt.

Phase 4: Begrenzter Echtbetrieb

Nur ausgewählte Vorgänge werden verarbeitet. Ergebnisse werden kontrolliert, bevor sie Folgen auslösen. Der alte Ablauf bleibt als Ersatz verfügbar.

Phase 5: Auswertung und Entscheidung

Gemessen werden technische Zuverlässigkeit, Fehler, eingesparte Zeit, verbleibender Kontrollaufwand, Fremdkosten und Rückmeldungen der Beschäftigten.

3.6 Mögliche Ergebnisse

Ein Pilot muss nicht zwingend zur vollständigen Einführung führen. Es gibt vier ehrliche Ergebnisse:

1. Einführen: Die Ziele wurden erreicht.
2. Anpassen und erneut prüfen: Der Nutzen ist erkennbar, aber einzelne Schwächen müssen behoben werden.
3. Begrenzen: Nur ein Teil des geplanten Ablaufs ist wirtschaftlich oder zuverlässig genug.
4. Beenden: Aufwand, Risiko oder Kosten sind höher als der Nutzen.

Auch ein beendeter Pilot kann wertvoll sein, wenn er eine größere Fehlinvestition verhindert. Der Kunde bezahlt deshalb für eine belastbare Prüfung und nicht für eine vorab versprochene Erfolgsgarantie.

3.7 Was im Pilotvertrag stehen sollte

• genauer Umfang und Laufzeit,
• verwendete Systeme und Daten,
• erlaubte und gesperrte Aktionen,
• Verantwortlichkeiten auf beiden Seiten,
• Erfolgskriterien,
• Umgang mit Fehlern,
• Kostenobergrenzen,
• Datenschutz und Löschung der Testdaten,
• Ergebnisdokumentation,
• Bedingungen für Abbruch und Übergang in den Produktivbetrieb.

3.8 Bedeutung für Konstellarum

Der Pilot ist das zentrale Einstiegsprodukt. Er verringert das Risiko des Kunden und schützt zugleich Konstellarum vor einem unklaren Großprojekt.

Ein guter Pilot liefert am Ende nicht nur einen funktionierenden Ablauf, sondern auch:

• eine dokumentierte Prozessbeschreibung,
• eine Liste der getesteten Fälle,
• gemessene Vorher-Nachher-Werte,
• bekannte Grenzen,
• eine Aufwandsschätzung für den Produktivbetrieb,
• eine klare Empfehlung.

3.9 Kurze Prüfliste

• Ist der Pilot in einem Satz abgrenzbar?
• Sind Start- und Enddatum festgelegt?
• Gibt es einen Ausgangswert?
• Sind Erfolg und Misserfolg messbar definiert?
• Sind externe Aktionen zunächst gesperrt oder freigabepflichtig?
• Gibt es einen manuellen Ersatzweg?
• Sind Kosten und Datenmenge begrenzt?
• Ist die Entscheidung nach dem Pilot bereits vorgesehen?

---

4.1 Einfache Erklärung

Ein Kundendaten-System ist eine zentrale, geordnete Verwaltung von Kontakten und den zugehörigen Vorgängen. Häufig wird dafür die englische Abkürzung CRM verwendet. Sie steht für „Customer Relationship Management“, also die Verwaltung von Kundenbeziehungen.

Es handelt sich nicht nur um ein digitales Adressbuch. Ein brauchbares System beantwortet zum Beispiel:

• Wer ist der Kunde?
• Welche Ansprechpartner gibt es?
• Welche Anfrage wurde gestellt?
• Wer ist im eigenen Unternehmen zuständig?
• Was wurde bereits besprochen oder versendet?
• Welche Aufgabe ist als Nächstes fällig?
• Gibt es ein offenes Angebot?
• Welche Einwilligungen, Sperren oder Aufbewahrungsregeln gelten?

Das System muss nicht zwingend ein großes besonderes Programm sein. Zum Einstieg kann es auch eine sauber aufgebaute Fachsoftware oder eine geeignete Datenbank sein. Eine frei bearbeitete Tabelle stößt jedoch schnell an Grenzen, wenn mehrere Personen gleichzeitig arbeiten, Rechte benötigt werden oder Änderungen nachvollziehbar sein müssen.

4.2 Der Unterschied zwischen Kontakt, Unternehmen und Vorgang

Diese drei Dinge werden häufig vermischt:

• Unternehmen: zum Beispiel „Mustertechnik GmbH“.
• Kontaktperson: zum Beispiel „Frau Meier, technische Leitung“.
• Vorgang: zum Beispiel „Anfrage zur Wartung von Anlage 3“.

Ein Unternehmen kann mehrere Kontaktpersonen und viele Vorgänge haben. Eine Kontaktperson kann ihre Telefonnummer ändern, ohne dass dadurch ein neuer Vorgang entsteht. Ein Vorgang kann abgeschlossen werden, während die Kundenbeziehung bestehen bleibt.

Wenn alles nur als einzelne Zeile in einer Tabelle gespeichert wird, werden Firmendaten häufig für jeden Vorgang erneut eingetragen. Dadurch entstehen widersprüchliche Schreibweisen, alte Telefonnummern und doppelte Datensätze.

4.3 Die zentrale verlässliche Stelle

Für wichtige Angaben sollte festgelegt sein, welches System als maßgebliche Quelle gilt. Man kann dies als zentrale verlässliche Stelle bezeichnen.

Beispiel:

• Kontaktdaten werden im Kundendaten-System gepflegt.
• Termine werden im Kalender gepflegt.
• Angebote werden in der kaufmännischen Software gepflegt.
• Dokumente liegen in der Dokumentenablage.

Die Automatisierung verbindet diese Stellen. Sie sollte nicht unkontrolliert neue Nebenlisten erzeugen. Sonst ist nach kurzer Zeit unklar, welche Telefonnummer oder welcher Bearbeitungsstand richtig ist.

4.4 Welche Daten wirklich benötigt werden

Mehr Daten sind nicht automatisch besser. Für einen Anfrageprozess könnten genügen:

• eindeutige Vorgangsnummer,
• Unternehmen oder Privatkunde,
• Name und erreichbare Kontaktdaten,
• Eingangskanal und Eingangsdatum,
• gewünschte Leistung,
• Kurzbeschreibung,
• zuständige Person,
• Bearbeitungsstand,
• nächster Schritt und Fälligkeit,
• Verweis auf zugehörige Dokumente.

Zusätzliche Daten sollten nur gespeichert werden, wenn ein klarer Arbeitszweck besteht. Das erleichtert Bedienung, Datenschutz, Datenpflege und spätere Automatisierung.

4.5 Bearbeitungsstände statt freier Merkzettel

Ein Vorgang sollte einen klaren Zustand besitzen, zum Beispiel:

1. Neu eingegangen
2. Angaben unvollständig
3. Fachliche Prüfung
4. Angebot in Vorbereitung
5. Angebot versendet
6. Rückmeldung ausstehend
7. Beauftragt
8. Abgelehnt
9. Abgeschlossen

Für jeden Zustand kann festgelegt werden, welche Angaben vorhanden sein müssen und was als Nächstes geschehen darf. Dadurch lässt sich vermeiden, dass ein Angebot als versendet markiert wird, obwohl keine Empfängeradresse vorhanden ist.

4.6 Doppelte Datensätze richtig behandeln

Automatisierungen dürfen nicht einfach bei jeder E-Mail einen neuen Kunden anlegen. Ein Abgleich kann mehrere Merkmale verwenden:

• Kundennummer,
• genaue E-Mail-Adresse,
• Telefonnummer,
• Firmenname und Anschrift,
• vorhandene Vorgangsnummer im Betreff.

Ein eindeutiger Treffer kann automatisch zugeordnet werden. Mehrere mögliche Treffer werden einem Menschen angezeigt. Ein unsicherer Abgleich darf nicht stillschweigend zwei Personen zusammenführen, weil dadurch Daten beim falschen Kunden landen könnten.

4.7 Beispiel im technischen Dienstleistungsbetrieb

Eine Anfrage geht ein. Das System findet anhand der Absenderadresse bereits die Firma, aber zwei mögliche Ansprechpartner. Die Automatisierung:

1. legt noch keinen neuen Kontakt an,
2. erstellt einen neuen Vorgang unter der vorhandenen Firma,
3. markiert die Kontaktperson als unklar,
4. übernimmt nur eindeutig erkannte Angaben,
5. legt eine Aufgabe zur Prüfung an,
6. verknüpft nach Freigabe die Nachricht und den Anhang mit dem Vorgang.

So spart die Technik Arbeit, ohne eine unsichere Zuordnung als Tatsache zu behandeln.

4.8 Rechte und Nachvollziehbarkeit

Nicht jeder Beschäftigte muss alle Kundendaten sehen oder verändern können. Ein gutes System unterscheidet mindestens:

• lesen,
• neu anlegen,
• ändern,
• löschen,
• exportieren,
• Benutzer und Rechte verwalten.

Wichtige Änderungen sollten nachvollziehbar sein: Wer hat wann den Bearbeitungsstand, die Zuständigkeit oder eine Adresse geändert? Das ist für Fehlerklärung, Datenschutz und Zusammenarbeit wichtig.

4.9 Bedeutung für Konstellarum

Konstellarum muss vor jeder Verbindung klären:

• Welches System ist für welche Information maßgeblich?
• Welche Felder sind Pflichtfelder?
• Welche Werte sind erlaubt?
• Wie werden doppelte Einträge erkannt?
• Welche Benutzerrolle darf was?
• Wie werden Änderungen protokolliert?
• Wann werden Daten gelöscht oder gesperrt?
• Was geschieht, wenn das Zielsystem nicht erreichbar ist?

Erst danach sollte die automatische Übertragung eingerichtet werden. Sonst wird aus einer Zeitersparnis schnell eine Quelle neuer Datenfehler.

4.10 Kurze Prüfliste

• Sind Unternehmen, Kontaktperson und Vorgang getrennt?
• Gibt es für jede wichtige Angabe eine maßgebliche Quelle?
• Sind Pflichtfelder und erlaubte Werte definiert?
• Gibt es klare Bearbeitungsstände?
• Werden mögliche Doppelungen erkannt?
• Sind Rechte begrenzt?
• Sind Änderungen nachvollziehbar?
• Gibt es Regeln für Aufbewahrung und Löschung?

---

5.1 Was damit gemeint ist

Menschliche Freigabe bedeutet, dass eine verantwortliche Person ein vorbereitetes Ergebnis prüft, bevor daraus eine wichtige Handlung entsteht.

Beispiele:

• Ein Antwortentwurf wird vor dem Versand gelesen.
• Ein ausgelesener Rechnungsbetrag wird vor der Buchung bestätigt.
• Ein möglicher doppelter Kundeneintrag wird vor dem Zusammenführen geprüft.
• Ein vorbereiteter Preis wird vor der Aufnahme in ein Angebot freigegeben.

Die Freigabe ist nicht nur ein zusätzlicher Knopf. Sie ist ein bewusst gestalteter Kontrollpunkt mit einer klaren Frage: Was genau muss der Mensch erkennen und entscheiden?

5.2 Warum menschliche Kontrolle nötig bleibt

Automatische Systeme können Fehler machen, weil:

• Eingangsdaten unvollständig oder falsch sind,
• eine Regel einen unbekannten Sonderfall nicht abdeckt,
• eine KI einen Text falsch einordnet,
• sich ein Programm oder Datenformat geändert hat,
• ein technisch richtiges Ergebnis im geschäftlichen Zusammenhang unpassend ist.

Ein Mensch kann Zusammenhänge berücksichtigen, die dem System fehlen: einen laufenden Streitfall, eine besondere Kundenvereinbarung oder ein ungewöhnliches Sicherheitsrisiko.

Das NIST-Rahmenwerk für KI-Risikomanagement empfiehlt, Umfang und Zuständigkeit menschlicher Aufsicht passend zu Fähigkeiten, Grenzen und Risiken des Systems zu dokumentieren. [Q1]

5.3 Drei Risikostufen

Eine einfache Einteilung hilft, nicht jeden Schritt gleich streng zu behandeln.

Grün: automatische Ausführung möglich

Ein Fehler ist leicht erkennbar und einfach rückgängig zu machen.

Beispiele:

• interne Aufgabe anlegen,
• Datei nach einem geprüften Muster benennen,
• interne Tagesübersicht erzeugen,
• Erinnerung an einen zuständigen Mitarbeiter senden.

Gelb: vorbereiten, dann freigeben

Ein Fehler könnte Kunden irritieren, Arbeitszeit verursachen oder falsche Daten erzeugen.

Beispiele:

• externe E-Mail versenden,
• Kundendaten ändern,
• Dokument einem Vorgang zuordnen,
• Termin vorschlagen.

Rot: Entscheidung bleibt vollständig beim Menschen

Ein Fehler kann erhebliche finanzielle, rechtliche, persönliche oder sicherheitsbezogene Folgen haben.

Beispiele:

• verbindlichen Preis oder Vertrag freigeben,
• Zahlung auslösen,
• rechtliche oder medizinische Bewertung abgeben,
• Bewerber oder Beschäftigte beurteilen,
• sicherheitskritischen Maschinenbefehl ausführen.

Die Einstufung ist keine allgemeingültige Rechtskategorie. Sie ist eine praktische Methode für die Projektplanung.

5.4 Eine gute Freigabeoberfläche

Damit eine Person sinnvoll prüfen kann, benötigt sie nicht nur das vorgeschlagene Ergebnis. Sie braucht den Zusammenhang:

• die ursprüngliche Nachricht oder Datei,
• die vom System erkannten Angaben,
• markierte Unsicherheiten,
• den vorgeschlagenen Text oder die geplante Aktion,
• sichtbare Änderungen gegenüber vorhandenen Daten,
• eine verständliche Begründung oder Regel,
• Möglichkeiten zum Freigeben, Korrigieren oder Ablehnen.

Wenn der Prüfer zwischen fünf Programmen wechseln und die Ausgangsdaten selbst zusammensuchen muss, wird die Freigabe langsam und fehleranfällig.

5.5 Kontrollmüdigkeit vermeiden

Muss ein Mitarbeiter täglich hundert fast identische Ergebnisse bestätigen, klickt er irgendwann nur noch weiter. Die menschliche Kontrolle besteht dann auf dem Papier, wirkt aber praktisch nicht mehr.

Gegenmaßnahmen:

• nur wirklich prüfbedürftige Fälle vorlegen,
• Unterschiede und Unsicherheiten deutlich markieren,
• eindeutige Fälle nach einer erfolgreichen Testphase automatisieren,
• Prüffragen knapp und konkret formulieren,
• Freigaben nach Risiko staffeln,
• zufällige Qualitätsstichproben statt vollständiger Prüfung bei risikoarmen Fällen,
• Fehler und Korrekturen auswerten.

5.6 Freigabe und Verantwortung

Die Freigabe darf nicht so gestaltet sein, dass ein Beschäftigter formal haftet, ohne die nötigen Informationen, Zeit oder Befugnisse zu besitzen. Deshalb muss festgelegt werden:

• welche Rolle freigeben darf,
• was diese Person prüfen muss,
• welche Informationen sie erhält,
• wie mit Zweifeln umzugehen ist,
• wer bei Abwesenheit zuständig ist,
• wie die Entscheidung protokolliert wird.

Bei Anwendungen, die unter besondere gesetzliche Vorschriften fallen, reicht eine frei erfundene interne Freigaberegel möglicherweise nicht aus. Dann ist fachliche oder rechtliche Prüfung erforderlich.

5.7 Beispiel: Rückfrage an einen Kunden

Das System erkennt, dass für ein Angebot die Seriennummer einer Anlage fehlt. Es erstellt eine Rückfrage.

Die Freigabeansicht zeigt:

• ursprüngliche Anfrage,
• vorhandene Angaben,
• fehlendes Feld „Seriennummer“,
• vorbereiteten Text,
• Empfängeradresse,
• geplanten Versandzeitpunkt.

Der Mitarbeiter kann:

• unverändert freigeben,
• den Text anpassen,
• weitere Frage ergänzen,
• Versand ablehnen,
• den Vorgang an einen Kollegen weitergeben.

Die Korrektur wird gespeichert. Wenn viele Mitarbeiter immer dieselbe Ergänzung vornehmen, kann der Standardtext später verbessert werden.

5.8 Freigabe ist nicht immer rechtlich vorgeschrieben

Konstellarum sollte menschliche Kontrolle aus dem tatsächlichen Risiko ableiten. Nicht jeder automatisch erzeugte Text braucht zwingend eine Einzelprüfung. Umgekehrt darf eine menschliche Freigabe nicht als pauschale Lösung für jedes rechtliche oder technische Risiko dargestellt werden.

Seit dem 2. August 2026 ist die EU-Verordnung über künstliche Intelligenz grundsätzlich anwendbar; einzelne Vorschriften und Übergangsfristen unterscheiden sich. Pflichten zur menschlichen Aufsicht betreffen insbesondere bestimmte risikoreiche Systeme, während Transparenzpflichten nach Artikel 50 vom konkreten Einsatz abhängen. Jede Anwendung muss daher einzeln eingeordnet werden. [Q2]

5.9 Bedeutung für Konstellarum

Für jeden automatisierten Schritt sollte in der Prozessbeschreibung eine von drei Angaben stehen:

• automatische Ausführung,
• menschliche Freigabe vor Ausführung,
• vollständig menschliche Entscheidung.

Zusätzlich werden Freigaberolle, Prüfinhalt, Reaktionszeit, Vertretung und Protokollierung festgelegt. Dadurch wird „der Mensch bleibt verantwortlich“ von einem Werbesatz zu einem echten Arbeitsablauf.

5.10 Kurze Prüfliste

• Welche Folge hätte ein Fehler?
• Ist die Handlung rückgängig zu machen?
• Was genau soll der Mensch prüfen?
• Sieht er Ausgangsdaten und geplante Änderung gemeinsam?
• Hat er genug Zeit, Wissen und Befugnis?
• Werden Korrekturen ausgewertet?
• Kann Kontrollmüdigkeit entstehen?
• Ist die Freigabe technisch protokolliert?

---

6.1 Worum es geht

Eine Wirtschaftlichkeitsrechnung beantwortet die Frage, ob der erwartete Nutzen einer Automatisierung größer ist als ihre gesamten Kosten und Risiken.

Es reicht nicht zu sagen: „Die Software spart Zeit.“ Entscheidend ist:

• Wie viel Zeit wird heute tatsächlich benötigt?
• Wie viel davon kann realistisch entfallen?
• Wie viel neue Kontroll- und Pflegearbeit entsteht?
• Welche einmaligen und laufenden Kosten fallen an?
• Welche Fehler werden vermieden oder neu verursacht?
• Wann hat sich die Anfangsinvestition ausgeglichen?

Als allgemeiner Hintergrund ermittelte KfW Research für mittelständische Unternehmen im Durchschnitt sieben Prozent der Arbeitszeit beziehungsweise 32 Stunden je Unternehmen und Monat für gesetzlich bedingte Verwaltungsaufgaben. Dieser Wert ist kein Maß für automatisch einsparbare Zeit: Viele Tätigkeiten bleiben gesetzlich oder praktisch notwendig. Er zeigt vielmehr, warum der Aufwand im konkreten Kundenprozess gemessen werden muss. [Q5]

6.2 Ausgangswerte messen

Vor dem Pilot sollten mindestens zwei bis vier Wochen lang einfache Ausgangswerte gesammelt werden:

• Anzahl der Vorgänge,
• durchschnittliche Bearbeitungszeit,
• Wartezeit bis zur ersten Reaktion,
• Zahl notwendiger Rückfragen,
• Zahl überfälliger oder vergessener Vorgänge,
• Korrektur- und Fehlerquote,
• beteiligte Mitarbeiterrollen.

Schätzungen sind möglich, sollten aber als Schätzungen gekennzeichnet werden. Besonders hilfreich ist eine kleine Stichprobe: Zehn oder zwanzig echte Vorgänge werden mit einer einfachen Stoppuhr oder Zeitaufschreibung beobachtet.

6.3 Gesamtkosten betrachten

Zu den Kosten gehören nicht nur Einrichtung und monatliche Betreuung.

Einmalige Kosten

• Prozessaufnahme,
• Pilot,
• produktive Einrichtung,
• Datenbereinigung,
• Schulung,
• interne Arbeitszeit des Kunden,
• gegebenenfalls neue Software oder Hardware.

Laufende Kosten

• Betreuung und Überwachung,
• Serverbetrieb,
• KI-Nutzung,
• Nachrichten- oder Dokumentendienste,
• Lizenzen,
• menschliche Kontrollen,
• Pflege bei Prozessänderungen,
• interne Zuständigkeit.

Risikokosten

Nicht jeder mögliche Schaden lässt sich exakt in Euro ausdrücken. Trotzdem sollten mögliche Folgen benannt werden: falsche Kundenkommunikation, Datenverlust, Arbeitsunterbrechung oder Datenschutzverletzung.

6.4 Direkter Nutzen

Der am einfachsten messbare Nutzen ist eingesparte Arbeitszeit.

Eine einfache Rechnung lautet:

Monatlicher Zeitwert = eingesparte Stunden × interne Kosten je Arbeitsstunde

Die internen Kosten je Stunde sind nicht dasselbe wie der ausgezahlte Stundenlohn. Dazu gehören je nach Rechnung auch Arbeitgeberanteile, Urlaub, Krankheit, Arbeitsplatz, Verwaltung und andere Gemeinkosten. Für eine erste Modellrechnung kann der Kunde einen eigenen internen Wert vorgeben.

6.5 Beispielrechnung

Ein Betrieb bearbeitet monatlich 80 Anfragen.

Vorher

• 80 Vorgänge × 18 Minuten = 1.440 Minuten
• das entspricht 24 Stunden im Monat
• angenommene interne Kosten: 38 Euro je Stunde
• rechnerischer Aufwand: 912 Euro im Monat

Nachher

• 80 Vorgänge × 7 Minuten verbleibende Prüfung = 560 Minuten
• das entspricht rund 9,3 Stunden
• verbleibender Zeitaufwand: rund 353 Euro
• laufende Betreuung: angenommen 249 Euro
• externe technische Nutzung: angenommen 35 Euro
• gesamte laufende Kosten: rund 637 Euro

Ergebnis

• bisheriger Aufwand: 912 Euro
• neuer laufender Aufwand: 637 Euro
• rechnerischer laufender Vorteil: 275 Euro im Monat

Wenn die einmalige Einrichtung 2.200 Euro kostet, wäre sie allein durch diesen laufenden Vorteil nach acht Monaten ausgeglichen:

2.200 Euro ÷ 275 Euro pro Monat = 8 Monate

Diese Rechnung ist ein Beispiel und keine Zusage. Schon kleine Änderungen bei Vorgangsmenge, Bearbeitungszeit oder Kontrollaufwand verändern das Ergebnis.

6.6 Nicht nur Zeitersparnis

Zusätzlicher Nutzen kann entstehen durch:

• schnellere erste Antwort,
• weniger vergessene Angebote,
• vollständigere Angaben,
• einheitlichere Bearbeitung,
• bessere Vertretbarkeit bei Krankheit oder Urlaub,
• nachvollziehbare Zuständigkeiten,
• geringere Fehler- und Suchzeiten.

Dieser Nutzen darf nicht beliebig in Euro umgerechnet werden. Beispiel: Eine schnellere Antwort kann die Auftragschance erhöhen, aber ohne Messdaten ist unklar, um wie viel. Deshalb sollte zwischen gemessenem Nutzen, plausiblem Zusatznutzen und bloßer Vermutung unterschieden werden.

6.7 Empfindlichkeitsrechnung

Eine Wirtschaftlichkeitsrechnung sollte nicht nur einen idealen Wert zeigen. Sinnvoll sind drei Fälle:

Annahme	Vorsichtiger Fall	Erwarteter Fall	Günstiger Fall
Vorgänge pro Monat	60	80	100
Ersparnis je Vorgang	7 Min.	11 Min.	13 Min.
Korrekturaufwand	hoch	mittel	niedrig
Monatlicher Vorteil	klein	tragfähig	deutlich

Wenn sich die Lösung nur im günstigsten Fall rechnet, ist das Vorhaben riskant. Rechnet sie sich auch bei vorsichtigen Annahmen, ist die Entscheidung belastbarer.

6.8 Kapazität ist nicht automatisch Geldeinsparung

Zehn eingesparte Stunden führen nicht automatisch zu zehn Stunden weniger Lohnkosten. Oft bleibt das Personal gleich. Der Nutzen besteht dann in freier Kapazität:

• mehr Kundenanfragen bearbeiten,
• Rückstände abbauen,
• Fachkräfte von Verwaltungsarbeit entlasten,
• Überstunden vermeiden,
• Wachstum ohne sofortige zusätzliche Stelle ermöglichen.

Die Rechnung sollte offen sagen, welche Art von Nutzen erwartet wird.

6.9 Bedeutung für Konstellarum

Konstellarum sollte vor dem Pilot eine einfache Rechentabelle gemeinsam mit dem Kunden ausfüllen. Nach dem Pilot werden Schätzwerte durch Messwerte ersetzt.

Mindestens enthalten sein sollten:

• Vorgänge je Monat,
• Minuten je Vorgang vorher und nachher,
• interner Stundenwert,
• Einmalkosten,
• laufende Kosten,
• Restaufwand für Kontrollen,
• erwartete Nutzungsdauer,
• vorsichtiger und erwarteter Fall.

Das schützt vor übertriebenen Versprechen und zeigt zugleich, welche Prozesse tatsächlich wirtschaftlich interessant sind.

6.10 Kurze Prüfliste

• Wurde der heutige Aufwand gemessen?
• Sind einmalige und laufende Kosten vollständig?
• Ist der menschliche Restaufwand enthalten?
• Sind Fremdkosten und Lizenzen berücksichtigt?
• Wird zwischen Geldersparnis und freier Kapazität unterschieden?
• Gibt es einen vorsichtigen Vergleichsfall?
• Ist der Zeitpunkt des Kostenausgleichs berechnet?
• Werden die Werte nach dem Pilot aktualisiert?

---

7.1 Warum eine fertige Automatisierung nicht einfach „für immer läuft“

Eine Automatisierung verbindet mehrere bewegliche Teile. Auch wenn Konstellarum nichts ändert, können sich die Umgebung und die Daten verändern:

• Ein E-Mail-Anbieter ändert seine Anmeldung.
• Ein Zugangsschlüssel läuft ab.
• Ein Programm benennt ein Datenfeld um.
• Ein Kunde führt eine neue Leistung ein.
• Eine Formularfrage wird entfernt.
• Ein KI-Anbieter ändert Modell, Preis oder Nutzungsgrenze.
• Ein Server benötigt Sicherheitsaktualisierungen.
• Ein Mitarbeiter wechselt die Rolle.
• Ein ungewöhnlicher neuer Dokumenttyp tritt auf.

Die Automatisierung ist deshalb kein einmal gebautes Werkstück ohne Wartungsbedarf. Sie ähnelt eher einer kleinen betrieblichen Anlage, deren Zustand überwacht und deren Schnittstellen gepflegt werden müssen.

7.2 Betreuung besteht aus mehreren Leistungen

Überwachung

Das System meldet, ob Abläufe erfolgreich waren, ungewöhnlich lange dauerten oder vollständig ausgefallen sind.

Fehlerbearbeitung

Fehler werden eingeordnet, begrenzt und behoben. Dazu gehört auch die Frage, ob ein Vorgang erneut ausgeführt werden darf, ohne eine Nachricht doppelt zu senden oder einen Datensatz doppelt anzulegen.

Wartung

Programme, Sicherheitskorrekturen und technische Verbindungen werden gepflegt.

Datensicherung

Wichtige Einstellungen und Daten werden gesichert. Eine Sicherung ist erst belastbar, wenn die Wiederherstellung regelmäßig geprüft wird. Das BSI empfiehlt eine planvolle Datensicherung und eine vom laufenden System getrennte Aufbewahrung. [Q8]

Qualitätskontrolle

Bei KI-Schritten werden Stichproben geprüft. Fehlerarten und häufige menschliche Korrekturen werden ausgewertet.

Kostenkontrolle

Ungewöhnlich viele Aufrufe, große Dokumente oder wiederholte Fehler können Fremdkosten erhöhen. Deshalb werden Nutzung und festgelegte Grenzen überwacht.

Anpassung

Kleine Änderungen am vorhandenen Ablauf können in einer Betreuungspauschale enthalten sein. Ein neuer Prozess oder eine neue Programmanbindung ist dagegen ein eigenes Erweiterungsprojekt.

7.3 Was überwacht werden sollte

Ein sinnvoller Betriebsüberblick beantwortet mindestens:

• Läuft der Dienst überhaupt?
• Wie viele Vorgänge waren erfolgreich?
• Wie viele sind fehlgeschlagen?
• Gibt es einen Rückstau?
• Wie lange dauert eine Ausführung?
• Welche Schnittstelle verursacht Fehler?
• Wie hoch sind die externen Kosten?
• Wie oft greift die menschliche Ausnahmebearbeitung?
• Wurde die letzte Sicherung erfolgreich erstellt?
• Wann wurde zuletzt eine Wiederherstellung getestet?

OpenTelemetry beschreibt technische Beobachtbarkeit über Ablaufspuren, Messwerte und Ereignisprotokolle. Vereinfacht gesagt zeigen diese Daten, welchen Weg ein Vorgang genommen hat, wie sich Mengen und Zeiten entwickeln und welche Einzelereignisse aufgetreten sind. [Q7]

7.4 Reaktionszeit ist nicht Wiederherstellungszeit

Im Betreuungsvertrag sollten zwei Dinge getrennt werden:

• Reaktionszeit: Bis wann Konstellarum eine Störung aufnimmt und mit der Prüfung beginnt.
• Wiederherstellungszeit: Bis wann der Ablauf voraussichtlich wieder funktioniert.

Eine kurze Reaktionszeit garantiert keine sofortige Lösung. Wenn ein Fremdanbieter ausgefallen ist, kann Konstellarum den Fehler erkennen und einen Ersatzweg aktivieren, aber den Anbieter nicht selbst reparieren.

7.5 Störungsklassen

Klasse	Beispiel	Sinnvolle Behandlung
Kritisch	Daten werden falsch zugeordnet oder externe Nachrichten mehrfach versendet.	Ablauf sofort stoppen, Kunde informieren, Ursache sichern.
Hoch	Der gesamte Anfrageablauf steht.	Schnelle Prüfung, manuellen Ersatzweg aktivieren.
Mittel	Einzelne ungewöhnliche Dokumente scheitern.	Vorgänge sammeln und innerhalb vereinbarter Zeit prüfen.
Niedrig	Eine interne Übersicht ist optisch fehlerhaft.	In die planmäßige Wartung aufnehmen.

Diese Einteilung muss zum jeweiligen Kunden passen. Ein Ausfall am Wochenende kann in einem Büroprozess weniger kritisch sein als in einem rund um die Uhr arbeitenden Servicebetrieb.

7.6 Klare Grenzen der Monatspauschale

Ohne klare Grenze kann eine kleine Betreuungspauschale wirtschaftlich nicht funktionieren. Im Vertrag sollte stehen:

• welche Abläufe enthalten sind,
• welche Systeme überwacht werden,
• zu welchen Zeiten Störungen bearbeitet werden,
• wie viele kleine Änderungen enthalten sind,
• was als kleine Änderung gilt,
• welche Fremdkosten getrennt berechnet werden,
• welche Mitwirkung der Kunde leisten muss,
• welche Leistungen ausdrücklich nicht enthalten sind.

Beispiel: Das Umbenennen eines vorhandenen Pflichtfeldes kann eine kleine Änderung sein. Die Anbindung eines neuen Warenwirtschaftssystems ist ein neues Projekt.

7.7 Regelmäßiger Betreuungsrhythmus

Laufend

• technische Fehlermeldungen,
• Kosten- und Mengenlimits,
• Erreichbarkeit wichtiger Dienste.

Wöchentlich

• fehlgeschlagene und manuell bearbeitete Fälle,
• ungewöhnliche Laufzeiten,
• wiederkehrende Fehlerursachen.

Monatlich

• Erfolgsquote,
• Zeitersparnis und Bearbeitungsmenge,
• KI-Korrekturen,
• Fremdkosten,
• kleine Verbesserungen.

Vierteljährlich oder halbjährlich

• Rechte und Benutzer,
• Wiederherstellungstest,
• eingesetzte Anbieter,
• Dokumentation,
• Nutzen und Vertragsumfang.

7.8 Bedeutung für Konstellarum

Die monatliche Betreuung ist nicht nur ein Einnahmemodell. Sie ist die organisatorische Voraussetzung dafür, dass Konstellarum dauerhaft Verantwortung für einen technischen Ablauf übernehmen kann.

Ein Betreuungspaket sollte deshalb kein unbestimmtes „Wir kümmern uns“ versprechen, sondern konkrete Leistungen, Grenzen und Messwerte enthalten. Gute Betreuung kann außerdem neue Verbesserungsmöglichkeiten zeigen, ohne den Kunden zu unnötigen Erweiterungen zu drängen.

7.9 Kurze Prüfliste

• Welche Fehler werden automatisch gemeldet?
• Wer wird bei einer Störung informiert?
• Gibt es einen manuellen Ersatzweg?
• Sind Reaktionszeit und Wiederherstellung getrennt?
• Werden Sicherungen wirklich zurückgespielt und geprüft?
• Sind kleine Änderungen klar begrenzt?
• Werden Nutzung und Fremdkosten überwacht?
• Wird der wirtschaftliche Nutzen regelmäßig überprüft?

---

8.1 Einfache Erklärung

Die Datenschutz-Grundverordnung unterscheidet verschiedene Rollen. Für das Geschäftsmodell sind vor allem zwei wichtig:

• Der Verantwortliche entscheidet, warum und auf welche Weise personenbezogene Daten verarbeitet werden.
• Der Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag und nach Weisung des Verantwortlichen.

Wenn ein Handwerksbetrieb Konstellarum beauftragt, seinen Anfrageprozess technisch zu betreiben, bleibt der Handwerksbetrieb in der Regel für den Zweck verantwortlich: Er möchte Kundenanfragen bearbeiten. Konstellarum kann zum Auftragsverarbeiter werden, wenn es dabei nach Weisung auf Namen, E-Mail-Adressen, Nachrichten oder andere personenbezogene Daten zugreift.

Ob tatsächlich eine Auftragsverarbeitung vorliegt, hängt von der konkreten Aufgaben- und Entscheidungsverteilung ab. Die Bezeichnung im Vertrag allein entscheidet das nicht.

8.2 Was personenbezogene Daten sind

Personenbezogene Daten sind Informationen, die sich auf eine bestimmte oder bestimmbare natürliche Person beziehen. Im Anfrageprozess können das sein:

• Name,
• persönliche oder geschäftliche E-Mail-Adresse,
• Telefonnummer,
• Anschrift,
• Nachrichtentext,
• Stimme oder Bild,
• technische Kennungen,
• Angaben über Beschäftigung oder Funktion.

Auch eine Firmenanfrage enthält häufig personenbezogene Daten, weil eine konkrete Kontaktperson genannt wird.

8.3 Warum ein besonderer Vertrag benötigt wird

Artikel 28 DSGVO verlangt bei einer Auftragsverarbeitung eine vertragliche Regelung. Darin werden unter anderem Gegenstand, Dauer, Zweck, Datenarten, betroffene Personengruppen sowie Rechte und Pflichten festgelegt. Der Verantwortliche darf nur Auftragsverarbeiter einsetzen, die ausreichende Garantien für geeignete technische und organisatorische Schutzmaßnahmen bieten. [Q3][Q4]

Dieser Vertrag wird häufig als AV-Vertrag oder Vereinbarung zur Auftragsverarbeitung bezeichnet. Er ersetzt nicht den normalen Dienstleistungsvertrag. Beide erfüllen unterschiedliche Aufgaben:

• Dienstleistungsvertrag: Leistung, Preis, Haftung, Laufzeit und Unterstützung.
• AV-Vertrag: Umgang mit personenbezogenen Daten im Auftrag.

8.4 Typische Inhalte einer Vereinbarung

In verständlicher Form muss geklärt werden:

• Welche Leistung wird erbracht?
• Welche personenbezogenen Daten werden verarbeitet?
• Welche Personengruppen sind betroffen?
• Was darf Konstellarum mit den Daten tun?
• Welche Weisungen gelten?
• Wer darf bei Konstellarum zugreifen?
• Welche Schutzmaßnahmen bestehen?
• Welche weiteren Dienstleister werden eingesetzt?
• Was geschieht bei Datenschutzvorfällen?
• Wie unterstützt Konstellarum bei Auskunft, Berichtigung oder Löschung?
• Was geschieht nach Vertragsende mit Daten und Kopien?
• Welche Prüf- und Nachweismöglichkeiten hat der Kunde?

Das Bayerische Landesamt für Datenschutzaufsicht stellt Erläuterungen und eine Formulierungshilfe bereit, weist aber darauf hin, dass ein Muster an den tatsächlichen Auftrag angepasst werden muss. [Q4]

8.5 Technische und organisatorische Maßnahmen

Artikel 32 DSGVO verlangt ein Schutzniveau, das zum Risiko passt. Die Maßnahmen sind daher nicht für jeden Kunden identisch. Typische Punkte sind:

• verschlüsselte Übertragung,
• begrenzte Benutzerrechte,
• Mehrfaktor-Anmeldung für wichtige Zugänge,
• getrennte Kundendaten,
• sichere Verwaltung von Zugangsschlüsseln,
• Protokollierung wichtiger Zugriffe und Änderungen,
• regelmäßige Sicherheitsaktualisierungen,
• Datensicherung und Wiederherstellung,
• festgelegte Löschfristen,
• Verfahren für Störungen und Datenschutzvorfälle,
• regelmäßige Prüfung der Wirksamkeit.

Eine lange Liste technischer Begriffe reicht nicht. Die Maßnahmen müssen zum eingesetzten System passen und tatsächlich umgesetzt werden.

8.6 Weitere Dienstleister

Konstellarum wird häufig nicht alle Technik allein betreiben. Mögliche weitere Dienstleister sind:

• Serveranbieter,
• E-Mail-Dienst,
• Anbieter eines Sprachmodells,
• Protokoll- oder Überwachungsdienst,
• Sicherungsspeicher.

Diese können datenschutzrechtlich weitere Auftragsverarbeiter sein. Der Kunde muss wissen, welche Stellen beteiligt sind. Je nach Vertragsgestaltung ist eine vorherige besondere oder allgemeine Genehmigung nötig. Änderungen dürfen nicht stillschweigend erfolgen.

8.7 Verarbeitung außerhalb von EU und EWR

Der Sitz eines Anbieters allein beantwortet nicht, wo Daten verarbeitet werden. Zu prüfen sind unter anderem:

• Speicherort,
• mögliche Fernzugriffe,
• Unterauftragnehmer,
• Vertragsbedingungen,
• anwendbare Übermittlungsgrundlage,
• zusätzliche Schutzmaßnahmen.

Eine technisch gute Lösung kann ungeeignet sein, wenn die rechtlichen und vertraglichen Bedingungen für die konkreten Kundendaten nicht passen. Konstellarum sollte deshalb Anbieter nicht nur nach Preis und Modellqualität auswählen.

8.8 Datenminimierung

Für jeden automatisierten Schritt sollte gefragt werden:

• Welche Angaben werden wirklich benötigt?
• Kann ein Dokument vor der KI-Verarbeitung gekürzt oder geschwärzt werden?
• Muss der vollständige Nachrichtentext gespeichert werden?
• Wie lange werden technische Protokolle benötigt?
• Können Testdaten künstlich erzeugt werden?
• Müssen besonders sensible Daten vollständig ausgeschlossen werden?

Je weniger Daten verarbeitet werden, desto geringer sind häufig Risiko, Speicheraufwand und Erklärungsbedarf.

8.9 Vorfälle und Betroffenenrechte

Wenn Daten falsch versendet, unberechtigt eingesehen oder verloren wurden, muss Konstellarum den Kunden unverzüglich nach der vertraglichen Regelung unterstützen und informieren. Die rechtliche Bewertung und eine mögliche Meldung an die Aufsichtsbehörde liegen grundsätzlich beim Verantwortlichen, sofern nicht eine andere eigene Pflicht greift.

Auch Anfragen auf Auskunft, Berichtigung, Löschung oder Einschränkung müssen technisch unterstützt werden können. Deshalb muss bekannt sein, in welchen Systemen, Protokollen und Sicherungen Daten liegen.

8.10 Bedeutung für Konstellarum

Vor jedem produktiven Projekt sollte eine einfache Datenübersicht erstellt werden:

Frage	Beispielantwort
Welche Daten?	Name, E-Mail, Nachricht und Auftragsbezug
Wessen Daten?	Kunden, Interessenten und Ansprechpartner
Wozu?	Anfrage zuordnen und bearbeiten
Woher?	E-Mail-Postfach und Websiteformular
Wohin?	Kundendaten-System und Aufgabenliste
Wer hat Zugriff?	zuständige Kundenrollen und begrenzte Betreuung
Welche externen Dienste?	Server, E-Mail und gegebenenfalls KI-Anbieter
Wie lange?	nach dokumentierter Aufbewahrungs- und Löschregel

Konstellarum kann die technische Dokumentation vorbereiten, ersetzt aber keine individuelle Rechtsberatung. Bei sensiblen Daten, unklaren Rollen oder grenzüberschreitender Verarbeitung sollte der Kunde seinen Datenschutzbeauftragten oder juristischen Berater einbeziehen.

8.11 Kurze Prüfliste

• Wer bestimmt Zweck und wesentliche Mittel?
• Liegt Auftragsverarbeitung vor?
• Gibt es Dienstleistungs- und AV-Vertrag?
• Sind Datenarten, Personen und Zweck beschrieben?
• Sind Schutzmaßnahmen tatsächlich umgesetzt?
• Sind weitere Dienstleister vollständig bekannt?
• Wurden mögliche Drittlandübermittlungen geprüft?
• Gibt es Lösch-, Rückgabe- und Vorfallregeln?
• Können Auskunft und Löschung technisch unterstützt werden?

---

9.1 Was „Betrieb“ bedeutet

Die Entwicklung endet, sobald ein Ablauf technisch fertig eingerichtet ist. Der Betrieb beginnt dort erst. Betrieb bedeutet, die Lösung unter echten Bedingungen verfügbar, sicher, nachvollziehbar und bezahlbar zu halten.

Eine typische Automatisierung besteht aus mehreren Bausteinen:

• Eingang wie E-Mail oder Formular,
• Automatisierungssoftware,
• feste Prüf- und Entscheidungsregeln,
• gegebenenfalls KI-Dienst,
• Kundendaten-System,
• Dateiablage,
• Datenbank,
• Protokollierung und Überwachung,
• Sicherung,
• Benutzer- und Rechteverwaltung.

Der Kunde erlebt einen einzigen Ablauf. Technisch arbeiten jedoch mehrere Systeme zusammen.

9.2 Programmschnittstellen

Programme tauschen Daten häufig über eine Programmschnittstelle aus. In technischen Unterlagen steht dafür meist API. Eine Schnittstelle legt fest:

• welche Anfrage ein Programm stellen darf,
• welche Zugangsdaten benötigt werden,
• wie Daten aufgebaut sein müssen,
• welche Antwort zurückkommt,
• wie Fehler angezeigt werden,
• wie viele Anfragen erlaubt sind.

Ändert ein Anbieter seine Schnittstelle, kann die Verbindung angepasst werden müssen. Deshalb ist die laufende Betreuung Bestandteil des Angebots.

9.3 Automatisierungssoftware als Ablaufsteuerung

Eine Software wie n8n kann Eingänge, Regeln, Programmschnittstellen und Fehlerwege miteinander verbinden. Sie ist die Ablaufsteuerung, aber nicht automatisch die gesamte Lösung.

Vor einem produktiven Angebot muss auch die Lizenz zum Betriebsmodell passen. Die n8n-Dokumentation beschreibt Beratung und Einrichtung auf einem internen Kundenserver als grundsätzlich zulässige Beispiele der freien Lizenz; ein kostenpflichtiger Zugang zu einer selbst gehosteten n8n-Instanz kann dagegen eine andere Lizenz erfordern. Das konkrete Modell ist vor Vertragsabschluss erneut zu prüfen. [Q9]

9.4 Getrennte Umgebungen

Mindestens drei Umgebungen sind sinnvoll:

• Entwicklung: Hier wird gebaut und verändert.
• Test: Hier wird mit festgelegten Fällen geprüft.
• Produktivbetrieb: Hier werden echte Vorgänge bearbeitet.

Änderungen sollten nicht direkt an echten Kundendaten ausprobiert werden. Test und Produktivbetrieb benötigen getrennte Zugangsdaten, Speicherbereiche und möglichst auch getrennte Datenbanken.

Docker Compose kann mehrere zusammengehörige Dienste, Netzwerke und Speicherbereiche in einer zentralen Konfigurationsdatei beschreiben. Dadurch lässt sich eine Umgebung nachvollziehbar aufbauen. Es ersetzt jedoch weder Datensicherung noch Sicherheitskonzept oder Überwachung. [Q6]

9.5 Zugangsdaten und Rechte

Zugangsschlüssel gehören nicht offen in Ablaufbeschreibungen, Quelltexte oder E-Mails. Sie sollten in einer dafür vorgesehenen sicheren Verwaltung liegen.

Grundregeln:

• jeder Kunde erhält getrennte Zugänge,
• jeder Dienst bekommt nur die benötigten Rechte,
• Test und Produktivbetrieb verwenden verschiedene Schlüssel,
• persönliche Benutzerkonten werden nicht gemeinsam verwendet,
• ausgeschiedene Benutzer werden zeitnah gesperrt,
• wichtige Zugänge werden mit zusätzlichem Anmeldefaktor geschützt,
• Schlüssel werden planmäßig oder bei Verdacht erneuert.

Das BSI beschreibt Berechtigungsmanagement als geregelte Zuweisung, Entziehung und Kontrolle von Rechten. [Q10]

9.6 Doppelte Aktionen verhindern

Technische Systeme wiederholen fehlgeschlagene Schritte häufig. Das ist sinnvoll, wenn eine Verbindung kurz unterbrochen war. Es wird gefährlich, wenn dadurch dieselbe Rechnung zweimal angelegt oder dieselbe Nachricht zweimal versendet wird.

Deshalb erhält jeder Vorgang eine eindeutige Kennung. Vor einer Aktion wird geprüft:

• Wurde dieser Vorgang bereits verarbeitet?
• Wurde die geplante Nachricht bereits versendet?
• Existiert der Datensatz schon?
• Ist eine frühere Ausführung noch aktiv?

In der Softwareentwicklung wird diese Eigenschaft häufig Idempotenz genannt. Einfach ausgedrückt: Eine technische Wiederholung darf keine unerwünschte Doppelwirkung erzeugen.

9.7 Fehlerwege

Ein robuster Ablauf benötigt für jeden wichtigen Schritt eine Antwort auf Fehler:

• Wie oft wird automatisch erneut versucht?
• Wann wird gestoppt?
• Wo wird der unbearbeitete Vorgang zwischengespeichert?
• Wer erhält eine Meldung?
• Welche Angaben stehen in der Meldung?
• Kann der Vorgang nach einer Korrektur sicher fortgesetzt werden?
• Muss eine bereits ausgeführte Teilaktion zurückgenommen werden?

Ein Fehler darf nicht dazu führen, dass eine Anfrage unbemerkt verschwindet.

9.8 Protokolle, Messwerte und Ablaufspuren

Für den Betrieb werden drei Arten technischer Informationen unterschieden:

• Ereignisprotokolle: Was ist zu einem bestimmten Zeitpunkt geschehen?
• Messwerte: Wie viele Vorgänge, Fehler oder Sekunden treten über die Zeit auf?
• Ablaufspuren: Welchen Weg nahm ein einzelner Vorgang durch mehrere Dienste?

OpenTelemetry stellt dafür ein anbieterunabhängiges Verfahren bereit. Es speichert nicht automatisch alle Daten sicher und zeigt nicht automatisch ein fertiges Bedienfeld; es standardisiert vor allem die Erfassung und Weitergabe technischer Beobachtungsdaten. [Q7]

Bei Protokollen gilt Datenschutz: Nachrichtentexte, Zugangsschlüssel und vollständige Dokumente gehören nicht ungeprüft in technische Fehlermeldungen.

9.9 Datensicherung und Wiederherstellung

Gesichert werden können:

• Ablaufdefinitionen,
• Konfigurationen,
• Datenbanken,
• Dokumente,
• Berechtigungs- und Systemeinstellungen,
• wichtige Nachweise.

Zu jeder Sicherung gehören vier Fragen:

1. Wie viel Datenverlust ist im schlimmsten Fall vertretbar?
2. Wie schnell muss der Betrieb wiederhergestellt sein?
3. Wo liegt die getrennte Sicherung?
4. Wann wurde die Wiederherstellung zuletzt tatsächlich getestet?

Eine grüne Meldung „Sicherung erfolgreich“ beweist nur, dass Daten geschrieben wurden. Erst ein Rücksicherungstest zeigt, ob daraus ein funktionsfähiges System hergestellt werden kann. [Q8]

9.10 Änderungen kontrollieren

Jede produktive Änderung sollte:

• eine kurze Begründung besitzen,
• einer Version zugeordnet sein,
• in einer Testumgebung geprüft werden,
• eine Rückkehr zur vorherigen Version ermöglichen,
• dokumentiert freigegeben werden,
• nach Einführung beobachtet werden.

Das gilt auch für Änderungen an KI-Anweisungen. Eine kleine Formulierungsänderung kann viele Ergebnisse beeinflussen.

9.11 Kostenbegrenzung

Technischer Betrieb muss vor unerwarteten Kosten geschützt werden:

• maximale Dokumentgröße,
• maximale Zahl von Wiederholungen,
• tägliche oder monatliche Nutzungsgrenze,
• Warnung bei ungewöhnlichem Anstieg,
• Wahl des kleinsten ausreichend guten KI-Modells,
• Speicherung bereits berechneter Ergebnisse, wenn fachlich zulässig,
• Abschaltung eines fehlerhaften Endlosablaufs.

9.12 Bedeutung für Konstellarum

Für jeden Kunden sollte eine kompakte Betriebsakte entstehen:

• Systemübersicht,
• beteiligte Programme und Anbieter,
• Zugänge und Verantwortlichkeiten,
• Datenwege,
• Fehler- und Alarmregeln,
• Sicherungs- und Wiederherstellungsplan,
• Änderungsverfahren,
• Kostenlimits,
• manueller Ersatzbetrieb,
• bekannte Abhängigkeiten und Lizenzbedingungen.

Diese Betriebsakte ist mindestens so wichtig wie der sichtbare Ablauf in der Automatisierungssoftware.

9.13 Kurze Prüfliste

• Sind Entwicklung, Test und Produktivbetrieb getrennt?
• Haben Dienste nur notwendige Rechte?
• Sind Zugangsdaten sicher verwaltet?
• Werden Doppelwirkungen bei Wiederholungen verhindert?
• Gibt es für jeden kritischen Schritt einen Fehlerweg?
• Sind Mengen, Laufzeiten, Fehler und Kosten sichtbar?
• Werden Sicherungen zurückgespielt und geprüft?
• Können Änderungen zurückgenommen werden?
• Ist das Lizenzmodell geklärt?

---

10.1 Einfache Erklärung

Standardisierung bedeutet, gleiche Aufgaben nach einer gemeinsamen Struktur zu lösen. Wiederverwendung bedeutet, bereits geprüfte Bausteine bei mehreren Kunden erneut einzusetzen, statt alles neu zu entwickeln.

Das bedeutet nicht, jedem Kunden exakt dieselbe Lösung aufzuzwingen. Ein guter Vergleich ist ein Schaltschrankbau mit standardisierten Komponenten:

• Gehäuse, Klemmen, Sicherungen und Dokumentationsregeln können standardisiert sein.
• Anschlusswerte, Feldgeräte, Beschriftung und Steuerungslogik werden an die Anlage angepasst.

Bei Prozessautomatisierung ist es ähnlich. Der technische Grundaufbau kann gleich bleiben, während Fachbegriffe, Programme, Verantwortlichkeiten und Regeln kundenspezifisch sind.

10.2 Warum dies wirtschaftlich notwendig ist

Wenn jeder Kunde eine vollständig neue Sonderentwicklung erhält, entstehen:

• hoher Entwicklungsaufwand,
• viele unterschiedliche Fehlerquellen,
• schwer kalkulierbare Projekte,
• aufwendige Wartung,
• kaum planbare Monatspauschalen,
• starke Abhängigkeit vom Wissen einzelner Entwickler.

Wiederverwendbare Bausteine senken nicht automatisch jeden Preis. Sie schaffen aber mehr Zeit für die tatsächlich kundenspezifischen Fragen und erhöhen die Zuverlässigkeit, weil ein Baustein bereits mehrfach getestet wurde.

10.3 Vier Schichten einer wiederverwendbaren Lösung

Schicht 1: Technischer Grundbetrieb

Für alle Kunden ähnlich:

• Überwachung,
• Protokollierung,
• Sicherung,
• Benutzer- und Rechteprinzip,
• Versionsverwaltung,
• Fehlerbenachrichtigung,
• Kostenkontrolle.

Schicht 2: Allgemeine Prozessbausteine

Wiederverwendbare Funktionen:

• E-Mail einlesen,
• Pflichtfelder prüfen,
• Dokument ablegen,
• Aufgabe erzeugen,
• Freigabe anfordern,
• Erinnerung setzen,
• Fehler in eine Warteschlange legen.

Schicht 3: Verbindung zum Kundenprogramm

Anpassung an das tatsächlich verwendete Kundendaten-System, E-Mail-Programm, Formular oder die Dokumentenablage.

Schicht 4: Fachliche Regeln des Kunden

Individuell bleiben:

• angebotene Leistungen,
• benötigte Angaben,
• Zuständigkeiten,
• Bearbeitungsfristen,
• Schreibstil,
• Preis- und Freigabegrenzen,
• Sonderfälle.

Diese Trennung verhindert, dass eine kleine Änderung am Schreibstil den technischen Grundbetrieb beeinflusst.

10.4 Konfiguration statt Kopie

Eine schlechte Form der Wiederverwendung besteht darin, einen ganzen Kundenablauf zu kopieren und anschließend an vielen Stellen umzuschreiben. Nach einigen Projekten existieren dann zehn leicht unterschiedliche Fassungen. Fehlerkorrekturen müssen zehnmal durchgeführt werden.

Besser ist ein gemeinsamer Baustein mit einstellbaren Werten, zum Beispiel:

• Name des Eingangspostfachs,
• Liste der Pflichtfelder,
• zulässige Dateitypen,
• Freigabegrenze,
• zuständige Rolle,
• Erinnerungsfrist,
• gewünschter Schreibstil.

Der geprüfte Kern bleibt gleich; nur die Konfiguration ändert sich.

10.5 Was sich gut wiederverwenden lässt

• technische Anmeldung und Fehlerbehandlung für verbreitete Systeme,
• Prüfung von E-Mail-Adressen und Pflichtfeldern,
• Vergabe eindeutiger Vorgangskennungen,
• Schutz vor doppelter Ausführung,
• Freigabeoberfläche,
• Protokoll- und Messstruktur,
• Benachrichtigungen,
• Sicherungs- und Betriebsdokumentation,
• Testfallvorlagen,
• Datenschutz-Fragenkatalog,
• Angebots- und Abnahmevorlagen.

10.6 Was kundenspezifisch bleiben muss

• tatsächlicher Arbeitsablauf,
• Fachsprache,
• erlaubte Entscheidungen,
• besondere Kundenvereinbarungen,
• Verantwortlichkeiten,
• Datenaufbewahrung,
• rechtliche Einordnung,
• Risikogrenzen,
• vorhandene Programme und deren Qualität.

Standardisierung darf nicht dazu führen, dass eine fachlich unpassende Lösung nur deshalb eingesetzt wird, weil der Baustein schon vorhanden ist.

10.7 Bausteine brauchen Versionsstände

Ein wiederverwendbarer Baustein verändert sich im Laufe der Zeit. Deshalb braucht er:

• eindeutigen Namen,
• Versionsnummer,
• kurze Beschreibung,
• bekannte Voraussetzungen,
• festgelegte Ein- und Ausgaben,
• Testfälle,
• Änderungsverzeichnis,
• bekannte Grenzen,
• verantwortliche Person.

Wenn eine neue Version entsteht, muss klar sein, welche Kunden die alte Version verwenden und ob eine Aktualisierung notwendig ist.

10.8 Testen auf zwei Ebenen

Bausteintest

Es wird geprüft, ob der einzelne Baustein allgemein richtig arbeitet. Beispiel: Erkennt die Pflichtfeldprüfung leere, falsch benannte und widersprüchliche Werte?

Kundentest

Es wird geprüft, ob die Kombination beim konkreten Kunden funktioniert. Beispiel: Kommen die Felder aus dessen Formular wirklich in der erwarteten Form an?

Ein bereits geprüfter Baustein macht den Kundentest kleiner, ersetzt ihn aber nicht.

10.9 Beispiel: Anfragebearbeitung bei zwei Kunden

Gemeinsam

Beide Kunden verwenden:

• E-Mail-Eingang,
• Erkennung eines bestehenden Vorgangs,
• Pflichtfeldprüfung,
• menschliche Freigabe einer Rückfrage,
• Aufgabe mit Frist,
• Protokollierung und Fehleralarm.

Kunde A: Elektrobetrieb

Benötigte Angaben:

• Anlagenart,
• Standort,
• Fehlerbeschreibung,
• gewünschter Termin.

Kunde B: Ingenieurbüro

Benötigte Angaben:

• Projektart,
• Bauort,
• vorhandene Unterlagen,
• gewünschter Leistungsumfang.

Der technische Kern bleibt gleich. Pflichtfelder, Fachkategorien, Zuständigkeiten und Textvorlagen werden konfiguriert.

10.10 Gefahr der Überstandardisierung

Zu viel Standardisierung zeigt sich daran, dass:

• Beschäftigte ständig Ausnahmen von Hand korrigieren,
• wichtige Fachregeln nicht abbildbar sind,
• der Kunde seine sinnvollen Abläufe unnötig ändern soll,
• Datenschutz- oder Sicherheitsanforderungen nicht passen,
• ein Baustein immer wieder mit Sonderlösungen umgangen wird.

Dann sollte entweder der Baustein sinnvoll erweitert oder der Kundenfall bewusst als Sonderlösung behandelt werden.

10.11 Gefahr zu früher Verallgemeinerung

Aus einem einzigen Projekt lässt sich noch kein verlässlicher Standard ableiten. Sinnvoll ist:

1. ersten Kundenfall sauber lösen,
2. beim zweiten Fall Gemeinsamkeiten und Unterschiede beobachten,
3. wiederkehrende Teile herauslösen,
4. erst danach einen allgemein einstellbaren Baustein bauen,
5. bei weiteren Projekten prüfen und verbessern.

Damit wird nicht wochenlang ein vermeintlich universelles System entwickelt, bevor ein Kunde seinen Nutzen bestätigt hat.

10.12 Bedeutung für Konstellarum

Konstellarum sollte eine interne Bausteinbibliothek aufbauen. Für jeden Baustein werden Technik, Tests, Betriebsanforderungen und Lizenz festgehalten.

Der wirtschaftliche Nutzen entsteht auf drei Ebenen:

• Piloten können schneller und zuverlässiger eingerichtet werden.
• Angebote lassen sich genauer kalkulieren.
• Monatliche Betreuung bleibt beherrschbar, weil nicht jeder Kunde eine völlig andere technische Grundlage hat.

Die kundenspezifische Leistung verschwindet dadurch nicht. Sie verlagert sich auf die wertvolleren Aufgaben: Prozessverständnis, fachliche Regeln, sichere Einbindung und messbarer Nutzen.

10.13 Kurze Prüfliste

• Welche Teile sind bei mehreren Kunden wirklich gleich?
• Welche Werte können konfiguriert werden?
• Welche Fachregeln müssen individuell bleiben?
• Hat jeder Baustein Version, Tests und Dokumentation?
• Ist bekannt, welcher Kunde welche Version verwendet?
• Werden Fehlerkorrekturen zentral übernommen?
• Wird ein Standard erst nach realen Projekterfahrungen gebildet?
• Ist eine bewusste Sonderlösung möglich, wenn sie fachlich nötig ist?

---