Connecting manufacturing professionals to drive continuous improvement!
Methodology for implementing a PLM System
I see more and more that How to implement a PLM System is more important then the selection of a System.
In my projects as a PLM Consultant I use IDEF-0 Methode for analyzing the information in a Company and USe Cases to set up the specifications.
Now I want to know what kind of methods other people use and the experience they have with this method.
If people also use Use Cases, what kind of tools do you use? I use Agilian.
Regards,
Menk Slot
www.plmconsult.nl
In my projects as a PLM Consultant I use IDEF-0 Methode for analyzing the information in a Company and USe Cases to set up the specifications.
Now I want to know what kind of methods other people use and the experience they have with this method.
If people also use Use Cases, what kind of tools do you use? I use Agilian.
Regards,
Menk Slot
www.plmconsult.nl
Tags: implementation methodes, plm
Replies to This Discussion
-
Permalink Reply by Jonathan Scott on -
I would agree with your premise that "how" is more important for PLM than "what". I have analyzed the major systems for clients (Siemens' Teamcenter, Dassault's ENOVIA, and PTC's Windchill), and I find that they are different in minor ways (at their core). The argument can easily be made that one system offers functionality in areas that the others don't, but its usually only a matter of time before the competitors catch up. And of course, it only helps differentiate the vendors if the selecting company needs that particular differentiating functionality.
That being said, I am a fan of Dassault's approach to implementations with their ENOVIA SmarTeam Express offerings (in conjunction with any CAD platform). Having recently reviewed Teamcenter's Velocity series (3.0), I like Dassault's approach much better (much more open and flexible). Unfortunately, I think PTC could have a decent approach with Windchill, but they obfuscate it with an overly aggressive position in the market (they advocate that the only valid solution is to exclusively use their Product Development System - PDS).
Of course, that wasn't really the thrust of your discussion thread. To your point about the "how" of implementation, my experience is that more informal processes are successful in many situations. I cannot disagree with your finding that formal/standard methodologies and tools are helpful (and even critical) for large implementations (project teams larger than 10). For many of my clients however (most of whom are Small-to-Medium Businesses), PLM is a step-wise investment, that typically comes in this order:
- 3D CAD
- 3D CAD file management
- engineering document management (frequently to include ECAD and software)
- Workflow for change management
- BOM management
- integration with other systems (ERP, configurators, etc.)
That being the case, many of these clients choose a less formal implementation approach, with the following steps: 1) requirements, 2) prototype, 3) pilot, 4) iteration, 5) training, and 6) rollout. By making all 6 steps take place in 3-6 months with project teams of 5 or so members, the risk is minimized and the need for more formal deployment processes is reduced.
So in summary, I cannot argue with the methodology you use, but I find that a less formal/standard practice fits many of my clients well.
-
Permalink Reply by Menk Slot on -
I agree with you Jonathan. I also believe that a prototype is the best way to explain the end user what they will get.
The requirements in step 1 should be very clear and easy to read for the end users. Use Cases can be a very helpfull tool to do this.
When you start to write Use cases, the end users should also be involved. I have good experience with Workshops where the Use Cases are written together with the people who are involved in the project.
Every Use Case is split up in functional blocks like creating an Item, document etc. Because of this you can also use it for a step wise implementation. (A step wise implementation is always the best way)
The result of an Use Case can be used for testing. If you use a special tool for making Use Cases you can generate the reports for the different user groups. (Some people use MS-Words and this will generate a large unreadable document)
TeamCenter Express is a predefined TeamCenter Engineering, with User Definable fields. For the System Integrator it will be as flexible as TeamCenter Engineering. They can define Workflows, Create new Item types etc. Only the customer will not have this possibility. If he wants to do this he can always upgrade to TeamCenter Engineering
Regards,
Menk
www.plmconsult.nl
-
Permalink Reply by Jos Voskuil on -
I used IDEF-0 in the past in some 'heavy' consultancy projects - i guess relevant for implementations with a strong top-down approach.
Currenlty, as I am working much like Jonathan with mid-market companies, I realized that the budget and acceptance for thorough analyses and definition is low.
I believe in the same approach as Jonathan, which means:
- know your vision / goals
- build a possible roadmap/direction with 3-6 month steps
- prototype the step and then implement
The advantage is the customer has direct feedback and understanding of what is going to happen.
For explaining scenarios and information flows I use Visio and powerpoint
-
Permalink Reply by Menk Slot on
-
Perhaps you are right for Small companies. I work on a multi site project at this time and we started in the beginning also with a prototype, but for thise kind of projects a prototype is not enough. if the projects become a little bit more complex Use Cases can be the best way to do it.
Regards,
Menk
www.plmconsult.nl
© 2010 Created by Paul Patterson.
