CONTACT Software Blog

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.

bigfish Natü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.

Auch PLM-Systeme kommen in die Jahre

Mit einem Textverarbeitungsprogramm, das nicht mehr auf dem aktuellen Stand ist, über die Notwendigkeit der Software-Aktualisierung zu schreiben, ist nur scheinbar ein Widerspruch. Während man bei Word & Co. als normaler Anwender durch einen Versionswechsel kaum noch Produktivitätszuwächse erzielt, dafür aber tagelang damit beschäftigt ist, vertraute Funktionen wiederzufinden, die ein agiler Software-Entwickler aus unerfindlichen Gründen dort versteckt hat, wo man sie nicht suchen würde, kann die Aktualisierung einer Unternehmensanwendung einen Produktivitätsschub auslösen. Insbesondere wenn es sich um eine historisch gewachsene IT-Lösung handelt.

Alt- oder Legacy-Systeme sind strukturell zukunftsunfähig, weil sie meist auf einer veralteten Technologie basieren, inkompatibel zu anderen Unternehmensanwendungen sind und sich nicht oder nur mit einem hohem Aufwand an die aktuellen Anforderungen anpassen lassen. Ihre Aufrechterhaltung bindet nicht nur Personal mit Know-how, das immer schwerer zu finden bzw. zu ersetzen ist, sondern auch finanzielle Ressourcen, die nicht mehr für Investitionen in die Modernisierung der IT-Landschaft zur Verfügung stehen. Darauf hat kürzlich die Management-Beratung Lüdendonk in einem Whitepaper über die Software-Modernisierung hingewiesen, das ich zur Lektüre empfehle.

Mit freundlicher Genehmigung von dan, www.FreeDigitalPhotos.net

Obwohl sich die IT-Verantwortlichen der Tatsache bewusst sind, dass die Modernisierung der Software-Landschaften eine Notwendigkeit ist, halten sie an ihren Legacy-Systemen oft genauso zäh fest wie ich an meinem alten Texteditor. Das liegt daran, dass diese Systeme sehr viel Unternehmens-Know-how beinhalten und oft so eng mit anderen IT-Lösungen verknüpft sind, dass sich die Auswirkungen einer Modernisierung nur schwer abschätzen lassen. Dies umso mehr als ihre Entstehungsgeschichte oft nicht sauber dokumentiert ist. Die Experten von Lüdendonk empfehlen dennoch eine planvolle Modernisierung der Software-Landschaft und stellen dafür verschiedene Strategien vor.

Zugegebenermaßen haben neue Software-Programme manchen Bug, aber sie sind in den letzten Jahren deutlich zuverlässiger geworden. Die Furcht vor Kinderkrankheiten sollte deshalb kein Grund sein, seine Software-Installation nicht zu aktualisieren. Gerade moderne PLM-Systeme bieten heute standardmäßig einen Funktionsumfang, der vor einigen Jahren nicht oder nur mit einem hohen Anpassungsaufwand und Zusatzprogrammierungen erreichbar war. Die bestehenden IT-Lösungen abzulösen, hat den Vorteil, dass man sie funktional wieder näher an den Standard heranführen kann. Das reduziert nicht nur den Aufwand für Wartung und Pflege der Installation, sondern erleichtert auch Software-Updates. Davon abgesehen erlauben die heute zur Verfügung Programmierwerkzeuge eine einfachere und schnellere Zusatzprogrammierung, falls doch einmal kundenspezifische Erweiterungen erforderlich sind.

Außerdem werden die Architekturen der PLM-Systeme nicht zuletzt auch unter dem Druck von Initiativen wie dem Codex of PLM Openness offener, was ihre Integration in bestehende IT-Landschaften vereinfacht. Alle diese Faktoren haben zur Folge, dass die Kosten für Anschaffung und Betrieb einer PLM-Lösung tendenziell sinken. Deshalb sollten gerade Unternehmen mit einer älteren und stark kundenspezifisch angepassten PLM-Lösung ernsthaft über eine Modernisierung ihrer Installation nachdenken. Die Lebensdauer der Alt-Systeme zu dehnen, hat Lüdendonk zufolge negative Auswirkungen auf die Gesamtkostenstruktur der IT: “Je mehr Zeit und Geldmittel […] die Unternehmen für die Wartung älterer Software aufwenden müssen, desto weniger bleibt für die Realisierung zukunftsweisender Projekte übrig”, so die Autoren des Whitepapers.

In den letzten Monaten habe ich eine Reihe von Unternehmen besucht, die sich aus dem einen oder anderen Grund für eine Modernisierung ihres PLM-Systems entschieden haben. Der damit verbundene Aufwand war zum Teil nicht unerheblich, weil sie im Zuge der Modernisierung auch ihre Entwicklungsprozesse umstrukturiert haben. In allen Fällen profitierten die Unternehmen jedoch von dem erweiterten Standard-Funktionsumfang ihres PLM-System, insbesondere in punkto Projektmanagement, der wesentlich einfacher zu implementieren war als die kundenspezifischen Anpassungen der Vergangenheit.

Warum einfach, wenn’s auch kompliziert geht

Deutschen Ingenieuren wird oft vorgeworfen, dass sie zum Over Engineering neigen. Leider nicht ganz zu Unrecht. Das ist aber nicht allein ihre Schuld, sondern auch die ihrer Vorgesetzten (meist selber Ingenieure), die nicht immer in der Lage sind, den ihren Mitarbeiter in die Ingenieurswiege gelegten Kreativtrieb zu bremsen oder wenigstens in die richtigen Bahnen zu lenken. (Oh, ich sehe schon, dass ich mir mit diesem Blogbeitrag keine Freunde machen werde:-)).

Deutsche Unternehmen, die zum Beispiel eine einfache (und kostengünstige) Produktvariante für den asiatischen Markt entwickeln wollen, überlassen das nicht selten ihren polnischen oder tschechischen Ingenieuren. Und das nicht etwa deshalb, weil die weniger kosten (das natürlich auch), sondern weil sie eher in der Lage sind, sich weniger komplexe Lösungen auszudenken. Manchmal werden diese Produkte sogar reimportiert, weil die Unternehmen plötzliche entdecken, dass es auch in unserer entwickelten Welt Bedarf für einfache und preisgünstige Lösungen gibt. Die Amerikaner nennen diesen Trend Reverse Innovation.

Mit freundlicher Genehmigung supakitmod, www.FreeDigitalPhotos.net

Natürlich muss man zur Verteidigung der westlichen Welt und ihrer Ingenieure sagen, dass sie letztlich nur das entwickeln, was wir als (deutsche) Konsumenten für teures Geld zu kaufen bereit sind. Vielleicht sollte ich die Klammer weglassen, denn ich bin der festen Überzeugung, dass Phänomene wie die Mass Customization, das heißt die kundenindividuelle Konfiguration (wenn nicht gleich Entwicklung) von in Serie zu fertigenden Produkten, eigentlich eine Erfindung deutscher Ingenieure ist. So wie übrigens auch die deutsche Antwort auf die damit verbundene, fertigungstechnische Herausforderung: Industrie 4.0.

Beweise? Fragen Sie doch mal bei einem der deutschen Premium-Automobilhersteller nach, ob er nordamerikanischen oder asiatischen Kunden die gleichen Konfigurationsmöglichkeiten für seine Fahrzeuge einräumt wie seinen deutschen Kunden? Pustekuchen. Da wird oft schon der langen Lieferzeiten wegen mit vorkonfigurierten Paketen gearbeitet.

Richtig ist aber, dass die Ingenieure in kaum einer Branche so kreativ sein dürfen wie in der globalen Automobilindustrie. Trotz modularer Längs- und Querbaukästen und anderer Anstrengungen zur Eindämmung der Variantenvielfalt werden viele Dinge in einer zumindest für Laien unfassbar großen Varianz entwickelt, was den allseits bekannten Rattenschwanz an Kosten für Fertigung, Einkauf, Lagerhaltung und Verwaltung der eigentlich redundanten Teile nach sich zieht.

Ein schönes Beispiel dafür habe ich neulich beim Besuch eines bekannten Herstellers von Kabelbindern und -befestigungssystemen entdeckt. Das Unternehmen hat einen innovativen Befestigungsclip für Kabelsätze entwickelt, der in ovale Löcher unterschiedlicher Größe in unterschiedlichen Fahrzeugmarken und -modellen passt. Warum, fragte ich mich, müssen die Löcher für die Befestigungen der Kabelsätze eigentlich unterschiedlich groß sein? Könnte man sich da nicht auf einen Standard einigen oder – besser noch – einfach die Vorgaben der Verkabelungsspezialisten übernehmen? Die wissen doch am besten, welche Kräfte so eine Befestigungssystem aushalten muss. Aber nein, es muss eine kundenindividuelle Lösung sein.

Möglicherweise liegt es daran, dass die Ingenieure nicht wissen, welche Lösungen es von der Stange gibt und wie viel Geld sie durch ihre Verwendung sparen könnten. Und wie viel Zeit, denn geprüfte Komponenten müssen nicht mehr aufwendig abgesichert werden, bevor sie verwendet werden können. Dazu bräuchten sie aus ihrem PLM-System heraus den Zugriff auf leistungsfähige Bauteil-Bibliotheken, in denen sie anhand technischer Parameter die passenden Kaufteile suchen und am besten gleich verbauen können. Und die sie auch darüber informieren, welche ähnlichen Komponenten auf Lager sind und alternativ verbaut werden könnten. Solche Bibliothekssysteme gibt es zwar, aber sie werden offensichtlich noch zu wenig genutzt. Sonst müssten sich die Ingenieure das Leben nicht so schwer machen.