You are currently browsing the category archive for the ‘Configuration Management’ category.

The digital thread according to GE

In my earlier posts, I have explored the incompatibility between current PLM practices and future needs for digital PLM.  Digital PLM is one of the terms I am using for future concepts. Actually, in a digital enterprise, system borders become vague, it is more about connected platforms and digital services. Current PLM practices can be considered as Coordinated where the future for PLM is aiming at Connected information. See also Coordinated or Connected.

Moving from current PLM practices towards modern ways of working is a transformation for several reasons.

  • First, because the scope of current PLM implementation is most of the time focusing on engineering. Digital PLM aims to offer product information services along the product lifecycle.
  • Second, because the information in current PLM implementations is mainly stored in documents – drawings still being the leading In advanced PLM implementations BOM-structures, the EBOM and MBOM are information structures, again relying on related specification documents, either CAD- or Office files.

So let’s review the transformation challenges related to moving from current PLM to Digital PLM

Current PLM – document management

The first PLM implementations were most of the time advanced cPDM implementations, targeting sharing CAD models and drawings. Deployments started with the engineering department with the aim to centralize product design information. Integrations with mechanical CAD systems had the major priority including engineering change processes. Multidisciplinary collaboration enabled by introducing the concept of the Engineering Bill of Materials (EBOM).  Every discipline, mechanical, electrical and sometimes (embedded) software teams, linked their information to the EBOM. The product release process was driven by the EBOM. If the EBOM is released, the product is fully specified and can be manufactured.

Although people complain implementing PLM is complex, this type of implementation is relatively simple. The only added mental effort you are demanding from the PLM user is to work in a structured way and have a more controlled (rigid) way of working compared to a directory structure approach. For many people, this controlled way of working is already considered as a limitation of their freedom. However, companies are not profitable because their employees are all artists working in full freedom. They become successful if they can deliver in some efficient way products with consistent quality. In a competitive, global market there is no room anymore for inefficient ways of working as labor costs are adding to the price.

The way people work in this cPDM environment is coordinated, meaning based on business processes the various stakeholders agree to offer complete sets of information (read: documents) to contribute to the full product definition. If all contributions are consistent depends on the time and effort people spent to verify and validate its consistency. Often this is not done thoroughly and errors are only discovered during manufacturing or later in the field. Costly but accepted as it has always been the case.

Next Step PLM – coordinated document management / item-centric

When the awareness exists that data needs to flow through an organization is a consistent manner, the next step of PLM implementations come into the picture. Here I would state we are really talking about PLM as the target is to share product data outside the engineering department.

The first logical extension for PLM is moving information from an EBOM view (engineering) towards a Manufacturing Bill of Materials (MBOM) view. The MBOM is aiming to represent the manufacturing definition of the product and becomes a placeholder to link with the ERP system and suppliers directly. Having an integrated EBOM / MBOM process with your ERP system is already a big step forward as it creates an efficient way of working to connect engineering and manufacturing.

As all the information is now related to the EBOM and MBOM, this approach is often called the item-centric approach. The Item (or Part) is the information carrier linked to its specification documents.

 

Managing the right version of the information in relation to a specific version of the product is called configuration management. And the better you have your configuration management processes in place, the more efficient and with high confidence you can deliver and support your products.  Configuration Management is again a typical example where we are talking about a coordinated approach to managing products and documents.

Implementing this type of PLM requires already more complex as it needs different disciplines to agree on a collective process across various (enterprise) systems. ERP integrations are technically not complicated, it is the agreement on a leading process that makes it difficult as the holistic view is often failing.

Next, next step PLM – the Digital Thread

Continuing reading might give you the impression that the next step in PLM evolution is the digital thread. And this can be the case depending on your definition of the digital thread. Oleg Shilovitsky recently published an article: Digital Thread – A new catchy phrase to replace PLM? related to his observations from  ConX18 illustrate that there are many viewpoints to this concept. And of course, some vendors promote their perfect fit based on their unique definition. In general, I would classify the idea of Digital Thread in two approaches:

The Digital Thread – coordinated

In the Digital Thread – coordinated approach we are not revolutionizing the way of working in an enterprise. In the coordinated approach, the PLM environment is connected with another overlay, combining data from various disciplines into an environment where the dependencies are traceable. This can be the Aras overlay approach (here explained by Oleg Shilovitsky), the PTC Navigate approach or others, using a new extra layer to connect the various discipline data and create traceability in a more or less non-intrusive way. Similar concepts, but less intrusive can be done through Business Intelligence applications, although they are more read-only than a system approach.

The Digital Thread – connected

In the Digital Thread – connected approach the idea is that information is stored in an extreme granular way and shared among disciplines. Instead of the coordinated way, where every discipline can have their own data sources, here the target is to be data-driven (neutral/standard formats). I described this approach in the various aspects of the model-based enterprise. The challenge of a connected enterprise is the standardized data definition to make it available for all stakeholders.

Working in a connected enterprise is extremely difficult, in particular for people educated in the old-fashioned ways of working. If you have learned to work with shared documents, like Google Docs or Office documents in sharing mode, you will understand the mental change you have to go through. Continuous sharing the information instead of waiting until you feel your part is complete.

In the software domain, companies are used to work this way and to integrate data in a continuous stream. We have to learn to apply these practices also to a complete product lifecycle, where the product consists of hardware and software.

Still, the connect way if working is the vision where digital enterprises should aim for as it dramatically reduces the overhead of information conversion, overhead, and ambiguity. How we will implement in the context of PLM / Product Innovation is a learning process, where we should not be blocked by our echo chamber as Jan Bosch states it in his latest post: Don’t Get Stuck In Your Company’s Echo Chamber

Jan Bosch is coming from the software world, promoting the Software-Centric Systems conference SC2 as a conference to open up your mind. I recommend you to take part in upcoming PLM related events: CIMdata’s PLM roadmap Europe combined with PDT Europe on 24/25th October in Stuttgart, or if you are living in the US there is the upcoming PI PLMx CHICAGO 2018 on Nov 5/6th.

Conclusion

Learning and understanding are crucial and takes time. A digital transformation has many aspects to learn – keep in mind the difference between coordinated (relatively easy) and connected (extraordinarily challenging but promising). Unfortunate there is no populist way to become digital.

Note:
If you want to continue learning, please read this post – The True Impact of Industry 4.0 Revealed  -and its internal links to reference information from Martijn Dullaart – so relevant.

 

Advertisements

dummies_logo

 

In my earlier posts, I described generic PLM data model and practices related to Products, BOMs en recently EBOM and (CAD) Documents. This time I want to elaborate a little bit more on the various EBOM characteristics.

 

The EBOM is the place where engineering teams collaborate and define the product. A released EBOM is supposed to give the full engineering specification how a product should behave including material quality and tolerances. This makes it different from the MBOM, which contains the specification of how this product should be manufactured based on exact components and materials.

Depending on the type of product there are several EBOM best practices which I will discuss here (briefly) in alphabetical order:

EBOM & Buy Part

PDM_ERP_AML_AVLUsually, an EBOM consists of Make and Buy parts –an attribute on the EBOM part indicates the preferred approach. Make parts are typically sourced towards qualified suppliers, where Buy parts can be more generic and based on qualified vendors. Engineering specifies who are the approved Manufacturers for the part (AML) and purchasing decides who are the approved Vendors for this part (AVL). In general Buy parts do not need an engineering efforts every time the part is used in a product.

EBOM & CAD related

My previous post already discussed some of the points related to EBOM and CAD Documents. Here I want to extend a little more addressing the close relation between MCAD parts and EBOM parts. In particular in the Engineering To Order industry, there is, most of the time, no standard product to relate to. In that case, Mechanical CAD can be the driver for the EBOM definition and usually EBOM Make parts are designed uniquely. The challenge is to understand similar parts that might exist and reuse them. Classification (and old post here) and geometric search capabilities support the modern engineer. I will come back to classification in a later post

EBOM – Configuration Item

cmiiIn case a product is designed for mass production throughout a longer lifetime, it becomes necessary to manage the product configuration over time. How is the product is defined today and avoid the need to have for each product variant a complete EBOM to manage. The EBOM can be structured with Options and Variants. In that case, having Configuration Items in the EBOM is crucial. The Configuration Item is the top part that is versioned and controlled. Parts below the configuration item, mostly standard parts do not impact the version of the Configuration Item as long as the Form-Fit-Function from the Configuration Item does not change. Configuration Management is a topic on its own and some people believe PLM systems were invented to support Configuration Management.

EBOM – Company Standard Part

Standard Parts are often designed parts that should be used across various products or product lines. The advantage of company standard parts is that it reduces costs throughout the whole product lifecycle. Less design time, less manufacturing setup time and material sourcing effort and potential lower material cost thanks to higher volumes. Any EBOM part could become at a certain moment a Company Standard part and it is recommended to use a classification related to these parts. Otherwise they will not be found again. As mentioned before I will come back to classification.

EBOM – Functional group

Sometimes during the design of a product, several parts are logically grouped together from the design point of view, either because they are modular or because they always appear as a group of parts.

The EBOM, in that case, can contain phantom parts, which do not represent an end item. These phantom parts assist the company in understanding changing one of the individual parts in this functional group.

EBOM – Long Lead

In typical Engineering to Order or Build To Order deliveries there are components on the critical path of the product delivery. Components with a long lead time should be identified and ordered as early as possible during the delivery process. Often the EBOM is not complete or mature enough to pass through all the information to ERP. Therefore Long Lead items require a fast track towards ERP and a special status in the EBOM reflecting its ordering status. Long Lead items are the example where a company can benefit from a precise interaction between PLM and ERP with various status handshakes and approvals during the delivery process

EBOM – Make parts

Make Parts in an EBOM are usually specified by their related model and drawings. Therefore Make Parts usually have revisions but be aware that they do not follow the same versioning of the related model or drawing. A Make Part is in an In Work status as long as the EBOM is not released. Once the model is approved, the EBOM part can be approved or released. Often companies do not want to release the data as long as manufacturing is not completed. This to make sure that the first revision comes out at the first delivery of the product.

EBOM – Materials

In many mechanical assemblies, the designer specifies materials with a particular length. For example a rubber strip, tubing / piping. When extracting the information from the 3D CAD assembly, this material instance will get a unique identifier. Here it is important that the Material Part has an attribute that describes the material specification. In the ideal data model, this is a reference to a Materials library. Next when manufacturing engineering is defining the MBOM, they can decide on material quantities to purchase for the EBOM Material.

EBOM – Part Number

QRThis could be a post on its own. Do we need intelligent part numbers or can we use random generated unique numbers? I have a black and white opinion about that. If you want to achieve a digital enterprise you should aim for random generated unique numbers. This because in a digital enterprise data is connected without human transfer. The PLM and ERP link is unambiguous. Part recognition at the shop floor can be done with labels and scanning at the workstation. There is no need for a person to remember or transfer information from one system or location by understanding the part number. The uniquely generated number make sure every person will have a look at the digital metadata online available. Therefore immediately seeing a potential status change or upcoming engineering change. Supporting the intelligent numbering approach allows people to work disconnected again, therefore not guaranteeing that an error-free activity takes place. People make mistakes, machines usually not.

EBOM – Service Parts

It is important to identify already in the EBOM which parts need to be serviced in operation and engineering should relate the service information already to the EBOM part. This could be the same single part with a different packaging or it could be a service kit plus instructions linked to the part. In a PLM environment, it is important that this activity is done upfront by engineering to avoid later retrieval of the data and work again on service information. A sensitive point here is that engineers currently in the classical approach are not measured on the benefits they deliver downstream when the products are in the field. Too many companies work here in silos.

EBOM – Standard Parts

3dFinally, as I reach already the 1000 words, a short statement about EBOM standard parts. These standard parts, based on international or commercial standards do not need a revision and often they have a specification sheet, not necessary a 3D model for visualization. Classification is crucial for Standard Part and here I will write a separate post about dealing with Standard Parts, both mechanical and electrical.

Concluding: this post we can see that the EBOM is having many facets and based on the type of EBOM part different behavior is expected. It made me realize PLM is not that simple as I thought. In general when defining an EBOM data model you would try to minimize the specific classes for the EBOM part. Where possible, solve it with attributes (Make/Buy – Long Lead – Service – etc.). Use classification to store specific attributes per part type related to the part. Classification will be my next topic as it appears

Feel free to jump on any of the EBOM characteristics for an extended discussion

note: images borrowed from the internet contain links to the original location where I found them. The context there is not always relevant for this post.

PLM_profI believe that PLM with its roots in automotive, aerospace and discrete manufacturing is accepted, as a vital technology / business strategy to make a company more competitive and guarantee its future. Writing this sentence feels like marketing, trying to generalize a lot of information in one sentence.

Some questions you might raise:

  • Is PLM a technology or business strategy?
  • Are companies actually implementing PLM or is it extended PDM?
  • Does PLM suit every company?

My opinion:

  • PLM is a combination of technology (you need the right IT-infrastructure / software to start from) and the implementation is a business approach (it should be a business transformation). PLM vendors will tell you that it is their software that makes it happen; implementers have their preferred software and methodology to differentiate themselves. It is not a single simple solution. Interesting enough Stephen Porter wrote about this topic this week in the Zero Wait-State blog:  Applying the Goldilocks Principle to PLM – finding balance. Crucial for me is that PLM is about sharing data (not only/just documents) with status and context. Sharing data is the only way to (information) silos in a company and provide to each person a more adequate understanding.
  • Most companies that claim to have implemented PLM have implemented just extended PDM, which means on top of the CAD software add other engineering data and processes. This was also mentioned by Prof Eigner in his speech during PLM Innovation early this year in Munich. PLM is still considered by the management as an engineering tool, and at the other side they have ERP. Again sharing all product IP with all its iterations and maturity (PLM) and pushing execution to ERP is still a unique approach for more traditional companies. See also a nice discussion from my blog buddy Oleg: BOM: Apple of Discord between PLM and ERP?
  • Not every business needs the full PLM capabilities that are available. Larger companies might focus more on standardized processes across the enterprise; smaller companies might focus more on sharing the data. There is to my opinion no system that suits all. One point they are all dreaming of: usability and as in small companies PLM decisions are more bottom-up the voice of the user is stronger here. Therefore I might stick to my old post PLM for the mid-market: mission impossible ?

However, the title of this blog post is: PLM for all industries. Therefore, I will not go deeper on the points above. Topics for the future perhaps.

PLM for all industries ?

This time I will share with you some observations and experiences based on interactions with companies that not necessary think about PLM. I have been working with these companies the past five years. Some with some success, some still in an awareness phase. I strongly believe these companies described below would benefit a lot from PLM technology and practices.

Apparel

imageIn July, I wrote about my observations during the Product Innovation Apparel event in London. I am not a fashion expert and here I discovered that, in a sense, PLM in Apparel is much closer to the modern vision of PLM than classic PLM. They depend on data sharing in a global model, disciplines and suppliers driven by their crazy short time to market and the vast amount of interactions in a short time; otherwise they would not be competitive anymore and disappear.

This figure represented modern PLM

PLM in Apparel is still in the early stages. The classic PLM vendors try to support Apparel with their traditional systems and are often too complicated or not user-friendly enough. The niche PLM vendors in Apparel have a more lightweight entry level, simple and easy, sometimes cloud-based. They miss the long-term experience of building all the required technology, scalability and security, in their products, assuring future upgradability. For sure this market will evolve, and we will see consolidation

Owner / Operators nuclear

nuclearFor s nuclear plants it is essential to have configuration management in place, which in short would mean that the plant operates (as-built) is the same as specified by its specifications (as-designed). In fact this is hardly the case. A lot of legacy data in paper or legacy document archives do not provide the actual state. They are stored and duplicated disconnected from each other. In parallel the MRO system (SAP PM / Maximo are major systems) runs in an isolated environment only dealing with actual data (that might be validated).

In the past 5 years I have been working and talking with owners/operators from nuclear plants to discuss and improve support for their configuration management. frog

The main obstacles encountered are:

  • The boiling frog syndrome –it is not that bad
    (and even if it is bad we won´t tell you)
  • An IT-department that believes configuration management is about document management – they set the standards for the tools (Documentum / SharePoint – no business focus)
  • An aging generation, very knowledgeable in their current work, but averse for new ways of information management and highly demanding to keep the status quo till they retire
  • And the “If it works, do not touch it” – approach somehow related to the boiling frog syndrome.

Meanwhile business values for a change using a PLM infrastructure have been identified. With a PLM environment completing the operational environment, an owner/operator can introduce coordinated changes to the plant, reduce downtime and improve quality of information for the future. One week less down-time could provide a benefit of million Euros.

No_roiHowever with the current, lowering electricity costs in Europe, the profits for owner/operators are under pressure and they are not motivated to invest at this time in a long term project. First satisfy the shareholders Sad smile

 

 

Owner / Operators other process oriented plants

almIn the nuclear industry safety is priority one and required by the authorities. Therefore, there is a high pressure for data quality and configuration management. For other industries the principles remain the same. Here, depending on the plant lifetime, criticality of downtime and risk for catastrophes, the interest for a PLM based plant information management platform varies. The main obstacles here are similar to the nuclear ones:frog

  • Even a bigger boiling frog as we have SAP PM – so what else do we need
  • IT standardizes on a document management solution
  • The aging workforce and higher labor costs are not identified yet as threats for the future looking towards competing against cheaper and modern plants in the upcoming markets – the boiling frog again.

The benefits for a PLM based infrastructure are less direct visible, still ROI estimates predict that after two years a break-even can be reached. Too long for share holder driven companies L although in 10 years time the plant might need to close due to inefficiencies.

 

EPC companies

epcEPC (Engineering, Procurement and Construction) and EPCIC (Engineering, Procurement, Construction, Installation and Commissioning) companies exist in many industries: nuclear new build, oil & gas, Chemical, Civil construction, Building Construction.

They all work commissioned for owner / operators and internally they are looking for ways to improve their business performance. To increase their margin they need to work more efficient, faster and often global, to make use of the best (cheaper) resources around the world. A way to improve quality and margin is through more reuse and modularization. This is a mind-shift as most EPC companies have a single project / single customer per project in mind, as every owner/operator also pushes their own standards and formats.

knowledgeIn addition, when you start to work on reuse and knowledge capturing, you need to have a way to control and capture your IP. And EPCs want to protect their IP and not expose too much to their customers to maintain a dependency on their solution.

The last paragraph should sound familiar to the challenges automotive and aerospace supply chains had to face 15 years ago and were the reasons why PLM was introduced. Why do EPC companies not jump on PLM?

  • They have their home-grown systems – hard to replace as everyone likes their own babies (even when they reach adolescence or retirement symptoms)
  • Integrated process thinking needs to be developed instead of departmental thinking
  • As they are project-centric, an innovation strategy can only be budgeted inside a huge project, where they can write-off the investment to their customer project. However this makes them less competitive in their bid – so let´s not do it
  • Lack of data and exchange standards. Where in the automotive and aerospace industry CATIA was the driving 3D standard, such a standard and 3D is not available yet for other industries. ISO 15926 for the process industry is reasonable mature, BIM for the construction industry is still in many countries in its discovery phase.
  • Extreme lose supplier relations compared to automotive and aerospace, which combined with the lack of data exchanges standards contributes to low investments in information infrastructure.

Conclusion

In the past 5 years I have been focusing on explaining the significance of PLM infrastructure and concepts to the industries mentioned before. The value lies on sharing data, instead of working in silos. If needed do not call it PLM, call it online collaboration, controlled Excel on the cloud.
Modern web technologies and infrastructure make this all achievable; however it is a business change to start sharing. Beside Excel the boiling frog syndrome dominates everywhere.

  • What do you think?
  • Do you have examples of companies that took advantage of modern PLM capabilities to change their business?

I am looking forward to learn more.

Below some links that are relevant for this post as a reference:

imageSome weeks ago PLMJEN asked me my opinion on Peter Schroer´s post and invitation to an ARAS webinar called: Change Management: One Size Will Never Fit All. Change Management is actually a compelling topic, and I realized I had never written a dedicated post to such an essential topic. The introduction from Peter was excellent:

Change management is the toughest thing inside of PLM. It’s also the most important.

For the rest, the post elaborated further into software capabilities and the value of having templates processes for various industry practices. I share that opinion when talking to companies that are starting to establish their processes. It is extremely rare that an existing company will change its processes towards more standard processes delivered by the PLM system when implementing a new system. The rule of thumb is People, Processes and Tools. This all is nicely explained by Stephen Porter in his latest blog post Beware the quick fix successful plm deployment strategies. As I was not able to attend the webinar, here are my more general thoughts related to change management and why it is essential for PLM.

Change Management has always been there

It is not that PLM has invented change management. Before companies started to use ERP and PDM systems, every company had to deal with managing changes. At that time, their business was mostly local and compared with today slow. “Time to market” was more a “Time to Region” issue. Engineering and Manufacturing were operating from the same location. Change management was a personal responsibility supported by (paper) documents and individuals. Only with the growing complexity of products, growing and global customer demands and increasing regulatory constraints it became impossible to manage change in an unstructured manner.

Survival of the fittest change organization

imageI have worked with several companies where change management was a running Excel business. Running can be interpreted in two ways. The current operation could not stop and step back and look into an improvement cycle, and a lot of people were running to collect, check and validate information in order to make change estimates and make decisions based on the collected data.

When a lot of people are running, it means your business is at risk. A lot of people means costs for data (re)search and handling are higher than the competition if this can be done automatically. Also in countries of low labor costs, a lot of people running becomes a threat at a certain moment. In addition, running people can make mistakes or provide insufficient information, which leads to the wrong decisions.

Wrong decisions can be costly. Your product may become too expensive; your project may delay significant as information was based on conflicting information between disciplines or suppliers. Additional iterations to fix these issues lead to a longer time to market. Late discoveries can lead to severe high costs. For certain, when the product has been released to the market the cost might be tremendous.

NoChangeFrom the other side if making changes becomes difficult because the data has to be collected from various sources through human intervention, organizations might try to avoid making changes.

Somehow this is also an indirect death penalty. The future is for companies that are able to react quickly at any time and implement changes.

The analogy is with a commercial aircraft and a fighter plane. Let’s take the Airbus 380 in mind and a modern fighter jet the Joint Strike Fighter (JSF). The Airbus 380 brings you comfortable from A to B as long as A and B are well prepared places to land. The flight is comfortable as the plane is extremely stable. It is a well planned trip with an aversion to change of the trajectory.

The JSF airplane by definition is an unstable plane. It is only by its computer steering control that the plane behaves stable in the air. The built-in instability makes it possible to react as quickly as possible to unforeseen situations, preferable faster than the competition. This is a solution designed for change.

Based on your business you all should admire the JSF concept and try to understand where it is needed in your organization.

Why is change management integrated in PLM so important?

If we consider where changes appear the most, it is evident in the early lifecycle of the product most of the changes occur. And as long as they are in the virtual world with uncommitted costs to the product they are relative cheap. To my surprise many engineering companies and engineering departments work only with change management outside their own environment. Historically because outside their environment connected to prototyping or production costs of change are the highest. And our existing ERP system has an Engineering Change process – so let’s use that.

whyworryMeanwhile, engineering is used to work with the best so far information. At any moment, every discipline stores their data in a central repository. This could be a directory structure or PDM systems. Everyone is looking to the latest data. Files are overwritten with the latest versions. Data in the PDM system shows the latest version to all users. Hallelujah

And this is the place where it goes wrong. A mechanical engineer has overlooked a requirement in the specification that has been changed. Yes, the latest version of the 20 page document is there. An electrical engineer has defined a new control system for the engine, but has not noticed that the operating parameters of the motor have been changed. Typical examples where a best so far environments creates the visibility, but the individual user cannot understand the impact of a change anymore (especially when additional sites perform the engineering work)

Here comes the value of change management in PLM. Change Management in PLM can be light weighted in the early design phases, providing checks on changes (baselines) and notifications to disciplines involved. Approval processes are more agreements to changes to implement and their impact on all disciplines.

sel_aPLM supports the product definition through the whole product lifecycle, change management at each stage can have its particular behavior. In the early stages a focus on notifications and visibility of change, later checking the impact based on the maturity of the various disciplines and finally when running into production and materials commitment towards a strict and organized change mechanism. It is only in a PLM system where the gradual flow can be supported seamless

Change Management and ERP

As mentioned before, most manufacturing companies have implemented change management in ERP as the costs of change are the highest when the product capabilities are committed. However, the ERP system is not the place to explore and iterate for further improved solutions. The ERP system can be the trigger for a change process based on production issues. However the full implementation of the change requires a change in the product definition, the area where PLM is strong.

NOTE: on purpose I am not mentioning a change in the engineering definition as in some cases the engineering definition might remain the same, but only the manufacturing process or materials need to be adapted. PLM supports iterations, not an ERP execution matter.

Change Management and Configuration Management

cmiiSo far we have been discussing how the manufacturing system would be able to offer products based on the right engineering definition. As each specific product might not have an individual definition checked at any time, there is the need for configuration management (CM). Proper implemented configuration management assures there is a consistent relationship between how the product is specified and defined and the way it is produced. Read a refined and precise explanation on wiki

In one of my following posts I will focus on configuration management practices and why PLM systems and Configuration Management are like a Siamese twins

Conclusion:

Storing your data in a (PLM) system has only value if you are able to keep the actual status of the information and its context. Only then a person can make the right decisions immediately and with the right accuracy. The more systems or manual data handling, the less completive your company will be. Integrated and lean change management means survival !

dontmissLast week I started my final preparation for the PLM Innovation Congress 2012 on February 22nd and 23rd in Munich, where I will speak about Making the Case for PLM. Looking forward for two intensive days of knowledge sharing and discussion

The question came to my mind that when you make the case for PLM, you also must be clear about what you mean by PLM. And here I started to struggle a little. I have my perception of PLM, but I am also aware everyone has a different perception about the meaning of PLM.

cmpicI wrote about it last year, triggered by a question in the CMPIC group (configuration management) on LinkedIn. The question was Aren’t CM and PLM the same thing ? There was a firm belief from some of the members that PLM was the IT-platform to implement CM.

PLM_PDM_CAD_networkA few days ago Inge Craninckx posted a question in the PDM PLM CAD network group about the definition of PLM based on a statement from the PLMIG. In short:

“PDM is the IT platform for PLM.”Or, expressed from the opposite viewpoint: “PLM is the business context in which PDM is implemented

The response from Rick Franzosa caught my attention and I extracted the following text:

The reality is that most PLM systems are doing PDM, managing product data via BOM management, vaulting and workflow. In that regard, PDM [read BOM management, vaulting and workflow], IS the IT platform for the, in some ways, unfulfilled promise of PLM.

I fully agree with Rick’s statement and coming back to my introduction about making the case for PLM, we need to differentiate how we implement PLM. Also we have to take into our minds that no vendor, so also not a PLM vendor, will undersell their product. They are all promising J

Two different types of PLM implementation

Originally PLM has started in 1999 by extending the reach of Product Data outside the engineering department. However besides just adding extra functionality to extend the coverage of the lifecycle, PLM also created the opportunity to do things different. And here I believe you can follow two different definitions and directions for PLM.

Let’s start with the non-disruptive approach, which I call the extended PDM approach

Extended PDM

expressWhen I worked 6 years ago with SmarTeam on the Express approach, the target was to provide an OOTB (Out of the Box) generic scenario for mid-market companies. Main messages were around quick implementation and extending the CAD data management with BOM and Workflow. Several vendors at that time have promoted their quick start packages for the mid-market, all avoiding one word: change.

I was a great believer of this approach, but the first benchmark project that I governed demonstrated that if you want to do it right, you need to change the way people work, and this takes time (It took 2+ years). For the details: See A PLM success story with ROI from 2009

NoChange

Cloud based solutions have become now the packaging for this OOTB approach enriched, with the ease of deployment – no IT investment needed (and everyone avoids the word change again).

If you do not want to change too much in your company, the easiest way to make PDM available for the enterprise is to extend this environment with an enterprise PLM layer for BOM management, manufacturing definition, program management, compliancy and more.

Ten years ago, big global enterprises started to implement this approach, using local PDM systems for mainly engineering data management and a PLM system for the enterprise. See picture below:

clip_image002

This approach is now adapted by the Autodesk PLM solution and also ARAS is marketing themselves in the same direction. You have a CAD data management environment and without changing much on that area, you connect the other disciplines and lifecycle stages of the product lifecycle by implementing an additional enterprise layer.

The advantage from this approach is you get a shared and connected data repository of your product data and you are able to extend this with common best practices, BOM management (all the variants EBOM/MBOM/SBOM, …) but also connect the market opportunities and the customer (Portfolio management, Systems engineering)

myplmThe big three, Dassault Systemes, Siemens PLM and PTC, provide the above functionality as a complete set of functionalities – either as a single platform or as a portfolio of products (check the difference between marketing and reality).

Oracle and SAP also fight for the enterprise layer from the ERP side, by providing their enterprise PLM functionality as an extension of their ERP functionality. Also here in two different ways: as a single platform or as a portfolio of products. As their nature is on efficient execution, I would position these vendors as the one that drive for efficiency in a company, assuming all activities somehow can be scheduled and predicted

My statement is that extended PDM leads to more efficiency, more quality (as you standardize on your processes) and for many companies this approach is a relative easy way to get into PLM (extended PDM). If your company exists because of bringing new products quickly to the market, I would start from the PDM/PLM side with my implementation.

The other PLM – innovative PLM

idea

Most PLM vendors associate the word PLM in their marketing language with Innovation. In the previous paragraph I avoided on purpose the word Innovation. How do PLM vendors believe they contribute to Innovation?

This is something you do not hear so much about. Yes, in marketing terms it works, but in reality? Only few companies have implemented PLM in a different way, most of the time because they do not carry years of history, numbering systems, standard procedures to consider or to change. They can implement PLM in a different way, as they are open to change.

If you want to be innovative, you need to implement PLM in a more disruptive manner, as you need to change the way your organization is triggered – see the diagram below:

PLM_flow

The whole organization works around the market, the customer. Understanding the customer and the market needs at every moment in the organization is key for making a change. For me, an indicator of innovative PLM is the way concept development is connected with the after sales market and the customers. Is there a structured, powerful connection in your company between these people? If not, you do the extended PLM, not the innovative PLM.

Innovative PLM requires a change in business as I described in my series around PLM 2.0. Personally I am a big believer that this type of PLM is the lifesaver for companies, but I also realize it is the hardest to implement as you need people that have the vision and power to change the company. And as I described in my PLM 2.0 series, the longer the company exist, the harder to make a fundamental change.

Conclusion

There are two main directions possible for PLM. The first and oldest approach, which is an extension of PDM and the second approach which is a new customer centric approach, driving innovation. Your choice to make the case for one or the other, based on your business strategy.

Looking forward to an interesting discussion and see you in Munich where I will make the case

PLM_inno_2012

cmpic Recently i noticed two different discussions. One on LinkedIn in the CMPIC®  Configuration Management Trends group, where Chris Jennings started with the following statement:

Product Lifecycle Management (PLM) vs CM

An interesting debate has started up here about PLM vs CM. Not surprisingly it is revealing a variety of opinions on what each mean. So I’m wondering what sort of reaction I might get from this erudite community if I made a potentially provocative statement like …
“Actually, PLM and CM are one and the same thing” ?

24 days ago

It became a very active discussion and it was interesting to see that some of the respondents saw PLM as the tool to implement CM. Later the discussion moved more towards system engineering, with a focus on requirements management. Of course requirements management is key for CM, you could say CM starts with the capturing of requirements.

myplm

There was some discussion about what is the real definition of PLM and this triggered my post. Is the definition of PLM secured in a book – and if so – in which book as historically we have learned that when the truth comes from one book there is discussion

But initially in the early days of the PLM, requirements management was not part of the focus for PLM vendors. Yes, requirements and specifications existed in their terminology but were not fully integrated. They focused more on the ‘middle part’ of the product lifecycle – digital mockup and virtual manufacturing planning. Only a few years later PLM vendors started to address requirements management (and systems engineering) as part of their portfolio – either by acquisitions of products or by adding it natively.

For me it demonstrates that PLM and CM are not the same. CM initially had a wider scope than early PLM systems supported, although in various definitions of PLM you will see that CM is a key component of the PLM practices.

plmbookStill PLM and CM have a lot in common, I wrote about is a year ago in my post: PLM, CM and ALM; not sexy ! and both fighting to get enough management support and investments.  There is in the CMIP group another discussion open with the title: What crazy CM quotes have you heard ? You can easily use these quotes also for the current PLM opinion. Read them (if you have access and have fun)

But the same week another post caught my interest. Oleg’s post about Inforbix and Product Data Management. I am aware that also other vendors are working on concepts to provide end users with data without the effort of data management required.  Alcove9 and Exalead are products with a similar scope and my excuses to all companies not mentioned here.

cm_futureWhat you see it the trend to make PLM more simple by trying to avoid the CM practices that often are considered as “non-value add”, “bureaucracy” and more negative terms. I will be curious to learn how CM practices will be adhered by these “New Generation of PDM” vendors, as I believe you need CM to manage proactively your  products.

What is your opinion about CM and PLM  – can modern PLM change the way CM is done ?

observation This time it is hard to write my blog post. First of all, because tomorrow there will be the soccer final between Holland and Spain and as a Virtual Dutchman I still dream of a real cup for the Dutch team.

Beside that I had several discussions around PLM (Product Lifecycle Management), CM (Configuration Management) and ALM (Asset Lifecycle Management), where all insiders agreed that it is hard to explain and sell the value and best practices, because it is boring, because it is not sexy, etc, etc. 

So why am I still doing this job…..

Product Lifecycle Management (PLM)

3dlive

If you look at trade shows and major events of PLM vendors, the eye-catching hdplmstuff is 3D (CAD).  

Dassault Systemes introduced in 2006 3DLive as the 3D collaboration layer for all users with the capability to provide in a 3D manner (see what you mean) on-line role specific information, coming from different information sources.  Recently Siemens introduced their HD PLM, which as far as I understood, brings decision making capabilities (and fun) to the user.

Both user interfaces are focusing on providing information in a user-friendly and natural way – this is sexy to demonstrate, but a question never asked: “Where does the information come from ? “

And this is the boring but required part of PLM. Without data stored or connected to the PLM system, there is no way these sexy dashboards can provide the right information. The challenge for PLM systems will be to extract this information from various applications and from users to have the discipline to enter the needed data. 

Those software vendors, who find an invisible way to capture the required information hold the key to success. Will it be through a more social collaboration with a lot of fun, I am afraid not. The main issue is that the people who need to enter the data are not rewarded for doing it. It is downstream the organization, in the product lifecycle, that other people benefit from the complete information. And I even suspect in some organizations that there are people who do not want share data to assure being required in the organization – see also Some users do not like the single version of the truth

important

So who can reward these users and make them feel important. I believe this is a management job and no sexy (3D) environment will help here

 

Configuration Management (CM)

cmii Although it is considered a part of PLM, I added configuration management to my post as a separate bullet. Two weeks ago, I attended the second day of the  CMII Europe conference in Amsterdam. What I learned from this event was that the members of the CMII community are a group of enthusiastic people with somehow the same vision as PLM missionaries. 

Quoting the organization:  “CMII is about changing faster and documenting better. It is about accommodating change and keeping requirements clear, concise and valid.” 

And it was interesting to listen to speeches of the members. Like with PLM, everyone is convinced configuration management brings a lot of value to a company, they are also fighting for acknowledgement. Not sexy is what I learned here and also here those people who are responsible for data accuracy are not necessary the ones that benefit (the most).

Like PLM, but even more in Configuration Management, the cultural change should not be neglected. Companies are used to have a certain level of “configuration management”, often based on manual processes, not always as efficient, clear and understood and satisfactory for the management, till something happens due to incorrect information.

whyworry

  Of course the impact of an error differentiates per industry, a problem occurring due to wrong information for an  airplane is something different compared to a problem with a  sound system.

So the investment in configuration management pays of for complex products with critical behaviors and in countries where labor costs are high. It was interesting to learn that a CM maturity assessment showed that most companies score below average when it comes to management support and that they score above average when talking about the tools they have in place.

This demonstrates for me that also for configuration management, companies believe tools will implement the change without a continuous management push. I remember that in several PLM selection processes, prospects were asking for all kind of complex configuration management capabilities, like complex filtering of a product structure. Perhaps pushed by a competitor, as at the end it was never implemented 😦

Asset Lifecycle Management (ALM)

iaea In some previous posts,  I wrote about the benefits a PLM system can bring, when used as the core system for all asset related information. For nuclear plants, the IAEA (International Atomic Energy Agency) recommends to use configuration management best practices and I have met an owner/operator of a nuclear plant who recognized that a PLM system brings the right infrastructure, instead of SAP for example, which has more focus on operational data.

Also I had a meeting with another owner/operator, who was used to manage their asset data in a classical manner – documents in an as-built environment and changes of documents in various projects environments.

alm_1 When discussing the ALM best practices based on a PLM system, it was clear all the benefits it could bring, but also we realized that implementing these concepts would require a conceptual revolution. People would need to start thinking asset centric (with lifecycle behavior) instead of document centric with only revisions.

This kind of change requires a management vision, clear explanation of the benefits and a lot of attention for the user. Only then when these changes have been implemented, and data is available in a single repository, only then the fun and sexy environments become available for use.

Conclusion

PLM, CM and ALM are not sexy especially for the users who need to provide the data. But they provide the base for sexy applications where users have instant access to complete information to make the right decisions.  To get there a cultural change is required. The management needs to realize that the company changes into becoming proactive (avoiding errors) instead of being reactive  (trying to contain errors);  investing upfront and never be able to know what the losses would be in case an error occurred.

Not sexy, however the benefits this approach can bring allow employees and companies to continue to do their work for a secure future

 

And now … time to close as the final is near

spain_nl

%d bloggers like this: