Pilot, Rollout und Übergabe

Pilot, Rollout und Übergabe

0:00 Willkommen zu Modul fünfzehn. Technisch ist Lotsenhaus jetzt so weit, wie eine Plattform im Labor nur sein kann: abgesichert, überwacht, wiederherstellbar. Was noch fehlt, sind die Menschen. In diesem Modul geht es darum, wie aus der Plattform ein Werkzeug wird, das die Pilotbereiche von Brandtner Fördertechnik tatsächlich nutzen, und wie man nach einigen Wochen ehrlich sagen kann, ob es sich lohnt.

0:22 Wir setzen den Pilot mit klarem Zuschnitt und Training auf, unterscheiden Nutzung von Wirkung, treffen Entscheidungen je Anwendungsfall und übergeben am Ende sauber an den Regelbetrieb. In der Übung entwerfen Sie einen Rolloutplan für die ersten neunzig Tage.

Pilot, Rollout und Übergabe

0:37 Der sechste Tag geht weiter, und der Satz auf dieser Folie räumt mit einem verbreiteten Missverständnis auf. Viele Unternehmen nennen etwas Pilot, das in Wahrheit ein vorsichtiger Dauerbetrieb ist. Ein echter Pilot ist ein Experiment mit Ende, und am Ende steht eine Entscheidung. Diese Haltung zieht sich durch das ganze Modul.

Den Pilot aufsetzen

0:56 Ein Pilot steht und fällt mit dem, was vor dem ersten Login festgelegt wird. Wer, was, wie lange und woran man Erfolg erkennt. Man kann sich einen Pilot wie eine Probefahrt vorstellen, aber eine mit Protokoll. Sie fahren nicht einfach los und schauen, wie es sich anfühlt, sondern legen vorher Strecke, Dauer und die Werte fest, die Sie messen wollen.

1:18 Bei Lotsenhaus heißt das: eine benannte Gruppe, feste Anwendungsfälle, eine begrenzte Laufzeit und Erfolgskriterien, die abgezeichnet sind, bevor es losgeht. Die eine Frage, die der Pilot beantworten soll, ist bewusst doppelt formuliert. Wird die Arbeit messbar besser, und bleiben dabei Qualität, Zugriffsschutz und Kosten im Rahmen?

1:38 Ein Gewinn an Tempo, der mit falschen Auskünften erkauft wird, ist kein Erfolg. Der Zuschnitt macht aus einer guten Absicht einen prüfbaren Plan. Bemerkenswert ist vor allem die Begrenzung: Drei Bereiche, zwei Assistenten, und der Störmelder nur lesend. Dazu kommen Erfolgskriterien mit Ausgangswert, Ziel und Messmethode aus den Steckbriefen, und, genauso wichtig, Ausschlusskriterien.

2:01 Ein Datenabfluss, eine falsche Richtlinienauskunft ohne Quelle oder ein überschrittenes Budget beenden einen Anwendungsfall, egal wie beliebt er ist. Je Bereich gibt es einen Multiplikator als ersten Ansprechpartner. Die Fußzeile ist die eigentliche Disziplin: Was nicht im Zuschnitt steht, gehört nicht in den Pilot, auch wenn es technisch längst möglich wäre.

2:22 Training ist hier keine nette Zugabe, sondern eine rechtliche Pflicht. Artikel vier der KI-Verordnung gilt seit Februar 2025 für Anbieter und für Betreiber von KI-Systemen. Seit dem Digital Omnibus im Juli 2026 verlangt er Maßnahmen, die die KI-Kompetenz des Personals fördern. Der Maßstab ist dabei nicht ein Einheitskurs für alle, sondern Vorwissen, Erfahrung, Ausbildung und der konkrete Einsatzkontext.

2:47 Für Brandtner bedeutet das: Wer Lotsenhaus betreibt, muss diese Maßnahmen selbst planen und nachweisen können. Das ist weniger Last, als es klingt. Ein Pilot ohne geschulte Nutzer liefert ohnehin keine verwertbaren Ergebnisse. Die Tabelle folgt einem einfachen Prinzip: Jede Rolle lernt, was sie für ihre Aufgabe braucht, nicht mehr und nicht weniger.

3:09 Alle Nutzer bekommen vor dem Zugang eine kurze Einführung in Datenklassen, die Grenzen der Modelle und das Prüfen von Quellen. Die Multiplikatoren gehen tiefer, denn sie sollen Fragen auffangen und Feedback einordnen. Die Gruppe lh-wissen lernt, Dokumente zu pflegen und Widersprüche zu erkennen, etwa zwischen zwei Fassungen einer Richtlinie. Und lh-admin bekommt eine echte Betriebsschulung.

3:32 Die Fußzeile ist der praktische Teil der Rechtspflicht: Teilnahme dokumentieren, denn genau das ist später Ihr Nachweis. Ein Pilot ohne Rückkanal ist wie ein Restaurant ohne Kellner. Das Essen mag gut sein, aber Sie erfahren nie, was den Gästen fehlt. Deshalb richten Sie mehrere Wege ein, die zusammenspielen. Der Multiplikator im Bereich nimmt die ersten Fragen an.

3:54 Störungen und Fehlantworten landen als Ticket im Störmelder, damit nichts im Flurfunk verschwindet. Die Bewertung per Daumen je Antwort wird erklärt, sonst nutzt sie kaum jemand. Ein Banner verweist auf Supportweg und Regeln. Und alle zwei Wochen wird ausgewertet und weitergegeben. Beachten Sie die Fußzeile: Banner sieht man nur beim neuen Chat, die Regeln gehören zusätzlich schriftlich verteilt.

4:19 Die Stolpersteine beim Pilotstart sind fast alle Reihenfolgefehler. Der Zugang wird freigeschaltet, bevor das Training stattgefunden hat, weil die Technik früher fertig ist als der Schulungstermin. Multiplikatoren werden benannt, aber ohne Zeit für die Rolle, und dann bleibt sie ein Name auf einer Liste. Feedback wird gesammelt, aber niemand ist zuständig, es auszuwerten und zu reagieren.

4:41 Das ist schlimmer als gar kein Feedback, denn es lehrt die Nutzer, dass Rückmeldungen nichts bewirken. Und der Klassiker: ein Pilot ohne Enddatum. Aus dem Versuch wird stiller Dauerbetrieb, und die Entscheidung findet nie statt.

Wirkung messen und entscheiden

4:55 Jetzt läuft der Pilot, und die ersten Zahlen kommen herein. Die Kunst liegt darin, sie richtig zu lesen und nicht mit Erfolg zu verwechseln. Open WebUI bringt erstaunlich viel Messung mit. Im Admin-Bereich sehen Sie Antworten, Tokens, Chats und aktive Nutzer, auf Wunsch gefiltert nach einer Gruppe wie lh-anwender. Es gibt eine Nutzertabelle mit den aktivsten Personen, die Bewertungen je Antwort und eine Rangliste der Modelle, die aus Vergleichsbewertungen errechnet wird, ähnlich wie Ranglisten im Schach.

5:25 Jede Person sieht außerdem ihre eigene Nutzung. Das ist ein guter Grundstock für den Pilot. Aber halten Sie im Kopf, was diese Zahlen sind: Spuren der Nutzung. Ob die Arbeit dadurch besser wird, steht in keiner dieser Tabellen, und genau darum geht es auf der nächsten Folie. Dieser Gegensatz ist der Kern des Kapitels. Nutzung ist leicht zu messen: Die Zahlen fallen in Analytics einfach an und zeigen, ob die Plattform angenommen wird und wie sich die Kosten entwickeln. Wirkung ist mühsamer.

5:54 Sie kommt aus dem Fachbereich, misst etwa Zeit oder Rückfragen pro Vorgang und braucht einen Ausgangswert und einen Messplan. Ein Bild dazu: Die Zahl der Besucher in einem Fitnessstudio sagt nichts darüber, ob jemand fitter geworden ist. Wer nur Nutzung berichtet, beantwortet die Frage des Pilots nicht. Deshalb gehören in die Steckbriefe Messmethoden, die der Fachbereich auch wirklich erheben kann.

6:17 Auch die eingebauten Zahlen haben Tücken, und die sollten Sie kennen, bevor Sie sie in einen Bericht übernehmen. Analytics zählt die Antworten des Assistenten, nicht die Nachrichten der Nutzer, und das verschiebt jede Rechnung pro Anfrage. Fehlende Tokenangaben eines Anbieters erscheinen als null, Ihre Kostenrechnung ist dann zu niedrig.

6:37 Personenbezogene Auswertungen sind Leistungs- und Verhaltensdaten, und da bestimmt der Betriebsrat mit. Und Bewertungen sind keine Stichprobe. Es bewerten wenige, und überdurchschnittlich oft die Unzufriedenen. Das macht sie nicht wertlos, aber man liest sie als Hinweisgeber, nicht als Zufriedenheitsquote. Eine Entscheidung über einen Anwendungsfall folgt einem festen Weg, damit sie nicht vom lautesten Fürsprecher abhängt.

7:02 Zuerst vergleichen Sie die Kriterien aus dem Steckbrief mit den gemessenen Werten. Dann stellen Sie die Referenzfragen erneut und prüfen, ob die Antwortqualität gehalten hat. Die Kosten rechnen Sie aus Tokens und Anbieterpreis aus. Erst auf dieser Grundlage folgt ein begründeter Vorschlag, und abgezeichnet wird er gemeinsam von fachlicher Verantwortung und Plattformbetrieb.

7:23 Die Fußzeile verdient besondere Beachtung: Einen Anwendungsfall einzustellen, ist kein Scheitern, sondern ein Ergebnis. Es spart Betrieb und schützt das Vertrauen in die Fälle, die bleiben. Die vier Felder machen aus einer Bauchentscheidung eine Einordnung. Ausbauen heißt: Kriterien erreicht, Qualität stabil, weitere Bereiche dürfen dazukommen.

7:43 Anpassen heißt: Der Nutzen ist sichtbar, aber die Qualität schwankt, also wird an Wissen, Prompt oder Modell nachgebessert. Beobachten ist das interessanteste Feld: Die Qualität ist gut, aber kaum jemand nutzt den Fall. Dann liegt es oft nicht an der Technik, sondern an Training oder Zuschnitt. Und Einstellen heißt: Kriterien verfehlt oder ein Ausschlusskriterium ist eingetreten.

8:06 Der Vorteil dieses Rasters ist, dass jeder Anwendungsfall einzeln entschieden wird und nicht die ganze Plattform auf einmal. Eine Entscheidung ist keine Dauerfreigabe. Die Tabelle zeigt vier Prüfungen, die im Pilot und danach regelmäßig wiederkehren, jede mit eigener Zuständigkeit. Die Administration prüft, ob Gruppen und Freigaben noch stimmen, denn Berechtigungen wachsen still mit der Zeit.

8:29 Die Gruppe lh-wissen prüft die Antwortqualität anhand der Referenzfragen und sorgt dafür, dass veraltete Fassungen von Richtlinien aus der Wissensbasis verschwinden. Der Plattformbetrieb behält die Kosten im Blick. Den Rhythmus schlägt die Fußzeile vor: monatlich im Pilot, vierteljährlich im Regelbetrieb. Wichtig ist weniger die genaue Frequenz als dass sie im Kalender steht.

Übergabe in den Betrieb

8:52 Irgendwann endet das Projekt, aber nicht die Plattform. Wer danach anruft, muss jemanden erreichen, der zuständig ist und Bescheid weiß. Eine Übergabe ist mehr als ein Ordner, den man über den Tisch schiebt. Übergeben werden fünf Dinge: der Betrieb mit Repository, Runbooks und Notfallhandbuch, die Nachweise wie Wiederherstellungsprobe und offene Sicherheitshinweise, die benannten Rollen, die geltenden Regeln und schließlich das Wissen der Menschen.

9:18 Für das Letzte gibt es die Einweisung der Rufbereitschaft und eine gemeinsame Störungsübung. Die Fußzeile setzt den Maßstab hoch und richtig: Übergeben ist erst, wenn der Regelbetrieb eine Störung ohne das Projektteam behoben hat. Vorher ist es eine Leihgabe, bei der im Ernstfall doch wieder die alten Telefonnummern gewählt werden.

9:37 Eine Plattform wie Lotsenhaus lebt davon, dass Neues hinzukommt, und genau deshalb braucht sie ein geregeltes Aufnahmeverfahren. Es beginnt mit einem Antrag, der Anwendungsfall, Datenklasse und Verantwortlichen nennt. Dann folgt der Abgleich mit der Governance-Matrix: Welche Datenklassen darf das Neue überhaupt sehen? Getestet wird auf der Testumgebung mit den bekannten Referenzfragen, Modelle lassen sich zusätzlich im direkten Vergleich bewerten.

10:02 Erst danach gibt es eine Freigabe für eine bestimmte Gruppe, und das Ergebnis wird dokumentiert. Die Fußzeile schließt eine beliebte Lücke: Auch eine neue Version eines bereits freigegebenen Modells durchläuft dasselbe Verfahren. Über den Ausstieg spricht man am besten, solange alles gut läuft, denn dann ist es billig. Open WebUI überträgt keine Daten zwischen Datenbanken, ein Wechsel braucht also eigene Werkzeuge.

10:27 Den Modellanbieter auszutauschen ist eine Konfigurationsänderung, die ganze Plattform zu wechseln dagegen ein eigenes Projekt. Wer den Export erst beim Ausstieg probiert, entdeckt die Lücken genau dann, wenn keine Zeit mehr für Lösungen ist. Und Außerbetriebnahme heißt nicht nur abschalten, sondern auch Sicherungen, Schlüssel und Konten nachweisbar löschen.

10:47 Das Bild dazu ist der Mietvertrag: Die Kündigungsfristen liest man vor dem Einzug, nicht beim Auszug. Die Tabelle zeigt, dass ein Export möglich ist, aber nie ganz ohne Grenzen. Jede Person kann ihre eigenen Chats als JSON exportieren, die Administration alle Chats, sofern die Funktion nicht abgeschaltet ist. Assistenten lassen sich im Format von Open WebUI exportieren, Wissensbasen als ZIP, allerdings mit dem extrahierten Text, nicht mit den Originaldokumenten.

11:15 Die Analytics-Schnittstelle liefert nur Metadaten, und der Datenbankabzug enthält alles, aber im Schema von Open WebUI, das ein Zielsystem erst abbilden muss. Die Fußzeile ist eine wichtige Erinnerung: Die Originaldokumente kommen aus ihrem Quellsystem, die Wissensbasis ist nur eine Kopie davon. Die Stolpersteine der Übergabe sind meist Fragen, die niemand formal beantwortet hat.

11:38 Die Betriebsverantwortung bleibt beim Projektteam hängen, weil sie nie jemand ausdrücklich übernommen hat. Neue Modelle werden direkt freigegeben, weil der Test auf dem Testsystem als zu langsam empfunden wird, und damit ist das Aufnahmeverfahren schon beim ersten Mal ausgehebelt. Ein Export aller Chats geschieht ohne geklärten Zweck, ohne Rechtsgrundlage und ohne Betriebsrat. Und bei der Außerbetriebnahme werden die Sicherungen vergessen.

12:03 Die Plattform ist abgeschaltet, aber die Daten leben in den Sicherungen weiter, und mit ihnen alle Pflichten.

Übung

12:10 Jetzt planen Sie selbst. Die ersten neunzig Tage von Lotsenhaus, von der Vorbereitung bis zur Entscheidung. Die Fähigkeit, die Sie hier üben, ist planerisch: einen KI-Pilot so anzulegen, dass am Ende eine begründete Entscheidung möglich ist und nicht nur ein Bauchgefühl. Ihr Plan ist erfolgreich, wenn er je Phase Verantwortliche und Maßnahmen nennt, zwei Entscheidungstermine mit Kriterien enthält und für jeden Anwendungsfall eine Ausstiegsregel festlegt.

12:36 Sie fangen nicht bei null an. Grundlage sind die Steckbriefe aus Modul eins und die Governance-Matrix aus Modul zwei. Hier schließt sich ein Bogen über das ganze Seminar: Was Sie am ersten Tag als Anforderung formuliert haben, wird jetzt zum Maßstab für die Entscheidung. Sie arbeiten in der Gruppe und gehen vom Groben ins Feine. Zuerst legen Sie die Phasen fest, also Vorbereitung mit Training, den eigentlichen Pilotbetrieb und die Auswertung.

13:02 Dann ordnen Sie jeder Phase Verantwortliche aus der Rollentabelle zu. Bei den Messpunkten trennen Sie bewusst, was Analytics von selbst liefert und was der Fachbereich erheben muss. Die beiden Entscheidungstermine an Tag fünfundvierzig und Tag neunzig bekommen klare Kriterien. Und ganz am Ende stehen Übergabe und Ausstiegsszenario.

13:21 Ihr Plan ist kein Selbstzweck: Er fließt in das Abschlussprojekt ein, und dort wird er im Review geprüft.