Warum das Pferd vom Schwanz aufzäumen?

Erst kommt die Pflicht des Produktdatenmanagements und dann als Kür das Product Lifecycle Management (PLM). Das war lange Zeit die meist praktizierte Best Practice der PDM/PLM-Implementierung. Aber war es auch die erfolgreichste Vorgehensweise? In Anbetracht vieler Projekte, die im Kleinklein von CAD-Integration, Datenmigration etc. stecken geblieben sind und nie oder erst mit Verspätung die weiter gesteckten PLM-Ziele erreicht haben, möchte man das manchmal bezweifeln. Continue reading “Warum das Pferd vom Schwanz aufzäumen?”

PLM muss große und kleine Fische unterstützen

Von PLM-Lösungen für den Mittelstand zu sprechen, verleitet leicht zu falschen Schlüssen. Mittelständische Unternehmen haben grundsätzlich die gleichen PLM-Anforderungen wie Großunternehmen, denn sie entwickeln ähnlich komplexe Produkte, meist in einer riesigen Zahl kundenspezifischer Ausprägungen. Sie sind als Zulieferer in komplexe globale Wertschöpfungsketten eingebunden und haben oft selbst Entwicklungs- oder zumindest Fertigungsstandorte in anderen Ländern. Und sie müssen in aller Regel dieselben Qualität- und Compliance-Anforderungen erfüllen wie ihre Auftraggeber. Deshalb brauchen sie keine funktional abgespeckten PLM-Lösungen, die sich im wesentlichen auf CAD-Daten- und Dokumenten-Management und vielleicht ein paar  Workflows beschränken, sondern das volle PLM-Programm. Nicht von ungefähr haben einige PLM-Hersteller ihre schnell geschnürten Mittelstandspakete wieder in der Versenkung verschwinden lassen.

bigfishNatürlich gibt es Unterschiede. Mittelständische Unternehmen haben normalerweise keine großen IT-Abteilungen, die ein monatelanges PLM-Projekt unterstützen können. Die Implementierung liegt meist in den Händen junger, engagierter Mitarbeiter aus den Fachabteilungen, die über wenig Erfahrung im Projekt- und Change-Management verfügen. Dafür sind, im Unterschied zu Großunternehmen, die Mauern zwischen den Abteilungen weniger hoch, so dass sich abteilungsübergreifende Prozesse einfacher reorganisieren lassen. Und die Geschäftsleitung ist erfreulich oft nahe am PLM-Projektgeschehen und stärkt dem Projektteam in kritischen Phasen den Rücken.

Was bedeutet das nun für die PLM-Hersteller und Ihre “Mittelstandslösungen”? Zunächst einmal brauchen sie kompetente Mitarbeiter mit Projekterfahrung, die den Kunden bei der Umsetzung der Projektschritte beraten und unterstützen und gegebenenfalls sogar die (Co-)Projektleitung übernehmen können. Agilität ist die Stärke des Mittelstands – das muss auch für das Projektmanagement gelten. Voraussetzung ist natürlich ein PLM-System das von der Software-Architektur und den Entwicklungswerkzeugen ein agiles Vorgehen bei der Implementierung zulässt.

Vorkonfigurierte Lösungen haben den Vorteil, dass sie sich schnell ausrollen lassen. Aber dieser Vorteil darf nicht durch mangelnde Flexibilität erkauft werden. Natürlich kann es zweckmäßig sein, die Prozesse im Zuge der PLM-Implementierung auf den Prüfstand zu stellen, aber wenn es sich um erprobte Prozesse handelt, die vielleicht sogar einen Vorsprung des Unternehmens im Wettbewerb ausmachen, muss die Software diese Prozesse abbilden können.

Was den Funktionsumfang anbelangt, so ist eine modulare Plattform mit Basisfunktionalität und ergänzenden Anwendungsmodulen die beste Gewähr für eine skalierbare PLM-Installation, die mit den Anforderungen des Unternehmens wachsen kann. Die Möglichkeit, Funktionalität nachzurüsten, beschleunigt den Rollout und verkürzt den ROI. Ich habe in den letzten Monaten verschiedene Unternehmen besucht, die das Projektmanagement zunächst nur als Struktur für eine projektorientierte Ablage der Daten und Dokumente produktiv genutzt haben, um erst im zweiten Schritt ein umfassendes Projektmanagement mit Terminverfolgung, Kostenkontrolle und Aufwandserfassung zu implementieren. In einigen Fällen werden inzwischen sogar Vertriebsprojekte im PLM-System angelegt, so dass der gesamte Produktentstehungsprozess von der Angebotsphase bis zur Auslieferung durchgängig unterstützt wird.

Interessanterweise sieht man solche umfassenden PLM-Implementierungen häufiger im Mittelstand als bei Großunternehmen. Das wiederum hängt meiner Einschätzung nach mit den flacheren Strukturen zwischen den Abteilungen und der größeren Aufmerksamkeit des Managements für das PLM-Thema zusammen. Wenn sich mittelständische Unternehmen für eine PLM-Implementierung entscheiden, werden die Projekte in aller Regel sehr konsequent durchgezogen. In diesem Sinne würde man sich mehr “Mittelstandslösungen” bei Großunternehmen wünschen.

Mit Big Bang zum Projekterfolg

Der Begriff Big Bang oder Urknall bezeichnet in der Kosmologie den Beginn unseres Universums – ein angeblich singuläres Ereignis. Angeblich deshalb, weil es vor schlappen 13,8 Milliarden Jahren ohne Augenzeugen stattfand (Einstein, Planck und Co. waren nur theoretisch anwesend) und möglicherweise gar nicht so singulär war. Irgendwo habe ich mal gelesen, dass es vielleicht nur der Moment der maximalen Verdichtung von Materie, Raum und Zeit eines früheren Universums war, das ab da wieder zu expandieren anfing.

In unserer bescheidenen PLM-Welt verwendet man den Begriff Big Bang gerne für ein Vorhaben, bei dem eine umfassende PLM-Lösung auf einen Schlag an allen Standorten eines Unternehmens und/oder in allen Abteilungen, die in den Produktentstehungsprozess involviert sind, scharf geschaltet wird. Soweit die Theorie. In der Praxis gehen solchen Big Bang-Projekten meist monatelange Vorbereitungen mit aufwendigen Tests voraus, um das Risiko eines Fehlstarts zu minimieren. Und wie bei der PLM-Einführung in mehreren Projektschritten ist auch der Urknall im Erfolgsfall nur der Startschuss für die kontinuierliche Expansion des PLM-Universums.

Image
Mit freundlicher Genehmigung Victor Habbick, www.FreeDigitalPhotos.net

Gegen den Big Bang gab es früher viele Vorbehalte, insbesondere bei mittelständischen Unternehmen, weil die Projekte sich über die Gebühr in die Länge zogen. Ihr Lieblingsrezept für die PLM-Einführung lautete: Think big, but start small. Das ändert sich allerdings mit der Weiterentwicklung der PLM-Software, die dank modularer Architekturen, vorkonfigurierter Komponenten und leistungsfähiger Werkzeuge für die Entwicklung kundenspezifischer Anpassungen einfacher und schneller mit einem vergleichsweise großen Funktionsumfang ausgerollt werden können als vielleicht noch vor zehn Jahren. De facto ist der wachsende Funktionsumfang der Implementierungen der Grund dafür, dass sich die Projektlaufzeiten im Schnitt nicht wesentlich verkürzt haben.

Ob sich ein Unternehmen für den Big Bang oder eine Politik der kleinen Schritte entscheidet, hängt von vielen Faktoren ab. Wichtig sind zum einen die Rahmenbedingen: Ein Unternehmen mit global verteilten Entwicklungsstandorten, die bei Entwicklungsprojekten zusammenarbeiten sollen, wird nicht umhin kommen, über den gleichzeitigen Rollout der PLM-Lösung an allen Standorten nachzudenken. Zum anderen hängt die Entscheidung davon ab, wie weit der Istzustand vor der PLM-Einführung und der angestrebte Sollzustand auseinander liegen. Größere Veränderungen der Prozesslandschaft erfordern, wenn nicht den Big Bang, so doch einen größeren Sprung, um zu verhindern, dass das Projekt auf halbem Wege im Morast des Tagesgeschäfts stecken bleibt. Wer den Produktentstehungsprozess umgestalten möchte, kann sich nicht damit begnügen, erst einmal testweise ein CAD-Datenmanagement im Engineering zu implementieren.

Viele Unternehmen scheuen den Big Bang, nicht unbedingt weil das damit verbundene Risiko höher ist, sondern weil sie es schwerer einschätzen können und lieber auf Nummer sicher gehen. Das gilt vor allem für Unternehmen, in denen das Management dem Thema PLM nicht die Aufmerksamkeit schenkt, die es verdient. Wer mit knappen finanziellen Ressourcen und einer eher zufällig zusammen gewürfelten Truppe aufmarschiert, wird sich nur in kleinen Schritten an PLM heranpirschen. Big Bang-Projekte erfordern den unbedingten Rückhalt der Geschäftsleitung: “Es muss jemanden geben, der ein so großes Projekt auch mal über die kritischen Klippen hievt”, sagte mir vor ein paar Wochen  der Geschäftsführer eines Unternehmens, das gerade mit einem Kostenaufwand von mehreren Millionen Euro seine komplette CAD/CAM- und PLM-Lösung ausgewechselt hatte.

PLM-Projekte brauchen außerdem ein starkes und motiviertes Projektteam, unabhängig davon, ob das Unternehmen sich für die Big Bang-Ansatz oder eine Implementierung in kleinen Schritten entscheidet. Dazu gehören auch kompetente Ansprechpartner auf Seiten des Softwarelieferanten, die in den Lage sind, die Prozesse des Kunden zu verstehen und in der Software abzubilden. Aus den Teammitgliedern eine schlagkräftige Mannschaft zu formen und auf sie ein gemeinsames Ziel einzuschwören, ist Aufgabe der Projektleiter, deren Geschick über Erfolg oder Misserfolg des Projekts entscheiden kann.

PLM überwindet kulturelle Barrieren

Die Vereinheitlichung von Systemen und Prozessen ist eine große Herausforderung bei PDM/PLM-Projekten und zugleich eine ihrer Zielsetzungen. Je größer und globaler die Unternehmen und je gewachsener um nicht zu sagen verwachsender ihre Strukturen, desto schwieriger erscheint diese Integrationsaufgabe. Zu den technisch-organisatorischen Hürden gesellen sich oft noch Sprachbarrieren und kulturelle Unterschiede. Dazu braucht man nicht in die Ferne zu schweifen – selbst unmittelbare Nachbarn unterscheiden sich in punkto Mentalität: Wo für uns “Piefkes” die Lage ernst, aber nicht hoffnungslos ist, ist sie für Österreicher allenfalls hoffnungslos, aber niemals ernst.

Die berühmte Verballhornung preußischen Denkens ist in der Alpenrepublik gelebte Wirklichkeit wie ich vor kurzem beim Besuch eines großen Österreichischen Konzerns feststellen konnte. Die Firma führt gerade im zweiten Anlauf PDM ein: Nicht mehr ein konzernweites System, sondern drei verschiedene Systeme, weil man erkannt hat, dass sich der Aufwand für die Vereinheitlichung nicht lohnt. Also hat man den Geschäftsbereichen die Systemwahl freigestellt, und einer hat sich für das Produkt entschieden, das bei der deutschen Tochtergesellschaft schon im Einsatz war.

Die Österreicher, das zeigte das Gespräch, sehen viele Dinge gelassener und handeln entsprechend pragmatisch, um nicht zu sagen hemdsärmelig. Das macht sie gerade so sympathisch. Wir Deutschen neigen dazu, unsere Prozesse viel stärker zu formalisieren, so dass sie sich wunderschön vereinheitlichen und in einer PDM-Lösung abbilden lassen. Natürlich sind wir dadurch in der Regel sehr effizient, was unsere Nachbarn durchaus anerkennen, aber wir verlieren auch ein Stück Spontaneität und Flexibilität. Dafür haben wir dann unsere Ad-hoc-Workflows.

Ein interessanter Aspekt bei dem standortübergreifenden PDM-Projekt des Österreichischen Unternehmens war, dass die harmonische Zusammenarbeit des Projektteams aus Mitarbeitern unterschiedlicher Ländern mehr zur Vereinheitlichung der Vorgehensweisen beigetragen hat als die jahrelangen Versuche, per ordre de mufti ein einheitliches System einzuführen. Das bedeutet nicht unbedingt das Ende aller Unterschiede, aber doch ein besseres gegenseitiges Verständnis dafür, warum die Kollegen an der anderen Standorten bestimmte Dinge so und nicht anders machen. Und auch die Bereitschaft, voneinander zu lernen. So werden die Österreicher bestimmte Zusatzfunktionen des Systems nutzen, die ursprüngliche für die deutsche Tochtergesellschaft entwickelt wurden.

Von anderen zu lernen, ist leider nicht unbedingt eine deutsche Tugend. Wir belehren lieber als dass wir uns belehren lassen – daran hat sich von Bismarck bis Merkel nicht viel geändert.  Dabei ließen sich aus dem ersten PDM-Anlauf der Österreicher durchaus Lehren für die erfolgreiche Abwicklung von großen IT-Projekten ableiten. Zum Beispiel dass die Harmonisierung kein Selbstzweck ist, sondern sich rechnen muss. Oder dass ein zentrales System, das es allen recht machen soll, leicht zu einem nicht mehr bedienbaren Moloch wird.

Gerade wir Deutschen sollten öfter mal die Schlagbäume hochreißen und hinschauen, wie die Anderen es machen. Wenn wir nämlich versuchen, Unternehmen in anderen Ländern zackzackig unsere Denk- und Arbeitsweisen überzustülpen, geht das meistens schief. Dafür gibt es prominente Beispiele, gerade aus der Automobilindustrie mit ihren straffen Strukturen: BMWs geplatzte Hochzeit mit Rover, Daimlers jahrelanger Ehekrieg mit Chrysler… Uns fehlt einfach das habsburgische Herrschaftswissen unserer Österreichischen Nachbarn, die sich vor kurzen in x-ter Ehe mit einem deutschen Unternehmen vermählt haben: Bella gerant alii, tu felix Austria nube – Kriege mögen andere führen, Du glückliches Österreich heirate.

Zielsicheres Projektmanagement

Vor ein paar Monaten habe ich ein kleines, mittelständisches Unternehmen bei der Analyse seiner Informationsflüsse unterstützt. Eine sehr erfolgreiche Firma, die elektroakustische Geräte für renommierte Kunden in der Luftfahrtindustrie, Verkehrstechnik und im Öffentlichen Dienst herstellt. Sie muss eine riesige Zahl an Produkten und Varianten managen, weil die Geräte immer wieder kundenspezifisch angepasst werden: Hier ein anderer Stecker, hier ein längeres Kabel, hier ein unterschiedlicher Schallwandler.

Die Mitarbeiter ertrinken in einer Flut an kleinen Aufträgen/Projekten, mit dem Erfolg, dass innovative Neuentwicklungen über dem Tagesgeschäft oft auf der Strecke bleiben. Und dass obwohl viele Projekte heute schon an der Entwicklung vorbei direkt in die Arbeitsvorbereitung wandern. Wie viele Projekte gerade laufen, in welchem Status sie sich befinden, wie rentabel sie sind und ob genügend Ressourcen für neue Aufträge frei sind, weiß eigentlich niemand so genau. Nicht einmal die Geschäftsleitung.

Image

Nach meiner Einschätzung ist das kein Einzelfall, sondern aufgrund der wachsende Produktvielfalt in vielen Unternehmen die Realität. Ohne eine effizientere Steuerung und Kontrolle der Projekte (Controlling) laufen diese Unternehmen Gefahr, den Wald vor lauter Bäumen nicht mehr zu sehen und sich im Unterholz der Projektabwicklung zu verirren. Ein einfaches Projektmanagement (PM), das alle Vorhaben mit Verantwortlichen, Terminen und geschätztem Reifegrad erfasst, würde schon für eine bessere Übersicht sorgen. Auf Dauer reicht es natürlich nicht aus, um Projekte erfolgreich durch die Untiefen eines kreativ-chaotischen Entwicklungsprozesses zu steuern.

Anders als bei einem Bauvorhaben, bei dem der Plan im Prinzip steht und “nur” noch umgesetzt werden muss, was aufgrund der Vielzahl der beteiligten Gewerke schon schwierig genug ist, entsteht der Plan bei einem Entwicklungsvorhaben ja erst: CAD-Modelle, Zeichnungen und anderen Unterlagen sind nicht der Input für, sondern der Output des Projektmanagements. Ohne Kenntnis der Arbeitsfortschritte und ihres Reifegrads kann man also nicht zuverlässig beurteilen, ob das Projekt hinsichtlich Terminen und Kosten im grünen Bereich ist oder gerade aus dem Ruder läuft. Das Projektmanagement muss Termine, Kosten und Qualität der Lieferobjekte (deliverables) gleichermaßen ins Lot bringen.

Ein solches, ergebnis- und produktorientierte Projektmanagement hebt die Trennung zwischen Projektmanagement und der eigentlichen Projektarbeit auf, was unter anderem bedeutet, dass jeder Projektmitarbeiter auch Steuerungsaufgaben übernimmt. Das erfordert zum einen ein Umdenken in der Organisation und die Etablierung einheitlicher Vorgehensweisen bei der Projektabwicklung, die flexibel anpassbar sein müssen, um dem Spannungsfeld zwischen Kreativität und Systematisierung gerecht zu werden. Zum anderen sind PM-Werkzeuge erforderlich, die die Steuerungsfunktionen in derselben Umgebung bereitstellen, in der die Projektmitarbeiter den Lifecycle und Reifegrad ihre Arbeitsergebnisse managen. Oder einfach ausgedrückt: Das Projektmanagement gehört ins PLM, und zwar nicht als nettes Zusatztool, sondern als zentrales Werkzeug für die Steuerung und Kontrolle von Entwicklungsvorhaben.