Copilot-Einführung bei der Harry Hase AG

Management Summary

Die Harry Hase AG (Name geändert, echter Name auf Anfrage), ein etablierter Automobilzulieferer mit 4.000 Mitarbeitern, hat sich das Ziel gesetzt, Künstliche Intelligenz (KI) als produktiven Co-Piloten für seine Wissensarbeiter einzuführen. Als externer Projektleiter habe ich dieses Vorhaben – von der ersten Vision bis zum Übergang in den produktiven Regelbetrieb – geleitet. Durch den Einsatz von KI sollen die Produktivität gesteigert, die Qualität gesichert, die Time-to-Insight verkürzt und Kosten reduziert werden.

Um diese Ziele zu erreichen, haben wir konkrete, messbare KPIs definiert. Beispielsweise strebten wir eine Automatisierungsquote von 30% bei bestimmten Routineaufgaben an, eine Halbierung der Durchlaufzeiten für wiederkehrende Berichte, eine Reduktion des Support-Ticket-Volumens um 20% sowie eine Verkürzung der Dokumentenerstellungszeiten um 40%. Diese Kennzahlen dienten als Richtschnur, um den Erfolg der KI-Einführung quantifizierbar zu machen.

Der Projektrahmen war entsprechend ambitioniert abgesteckt: Eine Laufzeit von 18 Monaten, ein Budget im hohen sechsstelligen Euro-Bereich und eine klare Governance-Struktur für Entscheidungen. Der CIO der Harry Hase AG übernahm als Sponsor die Schirmherrschaft, ein Steering Committee aus IT-Leitung und Fachbereichsleitung steuerte den strategischen Kurs. Gemeinsam sorgten wir dafür, dass das Projekt im Rahmen blieb und technische, rechtliche sowie organisatorische Vorgaben durchgehend eingehalten wurden.

Ausgangssituation der Harry Hase AG

Unternehmensprofil und Prozesslandschaft

Die Harry Hase AG ist ein mittelständischer Automobilzulieferer mit über 130 Jahren Firmengeschichte. Das Unternehmen beschäftigt rund 4.000 Mitarbeiter und bedient eine breite Prozesslandschaft: von der Forschung & Entwicklung über Einkauf und Produktion bis hin zu Qualitätsmanagement, Logistik, Vertrieb und Aftermarket. Jede dieser Abteilungen bringt spezifische Informationsbedürfnisse und Arbeitsabläufe mit sich. Vor Projektbeginn erfolgte die Wissensarbeit klassisch – Angebote wurden manuell erstellt, Qualitätsberichte in Word geschrieben, Kundenanfragen per E-Mail beantwortet. Die Digitalisierung war bereits fortgeschritten, doch der gezielte Einsatz von KI fehlte noch.

Als Automobilzulieferer steht die Harry Hase AG im Wettbewerb unter hohem Kostendruck und Qualitätsanspruch. Fehlerfreie Prozesse, schnelle Reaktionszeiten auf Kundenanfragen und ein hohes Innovationstempo sind überlebenswichtig. In dieser Ausgangslage entstand der Wunsch, mit KI-Unterstützung einen weiteren Effizienzsprung zu erzielen, Routinetätigkeiten zu automatisieren und Mitarbeitern mehr Zeit für wertschöpfende Aufgaben zu verschaffen.

IT-Landschaft mit Microsoft 365

IT-seitig war eine solide Grundlage vorhanden. Die Harry Hase AG nutzt seit zwei Jahren Microsoft 365 als zentrale Produktivitätsplattform. Alle 2.000 Büro-Mitarbeiter – vom Entwickler bis zum Vertriebler – arbeiten mit Office 365 Apps, Exchange Online, SharePoint Online, OneDrive und Microsoft Teams. Die Mitarbeiter sind mit der Cloud-Umgebung vertraut; das Entra ID (Azure AD) für Identitätsmanagement ist etabliert, und unternehmensweit gelten uniforme Sicherheitsrichtlinien für Anmeldungen (z.B. Multi-Faktor-Authentifizierung und Conditional Access).

Neben den M365-Workloads bestehen weitere zentrale Datenquellen: ein ERP-System (SAP) für Materialwirtschaft und Finanzen, ein PLM-System für Produktdaten, ein MES für die Produktionssteuerung sowie ein Data Warehouse, das Daten für Analysen konsolidiert. Zudem gibt es historische File Shares mit Altdaten, die noch nicht vollständig nach SharePoint migriert wurden. Diese heterogene Landschaft bedeutete für das KI-Projekt: die relevanten Daten liegen verteilt und müssen möglichst zugreifbar gemacht werden, ohne Sicherheits- oder Compliance-Regeln zu verletzen.

Datenmanagement und Compliance-Status

Vor Start des KI-Projekts haben wir den Reifegrad des Datenmanagements beurteilt. Positiv war, dass bereits eine Basis an Informationsschutz existierte – es gab klassifizierte Dokumente mit Sensitivitätslabeln und definierte Aufbewahrungsfristen in Microsoft 365. Auch eine Betriebsvereinbarung zur Nutzung von Cloud-Diensten lag vor, die den grundsätzlichen Rahmen für Datenschutz und IT-Compliance steckte. Allerdings zeigte sich auch Handlungsbedarf: Die Datenqualität war in einigen Bereichen uneinheitlich, Metadaten wurden nicht konsequent gepflegt, und nicht für alle relevanten Datenbestände gab es klare Verantwortlichkeiten (Data Owner).

In puncto Security-Basis waren die fundamentalen Maßnahmen umgesetzt: aktuelle Endpoint-Security auf den Clients, strenge Berechtigungsvergaben nach dem Need-to-know-Prinzip und etablierte DLP-Richtlinien zum Schutz vertraulicher Informationen. Auch Compliance-seitig (Stichwort DSGVO) war man bereits relativ gut aufgestellt – ein Datenschutzbeauftragter war involviert, es existierten Verzeichnisse von Verarbeitungstätigkeiten und technische-organisatorische Maßnahmen (TOMs) für bestehende IT-Systeme. Diese vorhandenen Strukturen bildeten ein stabiles Fundament, um darauf ein KI-Projekt sicher aufzusetzen. Dennoch war klar, dass wir im Verlauf der KI-Einführung die bestehenden Policies präzisieren und um KI-spezifische Regelungen erweitern müssen, etwa durch eine ergänzte Betriebsvereinbarung für KI-Anwendungen.

Vision, Strategie und Zielbild für KI

Leitbild: KI als Co-Pilot

Zu Beginn des Projekts habe ich gemeinsam mit dem Management ein klares Leitbild formuliert: „KI als Co-Pilot“. Die KI sollte den Mitarbeitern als intelligenter Assistent dienen – vergleichbar einem Co-Piloten im Cockpit, der Routineaufgaben übernimmt und dem Piloten wichtige Informationen liefert, während die Kontrolle und Entscheidungshoheit immer beim Menschen bleibt. Dieses Bild half allen Beteiligten, die Rolle der KI richtig einzuordnen: nicht als Ersatz für menschliche Mitarbeiter, sondern als Werkzeug zur Ergänzung ihrer Fähigkeiten.

Die Vision war, dass in jedem Fachbereich KI-Unterstützung selbstverständlicher Teil der Arbeit wird. Entwickler sollten einen Co-Piloten für Code und technische Dokumentation erhalten, der Vertriebsinnendienst einen Assistenten für Angebote und Kunden-E-Mails, die Qualitätssicherung eine Hilfe bei Auswertungen und Berichtswesen, usw. Dieses Zielbild wurde früh und klar kommuniziert: Wir wollten den Sprung von vereinzelten KI-Experimenten hin zu einem strategischen, unternehmensweiten Einsatz schaffen.

Leitprinzipien für den KI-Einsatz

Auf dem Weg zur KI-gestützten Organisation haben wir uns von zentralen Prinzipien leiten lassen. Erstens stand die Sicherheit der Daten und Systeme an oberster Stelle: Jede KI-Lösung musste unseren strengen Sicherheitsstandards genügen. Zweitens hatte der Datenschutz absolute Priorität – personenbezogene oder vertrauliche Informationen sollten durch die KI nie unbefugt abfließen oder missbraucht werden. Drittens legten wir großen Wert auf Nachvollziehbarkeit: Die Ergebnisse, die eine KI liefert, müssen für den Anwender transparent und erklärbar sein. Wo immer möglich, sollte die KI Quellen oder Erklärungen zu ihren Auskünften mitliefern, um Vertrauen zu schaffen.

Ein weiteres Prinzip war die strikte Nutzenorientierung: Wir setzten KI nicht zum Selbstzweck ein, sondern nur dort, wo ein klarer Mehrwert für die Mitarbeiter entsteht. Jeder Use Case wurde daraufhin geprüft, ob er Arbeit spürbar erleichtert oder beschleunigt. Außerdem galt „Human in the Loop“ als Maxime: KI-Unterstützung sollte immer den Menschen einbinden. Das heißt, wichtige Entscheidungen oder Freigaben liegen weiterhin bei unseren Fachkräften; die KI liefert Vorschläge, Vorarbeit und Analysen, aber der Mensch steuert und validiert. Dieses Prinzip hilft nicht nur, Fehler zu vermeiden, sondern erleichterte auch die Akzeptanz, weil die Mitarbeiter wussten, dass sie nicht „entmündigt“ werden.

Abgrenzung: Was KI leisten soll – und was nicht

Gleichzeitig haben wir klar abgegrenzt, wofür KI eingesetzt werden soll und wofür nicht. Die KI sollte unsere Wissensarbeiter bei repetitiven, zeitaufwendigen Aufgaben entlasten: z.B. automatische Zusammenfassungen von Meetings und Dokumenten erzeugen, erste Entwürfe für Angebote oder Berichte schreiben, E-Mails auf Basis vordefinierter Antworten formulieren oder Daten aus verschiedenen Quellen konsolidieren. Ebenso sollte sie als intelligentes Such- und Hilfsmittel dienen, um intern schneller an benötigtes Wissen zu gelangen (statt lange in Handbüchern oder Intranets zu recherchieren).

Nicht leisten sollte die KI dagegen alles, was kritische Entscheidungen ohne menschliche Prüfung betrifft oder hochkomplexe fachliche Bewertungen, die außerhalb ihres Trainingsstandes liegen. So wurde z.B. ausgeschlossen, dass KI autonom über die Qualitätsfreigabe von Produkten entscheidet oder rechtlich bindende Aussagen generiert. Auch eine Mitarbeiterüberwachung oder Leistungsbewertung durch KI wurde explizit ausgeschlossen – die Einführung erfolgte unter dem Versprechen, dass die KI ein Unterstützer für die Belegschaft ist und kein Kontrollinstrument. Diese Abgrenzungen wurden in Schulungen und der Kommunikation immer wieder betont, um unrealistische Erwartungen zu dämpfen und Vorbehalte abzubauen.

Use-Case-Portfolio & Priorisierung

Methodik zur Use-Case-Identifikation

Um herauszufinden, wo KI den größten Nutzen stiften kann, haben wir einen strukturierten Prozess zur Use-Case-Findung durchlaufen. Zunächst haben wir Standardanwendungsfälle betrachtet, die Microsoft 365 Copilot von Haus aus bietet – etwa automatische Meeting-Zusammenfassungen in Teams oder das Generieren von Aufgabenlisten aus Besprechungen. Zusätzlich haben wir uns an branchentypischen Beispielen und Studien (z.B. Microsofts Work Trend Index) orientiert, um bewährte Einsatzmöglichkeiten nicht zu übersehen.

Der Kern der Identifikation war jedoch die enge Einbindung der Fachbereiche. In gemeinsamen Workshops mit Einkauf, Entwicklung, Qualität, Vertrieb und weiteren Abteilungen haben wir gezielt nach Schmerzpunkten und Verbesserungsmöglichkeiten im Arbeitsalltag gesucht. Die Mitarbeiter beschrieben repetitive oder zeitintensive Aufgaben, bei denen sie sich Unterstützung wünschten. Wichtig war dabei auch ein erstes Erwartungsmanagement: In der Diskussion klärten wir direkt, was heutige KI-Tools wie Copilot realistisch leisten können – und wo ihre Grenzen liegen. So wurde vermieden, dass Fachbereiche völlig utopische Vorstellungen entwickeln oder später enttäuscht würden.

Nach diesen Workshops lag eine umfangreiche Liste potenzieller Use Cases auf dem Tisch. Um daraus ein machbares Portfolio zu schnüren, haben wir die Vorschläge mittels Value Tree-Analyse auf ihren geschäftlichen Wert abgebildet und nach dem Pareto-Prinzip vorsortiert: Welche 20% der Ideen versprachen 80% des Nutzens? Diese verdichtete Auswahl haben wir anschließend einem systematischen Scoring unterzogen.

Bewertung und Priorisierung

Jeder identifizierte Use Case wurde anhand mehrerer Kriterien bewertet:

• Nutzenpotenzial: Wie stark verbessert oder beschleunigt der Use Case einen Prozess? Lässt er sich in eingesparter Zeit, höherer Qualität oder Kundenzufriedenheit quantifizieren?
• Machbarkeit: Ist der Use Case technisch umsetzbar? Verfügt die KI (insbesondere Microsofts Copilot) über die nötigen Funktionen, um diese Aufgabe zu erfüllen?
• Datenverfügbarkeit: Sind die benötigten Daten vorhanden und zugänglich (z.B. in SharePoint, Datenbanken) und in ausreichender Qualität? Oder müsste erst umfangreiches Data Cleaning betrieben werden?
• Compliance-Risiko: Welche datenschutz- oder sicherheitsrelevanten Risiken bestehen beim jeweiligen Use Case? (Beispiel: beinhaltet er personenbezogene Daten oder sensible Geschäftsinformationen?)
• Skalierbarkeit: Lässt sich der Use Case, einmal erfolgreich pilotiert, unternehmensweit ausrollen? Oder ist er sehr bereichsspezifisch?
• Change-Aufwand: Wie stark müssten sich Benutzer umgewöhnen? Benötigt der Use Case intensive Schulungen oder prozessuale Anpassungen?

Diese Kriterien haben wir in einer Bewertungsmatrix je Use Case zusammengetragen. Daraus ergab sich ein Ranking, welche Anwendungsfälle sowohl hohen Nutzen als auch gute Realisierbarkeit versprachen. Die Top-Ergebnisse dieser Priorisierung sind in der folgenden Tabelle auszugsweise dargestellt:

Bereich	Use Case	Nutzen	Machbarkeit	Datenlage	Risiko	Priorität
Vertrieb	Angebotsassistent (Erstellung von Angeboten und Spezifikationen)	hoch	hoch	mittel	mittel	1
Qualität	Qualitätsdokumentation (Prüfberichte automatisch vorbefüllen)	hoch	mittel	hoch	niedrig	2
Einkauf	Lieferantenkommunikation (automatisierte Anfragen, Übersetzungen)	mittel	hoch	mittel	mittel	3
Kundenservice	Reklamationsanalyse (KI-Auswertung von Kundenfeedback)	hoch	mittel	mittel	hoch	4
Unternehmen übergreifend	Wissenssuche (KI-Chatbot für interne Wissensdatenbanken)	hoch	hoch	mittel	niedrig	5
Büro allgemein	Routinekorrespondenz (automatisiertes Entwerfen von Standard-E-Mails)	mittel	hoch	hoch	niedrig	6
Entwicklung	Code-Assistenz für Citizen Developer (Unterstützung in Power Platform)	mittel	mittel	mittel	mittel	7

Anhand dieser Priorisierung konnten wir entscheiden, welche Use Cases zuerst in Angriff genommen wurden. Wir legten Wert auf eine Mischung aus Quick Wins und Leuchtturm-Projekten: Einerseits schnell umsetzbare, eng begrenzte Anwendungen (z.B. automatisierte Meeting-Zusammenfassungen), die rasch Erfolgserlebnisse liefern. Andererseits einige strategische Leuchtturm-Use-Cases, die zwar mehr Aufwand erforderten, aber einen großen Wirkungsgrad und Signalwirkung für das ganze Unternehmen hatten. Dieser Mix half, Schwung ins Projekt zu bringen, ohne sich jedoch nur auf triviale Verbesserungen zu beschränken oder umgekehrt im Komplexen zu verzetteln.

Datenstrategie & Informationsarchitektur

Quellsysteme, Datenklassifikation und Taxonomien

Für die Umsetzung der identifizierten Use Cases war eine robuste Datenstrategie unabdingbar. Im ersten Schritt haben wir die relevanten Quellsysteme und Datenbestände erfasst. Dazu zählten insbesondere die Microsoft-365-Daten (SharePoint-Dokumentbibliotheken, OneDrive der Benutzer, Teams-Chats), aber auch externe Systeme wie das ERP, PLM und das Data Warehouse. Wir katalogisierten, welche Informationen wo liegen und wie kritisch sie jeweils sind.

Ein wichtiger Baustein war die Datenklassifikation. Bereits vorhandene Klassifizierungen (z.B. „Vertraulich“, „Intern“) haben wir für das KI-Projekt konkretisiert. Gemeinsam mit dem Informationssicherheitsbeauftragten definierten wir, welche Datenarten überhaupt für KI verarbeitet werden dürfen. So war z.B. klar, dass hochvertrauliche Dokumente (etwa Prototypen-Pläne oder Führungsgremien-Protokolle) vom KI-Zugriff ausgenommen bleiben. Für die freigegebenen Daten wurden Taxonomien und ein Metadatenmodell abgestimmt, damit die KI Inhalte später besser einordnen kann. Zum Beispiel erhielten Produktdokumentationen Tags für Bauteil, Kundenprojekt und Versionsstand. Auch Aufbewahrungsregeln (Retention Policies) spielten hier hinein: die KI sollte bevorzugt auf aktuelle Informationen zugreifen, archivierte Altdaten wurden ausgeblendet, um Fehlinformationen zu vermeiden.

Datenqualität und Zugriffsmodelle

Weil KI nur so gut sein kann wie die Daten, auf denen sie basiert, haben wir früh in Datenqualitäts-Maßnahmen investiert. Datenprofis aus dem Data-Warehouse-Team führten ein Data Profiling in Schlüsselbereichen durch, um Lücken, Dubletten oder veraltete Inhalte aufzudecken. Wo nötig, initiierten wir eine Bereinigung: zum Beispiel wurden in SharePoint nicht mehr gültige Dokumentversionen gekennzeichnet oder entfernt, Stammdaten im ERP aktualisiert und Dubletten in Wissensdatenbanken konsolidiert. Außerdem benannten wir für wichtige Datenbestände Data Owner, die die Verantwortung für die inhaltliche Pflege übernehmen. Dieses Data Stewardship stellte sicher, dass auch nach Projektende die Datenqualität aufrechterhalten wird.

Parallel dazu haben wir die Zugriffsmodelle überprüft und optimiert. Nach dem Prinzip des Least Privilege bekam die KI (bzw. die zugrundeliegenden Dienste) nur auf diejenigen Informationen Zugriff, die ein Benutzer auch regulär sehen darf. Microsofts Graph-API dient hier als Tor zu den Daten: Wir stellten sicher, dass Berechtigungen in SharePoint, Teams & Co. korrekt und aktuell sind, damit keine unbefugten Informationsabfragen durch die KI möglich sind. In manchen Fällen führte das dazu, alte pauschale Berechtigungen zu reduzieren oder aufzuräumen. Außerdem musste geklärt werden, wie mit Mandantentrennung und Umgebungen verfahren wird: Die Harry Hase AG betreibt einen einzigen M365-Tenant für alle Standorte, was die KI-Integration erleichterte. Für Tests und Entwicklungen richteten wir separate Testumgebungen bzw. einen nicht-produktiven Tenant ein, um neue KI-Funktionen gefahrlos mit Echtdaten ausprobieren zu können, ohne den Produktivbetrieb zu beeinflussen.

Integration und Governance-Struktur

Ein Schlüsselfaktor war die reibungslose Integration der KI in die bestehende Informationsarchitektur. Microsoft 365 Copilot zieht Daten über den Microsoft Graph; daher haben wir die nötigen Graph-Konnektoren aktiviert, um auch externe Quellen einzubinden. Beispielsweise implementierten wir einen Graph Connector für das lokale File Share, sodass die dort gespeicherten Wissensdokumente ebenfalls durchsuchbar und für KI-Anfragen nutzbar wurden. Ähnliches gilt für bestimmte Datenbankinhalte aus dem ERP/PLM: Hier haben wir priorisiert nur die Felder und Tabellen eingebunden, die für die ausgewählten Use Cases relevant sind (z.B. Produktstammdaten für den Angebotsassistenten). Die Maxime war, Integration vor Perfektion: Lieber schnell die wichtigsten Datenquellen anschließen, als in endlosen Datenmodellierungsprojekten zu verharren.

Zur Governance der Informationen haben wir zudem bestehende Artefakte erweitert: Ein unternehmensweiter Datenkatalog dokumentiert nun, welche Datenquelle für welche KI-Funktion genutzt wird und wer dafür verantwortlich zeichnet. Neue Richtlinien legen fest, dass vor Einbindung einer Datenquelle in KI-Anwendungen ein Freigabeprozess durch Datenschutz und IT-Security erfolgt. Verantwortlichkeiten wurden klar geregelt – etwa, dass der Leiter Business Intelligence als Data Trustee die Einhaltung der Data Governance überwacht. Durch diese Strukturen ist gewährleistet, dass die KI auf einem zuverlässigen, vertrauenswürdigen Datenfundament aufsetzt und die Datenhoheit im Unternehmen bleibt.

Sicherheits-, Compliance- und Governance-Konzept

Identitäts- und Zugriffsverwaltung

Ein zentrales Element des Sicherheitskonzepts war die Identitäts- und Zugriffsverwaltung. Da alle KI-Funktionen auf bestehenden M365-Diensten aufsetzen, konnten wir auf die solide Basis von Entra ID (Azure AD) zurückgreifen. Wir stellten sicher, dass für sämtliche Benutzer, die KI nutzen, die Multi-Faktor-Authentifizierung (MFA) verpflichtend aktiv ist. Zusätzlich wurden gezielte Conditional Access-Regeln definiert: Zum Beispiel durften KI-Anfragen nur aus dem Unternehmensnetz oder von registrierten Geräten gestellt werden, um das Risiko unautorisierter Zugriffe zu minimieren. Die Rollen und Berechtigungen in der Azure AD wurden überprüft, um sicherzustellen, dass keine zu weitreichenden Privilegien für KI-Dienste oder Accounts bestehen.

Darüber hinaus richteten wir eigene Service Accounts bzw. eine verwaltete Identität für eventuelle Integrationsdienste ein, mit streng limitierten Rechten. Jeder Zugriff der KI auf Backend-Systeme (z.B. falls über eine API Daten aus dem ERP gezogen werden) erfolgt über solche privilegierten Konten, die nur genau die benötigten Rechte besitzen und deren Nutzung lückenlos protokolliert wird. Damit stellten wir sicher, dass die KI sich in das vorhandene IAM-Rahmenwerk nahtlos einfügt.

Informationsschutz und Compliance-Richtlinien

Die bestehende Informationsschutz-Architektur wurde für die KI-Einführung gezielt erweitert. So wurden etwa die Sensitivity Labels (Vertraulichkeitsstufen) um Richtlinien für KI-Nutzung ergänzt: Dokumente, die als „Streng Vertraulich“ markiert sind, dürfen von der KI gar nicht verarbeitet oder angezeigt werden. Für andere Klassifizierungen gelten abgestufte Regeln, die wir in den Microsoft Purview Compliance-Einstellungen konfigurierten.

Zusätzlich kamen Data Loss Prevention (DLP)-Regeln zum Einsatz, um zu verhindern, dass sensible Daten über KI-Abfragen das Unternehmen verlassen. Konkret haben wir z.B. Richtlinien definiert, die unterbinden, dass personenbezogene Daten oder geheime Projektnamen in eine KI-Eingabe eingebracht werden, die auf externe LLMs zugreifen könnte. Zwar nutzt Copilot die Daten innerhalb des Microsoft-Graphen, aber wir wollten auch für zukünftige Erweiterungen (oder für den Fall, dass Mitarbeiter doch eigenständig externe KI-Tools nutzen) vorsorgen.

Ein weiterer Aspekt war E-Discovery und rechtliche Haltbarkeit von Informationen. Zusammen mit der Rechtsabteilung haben wir festgelegt, wie KI-generierte Inhalte zu behandeln sind: Zum Beispiel, ob eine von der KI erstellte E-Mail als offizielles Geschäftsdokument zu archivieren ist und wie man revisionssicher festhält, dass der Inhalt von einer KI verfasst (und vom Mitarbeiter freigegeben) wurde. Unsere Compliance-Richtlinien wurden entsprechend angepasst, damit im Ernstfall (z.B. Prüfungen oder Rechtsstreitigkeiten) nachvollziehbar bleibt, welche Informationen aus KI-Unterstützung stammen.

Auditierbarkeit und Nachvollziehbarkeit

Weil beim Einsatz von KI das Thema Nachvollziehbarkeit kritisch ist, haben wir technische und prozessuale Maßnahmen zur Auditierbarkeit eingeführt. Technisch wurde das Logging erweitert: Jede KI-Anfrage und -Antwort lässt sich in den Microsoft 365 Audit Logs nachvollziehen, inklusive welcher Benutzer wann was angefragt hat. Wir richteten Alerts ein, um auffällige Nutzungen schnell zu erkennen (z.B. wenn jemand in kurzer Zeit außergewöhnlich viele oder spezifische Daten abfragt).

Parallel dazu vereinbarten wir intern klare Dokumentationspflichten, falls KI in kritischen Prozessen genutzt wird. Beispielsweise muss in einem Angebot vermerkt werden, wenn Teile des Textes durch KI generiert und vom Sachbearbeiter nur noch überprüft wurden. Diese Transparenz nach innen und außen schützt das Unternehmen: Man kann bei Bedarf belegen, wie ein bestimmter Inhalt entstanden ist. Auch im Rahmen der Betriebsrat-Abstimmungen war diese Maßnahme wichtig, um Bedenken hinsichtlich einer Intransparenz der KI zu begegnen.

Betriebsvereinbarung, Zweckbindung und Mitarbeitertransparenz

Die Einführung von KI tangiert auch die Mitbestimmung. Daher haben wir von Anfang an den Betriebsrat und den Datenschutzbeauftragten eng eingebunden. Bereits vor dem Pilotstart einigten wir uns auf Eckpunkte für eine Betriebsvereinbarung KI. Darin wurden die Zweckbindung der KI-Nutzung klar definiert (also zu welchen Zwecken die KI genutzt werden darf und wozu nicht) und die Transparenz gegenüber den Mitarbeitern festgeschrieben. So haben wir zugesichert, dass niemand durch die KI-Leistung überwacht oder beurteilt wird, und dass jeder Mitarbeiter weiß, welche KI-Tools im Einsatz sind und welche Daten dafür herangezogen werden.

Die Betriebsvereinbarung enthält außerdem Regelungen zur Freiwilligkeit und Qualifizierung: Die Nutzung von KI-Unterstützung ist ein Angebot und kein Zwang. Mitarbeiter, die mit KI arbeiten, erhalten Schulungen und dürfen jederzeit Feedback oder Kritik äußern. Wir richteten hierzu eigene Feedback-Kanäle und Anlaufstellen (z.B. im Intranet und via Teams) ein. Durch diese transparente und partizipative Gestaltung konnten wir das Vertrauen der Belegschaft gewinnen und den formalen Anforderungen der Mitbestimmung gerecht werden.

Risikoanalyse und Gegenmaßnahmen

Im Sicherheits- und Governance-Konzept haben wir gezielt Risiken bewertet und Gegenmaßnahmen definiert. Ein zentrales Risiko war das Phänomen der Halluzination von KI-Modellen – also dass die KI überzeugend klingende, aber falsche Antworten gibt. Unsere Maßnahme hier: Mitarbeiter wurden sensibilisiert, KI-Ergebnisse nicht ungeprüft zu übernehmen. Zudem entwickelten wir Prozesse, dass kritische Ausgaben der KI stets einen Review durch Fachexperten durchlaufen.

Ein weiteres Risiko betraf den Datenabfluss. Hier adressierten die technischen Maßnahmen (DLP, Berechtigungen) bereits viel. Zusätzlich untersagten wir die Nutzung nicht freigegebener KI-Tools (Shadow-KI) über eine Richtlinie und kommunizierten deutlich die Gefahren, wenn Mitarbeiter z.B. interne Texte in externe Dienste wie ChatGPT eingeben. Durch das Angebot einer offiziellen, sicheren KI-Lösung (Copilot in unserer geschützten Umgebung) und klare Policies konnte wir Shadow-IT weitgehend eindämmen.

Auch Bias und ethische Fragen wurden thematisiert: Die KI sollte keinen diskriminierenden oder unangemessenen Output liefern. Wir überprüften daher stichprobenartig die KI-Antworten im Pilotbetrieb auf etwaige Verzerrungen und hielten fest, dass im Zweifel ein Mensch eingreift, falls die KI-Ausgabe gegen Unternehmenswerte oder -richtlinien verstößt. Insgesamt sorgte das ganzheitliche Sicherheits- und Compliance-Konzept dafür, dass die KI-Einführung nicht nur technisch, sondern auch regulatorisch und ethisch auf solidem Fundament stand.

Architektur & Plattformwahl

Die Entscheidung für die technische Plattform fiel auf eine Kombination von Microsoft-365-integrierten KI-Funktionen und ergänzenden Azure-Diensten. Kern der Lösung ist Microsoft 365 Copilot, der sich nahtlos in die bestehenden Office-Anwendungen und Microsoft Teams integriert. Das bedeutete, dass die Benutzer ihre gewohnte Arbeitsumgebung nicht verlassen müssen, um KI-Unterstützung zu nutzen: Copilot steht direkt in Word, Outlook, Excel, PowerPoint und Teams als Assistenz zur Verfügung. Damit nutzen wir die Stärke der Plattform – die Integration in die Office-Welt und den Zugriff auf Unternehmensdokumente über den Microsoft Graph.

Für spezielle Anforderungen, die über die Standardfunktionen von Copilot hinausgehen, zogen wir punktuell Azure KI-Services hinzu. Ein Beispiel ist die Analyse unstrukturierter Kundenkommentare aus unserer Reklamationsdatenbank: Hier kam Azure Cognitive Services zum Einsatz, um Stimmungsanalysen und Schlüsselwort-Erkennung durchzuführen, die wir dann in Copilot-Abfragen einbinden. Grundsätzlich haben wir jedoch darauf geachtet, möglichst viel mit den nativen Copilot-Funktionen abzudecken, um den Wartungsaufwand gering zu halten.

Wichtig war von Anfang an eine saubere Architekturtrennung der Umgebungen. Wir richteten eine Test- und eine Produktivumgebung für Copilot ein. Praktisch erfolgte dies über einen separaten Test-Tenant, in dem neue KI-Funktionen oder Konfigurationen vorab mit echten (aber anonymisierten) Beispieldaten ausprobiert wurden. Dieser Test-Tenant spiegelte die wesentlichen Einstellungen des produktiven Tenants wider. So konnten wir Risiken minimieren, bevor wir Änderungen live schalteten. Die Tenant-Einstellungen für Copilot wurden sorgsam konfiguriert – zum Beispiel stellten wir sicher, dass der Datenstandort für alle KI-Dienste auf die europäische Region festgelegt ist, um den Datenschutzanforderungen zu genügen.

Die Schnittstellen zu den Kernsystemen wurden über bereits erwähnte Graph-Konnektoren und APIs realisiert. Für das ERP-System (SAP) richteten wir z.B. eine API-Schnittstelle ein, über die Copilot (bzw. ein Azure-Integrationsdienst im Hintergrund) auf Materialstammdaten und Auftragsinformationen lesend zugreifen kann. Ähnliches galt für das PLM, wo produktrelevante Metadaten bereitgestellt wurden. Wichtig war, dass diese Integrationen entkoppelt und über standardisierte Schnittstellen liefen, um die Wartbarkeit sicherzustellen. Wir vermieden direkte Zugriffe der KI auf die Transaktionssysteme; stattdessen wurden Zwischenpuffer (z.B. in Form von gecachten Abfragen oder einem kleinen Azure SQL, der relevante Ausschnitte spiegelte) genutzt, damit die Kernsysteme nicht unter Last geraten.

Was Skalierung und Verfügbarkeit angeht, profitieren wir von der Cloud-Plattform: Microsoft gewährleistet eine hohe Verfügbarkeit der Copilot-Dienste. Unsere Aufgabe war es hauptsächlich, die Mandantenskalierung zu planen – also wie viele Benutzer wir parallel anbinden können – und das Monitoring im Blick zu behalten. Zum Monitoring setzten wir auf die in M365 vorhandenen Tools: Dashboards für Nutzungsstatistiken von Copilot, über die wir verfolgen konnten, wie häufig welche Funktionen genutzt werden und ob irgendwo Fehler auftreten. Ergänzend implementierten wir eigene Skripte, die z.B. die Latenz von KI-Antworten überwachen, um frühzeitig Performance-Probleme zu erkennen.

Nicht zuletzt achteten wir auf Kostenkontrolle in der Architektur. Zwar fallen für Copilot an sich pro Benutzer Fixkosten an (dazu später mehr), doch etwaige Azure-Dienste im Hintergrund wurden so dimensioniert, dass sie nur bei Bedarf Ressourcen verbrauchen (Stichwort: serverless Functions für Integrationen). Wir entwickelten ein internes Kosten-Dashboard, das monatlich die Ausgaben für KI (Lizenzen, Azure-Verbrauch) dem tatsächlichen Nutzungsgrad gegenüberstellt. Diese Transparenz half dabei, frühzeitig Optimierungspotenziale zu erkennen und sicherzustellen, dass die technische Lösung nicht nur leistungsfähig, sondern auch wirtschaftlich bleibt.

Lizenzierung & Kostenmodell

Ausgangsbasis und Bedarfsermittlung

Die Harry Hase AG verfügte bereits über Microsoft 365 E3 Lizenzen für den Großteil der 2.000 Wissensarbeiter (einige Key User hatten E5 für erweiterte Sicherheitsfunktionen). Damit waren die Grundvoraussetzungen für den Einsatz von Copilot erfüllt, da ein geeigneter Basisplan vorhanden war. Für die KI-Einführung selbst mussten nun zusätzliche Add-on-Lizenzen für Microsoft 365 Copilot beschafft werden. Wir ermittelten den Bedarf je Projektphase: Zunächst für die Pilotierung mit einer kleinen Nutzergruppe, später für den gestaffelten Rollout in Wellen.

Lizenzplan: Pilot und Rollout-Wellen

In der Pilotphase konnten wir über Microsofts Early-Access-Programm eine begrenzte Anzahl Copilot-Lizenzen kostenfrei nutzen. Dies ermöglichte uns, erste Erfahrungen zu sammeln, ohne direkt Budget zu binden. Für den produktiven Rollout galt es dann, ein lizenztechnisch tragfähiges Modell zu finden. Wir beschlossen, die Einführung in zwei größere Wellen vorzunehmen:

1. Welle 1: Ca. 500 ausgewählte Mitarbeiter aus den wichtigsten Fachbereichen (darunter die bereits im Pilot beteiligten Key User) erhielten Copilot-Lizenzen unmittelbar nach Abschluss des Piloten. Diese Gruppe fungierte als Multiplikator und stellte sicher, dass in allen relevanten Bereichen erste Kompetenz aufgebaut war.
2. Welle 2: In einer zweiten Welle wurde die verbleibende breite Masse der Wissensarbeiter (ca. 1.500 weitere Mitarbeiter) ausgestattet, sobald Prozesse und Schulungen aus Welle 1 etabliert waren.

Dieses gestufte Vorgehen erlaubte es, Kosten und Nutzen schrittweise zu validieren. Ein Mischmodell wurde ebenfalls diskutiert: Hätte sich gezeigt, dass bestimmte Nutzergruppen kaum vom KI-Einsatz profitieren, wären diese eventuell von der flächendeckenden Lizenzierung ausgenommen worden. Tatsächlich war der Nutzwert aber in nahezu allen Bereichen hoch, sodass wir keine größeren Gruppen ausschließen mussten.

Die nachfolgende Tabelle gibt einen Überblick über das Lizenzierungskonzept:

Rolle/Gruppe	Anzahl Nutzer	Lizenztyp	Kosten/Monat pro Nutzer	Zuweisungsprozess
Pilotanwender (bereichsübergreifend)	50	M365 Copilot Testlizenz	0 € (Hersteller-Early-Access)	Auswahl durch Projektteam (Kick-off Pilot)
Wissensarbeiter Welle 1 (Key User)	500	M365 Copilot Add-on (produktiv)	ca. 30 €	Nach Pilot, an geschulte Key User
Wissensarbeiter Welle 2 (Rollout gesamt)	1.500	M365 Copilot Add-on	ca. 30 €	Stufenweise Zuweisung nach Schulung
Produktionsmitarbeiter (kein Bürozugang)	2.000	keine Lizenz	0 €	Kein Bedarf (außerhalb Anwendungsbereich)

Der grobe finanzielle Rahmen für die Lizenzen war damit abgesteckt: Vollständig ausgerollt entstehen jährliche Kosten in der Größenordnung von 720.000 € nur für die Copilot-Addons (2.000 Nutzer * 30 € * 12 Monate). Dieses Budget musste vom Vorstand freigegeben werden. Wir argumentierten mit einem detaillierten Kosten-Nutzen-Ausblick: Den Lizenzkosten wurden die erwarteten Produktivitätsgewinne gegenübergestellt, was ein amortisierbares Investment in unter 1,5 Jahren ergeben sollte.

Kostenabschätzung, TCO und Vertragsaspekte

Neben den reinen Lizenzkosten berücksichtigten wir im Business Case auch Implementierungsaufwände (z.B. Integrationsentwicklung, Schulungen) als einmalige Kosten sowie mögliche laufende Betriebskosten (Azure-Verbräuche für zusätzliche Dienste). Daraus wurde die Total Cost of Ownership (TCO) für einen 3-Jahres-Zeitraum berechnet. Diese Berechnung half insbesondere dem Controlling und dem Betriebsrat, das Vorhaben wirtschaftlich einzuordnen.

Bei den Vertragsmodalitäten konnten wir durch den gestaffelten Zukauf der Lizenzen eine gewisse Flexibilität erreichen. Dank Microsoft Enterprise Agreement war es möglich, die Copilot-Lizenzen zunächst für eine Teilmenge der Nutzer zu buchen und später aufzustocken, ohne für ungenutzte Lizenzen zahlen zu müssen. Allerdings haben wir uns zu einer Mindestlaufzeit von 12 Monaten pro Lizenz bekannt, um einen Volumenrabatt zu erhalten. Diese Mischung aus Flexibilität und Commitment stellte sicher, dass das Unternehmen nicht überzahlt, aber dennoch von günstigeren Konditionen profitieren kann.

Lizenz-Governance: Zuweisung und Überprüfung

Um die Lizenzkosten langfristig im Griff zu behalten, etablierten wir einen Prozess zur Lizenz-Governance. Die Zuweisung einer Copilot-Lizenz erfolgt nach klaren Kriterien: Der Mitarbeiter muss zur Zielgruppe gehören, die erforderliche Schulung absolviert haben und den Nutzungsbedingungen (insbesondere zum Datenschutz) zustimmen. Lizenzen werden zentral durch das IT-Service-Team vergeben und dokumentiert.

Zudem haben wir ein Recertification-Verfahren eingeführt: Alle 6 Monate wird geprüft, welche Nutzer ihre Copilot-Lizenz tatsächlich einsetzen. Mitarbeiter, die das Tool kaum nutzen oder deren Aufgabenprofil sich geändert hat, werden identifiziert. In Absprache mit den Fachvorgesetzten kann deren Lizenz dann neu verteilt oder vorübergehend eingezogen werden, um Kosten zu sparen. Ebenso ist für austretende Mitarbeiter ein Offboarding-Prozess verankert, der neben der Sperrung des Accounts auch die Freisetzung der Lizenz umfasst. Dieses Vorgehen stellt sicher, dass die kostspieligen KI-Lizenzen stets dort zum Einsatz kommen, wo sie den größten Mehrwert bringen, und dass keine Ressourcen verschwendet werden.

Projektorganisation & Vorgehensmodell

Projektorganisation und Gremien

Das Projekt wurde bewusst interdisziplinär aufgesetzt, um alle relevanten Stakeholder einzubinden. Als externer Projektleiter habe ich die operative Steuerung übernommen, während ein Lenkungsausschuss (Steering Committee) die strategischen Entscheidungen fällte. Im Steering Committee saßen der CIO als Sponsor, Vertreter der IT-Leitung, zwei Fachbereichsleiter (für Vertrieb und für Produktion) sowie der CFO für die Budgetkontrolle. Dieses Gremium traf sich monatlich, um den Fortschritt zu bewerten, Richtungsentscheidungen zu treffen und etwaige Zielkonflikte zwischen Bereichen aufzulösen.

Für die inhaltliche Ausarbeitung der Lösung haben wir einen Product Owner KI benannt – eine erfahrene interne Führungskraft aus dem Bereich Business Development, die die fachlichen Anforderungen kanalisiert und Prioritäten aus Sicht des Geschäfts setzt. Auf technischer Seite gab es ein Architekturboard, bestehend aus Enterprise-Architekten der IT und mir als Berater, das über die technischen Weichenstellungen entschied (z.B. Integration externer Systeme, Azure-Komponenten, Sicherheitsarchitektur). Parallel dazu wurde ein Security & Compliance Board eingerichtet, in dem der Informationssicherheitsbeauftragte, der Datenschutzbeauftragte, ein Betriebsratsvertreter und Vertreter aus IT-Security gemeinsam alle Maßnahmen auf Vereinbarkeit mit Vorschriften und Policies prüften. Dieses Board wurde bei jedem Meilenstein konsultiert.

Die Projektgruppe selbst setzte sich aus einem Kernteam von etwa 8 Personen zusammen: Neben mir als Projektleiter gab es je einen Ansprechpartner aus den Fachbereichen Einkauf, Qualität und Vertrieb (sogenannte „Power User“), einen IT-Projektkoordinator, einen Change-Manager für Kommunikation & Schulung sowie zwei Entwickler/Administratoren für die technischen Implementierungen. Dieses Kernteam arbeitete eng und agil zusammen, traf sich mindestens wöchentlich zur Abstimmung und bildete den Motor des Projekts.

Vorgehensmodell und Meilensteine

Wir wählten ein iteratives Vorgehensmodell in Anlehnung an agile Prinzipien. Anstatt das gesamte KI-Programm in einem Big-Bang auszurollen, definierten wir klare Phasen mit Übergabepunkten:

1. Konzept & Strategie (Vision) – In den ersten 2 Projektmonaten wurde die Vision, Zielbilder und grobe Architektur erstellt (Ergebnis: Freigabe durch Steering Committee).
2. Use-Case-Definition & Architekturentwurf – Parallel zur Konzeptphase liefen die Workshops zur Use-Case-Findung. Daraus entstand eine priorisierte Backlog-Liste. Gleichzeitig wurde die Zielarchitektur skizziert. Meilenstein: Abnahme der Top-Use-Cases und Architektur durch das Architekturboard.
3. Pilotimplementierung (MVP) – Über ca. 4 Monate wurde ein Minimalprodukt für die obersten Use Cases umgesetzt: Copilot wurde für die Pilotnutzer aktiviert, Daten integriert, erste Schulungen durchgeführt. Am Ende dieser Phase erfolgte ein Pilot-Review mit den Key Stakeholdern, in dem Nutzen und Funktionalität evaluiert wurden.
4. Rollout-Vorbereitung – Auf Basis der Pilot-Erkenntnisse wurden erforderliche Anpassungen vorgenommen (z.B. Datenqualität nachgebessert, Policies justiert). Schulungskonzepte für die breite Masse wurden ausgearbeitet. Meilenstein: „Go“ für den unternehmensweiten Rollout durch das Steering Committee, nachdem die Ziele (z.B. Akzeptanz > 80% im Pilot, keine kritischen Compliance-Einwände) erreicht wurden.
5. Rollout Welle 1 & 2 – Die gestaffelten Rollouts wurden durchgeführt, jeweils mit einem Quality Gate nach jeder Welle, um Feedback auszuwerten und ggf. nachzusteuern, bevor die nächste Gruppe startete.

Wichtige Artefakte begleiteten dieses Vorgehen: Wir führten ein detailliertes Entscheidungsprotokoll, in dem alle Beschlüsse des Steering Committees und Architekturboards festgehalten wurden (inkl. Begründung und Verantwortlichem). Technische Schlüsselentscheidungen dokumentierten wir zusätzlich in Architecture Decision Records (ADR), damit später nachvollziehbar bleibt, warum wir z.B. eine bestimmte Integrationsstrategie gewählt haben. Für den späteren Betrieb erstellten wir Runbooks (z.B. für die Wiederherstellung von KI-Services oder das Onboarding neuer Nutzer) und Playbooks für den Support (Fehlerbilder und Lösungswege bei typischen Anwenderproblemen mit Copilot). Diese Dokumente stellten sicher, dass das Wissen aus dem Projekt konserviert und an die Betriebsmannschaft übergeben werden konnte.

Pilotphase und validierte Ergebnisse

Pilotgruppen und Anwendungsfälle

Die Pilotphase starteten wir mit insgesamt 50 Nutzern aus ausgewählten Bereichen. Dazu zählten insbesondere Einkauf, Qualität und Vertrieb, da diese Bereiche in der Use-Case-Priorität weit vorn lagen. Im Einkauf testeten wir z.B. den KI-Einsatz bei Lieferantenrecherchen und Übersetzungen von technischen Anfragen. In der Qualität lag der Fokus auf der teilautomatisierten Erstellung von Prüfberichten und der schnellen Zusammenfassung von Reklamationsfällen. Der Vertrieb pilotierte den Angebotsassistenten für Angebotstexte sowie die automatische Zusammenfassung von Meeting-Notizen aus Verkaufsgesprächen.

Wichtig war uns, die Pilotgruppe möglichst divers aufzustellen: Sowohl erfahrene Mitarbeiter als auch jüngere Kollegen, verschieden IT-Affinitätslevel, und auch ein Vertreter des Betriebsrats und der Datenschutzabteilung waren dabei. Letztere stellten sicher, dass bereits im Pilot etwaige Datenschutzbedenken oder Fehlentwicklungen erkannt würden. Die Pilotnutzer wurden vorab in einer Kick-off-Schulung auf die KI eingeschworen: Sie erhielten Guidelines zur Nutzung und wir formulierten klar die Erwartung, dass sie aktiv Rückmeldung geben sollten zu Nutzen, Problemen und Wünschen.

Ergebnisse und Nutzenbelege

Der Pilotlauf lief über 3 Monate. Die Ergebnisse waren insgesamt äußerst positiv und lieferten den Proof of Value, den wir benötigten. Einige Highlights:

• Die Bearbeitungszeit für ein Angebotsdokument im Vertrieb sank im Schnitt von ~4 Stunden auf 2,5 Stunden, da Copilot den ersten Entwurf übernahm.
• Im Qualitätswesen konnten Routineberichte etwa 30% schneller erstellt werden, und die Einheitlichkeit der Dokumentation stieg (weniger manuelle Fehler, da Vorlagen konsequent genutzt wurden).
• Eine Umfrage unter den Pilotanwendern ergab eine Zufriedenheitsrate von 90%. Der Net-Promoter-Score (NPS) für die KI-Unterstützung lag bei +45, was für ein neues Tool einen sehr hohen Wert darstellt.
• Interessant war auch, dass das Volumen bestimmter Support-Anfragen leicht zurückging: Einige Benutzer fanden Antworten auf Anwendungsfragen (z.B. Excel-Formeln, Formatierungen) direkt über Copilot, statt ein Ticket beim IT-Support zu öffnen.

Natürlich gab es auch Herausforderungen. Zu Beginn fiel einigen Pilotteilnehmern die Eingewöhnung schwer – manche versuchten, mit vagen Befehlen zu arbeiten und erhielten dann wenig hilfreiche Ergebnisse. Hier zahlte es sich aus, dass wir Prompting-Tipps bereitgestellt hatten. Mit etwas Übung wurden die Nutzer immer zielsicherer darin, der KI die richtigen Anweisungen zu geben.

Sicherheits- oder Datenschutzverstöße traten im Pilot nicht auf. Die Einrichtung der Rechte hatte gegriffen: Kein Pilotnutzer konnte über Copilot auf Informationen zugreifen, für die er keine Berechtigung hatte. Dieses Ergebnis beruhigte insbesondere den Betriebsrat und den Datenschutzbeauftragten.

Learnings und Anpassungen vor dem Rollout

Aus der Pilotphase zogen wir wertvolle Lessons Learned. So stellten wir fest, dass die Datenqualität in einigen SharePoint-Bereichen direkteren Einfluss auf die KI-Ergebnisse hatte als angenommen. Beispiel: In einem Fall lieferte Copilot veraltete Informationen, weil ein veraltetes Dokument noch als aktuell markiert war. Daraus lernten wir, vor dem Rollout nochmals gezielt aufzuräumen und Altdokumente klar als Archiv zu markieren.

Ein weiteres Learning betraf den Change-Bedarf: Trotz grundsätzlich hoher Akzeptanz merkte man, dass manche Nutzer unsicher im Umgang mit der KI waren oder Bedenken hatten, etwas „falsch zu machen“. Hier planten wir für den Rollout zusätzliche Unterstützung ein, etwa ein KI-Anwenderforum und offene Sprechstunden, wo Fragen gestellt werden konnten.

Die Pilotphase zeigte auch, welche Use Cases besonders einschlugen und wo Nachsteuerung nötig war: Der Angebotsassistent und die Meeting-Zusammenfassungen wurden spontan in weiteren Teams nachgefragt – ein gutes Zeichen für virale Verbreitung. Hingegen war die Nutzung des Code-Assistenz-Features geringer als erwartet, was darauf hindeutete, dass wir hier ggf. noch mehr Schulungsaufwand in der Entwickler-Community betreiben müssen.

Vor dem breiten Rollout justierten wir also noch einmal unser Vorgehen: Datenbereinigung wurde abgeschlossen, die Schulungsunterlagen um FAQs aus dem Pilot ergänzt, und die Governance-Boards gaben grünes Licht, da keine unerwarteten Risiken aufgetaucht waren. Damit waren wir bereit, die KI-Unterstützung in die Breite zu bringen.

Change Management & Kommunikation

Kommunikationsstrategie

Ein erfolgreicher Wandel hin zu KI-gestütztem Arbeiten erfordert intensive Kommunikation. Wir entwickelten eine Kommunikationsstrategie, die alle Zielgruppen im Unternehmen adressierte. Zum Projektstart gab es eine Ankündigung des Vorstands im Intranet, in der die Vision „KI als Co-Pilot“ erläutert wurde und warum das Unternehmen diesen Schritt geht (Stichworte: Wettbewerbsfähigkeit, Entlastung der Mitarbeiter, neue Chancen).

Im weiteren Verlauf setzten wir auf zielgruppengerechte Botschaften: Für die Mitarbeiter in den Fachbereichen lag der Fokus auf konkreten Vorteilen im Tagesgeschäft („Weniger Routine, mehr Zeit für anspruchsvolle Aufgaben“). Für Führungskräfte hoben wir hervor, wie KI die Teamleistung steigern kann und dass es nun darauf ankommt, als Vorbild die Nutzung zu fördern. Gegenüber dem Betriebsrat und Datenschutz stellten wir Transparenz und Kontrolle heraus („KI-Einsatz immer nachvollziehbar und freiwillig“). Und in Richtung IT/Support betonten wir, dass die Einführung schrittweise und mit ausreichender Qualifizierung passiert, um Überlastung zu vermeiden.

Als Kommunikationskanäle dienten ein projektbegleitender Blog im Intranet mit regelmäßigen Updates, interne Newsletter sowie Live-Demonstrationen. Während der Pilotphase veröffentlichten wir z.B. alle zwei Wochen Praxisberichte eines Pilotnutzers („Meine Erfahrung mit Copilot in Woche 2“), um die Kollegen neugierig zu machen und echte Anwendungsfälle greifbar zu schilderen. Diese Offenheit half, das Thema im Unternehmen präsent zu halten und Gerüchten oder Ängsten vorzubeugen.

Leitplanken, Q&A und FAQ

Parallel zur positiven Botschaft brauchten alle Mitarbeiter klare Leitplanken für den KI-Einsatz. Wir erstellten einen leicht verständlichen Leitfaden zur KI-Nutzung, der Do’s & Don’ts enthielt. Darin stand zum Beispiel: „Verwenden Sie Copilot bevorzugt für erste Entwürfe, aber prüfen Sie die Ergebnisse stets kritisch.“ Oder: „Geben Sie keine sensiblen personenbezogenen Daten als Prompt ein.“ Auch der Hinweis, dass KI-Antworten Fehler enthalten können und nicht als offizielle Aussage des Unternehmens gelten, war wichtig. Dieser Leitfaden wurde mit dem Betriebsrat abgestimmt und an alle verteilt.

Ergänzend bauten wir eine interne Wissensbasis (FAQ) auf. Darin beantworteten wir die häufigsten Fragen: „Wird KI meinen Arbeitsplatz überflüssig machen?“ (Antwort: Nein, sie soll dich von Routine entlasten, nicht ersetzen), „Wer haftet, wenn die KI etwas Falsches schreibt?“ (Antwort: Der Mitarbeiter, der das Ergebnis nutzt, trägt weiterhin die Verantwortung – deshalb Prüfpflicht). Ebenso erklärten wir, welche Datenquellen die KI nutzt, wie Datenschutz gewahrt bleibt und wohin man sich bei Unsicherheiten wenden kann. Diese FAQ wurde im Intranet veröffentlicht und laufend aktualisiert.

Umgang mit Skepsis und ethischen Fragen

In jeder größeren Veränderung gibt es Skepsis. Wir begegneten Vorbehalten offen: In Townhall-Meetings konnten Mitarbeiter ihre Sorgen ausdrücken. Typische Themen waren die Angst vor Stellenabbau, Zweifel an der Vertraulichkeit oder ethische Bedenken („Trifft die KI vielleicht voreingenommene Entscheidungen?“). Das Projektteam beantwortete diese Fragen ehrlich und belegte Aussagen mit Pilot-Ergebnissen (z.B. dass die KI kein einziges vertrauliches Dokument unbefugt preisgab). Wichtig war auch, klarzustellen, dass die Ethik-Leitlinien des Unternehmens unverändert gelten: Jede KI-Nutzung muss sich an unseren Code of Conduct halten.

Wir richteten Feedback-Kanäle ein, damit jeder Mitarbeiter laufend Fragen oder Bedenken adressieren konnte – etwa über einen dedizierten Teams-Kanal „Frag den KI-Coach“ oder anonyme Meldemöglichkeiten für kritische Beobachtungen. Durch dieses proaktive Change Management schafften wir eine Atmosphäre, in der KI nicht als Bedrohung, sondern als gemeinsamer Fortschritt gesehen wurde. Die offene Kommunikation und klaren Leitplanken halfen, das Vertrauen der Belegschaft zu gewinnen und eine positive Grundhaltung gegenüber den neuen Tools zu etablieren.

Schulung & Enablement

Schulungskonzept nach Rollen

Die Einführung von KI-Tools verlangte eine umfassende Qualifizierung der Belegschaft. Wir entwickelten ein rollenspezifisches Schulungskonzept:

• Fachanwender (alle Wissensarbeiter): Sie erhielten eine Grundlagenschulung „Copilot in der Praxis“. Darin wurden die Funktionen in Word, Excel, Outlook, Teams etc. gezeigt und übliche Anwendungsfälle live demonstriert. Wichtig war auch ein Modul über die Unternehmensrichtlinien (was erlaubt ist und was nicht).
• Power User & Multiplikatoren: Aus jedem Fachbereich wurden einige besonders technikaffine Mitarbeiter tiefergehend ausgebildet. Diese „KI-Champions“ lernten neben den Grundlagen auch erweiterte Tricks (z.B. komplexere Prompt-Techniken, Anbindung externer Datenquellen) und wurden darauf vorbereitet, ihren Kollegen als erste Anlaufstelle zu dienen.
• Führungskräfte: Für Team- und Abteilungsleiter gab es eigenständige Workshops. Dort vermittelten wir nicht nur die KI-Funktionen, sondern diskutierten auch Führungsaspekte: Wie fördere ich die Nutzung im Team? Wie gehe ich mit Fehlern von KI um, wenn meine Mitarbeiter damit arbeiten? Ziel war, die Führungskräfte als Unterstützer des Wandels zu gewinnen.
• Support- und IT-Teams: Unsere IT-Helpdesk-Mitarbeiter und Administratoren bekamen spezialisierte Trainings, um Second-Level-Support für Copilot leisten zu können. Sie lernten die typischen Fehlermuster (z.B. Berechtigungsprobleme, Antwortzeit-Verzögerungen) und wie man diese analysiert. Ebenso schulten wir sie in der Kommunikation mit Anwendern, die KI-Fragen haben, damit der Support kompetent und einheitlich antworten kann.

Didaktische Umsetzung und Lernangebote

Bei der Umsetzung der Schulungen setzten wir auf abwechslungsreiche Lernformate. Statt langatmiger Präsentationen gab es kurze, modulare Einheiten von 30-60 Minuten. Beispielsweise eine kompakte Live-Demo in Teams, wie man Copilot bittet, ein Meetingprotokoll zu erstellen. Darauf folgte eine Übungsphase, in der die Teilnehmer selbst im geschützten Test-Tenant Aufgaben lösen konnten (z.B. einen Beispieltext mit KI formulieren). Diese Hands-on-Übungen waren wichtig, um Berührungsängste abzubauen.

Zudem stellten wir E-Learning-Inhalte bereit: Ein self-service Lernpfad im Learning-Management-System führte Schritt für Schritt durch die wichtigsten Copilot-Features. Mitarbeiter konnten im eigenen Tempo Lernvideos anschauen und Quizfragen beantworten. Die Power User bildeten wir zusätzlich in präsenznahen Workshops aus, in denen viel Raum für Praxisfragen und den Austausch untereinander war.

Ergänzt wurde das formale Training durch eine Community of Practice: Wir etablierten ein internes „KI-Forum“ (via Teams und monatlichen Treffen), in dem Anwender Tipps teilen, Anwendungsfälle diskutieren und direkt vom Projektteam neueste Updates erfahren konnten. So entstand ein kontinuierlicher Lernprozess über die offiziellen Schulungen hinaus.

Erfolgsmessung des Enablement

Wir legten von Anfang an Kriterien fest, um den Erfolg der Schulungen messbar zu machen. Dazu gehörten quantitativer Kennzahlen wie die Teilnahmequote (wir zielten auf >95% Teilnahme der anvisierten Nutzergruppen an den Pflichtschulungen) und Feedback-Bewertungen der Schulungen (durchschnittlich >4 von 5 Punkten in der Teilnehmerzufriedenheit).

Wichtiger noch war der Praxis-Transfer: Wir beobachteten die Nutzungsmetriken von Copilot nach den Trainings. Zum Beispiel werteten wir aus, wie viele Mitarbeiter innerhalb der ersten zwei Wochen nach Rollout aktiv KI-Funktionen nutzten. Diese „Activation Rate“ war ein Indikator dafür, ob die Schulung ausreichend motiviert und befähigt hat. Auch qualitative Rückmeldungen sammelten wir: die Trainer (und Power User) führten nach einigen Wochen Feedbackrunden in ihren Teams durch, um zu hören, wo es noch Unsicherheiten gibt oder wo evtl. Nachschulungsbedarf besteht.

Das Ergebnis war ermutigend: Bereits ein Monat nach Rollout hatten über 75% der geschulten Mitarbeiter Copilot aktiv in ihrem Arbeitsalltag ausprobiert. Die Support-Anfragen zur Bedienung blieben gering, was auf die gute Vorbereitung hinwies. Diese Metriken und Beobachtungen halfen uns, das Enablement bei Bedarf feinzujustieren und Erfolge intern sichtbar zu machen.

Rechtliche Rahmenbedingungen

Datenschutz und Auftragsverarbeitung (DSGVO/BDSG)

Die Nutzung von KI im Unternehmen musste streng im Einklang mit Datenschutzgesetzen wie der DSGVO und dem BDSG stehen. Wir haben daher zunächst die Rechtsgrundlage für die Verarbeitung personenbezogener Daten durch Copilot geprüft. Unsere Bewertung: Die Verarbeitung erfolgt im Rahmen der Erfüllung arbeitsvertraglicher Pflichten bzw. unseres berechtigten Interesses, die Arbeitsprozesse effizienter zu gestalten. Eine Einwilligung der Mitarbeiter war somit nicht zwingend erforderlich, wurde aber transparent kommuniziert.

Im Verzeichnis der Verarbeitungstätigkeiten wurde ein neuer Eintrag für die Nutzung von Microsoft 365 Copilot angelegt. Darin dokumentierten wir, welche Arten von personenbezogenen Daten in Prompts oder verarbeiteten Dokumenten vorkommen können (z.B. Mitarbeiterkontaktdaten, Kundendaten in Texten) und zu welchem Zweck die Verarbeitung erfolgt. Gleichzeitig überprüften wir die bestehenden Auftragsverarbeitungsverträge mit Microsoft. Glücklicherweise deckte unser bestehendes Enterprise Agreement inkl. der Online Service Terms die neuen KI-Dienste bereits mit ab, da Microsoft vertraglich zusichert, als Auftragsverarbeiter zu agieren und die EU-Standardvertragsklauseln einzuhalten.

Zusätzlich achteten wir darauf, dass die technisch-organisatorischen Maßnahmen (TOMs) den erweiterten Einsatz abdecken. Beispielsweise wurde die Verschlüsselung von Daten in Microsoft 365 end-to-end sichergestellt und der Zugriff auf die KI-Dienste protokolliert (siehe Audit-Konzept). Durch diese Maßnahmen konnten wir intern wie extern (gegenüber Kunden oder Prüfern) darlegen, dass das KI-System innerhalb unseres bestehenden Datenschutz-Compliance-Rahmens betrieben wird.

Schutz von Geschäftsgeheimnissen und Exportkontrolle

Als Automobilzulieferer hält die Harry Hase AG viele Betriebs- und Geschäftsgeheimnisse (etwa technische Spezifikationen, Prototypenpläne, Preiskalkulationen). Ein zentrales Anliegen war, dass diese Geheimnisse durch die KI-Nutzung nicht gefährdet werden. Durch die implementierten Sicherheitsmaßnahmen (Zugriffskontrolle, DLP etc.) stellten wir sicher, dass keine vertraulichen Informationen unkontrolliert nach außen gelangen. Zudem schulten wir die Mitarbeiter dahingehend, sensibel mit solchen Informationen umzugehen, auch bei KI-Anfragen.

Thema Exportkontrolle: Wir prüften, ob der Einsatz von Cloud-KI-Diensten potentiell dem Exportkontrollrecht unterliegen könnte. Zwar werden hier keine physischen Güter bewegt, aber technische Informationen (z.B. zu bestimmten Produkten) können exportkontrollrechtlich relevant sein. Unsere Juristen kamen zum Schluss, dass bei bestimmungsgemäßer Nutzung kein Export in Drittstaaten erfolgt (Datenverarbeitung findet in EU-Rechenzentren statt), und dass sensible technische Daten gar nicht erst in KI-Anfragen eingegeben werden dürfen. Entsprechende Hinweise wurden in die Leitlinien aufgenommen. Somit sahen wir keine zusätzlichen Exportkontrollauflagen verletzt.

Branchen- und Kundenanforderungen

In der Automobilbranche gelten hohe Anforderungen an Informationssicherheit und Compliance. Die Harry Hase AG ist beispielsweise TISAX-zertifiziert, was auch den Umgang mit Informationen regelt. Wir stellten sicher, dass die KI-Einführung diese Standards nicht kompromittiert: Alle Maßnahmen wurden so gestaltet, dass sie TISAX-Prüfanforderungen standhalten (z.B. dokumentierte Risikoanalyse, definierte Maßnahmen, Schulungen nachweisbar durchgeführt).

Auch einige Kunden haben Vorgaben, was den Einsatz von KI betrifft. Beispielsweise verlangen manche OEMs, dass vertrauliche Entwicklungsdaten nicht in fremde KI-Systeme gelangen. Hier konnten wir transparent darlegen, dass unsere Lösung nur auf unsere interne M365-Umgebung zugreift und Microsoft als Dienstleister vertraglich gebunden ist. In Audits präsentierten wir unser KI-Konzept und stießen auf positives Interesse, da wir proaktiv mit dem Thema umgehen.

Betriebsvereinbarung KI und interne Richtlinien

Abschließend wurde die bereits erwähnte Betriebsvereinbarung KI formell abgeschlossen. Sie regelt verbindlich die Zweckbindung („KI dürfen nur zur Unterstützung der Arbeitsaufgaben, nicht zur Leistungskontrolle eingesetzt werden“), die Freiwilligkeit und Mitbestimmung (inkl. der Möglichkeit für den Betriebsrat, jederzeit Einblick in die Nutzung zu nehmen), sowie Evaluationsmechanismen. So ist z.B. vereinbart, dass 12 Monate nach Rollout eine gemeinsame Evaluierung zwischen Arbeitgeber und Betriebsrat stattfindet, um die Erfahrungen zu bewerten und eventuelle Anpassungen der Vereinbarung vorzunehmen.

Ergänzend zur Betriebsvereinbarung haben wir interne Richtlinien (Policies) aktualisiert. Die IT-Benutzerrichtlinie enthält nun einen Abschnitt zur KI-Nutzung, der jeden Mitarbeiter an seine Pflicht erinnert, verantwortungsvoll mit den Werkzeugen und Daten umzugehen. Damit ist sichergestellt, dass neben dem formalen rechtlichen Rahmen auch im Tagesgeschäft klare Regeln für den KI-Einsatz gelten.

Rollout in Wellen

Rollout-Plan und Wellenkriterien

Der produktive Rollout der KI-Unterstützung erfolgte bewusst in Wellen, um aus den Erfahrungen der ersten Gruppe zu lernen und bei Bedarf nachsteuern zu können. Für die Bildung der Wellen legten wir Kriterien fest:

• Geschäftskritikalität: Welle 1 sollte Bereiche umfassen, in denen schnelle Erfolge möglich und sichtbar sind (z.B. Vertrieb, der direkt beim Kundenimpact hat).
• Pilot-Abdeckung: Wir wählten für Welle 1 gezielt Abteilungen, die bereits Pilotanwender stellten, damit dort schon internes Know-how vorhanden war (z.B. Einkauf und Qualität).
• Bereitschaft & Datenlage: Bereiche, die organisatorisch bereit waren (offene Einstellung der Führungskräfte, ausreichende Schulungskapazität) und deren Daten bereits gut integriert waren, kamen zuerst dran. Abteilungen, wo noch Vorarbeiten nötig waren (z.B. Datenbereinigung), wurden in Welle 2 verschoben.

Auf Basis dieser Kriterien entstand ein Rollout-Fahrplan:

Welle	Bereiche (Auszug)	Anzahl Nutzer	Voraussetzungen	Termin	Hypercare-Dauer
1	Vertrieb, Einkauf, Qualität, IT (Key User)	ca. 500	Pilot abgeschlossen; Key User pro Bereich geschult; Daten integriert	Q1 2024	4 Wochen
2	Alle restlichen Bürobereiche (Entwicklung, Logistik, Finance, etc.)	ca. 1500	Lessons Learned aus Welle 1 umgesetzt; vollst. Schulungskampagne abgeschlossen	Q2 2024	4 Wochen

Die Wellen lagen etwa 3 Monate auseinander. So blieb genug Zeit, um aus Welle 1 zu lernen und für Welle 2 ggf. Unterlagen oder Einstellungen anzupassen.

Hypercare und Support-Skalierung

Für jede Welle richteten wir eine Hypercare-Phase ein: In den ersten Wochen nach dem Rollout waren das Projektteam und extra Support-Kapazitäten in erhöhter Alarmbereitschaft. Wir schalteten z.B. eine Hotline und einen speziellen Chat-Kanal, über den Nutzer direkt Fragen stellen konnten. Während der Hypercare von Welle 1 dokumentierten wir alle eingehenden Fragen und Probleme akribisch. Diese bildeten die Basis für den Ausbau der FAQ und halfen dem Support-Team, sich auf wiederkehrende Themen einzustellen.

Um den Support für die steigende Nutzerzahl zu skalieren, schulten wir rechtzeitig vor Welle 2 zusätzliche First-Level-Supporter in den Grundlagen von Copilot. Außerdem etablierten wir ein Ticketsystem-Tagging: Anfragen zum Thema KI wurden im Helpdesk-System gekennzeichnet, sodass wir Statistiken zur Auslastung und Problemarten erheben konnten.

Erfolgskontrolle pro Welle

Nach jeder Rollout-Welle zogen wir in einem Review-Meeting Bilanz. Für definierte KPIs (wie Nutzungsrate, Zufriedenheitswerte, produktivitätsbezogene Messgrößen) hatten wir Zielwerte festgelegt. Beispielsweise strebten wir nach Welle 1 an, dass mindestens 50% der Nutzer Copilot regelmäßig (d.h. wöchentlich) nutzen. Ebenfalls sollte die durchschnittliche Bearbeitungszeit bestimmter Dokumente um >20% gesunken sein.

Wir überwachten diese Kennzahlen laufend während der Hypercare. Sollten Abweichungen auftreten (z.B. deutlich geringere Nutzung als erwartet), hatten wir ein „Drehbuch“ parat: Zusätzliche Trainingsmaßnahmen, persönliche Unterstützung für Zurückhaltende oder technische Nachbesserungen wurden dann gezielt eingeleitet.

Nach Welle 1 konnten wir so z.B. feststellen, dass das Nutzungsziel erreicht wurde (rund 60% wöchentliche aktive Nutzer). Lediglich in einem Bereich (Logistik) war die Quote geringer, was wir auf spezifische Anwendungsunsicherheiten zurückführten. Hier boten wir vor dem Start der Welle 2 noch einmal eine Auffrischungsschulung an.

Durch diese engmaschige Erfolgskontrolle stellten wir sicher, dass jede Rollout-Welle die gewünschten Effekte erzielte und dass wir für die folgenden Wellen optimal vorbereitet waren. Das Vertrauen des Managements und des Betriebsrats in den Ansatz wurde durch die sichtbar erreichten Zwischenziele gestärkt.

Betrieb, Monitoring & kontinuierliche Verbesserung

Betriebsmodell und Support

Nach dem erfolgreichen Rollout ging das Projekt in den Regelbetrieb über. Dafür haben wir ein klares Betriebsmodell definiert. Die Verantwortung für den laufenden Betrieb der KI-Services liegt nun bei der IT-Abteilung (Bereich Digital Workplace). Ein interner Service Owner KI wurde benannt, der alle Aktivitäten koordiniert und als Ansprechpartner für die Fachbereiche dient.

Der Support ist in die bestehenden Strukturen integriert: First-Level-Anfragen laufen über den normalen IT-Helpdesk. Die Mitarbeiter dort nutzen unsere erstellten Playbooks, um häufige Fragen sofort zu beantworten. Komplexere Fälle gehen an den Second-Level, bestehend aus dem erfahrenen Kernteam (inkl. der KI-Champions aus den Fachbereichen und IT-Experten). Hier werden Probleme analysiert, Konfigurationen angepasst oder auch mal ein Benutzer individuell gecoacht. Sollte ein Problem die Plattform selbst betreffen (z.B. ein Ausfall von Copilot-Diensten), eskaliert der Second-Level an Microsoft bzw. den Third-Level-Support des Herstellers im Rahmen unseres Support-Vertrags.

Wichtig war auch die Übergabe aller relevanten Informationen aus dem Projekt an die Betriebsorganisation. In mehreren Knowledge-Transfer-Sessions haben wir das IT-Betriebsteam mit den Runbooks vertraut gemacht und gemeinsam Notfallszenarien durchgespielt (z.B. wie zu verfahren ist, wenn die KI unbeabsichtigt nicht verfügbar ist oder falsche Ergebnisse in Serie liefern würde). Damit ist sichergestellt, dass das Unternehmen nun auch ohne externe Unterstützung die KI-Plattform betreiben und weiterentwickeln kann.

Monitoring und Nutzungsanalyse

Ein zentraler Baustein im Betrieb ist das Monitoring. Wir behalten zum einen die technischen Parameter im Auge (Systemauslastung, Antwortzeiten der KI, Fehlerlogs), um Performance-Probleme oder Störungen sofort zu erkennen. Zum anderen führen wir eine kontinuierliche Nutzungsanalyse durch: Über die M365-Reports und unsere eigenen Auswertungen sehen wir, wie oft welche Copilot-Funktionen genutzt werden, welche Bereiche besonders aktiv sind und wo möglicherweise Nachholbedarf besteht.

Diese Daten werden in einem KPI-Dashboard aufbereitet, das monatlich im Team reviewed wird. Typische Kennzahlen sind z.B. die Anzahl aktiver Nutzer pro Woche, die Top 5 genutzten KI-Funktionalitäten, oder die durchschnittliche Antwortdauer der KI. Auch eventuelle sicherheitsrelevante Ereignisse (z.B. blockierte DLP-Versuche) fließen hier ein. So haben wir stets einen aktuellen Überblick, ob die KI-Plattform ordnungsgemäß und im Sinne der Ziele läuft.

Ein weiterer Aspekt der Überwachung ist die Rezertifizierung von Berechtigungen und Lizenzen. Wie geplant überprüft das Team halbjährlich, ob die Copilot-Zugänge noch korrekt zugeteilt sind, und bereinigt diese falls erforderlich (z.B. Entfernen von Lizenzen bei ausgeschiedenen oder inaktiv gewordenen Nutzern). Dies erfolgt in Abstimmung mit den Fachbereichen.

Kontinuierliche Verbesserung

Das KI-Projekt ging nahtlos in einen Prozess der kontinuierlichen Verbesserung über. Wir führen quartalsweise Review-Meetings mit dem ursprünglichen Projekt-Board durch, um neue Erkenntnisse und mögliche Erweiterungen zu besprechen. Aus dem Arbeitsalltag der Nutzer werden stetig neue Use-Case-Ideen gemeldet. Diese sammeln wir in einem zentralen Backlog. Eine Bewertungsrunde (analog zur anfänglichen Priorisierung) entscheidet, welche Ideen aufgegriffen werden.

Bereits kurz nach dem Rollout entstanden z.B. Vorschläge, auch das CRM-System per KI auszuwerten, oder KI-gestützte Auswertungen im Produktionscontrolling zu nutzen. Solche möglichen Erweiterungen prüfen wir iterativ auf Machbarkeit und Nutzen. Kleinere Optimierungen (z.B. neue Prompt-Vorlagen oder das Feintuning von Sicherheitsrichtlinien) setzen wir zeitnah um. Größere Vorhaben fließen in die Roadmap für die nächsten 12 Monate ein, die gemeinsam mit der Geschäftsleitung abgestimmt wird.

Auch das Risikomanagement bleibt aktiv: In regelmäßigen Abständen (vierteljährlich) evaluiert das Security Board, ob neue Risiken entstanden sind oder bestehende Maßnahmen angepasst werden müssen (etwa durch Änderungen in der Gesetzeslage oder neue Erkenntnisse zu KI-Modellen). So bleibt die KI-Nutzung nicht statisch, sondern entwickelt sich kontrolliert mit den Anforderungen und Rahmenbedingungen weiter.

ROI, KPIs und Controlling

Business-Case-Fortschreibung und Nutzenbewertung

Von Beginn an war es für das Controlling wichtig, den Return on Investment (ROI) der KI-Initiative nachhalten zu können. Wir führten daher Vorher/Nachher-Analysen für die wichtigsten Kennzahlen durch. Hierzu zählten zum Beispiel die durchschnittliche Bearbeitungsdauer für Angebote, die Anzahl an iterativen Schleifen bei Dokumenterstellungen oder die Bearbeitungszeit von Supportanfragen.

Die Ergebnisse konnten sich sehen lassen: In den Pilotbereichen sank die Durchlaufzeit für ein Angebot um durchschnittlich 40%, und die Zahl der notwendigen Korrekturschleifen bei Berichtserstellungen ging merklich zurück. Auf Gesamtunternehmensebene hochgerechnet bedeuteten die bisher beobachteten Effizienzgewinne eine Zeitersparnis von rund 15.000 Arbeitsstunden pro Jahr. Selbst konservativ mit dem internen Stundensatz bewertet, entspricht das einem Gegenwert, der die jährlichen Lizenzkosten deutlich übersteigt.

Natürlich berücksichtigt unser ROI-Modell nicht nur die harten Einsparungen. Auch Qualitätsverbesserungen (z.B. weniger Fehler in Dokumenten, konsistentere Kommunikation) und beschleunigte Einarbeitungszeiten für neue Mitarbeiter flossen in die Nutzenbewertung ein. Diese wurden mittels Feedback und Qualitätsmetriken greifbar gemacht.

Das Controlling aktualisiert den Business-Case nun im Quartalsrhythmus mit den Ist-Zahlen. Dabei zeigt sich, dass wir auf einem guten Weg sind: Die initial kalkulierte Amortisationszeit von 1,5 Jahren könnte, wenn der Trend anhält, sogar unterschritten werden.

KPI-Board: Kennzahlenübersicht

Um den Überblick zu behalten, welche Ziele erreicht werden, nutzen wir ein KPI-Board mit Schlüsselkennzahlen. Ein Auszug daraus:

KPI	Zielwert	Ist-Wert (Q2 2024)	Messmethode	Review-Turnus
Automatisierungsquote Routineberichte	30% automatisiert	28%	Auswertung bearbeiteter Berichte (Vorher/Nachher-Vergl.)	monatlich
Durchschn. Angebotsdurchlaufzeit	2 Tage	1,5 Tage	Zeitmessung Angebotserstellung (ERP/CRM-Daten)	quartalsw.
Copilot-Nutzeranteil (aktive Nutzer/WW)	90% der Info-Worker	85%	Nutzungsreport M365	monatlich
Anwender-Zufriedenheit KI (NPS)	+40	+50	Umfrageergebnisse (Stichprobe)	halbjährl.
KI-bezogene Supporttickets pro Monat	<= 20	10	Ticketsystem-Auswertung	monatlich

Diese Zahlen dienen als Steuerungsinstrument. Beispielsweise erkennen wir am KPI Automatisierungsquote Routineberichte, dass wir unser 30%-Ziel fast erreicht haben. Die Angebotsdurchlaufzeit hat sich mit 1,5 Tagen sogar besser entwickelt als erwartet. Der Anteil aktiver Copilot-Nutzer liegt mit 85% noch etwas unter dem Ziel; hier sind weiterhin Fördermaßnahmen wie Schulungen und Kommunikation wichtig. Positiv hervorzuheben ist die hohe Zufriedenheit der Anwender (NPS +50) und die geringe Anzahl an Supporttickets, was für eine gelungene Einführung spricht.

Durch diese engmaschige KPI-Überwachung behält das Management den Nutzen der KI-Lösung stets im Blick. Zudem lassen sich bei Bedarf frühzeitig Gegenmaßnahmen ergreifen, falls ein Indikator hinter den Erwartungen zurückbleibt. Insgesamt liefert das KPI-Board die Evidenz, dass die KI-Einführung nicht nur technisch, sondern auch betriebswirtschaftlich ein Erfolg ist.

Risiken, Anti-Pattern und Lessons Learned

Abschließend möchte ich einige Stolpersteine benennen, die in KI-Projekten typischerweise drohen, und wie wir ihnen begegnet sind:

• Unklare Verantwortung/Steuerung: Ohne klare Ownership verzetteln sich solche Projekte leicht. Unsere Lösung: eine eindeutige Governance mit benannten Verantwortlichen (Sponsor, Projektleiter, Product Owner, Gremien) und regelmäßiger Abstimmung.
• Unzureichende Datenpflege: KI ist nur so gut wie die Datenbasis. Unsere Lösung: Früh eine Datenqualitätsinitiative starten, Data Owner etablieren und Altlasten bereinigen, bevor man KI breit ausrollt.
• Zu großer Scope am Anfang: Wer alles auf einmal will, überfordert Organisation und Technik. Unsere Lösung: strikte Priorisierung auf Quick Wins und Top-Use-Cases, Pilot als MVP nutzen und danach iterativ ausbauen.
• Mangelndes Change Management: Die beste KI nützt nichts, wenn Anwender skeptisch oder überfordert sind. Unsere Lösung: intensive Kommunikation, Schulung und Einbindung des Betriebsrats, um Akzeptanz zu sichern. Führungskräfte als Vorbilder einsetzen.
• Compliance & Security nicht von Beginn an einbezogen: Wenn Datenschutz oder IT-Security spät Bedenken anmelden, drohen Projektstopps. Unsere Lösung: von Tag 1 alle Compliance-Stakeholder eingebunden, gemeinsame Richtlinien erarbeitet und Transparenz geschaffen, um Vertrauen aufzubauen.

Diese Lessons Learned aus unserem Projekt können als Leitfaden für ähnliche Vorhaben dienen. Letztlich hat sich gezeigt: Ein KI-Einführungsprojekt ist nicht nur ein Technologieprojekt, sondern ein Organisationsprojekt. Erfolg stellt sich ein, wenn Menschen, Daten und Technik gleichermaßen berücksichtigt werden und Hand in Hand arbeiten.

Fazit und Ausblick

Rückblickend hat die Harry Hase AG durch dieses Projekt einen großen Schritt in Richtung digitale Zukunft gemacht. Als Projektleiter freue ich mich, dass wir nicht nur eine neue Technologie eingeführt, sondern nachhaltige Veränderungen in der Arbeitsweise verankert haben.

Der Reifegrad in Sachen KI-Nutzung ist nach Projektabschluss deutlich gestiegen: Viele Mitarbeiter nutzen Copilot selbstverständlich in ihrer täglichen Arbeit, und das Unternehmen verfügt über klare Richtlinien und Kompetenzträger für KI. Gleichzeitig wissen wir, dass dies erst der Anfang ist.

Für die nächsten 12-24 Monate haben wir eine Roadmap definiert, die weitere Use Cases und Verbesserungen umfasst. Dazu gehören etwa die Integration von KI in weitere Systeme (z.B. CRM), die Einführung von speziellen KI-Modellen für die Dokumentenanalyse, und die Vertiefung der Mitarbeiterschulungen in fortgeschrittenen KI-Themen. Auch die Entwicklungen im Bereich regulatorischer Anforderungen (Stichwort EU AI Act) werden wir im Auge behalten und unsere Governance bei Bedarf anpassen.

Insgesamt kann die Harry Hase AG heute auf eine erfolgreiche KI-Einführung blicken, die als Best Practice für digitale Transformation im Mittelstand dienen kann. Die Kombination aus technologischer Innovation, solidem Projektmanagement und frühzeitiger Einbindung der Menschen hat den Unterschied gemacht. Diese Erfahrung hat gezeigt: Mit dem richtigen Konzept wird KI vom Buzzword zum handfesten Mehrwert für das Unternehmen.

 

Weitere Beiträge zum Thema KI