Autor: Marc-Björn Seidel

Was ist eigentlich Change Management und braucht man das überhaupt?

Die bedruckte Tasse

Während es in machen Projekten als eine erst seit Neustem entdeckte, neue Disziplin gehypt wird, ignorieren oder umgehen es andere eher. Trotz mancher recherchierbaren Definition gibt es in der Projektpraxis nicht immer Konsens diesbezüglich.

Der Begriff wird offenbar unterschiedlich verstanden und interpretiert. Ein Kunde, dem das Thema wichtig war, frage bereits im Rahmen der Vergabe unter anderem auch nach einem Kurzkonzept für Change Management. Die Antworten darauf ließen auf sehr unterschiedliche Begriffsverständnisse schließen, und statt methodischer Konzepte schlug ein Anbieter lediglich Marketingideen, wie das Bedrucken von (DMS-)Tassen, vor.

Ist Change Management nun ein neu entdeckter Game Changer, ein überflüssiges Buzzword oder eine vergessene Disziplin unter neuer Namensflagge?

Was bedeutet Change Management für DMS-Projekte?

Aus unserer Sicht ist Change Management keine neue Erfindung und auch kein vom DMS-Projekt entkoppeltes (Teil-)Projekt. Zweifelsfrei bedeuten DMS-Projekte auch die Einführung von neuer Technologie. DMS-Lösungen sind unverzichtbare, infrastrukturelle Komponenten, um Digitalisierung betreiben zu können.

Einen deutlich größeren Wandel bedeuten DMS-Einführungsprojekte jedoch für die Mitarbeiter. Weniger IT-affine Personen sehen sich allein schon durch neue Anwendungen mit unbekannten Bedienoberflächen vor – teilweise angstbehaftete – Herausforderungen gestellt. Doch um nicht nur marginales Nutzenpotential von DMS-Lösungen zu haben, ist es darüber hinaus erforderlich bestehende Abläufe, organisatorische Regeln und individuelle Arbeitsweisen zu hinterfragen und teilweise anzupassen: Alte Zöpfe sollten nicht ungeprüft übernommen werden, manche müssen abgeschnitten werden, und das hat Auswirkungen auf die Anwender:

• Gewohnte Ablagewege und -systeme können nicht weitergenutzt werden.
• Prozesse, organisatorische Abläufe, werden durch die Einführung tangiert und mindestens in Details, manchmal an grundlegenden Stellen, verändert.
• Regeln und Abläufe, die oft noch auf eine analoge Welt zugeschnitten waren, müssen spätestens jetzt aktualisiert werden.
• Insbesondere dort, wo Regeln – z.B. zu Ordnungssystematik – fehlten, müssen individuelle Praktiken bereichsorientierten, teilweise auch unternehmensweiten Ablagesystemen weichen.
• Gewohnte Tätigkeiten können sich, je nach Aufgabenbereich, verändern und teilweise auch entfallen, während neue Aufgabenfelder entstehen. Ein sehr naheliegendes Beispiel dafür ist die bisherige Poststelle und eine zukünftige Scan- oder Post- und Scanstelle.

Projektspezifisch gibt es im Detail viele weitere Beispiele für Veränderungen, die nicht nur einmalig im Projekt umgesetzt, sondern insbesondere nach dem Go-Live von den Mitarbeitern angewandt und gelebt werden müssen.

Neben der Veränderung individueller Abläufe und Mikroprozesse kann durch das Anpassen von Organisationseinheiten (bzw. deren Aufgaben) und bereichs- oder unternehmensweiter Prozesse auch eine Veränderung von (so wahrgenommenen) Machtstrukturen stattfinden.

Man kann festhalten, dass es unterschiedliche Betroffenheitsgrade gibt und die Mitarbeiter unter verschiedenartigen Voraussetzungen, z.B. bezüglich ihrer IT-Affinität, konfrontiert sind.

Neben allen fachlichen und funktionalen Aufgaben, die in einem DMS-Einführungsprojekt vordergründig zu erledigen sind, besteht eine erfolgskritische Aufgabe darin, die Anwender „mitzunehmen“ und sowohl bzgl. der neuen Technik als auch besonders mit Blick auf die persönlichen, prozessualen und organisatorischen Veränderungen die Voraussetzungen für eine hohe Akzeptanz zu schaffen.

Herausforderungen im DMS-Kontext

Planvolle Veränderungen

Damit ein DMS-Projekt erfolgreich sein kann, müssen zunächst überhaupt die Stellschrauben identifiziert werden, die zu verändern sind. Die Einführung wird nicht erfolgreich gelingen, wenn alle alten Prozesse 1 zu 1 digitalisiert, d.h. mit neuer Technik umgesetzt, werden. Im Gegenteil, manches würde dadurch eher umständlicher und führt zu einem Akzeptanzrisiko. Genauso wenig zielführend ist aber ein vom DMS losgelöstes Modifizieren sämtlicher dokumentbezogener Prozesse nur um Veränderungen zu schaffen. In einigen Projekten wird diese „Henne-Ei-Frage“ der Prozessmodellierung diskutiert: Optimiert man erst die Prozesse und führt dann das DMS ein? Oder andersherum? Tatsächlich ist es bezüglich der dokumentzentrierten Prozesse empfehlenswert, beides nicht voneinander entkoppelt zu tun.

Sowohl das Hinterfragen von Prozessen als auch das „Mitnehmen“ der Anwender im Sinne einer später guten und akzeptablen Lösung, beginnt bereits im DMS-Auswahlprozess.

Die IT- oder eine Orga-Abteilung können in der Regel nicht die Anforderungen für sämtliche Bereiche benennen, weil das Detailwissen zu Arbeitsweisen, Herausforderungen und Sonderfällen oft fehlt. Das würde in der Konsequenz zu längeren Einführungsprojekten, unvorhergesehenen Hürden und höheren Kosten führen. Nicht berücksichtigte bereichsspezifische Anforderungen können zusätzlich zu Akzeptanzverlust oder Nichtbedienbarkeit führen, wodurch der Projekterfolg gefährdet wird.

Abhilfe schafft eine geeignete Methodik, zu der u.a. die Einbindung der Bereiche bereits im Prozess der Anforderungsdefinition gehört. Um ein ausgewogenes Verhältnis zwischen Aufwand und Nutzen zu wahren, wählt man relevante Bereiche gezielt aus. Identifizierte Key-User oder Vertreter spezifischer Aufgaben/Rollen werden tiefer in den Konzeptionsprozess einbezogen. Für beides, die Kommunikation mit den Stakeholdern bzw. Bereichen sowie auch die Detailanalyse, bieten sich jeweils geeignete, zielgerichtete Checklisten an, mit denen die benötigten Informationen ermittelt werden und die Erhebungsphase trotz Detaillierung zügig und fokussiert vorangetrieben werden kann.

Qualität durch kontinuierliche Einbindung

Eine einmalige Einbindung der potentiellen Anwender ist jedoch nicht ausreichend und auch nicht zielführend: Im Verlauf eines DMS-Projektes wachsen DMS-Verständnis und Erfahrungen zum Produkt bzw. zu den Produktmöglichkeiten und -grenzen. Häufig können Anwender erst im Laufe der Zeit verstehen, was formulierte Anforderungen bedeuten, welche Alternativen es gibt oder welche konkrete Auswirkungen einzelne Designentscheidungen auf die tägliche Arbeitspraxis haben. Daher ist es wichtig, dass eine Einbeziehung der User im Sinne von „Quality Gates“ systematisch an entscheidenden Stellen über den gesamten Projektverlauf hinweg (z.B. in Anforderungsanalyse, Konzeption, Implementierung, Test und Wissenstransfer) in das Projekt einbezogen werden.

Auf der anderen Seite ist es die Aufgabe des Projektes (z.B. Projektleitung oder Kernprojektteam) immer wieder die Ziele zu fokussieren: Nicht jeder Anwenderwunsch und nicht jede kreative Idee von IT-Nerds ist langfristig sinnvoll. Eine robuste 80%-Lösung ist in vielen Fällen sinnvoller und langfristig betrachtet wirtschaftlicher als eine gut gemeinte 99%-Lösung.

Wissenstransfer

Je umfangreicher die Veränderungen sind, desto wichtiger ist eine frühzeitige, projektbegleitende Kommunikation. Ist die Zielgerade für den ersten Go-Live in Sicht, müssen alle zukünftigen Anwender zudem befähigt werden und Informationen zu Lösung und Veränderungen zugänglich gemacht werden. Dabei gibt es methodisch längst eine breite Palette an Alternativen neben dem tradierten 1000-Seiten-Handbuch (egal ob gedruckt oder als PDF) und der Frontalschulung jedes einzelnen Anwenders. Es ist sehr sinnvoll, sich rechtzeitig konzeptionelle Gedanken für die Schulungsmaßnahmen zu machen und dabei auch über den Zeitpunkt des Go-Live hinauszudenken.

Braucht es einen Change Manager?

Change Management ist keine neue „on top“-Disziplin, kein isoliertes Arbeitspaket oder gar ein ausgelagertes Teilprojekt. Es ist ein Prozess, der bereits vor der Auswahlentscheidung einer DMS-Lösung beginnt und über den Termin der Inbetriebnahme hinaus reicht. Für unternehmensweite DMS-Lösungen ist der erste Go-Live (z.B. für ein Pilot-Projekt) eher der Ausgangspunkt für weitere Veränderungen durch Rollouts, Anpassungen etc. statt des Endes aller Projektaktivitäten. Mit geeigneten Change-Methoden während der Projektzeit werden somit auch Grundsteine für die Weiterentwicklung und den Betrieb gelegt. Es erscheint sinnvoll, dass die Change Management-Aufgaben nah an der Projektleitung und der späteren Stelle für die Applikationsverantwortung angegliedert werden.