Tag: PLM

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.