Is PLM Customization a Data Management Titanic?

February 26, 2010

PLM implementations are not simple. At the time when PLM vendors are working how to improve their out-of-the-box product offerings, PLM customization plays a very significant role. According to the analysts, customizations and services can be estimated as about 40-50% of total revenues in PDM/PLM domain.

What is behind these numbers and why it happens? In order to understand it, I think, we need to get short round-trip in the history of Product Lifecycle Management. The roots of PLM are in the first implementations made by large aerospace, defense and automotive manufacturers. This is the birth place of PLM and origin of PLM ideas. Since then, PLM started their journey downstream by proliferating ideas, software products and implementations. I can identify the following three trends in Product Lifecycle Management these days:

Maturity of the basic product offering
The PLM core functionality came to the stable form and mostly represented by product data management, lifecycle components and additional modules related to the business process activities – requirements, program, project, services and other processes. Interesting is that PDM and Lifecycle are considered as the most mature components of these portfolios.

Industry specialization
Initially, PLM started in aero/auto domains. However, nowadays it is moving towards all industries. In order to play industry game well, PLM vendors decided to invest into industry orientation. This trend can be characterized by a wide range of options starting from industry marketing and ending by providing packaged PLM solutions for the specific industries (i.e. Apparel, CPG, Food and Beverage, etc.)

Emerging trends
I can identify two main emerging trends – SaaS / OnDemand and Open Sources. Both are focused on how to satisfy needs of customers differently utilizing new software technologies  and deployment as well as by investing in the alternative form of business models.

When PLM industry focused mostly on providing out-of-the-box functionality, I didn’t find any technological trends focused on core data management capabilities of existing and future PLM systems. This is a very bad sign, in my view. Looking backwards, I can see significant improvements that were made in PLM software by the introduction of flexible data modeling. It allowed to decrease cost of PLM implementations, but created the huge amount of today’s customizations and implementations based on existing PDM/PLM platforms.  And this is a growing conflict between customized PLM software and upgrades to the coming releases of PLM portfolios.

I found the following Develop3D’s article as a very interesting. Al Dean is writing about replacement of highly customizable instance of MatrixOne by Open Source PLM Aras. There is more information about this event on Aras website. Read it. It looks like customer made the decision in favor of Open Source because of absence of alternatives to move to the next version of out-of-the-box MatrixOne version. I want to point out on the discussion about PLM software upgrades – PLM, Cloud, SaaS and Software Upgrades. My conclusion was simple – technology and architecture matter. If PLM data management capabilities could manage the upgrade event from highly customizable solution, I doubt the customer’s decision was to dump out existing vendors. Does it mean Aras has such technology? I don’t know. However, coupled with Open Source business model it crushed existing PLM implementation.

So, what is my conclusion? My hunch is that PLM vendors forgot to invest into data management technologies. PLM data management technologies were created 10-15 years ago. Since then, industry developed huge amounts of customized implementations. I see these implementations as Titanic pushing forward… Do you think they will be able to achieve port of destination or will die in front of icebergs of upgrades? I see it as a real and dangerous problem.

Just my thoughts…
Best, Oleg

Share


What We Are Losing By Going From CAD to PLM?

January 19, 2010

Do you remember the time before PLM? Time, when our focus was about CAD and Product Data Management? With all latest developments around Product Lifecycle Management and collaborative business processes, I think we lost some important grounds related to the critical data management issues related to engineering and product development.

CAD and related Design solutions is the biggest source of engineering data produced in the organization. For the last decades CAD and other design-related systems produced huge amount of engineering data – models, drawings, bill of materials, analyzes and more… These pieces of data are very critical to the organization from the standpoint of making product related decisions.

On the other side, product lifecycle management is running forward and shifting focus on how to optimize business processes in the organization. The new PLM solutions is very focused on how to define and run organizational processes related to product design, manufacturing, support, disposal, etc.

But here is the point. I think these two pieces become more and more disconnected. By shifting focus on the process-oriented environment vendors are losing their grounds in data management. Today design and related product knowledge is pretty locked in the systems that used to produce this information. PLM systems are not focusing on how to make this information managed and available inside of the enterprise. The solutions like 3DVIA composer, PTC Arbotext, Autodesk Inventor Publisher are good initial signs, but they are too much focused on geometry and very little on data.

What is my conclusion today? PLM is too much focused on how to capture processes and make it visible on CIO level. It obviously comes from the interest to compete with existing ERP and other solutions. However, on that way PLM is losing some core business related to the ability properly manage product and design data. We need to get back to product management roots and analyze what we still need to accomplish there.

Just my thought…
Best, Oleg


How PLM Vendors Can Listen To Competitors?

January 17, 2010

Last week I had chance to read Forbes’s article (Listen To Competitors — Not Customers), which made me think more about competition in Product Lifecycle Management. I read this article few times, and, I think, found why I felt not comfortable with position of author. The definition of customers is simple. Those people or organizations which consume products your organization manufactures. If you think about new markets, it is very simple to identify who are that organization or people you need to talk to. However, with competition the situation is not as simple. The definition of competition is subjective. You can consider the specific company (or product domain) as a competitive, but in fact, this is false reality.

In my view, today’s situation on the PLM market characterized by a very small amount of vendors that fight on the lucrative space of the specific services. At the same time, mainstream adoption of PLM is still a very significant problem. For the last decade, number of companies playing on PDM/PLM market decreased due to competitive acquisitions. If you will be listening to the PLM marketing, you can be confused by similarity of offering and messages. So, to realize a potential listening to the competitors the process of competitor’s selection need to be much different and going beyond Gartner Magic Quadrant.

So, what is my conclusion today? Discovering multiple ideas surrounding Product Lifecycle Management, I found many times that customer’s perspective on technology and product positioning is quite different from mainstream marketing presentations. Thus, you can find something, I’d call “alternative” and not “competition” to PLM. So, with such correction, I think, PLM companies need to watch alternatives to their solutions- it will create more balanced view and will focus on the competitiveness and ways to provide value to customers.

Just my thoughts…
Best, Oleg


Large Monolithic PLM Implementations Are a Thing of the Past

December 20, 2009

Continue my last week post about how to make next PLM implementation simpler, I decided to put some ideas towards how the next PLM implementations will look like.

PLM vendors are making huge efforts to simplify PLM deployment and make implementation simpler. Despite that, in my view, typical PLM implementation is still combined from three typical steps: a significant planning effort, deployment of software and additional customization and adaptation services. These steps make implementation expensive. Talking with PLM specialists and consultants you will learn the most important PLM activities are related to good planning upfront, methodologies and clarification of what organization need and how to math organizational needs to capabilities of the system. Gaps are covered by services.  It looks like a deadly connected circle. How we can break it?

I think many of PLM vendors and implementers made a misinterpretation of out-of-the box terms. What is currently proposed in PLM “out-of-the-box” package is an effort to create “standard PLM”. What you can hear around is additional activities how possible to create typical industry implementations, OEM/supplier oriented typical implementation, etc.

In my view, this is a dead-end in PLM evolution. Such efforts will be endless similar to multiple standard activities in product development. The main reason for that is because manufacturing these days need to be more agile, lean and dynamic to sustain in their business and making profit. When such fundamental for their product development system like PLM becomes “typical”, you cannot expect them to be dynamic, lean and efficient at the same time.

What is a possible solution? I think software vendors need to learn again lessons from 15-20 years back. In beginning of 90th, few companies were doing PDM. Such projects were considered as luxury, needed by big organizations only. PDM budgets started at six digits numbers and requires major involvement of software vendor, custom software builds and long project implementation time line. However, in the middle and end of 90th we had chance to see a strong trend towards flexible data models, inexpensive Windows based systems and as a result lower entry barrier for PDM implementation.

My conclusion today. Vendors need to leave magic-out-of-the-box marketing efforts and depart to the new station where we’ll able to find new engineering solution for old problem. Future systems will be adaptive, will not require a significant effort to deploy and implement.

Just my thoughts. YMMV…
Best, Oleg


Product and Process Models in PLM – What Should Come First?

December 3, 2009

Common definition of the process – “a set of activities leading to the desired outcome”. Despite on such simple and straightforward definition, implementation of processes in PLM delayed and very often lead to a significant complexity in implementation. I’d like to analyze and discover why it happens and what other factors can influence process implementation in the organization.

Process Model.
It depends on tools, technologies and environment customer has, processes in the organization can be modeled and implemented differently. Normally, there are more than one enterprise systems in the organization that is able to handle process modeling. Starting from middleware and specialized BPM software, following by enterprise systems such as ERP and PLM and ending with various Enterprise 2.0 collaboration tools. Process model, these days, can be developed by multiple tools. For the last few years, BPMN becomes somewhat similar to the standard process definition tools. What is the main problem? Data. Various products and corporate data needed to be injected into process implementation to make it work.

Product Model.
Originally started from CAD models, product model developed as an extended set of information describing various aspects and dimension of product – model, bill of material, requirements, items, information about customer requests etc. As we learned from process model definition, this specific product model information is needed to make process definition. Processes actually need to access data to trigger tasks and events to handle processes.

So, what should come first? Product or Process? My conclusion is that lack of the rational product model can drive to a very high level complexity of process definition and implementation. Product Model is the foundation of product lifecycle. Without a well defined product model that can cover enterprise product definition scope and related disciplines, development of a process oriented PLM environment becomes a complex and not achievable task. Organization implementing PLM as a process environment needs to invest first in implementation or adoption of the product model that will be used as a process foundation.

What is your opinion? What was your experience in similar tasks and efforts?
Best, Oleg


Measuring PLM Technologies Payoff

November 16, 2009

Picture 54Reading over the weekend ZDNet post, “Why IT cannot seem to deliver measurable productivity”, I started to think about how many times I heard about PLM technologies in the context of productivity and other aspects of PLM impact on organizational performance. Even, if I think, there is a significant improvement in the way companies perceived PLM,  I think, there are too many situations where PLM is not associated with company performance and existence of these tools and technologies in the organization considered as something “we cannot avoid”…

I started to think, why PLM product and technologies are too often standing in the shadow of negative expenses as well as not considered as tools and technologies that boost company forward. Below my three point conclusion about that as well as thought how we change it.

1. Undervalue of reporting capabilities. Historically, CAD/PDM/PLM technologies were focused on design and engineering work, managing of data, revisions and processes. However, many times, I found even simple reporting and more advanced business and information intelligence undervalued and not-delivered. This functionality considered as too complex to be delivered out of the box and products relies on technological frameworks, customization and services based implementation. As a result, today’s status is that we actually cannot measure what we are doing. Intensive reporting capabilities in PLM may result to expose information about how PLM performed on the organizational level and trigger ability to measure the payoff for PLM.

2. Concentration on Engineering. Engineering, very often, considered as a very separate from the rest of organization. The same happens with tools used for engineering. By focusing on engineering PLM getting a sticker of “internal” tools with no impact on what organization need. You don’t want to care what engineers used as soon as an engineering department makes delivery. On the other side, if PLM can bridge organizational problems and connect it to engineering using PLM tools, additional value can be exposed .

3. Lock-in data. In my view, there is a little obsession on data from CAD/PDM/PLM tools. Originally started from CAD tools and formats it proliferated on many other disciplines in Product Lifecycle Management. Looking on today’s business needs, ability to expose IP becomes of the most important. It can improve communication with customers, boost innovation in the organization and improve many other things.

So, what is my today’s conclusion? Ability to measure and data openness is two key directions we need to focus on to improve organizational understanding and value of PLM technologies and tools. How do you see it in your organization? How do you measure your PLM tools payoff?

Best, Oleg


Pitfalls of Selecting PLM For Order to Manufacturing

November 12, 2009

In today’s consumer oriented environment order to manufacturing systems becomes more and more popular. I see growing number of customers are interesting in the organization of “order to manufacturing” processes. Looking on exiting PLM systems, I’d like to discuss what are potential pitfalls in selecting PLM for such as “order to manufacturing” organizations.

Pitfall #1 Product Configuration Modeling
A typical order to manufacturing system need to be “configuration oriented” in front of potential customers or sale persons in the field. The first and the most important for such as the situation is to organize support for handling of configurations in multiple systems – sales, manufacturing, design and product management. This is not an easy task. Most of the systems have a very specific way to support configuration and because of difference between these implementations engineering, manufacturing and sales systems may not fit.

Pitfall #2 MRP synchronization
In order to handle smooth processes of orders and manufacturing, be able to synchronize data between CAD/PLM and ERP/MRP systems is crucial. So, to think about bi-directional data integration and synchronization between PLM and ERP must in your checklist.

Pitfall #3 Cross System ECO management
Because of cross-system organization, ECO organization needs to be fully supported in the same way in all systems and automated. Manual and half-manual ECO processes and monitoring probably will not be enough.

Pitfall #4 Support Organization
Because of very diverse product organization, you will need to be able to get up-to-order/configuration product information for support organization. It will require global information access between multiple systems in different organization departments.

Picture 48

I’m confident, future of manufacturing will be even more customer-oriented and to manage order to manufacturing processes will become even more important. What is your opinion on that? Do you face similar problems in your organizations? What type of the solutions you found as an efficient to handle that.

Best, Oleg


Design and Manufacturing: Top Down PLM approach with Treehouse?

October 29, 2009

The new release of SolidWorks Labs Threehouse V2 hit me to think again about Top Down approach and efficient communication between Design/Engineering and Manufacturing.


Background.
SolidWorks Labs released V2 of Treehouse. You can get more information on their website as well as take a look on multiple blog articles about that. My favorite was SolidSmack’s “Full Speed TreeBleed. SolidWorks Treehouse, Not Just a Treehouse“.

Design, Engineering and Manufacturing
Problem of disconnecting between Design/Engineering organization is not new, in my view and exists in many manufacturing organizations. It’s obvious Engineers sees a product they develop very much in the light, of how they build parts/sub-assemblies/assemblies/configurations models. For them this is what make sense. However, from manufacturing side, it always looks different because their structure is driven by assembly process, packaging, supply chain and other factors from a shop floor. Most of the systems today are not providing a good solution for this problem. Those customers that made decent solution in this space built it based on huge customization and service base.

Treehouse, Modular design and Top Down

In my view, Treehouse concept is interesting since it can provide a communication bridge between two worlds: design and engineering/manufacturing. The way to initiate design top-down in SolidWorks is not trivial and Treehouse can be an interesting approach to do so. It can facilitate modular design and ability to create new products and configuration top down initiated from Engineering/Manufacturing space.

What is your opinion on that? Have you had chance to think or implement the top-down approach in your organization? What systems you had in your mind to support it?

Best, Oleg


PLM Strategy and Six Thinking Hats

October 26, 2009

six-thinking-hatsDo you know how companies are making decisions about their PLM related strategies? I don’t… Each time I see this process, I think a company is trying to invent the wheel. I think, the most closest methodologies related to such decisions are in the space of Configuration Management and Engineering Documentation.

I was reading about Six Thinking Hats methodology over the weekend and found it interesting to apply to way organization apply their thinking about PLM-related strategies.

White Hat:
Thinking about Design, Product models, Bill of Material, Structures, Information.

Red Hat:
This is the way to think about how we work now. In most of the cases, I think, we are taking very emotionally, analyzes of how we work now. In most cases, it is very hard to disconnect.

Black Hat:

This is the place where all thoughts about previous unsuccessful projects come to our mind.

Yellow Hat:
Here all PLM Marketing messages going to be presented. Benefits, Values, ROI, TCO etc.

Green Hat:
This is the place where we are going to innovate and brings new technologies, a suggestion to change, improve etc.

Blue Hat:
This is our process control hat. When we think how to organize processes, how to decide. I’d call it probably “management way to think”. Sometimes, this one can turn us to data - reducing of Part Numbers, Optimizing ECO etc.

So, I’d be interesting to hear about ways you think when made your previous PLM-related decision? Do you see six hats association work for you? Share your thoughts, please…

Best, Oleg


PDM vs. PLM – Is this about Process?

September 21, 2009

I was reading interesting article during the weekend- PLM & The Importance Of Process by Gary S. Vasilash. Gary is the founding editor of Automotive Design & Production (AD&P) Magazine.plm-vs-pdmThere are few very interesting points were made by Gary and I liked it very much. Gary is discussing PLM topic with Twila Osborn, Lean Manufacturing and PLM, Computer Sciences Corp. (CSC; csc.com). Started with a solid statement came out of CIMData about strategic importance of the process for PLM, later Mr. Vasilash made some very important notes about handling of design data and BOM. “Who owns BOM?” Excellent questions.”The BOM is a corporate asset, not an engineering asset.” Sounds like PLM is the best candidate to own Bill of Material. However, a conclusion made immediately after mentioned that PLM companies (like DS and Siemens) invested a lot in Design Process, and it really works today. What sounds to me, BOM story is not as completed as a design story for PLM systems. You can hear a lot of “buts” when you start to discuss BOM story of PLM. “The mindset needs to change; it is not just CAD data.” About most of PLM implementations in organizations - “It might be very old, out of date. It might not have an integrated BOM. Some have BOMs based on proprietary technology, built from scratch. They might have a PLM system, but they’re using it as a PDM system.” A lot of “buts.”. What is very remarkable is a short review of top three PLM vendors (DS, PTC and Siemens). Unfortunately, this summary is corp-marketing-publishing-fully-buzzword-compliant. What will be very interesting is to find analyzes related to who owns Bill of Material and how to manage a BOM and related process beyond engineering on the corporate level using standard PLM systems.

But, I’d like to get back to the original topic - PDM vs. PLM. I asked many times about what is the difference between these two from customers, on conferences and during professional meetings. I think, professional community made a tremendous job in trying to explain it, but these two domains are continuing to confuse users.

I thought about few definitions to make before:

Product Data - product design, bill of materials
Product Data Changes - ECO-related information including design and Bill of Materials.
Product Lifecycle - information and process-definitions related to global product development stages.

I think PDM is definitely about first two. However, getting back to Mr. Vasilash’s - “The mindset needs to change; it is not just CAD data”. As soon as we can come to matured Bill of Material implementations (not home grown as it today), PDM will become mature to manage a complete scope of Product Data Changes and not only Design portion.

PLM definition is very fuzzy, in my view. However, this is definitely about how to move from Product Data Changes to Product lifecycle and corresponded to organizational processes. There are many business process management software suites (BPMS). However, all of them won’t be able to provide a relevant answers on product lifecycle. Because “product data” is a key asset that needs to be taken into consideration to manage organizational processes around product.

This is not the first time I’m touching this topic. I’d be interested to hear your voices and comments.

Best,
Oleg


Follow

Get every new post delivered to your Inbox.

Join 73 other followers