Recently, I was sitting in on a discussion between one of our consultants and a client. The consultant has years of experience with product portfolio management (PPM) and was advising our client on how to best adopt this capability in the context of their product lifecycle management (PLM) solution. The client had recently seen a demonstration of the PPM module and was feeling a bit overwhelmed. The issue the client had was that they currently had no process around project management that would easily translate to the centralized approach the PLM module required. The client was questioning how useful the module would be based on their current environment. My expectation would be that the consultant would agree with the client that there was no point in purchasing the module until they had a more mature project management environment with a process that could support the application. However, he surprised me a bit when he insisted that adopting the module and then using it as a framework to build a new process into would be the best approach. His point was that trying to build a process from scratch would be somewhat overwhelming without architecture to build on. He also felt that since ultimately this process would reside in the PLM, why not start out that way instead of designing a process and then trying to make it work inside the PLM. All of this seemed to make sense to the client but it got me thinking about PLM as a whole and our past experiences trying to integrate companies' processes into PLM. Certainly process should be altered to leverage PLM capabilities, but can PLM be used as a tool to actually develop process? Is it more efficient to use PLM to design process or develop process independently of PLM? The answers to these questions can impact how PLM is implemented and the expectations companies have about PLM when they purchase it. This blog will explore how using PLM as a tool to develop business process effects adoption methodology and ultimately the impact PLM has on a company's productivity.
One of the historic drawbacks for PLM is that it is not particularly flexible. Once you establish process and structure, it is very difficult to go back and modify this structure. This is why consultants spend lots of time up-front with the client mapping their product development process and making sure it is accurately captured within the system. Some of the easiest (and I use the term in a relative way) implementations can involve start-up companies that do not have established practices in place. These companies are often looking for guidance about "best practices" they can adopt that will allow them to fully leverage their new system. Some start-up companies put off purchasing PLM because they feel that they need to become better established and understand their process more thoroughly. Based on my experience, companies that adopt PLM early tend to do better from a process automation perspective. They avoid building out process that does not map easily into the PLM tool. Having to go back and shoehorn a legacy process into a PLM is one of the more challenging aspects of implementation. I have also covered the challenges of data migration pretty thoroughly in a previous blog. The point, however, is about existing companies and their adoption of PLM or specific aspects of PLM, such as product portfolio management, costing, governance and compliance, engineering collaboration, etc. What if their processes for these areas don't exist or are so far removed from automation they cannot be leveraged? The implementation process for startups teaches us that using PLM to design process is a viable approach and that extending this methodology should be explored further.
While researching this blog, I came across a white paper by Antti Saaksvuori, titled "Building a PLM concept". Saaksvuori literally wrote the book on PLM. His book is titled appropriately enough Product Lifecycle Management. One point the white paper makes that is relevant to this discussion is as follows, "Companies seldom recognize the fact that the PLM maturity of the company is too low to launch a large scale PLM system project for the first time. There simply is not enough understanding of PLM and its possibilities, but also its impacts to current way (sic) of doing things. Usually the case also is that the processes and practices of a company are not mature enough to be utilized in PLM context." So, to further clarify, he is saying that in many cases companies' current processes are not compatible with a PLM system. Putting the PLM system in place early and then using it to build process seems to make the most sense. Yet in most cases, I do not believe that is the expectation that PLM vendors set with their clients. I would go further and state that most companies could probably benefit from re-implementing their PLM tools based on the knowledge they have gained from the first pass. Obviously, vendors would prefer a more aggressive approach where companies fully commit to the PLM and then implement. By using the PLM tool as a process development solution, a company could implement first and then if they liked the solution they would then purchase the needed licenses. Even if they decided to go with another PLM solution the process development work would have value.
Even in today's climate with PLM vendors touting "out of the box" capability and rapid implementation methodology, it would be wise to consider flipping things around and using a PLM tool as a means to capture company process before fully committing. There is significant value to be derived from a smaller purchase of software and consulting to design your systems and then using this knowledge to roll out to a wider audience and then gain significantly more value from fully adopting a properly configured PLM solution. Process transcends specific PLM tools, so once a company transitions from manual process to PLM, they can use their process with most of the different PLM solutions available. Virtualization makes it very easy to set up a PLM tool outside the context of the current environment so prototyping has become far easier than it once was. Even for companies looking to expand their PLM beyond its current scope can use this approach by setting up a development environment they can use to help drive new process. None of the things I have discussed here are necessarily innovative. Many companies have broken up PLM into small segments to make it more manageable and to shorten the ramp to value. It is fairly common knowledge that trying to undertake a long complex and expensive project to adopt PLM is not going to go smoothly. The unique idea from this article is that outside of the typical value PLM delivers in automating process, shortening cycle time and improving communication, there is specific value from using PLM to construct new processes that are compatible with automation. The architecture and structure of PLM provides a platform that will be far more useful for developing process than trying to do it via committees with whiteboards and power point.
[Reposted from 2015]