Enterprise software implementations are usually not a simple task. Compared to selection of your next mobile device and RSS reader, it is an organizational effort. Enterprise software gets really complicated when it comes to the point implementation requires involvement of people. Product lifecycle management (PLM) is one of these systems. Implementation of PLM is deeply connected to product development and manufacturing processes. Success or failure of PLM implementation is directly impacted by how people are involved in PLM system adoption and use.
Companies are taking different approaches in implementing PLM. However, fundamentally, I can see two different ways in implementation. First is holistic approach usually called "business transformation". It implies significant process changes as a result of PLM system implementation. Companies are analyzing their existing processes, optimize and restructuring the way they do business. Second approach is focusing on a specific process or problem solving. It is usually come as an improvement of a specific activity and/or process.
There are lots of debates about PLM implementations these days. The value of PLM system implementations becomes clear to organizations on different levels. At the same time, it is obviously not easy to people to understand how to start using a PLM system that will have such a significant impact of everything they do.
I was reading an Minerva blog post – Should we pull PLM deployment? A new lean deployment strategy by Yoann Maingon. In this article Yoann shares his view on different approaches to implement PLM. The idea of lean and "pulling data" resonated. Here is an interesting passage:
The lean concept is highly based on a pull flow. Most of the arguments I’ve had were about the fact that the main data is created in Engineering so we should start deployment in engineering. Well, what if you should provide a system to the first person who enter the system. The one who will pull the flow, the customer? the marketing? assistance & support?
It made me think about how to maximize the value of PLM implementation withing short period of time. Here is the idea. Every company is manufacturing products for customers in some ways. The biggest process loop in every manufacturing company starts from requirements and ends with "release" of product to customer. To control the loop between requirements and results can be an interesting problem to handle first.
The idea of "pull" will be related to pulling of product requirements and documents representing released products and combined them together in a single system. In my view, it can provide an interesting insight on company operation. It is also very useful information source that every company can "re-use" for different purposes – new projects, customer support, etc.
What is the conclusion? It all starts from ROI. How to make it faster… This is a challenge most of PLM implementations are facing these days. For most of the implementations the process of getting to results can be slow. To provide system that can capture requirements to release control can be an interesting option. Lots of valuable information is hidden in this relationships of requirements-result. It also can drive management attention and focus in a company. Just my thoughts…
Best, Oleg
Posted by olegshilovitsky
Technological predictions are tough and nobody wants to make them. Back in 2010, I came with the following post - 

PLM is all about process management. This statement comes to the play when people explain the value of PLM in the organization. Usually, when you think about process management, your mind is switching to some kind of "workflow thinking" mode, which assumes you need to follow the process from state to state by accomplishing tasks and activities. In every PLM implementation, this is a moment of time, people ask – how do we manage engineering processes? What toolset we need to have to make it happen?




I’m in Moscow these days to attend the
I was long time I didn’t write anything about SharePoint. I’ve been tracking SharePoint for the last 5-7 years very closely. These days I can hear lots of talks about coming SharePoint 2013. Many of the customers I know are using SharePoint. Back in 2006-2007, the success of SharePoint comes from the ability to provide an easy starting solution to collaborate on files in folders. The technology was easy, came together with Windows server and was free as soon as you have paid Windows server license. It was easy to start and put you hands-on something that gives you value immediately.
I’m spending this weekend on Cape Cod with my family. When hiding from active afternoon sun, I stumble on blog post by Jos Voskuil (aka 








