Die No-Gos im Change-Projekt

Neue ERP- oder CRM-Systeme, Cloud-Migrationen, automatisierte Abläufe und KI-gestützte Prozesse verändern nicht nur die IT. Sie greifen in Aufgaben, Verantwortlichkeiten, Entscheidungen und oft auch in die Zusammenarbeit mit Kunden und Partnern ein. Genau deshalb ist ein Change-Projekt mehr als die Einführung einer Technologie.

Viele Vorhaben scheitern nicht an einzelnen Funktionen, sondern an vermeidbaren Managementfehlern. Wer Ziele, Prozesse, Daten, Kommunikation und Governance gemeinsam betrachtet, schafft die Grundlage dafür, dass aus einer technischen Einführung eine tragfähige Veränderung wird.

No-Go 1: Mit einer Lösung starten, bevor das Problem geklärt ist

Ein neues System ist noch keine Strategie. Trotzdem beginnen Change-Projekte häufig mit einer Produktauswahl oder einem bereits festgelegten Einführungstermin. Unklar bleibt, welches konkrete Problem gelöst werden soll, welche Abläufe sich ändern müssen und woran das Unternehmen einen sinnvollen Fortschritt erkennt.

Das gilt besonders für KI-Projekte. Ein Assistent, ein Sprachmodell oder eine automatisierte Klassifikation erzeugt nicht automatisch einen geschäftlichen Nutzen. Ohne klaren Anwendungsfall entstehen Pilotprojekte, die technisch interessant sind, aber weder in bestehende Prozesse integriert noch verlässlich betrieben werden können.

Formulieren Sie deshalb vor der Technologieentscheidung ein belastbares Zielbild. Es sollte nicht nur einen gewünschten Endzustand beschreiben, sondern auch die Auswirkungen auf Rollen, Datenflüsse, Freigaben und Schnittstellen. Relevante Fragen sind:

• Welches fachliche Problem soll gelöst werden?
• Welche Arbeitsschritte entfallen, verändern sich oder kommen hinzu?
• Wer trägt künftig die fachliche und technische Verantwortung?
• Welche Abhängigkeiten bestehen zu anderen Systemen und Prozessen?
• Nach welchen qualitativen und operativen Kriterien wird der Nutzen bewertet?

Vermeiden Sie zugleich ein zu starres Zielbild. Cloud- und SaaS-Plattformen entwickeln sich laufend weiter, und auch regulatorische Anforderungen können Anpassungen notwendig machen. Die Richtung muss klar sein, der Umsetzungsweg sollte jedoch überprüfbar und anpassbar bleiben.

No-Go 2: Betroffene erst kurz vor dem Rollout einbeziehen

Wer täglich mit einem Prozess arbeitet, erkennt Ausnahmen, Abhängigkeiten und informelle Lösungen, die in einer Prozessbeschreibung oft fehlen. Werden diese Beschäftigten erst zur Schulung oder beim Produktivstart beteiligt, sind wesentliche Entscheidungen bereits gefallen. Widerstand ist dann nicht zwingend Technikfeindlichkeit, sondern kann auf reale Lücken im Konzept hinweisen.

Teilen Sie Mitarbeitende nicht vorschnell in Befürworter und Verweigerer ein. Reaktionen hängen unter anderem von der bisherigen Erfahrung, der wahrgenommenen Belastung, dem Vertrauen in die Führung und den persönlichen Auswirkungen ab. Besonders kritisch wird es, wenn Automatisierung oder KI als Kontrolle, Leistungsbewertung oder mögliche Bedrohung des Arbeitsplatzes verstanden werden.

Beteiligung bedeutet jedoch nicht, jede Entscheidung im Konsens zu treffen. Sie benötigt einen klaren Rahmen: Welche Punkte stehen fest, wo ist Mitgestaltung möglich und wer entscheidet bei Zielkonflikten? Geeignete Formate sind Prozessworkshops, Interviews, Tests mit realistischen Aufgaben sowie Pilotgruppen aus unterschiedlichen Fachbereichen.

• Beziehen Sie Fachanwender, IT, Datenschutz, Informationssicherheit und gegebenenfalls den Betriebsrat frühzeitig ein.
• Dokumentieren Sie Einwände und machen Sie sichtbar, wie damit umgegangen wurde.
• Benennen Sie Multiplikatoren, ohne ihnen die gesamte Veränderungsarbeit zu übertragen.
• Planen Sie Zeit für Feedback und Korrekturen vor dem breiten Rollout ein.

No-Go 3: Prozesse, Daten und Architektur getrennt behandeln

Eine moderne Benutzeroberfläche behebt keinen ungeklärten Prozess. Wird ein fehlerhafter Ablauf lediglich digitalisiert, werden Medienbrüche, doppelte Freigaben und unklare Zuständigkeiten häufig nur in eine neue Plattform übertragen. Vor der Automatisierung sollte daher geprüft werden, welche Schritte notwendig sind, welche vereinfacht werden können und wo eine bewusste menschliche Entscheidung erforderlich bleibt.

Auch die Datenqualität ist Teil des Change-Projekts. Automatisierte Workflows und KI-Anwendungen sind auf vollständige, aktuelle und eindeutig zugeordnete Informationen angewiesen. Unklare Stammdaten, unterschiedliche Begriffe oder fehlende Verantwortlichkeiten führen sonst zu falschen Zuordnungen, unzuverlässigen Ergebnissen und zusätzlicher manueller Nacharbeit.

Bei Cloud- und SaaS-Architekturen kommen weitere Abhängigkeiten hinzu. Identitätsmanagement, Rollenmodelle, Schnittstellen, Datenexporte, Protokollierung und der Umgang mit Anbieteränderungen müssen früh geklärt werden. Andernfalls funktioniert die neue Anwendung als isolierte Insellösung, während Beschäftigte Daten weiterhin kopieren oder auf nicht freigegebene Werkzeuge ausweichen.

Für KI-gestützte Prozesse ist außerdem festzulegen, welche Ergebnisse automatisch weiterverarbeitet werden dürfen und wann eine menschliche Prüfung erforderlich ist. Ausgaben generativer KI können unvollständig, sachlich falsch oder nicht nachvollziehbar sein. Ein produktiver Einsatz braucht deshalb definierte Eingabedaten, Prüfregeln, Freigaben und einen kontrollierten Umgang mit Fehlerfällen.

No-Go 4: Kommunikation mit Ankündigungen und Schulungen verwechseln

Eine E-Mail zum Projektstart und eine Produktschulung vor dem Go-live sind keine ausreichende Change-Kommunikation. Beschäftigte müssen verstehen, warum eine Veränderung notwendig ist, was sie konkret betrifft und welche Entscheidungen noch offen sind. Allgemeine Aussagen über Effizienz oder Zukunftsfähigkeit reichen dafür nicht aus.

Kommunizieren Sie früh, regelmäßig und zielgruppengerecht. Eine Geschäftsführung benötigt andere Informationen als ein Serviceteam, die IT-Administration oder eine Fachabteilung. Neben dem Zielbild sollten auch Einschränkungen, Übergangsphasen und bekannte Unsicherheiten offen benannt werden. Überzogene Versprechen beschädigen das Vertrauen, sobald der Arbeitsalltag von der Ankündigung abweicht.

Lernen sollte direkt an Aufgaben und Rollen anknüpfen. Neben Einführungen sind kurze Anleitungen, Übungsumgebungen, Sprechstunden und erreichbare Ansprechpartner hilfreich. Bei KI-Anwendungen benötigen Beschäftigte zusätzlich Orientierung dazu, welche Informationen eingegeben werden dürfen, wie Ergebnisse zu prüfen sind und wie fehlerhafte oder problematische Ausgaben gemeldet werden.

• Erklären Sie den Zweck der Veränderung anhand konkreter Arbeitsabläufe.
• Trennen Sie verbindliche Regeln von Empfehlungen und vorläufigen Annahmen.
• Schaffen Sie einen sichtbaren Kanal für Fragen, Fehler und Verbesserungsvorschläge.
• Planen Sie Unterstützung auch nach dem Produktivstart ein.

No-Go 5: Governance, Compliance und Betrieb nachträglich ergänzen

Datenschutz, Informationssicherheit und Compliance sind keine Abnahmeaufgaben am Projektende. Bei SaaS- und KI-Lösungen betreffen sie bereits die Auswahl und Gestaltung: Welche Daten werden verarbeitet? Wo werden sie gespeichert? Welche Unterauftragnehmer sind beteiligt? Wie werden Zugriffe, Löschfristen, Protokolle und Berechtigungen geregelt?

Je nach Anwendungsfall sind unter anderem die Datenschutz-Grundverordnung, Anforderungen des EU AI Act, branchenspezifische Vorgaben, arbeitsrechtliche Fragen und interne Richtlinien zu berücksichtigen. Welche Pflichten konkret gelten, sollte fachkundig geprüft werden. Ein pauschales Verbot neuer Werkzeuge ist dabei ebenso wenig tragfähig wie eine unkontrollierte Freigabe, die Schatten-IT oder Schatten-KI begünstigt.

Klare Governance beantwortet, wer Entscheidungen trifft und wer im laufenden Betrieb verantwortlich bleibt. Dazu gehören fachliche Systemverantwortung, Datenverantwortung, Berechtigungsmanagement, Risikobewertung, Anbietersteuerung und ein Verfahren für Änderungen. Für KI-Systeme sollten zusätzlich Modell- oder Dienständerungen, Prüfintervalle, dokumentierte Freigaben und Eskalationswege berücksichtigt werden.

Beenden Sie das Change-Projekt außerdem nicht mit dem Go-live. Beobachten Sie, ob der neue Prozess tatsächlich genutzt wird, wo Umgehungslösungen entstehen und welche Fehler wiederholt auftreten. Rückmeldungen aus Support, Fachbereichen und Kontrollen sollten in einen geregelten Verbesserungsprozess einfließen.

Fazit: Veränderung als Betriebsaufgabe verstehen

Die größten No-Gos im Change-Projekt sind ein unklarer Zweck, späte Beteiligung, getrennte Betrachtung von Technik und Organisation, oberflächliche Kommunikation sowie nachgelagerte Governance. Diese Fehler werden durch Cloud, Automatisierung und KI nicht kleiner. Vielmehr steigen die Abhängigkeiten zwischen Prozessen, Daten, Plattformen und Verantwortlichkeiten.

Ein tragfähiges Change-Projekt verbindet daher fachliches Zielbild, technische Architektur, Datenqualität, Beteiligung, Qualifizierung und Compliance von Beginn an. Führen Sie Veränderungen schrittweise ein, prüfen Sie Annahmen im Arbeitsalltag und schaffen Sie klare Zuständigkeiten für den dauerhaften Betrieb.

Akzeptanz lässt sich nicht anordnen. Sie entsteht, wenn Entscheidungen nachvollziehbar sind, Rückmeldungen ernst genommen werden und die neue Arbeitsweise im Alltag verlässlich funktioniert. So wird Veränderung nicht zum einmaligen Rollout, sondern zu einer steuerbaren Fähigkeit des Unternehmens.