One of the big project level benefits of a PLM implementation is that most PLM solutions can be rolled out to the users in stages. New PLM processes and workflows and modules can be incrementally added after the foundation is laid – this is GREAT and it is TERRIBLE.
It is great that PLM can have core functionality within weeks or months of starting a deployment – systems like Arena Solutions or Teamcenter Express that target the small businesses can be rolled out literally in 1-2 weeks if your business can accept out of the box workflows for change management. For the mid-sized businesses systems such as Agile and Windchill can typically be deployed within 3 to 4 months with core functionality in place. What adds time to these types of deployments is typically dealing with preparing the training program and process documentation associated with implementing these solutions. With the larger enterprises implementing Windchill, Teamcenter or Enovia the enterprise complexities come into play earlier and take longer to deploy at 6-9 months, but even the large enterprises tend to only see a small piece of the PLM vision and only obtain limited benefit due to stopping at change management.
What is terrible is how many PLM systems get implemented without an enterprise roadmap that takes the implementation beyond the foundational deployment. Change management is put in place without enabling the part classification (to enable reductions of duplicated parts). BOMs are built without enabling Multisite or BOM variants (tracking the site specific build data or the engineering vs. manufacturing BOM). Manufacturer and Supplier data is managed with the product information, yet the external partners are still sent CD’s or paper and kept outside the loop on major changes that impact their contribution to the finished product.
Why is this? It is the curse of the initial success of a PLM deployment. When an ERP system is rolled out for the first time (after 2-3 years preparation) it gets turned on with 90% of the functionality in place and then is very cautiously modified mostly for tuning purposed. PLM on the other hand can be rolled out successfully with only 40-50% of the business functionality implemented and considered successful at which point the senior management often thinks the project is done – losing the vision for the other 50-60% of business benefits that have yet to be obtained.
It is this tendency that makes the initial long term roadmap so critical. Without defining what the long term business objectives are that the PLM deployment is to address the execution typically halts after the “engineering” system is in place yet the enterprise enabling capabilities have not even been tapped into. The selection of the system is often targeted at a short term objective, then the longer term benefits may be hindered or require a second PLM system to obtain the next tier of benefit. (See Gartner’s Predicts 2008: Manufacturing IT Becomes More Than Business IT, December 2007)
No company would deploy ERP without a 5 year plan. Yet PLM, which impacts 30-40% more end users than ERP, typically is deployed without a similar long term plan. Then the users and the management end up stymied about why the benefits expected from PLM have yet to be achieved. (See Aberdeen’s July 2007 report – Profiting from PLM: Strategy and Delivery of the PLM Program)
What is your PLM roadmap?
Have you tied the PLM implementation to true business benefit or are you just implementing a data vault?
Do you have a phased plan that identifies the business value obtained from each and every phase?
What many companies will find is that for true understanding of what is possible and what to do to build that roadmap – it takes experts in PLM and in your industry issues to help you build that vision. To expect the IT or Engineering department to vision cast is often not possible – as internal resources often do not have the subject matter or process expertise to cast the PLM initiative into a plan that ties the implementation to direct business strategy.
I found your site on Google and read a few of your other entires. Nice Stuff. I’m looking forward to reading more from you.
Comment by Sue Massey — July 11, 2008 @ 11:01 am |
Thanks for posting again. I always look forward to your articles.
Comment by Daniel Bacon — July 11, 2008 @ 11:05 am |
I just discovered your blog (as you mentioned Teamcenter Express – I do the product marketing for this software). I hope you get some end users to contribute their thoughts about roadmaps.
Even with relatively simple PLM implementations in smaller manufacturing organizations I think a roadmap is essential. Smaller companies typically have limited resources for implementing PLM and focusing on an initial area, such as managing CAD data, and proving the ROI in this area before moving on to the next phase is a fairly typical approach. The roadmap can be used to communicate that this is just a first step and that further ROI will come from further phases such as supporting engineering change processes across multiple departments, or an integration with ERP.
Comment by David Chadwick — July 14, 2008 @ 9:20 am |
David,
I agree completely yet it is the smaller companies that tend to feel that they can’t afford to go thru the roadmap, as they don’t have the internal resources with the subject matter expertise, therefore the cost of services to establish the roadmap is a significant percentage of the overall investment. Yet it is crucial. The companies that do this benefit from having a complete plan, a full set of business targets, and capable users (because of actually training their people), and thus they see REAL results from the implementation. Too often, with tools such as Teamcenter Express, Arena Solutions, and PDMLink, the ease of deployment decieves the customer into thinking that they don’t have to invest in the plan, the training or the definition of processes.
Comment by Laila Hirr — July 14, 2008 @ 10:39 am |
I agree you must know where you are going and why… I would question if change management is the right first feature. That said I agree it is where everyone starts. But must change in a PD project is due to poor communication, as well most PD teams would like to finish right first time and not make any changes. So if most change is due to poor communication and PLM is positioned as a collaboration tool then why not start there and remove the need to process change?
Comment by Chris — October 21, 2008 @ 11:35 am |
Chris -
Great point – good breaking out of the boundaries perspective. Thanks for both of your comments today.
Comment by Laila Hirr — October 21, 2008 @ 11:51 am |
Good article, most don’t understand the need for a sustained roadmap and building up a resistance to allowing individuals that want to go “off-road” to speed up the process.
I agree with Laila, it is a good point Chris. As far as implementing features, it gets back to the focus of the article…the need for a roadmap. Ideally, the roadmap would include a roll out with the Product Development teams in addition to the change management process. The initial focus on change management serves several areas. First, it affects more users on the system from the beginning so the effects are more apparent. There are many organizations that have separate departments or teams that work independent of the main stream. Therefore, if the only starting point were with PD team, the initial impact in this case would be small and take a long time for the downstream users to see the effects until the project matured. Secondly, many projects need to show early benefits for the users and stakeholders. By having more users, the project should see a larger positive effect and enable the project managers of the system to show cost and time benefits to the stakeholders. Assuming a good rollout, the excitement generated by a good rollout is infectious and will win over the users that are initially resistant to the change. Most importantly, to the long term health of the project, is giving back the investment to the stakeholders quickly or they will lose interest and allow the project to die.
Comment by Phillip K — May 8, 2009 @ 7:33 am |
Do you think intergated PLM, sourcing and ERP should be part of the roadmap.
Comment by Matt Brosious — October 24, 2009 @ 11:47 am |
Meant to add question mark to above?
Comment by Matt — October 24, 2009 @ 11:48 am |
I don’t think you should have PLM without a roadmap. We should remember that PLM goes right through from design and manufacture, to service and disposal. Without that roadmap I fear disposal may be neglected, something we could regret in years to come.
Comment by Ian @ Document management — May 18, 2010 @ 5:01 am |
Ian, you’ve touched on something that most people haven’t even begun to think about in the context of PLM. Disposal. HUGE issue as more and more of the regulations are pushing for reporting and management of product disposability in the whole push for green. If you don’t have PLM you won’t be able to address this, and also you have to thing about planning for managing disposal information as your system is designed.
Comment by Laila Hirr — June 11, 2010 @ 2:40 pm |