Category: PLM applications

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)

Dieses „M“, das doch eigentlich viel sein sollte, als heiße Luft…

Das_MDer Begriff [‘mänätschmänt] blickt auf eine langjährige Karriere als inhaltsleere Füllwortmasse in allen Bereichen des Lebens zurück. Im Wesentlichen ist sie dazu da, das Ausatmen bei der Vertonung komplexer Wortgebilde zu erleichtern. Und auch unser aller Lieblingsabkürzung wurde leider nicht davon verschont – wo sie doch mit „P“ und „L“ so einen schmissigen Anfang genommen hat.

Machen wir das Beste draus, wagen wir das Experiment, das „M“ einmal ernst zu nehmen. Was wäre denn die Quintessenz vom „managen“ beim „productlifecyclen“? Kosten im Griff behalten – ja klar, zentral wichtig, aber im Kern die Ägide des Controllings. Termine? Macht das Projektmanagement (hoffentlich). Last but not least: Der Kern des „PL-“ Managements liegt für mich darin, den Reifegrad des Produktes unter Kontrolle zu haben.

Reifegrad hat dabei zwei Perspektiven:

1. Der Grad, in dem ein Produkt das macht, was es soll.

2. Der Grad, in dem das Produkt so hergestellt werden kann, wie man es haben will.

Diese beiden Sichtweisen werden gerne als Produkt- und Prozessreifegrad bezeichnet

Um so einen Reifegrad zu bestimmen oder gar zu steuern, ist es von Vorteil, erst einmal zu beschreiben, wogegen man messen will. Ich hätte dazu noch einen Begriff mit Füllwortende im Angebot: Anforderungsmanagement. Mit dem Vehikel „Anforderung“ beschreibe ich klassisch, was ein Produkt machen soll. Reicht aber nicht! Ich muß auch beschreiben, wie ich ein Produkt herstellen will! Das nennt sich dann „Front-Loading“ und hilft ganz gewaltig, den Zielraum für eine Produktentwicklung zu konkretisieren.

Wie aber das Wort „Entwicklung“ schon sagt, steuere ich hier gegen ein bewegliches Ziel, Produkt und Prozess wachsen weiter, machen manchmal auch einen Schritt rückwärts. Der Reifegrad muß also auch ein Ausdruck dafür sein, wie erfolgreich meine verschiedenen Konzeptalternativen sind bzw. wie weit ich den Trichter möglicher Optionen schon eingeengt habe (letztes Buzzword für heute: Set-Based Engineering).

So ergibt sich ein Korridor von Fakten, gegen den die Produktentwicklung reflektiert werden kann: Hat meine Entwicklung alle Anforderungen im Blick (Abdeckungsgrad)? Kann ich die Anforderungen auch bedienen (Erfüllungsgrad)?

Zum Thema „Abdeckungsgrad“ empfehle ich den Blog-Beitrag von Michael Wendenburg zum Systems Engineering, das ist eine Frage der intelligenten Verdrahtung von Informationen untereinander. Der Erfüllungsgrad wiederum ist eine Frage der Absicherung – und hier wird’s jetzt ein bißchen heterogen…

Absicherung stand lange Zeit synonym für den guten alten Versuch: Hält es noch, wenn man dran rüttelt? Läuft irgendwo Öl ‘raus? Entschuldigung an alle Kollegen aus dem Versuch für die saloppe Formulierung. Was ich damit verdeutlichen will, ist die Krux, daß der Versuchsplan sich in Ermangelung an klar formulierten Anforderungen auch nicht an solchen orientieren kann. Was man im Versuch herausfindet, wird klassischerweise so gut wie möglich gegen einzelne Teile oder Baugruppen dokumentiert und daraus ein (Produkt-) Reifegrad interpretiert.

Das Gleiche gilt grundsätzlich auch für die Absicherung der anderen Reifegrad-Perspektive. Aber Herstellbarkeitsprüfungen, Verbauuntersuchungen, Try-Outs zur Prozess-Stabilität… müssen eher noch ein härteres Schicksal tragen: Ergebnisse wie „läßt sich nicht mit dem Schrauber erreichen“ können wenigstens noch auf einen Bauraum bezogen werden, aber „zu breit für die Lackierkabine“ ist schon deutlich schlechter aufzulösen. Und es geht ja auch noch weiter: Sind die Logistik-Prozesse reif, klappt die IT-Versorgung für die Produktion und und und …

Nun existiert dazu auch noch eine veritable Parallelwelt: Simulation hat Ihren Platz in den Entwicklungsorganisationen gefunden, sowohl für Produkt-, als auch Prozessthemen. Allerdings ringen viele Beteiligte noch mit der Verdrahtung doch unterschiedlicher Prozesswelten. Typische Rückmeldungen aus der Simulation lauten in etwa „würde halten, wenn Du den Radius etwas kleiner machst“ – und das womöglich in sehr frühen Konzeptphasen, wo es kaum eine ausgegorene Produktstruktur als Referenz gibt.

Spätestens hier wird also der Zusammenhang zwischen Reifegrad und Alternativen besonders deutlich: Messe ich das eine, bewerte ich das andere.

Um managen zu können, brauchen ich ein gemeinsames Raster für Entwicklung und Absicherung, an dem Ergebnisse der sehr unterschiedlichen Aktivitäten gespiegelt werden. Egal ob Simulation oder physische Absicherung, frühe Konzepte oder B-Muster – ich benötige eine vereinheitlichte Aussage über den Reifegrad meiner Ergebnisse. Und nur auf der Ebene von Anforderungen habe ich ein hinreichend abstraktes Vehikel, um so ein Raster darzustellen und alle genannten Fraktionen abzuholen.

Wenn man „Management“ ernst nehmen will, dann sind wir hier – glaube ich – an einer guten Stelle dafür angelangt.

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.