PLM-Fauxpenness hat keine Zukunft

PLM-Blogger Oleg Shilovitsky, der sich wiederum auf einen Beitrag von Monica Schnitger bezieht, verdanke ich die Entdeckung eines wundervollen Begriffs, der ursprünglich in der Open Source Community geprägt wurde: Fauxpenness. Er bezeichnet eine Software, die vorgibt Open (Source) zu sein, aber es nicht wirklich ist. Der Begriff lässt sich prächtig auf die PLM-Hersteller und ihre Produkte übertragen, die aller Lippenbekenntnisse und der Unterzeichnung des Code of PLM Opennness (CPO) zum Trotz noch längst nicht so offen sind, wie sie sein müssten, um den wachsenden Kundenanforderungen in punkto Interoperabilität zu genügen. Continue reading “PLM-Fauxpenness hat keine Zukunft”

Data Science verstehen – Revolutionäres Potential aus vier Megatrends!

 Wir befinden uns an der Schwelle zu einem neuen Zeitalter, weil verschiedene Strömungen zusammenkommen und damit ein einzigartiges Umfeld schaffen. Vieles (manche würden sagen: alles) wird digital. Damit ist auch das Interesse an den Themen Datenanalyse und -exploration – also Data Science – enorm gestiegen. Data Science ist der Konvergenzpunkt von vier Megatrends, die die letzten Jahren dominiert haben und auch die kommenden dominieren werden: Cloud Computing, IoT, Big Data und algorithmische Analyse.

Was sind die Gründe für das Zusammenkommen verschiedener Strömungen und damit eines neuen, einzigartigen Umfeldes?

  1. Zum ersten Mal in der Geschichte der Künstliche Intelligenz, die in den 1950er Jahren als Disziplin begonnen hat, steht die notwendige Rechenleistung zu niedrigen Kosten zur Verfügung, um praktische Probleme mit den schon länger verfügbaren Algorithmen zu lösen.
  2. Die Algorithmen für das Machine Learning sind deutlich verbessert worden und können nun mit vertretbarem Aufwand für praktische Probleme eingesetzt werden.
  3. Die Popularität von Data Science trägt dazu bei, seine Methoden aus den akademischen Zirkeln in die Breite zu tragen, so dass eine große experimentierfreudige Community eine rapide Weiterentwicklung fördert.
  4. Heutzutage gibt es vor allem durch das Internet, die sozialen Netzwerke und die großen Einkaufsplattformen einen Datenschatz in nie gekannter Größenordnung, der auf seine Auswertung wartet.
  5. Das Internet der Dinge wird für weitere Datenströme sorgen, die zu neuen Geschäftsmodellen führen, die mit Hilfe von Data Science erschlossen werden.

Diese Faktoren haben dazu beigetragen, Data Science als eigene wissenschaftliche Fachdisziplin und Ergänzung zur klassischen Statistik zu etablieren. Data Scientist mit ihren Fähigkeiten im Bereich Programmierung, Statistik und neuerer Algorithmik bringen die erforderliche Expertise mit, um die heutigen Möglichkeiten der Datenanalyse gewinnbringend zu nutzen. Die verschiedenen Data Science Techniken lassen sich nach algorithmischen Verfahren oder nach dem Einsatzzweck grob so kategorisieren:

  • Regression
  • Klassifikation
  • Anomalienerkennung
  • Clustering
  • Reinforcement Learning

Auf der einen Seite der bestehenden Software-Landschaft gibt es bereits sehr spezifische Lösungen für gut umrissene Probleme, zum Beispiel im Einzelhandel oder in der Finanzindustrie. Am anderen Ende des Spektrums stehen die Anbieter von Software-Paketen, die ein abgestimmtes Toolset für den Spezialisten im Bereich Data Science zur Verfügung stellen.

Die meisten Lösungen basieren dabei auf Open Source Software. Im Bereich Toolsets dominieren vor allem zwei Sprachen den Markt: R and Python. Python hat sich zur Standardsprache für Data Scientists entwickelt, vor allem im Bereich Machine Learning.

Die gewaltigen Investitionen und die anziehenden Umsätze von großen Commodity-Plattformen wie Amazon, Microsoft und Google zeigen: Die Megatrends Cloud Computing, IoT, Big Data und algorithmische Analyse bestimmen bereits heute oder in naher zukunft die Geschäftsprozesse, und dass bis in die letzten Winkel. Für Unternehmen, die dieses Thema näher interessiert, hat CONTACT ein neues Data Science White Paper herausgebracht. Dies kann hier heruntergeladen werden.

Neue Servicekonzepte braucht die Bahn

In den letzten Wochen habe ich in Deutschland Urlaub gemacht – jawohl, das kann man, ohne vom Wetter reden zu müssen, was prächtig war. Es gibt ja auch spannendere Themen: Alle reden von der Deutschen Bahn, die sich zum Sinnbild für die neuen deutschen Untugenden entwickelt: Fortwährende Unpünktlichkeit, technische Unzuverlässigkeit und mangelnde Servicefreundlichkeit. Gut, letztere ist keine besonders neue Untugend und auch keine Erfindung der Bahn.

Ich war viel mit dem Zug unterwegs, mit Kindern und großem Gepäck, was der Urlaubslaune nicht immer zuträglich war, obwohl wir das Stellwerk Mainz weiträumig umfuhren. Verspätungen, verpasste Anschlusszüge, Zugausfälle – das ganze Programm an Foltermaßnahmen, mit dem die Bahn ihre Kunden tagtäglich malträtiert. Und weit und breit kein Kundendienstmitarbeiter zu sehen, der einem erklärt, wie man wenigstens das zum Fenster rausgeworfene Geld für die Sitzplatzreservierung wieder bekommt. Einziger Bahnbonuspunkt: Kinder in Begleitung der Eltern fahren auf den meisten Strecken umsonst, was ich nett von der Bahn finde. Erfreulich auch, dass die meisten Menschen mit undeutscher Gelassenheit auf die Pannen bei der Bahn reagieren. Nur ausländische Urlauber verstehen die Welt nicht mehr.

Image
By Courtesy of Kenneth Cratty, www.FreeDigitalPhotos.net

Während sich die Personalsituation  im Stellwerk Mainz nach Sommerurlaub und Sommergrippe wieder normalisieren dürfte, geben die vielen technischen Pannen zu denken, besonders wenn man mit 300 Stundenkilometern über die Schnellbahntrasse zwischen Köln und Mannheim saust. Man hat nicht gerade den Eindruck, dass die Bahn ein proaktives Servicekonzept verfolgt, das heißt Servicefälle durch vorbeugende Wartungsmaßnahmen zu vermeiden versucht. Sie reagiert auf Störungen, und das meistens zu spät.

Vielleicht sollten sich die Bahn und ihre Systemlieferanten mal ein Beispiel an der Japanische Staatsbahn nehmen, die bei ihren Zügen ein Konzept der Nullstillstandswartung verfolgt. Das bedeutet, dass die Züge im laufenden Betrieb gewartet werden und sich natürlich auch warten lassen müssen. Die konsequente Auswertung der Servicehistorie und ein permanentes Monitoring von Loks und Zügen schützt die japanischen Wartungstechniker vor unliebsamen Überraschungen – und das mit Erfolg: Verspätungen von mehr als 30 Minuten kommen bei Japan Railways so selten vor, dass sie Thema in den Nachrichten sind. Davon wagt man in Deutschland nicht mal zu träumen.

Softwaretechnisch sind solche proaktiven Servicekonzepte, die nicht nur die Bahn gut zu Gesicht stünden, dank der Vernetzung intelligenter Systeme über das Internet der Dinge viel leichter umsetzbar als noch vor ein paar Jahren. Voraussetzung dafür ist aber auch die Optimierung der Serviceprozesse, die in vielen Unternehmen immer noch recht hemdsärmelig organisiert sind. Sie betrachten den Service als notweniges Übel, statt ihn als Quelle zusätzlicher Einnahmen zu begreifen, was natürlich auch bedeuten würde, dass sie die Serviceleistungen zusammen mit den Produkten entwickeln müssten. Davon ist man jedoch noch weit entfernt: Produktentwicklung und Service führen in den meisten Unternehmen ein ausgeprägtes Eigenleben.

Die zunehmende Bedeutung des Serviceangebots für den Markterfolg der Produkte spricht dafür, Entwicklungs- und Serviceprozesse enger zu verzahnen. Grundlage dafür ist ein integriertes Produkt- und Service-Lifecycle-Management, das es beispielsweise erlaubt, Informationen über gehäuft auftretende Servicefälle in Form von Änderungen in die laufende Entwicklung einzusteuern. Für die PDM/PLM-Hersteller bedeutet das, dass sie ihre Lösungen entweder um zusätzliche Werkzeuge ergänzen oder aber Schnittstellen zu gängigen Serviceanwendungen schaffen müssen. Das werden sie allerdings nur tun, wenn ihre Kunden entscheiden, Entwicklung und Service endlich IT-technisch zu verheiraten.

Viel Lärm um Nichts

Von meiner letzten Reise in die USA habe ich ein tolles, neues Schlagwort mitgebracht: Servitization. Es beschreibt die beinahe kafkaeske Verwandlung von Produkten, die immer mehr eingebettete Software enthalten und über das Internet der Dinge miteinander kommunizieren, in hybride Produkt- und Serviceangebote. Im Extremfall kauft der Gebäudebetreiber keine Klimaanlage mehr, sondern zahlt für die Klimatisierung eines bestimmten Raumvolumens. Der Hersteller übernimmt die Verantwortung für die korrekte Auslegung der Klimatechnik und die Wartung der Anlage. Sie ist mit zig Sensoren ausgestattet und meldet Unmengen an Daten zurück, aus denen intelligente Software-Lösungen dann die Auffälligkeiten (z. Bsp. ein offenes Fenster) herausfiltern.

An diese Brave New World musste ich denken, als ich in meinem Appartementzimmer in New York morgens um 5 Uhr durch die ratternde Klimaanlage geweckt wurde. Genau genommen wurde ich nicht durch sie geweckt, sondern durch den Verkehrslärm auf der 3rd Avenue, der etwa ab dieser Uhrzeit die Klimaanlage übertönte. Wer New York kennt, kennt auch die etwas vorsintflutliche Gebäudetechnik: Die mehrfach verglasten Schiebefenster werden einfach hochgeschoben und fest arretiert, um die kastenförmigen Klimaanlagen einzubauen, womit zwar das Leben des Untermieters gesichert ist, nicht aber das eigene Überleben im Brandfall, weil der Zugang zur traditionellen Feuerleiter vor dem Fenster blockiert ist. Es sei denn, man schafft es, sich durch den engen Spalt rechts oder links des Geräts zu zwängen, der nur mit einer dünnen Plastikblende verschlossen ist. Schall- und Wärme-Isolierung gleich null.

Image
Alte und neue Fassaden in New York. Bild: Wendenburg

Vergeblich versuchte ich, den Kopf unter das Kopfkissen zu stecken und noch ein bisschen weiter zu schlafen. Mein unsanft aufgeweckter Geist suchte fieberhaft nach einer innovativen Lösung zur Senkung des Geräuschpegels. Kissen in die Aussparungen rechts und links neben der Klimaanlage zu knuffen, war weder besonders innovativ noch effektiv. Mir kam der Vortrag eines hochrangigen Airbus-Mitarbeiters über des Kabinenkonzept für das Jahr 2050 in den Sinn: Die komfortablen Sitze im Airbus der Zukunft sollen durch Gegenschallwellen von plärrenden Kindern und schnarchenden Nachbarn abgeschottet werden. Wenn man doch die amerikanischen Klimaanlagen mit Geräuschsensoren ausstatten und die Schallwellentäler des notorischen Brummens mit den Wellenbergen des Straßenlärms synchronisieren könnte? Das wäre wirklich mal eine Innovation, die diesen Namen verdient, mit schön viel Elektronik und eingebetteter Software.

Man könnte die Vision noch weiter spinnen und aus den Big Data sämtlicher New Yorker Klimaanlagen und ihren Positionsinformationen die Verkehrsdichte der jeweiligen Avenue berechnen, um die Verkehrströme in der Stadt besser zu lenken. Das Verkehrschaos in New York ist zu bestimmten Zeiten nämlich unbeschreiblich. Die Klimaanlage würde zum Herzen eines komplexen cyberphysischen Verkehrsleitsystems. Es darf nur keiner auf die Idee kommen, den Straßenbelag auszubessern, um den Geräuschpegel zu senken. Das würde die Berechnung total verfälschen.

Was ich eigentlich damit sagen will, ist dass die technischen Innovationen im allgemeinen und ganz besonders das Internet der Dinge mit einer gewissen Zwanghaftigkeit zur Entwicklung von immer komplexeren Systemen führt. Das mag zwar gut sein für die Hersteller von PLM- und Service Lifecycle Management-Systemen, die davon leben, diese Komplexität wieder beherrschbar zu machen. Aber manchmal fragt man sich wirklich, ob es unbedingt notwendig ist, auch noch die letzte Glühbirne mit Internet-IP und Wifi-Ersatz auszustatten, um sie über eine App in unserem Smartphone individuell ansteuern zu können? Auch ohne den ökologischen Fußabdruck mit PLM berechnet zu haben, bin ich mir ziemlich sicher, dass Entwicklung und Fertigung dieser smarten Produkte mehr Gehirnschmalz und Energie verbraucht haben als sie je in ihrem Lifecycle einsparen werden.

Homo informaticus hat ein quasi sado-masochistisches Verhältnis zur Komplexität. Wir jammern ständig darüber, dass alles immer komplexer wird, lassen uns aber wollüstig stöhnend von Complexitas in Ketten legen. Zum Glück gibt es Rettung. Im Jahr 2020 sollen bereits 70 Prozent der weltweiten Nachfrage nach Gütern und Dienstleistungen aus den Emerging Countries kommen. Im Zuge von Globalisierung und Personalisierung der Produktentwicklung bringen die Unternehmen immer mehr Produkte für diese Länder auf den Markt, deren Innovation im wesentlichen darin besteht, dass sie einfacher und kostengünstiger sind. Und plötzlich stellt man fest, dass es in unserer entwickelten Welt dafür einen Markt gibt und importiert sie zurück. Auch dafür haben die Amis ein schönes Schlagwort kreiert: Reverse Innovation.

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.

Mit PLM auf Wolke sieben?

Wenige IT-Themen werden dies- und jenseits des großen Teichs so unterschiedlich beurteilt wie die Nutzungsmöglichkeiten und das Nutzenpotential der Cloud für das Product Lifecycle Management. Die Amerikaner, die kurioserweise mehr Vorbehalte gegen das Internet-Banking haben als wir Deutschen, sind eher bereit, PLM-Funktionen aus der Cloud zu beziehen bzw. ihre PLM-Daten in die Cloud zu stellen. Böse Zungen behaupten, das sei nicht weiter verwunderlich, weil sie mehr Geld und weniger geistiges Eigentum zu verlieren haben als wir, aber das ist natürlich Unsinn. Es ist im vor allem eine (subjektive) Vertrauensfrage.

Objektiv betrachtet sind CAD- und PLM-Daten in der Cloud ebenso sicher wie in einem firmeneigenen Netz – sagen jedenfalls viele Sicherheitsexperten. Man könnte sogar argumentieren, dass sie dort wahrscheinlich sicherer sind, weil sich die Cloud-Betreiber aus wohlverstandenem Eigeninteresse viel intensiver um Datenschutz und Ausfallsicherheit kümmern als die meisten anderen Unternehmen. Natürlich sind IT-Service-Provider auch ein beliebtes Angriffsziel  für Datenpiraten. Aber ich bin überzeugt davon, dass mehr sensible Daten durch schlampigen Umgang mit ihnen (z. Bsp. durch liegen gelassene Laptops) als durch böswillige Hackerattacken verloren gehen.

plm_cloud(Bildquelle: InnoFour)

Dennoch stehen gerade in Deutschland viele Unternehmen der Cloud skeptisch gegenüber, obwohl sie das Potential zum Teil schon evaluieren. Auch ich gehöre eher zu den Skeptikern, bin allerdings davon überzeugt, dass sich die PLM-Branche dem allgemeinen Trend zum Cloud-Computing auf Dauer nicht wird widersetzen können. Was mich im Augenblick umtreibt ist die Frage, ob die Cloud den PLM-Anwendern wirklich den Nutzen bringt, den ihre Befürworter bzw. die wenigen Anbieter von Cloud-Lösungen ihnen versprechen. Ich habe da so meine (technisch begründeten) Zweifel.

Die wichtigsten Nutzeneffekte Cloud-basierter Lösungen sind Kosteneinsparungen für die (Nicht-)Anschaffung, Betrieb und Wartung von Hard- und Software, ein schnellerer Roll-out und die größere Flexibilität, dadurch dass die Unternehmen ihre IT-Ressourcen je nach Bedarf ohne Installationsaufwand ausweiten und auch wieder zurückfahren können. Die Installation atmet gewissermaßen ein und aus. Wie atmungsaktiv sie ist, hängt allerdings von der Art der Cloud ab. In einem privaten Wölkchen lassen sich die Ressourcen nicht so einfach umverteilen wie in einer öffentlichen Wolke. Wenn überhaupt werden PLM-Lösungen aber derzeit in einer privaten Cloud betrieben.

Die nächste Frage ist, wie viel an IT-Kosten sich tatsächlich einsparen lässt, wenn man neben einer Cloud-basierte PLM-Lösung eine lokale IT-Infrastruktur für CAx-Anwendungen und -Datenmanagement aufrecht erhalten muss. Daran führt aber zu Zeit kein Weg vorbei, erstens weil keiner der führenden PLM-Anbieter eine wirklich Cloud-fähige CAD-Lösung anzubieten hat und zweitens weil die PLM-Anwender zumindest hierzulande ohnehin nicht bereit wären, ihr Engineering-Know-how einem fremden Unternehmen anzuvertrauen. Ohne CAD in der Cloud ist PLM in der Cloud nur von eingeschränktem Wert: Eine interessante Option für PLM-Nachzügler, die die Technologie ohne eigene PLM-Installation nutzen möchten, oder für bestimmte PLM-Prozesse wie die Supply Chain Collaboration.

PLM in der Cloud ist meiner Einschätzung nach zur Zeit (noch) keine Alternative, sondern nur eine Ergänzung zu herkömmlichen Implementierungen. Es ist aber wahrscheinlich, dass nach und nach immer mehr PLM-Funktionen in die Cloud abwandern. Für die meisten PLM-Anbieter bedeutet das, dass sie ihre Lösungen erst mal fit für die Cloud machen müssen. Das sind sie nämlich nicht. Es ist nicht damit getan, sie in einer Cloud-Infrastruktur (IaaS) betreiben zu können – sie müssen auch die PLM-Software als Service anbieten. Dafür muss ihre Software aus dem Stand nutzbar sein, ohne sie vorher tagelang konfigurieren zu müssen. Außerdem muss die Architektur so modular aufgebaut sein, dass Kunden oder Drittanbieter die Möglichkeit haben, sie als Plattform für Anpassungen oder die Entwicklung von Zusatzanwendungen (PaaS) zu nutzen.

Die Unternehmen werden sich auf Dauer nicht mit einer PLM-Lösung “von der Stange” begnügen, unabhängig davon, ob sie in der Cloud liegt oder nicht. Dazu sind ihre Produkte und Prozesse zu unterschiedlich. Eine Reisekostenabrechnung kann man vielleicht nach Schema F über das Internet abwickeln. Die Art und Weise, wie ein Unternehmen seine Entwicklungsprozesse organisiert, ist aber letztlich entscheidend für seine Wettbewerbsfähigkeit. PLM-Angebote aus der Cloud, die wirklich einen Nutzen für den Anwender erzielen wollen, müssen diesem Umstand Rechnung tragen. Sonst bleibt es bei wolkigen Versprechungen.

Einen ausführlichen Beitrag von mir zum Thema PLM in der Cloud finden Sie hier: (http://www.cadplace.de/Spezialthemen/Schwerpunktthema-Cloud/Hat-CAD-und-PLM-in-der-CLOUD-eine-Zukunft)

Pleiten, Pech, Pannen und PLM

“Alles was schief gehen kann, wird auch schief gehen”, lautet das wohl bekannteste von Murphys Gesetzen. Wo der Mensch seine Hände im Spiel hat, sind Fehler unausweichlich. Für die Unternehmen heißt das, dass sie die Fehlerquote reduzieren, aber Fehler nie ganz eliminieren können. Worauf es ankommt, ist ein effizienter Umgang mit den auftretenden Fehlern, um sie möglichst schnell zu beheben und ihre Wiederholung zu vermeiden. Das gilt vor allem für jene Fehler, die den Gebrauch eines Produktes beeinträchtigen, sprich Mängel.

Das Problem mit Fehlern ist, dass sie in vielen Formen auftreten – als Produkt- oder Qualitätsfehler, als Prozessfehler, als (meist unverständliche) Error-Meldung einer Software etc.. Manchmal verkleiden sie sich auch als Serviceanfragen oder Verbesserungsvorschläge. Einige fallen in der Entwicklung auf, andere in Fertigung und Montage bzw. in der Qualitätssicherung. Wieder andere entdecken die Servicetechniker oder – schlimmer noch – die Kunden, was Gewährleistungen, Reklamationen oder Beschwerden nach sich zieht.

Je nachdem, wo und wann sie auftreten bzw. auffallen, werden Fehler mit unterschiedlichen Werkzeugen wie Excel, eigene Datenbanken etc. verwaltet, was ihre strukturierte Bearbeitung nach einer einheitlichen Methodik (z. Bsp. der 8D Methode) erschwert. Das ist weder effizient noch effektiv, denn bei allen diesen Vorgängen geht es letztlich darum, sie systematisch zu erfassen, auszuwerten, entsprechende Maßnahmen zu ergreifen und diese nachvollziehbar zu dokumentieren. Deshalb liegt es nahe, die Bearbeitung aller fehlerrelevanten Vorgänge in einer einheitlichen IT-Systemumgebung zusammenzuführen. Die Frage ist, ob PLM dafür die geeignete Plattform ist bzw. was sie leisten muss, um diese Funktion zu erfüllen?

Für die Integration des Mängelmanagements in PLM sprechen verschiedene Gründe:

  • Mängel, Reklamationen etc. haben normalerweise einen engen Bezug zu einem Produkt oder Projekt, deren Unterlagen mit PLM verwaltet werden;
  • für die Bearbeitung der Vorgänge können einheitliche Vorgehensweisen in Form von elektronischen Workflows abgebildet werden;
  • die Rechteverwaltung des PLM stellt sicher, dass nur autorisierte Personen zu den Informationen über Mängel, Reklamationen etc. haben;
  • PLM unterstützt die Umsetzung von Maßnahmen zur Fehlerbehebung durch formale Workflow-Prozesse;
  • die vorhandenen Projektmanagement-Funktionen können für die Umsetzung von größeren Verbesserungsvorhaben genutzt werden;
  • die Nutzung einer einheitlichen Plattform spart Schnittstellen und Kosten für Anschaffung bzw. Wartung einer separaten Reklamationsmanagement-Anwendung.

Alle Vorgänge, die mit der Behandlung von Fehlern zu tun haben, in die PLM-Lösung zu packen, ist also keine schlechte Idee. Einheitliche Bearbeitungsmethoden unter einer einheitlichen Oberfläche sorgen dafür, dass die Mitarbeiter Mängel, Reklamationen etc. schneller erledigen können. Das spart Kosten, erhöht die Zufriedenheit der Kunden und bindet sie an das Unternehmen. Wem bei einer Reklamation schnell und unbürokratisch geholfen wird, der kauft gerne wieder.

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.

Viel Bauchgefühl, wenig Zahlen

Erfolg muss messbar sein – das gilt auch für den Erfolg von PDM/PLM-Projekten. Sollte man meinen, doch die Realität sieht oft anders aus. Wenn ich bei meinen Gesprächen PDM/PLM-Verantwortliche frage, was die Investitionen in ihre Lösung denn an Nutzeneffekten gebracht haben, bekomme ich in der Regel keine erschöpfende Antwort: Viel Bauchgefühl und wenig belastbare Zahlen. Zum Teil hängt das damit zusammen, dass der Ist-Zustand vor der PDM/PLM-Einführung nie genau erfasst worden ist, so dass man keine Vergleichszahlen hat; zum Teil hat man auf eine eingehende ROI-Betrachtung verzichtet, weil am PDM/PLM-Einsatz ohnehin kein Weg vorbei führte. Wozu sich also die Mühe machen? Dumm ist nur, dass die Unternehmen die Entwicklung von Effektivität und Effizienz der PLM-Prozesse auch nach der Systemeinführung nicht mehr verfolgen und sich dadurch schwertun, das Potential für stetige Prozessverbesserungen zu identifizieren.

Image

Zugegeben, je komplexer die Prozesse , desto schwieriger ist eine Erfassung verlässlicher Kennzahlen über diese Prozesse. Es gibt direkte Effekte wie die Verkürzung der Suchzeiten, die sich ziemlich einfach dem PDM/PLM-Einsatz zuschreiben lassen, aber eben auch viele indirekte Effekte oder Effekte, die ihre Wirkung im Zusammenspiel mit anderen Maßnahmen und IT-Systemen entfalten. Wie will man zum Beispiel den Nutzenanteil von PDM/PLM gewichten, wenn sich die Auftragsabwicklung spürbar verkürzt hat, weil PDM- und ERP-Systeme besser integriert wurden? Die Tatsache, dass man nie alle Effekte vollständig erfassen wird, spricht aber nicht grundsätzlich gegen eine Kennzahlensystematik. Im Gegenteil, es geht ja – unabhängig von den Nutzeneffekten – auch um eine bessere Transparenz der Prozesse, um die Auswirkungen von Veränderungen beurteilen zu können.

Paradoxerweise sind in vielen Unternehmen nicht mal die direkten Nutzeneffekte transparent, obwohl die Informationen darüber eigentlich im System stecken. Man kriegt sie nur nicht wieder raus – jedenfalls nicht in einer statistisch verwertbaren Form. Wer wann welchen Änderungsantrag gestellt hat und wann er freigegebenen wurde, ist dem System eigentlich bekannt. Mangels entsprechender Werkzeuge kann aber keiner sagen, wie sich die durchschnittliche Durchlaufzeit der Änderungsanträge im letzten Jahr entwickelt hat. Was die Unternehmen dafür benötigen ist ein PLM-integriertes Kennzahlenmanagement, mit dem sie bestimmte Leistungskennzahlen (Key Performance Indicators) berechnen, mit Zielwerten vergleichen und ihre Historie für Trendanalysen aufzeichnen können.

Welche Kennzahlen spiegeln die Performance einer PDM/PLM-Lösung am besten wieder? Das ist eine gute Frage, die sich noch nicht abschließend beantworten lässt. Der Verband der Deutschen Maschinen- und Anlagenbauer VDMA entwickelt im Rahmen der PIPE-Initiative (Prozesss-Indikatoren für Product Engineering) zusammen mit Contact Software und anderen namhaften PLM-Herstellern gerade eine einheitliches Modell mit entsprechenden Performance-Indikatoren, die eine branchenübergreifend einheitliche Bewertung von Engineering-Prozessen ermöglichen soll. Damit wird es auch erstmals möglich sein, die Leistungsfähigkeit von PDM/PLM-Lösungen nach einheitlichen Kriterien zu bewerten.

Effizienz und Effektivität der Produktentwicklung sind in einem Land, das von der Umsetzung innovativer Ideen lebt, entscheidend für die Innovationsfähigkeit der Unternehmen. Im Unterschied zur Produktion, in der alle möglichen Kennzahlen ausgewertet werden, ist die Produktentwicklung jedoch oft eine Gleichung mit vielen Unbekannten: Wo stehen wir aktuell, wo wollen wir hin, sind wir auf dem richtigen Weg und wie weit sind wir schon voran gekommen? Solche Fragen lassen sich ohne verlässliche Kennzahlen nicht beantworten lassen. Ein Kennzahlenmanagement, das direkt den PDM-Datenbestand nutzt, ist deshalb der Schlüssel zu einer besseren Steuerungsfähigkeit der Produktentwicklung.

Systems Engineering und der Innovationseffet

Elektronik und Software sind zum Motor der Innovation geworden – nicht nur im Automobil, sondern auch in vielen anderen Produkten. Und wie beim Billard stößt eine Innovation die andere an, auch wenn die Effets nicht immer vorhersehbar ist. Die softe Revolution erlaubt die schnelle Integration von zusätzlichen Funktionen, die den Produktlebenszyklus verlängern, und erleichtern gleichzeitig die funktionale Differenzierung der Produktpalette. Wie viel Pferdestärken ein Motor auf die Straße bringt, das hängt heute auch und vor allem von der eingebetteten Software ab.

Image

In einem Fahrzeug der Oberklasse stecken inzwischen mehr Zeilen Programmcode als in manchem PLM-System. Die eigentliche Herausforderung ist jedoch nicht die Menge an Software, die sich wesentlich schneller entwickeln lässt als andere Produktbestandteile, sondern das perfekte Zusammenspiel von Software, Elektrik/Elektronik und Mechanik. Ihre Abstimmung erfordert neue Werkzeuge, Methoden und Prozesse für die interdisziplinäre Produktentwicklung. Systems Engineering (SE) heißt das Schlagwort, das in aller Munde ist, auch wenn jeder SE-Experte es etwas anders definiert.

Verwunderlich ist die Definitionsvielfalt nicht, denn letztlich geht es genau darum: Erst einmal eine gemeinsame Sprache zu finden. Eine gemeinsame Sprache, mit der man komplexe Produkte als Gesamtsystem beschreiben und überprüfen kann, unabhängig davon, wie und mit welchen Werkzeugen die beschriebenen Funktionen und Eigenschaften nachher umgesetzt werden. Eine Sprache, die es den unterschiedlichen Disziplinen erlaubt, ein gemeinsames Verständnis für die bestehenden Abhängigkeiten zwischen Anforderungen, Funktionen, Bauteilen etc. zu entwickeln und gerade bei Änderungen einfacher miteinander zu kommunizieren. Sozusagen ein Esperanto für die Produktentwicklung.

Ganz gleich welche Sprache(n) und Sprachwerkzeuge zum Einsatz kommen, müssen sie in die Product Lifecycle Management-Lösungen integriert werden, um die beschriebenen Anforderungen und die daraus abgeleiteten Funktionen und Eigenschaften des Produkts über den gesamten Entwicklungsprozess verfolgen und die Wechselwirkungen von Änderungen beurteilen zu können. In diesem Sinne ist das Systems Engineering zum Motor für die Innovation der PLM-Technologie geworden, die lange Zeit einseitig auf die Datenverwaltung und Prozessteuerung in der Mechanikentwicklung fokussiert war. Die meisten PLM-Lösungen unterstützen heute ein disziplinenübergreifendes Anforderungs-Management und ermöglichen die Abbildung einer funktionalen Sicht auf das Produkt.

Anforderungen abzubilden und in Beziehung zu anderen Anforderungen, Funktionen, Bauteilen etc. zu setzen, ist weniger eine technische Herausforderung. Die PLM-Datenmodelle sind dafür ausreichend flexibel. Die Kunst besteht darin, dies so zu tun, dass die Systeme für die Anwender noch bedienbar sind. Oder anders ausgedrückt: Zu vermeiden, dass man den Teufel mit dem Belzebub austreibt. Schließlich soll das Systems Engineering die Komplexität der Produktentwicklung besser beherrschbar zu machen. Wenn die IT-Werkzeuge zur Unterstützung der Systementwicklung dadurch so komplex werden, dass sie für die Anwender kaum noch zu beherrschen sind, ist nichts gewonnen.

Die PLM-Hersteller müssen sich darüber Gedanken machen, wie sie die Definition der Beziehungen zwischen Anforderungen und anderen PLM-Objekten und vor allem die Visualisierung der komplexen Zusammenhänge besser unterstützen. Die Anwender benötigen komfortable grafische Eingabehilfen und neue Peripheriegeräte mit taktilen Oberflächen, um die Beziehungsgeflechte großformatig darstellen und mit ihnen direkt interagieren zu können.  Mit anderen Worten genau die Art von Produkten, deren Entwicklung ein interdisziplinäres Vorgehen im Sinne des Systems Engineering erfordert.