Do We Need PLM To Manage Changes?

One of the areas that is always in the focus of people related to Product Lifecycle Management is how to manage changes in the organization. It sounds obvious – product lifecycle is all about changes. So, it seems to me, change management need to be a sweet spot of PLM. In my view, companies are very often struggling with the implementation of change management practices. I will try to figure what are the elements of the change management and what are potential bottlenecks.

Change Process

When you speak with people about change management, this change process normally comes first. The reason is simple. Changes cannot be done by a single person. It requires multiple person communication. In most of the situations, it requires to communicate across organizational divisions. The bottom line – it is not easy to communicate between people, and it requires good collaboration and communication skills. Software used by an engineering department is not always used by other departments. From the PLM product standpoint, process is a diagram. Simple? I’m not sure it is simple. The most complicated part of this diagram is to draw one in the real organization. I think this process is hard and requires lots of communications with people in the organization.

Referenced Data

The topic of data is underestimated, in my view. You need to have an efficient access to all data related to a change. Models, Drawings, Requirements, Manufacturing, Customers, etc. This is not always possible and this information is rarely located only inside of the PLM system. This is a time when the value of PLM solution becomes lower in customer’s eyes. From the PLM product standpoint, data managed by PLM system can be efficiently used for change process needs. I see it as a chicken-egg problem.

Implementation

Change implementation is another important piece of change management. When a change is approved, the next step is to implement all required modifications in multiple systems – Bill of Materials, Models, Drawings, Manufacturing instructions, etc .. What is very valuable for this stage is to provide a tool to control the overall implementation process. Because of distributed character of operation and many people involved it is always complicated to provide a complete picture of implementation status and control of it. From the PLM product standpoint, everything can be controlled until it management by PLM system. However, this is not always a reality in the organization.

What is my conclusion today? Management of changes is a complex topic. There are multiple dimensions of complexity – process in the organization, people involved and referenced data. To get them together is not a simple task and hardly can be managed by a single system. To have multiple systems coordinated between them, involving people under the stress of the overall product development and manufacturing process makes is even more complicated. If I’m back to my first question about PLM system, I think, a PLM system can provide a significant help in managing changes. The most important characteristic of this system will be an ability to organized process and giving an access to relevant product and organizational data.

Just my thoughts…
Best, Oleg

Share

About these ads

9 Responses to Do We Need PLM To Manage Changes?

  1. Chris says:

    Clearly the answer to your question is no. We can safely say no since PLM is not currently managing change. I know all the people with PLM are now in complete disagreement. But hold on just a second. There is a big difference in managing change and releasing or approving a change. If a PLM system is in place then at best it is managing the change approval. Change approval is a process but change is not a process. Like design change is dynamic and cannot be mapped to a workflow. Change is a human activity like design where people come together, discuss and evaluate and then make decisions.

    Change is like issue or task management. The team evaluates what needs to get done, thinks about the impact and then works to clarify the impact and then they implement. This is a process of managing a list of issues, tasks and things to be evaluated.

  2. Alec Gil says:

    I cannot really answer the question the way it is posed. One thing we know is that the changes must be managed or orchestrated somehow. However, the fact of the matter is that change is being managed by a PLM system at my company. This goes way beyond release or approval functions, although we do use our PLM system for these functions as well.

    Chris, I agree with you that change fits poorly into the traditional definition of a process, the definition that is often exacerbated by what available “out of the box” workflow tools can do. These tools allow us to model linear repetitive activities with a few feedback loops at best. Clearly, they do not capture change as described by you and Oleg.

    However, change is a process nonetheless. It just has to be modeled differently. The key lies in granularity and flexibility, something, judging from the recent blogs, Oleg has been on the bandwagon of lately. The system designers must analyze their business to the minute possible detail and understand the interactions between these details. They must not forget the organizational roles that participate in these interactions and contribute to the creation of the related content. All of these elements should then be modeled in a way where the appropriate data is presented to the appropriate stakeholders for decision making at the appropriate time. As one example of what we have done, if a project team is working on a product option; different team members can contribute to the creation of a BOM, but only after the upstream activities have been completed. In other words, a manufacturing engineer cannot even see the BOM (or a product structure if you will), until the detail design is complete. The manufacturing engineer cannot complete his/her work until tooling or purchasing has completed theirs. On the other hand, a designer can expose a preliminary BOM to the Purchasing department so that the long lead-time components can be ordered. Design can continue in the meantime. These are just a few simple examples of the interactions that are systematically enforced. Of course, none of this precludes the team members from communicating in other ways, through meetings, e-mails, phone conversations, etc. And the residual results of these interactions can also be managed in the PLM system in the documents form.

    Was it easy to do? No. It has taken us a few years to get to the point we are at now, and I am sure there are things we can add or do better. That said, a well thought out, flexible PLM system with some internally developed enhancements is certainly enabling us to manage change.

  3. Chris, I’d be looking on the different aspects of “change” definition. I agree, PLM cannot manage a “change” from the standpoint of “design intent”. This is something that can be captured maybe by KBE tools. However, why not to manage my “change lists” and “priorities”? It sounds reasonable to me. Approvals are another side of managing change and also can be done by a workflow and/or BPM system. PLM can be very beneficial in finding all referenced data and materials as well as tracking implementation. So, my point was to have a granular look on change management- process definition, reference data, implementation validation. Does it make sense? Best, Oleg

  4. Alec, Thank you for your thoughts… I definitely agree that to mange change is a complicated process. And this probably can go beyond traditional understanding of what PLM can (or cannot) do. I clearly like the way you describe the activity of granular definition of change related information. This is something that fits very well my idea of “referenced data” combined with process/activity definitions. From what you mentioned, I can see that lots of these definitions are very dependent on your organization and cannot be predefined in any ready-to-go software (PLM, SharePoint or anything else)… Nevertheless, you can use flexible PLM system (or any other software of such a kind) to implement it. I hope, I got your point in the right way. Best, Oleg

  5. Paul says:

    Given how hard we’ve found it to use PLM to manage change up to now, it is only going to get harder as the number of product variations and the length of service increase. When you have to consider the impact of (say) a design change on a maintenance schedule 3 years out, that is another order of magnitude (at least) than managing the impact during production, or just during design.

    I think automation is going to become far more important in identifying the (potential) impact of change, as well as ensuring all affected parties have assessed it and have all ‘done their bit’. For that, we need Oleg’s uber-BoM well and truly in place so the impact on any aspect of a system (from the part, through the maintenance schedule, to its diposal requirements) can be assessed on everything else – then we can manage the process of embodiying that change into the definition and the product.

    Paul

  6. Paul, I cannot agree more with you are saying. Managing change is hard. The dependencies (what I called referenced information) are complicated, and we need to provide good tools to discover it. Thanks for commenting! Best, Oleg

  7. David Sherburne says:

    This is a good discussion. It depends on the organizational complexity if you need a PLM change system. For a small company sneakers are flexible and easy when your all co-located. If your a global R&D and Manufacturer the complexity of the situation does not allow manual processes to work consistently. If your regulated then the risk goes beyond poor quality and maybe to legal problems. So in larger complex organizations it is required.

    Change Process is complex. Access to data in many systems is required. If your company has deep legacy and is not very mature and consistent at getting to the data in all these systems is very manual and labor intensive process. I know people who have job security on this one point. So organizational maturity is a pre-requirement to a PLM automated change process. You must have a good master data plan and also some agreement on a common approach to change management across the different functions. Then you need some good business planners to determine how to make it happen across all the functions so that you can get at the data that required and justify a project that is funded right!

    This example requires a perfect marriage of data and process along with solid leadership!

  8. David, Thanks for your comment! I liked your excellent insight about correlation between organizational maturity, data access and change management. The connection of change to “change cause” and other ref. data, make a system much more efficient. Best, Oleg

  9. Vasilkov Okna…

    [...]Do We Need PLM To Manage Changes? « Daily PLM Think Tank Blog[...]…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 252 other followers

%d bloggers like this: