PDM/PLM and Customization

April 21, 2010

Customization is a topic in Product Lifecycle Management that always raises discussions. There are multiple aspects related to customization of PLM systems, and I decided to explore them. In my view, the nature of PLM system customization is deeply related to engineering and product development aspects that in most of the manufacturing organizations are related to their core competencies and touch many processes in the organization. To be able to support them PLM systems are providing various customization capabilities. On the other side, the total cost of PLM systems and especially cost of changes becomes crucial for many companies and implementations. When it comes to implementation cost, need to customize PLM system becomes a negative factor.

Early Monsters
In the early beginning, PDM started as a completely customizable toolkit-oriented systems. In order to implementation and customize them, the significant amount of work needs to be done. For most of the early cases, vendors provided unique production builds of the systems dedicated to a particular customer. PDM was considered as 1M dollars project.

Flexible Data Models and API
Since demand on PDM/PLM systems started to grow, vendors looked how possible to deliver PDM system that will not require a significant effort in order to be customized and tailored to customer needs. The concept of “a flexible data model” was born and few very innovative systems were introduced to the market in late 80s and early 90’s. They provided set of customization tools to modify data schema and additional parameters as well as advanced APIs to support customer-oriented environment. Later in the mid of 90s, more PDM systems were created under significant influence of Microsoft Windows environment.

Out-Of-The-Box PLM
Next step in the PDM customization story was so called “out-of-the-box” system, yet fully customizable. Most of these systems were born as a modification of “a toolkit”-oriented implementations and providing their configuration tuned with a specific parameters and data schema. In my view, it was a beginning of “PLM industrialization” bubble. When systems still provided all options to be flexible configured and customized, the marketing story always emphasized their ability to be ready-to-implementation AS IS. Unfortunately, because of a significant emphasizing of out-of-the-box, technological and  development focus shifted from innovation in providing of flexible, customizable systems towards “packaging” and selling of boxed PLM for industries.

Cloud and PLM
Customization is considered as one of the most significant risks and problems related to PDM/PLM systems in what called ASP model in the beginning and later became OnDeman/Cloud systems. I don’t think, there is a Cloud/SaaS PDM/PLM system today that can provide the same level of customization as a system-on-premise. I think, an effort need to be made to learn Salesforce.com environment and specifically their Force.com platform in order to understand the “secret sauce” of their success story.

What Is Next?
I have a feeling, we are in the middle of debates about flexibility and customization vs. out-of-the-box flavors of PLM. When it became clear, out-of-the-box systems cannot provide what customers need, industry is still continuing to promote ready-to-go solutions, industrial verticals and other sales and marketing oriented speeches. Nevertheless, I can hear strong voices to revise experience of the past 4-6 years and focus on technological development that can provide a platform for the future flexible and customization PDM/PLM system.

What is my conclusion today? Product Lifecycle Management is in the critical situation. It started as a complete customizable environment and, since 1990s moved towards out-of-the-box packages and non-customizable solution. The last happened based on the strong message about making implementation faster and cost reducing. It seems to me that out-of-the-box PLM is a marketing and sales dreams. Engineering and product development cannot be done “out-of-the-box” and even so, companies are doing similar things, their strong believe in the uniqueness and benefits of the engineering and manufacturing environments. The key word for me in PLM customization today is a granularity. To make it work is hard. How to bring it up remains a completely technical topic.

Just my thoughts…
Best, Oleg


Why Do We Need PLM to Control Product Cost?

December 22, 2009

I’d like to continue discussing topics that create maximum confusion between PLM marketing and reality. Today, I want to talk about one, that probably in the top list of all manufacturers – product cost. Yes, you want it down, no doubt. If you will talk to PLM marketers, they will all tell – PLM is the way to go. However, how magically it will happen? Why PLM can help you manage cost? How practically it will happen? I decided to discover the potential answers on these questions today…

Let me think about a traditional manufacturing environment that is not going to implement “PLM strategies”, but indeed is looking how to decrease cost of their products. The most reasonable approach is to ask different business units to develop their cost saving programs- R&D, Manufacturing, Supply Chain, Support. I believe, these organizations will be able to deliver decent results. Now, depends on manufacturing type, they have various chances to be successful. For the long run, the company manufacturing the same (or similar) products will be able to optimize cost of products. Their best chance to do so, will be for mass-manufacturing products. Within the time, all functional areas will be optimized and learn from the experience how to manage product costs for what they are doing. There are two potential problems in this approach. First is the time scale and the second production volume. What does it mean?

Time Scale in Manufacturing
With a significant time period, your manufacturing organization has a good chance to develop reasonable good product cost practices. Designers will find optimal solutions, right suppliers will be designated and subcontracted, manufacturing facilities will be optimized, etc.

Production Volume
The previous assumption of time scale will be working if you will continue to manufacture big series of products. With growing number of manufactured items, your product cost will go down.

What is the problem with such assumptions? The only one, in my view. This is less and less happening in modern manufacturing. Market demanding customization in production and due to that time and product volume is going down. So, manufacturers need to manage very flexible practices in their environment to maintain balance between production volume, time and cost.

Now, I want to get to my original question. How PLM can help? PLM is managing product data and processes. How product cost will be resulted from that? My answer – PLM need to facilitate cross-functional IT functions in the organization. Your functional domains are separate. Most of the systems in today’s IT are department oriented and rarely have global organizational exposure.  PLM need to make a success in cross-functional data and processes management. This will be a key for PLM success in the organization. And this is still not happenings…

What do you think about that?
Best, Oleg


Back to basics: Multi-CAD and PLM

December 15, 2009

How many CAD systems do you have in your development organization? I do believe more than one. And if you will think about your Product Lifecycle Management future, the obvious need is to connect your multiple CAD environment in the way allows you to manage all your design records, reference your design information in processes, allow downstream design usage in ERP and manufacturing systems. Today, most of the systems claims support for multi-CAD environment. So, what is the deal? I’d like to outline the following characteristics and vendor’s trends in this space:

1. My CAD vs. other CADs. For PLM vendors with origins in CAD space, own CAD systems will be always a priority. This is natural for business and much easy for development to support CAD system that making the same product development release cycle as PDM/PLM environment. Vendor’s “my CAD” interfaces may have additional features that will not be available for “other CADs”.

2. CAD/PDM bundles. Due to previous trend, I can see forming of stable CAD/PDM bundles that provide tuned functional characteristics. Autodesk/ProductStream; SolidWorks/PDMWorks; SolidEdge/TeamCenter; NX/TeamCenter; CATIA/ENOVIA etc. Such bundles can be best in class solution for a specific CAD.

3. No CAD files. This is a very new trend. Introduced in CATIA V6, this trend represents technological morphing of CAD and PDM/PLM environment into a single entity. (Note: With future of Cloud/SaaS, this type of software architecture, can be potentially a very interesting approach, but I will discuss it in separate post).

So, what can be the possible strategy for a company to support multiple CAD in PLM environment? I can see two possible and very obvious options.

Option 1: Focus on PLM vendor selection, choose your PLM environment and maximize usage of multi-CAD interfaces provided by this vendor. If you also thinking about possible reducing of CAD system usages and/or you shifting from multi-CAD environment to “primary CAD” option this can be a good option, in my view.

Option 2:
Implement best in class CAD/PDM bundles and think about separate provider of PLM products, services, environment. You can find more appropriated to use PLM system provided by your ERP vendor or use some alternative technologies to build your PLM environment. I posted about this option earlier this year (Which Technology Can Convert Multiple PDMs into a Single PLM).

So, what do you think about these options? Can you share your experience? I’m interested to get your comments and thoughts.
Best, Oleg


Back to basics: PLM and Single Point of Truth?

December 14, 2009

I’m continuing with a set of ‘back to basics’ questions and discussion. My topic today is about singularity or what known in PLM as “a single point of truth”. I remember the time before computers were widely spread in engineering and manufacturing organizations and people used “Drawing on the wall”. The famous statement back to that time was – if you see drawing on the wall, think maybe there is “another wall”. Computers supposed to resolve the problem of multiple walls. However, the problem becomes even worst. Now you may have an unlimited number of “electronic walls” in your email system, disk on your laptop, server in your location or different enterprise systems. PLM comes with a very promising and illusive statement about single point of truth. From PLM standpoint, it defined as capability (or ability) to manage single (or unique) version of product data in your organization.

Now, my questions today about how to manage this uniqueness? Is it something you can see as an achievable goal for your next PLM implementation or wishful thinking? Is it something we can realistically implement in the organization with all systems we have in place? Can we achieve it in a single shot, or we need to have multiple steps to get there?

Here is my take on this (and I’m making it the most provoke as I can think about).

1. PLM Singularity (or single point of truth) represents a fundamental interest of people in the organization to organize and manage product data.
2. We can implement it in the organization, but it requires a significant effort that may vary depends on organization complexity and number of other systems involved into product development process and number of geographical locations company plan to cover by this system.
3. Implementing of singularity may take multiple steps until it will be achieved in the organization.

So, what is my conclusion today? I think, singularity cannot be considered as a goal for PLM implementation. The final cost can be too heavy to carry, and it will take long time to get there. Realistic PLM implementation need be done as “go by steps” approach. Each step will achieve goals helping organization to resolve specific issues they have in the organization or optimize existing processes. This is the only way to create something I’d call – lean PLM. If you want to implement single point of truth, think about playing “singularity chess” before :). (thanks, Paul Burgess blog for picture)


Just my thoughts. I’m looking forward to your comments.
Best, Oleg


Back to basics: Should PLM Take Control of Your BOMs?

December 11, 2009

I got a comment on my blog yesterday stating “back to basics”. Why do we discuss advanced stuff at the time very basic issues are still open and require our attention? At the same time, I had chance to see Arena’s web site is stating about “control of the BOMs”.

So I decide to ask you – should PLM take control of the Bill of Materials in the organization?

In the past, I discussed various topics related to Bill of Materials. If you are new on my blog, you may consider to check the following posts:

When BOM seeks the right enterprise nanny…
Seven Rules Towards Single Bill of Materials
How we can socialize PLM Bill of Materials?
Is it time for a synchronized Bill of Materials?
Improve organizational performance by the management of multiple Bill Of Materials
and some others…

The question of “control” in Bill of Material space is related to the organization of different functional process spaces. Normally, they represented by a different department in the organization. Those organizations that have rigid borders between departments will continue to like an idea of control everything belonging to their department. However, some ideas about horizontal integration can lead them towards better integration of BOMs.

So, there are two fundamental options I can see:

1/ Split Bill of Materials between functional processes
2/ Lean organization of Bill of Materials as a single entity

I don’t think there is a solid decision these days about what to choose and how to manage Bill of Materials. However, I think there is a strong tendency to “lean” in the organizations. Multiple business systems and their respective marketing department will continue their war for market share. For me, the question of “control” will become less relevant and question what you can do and how you get value of product data can be considered as a more interesting problem.

Just my thoughts.
Best, Oleg


Why Project Management is important for PLM?

September 14, 2009

plm-projectI had chance to write about Project Management in the past. However, I decided to get back to this topic again. Few days I had chance to read CIMData press release “CIMdata Releases a Review of IFS’ Project-Based PLM Support Capabilities” and I found it extremely interesting even in broader scope.

This is what Mr. Bilello wrote –  “Our research and experience,” said Mr. Bilello “clearly indicates that the success of a project is built on the development of accurate cost estimates, in much the same way as in project-driven manufacturing companies, which in turn are based on a well-defined project scope and work schedule that are well managed and monitored, and are sensitive to changes and limitations of resources and other work items.” Mr. Bilello emphasized the importance of treating cost estimating, project scheduling, and project cost control as an integrated process rather than a disjointed set of activities. “A key challenge when trying to develop this integrated process is the management of information and the association of that information to the tasks that create and use it.”

I’m very agreeing with Mr. Bilello- to develop an integrated process that able to have access and association with right information is the key capability and need from project-oriented enterprises, whatever type they are – discrete manufacturing or construction. So, getting back to my earlier conclusion the following 3 steps  can be, in my view, very important for forward thinking PLM implementations and PLM vendors/providers.

1. PLM Content and other related product information. This is an important enabler from the side of PLM. Content need to be available. To be able to re-use right design, engineering, manufacturing and supply chain content that controlled and managed from the life cycle standpoint by PLM systems.

2. Project Tools able to integrate and interplay with PLM content. Both PLM, but very important Project Management tools need to develop a capability to work with an extended set of information related to tasks and their optimization. Project Management tools need to become “project optimization engine” for every kind of content related to execution of a project.

3. Overall monitoring tools. I don’t see it necessarily part of PLM or Project Manager or even both. My point here is that people need to have one stream of information monitoring these days. Your decision, what is important, but I think vendors need to deliver one set of tools for users.

So, what is my conclusion? Project management is one of the key drivers to move execution in an organization of every type. However, they are not efficient when they cannot have right information in their hands to help people to use it efficiently. PLM can use project management tools and capabilities to deliver information to people doing execution as well as decision makers in an organization. To make this link will be very important. However, I don’t believe PLM vendors have sufficient specialization in order to develop a full scope project management tool. Therefore, to find right balance and re-use project management infrastructure, will be key priority for PLM vendor in the near future.

Best, Oleg


The PLM Industry most confusing buzzwords

July 13, 2009

plmbuzzwordsAs part of my daily life, I’m monitoring PLM industry and technology. I found very interesting part of news – pitches from companies about Product Lifecycle Management achievements. After reading, at least 50 of such press-communications on monthly basis, I finally can conclude that “A Company is a leading provider of Product Lifecycle Management Technologies, enabling to support full lifecycle of products, to decrease time-to market, enable data-reuse and in the end allows to everybody in organization to see single version of truth about what is going on in organization” :). Of course, there are variations, industry influence, specific company terms and slogans, but in the end everything is pretty “buzzword-compliant” in my view.

So, I decided to take a bit closer  insight on these buzzwords and discuss with you what it possible means. I’m going to provide you my version, how I understand and will be very interested in hear your version too. These are my 5 top buzzwords in Product Lifecycle Management.

#1: Single Version of Truth

Buzz: Of course, PLM is about the single version of truth. Before PLM all data about product in organization supposed to be located in different places. Started from mails about customer requirements, CAD models designer’s workstations, custom-made-databases with CAE results and ending in multiple CRM-ERP-MRP and other manufacturing systems. So, PLM will magically replace (or consolidate) all these systems and will manage all product-related data. So, when you finally get into your PLM dashboard/workbench/web-portal/desk… you will see what actually happens with your product and organization. Sounds like dream… yes?

Real life: I think successful PLM implementations succeeded to create central product data location and track significant portion of product data. This product data is mostly originated in design systems. For PLM based on ERP, there is change to have product data more connected to financial and manufacturing data since ERP systems provide single backbone for data management. For rest of PLM, integrations with ERP are mostly custom-made, tailored to specific organization and provide very limited scope of data integration. Application landscape in organization is counting dozens and sometimes hundreds different systems… BI and MDM are trying to provide notion of place where right information can be found.  

#2: Full Product Lifecycle

Buzz: Since all product data is under control, we have control for how manage change of product information, and we can control it from early development concepts until final manufacturing and support stages.

Real life: I think, this buzz is mostly true on the level of product data managed by PLM systems. In most of the cases PLM successfully manages Product Models, Engineering Bills and Product Configurations and Portfolios. For this scope, PLM really can control lifecycle. I’m not sure mainstream PLM implementations successfully manage manufacturing, customer and support data and solutions for these problems are mostly custom-tailored.

#3: Data Re-use

Buzz: Enter data only one time. You can re-use design, bill of material, product specifications…. These are magic words. And yes, this is extremely important. Furthermore, very important to re-use existing projects, portfolios and orders.

Real life: What is the problem with data re-use in my view? If you know what do you want to re-use, PLM system can provide you this information, and you will be able to re-use it. The biggest problem is that you not always exactly know what do you want to re-use. In this case, modern systems still cannot help you. And answers are deep inside of organization and hardly can be discovered…

#4: Shorter Time to Market

Buzz: Since you have all (product data and all what you need) under control, you will be able to optimize time, effort, resources and in finally to deliver your products faster to customers/OEMs/suppliers etc. In our dynamic life, factor of time becomes very important…

Real life: I had chance to see very successful PLM implementations that significantly improved organizational processes and enabled performance nobody could  achieve before. In my view, this is still not mainstream PLM and very depends on actual organization and their implementation.

#5: PLM Value

Buzz: I thought about this buzzword a lot. Everybody likes values. You want to sell them on every level. I like my PLM values too…

Real life: Some time ago, I had chance to write post about Relative vs. Absolute values of PLM. I think PLM over-selling absolute PLM values. There are companies and products that serve similar needs, but not associate themselves with PLM. I think we need to be more accurate in defintion of PLM relative values, and it will help us to make PLM more valuable for organizations.

I focused on these top five, in my view, buzzwords. But in fact I can bring much more buzzword compliant PLM ideas J. I’m looking forward to your comments and discussion. Bring more buzzwords, let me know what do you think…

Best, Oleg.


Do we have problem managing history and time in PLM?

June 10, 2009

I’d like to continue yesterday’s discussion about PLM basics and talk about our ability to manage history and time in Product Lifecycle Management. Since PLM is about *Lifecycles*, time and history are very fundamental pieces, I found that they are not actually managed at the appropriate level.

Let’s look at what we have today in most of the systems. There are two basic definitions related to history and time. The first is *Revision*. Without going into the complexity of defining revisions, versions, and various management patterns of these revisions and versions, I can say that a revision is an explicit characteristic of an object in the system and can be applied (with different behaviors) to documents, parts and some other objects in the system. The second is *Effectivity*. In context of our conversation, this characteristic is related to the specific date from which information in the system is valid when applied to the objects we are managing. For example, we may have a Bill of Materials effective for today and for the next month, etc.

Design Systems: Most of the design systems are implementing and supporting revision concepts. This is natural for a system and designer behavior, but they also burden their work as they are not in particularly interested in knowing the number of revisions they have today. In most cases, the system implements revisions  in order to track changes in design in other places in the system (i.e. ECO etc.).

Operational Systems: Most of the operational systems are fundamentally time-oriented. This is mostly related to ERP and their manufacturing and operational modules. Effectivity is a characteristic that applies to almost everything in these systems, such as parts and BOMs. Obviously, Revision and Effectivity based systems are very hard to integrate as a single system, and bridging these different behaviors is not simple.

Where do I see problems with today’s system from the standpoint of management of history and time? The biggest problem, in my view, is that all these characteristics and parameters are secondary next to how the system manages data. We can apply them on an object in the system, but we don’t manage time/history as a core operational behavior to apply to everything – definition of models, objects, processes, changes, etc. There are two main aspects (1) Definition; (2) User Experience. Although they are different, they are certainly dependent since you cannot achieve a specific operational level in the user experience without being able to define time/history level in the information you manage.

Definition: There are many elements of Product Lifecycle Management system today that do not allow you to apply *time* as a characteristic of this element. The most straightforward example is that you cannot manage differences in product data dependent on time. In most of the systems, if I change a definition of a Part or a Document, these definitions need to be applied to everything I manage in the system. I’m sure that some implementations, can resolve such a problem on a particular implementation level, but this is not a core system behavior. Another problem is to manage functional characteristics of the system based on time. In today’s dynamic world, there are situations where a certain functionality of the system (i.e. compliance), need to be applied to products with a specific date/time/history perspective. To make it seamless is very problematic, in my view. In most cases, you can change process definitions and manage the process definitions as snapshots, but this is will be an artificial task, since you will define it explicitly in the system. Another issue, in my view, is the ability to keep track of changes in the system and query it on a timely basis. This functionality is mostly not available.

User Experience: User experience is complex and simple at the same time. We can allow a system to present time in the part of the system where it is available. But there is no system today, in my opinion that allows you to use time as a fundamental operational element from the user experience standpoint. Here is my point. I think that most people work in a timely manner. Our memory is associative with time. We can remember what we did yesterday and we can remember part of what we did 2 months ago. I think that the user experience of a PLM system needs to be aligned with the ability to operate systems in timely manner. It will make a system more natural in its behavior and also easier understand.

To end this post, I’d like to point on Google Wave Playback feature. Even if Google Wave is not pretending to become PLM system, the way changes made in Wave was presented actually was very impressive and has a lot of potential for future collaborative systems. This means, of course, not only for Product Lifecycle Management J.

 Google Wave Playback Function Demo:

Google Wave Playback -1

Google Wave Playback -2

What is your view and how do you see time and history managed in our systems in the future?


Do we need to fix PLM basics?

June 9, 2009

The weekend normally puts me into a much deeper thinking mode about what to discuss on PLMtwine. Since the post about Top Five Disappointing PLM Technologies, I’ve been thinking more about fundamental PLM elements, rather than about specific pieces of PLM. In additional, it was very interesting to see how many thoughts and opinions came in the space of PLM after the Google Wave announcement ten days ago. When new technology comes, it always sounds like new techie stuff can fix old problems magically. But this is not always true, and sometime dressing new technology “clothes” on an “old body” do not create a magical change. So far, I’d like to share my thoughts about the ‘basics’ of Product Lifecycle Management – the things that, in my view, provide fundamental definitions and tool-sets for the rest of our PLM activity.

PLM Model

This is the most important piece of a PLM system. Since PLM is about product lifecycles, it’s essential to be able to create a product model and its surrounding world in the PLM system. In the current PLM landscape, I see three PLM model lines:

(1) CAD / Product Structure – these models evolve from design and product data management systems. The core advantages of these systems emerged from a very mature background and from the history of the CAD industry and its ability to create design and engineering models. In my view, these systems are perfect to represent product design in a static view. However, they lack capabilities to manage product model relationships with the business world. The core reason is in the roots of these models that are able to present only snapshots of various product views.

(2) ERP based– these models came out of business systems. In the beginning of MRP/MRP II, these model fundamentals are in manufacturing and business planning. These systems are much more sustainable to represent time-oriented business and much more appropriated for lifecycle (from a time management standpoint) – but since their core is business-oriented, most of them are missing the ability to keep comprehensive definitions of product design, engineering and other elements of product models.

(3) EDM/PDM – you can find many various product models created as part of different applications in the document and product data management domains. All of these models are normally suited very well for their original applications. The core problem with these models is that most of them are fragmented and not expandable on the level that is needed to keep a system running or expanded.

So, my intermediate conclusion is that Product Models for PLM are still in a very immature phase. Most probably, new technologies need to be applied to this space in order to be more efficient, and in order to scale the tasks we have today in Product Lifecycle Management.

Change Management

Since PLM is about lifecycles, “change” is another fundamental piece of PLM space. Unfortunately, in my view, most PLM systems are not created with ‘change’ in mind. Applying changes in these systems is a very expensive and time-consuming process. A lot of business logic and specific techniques create complex dependencies as to how PLM is implemented and as to what is needed in order to add specific new characteristics. At the same time, today’s business is very dynamic. These unmatched behaviors create a basic conflict between PLM implementation and the surrounding business environment.

Staged Assumption

This approach is directed to resolve the complexity of PLM implementation in the organization. Since all PLM expectations cannot be created in a single implementation shot, most of the implementation is done in stages. This is a very practical and efficient mechanism for separating PLM implementation on domains. In this way, each domain is treated separately as well additional ones being added year after year. The problem with this approach is the issue of “Change Management” that I discussed earlier in this post. From stage to stage, complexity of the system increases and is multiplied by inefficient change management, thus creating more and more expensive implementations. (I have to say that this characteristic is not unique for PLM and probable the same for all Enterprise systems).

Final conclusion for today: I don’t want to discover possible solutions and point to “magic” or “instant” technologies. However, I did want to about three fundamental behaviors of Product Lifecycle Management. Understanding these behaviors and their alignment with new technological achievements can change what we’ve been doing in PLM until now.

As usual, I’m looking forward to an open discussion, and will continue blogging about this topic.



Follow

Get every new post delivered to your Inbox.

Join 244 other followers