PLM Challenges In The Global Product Development

I had chance to read The Practice of Global Product Development at MIT Sloan Management Review. You can find  the link to this article here. The original research was published back in 2006. The current article is dated November 2009. In this new work author Steven D. Eppinger and Anil R. Chitkara, examined state-of-the-art and emerging best practices in global product development (GPD). I think Global Product Development has a very co-planar vectors of development with PLM. In my view, in the global organization, PLM has an opportunity to become “the backbone” system. Since in many cases, ERP deployment is country specific, PLM will have an advantage to integrate product development activity on the global scale.

I’d like to figure out some essential key success factors of GPD that need to be in the focus of PLM-minded people.

2. Process Modularity To enable PD activities to be carried out in different locations, there must be a methodology to segregate the work packages for global distribution. For example, where a remote center will be handling tasks in a process that continues to be owned by the “central” PD location, a modular process is needed. The process must be broken down into clear steps, the steps distributed to different locations and the process reconfigured to allow for the necessary handoffs, reviews and approvals.

3. Product Modularity Modular product architecture is very helpful for GPD in which development of complete subsystems or components is to be carried out by teams in different locations. Clearly defined interfaces between modules facilitate their separate development and eventual integration into the product. Without such modularity, more intense collaboration across design interfaces is necessary.

5. Intellectual Property As critical product data, designs and technologies are shared more widely outside the company, protection of IP becomes more difficult. Defining products and processes in a modular structure not only can help with the distribution of activities, but also can help protect IP.

6. Data Quality The availability, accessibility and auditability of data become key challenges when many locations contribute to the PD process, often using different tools and databases. Teams may be working on different aspects of the product with similar “source data.” As these data change during the process, all users of the data must be aware of the changes and the implications for their work. One system or database must be used as the “source of truth.”

In my view, these success factors present important challenges to any PLM implementation for the organization during deployment and implementation of Global Product Development practices. Below is my take on the top PLM challenges in GPD.

Global Product Data Modeling
The big organization has their own rules in organization product data. Most of the global organizations already have a product development process which organizes product data in a certain way. When it comes to implementing PLM vision, the question of “how to model product data” is one of the first questions that implementing team is going to discover. Despite the fact PLM vendors developed and acquired technologies and tools for flexible data modeling, in my view, this is still not a simple task. The biggest challenge is to get people in the global organization to agree on a meaningful way to represent and model data. These are current PLM practices, and unfortunately they require significant investment from the organization to make it happen.

Distributed Data and File Share
Data in a global organization need to be distributed between multiple locations. This simple statement means very not trivial implementation. How to plan your data location globally, how to move files and other pieces of data, how to protect IP when you work offshore? All these questions need to be answered by PLM implementation. I believe each organization is going through their own path in the organization of their distributed data and file management practices.

Change Management
This is last, but definitely not least. At the time that job done and system is up and running, the next step is… change! Global organization will be requesting on going changes in the way data need to be managed, located, accessed, etc. All this to support organizational business performance. To be able to support on going changes timely and without product development is a huge challenge for PLM deployment.

Just my thoughts… I’m sure, I didn’t cover all challenges, and I’m awaiting your comments. I’m very interested if you can share your experience and practices related to global product development and PLM deployment.

Best, Oleg



Share This Post

  • Joe Provenzano


    Nice thoughts… I’ve a question about the “how to model product data” point. You state, “Most of the global organizations already have a product development process which organizes product data in a certain way.” What would you point to as an example of that? What high-level data structures are you thinking of?

    ~ Joe

  • Douglas

    Any old “drawing procedure” contains more or less of the following data structuring ways : indented BOM’s, parts classification in part numbers, effectivity by date or end product serial number, specific part number suffixes for monoparts, assemblies, kits (or phantom numbers)etc. These data structuring means (or data model entities) have been around for ages and are still valid.


  • Joe, Thanks! My point about existing product development was just to understate the simple fact. Existing organizations already have set of tools and process practices to support design and manufacturing process. Even if this is a paper and manual process. I think, the first thing that needs to be done is to find a way to absorb existing practices in the organization. This is, in my view, a starting point for any future improvements. When it happens in a global organization, we may have as an input, multiple business practices coming from multiple organizations. This is the next level of the complexity. Best, Oleg

  • Joe, Thank you for clarification. This is exactly what I mean. Best, Oleg

  • Shaoping Zhou

    Hi Oleg

    The Sloan review article was a very good read. Thanks for blogging about it here. I am a regular reader of Sloan review and it feel nice to hear about your comments above.

    I am particularly glad tha the article brought the attention to IP management processes and best practices. I happen to have the fortune to study this topic in a graduate research project, and also the professional opportunity to observe how IP management gets CTO and COO level attentions and investments because of its role as a source revenue and also as a way to develop new products and platforms. IP management can be thought of as an extension from module based design practice. However, these days, companies may build parts or all of its business model by selling or assembling IPs for a target end market segment. This is one of the most exciting frontiers of innovative PLM practices.

  • Shaoping, Thanks for your insight! IP management process is a very interesting topic- I agree with you. In the context of that, I see to challenges for PLM system development.
    1. How to have a system to acquire IP in the organization?
    2. How to reduce an average cost of change in the system?
    3. How to support IP management for a long period of time (10+ years and in specific industries 50+ years)
    In my view, these three capabilities are essential to establish an efficient set of IP management practices.
    Best, Oleg

  • Pingback: Dog Food?? | Bad Dog

  • Pingback: Global Product Data Management (PDM) Software Market – 2008-2012 | The Studio Blog()

  • Ben Camacho

    Our executives have been sold by some consultants on the idea of modularity, I think it is the same as your item 3 (Product Modularty) mentioned above. Can you help me understand what this is and how it is different than a standard product structure? Some examples or articles to read would be helpfully.

  • Ben, The meaning of modularity can vary. In the context of current blog post, modularity assumed that you can split development process into different elements (segments) that can be managed separately. Such approach may require an appropriate allocation of resources and data modeling practices. I don’t have any immediate links or document I can send or share. Let me know if you have specific questions, we can take this issue offline. Best, Oleg