Change Management und Kommunikation sind untrennbar mit ERP-Projekten verbunden. Theoretisch besteht heute eine gute Übersicht zu den Voraussetzungen erfolgreichen Wandels in Organisationen. Dennoch ist die Quote der gescheiterten Projekte nicht gesunken, die nicht „In Time, In Budget, In Quality“ abgewickelt wurden. Häufig passen die theoretischen Einsichten nicht zu dem, was operativ in Projekten für ERP-Implementierungen de facto geleistet werden kann. Untersucht werden ERP-Projekte daher hier nicht primär als Gegenstand von Change Management, sondern als Ergebnis einer organisationsinternen Innovation und im Hinblick darauf, welche Rolle dabei die Kommunikation im Umfeld der ERP-Entwicklung spielt.
nnovationsgenerierung in Organisationen
Unter Innovationen versteht der Autor geänderte Arbeitsweisen, die sich aus einem gegebenen Mangel in der bestehenden Organisation oder aus wahrgenommenen Optionen für neue Verfahrensweisen ergeben. Kriterium einer Innovation wird dann, dass diese Änderung im Vorgehen die gesamte Organisation umfasst. Andernfalls sollte eher von einer Adaption gesprochen werden. Die Frage, ob Innovationen von Organisationsmitgliedern oder Externen in die Organisation hineingetragen werden, mag trivial erscheinen. Diese Unterscheidung hat jedoch Konsequenzen für die Akzeptanz von Innovation, die durch und für das ERP-Projekt bereitgestellt werden.
Als hilfreich erweist sich eine Dreiteilung von Innovationen im IT-Umfeld. Eine geänderte Arbeitsweise oder Neuverteilungen von Arbeitsschritten in der IT-Abteilung können Innovationen für die IT-Abteilungen darstellen (Typ-1-Innovation). Auf einer zweiten Stufe folgt die Adaption von neuen Software-Komponenten zur Erledigung der Arbeiten oder die Einführung von neuen Programmier-Technologien (Typ-2-Innovation). Typ-1- und Typ-2-Innovationen stellen gemeinsam die Grundlage für Serviceinnovationen in der Organisation dar. Software und IT-Abteilungen werden bei solchen Serviceinnovationen zu Enablern und geraten in das Zentrum der Aufmerksamkeit. Dabei wird die IT-Abteilung direkt in den Serviceprozess integriert.
Im Mittelstand gibt es kaum Organisationen, die über das technische und funktionale Wissen in einer ausreichenden Detailtiefe verfügen, um die Implementierung eines ERP-Systems aus eigener Kraft zu stemmen. Gründe dafür sind vielfältig, aber sicherlich stellt die Fokussierung auf das Kerngeschäft der Organisation einen wichtigen Treiber dar, selbst keine Heerscharen von ERP-Beratern und -Entwicklern vorzuhalten.
Jeder im Umfeld von IT-Beratung ist sich bewusst, dass Beratung keine Einbahnstraße ist. Im Regelfall leistet auch die Kundenorganisation einen Beitrag zur ERP-Implementierung. Dieser Beitrag ist im Regelfall mehr als passive Rezeption. Es sollte gelten, dass bei einer Dienstleistung eine Koproduktion von Dienstleister und Kunde stattfindet.
Pauschal ist kein ERP-Projekt immer eine Neuinstallation oder ein Migrationsprojekt auf ein höheres Release. Strukturell lassen sich Maintenance-Projekte mit kurzer bis mittlerer Dauer von Business-Re-Engineering oder „Packaged Business Applications“- Projekten mit langer Dauer unterscheiden. Dabei sind es letztere, die oft Gegenstand von Change Management sind. Maintenance-Projekte mit kleinen Änderungen bieten kaum Raum für Innovationen. Oft schreibt in diesem Umfeld der Gesetzgeber weitestgehend die Art und Weise vor, wie etwas implementiert werden muss.
Spannend hingegen wird es bei Projekten mit einer langen Dauer. Bei diesen gilt, dass der Dienstleistungsvertrag mit seinen gegenseitigen Verpflichtungen erhebliche Spielräume bietet, Innovationen über das ERP-Projekt vorzunehmen. Dabei umfasst im Regelfall der Dienstleistungsvertrag nicht nur die Lieferung des fertigen Produkts, sondern definiert auch die Zwischenprodukte. Diese Zwischenprodukte kann der ERP-Anbieter nicht alleine erstellen, er ist auf die Mitarbeit des Kunden angewiesen.
Oft stellt die Abnahme dieser Zwischenprodukte durch den Kunden eines der Haupthindernisse für einen flüssigen Projektablauf dar und wird zu einem Konfliktherd. Diese Abnahmen können verstanden werden als ein echtes Commitment zum Projekt. Die Abnahme stellt einen Gradmesser für den Widerstand gegen eine Innovation-ERP-Applikation dar.
Es hilft, sich vor Augen zu führen, dass keine Innovation unmittelbar von allen Kunden angenommen wird. Dennoch wird von Projekt- und Einzelmitgliedern des Lenkungsausschusses das Projekt als Innovation weiter vorangetrieben. Somit ist das Projekt in einer dauernden Schaukelbewegung zwischen Ablehnung und Fortführung. Daher ist es hilfreich, sich zu vergegenwärtigen, dass Innovationen eher einer zyklischen Adaption unterliegen. Erst sehr spät erreicht dabei eine Innovation, und damit auch ein ERP-Projekt, eine Annahme durch mehr als ein Drittel der Beschäftigten (siehe Abbildung 1).
Einführungen von ERP-Applikationen, verstanden als Innovation, gehen mit verschiedenen Arten von Änderungen einher. Diese Veränderungen sind regelmäßig:
Kommunikation in und für ERP-Projekte
Jeder, der sich im ERP-Umfeld bewegt, weiß, dass Kommunikation das A und O ist. Dabei geht es darum, die Informationen zu erhalten und an den Kunden zu bringen, die notwendig sind, um den Projektauftrag zu erfüllen. In dieser Kommunikation teilt das Projektteam des Implementierers permanent implizit mit:
Kommunikation dient dem Austausch von Informationen zwischen Kunden und Berater. Dabei kann jede Äußerung jeweils anders als initial gemeint verstanden werden. Kunde und Berater haben daher Interesse daran, dass sich Sprecher/ Schreiber bemühen, sich so deutlich wie möglich verständlich zu machen, während der Zuhörer/Leser sich auf die Äußerung des Schreibers/Sprechers einlässt und im Sinne der vorherigen Kommunikation und Interaktionen versteht. Somit wird deutlich, dass keine Aussage in der Kommunikation zwischen Berater und Kunde im luftleeren Raum steht.
Die Vorgeschichte der Interaktion kann kürzer oder länger und persönlich oder technisch vermittelt sein. Seit Schulz von Thun ist das Quadrat der Kommunikation hinlänglich bekannt. In der IT-Beratungspraxis wird aber beobachtet, dass dessen Kern nicht unbedingt eingehalten wird (siehe Abbildung 2). Die vier Seiten des Quadrats sind jeweils mit einer Frage verbunden:
Nach Schulz von Thun hat jeder sein bevorzugtes Ohr und bei IT-Beratern ist im Regelfall das rationale Sach- und Appell-Ohr besonders gut ausgeprägt. Das eine, um möglichst schnell die Information zu erfassen, und das andere, um abzuwägen, wie groß der Aufwand ist. Mit Hinblick auf die Idee, dass ERP-Projekte Innovationen sind, steckt erhebliches Potenzial in der Kommunikation. Berater sind sich oft dessen nicht bewusst.
In ERP-Projekten läuft ein Großteil der Kommunikation über Sprache. Mit Sprache ist hier die Vermittlung von Wissen zwischen den Beteiligten gemeint. Denn das Wissen über die Abteilung und deren Prozesse, das ein Mitarbeiter an den Berater weitergibt, ist für das ERP-Projekt entscheidend. Die Spra- che, die in einem Projekt oder Teilprojekt gesprochen wird, ist Ausdruck des Wissens über die Gesamtorganisation und die darin vorkommenden Prozesse. Daher gibt es in ERP-Projekten grundsätzlich kein falsches Wissen. Vielmehr werden über Sprache Wissensunterschiede aufgedeckt. Diese stellen dar, was in einer bestimmten Fachabteilung wichtig ist und welche Arbeitsweisen damit einhergehen. Wird dieser Tatbe- stand der Unterschiede im Wissen als Unter- schied im Arbeiten wahrgenommen, ist ein Berater nicht mehr nur für die Installation der Software allein zuständig.
Der Berater schlüpft in die Rolle eines Lehrers. Damit ist gemeint, dass eine Perspektive über die Gesamtorganisation erlangt wird. Diese wird als Systementwurf an die Kunden- organisation zurückgeben. Der Berater muss zunächst die Gesamtorganisation verstehen, bevor er einen realistischen, praktikablen Syste- mentwurf an den Kunden übergibt.
Es gibt es viele Tools, die diese kollaborative Arbeit zwischen Fachabteilungen und auch mit Beratern unterstützen. Dazu gehört SharePoint, aber auch das ERP-System selbst. Praktiker der Beratung stellen jedoch fest, dass nur sehr selten Dokumente über die Fachbereiche hinweg verständlich sind.
Oft ist der Vorwurf zu hören, dass hier ein Prozessobjekt falsche Attribute hat oder doch ein anderer Name zu verwenden wäre. Solche Diskussionen über falsche Namen von Geschäftsobjekten oder angeblich fehlerhafte Attribute von Geschäftsobjekten, die abteilungsgetrieben sind, stellen schnell die eigentliche Aufgabe des ERP-Projekts in den Hintergrund. Wenn Projekte für solche Diskussionen über Korrektheit von Begriffen „gehijackt“ werden, ist Widerstand vorprogrammiert. Es wird immer schwerer, abteilungsübergreifend, unter Teilhabe des Kunden, das ERP-Projekt zu implementieren.
Dies muss jedoch nicht passieren. Es gibt clevere Lösungsmöglichkeiten, um solche Diskussionen einzudämmen. Eine Lösung stellt die Horus Software Tool Suite mit der Komponente „Business Modeler“ dar. Dort können interaktiv zwischen dem Berater und den Fachabteilungen, aber auch unter den Fachabteilungen selbst, sowohl der Prozess als auch die dazugehörige Nomenklatur der Geschäftsobjekte gepflegt und in einem Glossar für alle Teilnehmer am Projekt und für die Kundenorganisation im Generellen bereitgestellt werden. Somit kann ein neuer, einheitlicher Sprachgebrauch über das ERP-Projekt für die Gesamtorganisation erarbeitet und „geübt“ werden. Ferner wird die neue Soll-Lösung im Projektteam verankert und dann von dort aus auch von den internen Mitarbeitern weiter kommuniziert. Diese Lösung ist doppelt charmant, da sie es erlaubt, Wörterbuch und Prozess-Dokumentation parallel zu sein. Diese Dokumentation wurde kollaborativ erstellt und veranschaulicht damit die Teilhabe des Kunden am ERP-System.
ERP-Projekte sind ein wahrer Hort an Kreativität, um deren erfolgreiche Implementierung zu verhindern beziehungsweise den Status quo bestmöglich zu erhalten. Klassiker der Vermeidung ist das „Information hoarding und hiding“. Fachabteilungen geben keine präzisen Informationen über ihre eigenen internen Abläufe bekannt. Ferner stellen sich mit dieser Strategie oft Leistungsträger als ahnungsloser dar, als sie in Wirklichkeit sind. Dazu zählt auch, dass bestehende Dokumentationen nicht übergeben werden. Ein anderer Klassiker ist das Verwickeln der Organisation in verbale Scharmützel über den Sinn und Zweck
des ERP-Projekts. Verbunden ist damit die Frage, ob denn die Berater überhaupt wüssten, was die Kundenorganisation wirklich macht. In dieser Strategie geht es darum, sowohl den Implementierer zu diskreditieren als auch zu versuchen, durch nicht implementierbare Kompromisse zwischen Fachabteilungen das Projekt zum Scheitern zu bringen. Fachabteilungen zementieren damit ihre Machtposition und sabotieren das Projekt. Jeder hat etwas abgegeben, aber das eigentliche Thema wurde aus der Organisation geschoben.
„Wir haben gute Requirements, die genau auf unsere Organisation passen, daher sind keine Neuerungen notwendig“ und „Wir haben eine zutiefst integrierte Architektur, daher ist es unmöglich, etwas am ERP-System zu verändern“. Dies sind die Repräsentanten der dritten Art von Widerstand. Schlicht können diese als „Todeshammer“ definiert werden. Ihnen ist fachlich schwerlich etwas entgegenzusetzen, aber das Umwandeln solcher Aussagen in positives Commitment zum Projekt wird unmöglich. In diese Gruppe von Widerstand gehört auch, dass, sofern überhaupt Entscheidungen getroffen werden, sich diese sehr stark am Status quo orientieren. Eine subtile Variante des gleichen Vorgehens ist das gewissentliche Übersehen oder Nicht-Einhalten der vertraglichen Pflichten oder dubiose Implementierungen derselben. Das Ausmaß der Erbringung von Dienstleistungen durch den Kunden für das Projekt gibt Hinweise auf Widerstand oder Wohlwollen gegenüber dem von ihm initiierten ERP-Projekt.
Wie mit Widerstand umgehen?
Widerstände in ERP-Projekten sind normal und sollten daher nüchtern betrachtet werden. Daher gilt es zunächst einmal, als Betroffener in einer Widerstandssituation Ruhe zu bewahren und zu verstehen, was passiert. Widerstand ist jeweils projekt- und organisationsspezifisch. Zudem wird oft ein ERP-Projekt zwar mit Change-Management-Maßnahmen begleitet, aber das, was im Projekt selbst passiert, ist nicht Gegenstand des Change Management. Da Menschen in ERP-Projekten agieren und diese real strukturieren, sollte der Versuch unternommen werden, die Ängste, Sorgen und Ziele der projektbeteiligten Mitarbeiter in die Planung zu integrieren. Damit ist gemeint, sich aus der „einfachen Rolle“ des Beraters in die Lage des Mitarbeiters zu versetzen und vier Fragen zu stellen:
Widerstände, die auf Missverständnissen beruhen, lassen sich auflösen, wenn in solchen Fällen nicht nur der fachliche Berater, sondern noch ein Kollege dazukommt. Gemäß dem Quadrat der Kommunikation kann es sein, dass der federführende Berater etwas überhört, das dem Kunden aber sehr wichtig ist.
Nicht lösen kann ein Projektteam Widerstände, die dem Kundenunternehmen inhärent sind, etwa sich verändernde Machtpositionen, die den Betrogenen aufstoßen; das Projekt kann diese nicht aufangen und muss dennoch mit ihnen agieren. Wenn diese Widerstände das ERP-Projekt in der Zielerreichung beeinträchtigen, muss die Projektleitung zur Maßnahme der Information des Managements über den Lenkungskreis greifen.
nnovationsgenerierung in Organisationen
Unter Innovationen versteht der Autor geänderte Arbeitsweisen, die sich aus einem gegebenen Mangel in der bestehenden Organisation oder aus wahrgenommenen Optionen für neue Verfahrensweisen ergeben. Kriterium einer Innovation wird dann, dass diese Änderung im Vorgehen die gesamte Organisation umfasst. Andernfalls sollte eher von einer Adaption gesprochen werden. Die Frage, ob Innovationen von Organisationsmitgliedern oder Externen in die Organisation hineingetragen werden, mag trivial erscheinen. Diese Unterscheidung hat jedoch Konsequenzen für die Akzeptanz von Innovation, die durch und für das ERP-Projekt bereitgestellt werden.
Als hilfreich erweist sich eine Dreiteilung von Innovationen im IT-Umfeld. Eine geänderte Arbeitsweise oder Neuverteilungen von Arbeitsschritten in der IT-Abteilung können Innovationen für die IT-Abteilungen darstellen (Typ-1-Innovation). Auf einer zweiten Stufe folgt die Adaption von neuen Software-Komponenten zur Erledigung der Arbeiten oder die Einführung von neuen Programmier-Technologien (Typ-2-Innovation). Typ-1- und Typ-2-Innovationen stellen gemeinsam die Grundlage für Serviceinnovationen in der Organisation dar. Software und IT-Abteilungen werden bei solchen Serviceinnovationen zu Enablern und geraten in das Zentrum der Aufmerksamkeit. Dabei wird die IT-Abteilung direkt in den Serviceprozess integriert.
Im Mittelstand gibt es kaum Organisationen, die über das technische und funktionale Wissen in einer ausreichenden Detailtiefe verfügen, um die Implementierung eines ERP-Systems aus eigener Kraft zu stemmen. Gründe dafür sind vielfältig, aber sicherlich stellt die Fokussierung auf das Kerngeschäft der Organisation einen wichtigen Treiber dar, selbst keine Heerscharen von ERP-Beratern und -Entwicklern vorzuhalten.
Jeder im Umfeld von IT-Beratung ist sich bewusst, dass Beratung keine Einbahnstraße ist. Im Regelfall leistet auch die Kundenorganisation einen Beitrag zur ERP-Implementierung. Dieser Beitrag ist im Regelfall mehr als passive Rezeption. Es sollte gelten, dass bei einer Dienstleistung eine Koproduktion von Dienstleister und Kunde stattfindet.
Pauschal ist kein ERP-Projekt immer eine Neuinstallation oder ein Migrationsprojekt auf ein höheres Release. Strukturell lassen sich Maintenance-Projekte mit kurzer bis mittlerer Dauer von Business-Re-Engineering oder „Packaged Business Applications“- Projekten mit langer Dauer unterscheiden. Dabei sind es letztere, die oft Gegenstand von Change Management sind. Maintenance-Projekte mit kleinen Änderungen bieten kaum Raum für Innovationen. Oft schreibt in diesem Umfeld der Gesetzgeber weitestgehend die Art und Weise vor, wie etwas implementiert werden muss.
Spannend hingegen wird es bei Projekten mit einer langen Dauer. Bei diesen gilt, dass der Dienstleistungsvertrag mit seinen gegenseitigen Verpflichtungen erhebliche Spielräume bietet, Innovationen über das ERP-Projekt vorzunehmen. Dabei umfasst im Regelfall der Dienstleistungsvertrag nicht nur die Lieferung des fertigen Produkts, sondern definiert auch die Zwischenprodukte. Diese Zwischenprodukte kann der ERP-Anbieter nicht alleine erstellen, er ist auf die Mitarbeit des Kunden angewiesen.
Oft stellt die Abnahme dieser Zwischenprodukte durch den Kunden eines der Haupthindernisse für einen flüssigen Projektablauf dar und wird zu einem Konfliktherd. Diese Abnahmen können verstanden werden als ein echtes Commitment zum Projekt. Die Abnahme stellt einen Gradmesser für den Widerstand gegen eine Innovation-ERP-Applikation dar.
Es hilft, sich vor Augen zu führen, dass keine Innovation unmittelbar von allen Kunden angenommen wird. Dennoch wird von Projekt- und Einzelmitgliedern des Lenkungsausschusses das Projekt als Innovation weiter vorangetrieben. Somit ist das Projekt in einer dauernden Schaukelbewegung zwischen Ablehnung und Fortführung. Daher ist es hilfreich, sich zu vergegenwärtigen, dass Innovationen eher einer zyklischen Adaption unterliegen. Erst sehr spät erreicht dabei eine Innovation, und damit auch ein ERP-Projekt, eine Annahme durch mehr als ein Drittel der Beschäftigten (siehe Abbildung 1).
Einführungen von ERP-Applikationen, verstanden als Innovation, gehen mit verschiedenen Arten von Änderungen einher. Diese Veränderungen sind regelmäßig:
- Neue Prozesse mit einer geänderten Personalzusammenstellung
- Eine geänderte Organisationsstruktur mit einem neuen Zuschnitt von Verantwortlichkeiten
- Erschaffung und Verteilung neuen Wissens, um das ERP-System zu implementieren
- Definition von neuen Soll-Prozessen, die bereits in die Requirements-Phase eingehen können
- Eine kohärente Kommunikation zwischen den Abteilungen, um die Prozesse für das Soll-System zu definieren
- Einführung neuer Technologien und Kollaborationsmechanismen, um das ERP- Projekt zu einem Organisationserfolg zu machen.
Kommunikation in und für ERP-Projekte
Jeder, der sich im ERP-Umfeld bewegt, weiß, dass Kommunikation das A und O ist. Dabei geht es darum, die Informationen zu erhalten und an den Kunden zu bringen, die notwendig sind, um den Projektauftrag zu erfüllen. In dieser Kommunikation teilt das Projektteam des Implementierers permanent implizit mit:
- Wie gut sich jeder im Team in der Kundendomäne auskennt
- Wie sehr sich das Team in den Prozessen des Kunden auskennt
- Wie sich das Team zu dem Projekt stellt, für das es tätig ist
Kommunikation dient dem Austausch von Informationen zwischen Kunden und Berater. Dabei kann jede Äußerung jeweils anders als initial gemeint verstanden werden. Kunde und Berater haben daher Interesse daran, dass sich Sprecher/ Schreiber bemühen, sich so deutlich wie möglich verständlich zu machen, während der Zuhörer/Leser sich auf die Äußerung des Schreibers/Sprechers einlässt und im Sinne der vorherigen Kommunikation und Interaktionen versteht. Somit wird deutlich, dass keine Aussage in der Kommunikation zwischen Berater und Kunde im luftleeren Raum steht.
Die Vorgeschichte der Interaktion kann kürzer oder länger und persönlich oder technisch vermittelt sein. Seit Schulz von Thun ist das Quadrat der Kommunikation hinlänglich bekannt. In der IT-Beratungspraxis wird aber beobachtet, dass dessen Kern nicht unbedingt eingehalten wird (siehe Abbildung 2). Die vier Seiten des Quadrats sind jeweils mit einer Frage verbunden:
- Sachinhalt: Welches Faktum wird beschrieben?
- Appell: Welches Ziel hat eine Aussage/Kommunikation?
- Beziehung: In welcher Rolle sind Sprecher und Zuhörer aus der Sicht des Sprechers?
- Selbstkundgabe: Was sagt der Sprecher mit seiner Aussage über sich selbst aus?
- Sach-Ohr: Inhalte der Äußerung zählen
- Selbstkundgabe-Ohr: Was möchte mir der Sprecher über sich im Rahmen der Kommunikation sagen?
- Beziehungs-Ohr: Wie behandelt mich der Sprecher? Wie viel Respekt kommt da zum Vorschein?
- Appell-Ohr
Nach Schulz von Thun hat jeder sein bevorzugtes Ohr und bei IT-Beratern ist im Regelfall das rationale Sach- und Appell-Ohr besonders gut ausgeprägt. Das eine, um möglichst schnell die Information zu erfassen, und das andere, um abzuwägen, wie groß der Aufwand ist. Mit Hinblick auf die Idee, dass ERP-Projekte Innovationen sind, steckt erhebliches Potenzial in der Kommunikation. Berater sind sich oft dessen nicht bewusst.
In ERP-Projekten läuft ein Großteil der Kommunikation über Sprache. Mit Sprache ist hier die Vermittlung von Wissen zwischen den Beteiligten gemeint. Denn das Wissen über die Abteilung und deren Prozesse, das ein Mitarbeiter an den Berater weitergibt, ist für das ERP-Projekt entscheidend. Die Spra- che, die in einem Projekt oder Teilprojekt gesprochen wird, ist Ausdruck des Wissens über die Gesamtorganisation und die darin vorkommenden Prozesse. Daher gibt es in ERP-Projekten grundsätzlich kein falsches Wissen. Vielmehr werden über Sprache Wissensunterschiede aufgedeckt. Diese stellen dar, was in einer bestimmten Fachabteilung wichtig ist und welche Arbeitsweisen damit einhergehen. Wird dieser Tatbe- stand der Unterschiede im Wissen als Unter- schied im Arbeiten wahrgenommen, ist ein Berater nicht mehr nur für die Installation der Software allein zuständig.
Der Berater schlüpft in die Rolle eines Lehrers. Damit ist gemeint, dass eine Perspektive über die Gesamtorganisation erlangt wird. Diese wird als Systementwurf an die Kunden- organisation zurückgeben. Der Berater muss zunächst die Gesamtorganisation verstehen, bevor er einen realistischen, praktikablen Syste- mentwurf an den Kunden übergibt.
Es gibt es viele Tools, die diese kollaborative Arbeit zwischen Fachabteilungen und auch mit Beratern unterstützen. Dazu gehört SharePoint, aber auch das ERP-System selbst. Praktiker der Beratung stellen jedoch fest, dass nur sehr selten Dokumente über die Fachbereiche hinweg verständlich sind.
Oft ist der Vorwurf zu hören, dass hier ein Prozessobjekt falsche Attribute hat oder doch ein anderer Name zu verwenden wäre. Solche Diskussionen über falsche Namen von Geschäftsobjekten oder angeblich fehlerhafte Attribute von Geschäftsobjekten, die abteilungsgetrieben sind, stellen schnell die eigentliche Aufgabe des ERP-Projekts in den Hintergrund. Wenn Projekte für solche Diskussionen über Korrektheit von Begriffen „gehijackt“ werden, ist Widerstand vorprogrammiert. Es wird immer schwerer, abteilungsübergreifend, unter Teilhabe des Kunden, das ERP-Projekt zu implementieren.
Dies muss jedoch nicht passieren. Es gibt clevere Lösungsmöglichkeiten, um solche Diskussionen einzudämmen. Eine Lösung stellt die Horus Software Tool Suite mit der Komponente „Business Modeler“ dar. Dort können interaktiv zwischen dem Berater und den Fachabteilungen, aber auch unter den Fachabteilungen selbst, sowohl der Prozess als auch die dazugehörige Nomenklatur der Geschäftsobjekte gepflegt und in einem Glossar für alle Teilnehmer am Projekt und für die Kundenorganisation im Generellen bereitgestellt werden. Somit kann ein neuer, einheitlicher Sprachgebrauch über das ERP-Projekt für die Gesamtorganisation erarbeitet und „geübt“ werden. Ferner wird die neue Soll-Lösung im Projektteam verankert und dann von dort aus auch von den internen Mitarbeitern weiter kommuniziert. Diese Lösung ist doppelt charmant, da sie es erlaubt, Wörterbuch und Prozess-Dokumentation parallel zu sein. Diese Dokumentation wurde kollaborativ erstellt und veranschaulicht damit die Teilhabe des Kunden am ERP-System.
ERP-Projekte sind ein wahrer Hort an Kreativität, um deren erfolgreiche Implementierung zu verhindern beziehungsweise den Status quo bestmöglich zu erhalten. Klassiker der Vermeidung ist das „Information hoarding und hiding“. Fachabteilungen geben keine präzisen Informationen über ihre eigenen internen Abläufe bekannt. Ferner stellen sich mit dieser Strategie oft Leistungsträger als ahnungsloser dar, als sie in Wirklichkeit sind. Dazu zählt auch, dass bestehende Dokumentationen nicht übergeben werden. Ein anderer Klassiker ist das Verwickeln der Organisation in verbale Scharmützel über den Sinn und Zweck
des ERP-Projekts. Verbunden ist damit die Frage, ob denn die Berater überhaupt wüssten, was die Kundenorganisation wirklich macht. In dieser Strategie geht es darum, sowohl den Implementierer zu diskreditieren als auch zu versuchen, durch nicht implementierbare Kompromisse zwischen Fachabteilungen das Projekt zum Scheitern zu bringen. Fachabteilungen zementieren damit ihre Machtposition und sabotieren das Projekt. Jeder hat etwas abgegeben, aber das eigentliche Thema wurde aus der Organisation geschoben.
„Wir haben gute Requirements, die genau auf unsere Organisation passen, daher sind keine Neuerungen notwendig“ und „Wir haben eine zutiefst integrierte Architektur, daher ist es unmöglich, etwas am ERP-System zu verändern“. Dies sind die Repräsentanten der dritten Art von Widerstand. Schlicht können diese als „Todeshammer“ definiert werden. Ihnen ist fachlich schwerlich etwas entgegenzusetzen, aber das Umwandeln solcher Aussagen in positives Commitment zum Projekt wird unmöglich. In diese Gruppe von Widerstand gehört auch, dass, sofern überhaupt Entscheidungen getroffen werden, sich diese sehr stark am Status quo orientieren. Eine subtile Variante des gleichen Vorgehens ist das gewissentliche Übersehen oder Nicht-Einhalten der vertraglichen Pflichten oder dubiose Implementierungen derselben. Das Ausmaß der Erbringung von Dienstleistungen durch den Kunden für das Projekt gibt Hinweise auf Widerstand oder Wohlwollen gegenüber dem von ihm initiierten ERP-Projekt.
Wie mit Widerstand umgehen?
Widerstände in ERP-Projekten sind normal und sollten daher nüchtern betrachtet werden. Daher gilt es zunächst einmal, als Betroffener in einer Widerstandssituation Ruhe zu bewahren und zu verstehen, was passiert. Widerstand ist jeweils projekt- und organisationsspezifisch. Zudem wird oft ein ERP-Projekt zwar mit Change-Management-Maßnahmen begleitet, aber das, was im Projekt selbst passiert, ist nicht Gegenstand des Change Management. Da Menschen in ERP-Projekten agieren und diese real strukturieren, sollte der Versuch unternommen werden, die Ängste, Sorgen und Ziele der projektbeteiligten Mitarbeiter in die Planung zu integrieren. Damit ist gemeint, sich aus der „einfachen Rolle“ des Beraters in die Lage des Mitarbeiters zu versetzen und vier Fragen zu stellen:
- Wer mag schon einem Projekt zuarbeiten und dazu aktiv beitragen, wenn der Betrogene weiß, dass sein Arbeitsplatz bedroht ist?
- Wie groß kann die Motivation sein, wenn durch das ERP-Projekt ein ganzes Arbeitsleben aus den Angeln gehoben wird?
- Was, wenn das ERP-Projekt zu einer dramatischen Personalreduzierung in der IT-Abteilung führt, dieser aber für das ERP als Zulieferer vom Kunden angedient wird, um die Mitwirkungspflichten zu erfüllen?
- Wie kann man die Ziele, die das Implementierungsteam hat, mit denen der Kernbetrogenen zusammenbringen und somit Allianzen bilden?
Widerstände, die auf Missverständnissen beruhen, lassen sich auflösen, wenn in solchen Fällen nicht nur der fachliche Berater, sondern noch ein Kollege dazukommt. Gemäß dem Quadrat der Kommunikation kann es sein, dass der federführende Berater etwas überhört, das dem Kunden aber sehr wichtig ist.
Nicht lösen kann ein Projektteam Widerstände, die dem Kundenunternehmen inhärent sind, etwa sich verändernde Machtpositionen, die den Betrogenen aufstoßen; das Projekt kann diese nicht aufangen und muss dennoch mit ihnen agieren. Wenn diese Widerstände das ERP-Projekt in der Zielerreichung beeinträchtigen, muss die Projektleitung zur Maßnahme der Information des Managements über den Lenkungskreis greifen.
