Tag 18: Fallakte ISA Desk & Best Practices für Entwicklung und Rollout

Marc

Willkommen zum Begleitpodcast für den AI Business Specialist an der Graduate School of Applied Technology and Management. Heute steht Tag 18 auf dem Programm, und wir haben ein ganz zentrales Thema vor uns: Entwicklung und Einführung einer KI Lösung konzipieren. Ich bin Marc, und bei mir ist Stefan.

Stefan

Hallo Marc, hallo an alle Teilnehmerinnen und Teilnehmer. Tag 18 ist ein echter Wendepunkt im Lehrgang. Bisher ging es in den Tagen 15 bis 17 um die Charta, den Business Case, den Sprint Null Plan und die Frage: Was wollen wir bauen und unter welchen Bedingungen fangen wir an? Heute Abend mit Alfonso Papa wechselt die Perspektive fundamental: Das Vorhaben läuft seit vier Wochen, der erste Messwert liegt auf dem Tisch, und in drei Tagen steht der finale Entscheidungspunkt an. Und vor allem: Heute Abend arbeiten alle im Kurs ausnahmsweise am selben gemeinsamen Case, bevor es ab zwanzig Uhr in der Werkstatt an die eigenen Projekte geht.

Marc

Genau das ist der Punkt. Viele fragen sich: Warum arbeiten wir heute Abend an einem vorgegebenen Fall und nicht direkt am eigenen Projekt? Die Antwort ist ganz einfach: Eine echte Einführung und eine saubere Abnahmeprüfung brauchen Detailtiefe, Zahlen, Systeme, bestehende Verträge und personelle Realitäten, die man im eigenen Vorhaben zu diesem Zeitpunkt meistens noch gar nicht in dieser Schärfe hat. Und genau dieses Format bereitet euch direkt auf den dreissigsten Oktober vor, auf den Prüfungsteil zwei an der BernEXPO, wo ihr ebenfalls einen fremden Fall mit wenig Zeit knacken müsst. Deshalb wollen wir heute zuerst den Case, seine Ausgangslage und die konkreten Problemfelder genau durchleuchten, bevor wir auf die grossen Best Practices für Rollout und Steuerung eingehen.

Stefan

Schauen wir uns diesen Case also ganz genau an: Es geht um den ISA Desk, den internen Wissensassistenten der Geschäftsstelle eines Branchenverbands. Die Ausgangslage sieht so aus: Der Verband vertritt rund eintausendachthundertfünfzig Mitgliedsfirmen. Pro Jahr gehen etwa zweitausendvierhundert Anfragen ein, das sind rund zehn Anfragen pro Arbeitstag, die sich um Mitgliedschaft, Beiträge und Reglemente drehen. Insgesamt hat die Geschäftsstelle über sechshundert Anfragen pro Monat, aber der Zuschnitt für den KI Assistenten umfasst genau diese drei Themenbereiche. Das Auskunftsteam besteht heute aus zwei Personen, Sandra Keller und Reto Iten, die zusammen gerade mal fünfzig Stellenprozente für die Auskunft aufwenden. Und hier liegt schon der erste grosse Schmerzpunkt: Sie sind chronisch überlastet, die Mitglieder warten oft mehrere Tage auf eine Antwort, und im Budget ist eigentlich eine zusätzliche halbe Stelle vorgesehen. Diese Stelle ist aber unbesetzt.

Marc

Und genau an dieser unbesetzten halben Stelle hängt der gesamte Business Case. Wenn der ISA Desk funktioniert und das Auskunftsteam entlastet, soll diese halbe Stelle dauerhaft unbesetzt bleiben, was dem Verband jährlich fünfundvierzigtausend Franken spart. Wird die Stelle doch besetzt, fällt der grösste Nutzenbaustein schlagartig weg. Gleichzeitig muss Geschäftsführerin Andrea Bühler bis Ende Januar entscheiden, ob die Stelle ausgeschrieben wird. Man hat also einen enormen Zeitdruck im Nacken. Dazu kommt der Vorstand, der an der Delegiertenversammlung im März unbedingt ein erfolgreiches Ergebnis präsentieren will. Das ist die politische und wirtschaftliche Ausgangslage. Und wie sieht die technische Lösung aus? Man hat sich an Tag 10 gegen einen Eigenbau und für ein lizenziertes Cloud Produkt entschieden. Und ganz wichtig: Man hat das Muster E2 gewählt, Vorschlag mit menschlicher Freigabe. Der Assistent schlägt eine Antwort vor, ein Mensch liest und prüft sie, und erst dann geht sie an das Mitglied raus. Keine vollautomatische Beantwortung.

Stefan

Soweit die Theorie. Doch jetzt, nach vier Wochen Sprint Null, schlägt die Realität zu. Es gibt sieben massive Problemfelder und Lücken, die in der Fallakte ganz bewusst offengelegt sind. Problemfeld eins: Die Messung nach Woche drei. Ruth Langenegger, die Leiterin des Wissensmanagements, hat ein Prüfset aus fünfundvierzig echten Anfragen auf Deutsch zusammengestellt. Das Kriterium der Charta lautete: mindestens zweiundfünfzig Prozent der Anfragen müssen ohne menschliche Rückfrage beantwortet werden können. Gemessen wurden aber nur siebenundvierzig Prozent, also einundzwanzig von fünfundvierzig Fällen. Und die Charta besagt glasklar: Unter fünfundvierzig Prozent wird abgebrochen, ab zweiundfünfzig geht es weiter wie geplant, und zwischen fünfundvierzig und zweiundfünfzig Prozent heisst es: anders herangehen. Wir sind bei siebenundvierzig. Es muss also angepasst werden, aber niemand hat bisher definiert, was anders herangehen eigentlich konkret bedeutet.

Marc

Und wenn man diesen Wert von siebenundvierzig Prozent aufschlüsselt, sieht man sofort, wo die Probleme wirklich herkommen. Das ist nämlich keine gleichmässige Schwäche, sondern ein struktureller Riss. Bei Anfragen, die nur auf Reglemente, Merkblätter und FAQs zugreifen, erreicht der Assistent stolze achtundfünfzig Prozent ohne Rückfrage. Aber bei Anfragen, die auf die alte Mitgliederdatenbank zugreifen müssen, stürzt die Quote auf magere einundzwanzig Prozent ab. Nur drei von vierzehn Anfragen gelingen dort. Und warum? Weil die Mitgliederdatenbank aus dem Jahr 2014 stammt. Sie hat eine uralte Schnittstelle, die keinen Einzelfilter kennt, sondern jedes Mal einen kompletten Volldump aller eintausendachthundertfünfzig Mitgliedsdaten liefert. Das dauert vierzig bis neunzig Sekunden. Zusammen mit der KI Strecke reisst das System die Abbruchgrenze von einhundertachtzig Sekunden. Sechs Anfragen sind schlicht im Timeout gelandet.

Stefan

Und die Muss Anforderung M3, die genau das lösen sollte, nämlich ein nächtlicher Abgleich des Volldumps in einen Zwischenspeicher, ist noch gar nicht gebaut. Schlimmer noch: Es ist vertraglich nicht einmal geklärt, ob der Betreiber der Datenbank diesen nächtlichen Abzug überhaupt erlaubt. Tobias Kern, der externe IT Partner, der nur zwei Tage pro Woche da ist, hat die Anfrage erst am dreissigsten September gestellt, und die Antwort steht noch aus. Das ist Problemfeld Nummer eins: die technische Altlast und die unvollständige Zwischenschicht. Problemfeld Nummer zwei ist die Datenlage und die Quellenalter Sperre: Um das Risiko veralteter Auskünfte zu verhindern, wurde eine harte Sperre eingebaut: Dokumente älter als sechs Monate werden blockiert. Das Problem ist nur: Diese Sperre unterscheidet nicht zwischen überholt und alt aber gültig. Ein Beitragsreglement von 2024 ist voll in Kraft, wird aber stur blockiert. Zudem sind rund siebzig von dreihundertvierzig Dokumenten in der Ablage völlig undatiert. Die Sperre blockiert sie alle pauschal, und die Antworten werden zurückgehalten. Und bei eingekauften Vorlagen sind die Nutzungsrechte für KI noch gar nicht geklärt.

Marc

Und dann kommen die menschlichen und organisatorischen Baustellen, die mindestens genauso gravierend sind. Problemfeld Nummer drei: Ruth Langenegger, die das gesamte Wissen im Kopf hat und als einzige die gewachsene Ablage versteht, geht Ende Februar in Pension. Ihre Nachfolge ist nicht geregelt, und es gibt bis heute keinen Übergabeplan. Problemfeld Nummer vier: Im Auskunftsteam ist Sandra Keller begeistert dabei und testet seit Woche zwei. Aber Reto Iten, der seit elf Jahren im Verband arbeitet, zögert massiv. Er hat den Prototyp noch kein einziges Mal benutzt, weil er sich fragt: Was bleibt eigentlich von meiner Aufgabe übrig, wenn das Suchen wegfällt? Diese Angst wurde bisher komplett totgeschwiegen. Problemfeld Nummer fünf: Nadia Frei, die Datenschutzberaterin, und Philipp Zemp, der Leiter Rechtsberatung, haben faktisch ein Veto. Nadia Frei muss den Echtbetrieb freigeben, kennt aber das Zugriffsprotokoll der Zwischenschicht noch gar nicht. Und Philipp Zemp muss sicherstellen, dass der Assistent keine unzulässige Rechtsberatung erteilt. Problemfeld sechs: Die Regionalstellen in Lausanne und Bellinzona wurden gar nicht gefragt und haben erst aus einem Protokoll vom Projekt erfahren. Französisch und Italienisch sind komplett aussen vor. Und Problemfeld sieben: Es existiert überhaupt keine Support Organisation für den laufenden Betrieb. Niemand weiss, wer am Montagmorgen hilft, wenn das System steht, oder wer Änderungen am Prompt freigeben darf. Prompt Änderungen wurden in Woche drei einfach zweimal undokumentiert eingespielt.

Stefan

Das ist die Ausgangslage. Sie zeigt perfekt, wie ein reales Projekt aussieht: Es gibt funktionierende Teilbereiche, aber eben auch technische Schulden, ungeklärte Schnittstellen, Datenchaos, ungeklärte Governance und verunsicherte Mitarbeitende. Genau mit dieser Gemengelage geht ihr heute in die Werkstätten. Und die Frage, die über allem steht, lautet: Wie steuert man ein solches Projekt professionell und wie baut man daraus eine tragfähige Einführung? Das bringt uns direkt zu den Best Practices, die ihr heute Abend beherrschen müsst. Best Practice Nummer eins: Steuerung über eine schonungslose Abnahmeprüfung statt über gefärbte Statusberichte.

Marc

Absolut, Marc. Ein Zwischenresultat ist in der Projektsteuerung nur dann ein Resultat, wenn man es gegen einen vorher schriftlich fixierten Massstab hält. Und dieser Massstab ist die Projektcharta. Ein typischer Statusbericht berichtet immer nur darüber, was fertig ist: Die Maske steht, der Zugriff läuft, die Anbindung ist da. Aber gebaut ist kein Prüfbefund. Für jede Zusage der Charta gibt es bei der Abnahme nur genau drei ehrliche Befunde: erfüllt, nicht erfüllt oder nicht geprüft. Erfüllt heisst: mit harten Zahlen und Belegen nachgewiesen. Nicht erfüllt ist zwar unangenehm, aber transparent und steuerbar. Man weiss genau, woran man arbeiten muss. Der mit Abstand gefährlichste Befund im Projektmanagement ist nicht geprüft. Weil niemand widerspricht und niemand nachgeschaut hat, gilt eine Anforderung stillschweigend als erledigt. Und genau da schlummern die Zeitbomben, wie bei M3 im Fall ISA Desk, wo die Zwischenschicht unter Last überhaupt noch nie getestet wurde.

Stefan

Und dazu gehört die wichtige Unterform noch nicht fällig. Ein Erfolgskriterium wie mindestens zweiundfünfzig Prozent ohne Rückfrage ab Woche acht nach Produktivstart kann vor dem Produktivstart gar nicht erfüllt sein. Wer den heutigen Wert von siebenundvierzig Prozent dagegenhält, vergleicht einen Frühindikator mit einer Bedingung, die noch gar nicht greift. Das ist legitim als Trend, aber man muss es offen so deklarieren. Und zur sauberen Steuerung gehört die Vier Zeilen Dokumentation. Vergesst lange Berichte. Ein wirksamer Bericht hat vier Zeilen: Erstens, der aktuelle Messwert. Zweitens, der Vergleichswert aus der Charta. Drittens, die Veränderung seit dem letzten Mal, gebunden an die Version von Code, Daten und Prompt. Und viertens, was in diesem Berichtszeitraum ungeprüft geblieben ist. Wenn ihr den Prompt ändert, ohne die Version festzuhalten, könnt ihr nie wieder erklären, warum ein Messwert steigt oder sinkt. MLOps Disziplin beginnt genau hier.

Marc

Kommen wir zur zweiten grossen Best Practice: Governance, Compliance und Verantwortlichkeit. Compliance ist nichts, was man am Tag vor dem Go live der Rechtsabteilung vorlegt, um einen Stempel zu holen. Compliance gehört mitten in den Entwicklungsprozess. Bei jeder Zusage der Charta muss gefragt werden: Hat das eine rechtliche Seite und wer bestätigt mit seinem Namen, dass sie eingehalten ist? Nicht die Abteilung Recht, sondern eine konkrete Person mit Termin. Im Fall ISA Desk sind das Philipp Zemp für die Grenze zur Rechtsberatung und Nadia Frei für den Datenschutz. Nach Artikel 22 des Schweizer Datenschutzgesetzes ist bei hohem Risiko eine Datenschutz Folgenabschätzung vor der Bearbeitung Pflicht, und zwar auch vor einem Schattenbetrieb mit echten Daten. Wer Personendaten durch ein System jagt, braucht vorher die Freigabe.

Stefan

Und denkt an den Fall Air Canada von 2024. Das ist das klassische Lehrbeispiel für rechtliche Verantwortung bei KI Systemen. Ein Kunde buchte ein Flugticket, nachdem der Chatbot auf der Website behauptet hatte, man könne den günstigen Trauerfall Tarif auch nachträglich beantragen. Auf einer anderen Unterseite stand das genaue Gegenteil. Als der Kunde die Differenz zurückforderte, lehnte Air Canada ab mit dem Argument, der Chatbot sei eine eigenständige juristische Einheit und das Unternehmen hafte nicht für dessen Falschauskünfte. Das Gericht in British Columbia hat das in aller Klarheit verworfen: Ein Unternehmen ist für jede Information auf seiner Website voll haftbar, ganz egal ob sie von einem Menschen geschrieben oder von einer KI generiert wurde. Genau deshalb ist beim ISA Desk die menschliche Freigabe im Muster E2 kein bürokratisches Beiwerk, sondern die zentrale Compliance Massnahme des ganzen Verbands. Wer Auskünfte erteilt, haftet. Punkt.

Marc

Und damit sind wir bei der dritten Best Practice, dem Kern von Handlungskompetenz D3: Wie konzipiert man die Einführung? Die Kernbotschaft von Tag 18 lautet: Eine Einführung ist keine Frage des Termins, sondern eine Frage der Reihenfolge. Wenn das Management fragt: Wann gehen wir live?, dann setzt das voraus, dass es einen Stichtag gibt, an dem ein Schalter umgelegt wird und alle gleichzeitig umgestellt werden. Genau das ist die Big Bang Methode, und sie ist das gefährlichste Muster überhaupt. Der Fall der britischen Bank TSB von 2018 zeigt das drastisch: Fünf Komma zwei Millionen Kundinnen und Kunden wurden an einem einzigen Wochenende auf eine neue IT Plattform migriert. Technisch kamen die Daten an, aber die Plattform kollabierte im Echtbetrieb vollständig. Filialen, Onlinebanking, Kartenzahlungen, alles stand still. Es dauerte acht Monate, bis der Normalbetrieb wiederhergestellt war, und die Aufsichtsbehörden verhängten eine Busse von fast neunundvierzig Millionen Pfund. Die Lehre daraus: Eine Migration ist erst dann fertig, wenn der Alltag stabil läuft. Wer alle gleichzeitig umstellt, hat keine Gruppe mehr, an der er Fehler zuerst sieht, und keinen alten Weg, auf den er zurückfallen kann.

Stefan

Deshalb arbeiten wir mit differenzierten Einführungsmustern. Und die goldene Regel lautet: Es gibt kein bestes Muster. Es gibt nur das Muster, das exakt zu der Frage passt, die ihr gerade beantworten müsst. Wir unterscheiden fünf Muster. Erstens: Shadow Mode. Das neue System läuft im Hintergrund mit echten Anfragen mit, aber seine Antworten erreichen niemanden extern. Man vergleicht das KI Ergebnis im stillen Kämmerlein mit dem, was der Mensch geantwortet hat. Das beantwortet die Frage: Ist das System qualitativ gut genug? Zweitens: Der Pilot. Eine fest abgegrenzte Gruppe nutzt das System im echten Arbeitsalltag, alle anderen arbeiten wie bisher. Das beantwortet nicht die Qualitätsfrage, sondern die Akzeptanzfrage: Nehmen die Menschen die Lösung an? Passt sie in ihren Arbeitsablauf? Drittens: Canary Release. Ein winziger, schrittweise steigender Prozentsatz des echten Datenverkehrs läuft über das neue System. Das beantwortet die Frage: Hält die Architektur unter Last, und bemerken wir Fehler rechtzeitig? Viertens: Phasing. Die schrittweise Einführung nach Abteilung, Standort, Fallart oder Sprache. Und fünftens: Big Bang, den man nur wählt, wenn ein Parallelbetrieb technisch absolut unmöglich ist.

Marc

Und hier tappen die allermeisten Projektleitenden in dieselbe Falle: Sie wählen reflexartig den Piloten, weil ein Pilot so herrlich vertraut und sicher klingt. Aber wenn eure offene Frage lautet: Schafft das System die Qualitätsquote von zweiundfünfzig Prozent?, dann ist das eine reine Messfrage. Dafür braucht man Daten, keine Nutzer. Wer bei einer Messfrage einen Piloten startet, setzt Mitarbeitende auf ein unfertiges System an, erzeugt Frust, weckt falsche Erwartungen und riskiert, dass das Tool verbrannt ist, bevor es überhaupt optimiert wurde. Denkt an McDonald's und den Drive thru Test mit IBM: Ein Pilot an über hundert Standorten lief über drei Jahre, ohne klares Enddatum und ohne harte Abbruchschwellen, bis man ihn schliesslich stoppen musste. Ein Pilot ohne feste Kriterien hört von alleine nicht auf.

Stefan

Um das richtige Muster auszuwählen, nutzt ihr die vier Entscheidungsfragen: Erstens: Wie schnell merkt man einen Fehler? Wenn man keine automatisierte Echtzeitüberwachung hat, merkt man Fehler erst, wenn sich ein Kunde beschwert. Dann scheidet ein Canary Release aus, und man muss zuerst in den Shadow Mode. Zweitens: Was kostet ein Fehler? Eine falsche Tarifauskunft kostet Geld, eine falsche Rechtsberatung kostet das Vertrauen der Mitglieder und zieht Haftung nach sich. Je teurer der Fehler, desto weniger echte Nutzer dürfen in der ersten Phase involviert sein. Drittens: Wie viele Fälle braucht eine statistisch belastbare Aussage? Bei zehn Anfragen am Tag braucht man Wochen, um ein paar hundert Fälle zu sammeln. Wer da mit Nutzern testet, verliert wertvolle Zeit. Viertens: Wie teuer ist der Rückweg? Solange der alte Prozess parallel weiterläuft, ist der Rückweg billig. Aber wenn Stellen umbesetzt oder alte Verträge gekündigt werden, wird der Rückweg extrem teuer. In Werkstatt zwei müsst ihr ein Muster für Phase eins wählen und die vier anderen mit genau diesen Fragen begründet verwerfen. Das Verwerfen ist die eigentliche intellektuelle Leistung.

Marc

Und denkt an die Überwachung, wenn ihr über Stabilität nachdenkt. Knight Capital im August 2012 ist die ultimative Mahnung. Ein fehlerhafter Software Rollout für den automatisierten Aktienhandel führte dazu, dass das System vor Börsenöffnung siebenundneunzig automatisierte Warn E Mails verschickte. Siebenundneunzig Warnungen. Niemand hat sie gelesen. Niemand war zuständig. Innerhalb von fünfundvierzig Minuten nach Handelsbeginn feuerte das System über vier Millionen fehlerhafte Orders in den Markt, und Knight Capital verlor über vierhundertsechzig Millionen Dollar. Die Lehre daraus: Überwachung ab Tag 1 heisst nicht, dass irgendwo ein Logfile geschrieben wird. Es heisst, dass ein Mensch mit Namen und Telefonnummer bestimmt ist, der die Alarme liest, und dass eine glasklare Regel existiert, wann das System per Feature Flag oder Not Aus Schalter sofort abgeschaltet wird. Rückweg in Minuten.

Stefan

Das alles fliesst schliesslich in das Meisterstück des heutigen Abends ein: den Phasing Plan auf einer Seite. Das ist die Vorlage, an der ihr in Werkstatt drei arbeitet. Vier Phasen, im Querformat, und jede Phase muss drei Spuren synchron abdecken: Organisation, Technik und Menschen. In der Spur Organisation steht: An welcher Stelle greift das System in den Ablauf ein? Wer betreibt den Support mit festen Zeiten und geregelter Vertretung? Und wer entscheidet über Änderungen an Prompts oder Sperren? In der Spur Technik steht: Welche Systeme sind angebunden? Was muss an Daten vorher bereinigt werden und was kann warten? Und welche präzise Fachfrage geht mit Termin an welchen Experten? Das Teure und Komplexe, wie die Anbindung alter Datenbanken, schiebt man in spätere Phasen, statt das Projekt von Tag eins an damit zu blockieren. Und in der Spur Menschen steht: Wer erfährt wann wovon, und wer braucht welche Schulung? Differenziert die Zielgruppen. Jemand, der Antworten freigibt, braucht ein ganz anderes Training als jemand, der nur informiert werden muss. Und gebt rechtzeitig eine Antwort auf die Frage von Menschen wie Reto Iten: Was bleibt von meiner Aufgabe übrig?

Marc

Und das Entscheidende an diesem Phasing Plan sind die Ein und Austrittskriterien für jede einzelne Phase. Ein Kriterium wie das Team fühlt sich bereit oder die Schulung ist abgeschlossen ist kein Kriterium. Ein Kriterium muss eine harte Zahl sein oder ein prüfbares Ja mit Unterschrift. Zum Beispiel: Phase eins endet erst, wenn an zweihundert echten Fällen im Schattenbetrieb eine Freigabequote von über fünfundfünfzig Prozent ohne Rückfrage gemessen wurde und Nadia Frei die Datenschutzfreigabe schriftlich unterzeichnet hat. Vorher geht es nicht in Phase zwei. Jede Phase ist ein kleiner, verbindlicher Entscheidungspunkt. Und zum Schluss macht ihr die Gegenprobe: Wenn der Vorstand kommt und sagt: Wir müssen zwei Monate früher fertig werden!, welche Phase streicht ihr dann aus dem Plan, was kostet dieser Verzicht an Qualität oder Risiko, und wer übernimmt dafür die Verantwortung? Ein Phasing Plan, der diese Gegenprobe nicht besteht, ist kein Plan, sondern nur ein Wunschzettel.

Stefan

Fassen wir die fünf wichtigsten Grundsätze zusammen, die ihr für heute Abend und die Vorbereitung auf die Prüfung im Kopf haben müsst: Erstens: Ein Zwischenergebnis zählt nur im Vergleich zu den vorher festgelegten Kriterien der Projektcharta. Zweitens: Nicht geprüft ist der gefährlichste Befund in jedem Projekt, weil er trügerische Sicherheit vortäuscht. Drittens: Compliance, Haftung und Support brauchen verbindliche Namen und klare Prozesse vor dem ersten echten Datenkontakt. Viertens: Wählt euer Einführungsmuster passend zur offenen Frage: Bei Messfragen gilt Daten statt Nutzer, bei Akzeptanzfragen braucht es den Piloten. Und fünftens: Jede Phase im Phasing Plan beantwortet genau eine Frage, steuert Organisation, Technik und Menschen synchron und wird durch messbare Zahlen für Eintritt und Austritt begrenzt.

Marc

Mit diesem Rüstzeug seid ihr perfekt vorbereitet für den Abend mit Alfonso Papa. Nutzt die Werkstatt am Fall ISA Desk, um die Argumentationsmuster und das Verwerfen von Optionen sauber einzuüben. Und ab zwanzig Uhr überträgt ihr genau diese Logik auf euer eigenes Vorhaben für Wochenaufgabe fünf. Wir wünschen euch einen hochspannenden, lehrreichen Abend. Bis zum nächsten Mal!