„Good Enough“ als Teil des (deutschen) Produktinnovationszyklus

Die Wirtschaftswoche brachte in den vergangenen Wochen zwei Titelthemen, die einen wesentlichen Zusammenhang haben – untereinander und zum Thema „Product Lifecycle Management“: einerseits das Thema „Innovation“ (WiWo, Nr. 16 2014) und andererseits die Hinterfragung der These „Paradies Deutschland“ (WiWo, Nr. 17 2014).

In der Ausgabe „Innovation“ wird die deutsche Innovationslandschaft kritisch betrachtet. Das reicht von der vielzitierten Berliner StartUp-Szene, über den deutschen Innovationspreis bis hin zu diversen zukunftsträchtigen Projekten. Einigkeit zeigen die Autoren darin, dass Innovationen für Deutschland das Schlüsselelement für vergangenen und zukünftigen Erfolg sind. Klar, denn in der Massenproduktion einfacher Güter haben wir den Wettbewerb schon lange gegen Billiglohnländer verloren (oder die Führungsposition abgegeben?). Der Leitartikel „Paradies Deutschland“ knüpft genau hier an. Hinterfragt wird, ob das deutsche Wirtschaftsmodell auch zukünftig noch solche paradiesische Zustände ermöglicht. Denn so wird Deutschland derzeit in der Welt betrachtet: hohe Einkommen, bei vergleichsweise ausgeglichenem Reichtum in der Gesellschaft; geringe Arbeitslosigkeit; hoch-qualitative und vor allem hoch-innovative Produkte.

Eben zu letzter These stellen die Autoren die Frage, an die auch ich anknüpfen möchte: Ist es möglich, eine Volkswirtschaft immer nur mit Technologien der höchsten Stufe aufrecht zu erhalten? Und können wir es uns leisten, in irgendeiner Disziplin auf Rang zwei oder drei zurückzufallen?

Deutsche Produkte haben einen relativ kurzen Lebenszyklus. Dieser beginnt im Regelfall dann, wenn die zugrunde liegende Innovation gerade marktreif wird. Die Produkte sind zu diesem Zeitpunkt, wie man sie „made in Germany“ kennt: hoch-qualitativ, technikverliebt und mit allerlei Raffinessen ausgestattet. Dieses (Over-)Engineering der 110 %-Produkte findet seine Abnehmer und macht die deutschen Ingenieure berühmt. Allerdings endet der Produktlebenszyklus ziemlich schnell, sobald ein Early Adopter auf den Zug aufspringt und das Produkt ebenfalls produziert bzw. eine neue Technologie entwickelt wird (vgl. Grafik). Wer zahlt schon den hohen Preis, beispielsweise für eine 110 %-made-in-Germany-Solarzelle, wenn die 80 %-non-Germany-Solarzelle für die Hälfte zu haben ist? Diese Good-enough-Produkte machen den Technologieführer oftmals zu einem Nischenanbieter des Marktes, den sich die breite Masse der Nachfrager nicht leisten kann oder will.

Als Beispiel sei hier die Firma Claas genannt, die sehr erfolgreich hoch qualitative Maschinen für die Landwirtschaft herstellt. Ich durfte selbst erleben, welche hohe Wertschätzung die Marke von den Nutzern erhält. Allerdings muss hier bedacht werden, dass große Teile der in der Landwirtschaft arbeitenden Weltbevölkerung aus armen Ländern stammt. Ein hochgezüchteter Mähdrescher, und mag er noch so innovativ sein, ist hier nicht gefragt. Gefragt sind bezahlbare Produkte (vgl. hierzu auch: http://intranet.tuhh.de/aktuell/pressemittelung_einzeln.php?id=9098). Kurzum: die Technologieführerschaft und Innovationsstärke deutscher Unternehmen zieht nicht zwangsläufig einen langfristigen und breiten Markterfolg nach sich. Eben dieser wird aber für eine nachhaltig starke Wirtschaft benötigt.

Was also tun? Ein möglicher Ansatz ist es, Produkten nicht nur über den Produktlebenszyklus zu steuern. Wie beschrieben, wird dieser oft stark von außen beeinflusst. Viel eher sollte das Innovationsmanagement betrachtet werden. Dieses bietet dem Produktmanager die nötigen Werkzeuge, um Technologien gezielt für verschiedene Marktsegmente zu entwickeln. Beispielsweise kann ein innovatives Unternehmen seine „veralteten“ Technologien in die Zweitverwertung schicken. Nur weil die Technologie nicht mehr dem allerneusten Stand entspricht, ist sie oftmals für den breiten Markt noch mehr als ausreichend gut.

Good Enough

Ein abschließendes Beispiel eines Unternehmens, das mittels Technologiemanagement dem europäischen Preiskampf entgeht (vgl. http://www.just-auto.com/news/dacia-protects-renault-from-europes-price-war_id135135.aspx): Renault stellt seit 1898 PKWs her, die für die meisten Europäer der mittleren Preisklasse angehören dürften – für große Teile der Welt jedoch unerschwinglich sind. Renault hat dieses Problem durchaus erkannt und deswegen um die Jahrtausendwende den rumänischen Hersteller Dacia übernommen. Dank diverser Synergien ist es möglich, günstige Fahrzeuge herzustellen, die trotzdem den hohen westlichen Sicherheits- und Umweltanforderungen genügen – dank des Technologietransfers von hochpreisigen Renaultmodellen. Diverse Fahrerassistenzsysteme, höchsten Komfort oder die Technologie-Speerspitze stellen die Fahrzeuge von Dacia nicht dar. Für viele Menschen, und das schließt den Großteil der westlichen Bevölkerung explizit ein, ist das jedoch good enough.

Ein gutes Vorbild für deutsche Unternehmen, die sich gerne innovativ nennen, aber in der (Zweit-)Verwertung Nachhilfe nötig haben.

PLM-Einführung = Prozessoptimierung = Prozessharmonisierung?

Man stelle sich einmal folgende Situation vor, die sicherlich noch viel zu oft vorkommt: Ein mittelständisches Unternehmen mit einem Fokus auf technischen Produkten beschließt, ein PLM-System einzuführen. Nach anfänglicher Begeisterung aller Beteiligten sowie einer generellen Aufbruchsstimmung gerät das Projekt nach etwa der Hälfte der Projektlaufzeit ins Schlingern. An vielen Ecken kommt es zu Problemen: einige Features funktionierten nicht so, wie man sich das vorgestellt hat; Geschäftsprozesse und Software passen nicht zusammen. Kurzum: Die Akzeptanz durch die Benutzer ist eher gering.

Wer muss sich anpassen?Was ist passiert? Die Einführung einer PLM-Lösung zieht immer Anpassungen nach sich, denn keine Software entspricht zu 100 % der Unternehmensrealität. Und jedes Unternehmen hat seine eigenen Prozesse und Vorgehensweisen. Am Anfang steht also die Frage: Passt sich das Unternehmen der Software an oder passt sich die Software dem Unternehmen an? Diese Frage gilt wohl für jede Softwareeinführung – jedoch betrifft keine Software so viele integrale Unternehmensprozesse wie ein PLM-System.

Die wohl naheliegendste und vordergründig einfachste Lösung besteht darin, die Software anzupassen. Die implementierende Beratung wird also beauftragt in vielen Workshops herauszufinden, wie das Unternehmen tickt. Oftmals stellt sich bei diesen Workshops heraus, dass das Unternehmen eben nicht wie eine Uhr tickt bzw. jeder Mitarbeiter und jede Abteilung dieses Ticken anders interpretiert. Man einigt sich, da unter Zeitdruck stehend, auf eine Zwischenlösung und passt die Software an diese an. Inwieweit diese Anpassung an die zwangsharmonisierten Prozesse möglich ist, hängt natürlich ganz von der gewählten PLM-Software ab.

Insbesondere kleine Unternehmen gehen oft den zweiten Weg. Sie entscheiden sich zu Beginn des Projekts dafür, den vordefinierten Prozessen der PLM-Software zu folgen – denn im Regelfall basieren diese auf Best Practices wie z. B. CMII. Man erhofft sich also eine Optimierung der Unternehmensprozesse durch die Software.

Für den eingangs beschriebenen Fall ist es unerheblich, welchen Weg das Unternehmen gegangen ist. In beiden Fällen müssen sich Mitarbeiter, also Menschen, an neue Arbeitsweisen anpassen. Und im Bereich von PLM-Software gibt es wenig Spielraum für abteilungsinterne oder persönliche Sonderwege: Prozesse, Datenmodelle und Rechte sind festgeschrieben. Da die finalen Prozesse im Regelfall aber nie der Arbeitsweise des einzelnen Mitarbeiters entsprechen – im schlimmsten Fall sogar eher an die feindlich gesinnte andere Abteilung angelehnt sind – muss mit Widerstand und Ablehnung gerechnet werden. Ablehnung der neuen Prozesse – und damit auch der neuen Software.

Meine Erfahrung ist, dass die Unternehmen nie genau Weg A oder Weg B gehen – es ist immer ein Zwischenweg. Auch könnte ich keine Empfehlung für den einen oder anderen Weg geben. Wichtiger ist meiner Meinung nach, dass jedem, der sich mit PLM beschäftigt, Folgendes bewusst sein muss: bei der Einführung einer PLM-Lösung sollte der Projekt-Fokus auf den Menschen (Stichwort „Change Management“) liegen – erst danach folgen die technischen Finessen.

Oder, in Kurzform: PLM ist vieles, AUCH Software.

Was hat PLM gegen objektorientierte Datenbanken?

Die Basis eines PLM-Systems ist ohne Zweifel die verwendete Datenbank. Die Entscheidung über das Datenbankkonzept ist daher von großer Bedeutung und wird in einer frühen Design-Phase getroffen. Heutzutage existieren mehrere Konzepte von Datenbanksystemen

  • Relationale Datenbanksysteme (RDMS)
  • Objektdatenbanksysteme (ODBMS)
  • Dokument-orientierte Datenbanksysteme (NoSQL)

Die meisten Hersteller nutzen kommerzielle SQL-Datenbanksysteme wie z. B. Microsoft SQL-Server oder Datenbanken des Herstellers Oracle als Datenhaltungsschicht. Die relationalen Datenbanken sollen aber heute nicht im Fokus meines Blogartikels stehen. Viel interessanter ist die Frage, warum im PLM-Umfeld sehr selten Objektdatenbanksysteme genutzt werden.

Eine objektorientierte Datenbank ist eine Datenbank, deren Inhalt Objekte im Sinne der objektorientierten Programmierung sind. Schließlich werden alle Informationen bzw. Daten eines PLM-Systems in Objekten dargereicht, um die Stammdaten, Stücklisten, Dokumente und weitere PLM-Objekte zu speichern. Auch die Komposition oder Aggregation von Daten werden über Objekte realisiert dargereicht.

RDBMS und somit SQL sind de facto Industriestandard geworden. RDBMS wie Oracle, Postgres, MySQL, Informix etc. pp. bieten Transaktionsmonitore an. Eine Transaktion ist eine Folge von Operationen, die entweder alle vollständig oder gar nicht durchgeführt werden sollen. Diese Funktionalität wird auch von ODBMS angeboten und zusätzlich werden die folgenden generellen Probleme von RDBMS eliminiert:

  • Manuelle Umsetzung des Entwurfsmodells (ERM) in das Implementierungsmodell (methodisch sauber – aber schwierig zu erlernen)
  • Zersplitterung von „zusammengehörigen Daten“ durch Normalisierung; meistens in die 3. Normalform
  • Joins bei navigierendem Zugriff sehr aufwendig und kosten Performance
  • Probleme bei Änderung des Datenmodells wegen fehlender Kapselung
  • Impedance Mismatch (Unverträglichkeit der Speicherung von Objekten in relationale Datenbanken)

Warum sind also ODBMS mit den Eigenschaften einer objektorientierte Programmierung vorteilhaft? Dazu muss man sich immer wieder die Ziele von objektorientierter Programmierung vor Augen halten. Zum einen soll das Erstellen großer Programmsysteme mit komplexen Wechselwirkungen und zum anderen eine Vereinfachung einer nachträglichen Erweiterung der Software ermöglicht werden. Allgemeingültige objektorientierte Konzepte bringen darüber hinaus einen großen Vorteil. Datengetriebene Modellierung vereinfacht lokale Modellierung, eine Vererbung erleichtert nachträgliche Veränderung und die Datenkapselung durch Methodenzugriff schützt vor Seiteneffekten. Auch komplexe Datenstrukturen sind über Objekte realisierbar.

Wenn die Daten für ein PLM-System in Objekte gekapselt werden, warum sind keine Objektdatenbanken in gängigen PLM-Systemen im Einsatz?

Das Speichern von Java- oder .NET-Objekten ist ein schlanker und schonender Weg, um eine persistente Lösung zu implementieren.

Weiterhin erfordert eine RDBMS einen hohen „Overhead“ für das objekt-relationale Mapping (ORM), was zu einem erhöhten Bedarf an Ressourcen erfordert. Wird bei einem RDBMS das Schema in einem bestehenden System verändert, generiert das einen hohen Aufwand für die Anpassung der Klassen oder vice versa. In ODBMS werden dagegen die Daten „on the fly“ gespeichert und diese genannten Nachteile existieren nicht.

Im Unterschied zu RDBMS können in Objektdatenbanken komplexere Daten bzw. Objektebeziehungen zusammengefügt werden. Untergeordnete Objekte können darüber hinaus die Eigenschaften erben. Das ergibt ein komfortableres und erweiterbares Gesamtsystem.

Komplexe Querverweise zwischen Objekten können nur schwierig und fehleranfällig in einem relationalen Datenbanksystem modelliert werden. Beziehungen zwischen Objekten werden oft mit Hilfe von Fremdschlüsseln behandelt. Je nach Komplexitätsgrad können sich somit lange Ketten von Fremdschlüsselverknüpfungen ergeben. Dies führt zu kompliziertem und schwierig wartbarem Code.

Es gibt eine Abfragesprache für objektorientierte Datenbanken namens OQL, die sehr stark SQL ähnelt. Im Gegensatz zu den relationalen Datenbanken ist das Ergebnis einer OQL-Anfrage allerdings keine Menge, sondern eine Liste von Objekten, die den geforderten Kriterien entspricht.

Als Kompromiss oder als „best of breed“-Ansatz zwischen diesen beiden Konzepten werden objektorientierte Komponenten in relationale Datenbanken einbezogen. Ein Beispiel für diese objekt-relationalen Systeme ist Oracle 10g.

In PLM-Lösungen liegt die Handhabung und Modellierung der Objekte meist auf der Applikationsschicht bzw. im Applikationsserver. Dieser stellt dem Anwender die Objekte zur Verfügung und bildet diese auf der Datenbank auf eine relationale Struktur ab. Im Java-Umfeld wird meistens RMI genutzt, oder – um eine Interoperabilität zu gewährleisten – wird ein SOAP-Webservice zur Verfügung gestellt. Das Weglassen eines relationalen Objekt-Mappings ermöglicht die Darstellung auch von komplexeren Systemen. Ebenfalls ist die Erweiterbarkeit und Wartbarkeit so garantiert. Die Applikationsschicht reicht eins zu eins die Objekte und komplexe Strukturen weiter

Fazit:

Wir haben verschiedene Konstellationen, in denen die Verwendung einer Objektdatenbank eine natürliche Wahl darstellt. Leider haben sich Objektdatenbanken nicht in PLM-Systemen etabliert. Gründe dafür sind die noch schlechten Performancewerte bei der Manipulation von vielen Daten und die komplexen Strukturen und Beziehungen. Aber vielleicht setzen auch PLM-Systemhersteller zukünftig vermehrt auf objektorientierte Datenbanken.

Hier einige interessante Links zu Objektdatenbanken:

http://www.objectdb.com/

http://www.db4o.com/?src=ODBMS-sidebar

http://www.actian.com/products/versant

http://www.objectivity.com/dach/

http://www.mcobject.com/perst

Obsoleszenz und Tore

Liebe TSG 1899 Hoffenheim,

Phantomtorwie sagte schon der Volksmund: Wer den Schaden hat, muss für den Spott nicht sorgen. Aber es ist schon ein Treppenwitz der Geschichte, dass es ausgerechnet Euch mit dem ersten echten Obsoleszenz-Fall in 50 Jahren Bundesliga trifft. Und mit Obsoleszenz-Fall meine ich jetzt natürlich nicht die Abdankung eines Trainers oder Managers, da seid Ihr ja mit Herrn Gisdol weit von entfernt. Und auch Eure Mannschaft zählt mit einem Durchschnittsalter von 24,2 Jahren (Quelle: transfermarkt.de) eher zu den jüngeren in der Liga.

Nein, ich meine natürlich den Zustand Eurer Hardware, sprich Tornetze. Das entsprach am vorletzten Spieltag wohl nicht ganz den Anforderungen (dichthalten) der Aufsichtsbehörden (DFB). Im Prinzip ist das ja nichts schlimmes, kommt ja in den besten Familien vor. Und Euer Hauptsponsor ist eine dieser besten Familien, gerade was das Produktlebenzyklusmanagement auch von Tornetzen angeht. Aber nun gut, man kennt das ja mit dem Schuster und den Schuhen. So sei es mir aber gestattet, auf Artikel in unserem Blog zu diesem Thema hinzuweisen: Obsoleszenz-Management, Produkt-Service-Systeme und der Nutzen für den Kunden und Obsoleszenz-Management – Der kontrollierte Produkttod. Und falls Ihr auch mal über den Tellerrand schauen wollt, wir haben da auch andere IT-Lösungen für das Produktdatenmanagement: www.datasquare.de

Aber nun nüscht für ungut. Das Kießling‘sche Phantomtor wird so schnell nicht der Obsoleszenz anheimfallen, da kann man sich sicher sein. Wenn in 50 Jahren das erste dreistellige Jubiläum der Bundesliga ansteht, dann könnt Ihr davon ausgehen, dass diese Geschichte erzählt wird. Was ich mich dann frage: War das vielleicht sogar eine grandiose Marketingidee von Euch? Das Tor selbst ist in der Endabrechnung egal, Ihr werdet auch mit dem(n) fehlend(en) Punkt(en) mit Sicherheit nichts mit dem Abstieg zu tun haben und Leverkusen wir auch mit den gewonnen aus dem Spiel nicht Meister. Wenn dem so ist, werden wir mal schauen, wie wir dieses geniale Konzept ins tägliche PLM-Geschäft tragen können. Chapeau!

Zurück aus Berlin: Über die DOAG Applications 2013

Drei anstrengende Tage auf der DOAG Applications 2013, der Konferenz rund um die Oracle-Businesslösungen der Deutschen Oracle-Anwendergruppe (DOAG), in Berlin liegen hinter uns und ich möchte hier ein Resümee dieser Veranstaltung ziehen.

DOAG 2013 Applications

Ich bin seit August 2013 der Leiter der Enterprise PLM Community der DOAG und habe zum ersten Mal eine DOAG-Veranstaltung dieser Größenordnung als „Verantwortlicher“ mitgemacht.

Ich habe die Atmosphäre als sehr positiv wahrgenommen. Vor allem, weil es sich bei den DOAG-Veranstaltungen nicht um „Hurra-Veranstaltungen“ für Oracle handelt, wie sie häufig in der Branche bei anderen Herstellern üblich sind. Oracle wurde für viele Dinge gelobt, es wurde aber auch – und das hat der Glaubwürdigkeit dieser Veranstaltung sehr gut getan – deutlich gemacht, wo Oracle noch Arbeit vor sich hat.

Auch für mich persönlich habe ich viel Positives mitgenommen, wie beispielsweise die Vorträge von Herrn Prof. Dr. Eigner über die neuen Entwicklungen im Product Lifecycle Management sowie den Oracle-PLM-Strategievortrag von Denis Senpere, Vice President PLM Oracle EMEA. Der Fokus dieses Vortrages lag auf der Vorstellung der neuen Middleware „Fusion“. Kernthema war, dass Oracle in diesem Bereich nicht nach einer „allumfassenden PLM-Lösung“ strebt, sondern spezielle Solutions für bestimmte Märkte erarbeiten lässt. Das ist eine große Chance für die Lösungspartner, sich mit ihrem speziellen Wissen über die Märkte mit einbringen können. Außerdem ermöglicht dieses Konzept Oracle, nicht bis zur vollständigen Fertigstellung des „Großprojekts“ Fusion warten zu müssen, sondern zeitnah sukzessive einzelne Module und Lösungen für die jeweiligen Märkte zu veröffentlichen.

Einen Bericht über weitere interessante Vorträge finden Sie aus der DOAG-Website.

Abschließend möchte ich mich bei den Organisatoren der Konferenz für die gute Planung und Sicherstellung des Ablaufs bedanken. Es war eine rundum gelungene Veranstaltung!

Eines der vielen Highlights war sicherlich die Keynote von Alexander Huber über die Weltrekordbesteigung des 1.000-m-Granitfelsens „The Nose“ im Yosemite-Nationalpark in den USA innerhalb von 2 Stunden und 45 Minuten. Er hat sehr überzeugend dargestellt, dass mit absolutem Willen alles möglich ist.

Das sehe ich als unser Motto für die Oracle-PLM-Aktivitäten in 2014.

PLM auf der DOAG Applications 2013

Ich möchte den Blog heute dafür nutzen, Sie auf die DOAG 2013 Applications aufmerksam zu machen. Die europäische Konferenz für Anwender von Oracle Business Solutions findet vom 9. bis zum 11. Oktober 2013 in Berlin statt. Als neuer Vorsitzender der Enterprise PLM Community der Deutschen Oracle-Anwendergruppe (DOAG) werde ich Gastgeber der PLM-Themen sein.

DOAG 2013 Applications

Die DOAG 2013 Applications hat sich zur Aufgabe gemacht, Entscheidern im komplexen Marktumfeld der Business Solutions Orientierung zu bieten und zu helfen, die richtigen Weichen zu stellen. Sie informiert über bewährte Lösungen, beschreibt Geschäftsprozesse sowie Anwendungsszenarien. In Keynotes, Fachvorträgen und Workshops zeigt sie, wie diese Lösungen mittels Oracle-Applikationen und -Technologien implementiert und im Unternehmen eingeführt und genutzt werden.

Die beiden PLM-Streams bieten eine Vielzahl von Informationen und Insights aus der Praxis. Eine ideale Möglichkeit für alle PLM-Interessierten, einen umfassenden Überblick zu erhalten und vom geballten Wissen sowohl von PLM-Experten als auch von Oracle als Hersteller und seinen Partnern zu profitieren.

Am ersten Veranstaltungstag wird es unter dem thematischen Dach „Innovation & Produktlebenszyklus-Management“ Vorträge unter anderem zu Social Innovation Labs und zur Reduced Rework Initiative der GfKM sowie eine Keynote von Prof. Dr. Martin Eigner zur Zukunft von PLM geben.

Im Rahmen des Agile-PLM-Streams am 10. Oktober erhalten die Konferenzteilnehmer Informationen über die Oracle-Enterprise-PLM-Strategie, die Product-Compliance-Solution sowie den Einsatz von Oracle Agile PLM im Bereich Elektronik-Hightech am Beispiel eines konkreten Anwendungsfalles. Außerdem können sie im Hands-on-Workshop „Key Performance Indikatoren“ Oracle Product Lifecycle Analytics durch praktisches Arbeiten am eigenen Rechner anhand echter Fallbeispiele erleben.

Das detaillierte Vortragsprogramm finden Sie auf der Veranstaltungswebsite. Hier können Sie sich auch direkt anmelden. Dazu ein Tipp: Bis morgen gelten noch die Frühbucherrabatte!

Ich würde mich freuen, Sie in Berlin begrüßen zu können!

Obsoleszenz-Management, Produkt-Service-Systeme und der Nutzen für den Kunden

„Kundennutzen durch aktives Obsoleszenz-Management“ statt „Obsoleszenz-Management – Der kontrollierte Produkttod“? Vor einiger Zeit habe in dem genannten Blog-Artikel relativ kritisch das Thema Obsoleszenz-Management betrachtet – nämlich als Mittel einiger Hersteller ihre Produkte im richtigen Moment (kurz nach Ende der Garantiezeit) kaputtgehen zu lassen. Nochmal kurz auf das Wesentliche reduziert, ist Obsoleszenz-Management nichts anderes als die systematische Betrachtung der unterschiedlichen Lebenszyklen aller Einzelteile eines Produkts. Dass man das Wissen aus dieser Betrachtung auch für den Kunden nutzen kann, möchte ich im Folgenden beschreiben.

Ein Großteil aktueller Produkte sind sogenannte Produkt-Service-Systeme (oder etwas wenig marketingtechnisch: hybride Leistungsbündel). Der Hersteller verkauft also nicht nur ein nacktes Produkt, sondern bereichert dieses Produkt durch diverse Dienstleistungen. Beispiele dafür sind das iPhone (ohne die Dienstleistung iTunes eigentlich langweilig), Autohersteller (im Regelfall mit eigener Werkstattkette) und nochmals Autohersteller, aber umgekehrt (z. B. das Angebot von Mercedes/Smart namens Car-2-Go-Carsharing in Hamburg). Bei Letzterem bekommt der Kunde als primäre Leistung das Carsharing (Dienstleistung = Mobilität) statt des Autos (= Produkt). Die Entwicklung von reinen Produktherstellern zu Produkt-Dienstleistungsunternehmen ist meiner Meinung nach positiv zu bewerten. Die Hersteller konzentrieren sich auf den Kerngedanken des Produkts. Im Fall von Car-2-Go: Der Kunde will mobil sein und sich keine Gedanken um Versicherung, Wartung, Säuberung etc. (also jedes kleine Detail des Lebenszyklus) machen.

Perspektivenwechsel zum Unternehmen: Bis vor einiger Zeit war es ganz normal, dass jedes Unternehmen seine eigene Abteilung für Dinge wie Infrastrukturmanagement, Fahrzeugwartung und die Verwaltung technischer Anlagen hatte. All dies sind Aufgaben, die mittlerweile ausgelagert werden – sie gehören nicht zur primären Wertschöpfung der Unternehmen. Das Vorgehen ist das Gleiche wie vorher beschrieben. Auch ein Unternehmen will technische Anlagen für einen bestimmten Zweck nutzen – im Idealfall ohne sich um Wartung und ähnliche Probleme kümmern zu müssen. Was liegt also näher, als jener Firma mit der Betreuung der Anlagen zu beauftragen, die sie hergestellt hat? Schließlich weiß sie im Detail, welche Aufgaben welches Zahnrad übernimmt.

Und was hat das jetzt mit Obsoleszenz-Management zu tun? Obsoleszenz-Management ist ein Werkzeug für diese Aufgabe. Mittels der systematischen Betrachtung aller Module eines Produkts und der breiten Erfahrung kann der Hersteller jederzeit genau Auskunft darüber geben, ob demnächst damit zu rechnen ist, dass einige Teile ausfallen (Abnutzungsgrad etc.). Weiterhin kann im gleichen Moment eine Aussage darüber getroffen werden, ob dieses Teil noch zu beschaffen ist, oder ob es der Hersteller schon abgekündigt hat – insbesondere in der kurzlebigen Welt der Elektronik ein oft auftretender Fall. Im Idealfall bekommt der Nutzer der Anlage über deren gesamten Lebenszyklus regelmäßige Statusberichte. Denn sinnvolle Entscheidungen können nur auf Basis transparenter Situationen getroffen werden.

So profitieren Hersteller (weitere Dienstleistung, positives Image der Produkte, proaktiver Kundenservice, …) und Nutzer/Anwender (transparente Zustandsanalyse, geringere Ausfallzeiten, …). Meiner Meinung nach dürfte diese Möglichkeit der zusätzlichen Dienstleistung, insbesondere für eine Maschinenbaunation wie Deutschland, ein enormes Umsatz- und Service-Potential bedeuten!

Zwei Schritte vor, einer zurück: Agiles Vorgehen in PLM-Projekten

Im Bereich der Softwaretechnik hat sich schon lange ein agiles Vorgehen etabliert. Funktioniert dieser Ansatz auch bei der Durchführung von PLM-Projekten? Wo liegen die Unterschiede?

Es gibt PLM-Projekte, bei denen sich agiles Vorgehen direkt anbietet und sich als eine praktikable Variante für die erfolgreiche Projektabwicklung darstellt. Stellen Sie sich einen Fall vor, in dem der Kunde schnell PLM-Funktionalitäten benötigt, aber zunächst noch nicht in der Lage ist, seine Anforderungen im Detail zu formulieren, da vielleicht die eigenen Prozesse nicht ausreichend dokumentiert sind oder gar nicht feststehen. Das ist keine Seltenheit. Der Ansatz, hier zunächst eine langwierige Analyse interner Prozesse und Bedürfnisse durchzuführen, die zu einer vollständigen Spezifikation führt, scheidet hier aus, warum also nicht agil vorgehen?

Entnehmen wir doch einfach Elemente aus Scrum, einem agilen Vorgehensmodell aus der Softwaretechnik, und übertragen diese auf unser PLM-Projekt. Scrum beruht auf der Annahme, dass Projekte in der Regel zu komplex sind, um durchgängig planbar zu sein. Demnach werden Projekte in kleine planbare Schritte zerlegt, das sind die so genannten Sprints. Mehrere Sprints münden dann in kleinere Zwischenreleases, die jeweils einen abgestimmten voll nutzbaren Funktionsumfang enthalten. Der Kunde erhält seine Gesamtlösung also in mehreren Teilen.

Was benötigen wir hierbei vom Kunden? Mitarbeit und Vertrauen.

Der Inhalt eines jeden Sprints (das Sprintziel) wird mit dem Kunden gemeinsam definiert. Für den notwendigen Input ist die Verfügbarkeit relevanter Stakeholder und Key-User erforderlich. Diese versorgen das Projektteam nicht nur zur zum Sprintbeginn mit Informationen, sondern stehen auch währenddessen für Rückfragen zur Verfügung. Gemeinsam entwickelt sich ein Verständnis über die Bedürfnisse und zugrundeliegenden Prozesse. Letztendlich beinhaltet ein Sprint ein Stück nutzbarer Funktionalität, welches sich in einem überschaubaren Zeitrahmen, z. B. vier Wochen, realisieren lässt. Am Ende des Sprints präsentiert das Projektteam das Ergebnis des Sprints auf dem Testsystem des Kunden, wobei das Feedback des Kunden direkt in die Planung des nächsten Sprints einfließt. Mit jedem Sprint wächst das System.

Agiles Vorgehen in PLM-Projekten

Zu Beginn des Projekts muss der Kunde jedoch einen Vertrauensvorschuss leisten. Beginnt doch die Implementierung bereits sehr frühzeitig, ohne dass eine vollständige Spezifikation von der angestrebten Gesamtlösung vorliegen muss. Ebenso existiert für die Implementierung der Lösung kein Projektplan nach herkömmlichem Verständnis. Durch die Dynamik im Projekt ist es schlicht nicht möglich, Tasks für spätere Sprints zu definieren. Das ist für den Kunden zunächst ungewohnt.

Aber durch den engen Kontakt bei der Planung der Sprintinhalte und die regelmäßigen Sprintpräsentationen, sieht der Kunde sein System wachsen. Er erkennt, dass er die Inhalte selber steuern kann, denn sein Feedback fließt unmittelbar in die weiteren Planungen ein. Zudem entsteht im Laufe des Projekts eine Reihe von Dokumenten, welche parallel zu jedem Sprint fortgeschrieben werden und den aktuellen Stand der Implementierung wiederspiegeln. Das Vertrauen ist da.

Das ganze Konzept des agilen Vorgehens geht jedoch nur mit der passenden Infrastruktur des Entwicklerteams auf. Um die kurzen Sprint-Zyklen zu ermöglichen, kann z. B. auf ein automatisiertes Testen, ein automatisches Erzeugen von Auslieferungspaketen sowie eine automatische Installation der Lösung auf einem Zielsystem nicht verzichtet werden. Der manuelle Aufwand wäre hier viel zu hoch.

Der Unterschied von PLM-Projekten zu reinen Softwareprojekten ist an dieser Stelle aber recht groß und ausschlaggebend, denn PLM-Projekte beinhalten neben etwas Coding im herkömmlichen Sinne einen erheblichen Anteil an System-Konfiguration. Es muss ein Weg geschaffen werden, die relevante Konfiguration vollständig aus dem PLM-System zu exportieren und in einem Repository abzulegen, bzw. aus dem Repository zu holen und in das PLM-System zu importieren. Dies ist die Basis für das Erstellen von Auslieferungspaketen. Diese Vorgänge müssen ohne manuelles Eingreifen geschehen können. Das Problem ist nicht trivial und erfordert zu Beginn des Projekts eine gewisse Vorarbeit.

Sollen auch Zwischenreleases bereits produktiv genutzt werden, muss an dieser Stelle auch dem Thema Datenmigration Beachtung geschenkt werde, denn in jedem agilen Projekt unterliegen die Datenstrukturen einer hohen Wahrscheinlichkeit für Veränderungen.

Sind diese Hürden erst einmal genommen, so steht dem Einsatz eines Continuous Integration Servers nichts mehr im Wege. Ein solcher Server wird genutzt, um den Build-Vorgang, das automatisierte Testen der Lösung, sowie das Erzeugen von Auslieferungspaketen zu steuern.

Von nun an kann der agile Ansatz gelebt werden, denn es ist zu jeder Zeit möglich, auf eine aktuelle und getestete Version der Lösung zuzugreifen. Der Kunde kann sehr schnell und ohne großen Aufwand mit dem neuesten Stand seiner Lösung versorgt werden. Das wird gut ankommen.

Welche Erfahrungen haben Sie mit agilem Vorgehen in PLM-Projekten gesammelt? Ich würde mich über einen Austausch freuen.

Conflict Minerals Regulation – eine neue Anforderung an das Product Lifecycle Management

In letzter Zeit richtet sich auch in der Elektronikindustrie die Aufmerksamkeit vermehrt auf Conflict Minerals. Als “Dodd-Frank Section 1502″ im vergangenen Jahr verabschiedet, verpflichtet diese Vorschrift SEC-gelistete Firmen, Informationen über die Herkunft bestimmter Metalle bis spätestens 2014 zu melden. Es wird damit angestrebt, die Verwendung von Gold, Zinn, Wolfram und Titan, die in Minen im Kongo und Anrainerstaaten unter menschenunwürdigen Bedingungen gewonnen werden, einzuschränken.

Die Produkthersteller verlangen nun von ihren Zulieferern Auskunft, ob die verwendeten Rohstoffe aus der genannten Region stammen und in welchen Hütten die Erze verarbeitet wurden. Dazu wird meistens ein standardisierter Fragebogen verwendet (Download und weitere Informationen unter: http://eicc.info/Extractives.shtml). Auch Firmen, die nicht unmittelbar von der Conflict Minerals Regulation betroffen sind, werden über kurz oder lang gezwungen sein, entsprechende Daten zu sammeln und zu verwalten, da sie als Lieferanten ihren Kunden diese Informationen zur Verfügung stellen müssen. Es ist zu erwarten, dass zudem der öffentliche Druck durch Endkunden den Einsatz von Metallen zweifelhafter Herkunft weltweit generell erschweren wird.

Einkauf und Produktmanagement sind üblicherweise gefordert, für die bereits vermarkteten Produkte Daten zu erheben bzw. Auskunft zu erteilen. Je umfangreicher die Stücklisten der Produkte, umso schwierigen ist es, die Daten vollständig, aktuell und nachverfolgbar vorzuhalten. Für die Entwicklung neuer Produkte sollte schon in der Planungs- und Designphase sichergestellt werden, dass die vorgesehenen Bauteile aus Conflict-Minerals-Sicht unproblematisch sind, um spätere kostenintensive Änderungen zu vermeiden.

Wieder eine neue Anforderung an das Product Lifecycle Management: Sämtliche Informationen zu Conflict Minerals müssen – wie Compliance-Daten zu anderen Regulationen auch (z. B. REACH, RoHS) – im PLM-System integriert verwaltet werden. Die größte Herausforderung liegt dabei sicherlich bei der R&D-Abteilung. Für ein gutes PLM-System sollte die Conflict Minerals Regulation nur eine zusätzliche Regel sein, die einfach implementiert werden kann.

Hannovermessenachlese – Industrie 4.0 und PLM

Die diesjährige Hannovermesse hat vor gut einem Monat ihre Pforten geschlossen und nach der Nachbereitung ist es an der Zeit, ein Resümee zu ziehen. Wurden in Hannover neue Trends gesetzt und falls ja, welche waren dies? Dem Kontext dieses Blogs verpflichtet, werfe ich einen Blick durch eine „PLM-Brille“ auf die News dieser Messe.

Traditionell finden sich PLM-Hersteller, Dienstleister und Beratungshäuser auf der Leitmesse „Digitale Fabrik“ in Halle 7 zusammen. Das Leitthema und der allgegenwärtige Aufmacher an vielen Messeständen war in diesem Jahr das Schlagwort „Industrie 4.0“. Dieses Schlagwort wirft natürlich Fragen auf, zumal wir im ultraschnellen Internet gerade einmal bei Release 2.0 angekommen sind.

Laut Wikipedia soll der Begriff „Industrie 4.0“ die vierte Revolution des Industriezeitalters charakterisieren. Nach der Mechanisierung der Industrie mittels Wasser- und Dampfkraft (Release 1.0), der Massenproduktion durch Fließbandfertigung und den Einsatz elektrischer Energie (2.0) und dem Einsatz von IT in der Produktion zur weiteren Automatisierung (3.0) wird jetzt eine weitere Evolutionsstufe genommen. Unter dem Begriff „Industrie 4.0“ finden sich alle Strategien zusammen, deren Automatisierungsgrad durch Verfahren, Methoden und Prozesse zur Selbstoptimierung, Selbstkonfiguration, Selbstdiagnose bis hin zu selbstlernenden Systemen charakterisiert ist. Es geht also darum, Produktionssysteme zu befähigen, selbständig Entscheidungen zu treffen und nicht nur eine Meldung zu geben, wenn ein Parameter aus dem Ruder läuft. Das könnte zum Beispiel dazu führen, dass der Ausfall einer Maschine durch eine automatische Neuorganisation der Fertigungsstraße kompensiert wird. Diese Implementierung von intelligenten Entscheidungsregeln in Produktionssteuerungssysteme ist ein gewaltiger Schritt. Das zeigt zum Beispiel auch, dass das Bundeswirtschaftsministerium Fördermittel für die Forschung in diesem Bereich zur Verfügung stellt. Wobei man auch kritisch anmerken muss, dass gegenüber den Mehrkosten für Flughäfen, Opernhäusern und anderen Großprojekten diese Fördersumme sehr bescheiden aussieht.

Was hat jetzt aber dieser sehr produktionslastige Begriff „Industrie 4.0“ mit PLM zu tun?

Produktionssysteme können nur auf Basis von Daten Entscheidungen treffen. So etwas wie ein „Bauchgefühl“ für Maschinen überlassen wir dann lieber noch der „Industrie 5.0“. Produktrelevante Daten liegen in PLM-Systemen und müssen somit mit den Industrie-4.0-Systemen ausgetauscht werden. Neben einer eher methodischen Herausforderung an eine Kommunikation von verschiedenen IT-Systemen über eine Schnittstelle (Synchronisierung, Datenmapping etc.) gibt es hier noch eine technische Herausforderung. Produktionsnahe Systeme benutzen spezielle Kommunikationsprotokolle (PROFIBUS, PROFINET etc.). Die meisten PLM-Systeme kommunizieren über Webservices mit der Außenwelt. Hier muss sich von beiden Seiten aufeinander zubewegt und eine gemeinsame Sprache definiert werden.

Ein weiterer Punkt ist natürlich die Integration in PLM-Prozesse. Es kann also nicht nur darum gehen, dass Industrie-4.0-Systeme auf Daten in PLM-Systemen zugreifen und diese Daten nutzen, sondern es muss auch über den Schritt nachgedacht werden, die dann getroffenen Entscheidungen und Auswirkungen mit den PLM-Prozessen zu verzahnen. Auf der einen Seite könnte es notwendig sein, diese Änderungen in der Stückliste oder der Baseline aufgrund von Zertifizierungs- und Zulassungsverordnungen zu dokumentieren. Auf der anderen Seite könnten diese Änderungen auch wertvolle Hinweise für den Produktentwicklungsprozess einer Neu- oder Ableitungskonstruktion geben und somit zur Produktinnovation beitragen.

Je länger man über dieses Thema nachdenkt, umso mehr Gemeinsamkeiten und Schnittmengen zwischen der Industrie-4.0- und der PLM-Welt fallen einem ein. Ich würde mich über Kommentare zu diesem Blogartikel sehr freuen und stehe einer Diskussion offen gegenüber.

Ältere Beiträge «