Can a true PLM initiative be decentralized?

In a previous blog I was looking for the PLM expert. The conclusion was that implementing PLM is a team effort (which is perhaps not a surprise), as a PLM implementation includes process, tool and organizational aspects. The executing team should possess knowledge within the customers’ business, the targeted domain, and available technology. Strengthened by having a reference group working in the day-to-day business and the support of management.

But we didn’t address the question on which level this “body of expertise” should act. Where should this organization reside, and what mandate should it have?

In short: what would the impact be of having a centralized or decentralized ownership of PLM?

A Decentralized PLM Ownership

From a process and method point-of-view you could probably find reasons to actually move the responsibility from the corporate level and allow local flexibility:

• Risk management through diversification, which would allow business units to try out things which could then benefit others in the organization
• Ownership of your own working methods would potentially allow easier change management
• Less compromises in the way you work and the tools you use in your daily work would probably generate less friction
• Closer to the immediate challenges will allow the organization to be more agile and finding solutions to emerging threats, opportunities and trends

Okay, so there might be good things with decentralized processes and methods. But let’s have a look at what a decentralized PLM (both process and tool) does to some of the (old) core values of P L M:

• Manage Information - Manage data and processes
• Find Information - Search, where used/referenced, process status
• Share Information - Real-time collaboration. Information attached to workflow

Doesn’t a “local” PLM system contradict with those values? I assume it has to do with your definition of local. If it is a site with 5000 employees does it have to be integrated with the rest of the company? It all depends on the business.

But let’s flip the coin completely and look at some more challenges you might find in an environment which has a decentralized PLM ownership:

• No one will be responsible for thinking horizontally and aligning the company across departments and across functions/disciplines
• Each department is measured and rewarded by their own results, blocking a strategic change as this requires an investment
• Hard to have job-rotation and change staff as the processes, working methods and tools differ
• More costly to have an effective tool support as it’s not consolidated
• Less efficiency further down the chain or even loss of opportunities and inability to execute on initiatives completely. In many cases the lack of a common way of doing things is hurtfully exposed once you have a need of unified processes and information at one end while having a diversified way of working and/or structuring and storing information at the other. It works as long as you don’t think of others … Typical initiatives and areas which will put their demands on what and the way information is delivered are: business analytics, procurement, manufacturing, e-commerce, and aftermarket.
• In many cases (to my experience) a decentralized ownership means more “let’s just make it work” which means that the experienced employees will have a way of dealing with things but the new ones will have to “find their way”. Is that really making things smooth and efficient?

Decentralized Processes and Methods but Consolidated PLM Tool(s)

Providing that you believe in decentralized processes and methods but also in the need for a consolidated application support for effective distribution of information you might avoid some of the bullets above. And looking at the core PLM values stated above; “only” the process part might not be accomplished.

The concept of self-organizing teams is not new. It is a great part of the agile software development movement. Isn’t this what we would talk about when we put PLM in a decentralized process environment but with consolidated tools and information, having common PLM tool(s) orchestrate these “teams” to deliver information and use tools in an uniting way?

In such an environment process support might be hard to implement within the commonly used tools, which might not always be a bad thing. Having processes tightly implemented into the IT tools assume a deterministic look at the world, but as we all know the world and the way we work is an ever changing parameter. So this could actually trigger a healthy look at how you architect and build your tool support as it will require modularization and flexibility.

The trap which you might fall into is that the consolidating system will become the “scapegoat” as it will have to unite and be a compromise from an end-user point of view. Also, many regulated businesses don’t have this option. To unite under one proven and compliant process is a matter of necessity and survival for these companies.

Decentralized PDM and Consolidated PLM

A trend we see at large companies is that they move away from one enterprise PLM solution covering everything. We see several examples of local PDM solutions allowing local flexibility feeding an enterprise PLM which has information and processes harmonized, but on a higher and more generic level.

Processes and ”how to do things” (methods or practices if you will) are not the same, and to be able to deliver and consolidate information in a coherent and consistent way “the way you do things” might very well have to be aligned as well. An example of an area which requires this thinking is CAD / CAM. In other words it’s important to understand if you have these type dependency so that you act accordingly in your decentralized PDM environment.

Using a PDM tool closer to the authoring tools will often result in better connection and less translation issues and richer details as a result. But keeping the innovation loops within PDM and consolidate in PLM cements the functional silo as it delays the point in which a cross functional view can be “visualized”.

Conclusion

As I can see it you actually don’t need to centralize everything under the PLM “umbrella”. This is of course a bit depending on your type of business.

Processes and methods should be carefully implemented. You could reap a great deal of benefits by aligning and consolidating tools and information across the enterprise and still allow processes to be more autonomous in nature. One trick is to implement the processes on the right / high enough level (in the applications) which would allow people to work within it, while still keeping important flexibility and agility in the tool. It is important to keep a clear distinction between processes and methods so that you consciously decide what it is that you want the tool to support and what you keep outside it, as this will allow you to adjust the way you work to temporary situations and differences in business models, while still delivering and using commonly structured information and tools.

Are you convinced that one approach is better than the other? What’s your view on this?

Robert Wallerblad
www.infuseit.com