Professionelles Änderungsmanagement bei Automobilzulieferer implementiert

Rahmenbedingungen und Ausgangssituation

Die Automobilindustrie verändert sich laufend und immer schneller. Kosten- und Zeitdruck sind ständige Begleiter. Das trifft natürlich auch auf Tier 1 Lieferanten zu, die in immer kürzere Zeit anbieten, liefern und auf Kundenwünsche reagieren müssen. Änderungen durch Kunden, Lieferanten oder auch die Umsetzung eigener Verbesserungsideen gehören zum Tagesgeschäft. Daher ist es wichtig, einen leistungsfähigen Prozess zu haben, der diese Notwendigkeiten unterstützt.

Unser Kunde ist erfolgreich am Markt und hat natürlich Prozesse und Vorgehensweisen, um Änderungen durchzuführen. Auf der Suche nach mehr Effizienz und Effektivität wuchs aber der Wunsch, die Prozessierung von Änderungen auf den Prüfstand zu stellen. Die Zielsetzung war, durch die Optimierung des Änderungsprozesses noch profitabler zu werden. Aber auch die Stärkung der Prozessrobustheit und Sicherstellung der Lieferfähigkeit waren Ziele der Initiative.

Wir haben gemeinsam den klassischen Ansatz gewählt:

  • Eine Analyse hat die Herausforderungen aber auch erste Ideen zutage gebracht
  • Gemeinsam mit dem Kundenteam wurde der Prozess modelliert
  • Ein Schwerpunkt liegt aktuell auf der Umsetzung in allen Standorten und Tochterunternehmen der Gruppe

Anders als bei einem klassischen Prozessprojekt hatten wir von Anfang an den Auftrag, den Prozess direkt in einer geeigneten Tool-Landschaft zu integrieren sowie die Anbindung der PLM- und ERP-Systeme sicherzustellen.

Vorgehensweise

Beim Aufsetzen des Projekts war uns von Anfang an wichtig, dass alle Bereiche, die an der Produktentstehung beteiligt sind, auch Teil dieser Initiative sind. Dementsprechend groß war unser Team. Uns war auch wichtig, alle betroffenen Produktionsstandorte in die Analysephase einzubeziehen. An den Standorten haben wir jeweils einen bereichsübergreifenden Workshop zur Prozessaufnahme durchgeführt. Begleitend haben wir Interviews mit Bereichsvertretern geführt, um herauszufinden, was aus Sicht der Bereiche geändert – und mindestens genauso wichtig – erhalten werden muss. Durch die Fragestellung der IT-System-Umsetzung haben wir auch bereits in der Analyse intensiv betrachtet, welche Tools zur Anwendung kommen.

Dabei haben wir die drei Ebenen Prozess, Rollen und Tool fokussiert. Diese Elemente haben uns durch das gesamte Projekt begleitet und helfen nun, die Ergebnisse der Analyse zu strukturieren.

Die Analyse hat gezeigt, dass der Kunde natürlich bestehende Lösungen für alle drei Elemente hatte. Die Aufgabe war also, die Handlungsbedarfe zu identifizieren, um die Performance auf das nächste Level zu bringen. Bezüglich Tools wurde schnell klar, dass SAP als Unterstützung für den Workflow in vielen Bereichen als hinderlich empfunden wird. Einzelne Bereiche oder Werke hatten sich Workarounds geschaffen, die die Datenintegrität beeinflusst haben.

Der Blick auf den Prozess hat gezeigt, dass sehr viele Änderungen parallel bearbeitet werden. Ein Abgleich mit den verfügbaren Ressourcen hat nicht immer stattgefunden und auch eine Priorisierung von Änderungsanfragen fand nur teilweise statt. Es war auch auffällig, dass ein nicht unbedeutender Teil von Änderungen bearbeitet und erst nach einigem Fortschritt und Aufwand erkannt wurde, dass die Änderungen nicht sinnvoll waren. Beispielsweise wurde eine mögliche Materialänderung intensiv ausgearbeitet, bevor man merkte, dass neue Maschinen und Infrastruktur für das Material in der Fertigung benötigt würden. In dem Fall wurde der Benefit des günstigeren Materials durch die Maschine aufgehoben. Die Erkenntnis kam aber erst, nachdem schon einiger Aufwand in die Änderung investiert worden war. Offensichtlich gab es also Potential bezüglich Bewertung, Transparenz und Priorisierung.

Rollen und Verantwortung waren beschrieben. Aber in der Anwendung und Umsetzung war Verbesserungsbedarf erkennbar. Es gab verschiedene Prozesse über die Produktlebenszyklusphasen. An den Übergängen gab es jeweils einen Übergang an Verantwortung, Datenhaltung und Vorgehen. In den Phasen gab es unterschiedliche Rollenkonzepte. Während im Produktentstehungszeitraum bis SOP ein klar definierter Projektleiter mit einem interdisziplinären Kernteam agierte, gab es diese Form der geführten interdisziplinären Zusammenarbeit für die Bearbeitung von Änderungen in der Serienphase nicht. Hier kam dem Projektleiter die Aufgabe zu, alle Bereiche und Experten direkt zu steuern, was häufig an die Grenze der Steuerbarkeit führte.

Im Fazit kann man es in einem Bild darstellen: Unser Kunde hatte eine funktionierende „Änderungsmaschine“, welche die Änderungen prozessiert. Die Maschine hat dabei aber immer wieder merkwürdige Geräusche gemacht und es war nicht immer klar, was die Maschine als Input benötigt bzw. verarbeiten kann und auch beim Ergebnis gab es ab und an Überraschungen. Das Projekt ist somit vergleichbar mit der Generalüberholung dieser „Änderungsmaschine“. Mit einem von allen Beteiligten getragenen Analyseergebnisse hat sich die cross-funktionale Projektgruppe an die Verbesserung gewagt.

Definition der Änderung

In einem ersten Schritt war es wichtig, eine gemeinsam getragene Definition für Änderungen zu finden, welche durch diesen Prozess abgedeckt werden sollen. Nachvollziehbarerweise hat jeder Fachbereich seine eigene Vorstellung, was eine Änderung ist und ab wann ein strukturiertes Änderungsmanagement Sinn macht. Dabei gilt es im Wesentlichen, die gute Abwägung zwischen Aufwand, Geschwindigkeit und Nutzen zu finden. In inhaltlicher Sicht war die wesentliche Abwägung, ob der Prozess nur technische Änderungen oder ganzheitlich alle Änderungen im Projekt und am Produkt abdecken soll. Am Ende setzte sich die Sicht durch, dass alle Änderungen im Lebenszyklus eines Produkts durch den gleichen Prozess laufen und in ein konsistentes Datenhalten münden sollten. Es wurde bewusst der Begriff „Project Change Management Process“ gewählt, um dieses Verständnis auszudrücken. Für eine bessere Handhabbarkeit wurde darüber hinaus festgelegt, dass eine Änderung nur dann vorliegt, wenn eine definierter oder freigegebener Projekt-/Produktzustand geändert wird. Somit sollen zukünftig alle Änderungen des Produkts und Prozesses abgedeckt werden, die Auswirkungen auf das „Magische Dreieck“ aus Kosten, Qualität und Zeit haben.

Auch die Frage nach der zeitlichen Anwendung wurde unterschiedlich bewertet. Der Konsens, dass ein Änderungsmanagement bis Ende der Produktion (EOP) erfolgen sollte, war schnell gefunden. Aber die Frage des Startpunkts und der Durchgängigkeit wurde intensiv abgewogen. Am Ende stand die Vereinbarung, dass das zukünftige Änderungsmanagement an dem Punkt startet, an dem ein erstes, verbindliches Angebot zum Kunden geht. Die zu treffende Abwägung betraf die Schnelligkeit, mit der Änderungen insbesondere in der Angebotsphase bearbeitet werden, um den Auftrag zu gewinnen, versus dem Mehrwert einer strukturierten Vorgehensweise und Datenhaltung. Die Vereinbarung, ein Prozessrahmenwerk zu erarbeiten, dass je nach Phase unterschiedlich komplexe Prozessderivate ermöglicht, und der Mehrwert einer durchgängigen Änderungshistorie haben dann zur Entscheidung geführt, einen einheitlichen Prozess und eine Dokumentationsbasis vom ersten Angebot bis zum Ende des Produkts zu verfolgen.

Prozess

Der Prozessrahmen selbst greift viele erfolgreiche und bestehende Elemente des Kunden wieder auf. Die größte Änderung besteht darin, vor dem eigentlichen Start der Ausarbeitung des Änderungsvorhabens eine cross-funktionale Grobbewertung durchzuführen. In dieser ist jeder Bereich aufgefordert den Aufwand abzuschätzen und kann auch aus der Sicht des Bereichs sein „no go“ platzieren. Auf Basis dieser Bewertung kann dann transparent entschieden werden, welche Änderungen wann angegangen werden. Über die frühe Transparenz wird es auch möglich Änderungen zu bündeln, um beispielsweise den Aufwand für Verifizierung und Validierung zu reduzieren. Verbesserungen in den Prozessdetails und die Schärfung der Meilensteine runden die Prozessüberarbeitung ab. Bei Freigaben wurde versucht, die Entscheidungen möglichst den verantwortlichen Teams zu überlassen. Ziel ist die Stärkung der Eigenverantwortung. Auch der Abschluss eines Änderungsprojekts wu rde dahingehend geschärft, sich pragmatisch über den Erfolg des Projekts, die Einhaltung der Ziele und auch mit den Erfahrungen auseinanderzusetzen, um für zukünftige Projekte zu lernen.

Die größte Änderung, die auch einer Weiterentwicklung des Mindsets der Mitarbeiter bedarf, ist wie bereits erwähnt sicherlich das Arbeiten mit Schätzungen in möglichst frühen Phasen. Hier liegt auch ein Schwerpunkt in der Umsetzung. Den Mitarbeitern erklären wir die Chancen und ermutigen sie, mit Abschätzungen zu arbeiten. Dem Management machen wir bewusst, dass Mitarbeiter nur schätzen werden, wenn die Fehlerkultur es auch zulässt, Fehler zu machen. Das Arbeiten mit Prämissen spielt dabei eine wesentliche Rolle.

Die Idee eines Prozessrahmens trägt der Erkenntnis Rechnung, dass im Lebenszyklus eines Produkts unterschiedliche Anforderungen an einen Änderungsprozess bestehen. In den frühen Phasen geht es darum, schnell das Konzept zur Reife zu bringen. Kurzzyklische Änderungen sind die Regel, ein Testen, Industrialisieren oder Validieren ist noch nicht notwendig. In der Serienphasen will jede Änderung gut abgestimmt und geplant sein, um die bestehenden Prozesse und das freigegebene Produkt nicht zu gefährden. Diese Anforderungen sind schwer mit einem „one size fits all“- Ansatz zu bedienen.

Die Lösung aus unserer Sicht ist einfach: Wir haben mit dem Prozessrahmen ein konsistentes Gebilde beschrieben, dass allen Anforderungen gerecht wird. Das Gesamtergebnis ist vergleichbar mit einem kleinen Produktentstehungsprozess, der alle Aspekte der cross-funktionalen Zusammenarbeit abdeckt. Je nach der konkreten Anforderung können aus dem Rahmen angepasste Prozesse abgeleitet werden. Bei erkennbaren Mustern können diese Prozessableitungen dauerhaft zur Verfügung gestellt werden, sogenannte „pre-tailored“ Prozessderivate. Im vorliegenden Fall gibt es feste Derivate zum Beispiel für Verlagerungen zwischen zwei Standorten oder Farbänderungen. Es wurde auch ein sehr kurzer Prozess für redaktionelle Zeichnungsänderungen fest abgeleitet. Und natürlich bietet der gesamte Prozessrahmen auch in jeder Anwendung die Möglichkeit, im Rahmen des Projektmanagements Aktivitäten bedarfsweise zu ergänzen oder im konkreten Fall auszublenden.

Jeder Prozess braucht klare Festlegungen, wer für welche Aktivität verantwortlich ist. Deshalb liegt hinter dem Prozess eine komplette RASIC-Matrix. Wir bedienen uns in diesen Fällen immer gerne der Beschreibungslogik des Kunden, damit das Ergebnis in das Gesamtbild passt. Wie in der Analyse erkannt, gab es kein durchgehendes Rollenmodell. In der Diskussion kristallisierte sich schnell der Wert von eindeutigen Bereichsrepräsentanten im Projektkernteam heraus. Nur so hat der übergreifend verantwortliche Projektleiter genug Ressource, um das gesamte Vorhaben zu steuern. So wurde dieser Ansatz durchgängig favorisiert. Für Neuproduktprojekte bedeutet dies lediglich eine Stärkung des vorhandenen Rollenmodells. In der Serie bedarf es aber der Installation von Bereichsvertretern. Am Ende steht damit die Erkenntnis, dass jeder Bereich auch Kapazität für Änderungen in der Serie aufbauen muss, um diese zu managen. Zusammen mit der Transparenz und der klaren Fokussierung auf aussichtsreiche Änderungen in der frühen Phase des Änderungsprozesses, stehen diesem Mehraufwand aber klare Vorteile gegenüber. Zukünftig kann bewusst entschieden werden, an welchen Themen gearbeitet wird und bei Bedarf kann mehr Kapazität investiert werden, wenn es Sinn macht.

IT Umsetzung

Für die IT-Umsetzung haben wir uns im Wesentlichen auf die Umstellung des Workflows von SAP auf JIRA und Confluence fokussiert. Aufgrund parallellaufender IT-Projekte zur Ablösung der bestehenden PLM- und ERP-Systeme, wurde in diesen Fällen sichergestellt, dass die Anforderungen aus dem Änderungsprozess klar hinterlegt sind. Mit der Einführung der Systeme werden weitere Synergien möglich.

Die Grundlage für die IT- Umsetzung im Toolset JIRA Confluence ist der beschriebene Prozess. Der Start für den Anwender im Toolset für den Project Change Management Process wurde bewusst versucht, einfach zu gestalten. Hierbei unterstützt das Tool JIRA Confluence in Form eines Service Desk Moduls , welches dem Anwender eine geführte Maske bereitstellt, in diesem er seine Anforderungen für die gewünschte Änderung beschreiben kann. Ziel war es, dem Anwender keinen komplexen Prozess zuzumuten, sondern einen einfachen Einstieg in den Änderungsprozess zu ermöglichen. Getreu dem Motto, „keep it simple und smart“.

So hat man sich mit dem Projektteam dafür entschieden, eine Handvoll Informationen für die Anforderung einer Änderung festzulegen. Diese sind im Wesentlichen, eine klare Information, was die Änderungen beschreibt. Des Weiteren, welche Komponenten, Zeichnungen und Referenzen davon betroffen sind. Eine kurze Beschreibung, welches Ziel oder erwartetes Ergebnis man sich von der beschriebenen Änderung verspricht, welchen Einfluss diese Änderung auf eine mögliche Dringlichkeit hat und welche möglichen Trigger für diese Änderung sein können. Diese Form soll es ermöglichen, jeder Änderung in der ersten Stufe der Bewertungen einen Raum zu geben und die Einstiegshürde etwas herunterzusetzen. Natürlich spielt hier auch eine einfache und benutzerorientierte Toolgestaltung eine Rolle, hier wurde sich an bereits bekannten Toolmasken orientiert.

Im zweiten Schritt, wird die vom Anwender erstellte Anforderung durch einen Change Administrator bewertet. Diese Bewertung ist wichtig, um im Vorfeld auszuschließen, dass es diese Änderung bereits gibt, oder ob es eine Möglichkeit gibt, hinsichtlich des beschriebenen Prozesses, die Änderungen in einem Tailoring Prozess schneller durchlaufen zu können. Auch hat der Change Administrator die Möglichkeit, die Änderungen auf Grund nicht vorhandener Dringlichkeit nach hintenanzustellen oder diese sogar abzuweisen. Nach dem der Change Administrator die Änderung bewertet und tailored hat, werden aus dem Toolset JIRA Confluence die beschriebenen Anforderungen der Änderung auf einer Confluence Page zusammengeführt. Dies dient in erster Linie der Übersichtlichkeit und bietet so einen schnellen Blick auf die Änderung, wo steht man und was ist noch zu tun.

Die Confluence Page beschreibt in Abhängigkeit des beschriebenen Prozesses, an welcher Stelle befinden wir uns in den Änderungen, welche Rolle im Prozess hat gerade welche Aufgabe und wer hat diese Aufgabe bereits erfüllt oder fehlt hier noch eine Bewertung oder ein Feedback. Aus Sicht der Toolset Gestaltung, haben wir für jede treibende Information im Project Change Management Prozess in JIRA Attribute erzeugt, welche von Anwender mit einer Eingabe zu belegen sind. Diese Eingaben sind so konfiguriert, dass diese über Texteingaben, Auswahlliste, Dropdown Menü oder Häkchen gesteuert werden können. Prozessaufgaben, welche eine klare Bewertung oder Entscheidung verlangen, sind Prozesstreiber, die notwendig sind, um von einem Prozess Gate in den nächsten wechseln zu können. Prozessaufgaben, welche aus einzelnen Teilaufgaben bestehen, wurde im Toolset in sogenannte Tasks und Subtasks aufgeteilt. Diese wurden dann aus Übersichtsgründen auf der Confluence Page wieder zusammen gemappt, um hier eine einfache Sicht auf den Stand im Prozess zu gewährleisten.

Der gesamte Durchlauf des Prozesses umfasst ca. 120 Tasks. Jeder dieser Tasks wird über den Change Admin oder einer Automatisierungslogik einer Rolle im Prozess zugewiesen. In den Übergangspunkten von einer Prozessphase zur nächsten, müssen vorgegeben Pflichtfelder oder Pflichtattribute ausgefüllt sein, sonst ist kein Wechsel in die neue Prozessphase möglich. Sollten Informationen fehlen oder diese nicht ausreichend beschrieben sein, gibt es im Toolset auch die Möglichkeit wieder in den Phasen auf Anfang zurückzuspringen. Zu jeder Zeit innerhalb der Änderung kann eine Auswertung in JIRA Confluence konfiguriert werden, da jedes erstellte Attribut im Gesamtprozess einen Betrag des Fortschritts beschreibt. Folgende Highlights aus dem Toolset JIRA Confluence wollen wir herausstellen:

  • Einfacher und Übersichtlicher Einstieg in den Prozess
  • Es gibt für jeden Schritt im Prozess eine Task oder Subtasks, welcher mit einer Rolle verknüpft ist
  • Überblick über den Verlauf der Änderung, durch eine konfigurierte Confluence Page pro Änderung
  • Toolset und Prozess sind im Doing und der Gestaltung eindeutig beschrieben
  • Einfaches erlernen, da JIRA Confluence im Unternehmen bereits genutzt wird

Umsetzung und Training

Auch der beste Prozess der Welt wird aber nur erfolgreich, wenn er gut implementiert wird. Als Berater mit besonderem Fokus auf Veränderungsmanagement ist uns das sehr wichtig. Unser Ansatz geht daher über reine Information und Trainings hinaus. Natürlich sind diese Elemente der erste Schritt, um Mitarbeiter und Management mit dem neuen Prozess vertraut zu machen. Dabei setzen wir auf eine Kombination aus erklären und präsentieren sowie gemeinsam erleben und erarbeiten. Spielerische Elemente wie zum Beispiel ein Rollenquiz bringen Schulungsteilnehmer dazu, das Gehörte direkt anzuwenden und fördern die Diskussion und das Verständnis. Natürlich gehören auch Spaß und Freude zum erfolgreichen Verstehen.

Neben Information und Training legen wir aber auch großen Wert darauf, die Bereiche auf dem Weg zur Umsetzung zu begleiten. Ein Angebot sind Implementierungs-Workshops zur Vertiefung des Verständnisses. Dabei wird hinterfragt, ob alle relevanten Standards, Methoden und Templates bereits vorliegen und nötigenfalls das Vorgehen zum Schließen der Lücken erörtert. Oft haben wir für die Übergangszeit auch eine „best practice“, die wir zur Verfügung stellen können. Darüber hinaus ist die konkrete Ausgestaltung der Rollen im Bereich inklusive der Festlegung, wer diese Rolle wahrnehmen wird, wichtig. Im konkreten Fall war die Diskussion in den Bereichen, wie zukünftig Schätzungen hergeleitet werden und die Definition eines gemeinsamen Verständnisses sehr wichtig, um den Mitarbeitern Orientierung und Sicherheit zu geben. Bestehende Gremien werden angepasst und Stakeholder geschult. Damit wird sichergestellt, dass in der Organisation spürbar eine Veränderung wahrnehmbar ist und bleibt.

Wie für jeden guten Berater ist es auch unser Ziel, die Inhalte nachhaltig zu verankern und sicherzustellen, dass die Organisation die Inhalte übernimmt und verinnerlicht. So achten wir schon in der Erarbeitung darauf, Mitarbeiter des Kunden intensiv einzubinden. In der Umsetzung ist uns wichtig, dass diese Kollegen auch die Ergebnisse vorstellen und mit uns argumentieren. So erkennt die Organisation, dass die Lösung von innen kommt. Wir begleiten die Mitarbeiter in der Umsetzung anfangs bedarfsorientiert und ziehen uns sukzessive zurück.

In Summe haben wir gemeinsam mit dem Kunden, seinen Änderungsmanagementprozess auf die nächste Ebene gebracht, um auch für zukünftige Herausforderungen gewappnet zu sein. Dabei haben wir unsere gesamte Fach- und Umsetzungskompetenz eingebracht. Darüber hinaus hat es sich ausgezahlt, dass unsere Berater mit ihrem OEM- und Zuliefererhintergrund die Stellhebel kennen und diese Expertise einbringen konnten.

Ihr Nutzen

  • Der Begriff Änderung muss eindeutig definiert und von allen Fachbereichen einheitlich verstanden werden
  • Änderungsanträge sollten von einem interdisziplinären Gremium bewertet werden
  • Der Änderungsprozess beginnt bei Entwicklungsstart und endet am Ende des Lebenszyklus
  • Änderungen müssen von interdisziplinären, eigenverantwortlichen Teams umgesetzt werden
  • Akzeptieren Sie Schätzungen. Jede Abschätzung ist besser als unbewertet fortzufahren. Über die Dokumentation der Prämissen werden Schätzung objektiv und besprechbar
  • Definieren Sie Prozessderivate für verschiedene Änderungsarten
  • Investieren Sie in ein erfolgreiches Veränderungsmanagement für eine nachhaltige Implementierung