Showing posts with label OOTB. Show all posts
Showing posts with label OOTB. Show all posts

Monday, February 4, 2013

Strategie für PLM-Standardsoftware

Product Lifecycle Management-Plattformen sind – neben ERP und CRM – ein Eckpfeiler moderner Unternehmens-IT. Gleichzeitig hat aktuelle PLM-Standardsoftware einen hohen Reifegrad erreicht, so dass in vielen Unternehmen die Ablösung der ersten Generation von PLM (-Individualentwicklungen) geplant wird. Eine tragfähige Lösung kann nur geschaffen werden, wenn die Spezifika von PLM-Standardsoftware in der PLM-Strategie berücksichtigt werden. So kann mit einer dedizierten PLM COTS Policy (commercial-off-the-shelf) zum Beispiel der große Block der Wartungs- und Betriebskosten nachhaltig gesenkt werden. Oder es können Risiken bzgl. Herstellerabhängigkeit gezielt adressiert werden.

Herausforderungen beim Einsatz von PLM-Standardsoftware

Die Entscheidung für PLM-Standardsoftware ist oft ein Paradigmenwechsel, der als solcher erkannt und gemanagt werden muss. Wenn vorher mit Individualentwicklungen jede Anforderung der kreativen Benutzer erfüllt werden konnte,  ist nun ein ständiger Abgleich zwischen Anforderungen und den Möglichkeiten der Software nötig. Damit diese Kluft nicht zu groß wird, müssen die Ziele und Prioritäten des PLM-Anbieters mit der eigenen PLM-Stategie zusammen passen bzw. passend gemacht werden. Dies ist bei großen Anbietern nicht einfach und erfordert abgestimmtes Vorgehen zwischen IT, Fachbereichen und Einkauf.

Optimierter Einsatz von PLM-Standardsoftware durch eine PLM COTS Policy

Ein Architekturprinzip wie „buy over make“ ist ein guter Anfang. Allerdings muss das Prinzip operationalisiert werden, z.B. durch Trainings für Projektleiter und Architekten oder durch Checklisten für die Betriebsfähigkeit einer Lösung.
Eine gute PLM COTS Policy zeichnet sich unter anderem durch folgende Punkte aus:
-         Strategisches Alignment: durch Deduktion aus der PLM-Strategie entsteht eine PLM COTS Policy, die nachweisbaren Nutzen für das Unternehmen bringt
-         Differenzierung: innovative, wettbewerbs-differenzierende Lösungen können nicht immer mit Standardsoftware geschaffen werden. Eine gute COTS Policy liefert Entscheidungskriterien für Abweichungen von „buy over make“.
-         Integration in EAM: die COTS Policy schafft Wege zur Zielbebauung gemäß Enterprise Architecture Management
-         Integration in Sourcing und VRM: Einkauf und Vendor Risk Management sind erfolgskritische Prozesse beim Einsatz von PLM-Standardsoftware

Entwicklung einer PLM COTS Policy

Die PLM COTS Policy lässt sich in drei Ebenen strukturieren.

Neben der strategischen und der operativen Ebene ist insbesondere die mittlere Ebene „pro PLM Bebauungscluster“ wichtig. Hier werden zum Beispiel Lead-Applikationen für MCAD und ECAD definiert oder die TDM-Strategie für das Simulationsdatenmanagement detailliert.
Als Beispiel für die operative Ebene seien Software-Entwicklungsrichtlinien genannt, die auf die Besonderheiten einer PLM-Plattform wie Teamcenter, ENOVIA oder Windchill eingehen. Durch explizite Richtlinien zu Namenskonventionen, Struktur, Pattern etc. sowie durch entsprechende Check-Tools kann die Software-Qualität sichergestellt werden. Dies ist gerade dann wichtig, wenn das PLM-Entwicklungsteam heterogen zusammengesetzt ist oder die Teammitglieder häufig wechseln.

Haben Sie Interesse an diesem Thema? Sprechen Sie uns an! Oder besuchen Sie uns am Stand auf dem ProSTEP-iViP Symposium am 16. und 17. April 2013 in Hannover. Im Vortrag „Product data is our main asset“ werden wir gemeinsam mit Airbus über Erfahrungen bei der Nutzung von PLM-Standardsoftware in großen Unternehmen berichten.

(Cross posting from NTT DATA EMEA Blog)

Sunday, May 15, 2011

iReq - personal requirements engineering

Still waiting for delivery of my iPad 2... Not sure if I really wanted the email on May 12, confirming delivery for May 24. I guess the logistics people at Apple just like torturing their customers.

Solution seeking problem
While waiting for the delivery, I thought about potential use cases. As I didn't find too many, I decided to search the web. I came across a posting from a similar minded person called The iPad: An Elegant Solution in Search of a Problem. My favorite part was his reply to a comment praising the rather balanced posting: “Honestly, it was really hard to write this. I love everything about Apple. And the iPad is gorgeous. I just can't find a real use for it.” That was when I noticed the banner ad at the bottom of the screen. Now that fits.



It seems as if the iPad somehow changes the bottom-up approach of identifying the requirements first and then developing a solution. This is a case where a neat piece of IT inspires new solutions. More specifically: an IT platform that allows seamless integration of new solutions. One of the reasons for me buying an iPad was curiosity about these solutions - and being able to closely follow the evolving state of the art.

Business drives IT, right?
I felt reminded of some PLM discussions that go like this:
Q: What is the best PLM system?
A: That depends on your requirements.
Q: What can it do for me?
A: Everything you want it to do.
Q: What do I want?
A: Right.

Given the scope of today's PLM suites, it's hard to get a complete and consistent set of requirements including prioritization. Vendors keep adding innovative functionality such as compliance management and social product development, while the business is still digesting basic PDM and CAD data management. This is looking more like IT drives Business.

PLM at the crossroads
In this situation, I see two options: you can either continue with the slow but proven bottom-up process of analyzing the processes, specifying requirements, selecting a system, customizing it etc. - business drives IT. Or you could adopt a process of providing OOTB solutions from your PLM vendor of choice and finding a way to apply them in your business. This second option can only work, if the solutions are good - and if you have an IT platform that allows seamless integration of new solutions (hence the iPad). The major PLM suites might provide good solutions for all kinds of problems, but they struggle with the integration into an existing system. Each new module brings along a list of prerequisites and dependencies that still requires major efforts to implement that module.

Conclusion
A PLM platform that wants to support OOTB implementations needs sophisticated mechanisms to separate the customer-specific configuration and customizing from the underlying platform. This would not only ease the integration of new modules, but also the maintenance of the overall system through the release cycle.