PLM & ITIL® passen nicht zusammen … oder doch?

Veröffentlicht am 5. Oktober 2015, aktualisiert am 5. Oktober 2015 von Christoph

Nach meinem ersten Interview mit Guido Weischedel zum Thema Konfigurationsmanagement hat heute ein neuer Gast auf meiner virtuellen Couch Platz genommen. Wir wollen heute einmal einen Blick über den Tellerrand wagen und uns mit dem Thema ITIL® ein wenig näher beschäftigen. Bernd Ebert, freiberuflicher Berater und Trainer für die Prozess- und IT-Servicemanagement, hat sich bereit erklärt, mir Fragen dazu beantworten und vielleicht finden wir doch mehr Gemeinsamkeiten zwischen ITIL® und PLM, als man gemeinhin so denkt.

Herzlich willkommen Herr Ebert. Einige Leser werden Sie aus Ihren Projekten bereits kennen, aber können Sie sich für die anderen ein wenig vorstellen und ein paar Worte zu Ihrem Hintergrund verlieren?

Nach meinem Studium habe ich im Beratungsfeld „Digitale Prototypen“ (DMU) gearbeitet und anschließend in der Industrie als Experte für Produktdatenmanagement. Dabei ging es zum Beispiel um die Konfiguration von CAD Software und die Bereitstellung von Visualisierungsdaten. Im Zuge dessen kam ich in Kontakt mit ITIL® (IT Infrastructure Library) – über Fragen, wie wir mit Störungen umgehen, wie wir Änderungen an der Software ordentlich steuern und wie wir Projektprodukte in den Betrieb überführen. Das Thema gefiel mir gut; so habe ich es ausgebaut und mich 2008 selbständig gemacht. Seitdem berate ich Unternehmen bei der Einführung und Anpassung von Prozessen für einen optimalen IT Betrieb. Seit 2011 trainiere ich darüber hinaus ITIL® bis zum Expert und Projektmanagement nach PRINCE2®.

Welche Bedeutung steht hinter dem Begriff ITIL®?

ITIL steht für „IT Infrastructure Library“ und stellt eine Bibliothek von Best Practices dar. Es beschreibt verschiedene Prozesse und Aspekte eines IT Betriebs, die sich als wichtig und nützlich herausgestellt haben. ITIL umfasst derzeit fünf Kernbücher, die sich mit den Lebenszyklen eines IT Services auseinandersetzen. Diese umfassen die Strategie, das Design, die Transition, den Betrieb und die kontinuierliche Verbesserung von IT Services aus prozessualer Sicht, dem IT Service Management. Erinnert irgendwie an Produktlebenszyklen, oder?

Es sieht so aus. Aber PLM und ITIL® sind nicht zweimal das gleiche, nur anders beschrieben, oder?

Das sind sie nicht. Natürlich gibt es viele Parallelen: Beide haben das gleiche Ziel. Beide sind kein Selbstzweck. Sie unterstützen die Lieferung eines exzellenten Produktes. Und es gibt natürlich Ähnlichkeiten in den Inhalten, z. B. Konfigurationen steuern, Änderungen steuern und Produkte freigeben. Die Produkte selbst unterscheiden sich, und damit auch die Art der Unterstützung. PLM steuert häufig physikalische Produkte, die hergestellt und später verkauft werden und begleitet deren Entwicklung und Änderung. Dann gehen die Produkte außerhalb des PLM nutzenden Unternehmens in den Betrieb. Beim IT Service Management geht es um die Steuerung eines vitalen IT Services innerhalb des Lifecycle Management Betriebes oder IT Dienstleisters.

Dann gibt es also sowohl Gemeinsamkeiten als auch Unterschiede. Aber was haben sie nun miteinander zu tun?

Sehr viel. PLM nutzt Methoden und Systeme, um den Lebenszyklus von Produkten zu steuern. Dabei stützt sich PLM neben der Methodik wesentlich auf Infrastruktur, Software und intelligente IT Services. IT Service Management unterstützt wiederum diese PLM Systeme, indem es dafür sorgt, dass diese Umgebung zuverlässig funktioniert. Die Qualitätsansprüche, die an das Produkt gestellt werden, erfordern sorgfältiges Management. Das bedeutet, dass die genutzten Werkzeuge ebenso zuverlässig funktionieren und sorgfältig gepflegt werden müssen.

Können Sie dafür konkrete Beispiele dafür nennen?

Nehmen wir das PLM-System: Der Hersteller bringt in regelmäßigen Abständen Aktualisierungen heraus, der Kunde nimmt immer wieder mal kleinere oder größerer Anpassungen vor, Schnittstellen zu Datenbanken müssen angepasst werden etc. Jede dieser Änderungen birgt das Risiko der Fehlfunktionen, Ausfällen oder Aufwänden ohne sichtbaren Nutzen. Diese Risiken lassen sich nur durch ein gutes Zusammenspiel ordentlicher Prozesse und kompetenter Mitarbeiter reduzieren. Hier sind insbesondere das Konfigurationsmanagement (der IT), das Change Management und das Release- und Deployment gefragt. Evaluierung und Test gehört natürlich ebenso dazu.

Wie funktionieren diese Prozesse zusammen? Noch klingt das nicht ganz greifbar…

Das Basis stellt das Konfigurationsmanagement dar. Es bildet die aktuelle Version des freigegebenen, sich im Betrieb PLM ITIL befindlichen PLM Services ab, einschließlich Software, Hardware, Prozesse, Wartungsverträge etc. Wenn ich nun Änderungen, wie z. B. den Update des Systems anstoße, steuere ich das über das Änderungsverfahren an. Hier werden alle Änderungen aufgenommen und analysiert: Abhängigkeiten, Auswirkungen etc. Sobald ein Change autorisiert wurde, bündle ich die Changes in einem Release. Das Release beschreibt das Delta zwischen dem aktuellen und dem zukünftigen PLM Service. Das Release und Deployment macht sich nun Gedanken, wie etwas freigegeben wird, wie etwas ausgerollt wird, wann welche Trainings für wen durchgeführt werden und welche Downtimes benötigt werden. Das Ziel ist letztlich immer das gleiche: Innerhalb kürzester Zeit maximalen Nutzen bei geringstmöglichen negativen Nebeneffekten zu erzielen. Ohne eine saubere Steuerung über Releases und Konfigurationen, weiß das Change Management nicht, worauf es sich einlässt. Es ist dann eine zeitaufwändige Fahrt durch den Nebel, bei der der Passagier im Grunde nicht weiß, wo er ankommt. Wenn es sich um ein zentrales System handelt, was ein PLM System bei produzierenden Unternehmen immer ist, erzeuge ich ohne die Prozesse und Technologien ein erhebliches Risiko.

Müssen noch weitere ITIL® Prozesse eingeführt werden, um das PLM System zu betreiben?

Das kommt darauf an. ITIL® stellt erstmal nur die möglichen Best Practices vor. Ich führe also kein ITIL® ein – schon gar nicht um seiner selbst willen. Die erste Frage ist, wo Probleme gelöst werden sollen oder wo Verbesserungen notwendig sind. Dazu werden die Ursachen analysiert. Dann kann ich überprüfen, ob ITIL® eine geeignete und bewährte Prozess-Referenz liefert, an der ich mich orientieren kann, um die Lage zu verbessern. Und nur diese greife ich mir aus der Bibliothek heraus und passe sie für das Unternehmen an. Schließlich ist es selten so, das gar nichts vorhanden ist.

Haben Sie zum Schluss noch 3 Tipps, wie ich als Betreiber eines PLM Systems beginnen sollte, mich mit dem Thema auseinanderzusetzen?

Prozesse funktionieren nur so gut, wie die Menschen sie akzeptieren, die damit arbeiten. Also beginne bei gewünschten Veränderungen damit, die Prozessbeteiligten an einen Tisch zu holen.

Außerdem hilft es, Dinge auszuprobieren, um den Mehrwert erfahrbar zu machen. Schrittweise erfolgreiche Veränderungen umzusetzen ist darum oft besser, als alles auf einmal.

ITIL® Grundlagen zu kennen, hilft manchmal neue Ideen zu entwickeln und eigene Prozesse zu überdenken. Und mit dem innewohnenden Vokabular eine gemeinsame Sprache zu finden.

Herr Ebert, vielen Dank für dieses aufschlussreiche Gespräch und noch viel Erfolg bei ihren Projekten.

ITIL® is a Registered Trade Mark of AXELOS Limited.

IT Infrastructure Library® is a Registered Trade Mark of AXELOS Limited.

PRINCE® is a Registered Trade Mark of AXELOS Limited.

Visualisierung in Zeiten von grenzenloser Mobilität

Veröffentlicht am 24. Juni 2015, aktualisiert am 23. Juni 2015 von Christoph

Die Visualisierung von Konstruktionsdaten für verschiedene Einsatzzwecke ist ein alter Hut im PLM-Geschäft. Der Anwendungsfall, Konstruktionsdaten in einem leichtgewichtigen Format allen Anwendern entlang der Wertschöpfungskette zur Verfügung zu stellen, wird in allen PLM-Einführungsprojekten mit hoher Priorität behandelt. Angefangen von der „VerTIFFung“ oder PDF-Konvertierung von 2D-Fertigungszeichnungen bis hin zur performanten Visualisierung von großen Baugruppenstrukturen in einem Viewer. Studien, Benchmarks und Untersuchungen gibt es viele.

Themen wie das Digital Mockup (Design Reviews, Kollisionsuntersuchungen usw.), Datenaustausch (Zulieferintegration), Technische Dokumentation (siehe Blogbeitrag zur Maschinenrichtlinie) setzen den Rahmen der Benchmark für die Auswahl eines geeigneten Datenformats und der dazugehörigen Konverter und Viewer. Und natürlich sollen diese Werkzeuge nahtlos in einem PLM-System integriert werden. Die Lösungen dafür sind vielfältig und keine wirklichen Hindernisse mehr in einem PLM-Projekt.

Neben dem Hype um iPad & Co gibt es zum Beispiel auch in der Technischen Dokumentation eindeutig einen Trend zu mobileren und interaktiveren Anwendungen. Aus technischer Sicht bedeutet das, dass neben den klassischen Betriebssystemen (Windows, Linux, OS X) und der dazugehörigen Hardware auch neue Plattformen wie Android oder iOS und andere Endgeräte wie Smartphones und Tablets kommen. Und mit dem rein technischen Wechsel geht auch eine Paradigmenwechsel in der Kultur der Anwendung auf diesen Endgeräten einher. Ich muss mich ja nur selbst anschauen: Ohne Wasserwaage-App auf meinem iPhone hänge ich zu Hause kein Bild mehr auf.

Die Frage, die ich mit meinem Blogpost heute aufwerfen und diskutieren möchte: Ist der Siegeszug von iPad und Konsorten der Beginn zu einer anderen Art der Anwendung von PLM? Schauen wir in zehn Jahren zurück und fragen uns, wie man „früher“ ohne mobile Endgeräte und smarte Anwendungen überhaupt PLM machen konnte? So wie wir heute auf die Mainframe-Dinosaurier, C64 Datasetten und Lochstreifenleser zurückschauen? Kommentare sind herzlich willkommen.

Produktinnovation vs. PLM-Innovation

Veröffentlicht am 8. April 2015, aktualisiert am 7. April 2015 von Christoph

In meinem heutigen Beitrag möc PLM Innovation hte ich einmal die Perspektive wechseln und aus der Sicht auf das Thema PLM schauen, auf die es eigentlich ankommt. Es geht um das „P“ in PLM – das Produkt. PLM ist ja kein reiner Selbstzweck von Softwareentwicklern, sondern im Zentrum des Interesses steht das Produkt und nicht die Software, die zu dessen Verwaltung angeschafft wird. Somit stellt doch die Innovation des Produktes eine der größten Herausforderungen dar, mit denen PLM umgehen muss und für die dieser Managementansatz und dann natürlich auch die dazugehörigen Softwaresysteme weiterentwickelt werden müssen. Schnelle, einfache Anpassbarkeit und Flexibilität in der Datenmodellierung und Prozessabbildung ist dabei unabdingbar.

Nun könnte man allein über die Produktinnovation in einer dedizierten Branche seitenlange Artikel schreiben. Man denke dabei nur an Hybrid- oder Elektroantriebe im Automobilbereich oder an dieses „Internet“, von dem man in der letzten Zeit immer soviel liest und hört. Und welche Produkte kommen heute überhaupt noch ohne Software aus. Diese definiert in immer größerem Maße viele Produkte und nimmt nicht selten bereits einen höheren Stellenwert am Gesamtprodukt ein als die klassische mechanische Konstruktion. Der geneigte Leser mag mal sein Smartphone in die Hand – wie groß ist hier die Verteilung der Funktionalität zwischen den mechanischen Komponenten und der Software?

Eine weitere Innovation ist die Kopplung des physischen Produktes mit Serviceleistungen oder Dienstleistungen. Das trifft gerade in Branchen zu, in denen die Produkte sich ähneln, aber Service und Supportdienstleistungen ein klares Differenzierungsmerkmal vom jeweiligen Wettbewerb sind. Eine hervorragende Veröffentlichung dazu gibt es von der Fakultät Wirtschafts- und Sozialwissenschaften der Universität Hamburg, die sich die Sanitär-, Heizungs- und Klimatechnikbranche näher unter diesem Aspekt angesehen haben.

Ein dritter Trend ist eine immer fortschreitende Tendenz zur Individualisierung und Variantenvielfalt, um Kundenwünschen und Marktbedürfnissen gerecht zu werden. Paradebeispiel ist hier die Automobilindustrie. Nur mit dem papiernen Hochglanzprospekt ist doch keiner mehr in der Lage, in endlicher Zeit die Abhängigkeiten und die Vielfalt von Ausstattungslinien und Sonderzubehör aufzulösen und ein Mittelklassefahrzeug zu konfigurieren. Die Zahl der Varianten ist schier immens. Und der Verwaltungsaufwand beim Hersteller? Nennen wir es mal eine sportliche Herausforderung.

Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit. Ich habe ja bereits „angedroht“, dass noch weitere Artikel folgen werden.

Aber diese Produktinnovationen sollten von diesem Ding namens PLM unterstützt und nicht behindert werden. Zum einen verlangt das natürlich nach Strategien und Lösungen. Welche PLM-Methoden, PLM-Prozesse, PLM-Datenmodelle sind geeignet, um diese Produktinnovationen zu unterstützen? Oder sogar noch voranzutreiben, ein innovatives PLM-Umfeld für innovative Produkte und Lösungen zu schaffen. Zum anderen wird sich an dieser Messlatte die Spreu vom Weizen trennen. IT-Trends nur um des Hypes willen werden in der Versenkung verschwinden. Wenn sie aber für eine Umgebung für die Entwicklung von innovativeren Produkten bieten, dann werden sie Teil eines PLM-Portfolios werden.

Wo ist das Bauteil?

Veröffentlicht am 11. März 2015, aktualisiert am 10. März 2015 von Christoph

Ordnung ist das halbe PLM-Leben

In meinem heutigen Blog-Beitrag möchte ich mich einem altbekannten Thema widmen, das aber immer noch nichts an seiner Brisanz verloren hat: Der Identifizierung von Bauteilen mittels Nummernsystemen. Sicherlich ist das kein stylishes Web-2.0-Thema, aber ohne dieses solide Fundament gibt es keine beständige Konstruktion.

In Deutschland, dem Land der Ingenieure, ist die Diskussion über Nummernsysteme und Bauteilerkennung ganz und gar nicht neu. Sachmerkmalsleisten, Klassifizierungen, „sprechende“ Nummernsysteme und weitere Ordnungsmerkmale entsprechen unserer gründlichen Mentalität und Ordnungsliebe. Sie waren und sind die Grundlage für einen effizienten Entwicklungs- und Produktionsprozess.

Gerade sprechende Nummernsysteme zur Bauteilidentifizierung haben sich heute in fast allen Industrieunternehmen etabliert. Historisch gewachsene Codierungsalgorhythmen, z. B. für das Projekt, die Produktlinie, bestimmte Bauteilmerkmale usw., sind den Mitarbeitern in Fleisch und Blut übergegangen. Im Rahmen von PLM-Systemeinführungen werden aber häufig (durchaus zu Recht) diese althergebrachten Nummernsysteme hinterfragt. PLM-Systeme bieten die Möglichkeit, über Attribute, Klassifikationen und Relationen Bauteile eindeutig zu kennzeichnen. Eine eindeutige Kennzeichnung in Form einer Teilenummer ohne Systematik ist vollkommen ausreichend. Baugruppen können über attributgesteuerte Suchabfragen deutlich komfortabler und effizienter wiedergefunden werden als über die Codierung innerhalb eines sprechenden Nummernsystems. Des Weiteren stößt jedes Nummernsystem irgendwann an seine Grenzen und die Ausnahme- und Erweiterungsregelungen machen es meist nicht einfacher. Diese Einschränkung gibt es bei Metadaten (Attribute, Relationen) nicht – ein klares Plus für diesen Ansatz. Auf der anderen Seite ist außerhalb des PLM-Systems, zum Beispiel beim Datenaustausch mit Zulieferern ohne PLM-System, das sprechende Nummernsystem eine Möglichkeit, beschreibende Informationen den Bauteilen mitzugeben. Jede Medaille hat dann doch wieder zwei Seiten, die es zu beleuchten und zu bewerten gilt.

In den letzten Jahren eroberte sich aber noch ein ganz anderer Ansatz der Bauteilidentifikation und -suche die PLM-Welt. Teilenummern werden mehr oder minder vollkommen unwichtig, wenn man Bauteile nach ihrem originären Informationsgehalt suchen kann: Nach ihrer Gestalt und Geometrie. Softwarewerkzeuge zur geometrischen Ähnlichkeitsteilsuche erlauben es, auf Basis einer skizierten Geometrie nach ähnlichen Teile zu suchen. Dies kann auch erweitert werden, indem man in der 3D-Visualisierung anhand des Bauraums und der Gestalt die Teile findet, die man benötigt. Aus Anwendersicht ist das ein vollkommen anderer Ansatz: Die Bauteilidentifikation ist deutlich intuitiver, da nicht die Suchabfrage in Attribute codiert werden muss. Dann tritt auch die Bedeutung einer Teilenummer als Informationsträger für Metainformationen vollkommen in den Hintergrund.

Aus meiner Sicht wird in der Zukunft der Weg über eine geometrische Suche deutlich an Gewicht gewinnen.

Nichts ist ohne Risiko…

Veröffentlicht am 2. März 2015, aktualisiert am 23. Februar 2015 von Christoph

In meinem Artikel „Keine Maschine ohne Richtlinie“ habe ich die gestiegene Bedeutung der Risikobeurteilung im Zusammenhang mit der neuen Maschinenrichtlinie MRL 2006/42/EG angesprochen. Den heutigen Beitrag möchte ich nutzen, das Thema einmal im Detail zu betrachten und dabei genauer auf die Integration dieses Teilprozesses in den Konstruktions- und Fertigungsablauf einzugehen.

Die MRL fordert, dass eine Risikobeurteilung vorgenommen wird, um deren Ergebnisse in die Konstruktion und den Bau der Maschine einfließen zu lassen. Es ist nicht ausreichend, auf Gefahren und Risiken bei Inbetriebnahme und Benutzung einer Maschine hinzuweisen. Es gilt der Grundsatz, dass durch eine geeignete Konstruktion eine Gefährdung gar nicht erst auftreten darf. Damit ist die Risikobeurteilung kein Prozess, der erst bei der Freigabe der Bauunterlagen oder sogar erst nach Fertigstellung der Maschine durchgeführt werden kann. Die Risikobeurteilung beginnt bereits bei den ersten Designentwürfen und begleitet den gesamten Engineeringprozess des Maschinenherstellers und ist somit Teil der PLM-Strategie.

Aber was ist eigentlich ein Risiko und wie wird eine Beurteilung eines Risikos durchgeführt? Dafür gibt es neben der MRL noch weitere Normen. Es sei auf die DIN EN ISO 14121-1 „Sicherheit von Maschinen – Risikobeurteilung“ und die DIN EN ISO 12100-1 und -2 „Sicherheit von Maschinen – Grundbegriffe, allgemeine Gestaltungsleitsätze“ verweisen. In ihnen und natürlich in weiteren Normen sind Prozesse, Methoden und Checklisten beschrieben. Ein Beispiel ist die 3-Stufen-Methode nach DIN EN ISO 12100. Oberste Priorität hat die Vermeidung von Gefährdungen durch eine inhärent sichere Konstruktion. Sollte das nicht möglich sein, müssen technische Schutzmaßnahmen eingebaut werden. Risiken, die dadurch nicht vermieden werden können, müssen durch Benutzerinformationen klar kommuniziert werden. Aus einem anderen Blickwinkel betrachtet heißt das: Anleitungen und Warnschilder sind nicht dazu da, Konstruktionsmängel zu kompensieren. Das betrifft nicht nur den Betrieb der Maschine, sondern den gesamten Lebenszyklus inkl. der Verschrottung und des Recyclings.

Was bedeutet dies jetzt für die gesamte PLM-Strategie eines Maschinenherstellers? Sicher können auch die Forderungen der MRL ohne Softwareunterstützung umgesetzt werden. Aber gerade in diesem Bereich steckt ein hohes Optimierungspotenzial durch den Einsatz eines PLM-Systems. Die Abbildung und die Synchronisation von Unternehmensprozessen, die Zuweisung von Aufgaben an Prozessbeteiligte, die Verwaltung der entstehenden Daten, der klare Blick auf den Stand der Dinge durch Managementreports, die Beschleunigung der Durchlaufzeiten und die Sicherheit, gesetzlichen Anforderungen gerecht zu werden, all dies spricht für den Einsatz einer PLM-Software.