Der PLM-Talk – heute mit Sven Mahn und Wolfgang Enking (Sven Mahn IT – The AX Authority)

Auf meiner virtuellen PLM-Couch haben wieder zwei hochkarätige Gesprächspartner Platz genommen: Sven Mahn, Inhaber der Sven Mahn IT GmbH & Co KG und Wolfgang Enking, Verantwortlich für das Business Development im gleichen Unternehmen sprechen über Gemeinsamkeiten und Unterschiede zwischen PLM- und ERP-Projekten.

Herzlich willkommen auf meiner virtuellen Blog-Couch, Herrn Mahn und Herr Enking. Ihre Namen sind mit dem Tool Microsoft Dynamics AX verbunden und man kennt Sie hauptsächlich aus dem ERP-Umfeld. Können Sie ein paar Worte zu Ihrem Werdegang verlieren?

ERP-Experte Sven Mahn

Sven Mahn

Sven Mahn: Moin moin von meiner Seite. Ich bin vor 40 Jahren in Hamburg geboren, bin hier groß geworden und habe nach dem Abitur eine Lehre zum Beton- und Stahlbetonbauer abgeschlossen. Mit Computern und Software habe ich mich seit dem zehnten Lebensjahr beschäftigen dürfen, neben den Klassikern auf C16 und C64 habe ich bereits in dem Alter angefangen zu programmieren. Das hat mich im weiteren Verlauf zur Wirtschaftsinformatik in einem pharmazeutischen Produktionsbetrieb getrieben. Nach einem Verkauf des Unternehmens habe ich die vermeintliche Sicherheit im Konzern gegen die Selbstständigkeit getauscht. Seit 2005 sind wir nun erfolgreich am Markt, mittlerweile mit annähernd 50 Mitarbeitern.

Wolfgang Enking: Bevor ich bei Sven und seiner Sven Mahn IT GmbH & Co. KG anfing, hatte ich vier Jahre lang die Verantwortung für die Microsoft Dynamics AX Consulting-Organisation in EMEA. Dies war eine der interessantesten Aufgaben in meiner 20-jährigen Laufbahn bei Microsoft. Ich war bei Microsoft im Consulting und Service tätig und hatte dort die unterschiedlichsten Leitungsaufgaben. Vorher habe ich bei verschiedenen Unternehmen im Umfeld der Bürokommunikation gearbeitet. Auch nach über 30 Jahren Berufserfahrung bin ich immer noch begeistert über die Möglichkeiten, die moderne IT für die Evolution, also die Weiterentwicklung, der Unternehmen bietet.

Hatten Sie in Ihren Projekten bereits Berührungspunkte zum Thema PLM?

Sven Mahn: Regelmäßig. Letztendlich ist eine PLM-Software die Vorstufe des ERP-Systems. Eine enge Verzahnung der Prozesse ist nicht auszuschließen. Da wir keinen Branchenfokus haben, sind wir bereits in allen Arten der Produktion unterwegs gewesen, mit unterschiedlichstem Grad an Professionalität des PLM. Am spannendsten ist eine ERP-Implementierung immer dann, wenn PLM-Prozesse weder softwaregestützt noch dokumentiert sind, sprich die Kopfmonopole der Unternehmen, deren Rezepturen, Stücklisten oder Produktionsprozesse inklusive Attributverwaltung auf einzelne Mitarbeiter abzielen und von diesen abhängig sind.

ERP und PLM sind in vielen Fertigungsunternehmen zwei Seiten der gleichen Medaille. Die Einführung eines Softwarewerkzeugs dieser Art ist immer eine besondere Herausforderung. Wo sehen Sie aus Ihrer Erfahrung heraus die größten Stolpersteine, ein Softwarewerkzeug dieser Tragweite in einem Unternehmen einzuführen?

Sven Mahn: In erster Linie sind es die Menschen, die sich selbst Stolpersteine in den Weg legen. Setzt man voraus, dass jeder Mitarbeiter auch am Erfolg und Erhalt seines Arbeitsplatzes interessiert ist, können diese Typen von Software dazu dienen, Arbeitsplätze zu vernichten. So die Wahrnehmung im ersten Schritt. Die Kommunikation des Ziels und der Ausrichtung des Unternehmens mit der neuen Software und den damit verbundenen Visionen ist unerlässlich. Hier wird häufig – wie man das heute so schön formuliert – nicht jeder gleich gut abgeholt. Nun gibt es in Unternehmen auch die bereits erwähnten Kopfmonopolisten, die sich eigentlich nicht um das Wohlergehen des Unternehmens, sondern den Erhalt der eigenen Spezies durch Wissensmonopole sorgen. Hier zeigt die Implementierung sehr schnell Grenzen auf bzw. bringt eine eventuell nicht auf Gegenliebe stoßende Transparenz in die Unternehmensabläufe. Dass mit dieser geschaffenen Standardisierung die Energie und das vermeintlich freiwerdende Kapital in Forschung und Entwicklung gesteckt werden können, erschließt sich nicht jedem, bzw. wird so auch selten kommuniziert. In der Implementierung selbst ist die Frage nach Qualitätssicherung eine der wesentlichen. Wie verifiziere ich, dass das angestrebte System und die abgebildeten Prozesse meinen Vorstellungen entsprechen und die Umsetzung durch den Implementierter auch verstanden wurde? Die Vorgabe von festen Implementierungszeitpunkten durch die Geschäftsführung erinnert mich immer an die Diskussionen mit meinen Töchtern, die doch bis zu einem bestimmten Zeitpunkt in der Woche ihr Zimmer aufgeräumt haben sollten. Schon 10- und 13-Jährige wissen, dass es darauf ankommt, zu definieren, was „aufgeräumt“ bedeutet. Bevor das nicht klar ist, wird kein

ERP-Experte Wolgang Enking

Wolfgang Enking

Termin gehalten werden. Zu guter Letzt ist die schiere Komplexität der Systemlandschaften und deren Ablösung durch ein oder zwei Systeme eine Herausforderung für sich. Hier gilt es aus unserer Sicht, bereits in der Implementierung besonderen Wert auf Transparenz und Qualität zu setzen.

Wolfgang Enking: Man sagt: „Qualität ist das Produkt aus Nutzen x Akzeptanz“. Bei den Projekten unserer Kunden orientieren wir uns gerne daran, denn es bringt die wesentlichen Erfolgsfaktoren eines Projektes in eine simple Formel. Wenn ein neues Softwarewerkzeug auch viel Nutzen für ein Unternehmen erzeugen kann, so ist die Akzeptanz der Anwender am Ende doch ein entscheidender Faktor für den Gesamterfolg.

In den letzten Jahren werden verstärkt agile Projektmanagementmethoden wie Scrum für PLM- und ERP-Einführungen benutzt. Wie sind Ihre Erfahrungen mit Methoden dieser Art? Ist das ein Lösungsansatz, um diese Stolpersteine zu vermeiden?

Sven Mahn: Werden sie? Wirklich? Oder bezeichnet man „Versuch und Irrtum“ als agil? Letzteres ist leider häufig der Fall. Als Feuerwehrmann kann ich nur sagen, eine enge Führung und Struktur sowie absolute Transparenz und Offenheit schützen nicht vor Fehlern oder ungeplanten Ereignissen, aber sie lassen einen auf diese kurzfristig reagieren und Entscheidungen fundiert führen. Es kommt für mich stark auf das Team und die Unternehmensphilosophie an, ob ein Projekt nach SCRUM oder anderen agilen Methoden durchgeführt werden kann. Gibt es einen hohen Grad an Disziplin und wird dem Team oder den Teams eine Selbstverwaltung zugetraut? Dann ist Agilität sicher ein Gewinn, da man so zumindest zu den Sprint-Results klar weiß, welche Funktionen vorhanden sein sollten, inklusive definierten erfolgreichen Unit-Test. Bei Wasserfallmethoden ist die lange Zeit des Wartens hinderlich, wird das Projekt nicht selten von äußeren Aktivitäten und Ereignissen ein- meistens gar überholt. Das macht teure Nacharbeiten oder das Justieren der Prozesse notwendig. Eine Dokumentationsflut kann zudem die Komplexität ins Unermessliche ausufern lassen und führt am Ende zu Frust und einem forcierten Go-Live, der dann eventuell weder dem Qualitätsanspruch genügt noch die ursprünglich angedachte und geforderte Funktionsumfänge bereitstellt.

Wolfgang Enking: In ERP-Projekten wird noch häufig mit dem Wasserfallmodell gearbeitet. Eine der Ursachen liegt sicher in der Ausstrahlung, die ein ERP-System auf so viele Prozesse in einem Unternehmen hat. Es ist schwierig, eine ERP-Umstellung „agil“ zu gestalten, gerade wenn es um die Schnittstellen und Verzahnung von verschiedenen Systemen in das neue ERP-System geht. Dennoch haben wir bereits bei einigen Kunden die agile Methode erfolgreich zum Einsatz gebracht und wir sehen darin eine attraktive Vorgehensweise, gerade wenn es um die Cloud-Technologien geht.

Da ERP- und PLM-Systeme das „offene Herz“ eines Fertigungsunternehmens sind, kommt der Qualitätssicherung bei der Tooleinführung eine große Rolle zu. Können Sie hier ein wenig aus dem Nähkästchen plaudern, wie sie in Ihren Projekten mit dieser Herausforderung umgehen?

Sven Mahn: Qualitätssicherung fängt bei der Auswahl des Systems in Kombination mit dem Anbieter/Implementierungspartner an und hört bei der Abnahme und dem Feiern des erfolgreichen Go-Lives auf. Als Anbieter für Dynamics AX und bekennender Qualitätssicherer stehen wir für offene und transparente Kommunikation und Dokumentation. Egal ob agil oder nach Phasenmodell, sobald ich die Anforderung kenne, können Testfälle erstellt oder die Akzeptanzkriterien definiert werden. Das fordern wir in unseren Projekten auch vom Kunden ein. Dies ist ein eklatanter Vorteil für die Arbeit der Entwickler, die bei identifizierten Gaps nicht nur gegen die Definition entwickeln, sondern auch unter Zuhilfenahme der Testfälle eine höhere Qualität ausliefern können – zumindest meistens. Menschen spielen immer eine intensive Rolle dabei, der eine mag genauer sein, der andere ist dafür innovativer und hat gute Ideen. Beide Typen in einem Projekt die richtige Qualität liefern zu lassen, ist die große Kunst. Dies versuchen wir bei der Rollenvergabe in Projekten zu beachten.

Wolfgang Enking: Nichts ist so teuer wie ein Fehler, der erst nach dem Go-Live entdeckt wird, denn dann hat der Schaden oft schon „Wellen geschlagen“. Leider wird dem Testen der Software noch immer eine zu geringe Wertigkeit eingeräumt. Dies führt dann zu sehr kurzen Zeiträumen für das Testen und oft zu sogenannten „Shortcuts“, in denen gewisse Funktionen erst gar nicht getestet werden. Wir thematisieren die Qualität bereits bei Beginn eines Engagements und gehen mit einer Methode vor, in der die Standardprozesse von Dynamics AX als Testfälle bereits im Design einer Lösung einfließen. Unterschiede zu kundenspezifischen Anforderungen werden so frühzeitig erkennbar. Der Fokus auf die Nutzung von Standardprozessen wird verstärkt und manchmal führt das dann zu einer guten Diskussion, ob ein Unternehmen damit nicht besser fährt als mit den gewohnten Prozessen.

ERP- und PLM-Systeme selber unterliegen ja auch einem Lebenszyklus. Neue Major Releases vom Softwarevendor oder Erweiterungen des Funktionsumfangs verlangen vor dem Einspielen in das Produktivsystem beim Kunden ebenfalls nach Qualitätssicherung. Welche Strategien und Methoden wenden Sie hier an?

Sven Mahn: Allerdings, die Zeiträume zwischen den Major Releases werden auch noch immer kürzer. In der Regel zieht hier die Dokumentationskarte. Je besser wir im Projekt dokumentiert haben, desto einfacher ist ein Releasemanagement. Letztendlich sind doch die Themen „Prozesse“, „Datenstand“ und „Softwarereleases“ in Kombination mit den Ständen der Testfälle ein zusammenhängender Komplex, der aus den Projekten heraus häufig zum Erliegen kommt. Dabei sind Implementierungsprojekte die Keimzelle definierter Prozesse für die Einhaltung eines Releasemanagements und der Dokumentation von Abweichungen, die durch eigene erforderliche Anpassungen entstanden sind. Die Verzahnung der Daten-, Software-, Testfall- und Konfigurationsreleases ist ein guter Lösungsansatz, um kontinuierliche Integration und Updatezyklen in kleineren Etappen durchzuführen. Je länger ein Update auf sich warten lässt und je weniger Dokumentation in den besagten Objekten vorliegt, desto grausamer wird ein Release. Eine Besonderheit sind hier die von den Unabhängigen Softwarelieferanten (ISV) angebotenen horizontalen und vertikalen Lösungen. Je nach Integrationsgrad und Alter der originären Lösung sollte eine genaue Begutachtung erfolgen. Nicht jeder ISV ist in der Lage, seine Branchenlösung kontinuierlich an die neuen Updates des Herstellers anzupassen; manche sind zwar in der aktuellsten Version verfügbar, weisen aber eine ungeeignete, weil veraltete Architektur aus. Man hat schlichtweg nicht die Zeit, die eigene Lösung an die neuen Funktionen und Architekturen komplett anzupassen, macht es manchmal auch den Nutzen der Branchenlösung selbst zunichte.

Wolfgang Enking: Die heutige Dynamik in der IT ist der wesentliche Grund für den schnellen technologischen Fortschritt. Insbesondere Cloud-Technologien bieten viele neue Möglichkeiten. Die Unternehmen werden damit vor enorme Herausforderungen gestellt, denn einerseits will man den Zug ja nicht verpassen, aber Schritt zu halten mit der Flut von Neuerungen ist extrem schwierig. Wie Sven schon sagte: Die akkurate Dokumentation der Prozesse und der damit verbundenen Daten ist der Schlüssel zum Erfolg. Je besser die Systemlandkarte, desto einfacher gelingt es, neue Technologien und Erweiterungen zu nutzen oder auszusperren.

Blicken wir zum Abschluss noch einmal in die Zukunft. Wie geht es für PLM-/ERP-Systeme weiter?

Wolfgang Enking: Wir erwarten eine zunehmende Akzeptanz von Cloud-Systemen auch in Deutschland. Damit sind viele neue Möglichkeiten verbunden, Prozesse im Unternehmen neu zu gestalten und zu vereinfachen. Wir werden uns immer mehr damit befassen, zu überlegen, welche Prozesse durch Systeme, Assistenten oder Roboter umgesetzt werden sollte und welche Aufgaben und Entscheidungen durch die Mitarbeiter verantwortet werden sollten. PLM- und ERP-Systeme spielen hier eine zentrale und wesentliche Rolle. Wir sind bereit, die Brücke in die Zukunft gemeinsam mit unseren Kunden zu bauen. Es bleibt spannend, was wir in diesem Umfeld in den kommenden Jahren erleben werden …

Vielen Dank an Sie beide für dieses informative Gespräch. Ich wünsche Ihnen noch viel Erfolg und gutes Gelingen in Ihren Projekten.

Virtuelle Welten auf der Hamburg Social Media Week

In der vergangenen Woche habe ich mal wieder einen Blick über den PLM – Tellerrand gewagt. In Hamburg fand die Hamburg Social Media Week statt und eine Veranstaltung hatte mein Interesse geweckt: „Hamburgs virtuelle Welten: Was entsteht hier an Virtual Reality?“. Virtual Reality? Ist das nicht im PLM-Kontext ein alter Hut? Ich kann mich an meine Anfänge als Junior Consultant am Anfang des Jahrtausends bei einem europäischen Flugzeughersteller erinnern. Dort gab es schon zu dieser Zeit eine Arbeitsgruppe „Augmented Reality“. Dinge wie digitale Mockups waren zwar noch immer eine Herausforderung für die Rechnertechnik, aber doch auch kein Hexenwerk mehr. Heute sind DMUs und eine virtuelle Produktentwicklung eher Standard als Ausnahme. Daher war ich gespannt, ob ich neue Anregungen auf dieser Veranstaltung gewinnen kann.

Auf dem Podium wurden drei Protagonisten der Hamburger Digitalwirtschaft vorgestellt. Die Hamburger Kreativ Gesellschaft hatte Fabio Buccheri, Gründer & CEO von NOYS – VR MUSIC, Julian Weiß, Gründer & CEO von headdraft und Simon Graff, VR-Experte und Berater zu einem Podiumgespräch geladen. NOYS – VR MUSIC ist eine Plattform für virtuelle Konzerte von aufstrebenden Musikern. Der Künstler kann sich seine Konzertumgebung selber bauen. Besucher kommen dieses Konzert in der Virtualität besuchen und können und mit den Musiker interagieren. Headdraft möchte die Produktionsprozesse in der Filmindustrie virtualisieren und somit neue kreative Ansätze erlauben und die Kosten senken. Simon Graff ist als Berater tätig und kann als alter VR-Hase auch in seiner Freizeit nicht davon lassen. Er entwickelt mit Freunden zusammen ein Spiel, das in der Cyberpunkwelt angesiedelt ist. All dies ist jetzt nichts, was einen direkten und offensichtlichen Bezug zum PLM hat, aber folgende Gedankenspiele sind doch einige Überlegungen wert.

Die virtuelle Welt

Fabio stellte dar, dass die Hardware, die auf der Konsumentenseite notwendig ist, überhaupt erst seit vielleicht 18 Monaten verfügbar ist. Die meisten kennen ja diese nette Werbung, als Papa den Helden gibt und seiner kranken Tochter das Konzert der Lieblings-Boyband aufnimmt und sie es mit der VR-Brille doch irgendwie miterleben kann. Wir stehen hier also am absoluten Anfang einer technologischen Entwicklung und jeder weiß, wie groß Entwicklungssprünge in der IT gerade in der Phase sein können. Wie technologisch ausgereift werden diese Endgeräte erst in drei oder in fünf Jahren sein? Und welche immense Verbreitung werden sie haben?

Das wird dazu führen, dass diese Devices auch in der Produktentwicklung ein ganz normales Werkzeug werden und damit unsere DMU um eine ganze interaktive Dimension erweitern. Und das gerade junge Nachwuchskräfte in der Industrie ganz natürlich davon ausgehen, dass sie diese Geräte auch in Ihrer Arbeit einsetzen können. Oder das sich Startups gründen und genau in diesem Feld der Produktentwicklung tätig werden. So wie es Julian in der Filmindustrie tut.

Ein weiterer Aspekt dieser Virtualisierung ist die Ausbildung. Training im Service oder in der Montage können entweder frontal per Powerpoint-Folien und gedruckter Manuals erfolgen oder interaktiv in der virtuellen Welt. Ich kann mir nicht vorstellen, dass man in einem solchen virtuellen, alle Sinne ansprechenden Training vor Langeweile einschlafen kann. Gleichzeitig erschließen sich hier weitere Möglichkeiten, auch Prozess- und Methodenwissen zu schulen. Zum Beispiel könnte man Prozesse aus Qualitätsmanagement in einer virtuellen Trainingsumgebung richtiggehend erlebbar machen. Die Möglichkeiten sind mannigfaltig.

Und zu guter Letzt ging mir noch das folgende Szenario durch den Kopf. Die Virtualität wird als zusätzlicher Bestandteil des Produktes gesehen und muss parallel dazu mitentwickelt werden. Sie wird Teil der Produktstruktur des Verkaufsartikels und ergänzt diesen um etwas, was es heute noch gar nicht so richtig gibt. Dann müssen Entwicklungsprozesse synchronisiert werden und Betrieb sowie  Service der virtuellen Welt gewährleistet werden.

Allen drei Szenarien ist gemeinsam, das es eine klare Verbindung zum PLM gibt. In allen Fällen werden digitale Produktdaten benötigt oder diese um weitere Bestandteile angereichert. Ebenso wie PLM-Prozesse sich dahingehend ausrichten müssen, diese virtuellen Welten zu nutzen oder zu unterstützen. Manch ein Leser wird jetzt vielleicht denken, dass diese Schlussfolgerungen etwas weit hergeholt sind. Das mag durchaus sein. Aber denken wir mal vielleicht 20 Jahre zurück. Wurde 3D-CAD damals nicht ähnlich bewertet? Ich freue mich auf eine Ihre Meinungen in den Kommentaren.

 

 

 

  

Agilität in PLM-Einführungsprojekten

Auch wenn es vielleicht manchmal den Anschein hat, dass PLM-Blogger den ganzen Tag und die ganze Nacht nicht anderes tun, als über PLM nachzudenken, so muss ich doch mit diesem Mythos ein wenig aufräumen. Nein, auch wir haben so etwas wie ein privates Leben und das hatte mich in den letzten Monaten doch stark im Griff. Somit ist leider etwas Zeit ins Land gegangen, bevor ich wieder zum Schreiben eines Blogartikels kam.

Meine Erfahrungen mit agilen (Software-)Projektmanagementmethoden bei der Einführung von PLM-Systemen sollen heute im Fokus dieses Artikels stehen. Und es wird nicht nur bei diesem einem Blogpost bleiben. Dieses Thema gibt Stoff für mehrere Artikel her und so wird eine kleine Serie darüber entstehen.

Scrum

Wenn ich im hiesigen Kontext von agilem Projektmanagement spreche, meine ich damit hauptsächlich Scrum als Vorgehensmodell und Kanban als unterstützende Projektmethode. Ehemalige Kollegen von mir konnten auch schon Erfahrungen mit extreme Programming sammeln und vielleicht lassen die sich ja mal zu einem Gastbeitrag hinreißen. Aber wie komme ich eigentlich darauf, dass agile Softwareentwicklung und eine Einführung oder Erweiterung eines PLM-Systems so gut zusammenpassen?

Am Anfang eines jeden PLM-Projekts steht der Wunsch nach einer Verbesserung des Engineeringprozesses oder eines Teilaspektes davon durch eine Softwareunterstützung. Das aktuelle Toolset passt aus verschiedenen Gründen nicht mehr (auch MS Excel hat seine Grenzen) oder bisherigen manuelle Prozesse sollten durch Software unterstützt werden. Gründe derer gibt es viele und somit auch mehr oder minder genau formulierte Anforderungen an die zukünftige Lösung. Die werden natürlich aufgeschrieben, in einem Benchmark mit unterschiedlichen PLM-Lösungen bewertet und sich dann für das richtige Tool entschieden.

Beim klassischen Vorgehen würde dann als erstes eine möglichst genaue Anforderungsspezifikation geschrieben werden. Der Stakeholder schildert seine Vorstellungen, die auf seinem bisherigen Erfahrungen mit dem Legacy-Toolset und mit dem, was er im Benchmark von neuen PLM-Tool gesehen hat, basieren. Die intellektuelle Leistung des Stakeholders, die dabei erbracht werden muss, ist immens. Er muss sich dabei seine bisherige Arbeitsweise vor seinem geistigen Auge mit dem neuen Werkzeug vorstellen und seine Anforderungen in verständlicher Form kommunizieren. Sicher gibt es viele Werkzeuge des Anforderungsmanagements, die hier unterstützen. Aber das Produkt dieser Arbeit ist eine Spezifikation, wie das zukünftige PLM-Tool arbeiten soll. Und auf Basis dieses Aufschriebs wird dann das PLM-Werkzeug angepasst, konfiguriert und programmiert. Und manchmal kommt sogar etwas raus, dass dem Anwender nutzt und er gebrauchen kann.

In einer agilen Vorgehensweise ersetzt man diesen Aufwand des Anforderungsanalyse durch eine direkte Kommunikation zwischen Stakeholder und Programmierer. Der Stakeholder schildert seine Anforderungen mündlich und der Implementierer kann direkt nachfragen, wenn Unklarheiten existieren. Des Weiteren hat der Consultant die Möglichkeit, dem Stakeholder best practice Ansätze und Standardlösungen in seinem Werkzeug zu zeigen, die vielleicht seine Anforderungen nicht zu 100% treffen. Die aber den Stakeholder potenziell begeistern können und ihm weitaus bessere Lösungen zeigen, als er bisher im Kopf hatte.

Kommunikation Diesen Effekt hatte ich einige Male in meiner Projektvergangenheit: Als Implementierer “verbiegt” man das PLM-System, damit man genau die in der ausführlichen Analyse aufgenommen Anforderungen umsetzt. Sonst ist ja der Kunde nicht zufrieden. Und dann schaut sich der  mal aus Zufall die Standardlösung an und findet die viel besser als das, was er sich ausgedacht und was er jetzt bekommen hat. Und über dieses Dilemma “Standard vs. Anpassung” und die Folgen (Hohe Implementierungskosten, Updatefähigkeit, Service und Support) habe ich mich in einem vergangenen Artikel bereits ausgelassen.

Neben diesem Aha-Effekt gibt es noch weitere Aspekte, die für eine agile Vorgehensweise bei der Einführung oder Weiterentwicklung eines PLM-Systems sprechen:

Minimierung der Unsicherheit in der Anforderungsanalyse:

Da Stakeholder und Implementierer direkt miteinander kommunizieren und alle Fragen im direkten Gespräch geklärt werden können, ist die Unsicherheit auf Seiten des Implementierers quasi nicht vorhanden. Missverständnisse in der Interpretation von Anforderungen können so kaum entstehen.

Höhere Transparenz durch sichtbare Zwischenergebnisse

Durch die unmittelbare Mitarbeit des Stakeholders und die iterative Vorgehensweise können schneller Ergebnisse präsentiert werden. Das Vertrauen auf beiden Seiten, in die richtige Richtung zu programmieren, wächst.

Basisanforderungen (Kano-Modell) werden nicht vergessen

Basisanforderungen sind laut dem Kano-Modell Anforderungen, die so selbstverständlich sind, dass sie vom Kunden nicht gesondert benannt werden. Sie führen bei Nichterfüllung zu maximaler Unzufriedenheit. Bei einer agilen Vorgehensweise fallen fehlende Basisanforderungen bereits während der gemeinsamen Entwicklung auf und somit zu einem maximal frühen Zeitpunkt.

Vetown-sign-822236_1280rhinderung von Goldplating

Funktionen, die zwar schön Aussehen, aber keinen wirklichen Nutzen bringen, fallen bei einer guten Priorisierung der zu entwickelnden Features schnell auf und werden bei jeder Sprintplanung neu auf den prüfstand gestellt. Somit werden wirklich nur Softwarefunktionen entwickelt, deren Nutzen klar dargestellt werden werden kann. Ich werde in einem der nächsten Blogartikel auf dieses Thema noch genauer eingehen.

Auf der anderen Seite ist eine agile Vorgehensweise auch an bestimmte Randbedingungen geknüpft, damit die oben beschriebenen positiven Effekte auch wirklich eintreten können. Als wichtigster und zentraler Punkt ist dabei die Kommunikation zwischen Stakeholder und Implementierer zu nennen.

Räumliche Trennung

Unternehmenssoftware wie PLM-Systeme sind fast immer standortübergreifend im Einsatz und somit sitzen die Stakeholder auch meist an verschiedenen Orten und Ländern. Sicher gibt es heute Videokonferenzen und andere Möglichkeiten der virtuellen Zusammenarbeit. Diese können durchaus eine Hilfe sein, um Entfernungen zu überbrücken. Aber trotz aller modernen Technik möchte ich hier eine Lanze für die gemeinsame Arbeit an einem Ort brechen. Meine Erfahrung zeigt, dass bereits unterschiedliche Räume am gleichen Standort zu Störungen in der Kommunikation führen können. Ein gemeinsamer Projektraum, in dem dann jeweils die relevanten Stakeholder temporär einziehen, trägt in einem großen Maß zum Projekterfolg bei.

Die berühmten “social skills”

Stakeholder und Implementierer müssen einfach “miteinander können”. Gerade auf Seiten des Implementierers ist neben dem technischen Wissen ein gerütteltes Maß an kommunikativen Skills notwendig. Er muss sich auf unterschiedliche Stakeholder einstellen können und ihn durch den gemeinsamen Entwicklungsprozess führen. Konflikte bleiben in keinem Projekt aus und bei einer agilen Vorgehensweise müssen diese im gemeinsamen Gespräch “an der Basis” gelöst werden. Ein gewisses Talent zum Hineinversetzen in die Lage des anderen schadet da auf keinen Fall. Bei internationalen Projekten kommt noch das Wissen um kulturelle Unterschiede und Fremdsprachen dazu.

Zeitliche Verfügbarkeit  der Stakeholder

Stakeholder sind in agile Projekte stark eingebunden und arbeiten Hand-in-Hand mit den Implementierer zusammen. Das ist nicht möglich, wenn sie für die Projektarbeit nur einen Teil Ihrer Zeit aufwenden können. Während der Implementierung ist eine nahezu einhundertprozentige Verfügbarkeit unbedingt erforderlich. Belohnt wird das mit genau der PLM-Funktionalität, die benötigt wird und Expertenwissen, dass beim Unternehmen verbleibt, wenn der Implementierer längst zum nächsten Kunden weitergezogen ist.

Technische Randbedingungen

Was aus technischer Sicht notwendig ist, um PLM-Systemanpassungen mit einem agilen Vorgehen ausliefern zu können, wird Thema von mindestens einem weiteren Blogartikel sein. Aspekte wie Continuous Deployment and Integration oder Test-driven Development verlangen nach mehr als einem kurzen Absatz.

Mit diesem Ausblick auf weiteren Lesestoff zur Agilität bei PLM-Softwareeinführungen möchte ich heute enden. Über Kommentare, Anregungen, Erfahrungen oder auch Kritik würde ich mich sehr freuen. Die Kommentarfunktion ist genau richtig dafür.

Feld-, Wald- und Wiesen-PLM

Vor einigen Tagen lies ich mich mal wieder durch das Internet treiben. Um genau zu sein, habe ich als erstes nach dem Begriff “PLM” in der Suchmaschine meiner Wahl gesucht, um herauszufinden, auf welcher Ergebnisseite dieser Blog auftaucht. Nachdem meine Tränen der Enttäuschung ob des niederschmetternden Ergebnisses getrocknet waren, sprangen mir seltsame Links ins Auge. Die sprachen bei PLM auf einmal von “Precision Land Management”. Geprägt durch mein Elternhaus habPLM und Landwirtschafte ich durchaus eine Verbindung zur Landwirtschaft und begann voller Interesse zu lesen. Beim obigen Begriff scheint es sich um eine Art Markenbegriff des Landmaschinenherstellers New Holland zu handeln, wobei natürlich auch alle anderen Landmaschinenhersteller sich des Themas intensiv widmen. Weiteres Eintauchen zeigte mir eine bis dato eher nicht so bekannte, aber sehr faszinierende Welt der Verbindung zwischen IT und Agrarwirtschaft mit einer heterogenen Anbieterlandschaft. Dieser Blogartikel soll einmal genauer hinschauen, welche Verbindungen zum PLM (jetzt im Sinne des Product-Lifecycle-Management) gezogen werden können.


Als Erstes fallen einem Ingenieur bei der geistigen Visualisierung eines landwirtschaftlichen Betriebes die ganzen Maschinen und Anlagen ein:

  • Traktoren, Schlepper, Mähdrescher und weitere Fahrzeuge unterschiedlichster Art
  • Arbeits- und Anbaugeräte wie Pflüge, Häcksler, Mähwerke, Mulcher  
  • Fest installierte Anlagen und Geräte (Melkmaschinen, Futteranlagen, Wasserversorgung)

Das klassische Einsatzgebiet von PLM ist bei diesen Maschinen, Geräten und Anlagen die Unterstützung des Produktentwicklungsprozesses auf der Herstellerseite. Moderne landwirtschaftliche Maschinen haben nichts gemein mit der verklärt-romantischen Vorstellung eines zufriedenen,  vor sich trottenden Pferdes mit einer Pflugschar dahinter. clydesdale-1106337_1280Der Grad an Elektronik und Software in den Maschinen ist immens und beeindruckt nicht nur in der Funktion. Vor den Konfigurationsmanagern bei den Herstellern, die hier Mechanik-, Elektronik- und Softwareentwicklung unter einen Hut bringen, ziehe ich den selbigen. Das ist PLM at its  best.

Ein weiterer PLM-Aspekt ist, dass das Produkt eben nicht nur aus der Maschine oder Anlage selbst besteht, sondern zunehmend Dienstleistungen originärer Teil des Produktes sind. Ein Beispiel wären hier Serviceverträge für die Wartung und Instandhaltung oder Vernetzungs- und Ortungsfunktionen (GPS) zu nennen. Diese Dienstleistungen sind integraler Bestandteil des Produktes, haben aber einen eigenen Lebenszyklus (z.B. eine Laufzeit) – eine weitere Herausforderung auf dem Spielfeld des PLM.

Und wenn wir schon bei Service und Wartung sind, sind wir auch beim Thema  Ersatzteilversorgung. Die Verfügbarkeit von landwirtschaftlichen Geräten ist ähnlich kritisch wie der Betrieb eines PLM- oder ERP-Systems in einem Produktionsunternehmen. Oder wie lange kann ein Landwirt auf eine ausgefallene Melkanlage verzichten, wenn jeden Tag 200 Kühe gemolken werden wollen? Oder der Mähdrescher mitten in der Getreideernte kaputt gegangen ist? Der Service muss dann die korrekte Konfiguration der Anlage kennen oder zumindest schnell ermitteln können, um das passende Ersatzteil auch ausliefern zu können. Und gerade bei Elektronik gibt es aufgrund des rasanten technischen Fortschritts das Thema Obsoleszenz zu berücksichtigen. Wie ist der Weiterbetrieb sichergestellt, obwohl das defekte Elektronikbauteil gar nicht mehr verfügbar ist. Weil es dem technischen Fortschritt zum Opfer gefallen ist und gar nicht mehr hergestellt wird. Allein darüber kann man über mehrere Blogartikel lang philosophieren.

Während des Betriebs von landwirtschaftlichen Maschinen und Anlagen entstehen auch eine Menge Daten. Einen sehr schönen Abriss über “Industrie 4.0” und “Big Data” in der Agrarwirtschaft gibt ein Artikel in der Zeit. Beim Lesen des Artikels kam mir der Gedanke, dass bei einem Mähdrescher oder einem Traktor auch die Umgebung als Teil des Produktes und damit des Lebenszyklusmanagements gesehen werden muss. So ein Acker ist eben kein steriler Operationssaal und Verschleiß durch Erde, Wetter und Korrosion spielen natürlich eine gewichtige Rolle auf die Lebensdauer des Produktes. Aber gerade beim GPS-gesteuerten zentimetergenauen Ausbringen von Saatgut oder Dünger stellt sich schon die Frage, ob Verschleiß nicht signifikanten Einfluss auf die Quantität der Ausbringung nimmt. Vielleicht wird dies ja bereitsclouds-978964_1280 durch intelligente Produkte, die dies selbst nachregeln können, bewältigt. Falls sich ein Leser damit auskennt, wäre ein Kommentar toll.


Aber auch generell sind natürlich alle Daten, die heute so ein Schlepper oder Mähdrescher erzeugt, ein wertvoller Schatz für jeden Hersteller. Diese Daten liefern Hinweise für Produktverbesserung und -innovation und fließen in die Produktentwicklung des Herstellers ein – ein klassischer Anwendungsfall des Product-Lifecycle-Managements.

Mit diesem Gedankengang möchte ich diesen Blogartikel beenden. Natürlich schließt sich die Bitte an, von der Kommentarfunktion reichlich Gebrauch zu machen. Gerade hier möchte ich mal Landwirte und sonstige Experten aus der Agrarwirtschaft bitten, ihre ganz persönliche Sicht der Dinge zu schildern. Ich bin mehr als gespannt.     

 

Der PLM-Talk – heute mit Dr. Markus Sachers, (PROSTEP AG)

Meine virtuelle Interview-Couch hat wieder einen Gast beherbergt. Nach Blicken über den Tellerrand in Richtung IT-Servicemanagement und einem Ausflug in das Konfigurationsmanagement geht es heute um nichts als reines PLM. Ich freue mich sehr, dass mit Dr. Markus Sachers ein ausgewiesener Kenner der Materie mir meine Fragen beantwortet hat.

Herr Dr. Sachers, als langjähriger Geschäftsführer innerhalb der PROSTEP Gruppe und designierter Leiter des Geschäftsfeldes PLM Strategie und Prozesse ist Ihr Name eng mit der PROSTEP Gruppe verbunden. Können Sie vielleicht ein paar Worte verlieren, wie Sie zur PROSTEP gekommen sind und wo Sie mit dem Virus PLM infiziert wurden?

Dr. Markus Sachers

Dr. Markus Sachers

Gerne. Bereits während meiner Promotion habe ich mich mit dem Thema der durchgängigen, IT-gestützten Produktentwicklung beschäftigt. Fokussiert waren meine Arbeiten damals – Mitte der 1990er Jahre – noch auf die CAD-CAM-Kopplung und die durchgängige Auftragsbearbeitung für Einzel- bzw. Kleinserienfertiger. Dabei spielte die Definition und Entwicklung notwendiger Datenschnittstellen eine entscheidende Rolle. PROSTEP – sowohl der ProSTEP Verein als auch das Unternehmen – haben damals schon wesentlich zur internationalen Standardisierung im Bereich des Produktdatenmanagements bzw. dessen Verbreitung beigetragen. Ich hatte auch in meinen Arbeiten durch die Nutzung des STEP-Standards damit zu tun, so dass ich nach Beendigung der Promotion gleich bei der PROSTEP AG (damals war es noch die GmbH) als Berater einstieg.

Der ProSTEP iViP e.V. als auch die PROSTEP AG engagieren sich in vielfältiger Weise im Product-Lifecycle-Management. Wo sind dabei die Schwerpunkte der Arbeit und was unterscheidet dabei den Verein von der AG?

Der ProSTEP iViP Verein als Non-Profit-Organisation ist ein Zusammenschluss von Unternehmen, Softwareherstellern, IT-Dienstleistern, Hochschulen und Forschungseinrichtungen. Er entwickelt zukunftsweisende Standards, Empfehlungen und Lösungsansätze für das Produktdatenmanagement und die virtuelle Produktenstehung.

Konkrete Beispiele der letzten Zeit sind Standards und Empfehlungen, die von Arbeitsgruppen zu den Themen Digital Manufacturing, ECAD, Requirements Management, Einsatz des JT-Visualisierungsformates, „Code of PLM Openness“ oder Langzeitarchivierung von PDM/CAD-Daten erarbeitet wurden.

PROSTEP_tag_rgb_hoch50pixDie PROSTEP AG ist als IT-Lösungsanbieter eigenständig am Markt mit Dienstleistungen und Produkten im Bereich PLM aktiv. Unsere Schwerpunkte liegen auf der Entwicklung von Unternehmens-weiten und -übergreifenden PLM-Konzepten, deren Bewertung und Einführung, der Integration von PDM und CAD-Systemen sowie der PDM/CAD-Migration. Dabei sind wir meistens als „Mittler“ zwischen den Fachbereichen und der IT aktiv. In allen Projekten bringen wir auch immer aktuelle Technologien und Standards – nicht nur aus dem ProSTEP iViP Verein – ein. Unsere vielfältigen Projekterfahrungen aus inzwischen über 20 Jahren PLM-Projekten sind dabei natürlich zentraler Bestandteil unserer Lösungen für unsere Kunden.

Seit der jüngeren Vergangenheit ist der Name PROSTEP mit der Initiative „Code of PLM Openness CPO“ verbunden. Was war die Motivation des ProSTEP iViP Vereins zur Unterstützung des CPO und in welcher Form passiert dies?

Treiber für den CPO waren in erster Linie Fertigungsunternehmen, die einen hohen Bedarf haben, PLM-Systeme in sehr heterogene IT-Landschaften integrieren und diese dann betreiben zu müssen. Dazu sind PLM-Systeme notwendig, die weitestgehend „offen“ sind, d.h., die offene Schnittstellen und transparente Architekturen aufweisen. Aber nicht nur technische Eigenschaften sind für die notwendige Offenheit relevant. Auch Vereinbarungen zwischen Anwenderunternehmen und Systemherstellern zu organisatorischen Regelungen – wie angemessene Partnerschaftsmodelle mit IT-Dienstleistern für Customizing-Leistungen, abgestimmte Produktrelease-Roadmaps, System-Kompatibilität mit Third-Party-Produkten und ähnlichem – sind wesentliche Aspekte.

Der ProSTEP iViP Verein Open PLMwurde dafür als bestens geeignete Plattform gewählt, um ein grundsätzliches Regelwerk zwischen Anwenderunternehmen, Systemherstellern und IT-Dienstleistungen gemeinsam zu erarbeiten. Inzwischen haben sich bereits über 80 IT-Kunden, IT-Anbieter und IT-Dienstleister zum Code of PLM Openness bekannt.

Die Grundsatzregeln aus dem CPO können als Basis für konkrete, messbare Vereinbarungen in den Lizenz- bzw. Pflegeverträgen zwischen Unternehmen und Systemanbietern verwendet werden. Bei der Durchführung entsprechender spezifischer Anpassungen und Konkretisierungen unterstützen wir von PROSTEP wiederum die Unternehmen.

Der „Code of PLM Openness“ ist ja nur ein Thema, dass unter der PROSTEP-Fahne segelt. Wo setzen Sie derzeit in Ihrer täglichen Arbeit gerade ihren Fokus?

Tatsächlich beschäftigen wir uns in unseren Projekten bei unseren Kunden in der letzten Zeit stark mit PLM-Einführungs- und Migrationsprojekten.

Neben den Branchen der Automobil- und Flugzeugindustrie, die ja bereits seit vielen Jahren die Einführung und den Roll-out konsolidierter PLM-Systeme betreiben, haben wir zunehmend Projekte in anderen Branchen der Fertigungsindustrie, die sich mit der Einführung von kommerziellen PLM-Systemen beschäftigen. Dabei bearbeiten wir in unseren Projekten alle Aufgabenstellungen von der strategischen Auswahl von Systemen (z.B. durch Unternehmens-spezifisches Benchmarking) über die Spezifikation und Implemetierung von Integrationslösungen bis zur Roll-out-Planung und –Unterstützung.

Auch die Datenmigration zwischen PLM-Systemen spielt zur Zeit eine erhebliche Rolle. Besonders Unternehmensveränderungen – wie Merger und Acquisitions, die Gründung von Joint Ventures oder die Auslagerung von Unternehmensteilen (Carve-out) – erfordern die Migration von PLM-Daten zwischen unterschiedlichen Systemen. In unseren Projekten sind PLM-Daten in erster Linie alle Entwicklungs- und Konstruktions-relevanten Daten, also natürlich auch CA-Daten, die in PLM-Systemen besonders integriert sind – sowohl methodisch, als auch von den Datenmodellen her. Hier setzen wir gerade mit unserer Expertise Lösungen um.

Sie blicken persönlich auf eine langjährige Erfahrung in der Planung und Unterstützung von PLM-Projekten zurück. Was hat sich in den letzten 10 Jahren verändert? 

In den letzten Jahren hat der Einsatz von kommerziellen PLM-/PDM-Systemen stetig zugenommen. Der Druck auf IT-gestützte Unternehmensprozesse, effizienter zu werden, bei gleichzeitiger Forderung nach reduzierten Wartungs- und Betriebskosten von IT-Systemen führt immer weitreichender zur Einführung bzw. zum Ausbau der Einsatzbereiche von PLM-Standardsoftware in den Unternehmen.

Dabei spielt die Integration der Prozesse und Systeme aus unterschiedlichen Domänen eine zentrale Rolle. Nicht nur Kernprozesse und –Daten aus der Entwicklung und Konstruktion – wie CAD-Daten, Produktstrukturen (z.B. verschiedene BoM-Sichten), Versionen und Konfigurationen oder Freigabeprozesse – werden in PLM-Systemen abgebildet, sondern auch zunehmend Bereiche wie Berechnung und Simulation (z.B. SDM-Systeme) oder Elektrik-/Elekronik- und Softwareentwicklung (z.B. ALM-Systeme). Treiber dafür ist häufig nicht nur eine steigende Produktkomplexität oder die immerwährende Forderung nach Effizienzsteigerungen, sondern auch die wachsende Erkenntnis, dass nur eine ganzheitliche Betrachtung der PLM-relevanten Prozesse und IT-Systeme im Unternehmen einen maximalen Nutzen bringt. Wir erreichen dies in unseren strategisch ausgerichteten Kundenprojekten zum Beispiel durch den Einsatz der Analyse- und Definitionsmethoden des „Enterprise Architecture Managements (EAM)“.

Eine weitere Entwicklung sind die vielen Unternehmenszusammenschlüsse und –Aufkäufe (Mergers & Acquisitions) der letzten Jahre in der Fertigungsindustrie. Wir haben bei unseren Kunden daher einen großen Anteil an PLM-Integrations- und Migrationsprojekten. Hier sind Lösungen gefragt, die den unterschiedlichen fachlichen und organisatorischen Voraussetzungen der Kunden Rechnung tragen. Beispielsweise können sowohl „Big Bang“-Migrationen als auch Lösungen auf Basis der temporären Koexistenz von Systemen sinnvoll sein. Beides verwenden wir in unseren Projekten.

Und wenn wir in die Vergangenheit schauen, darf auch der Blick in die Zukunft nicht fehlen: Was wird aus Ihrer Sicht das PLM-Projekt 2025 vom PLM-Projekt im Jahr 2015 unterscheiden?

PLM-Projekte werden sich zukünftig natürlich anhand der generellen Ausrichtung und Entwicklung von PLM in der Industrie in den kommenden zehn Jahren ausrichten. Und hier wird sich meines Erachtens ein starker Einfluß der „Digitalen Transformation“ auswirken. Als Digitale Transformation bezeichnen wir den – in vielen Bereichen bereits begonnenen – Wandel hin zu ganz neuen Produkten und Geschäftsmodellen, basierend auf einer zunehmenden Digitalisierung von Daten aus allen Lebensbereichen („Big Data“) und digitaler Vernetzung (z.B. „Smart Factory“, „Smart Product“, „Smart Service“ u.a.) auf allen Ebenen der industriellen Wirtschaft. In der Fertigungsindustrie beginnt das „Internet der Dinge“ bereits heute Daten, insbesondere aus Produktion („Industrie 4.0“), Logistik und dem After Sales, in einer Weise zu erfassen, wie es traditionell nicht möglich war. Dies wird zu einer zunehmenden Individualisierung von Produkten – auch in neuen Kombinationen mit Nutzer-spezifischen Funktionalitäten oder Dienstleistungen – führen, so dass die Komplexität der Produkte und deren Steuerung über den gesamten Lebenszyklus steigt. Dies führt nicht nur zu deutlich erhöhten Anforderungen an PLM-Konzepte und –Systeme auf der einen Seite, PLM wird auf der anderen Seite auch gerade ein zentraler Baustein für die erfolgreiche Umsetzung der digitalen Transformation in Unternehmen sein.

In der Zukunft werden wir die Einführung und Erweiterung von PLM-Systemen durchführen, die beispielsweise deutlich stärker vernetzt sein werden mit anderen Systemen oder zusätzliche Such- und Vernetzungs-Funktionalitäten erhalten werden. Letzteres ist bereits in Ansätzen durch PLM-Systemanbieter in der Vorbereitung. In diesem Zusammenhang werden wir, noch intensiver als heute schon, Konzepte des Anforderungs- und Wissensmanagements in PLM-Systemen umsetzen. Die erhöhte Verfügbarkeit von Daten aus dem gesamten Produktlebenszyklus werden sich darüber sowohl für die Verbesserung und Individualisierung vorhandener Produkte, als auch für die Entwicklung neuer Produkte nutzen lassen.

In der Produktentwicklung werden wir sicher eine konsequentere Umsetzung der Methoden des Systems Engineering in PLM-Systemen sehen. Eine Modell-basierte, ganzheitliche Entwicklung von mechanischen, elektronischen und Software-Komponenten wird aufgrund der genannten Trends verstärkt Einzug in PLM-Konzepte und –Systeme finden. In unseren heutigen PLM-Projekten entwickeln wir bereits Konzepte und Lösungen mit unseren Kunden für einige der genannten Methoden und Prozesse.

Herr Dr. Sachers, ich danke Ihnen für dieses Gespräch und wünsche Ihnen für Ihre kommenden Projekte viel Erfolg.