You are currently browsing the category archive for the ‘PLM’ category.
In my previous post, BOM for Dummies related to Configure To Order, I promised to come back on the special relation between the items in the BOM and the CAD data. I noticed from several posts in PLM and PDM groups that also the importance of CAD data is perceived in a different manner, depending on the background of the people or the systems they are experienced with.
So I would like to start with some general statements based on these observations.
People who are talking about the importance of CAD data and product structures are usually coming from a background in PDM. In an environment where products are designed, the focus is around data creation, mostly CAD data. The language around parts in the BOM is mostly targeting design parts. So in a PDM environment CAD data is an important topic – therefore PDM people and companies will talk about CAD data and vaults as the center of information.
When you are working in a PLM environment, you need a way to communicate around a product, through its whole lifecycle, not only the design phase but also supporting manufacturing phases, the possible changes of an existing product through engineering changes, the traceability of as-built data and more. In a PLM environment, people have the physical part (often called the ERP part) in mind, when they talk about a part number.
As PLM covers product information across various departments and disciplines, the information carrier for product information cannot be the CAD data. The BOM, usually the mBOM, is the main structure used to represent and produce the product. Most parts in the mBOM have a relation to a CAD document (in many companies still the 2D drawing). Therefore PLM people and companies understanding PLM will talk about items and products and their lifecycle as their center of information.
CAD data in relation to Engineering to Order
The above generalizations have to be combined with the different main business processes. In a strict Engineering To Order environment, where you design and build a solution only once for a specific customer, there is no big benefit of going through an eBOM and mBOM transition.
During the design process the engineer already has manufacturing in mind, which will be reflected in the CAD structure they build – sometime hybrid representing both engineering and manufacturing items. In such an environment CAD data is leading to build a BOM structure.
And in cases where engineering is done in one single 3D CAD system, the company might use the PDM system from this vendor to manage their Bill of Materials. The advantage of this approach is that PDM is smoothly integrated with the design environment. However it restricts in a certain matter the future as we will see in further reading.
Not everyone needs the Engineering to Order process !
Moving to an integrated, multi-disciplinary engineering process or changing the main process from Engineering To Order to Built To Order / Configure To Order will cause major challenges in the company.
I have seen in the recent past, several companies that would like to change their way of working from a CAD centric Engineering To Order process towards a more Built to Order or Configure To Order process. The bottle neck of making this switch was every time that engineering people think in CAD structures and all knowledge is embedded in the CAD data. They now want to configure their products in the CAD system.
For Configure to Order you have to look at a different way to your CAD data:
Questions to ask yourself as a company are:
- When I configure my products around a CAD structure, what should I do with data from other disciplines (Electrical/Tooling/Supplier data) ?
- When I upgrade my 3D CAD system to a new version, do I need to convert all old CAD data to the newest versions in order to keep my configurations alive?
- When configuring a new customer solution, do I need to build my whole product in CAD in order to assure it is complete?
- In Configure to Order the engineering BOM and manufacturing BOM are different. Does this mean that when I go through a new customer order, all CAD data need to be handled, going through eBOM and mBOM transition again?
For me it is obvious that only in an Engineering to Order environment the CAD data are leading for order fulfillment. In all other typical processes, BTO (Built to Order), CTO (Configure to Order) and MTS (Make to Stock), product configuration and definition is done around items and the CAD data is important associated data for the product definition and manufacturing
In the case of order fulfillment in a Configure to Order process, the CAD structure is not touched as configuration of the product is available based on items. Each item in the mBOM has it relations to CAD data or other specifying information.
In the case of Built To Order, a huge part of the product is already configured, like in Configure To Order. Only new interfaces or functionality will go through a CAD design process. This new design might be released through a process with an eBOM to mBOM transition. In cases where the impact or the amount of data created in engineering is not huge, it is even possible to configure the changes immediately in an mBOM environment.
A second point, which is also under a lot of discussion in the field ( PLM interest groups), is that PDM is easily to introduce as a departmental solution. The engineering BOM is forwarded to manufacturing and there further (disconnected) processed. The step from PDM to PLM is always a business change.
When PDM vendors talk about ERP integration, they often mean the technical solution of connecting the two systems, not integrating the processes around the BOM (eBOM/mBOM transition) 0r an integrated engineering change (ECR/ECO). See how easy it is according to some PDM vendors:
or
PLM requires an adaptation of all departments to work different and together around a single product definition. Especially in a mid-market company, this is a big issue, as all product knowledge is stored in the CAD data and the knowledge how to produce the product is stored in the mBOM on the ERP side. These environments are often disconnected.
Conclusion: In the context of PDM the importance of CAD data is clear and for companies following a strict Engineering To Order process the main source of product knowledge. Companies following the Built To Order / Configure To Order process should configure their products around items to keep flexibility towards the future.
Companies with the intention to move to Built To Order or Configure To Order should not invest too much in CAD data configuration as it creates a roadblock for the future.
In my next post I will address the question that comes up from many directions, addressed by Jim Brown and others, as discussed in one of his recent posts around a PLM standard definition and more ….
Although I am still active most of my time in ‘classical’ PLM, some of the projects I am involved with also deal with Asset Lifecycle Management. In general PLM focuses on a product development process, starting from a conceptual phase, going through planning, development and production. The PLM system serves as a collaboration and information backbone for all product IP (Intellectual Property). One of the main capabilities a PLM system provides is a ‘single version of the truth’.
And it is this capability, which makes a PLM system an excellent choice for Asset Lifecycle Management
Who practices Asset Lifecycle Management ?
Asset Lifecycle Management can be found at any location, where a company is maintaining a process – we call these companies Owners/ Operators. Best known industry for Asset Lifecycle Management is the Process & Power industry, where a company produces oil, energy or chemicals. However the same concept is also valid for water companies (water distribution process), food processing and infrastructure companies (railways, airports, roads)
All these companies have in common that they support a certain process and the challenge is, while being in operation, to optimize the process. During operation, maintenance and improvement activities should be as little as disruptive as possible.
A maintenance stop is very costly for Owner/Operators. Imagine a plant not producing fuel for two weeks (millions of liters) or a nuclear reactor not producing electricity for a month (millions of kilowatts) – no income. And no maintenance will lead to unexpected problems and in the worse case, disasters. So it is also about balancing these activities.
Let’s look at a definition of Asset Lifecycle Management
Asset Lifecycle Management is a balanced and active management of assets over the lifecycle, coupled with business objectives.
Simply said it translates into an approach, where based on business objectives (process stability, safety, margin) a company tries to optimize the usage of their assets (a reactor, a pump, a rail track, a road) through their individual lifecycles. This means perform preventive maintenance; renovate a part of the process and perform more parallel activities with a focus on improving the lifecycle of the process
So why not use a MRO system?
An MRO (Maintenance, Repair & Overhaul) system can be compared with an ERP system for manufacturing companies. The MRO system manages and schedules activities and resources on the plant, keeping track of maintenance activities done on inventory. But can it serve as the system providing the single version of the truth for all plant information? No!
So why not use an ERP system?
An ERP system is mostly used by owner/operators to control all financial transactions (contracts, purchasing, suppliers, projects/resources accounting). Some ERP vendors provide MRO functionality in a single system; still can this system provide the single version of truth for all plant information? Again I am sure it is not the case.
So why not use a document management system?
As most of the process information is stored in various types of documents, is seems to be appropriate to store all information in a document management system. And actually this is what owner/operators try to do, however they maintain inside their company different document management systems (paper archives, office documents in a specific system, engineering documents in another system, etc, etc). Each of the systems can provide a single version of the truth for specific content, however there is a consolidated single entry point for all asset data. Often the documents also do not reflect the status of an asset. Is the asset running in, is it active, is it demolished?
The tag number does not show it, and changing the status of an asset forces people to go through the various document systems to change the status there. An inefficient and costly procedure, not reliable and often not done.
So why not an integrated plant engineering system?
Engineering plant software is designed to support the design collaboration and is mostly used by EPC contractors. These engineering companies are hired by the owner/operator to design and construct the plant or make major modifications of the plant. EPC contractors need to work as efficient as possible (to get the job), which means for them work as intelligent as possible in an integrated manner with tag numbers, P&IDs, 3D Equipment, Piping, ISOs. This intelligence leads to an application specific format and infrastructure.
During the hand-over of the plant or modification, this intelligence disappears as the owner/operator does not use the engineering plant software. They do not want to be dependent on a single software provider or version of the data. As data has to live for many years, sometimes 30 years or more, application specific data is hard to maintain. So as part of the hand-over data will be provided in neutral formats, worst case paper, but often in PDFs, TIFFs or other publishing format, losing all the intelligence.
There is an intelligent, neutral format based on ISO 15926. This requires an investment from the EPC contractor and an investment from the owner/operator to manage all information in this format. For complex and long-lasting environments, like a nuclear plant, this approach surely pays off; however what you see is that on both sides (EPC and Owner/Operator) they try to minimize the costs on data handling/conversion. This leads in the long term to much more labor time internal at the owner/operator to manage and assure the data is accurate. But these costs somehow come later and are more hidden. And the question remains: can this system serve as the single version of truth for all plant information? No, plant engineering systems are too application specific
In addition, plant engineering software environments are not targeted to work integrated in an owner/operator environment, managing parallel projects and resources, quality processes and inventory statuses related to a certain asset and project.
So why not use a project management software system?
As in a plant many projects can run in parallel, it happens that they run on the same assets or locations in the plant. For engineers and maintenance it is important to have visibility on which projects have impact on each other. Project management software is not targeted to make data visible related to a collection of assets or locations. No, project management software can not be the system to serve as the single version of truth for all plant information.
So either we give up for looking a single version of the truth and pay the price for multiple software systems to maintain in the company and take the extra efforts for configuration management for granted, or we look at PLM ?
The PLM based solution
In the past 15 years I have done several projects with ENOVIA and projects where Asset Lifecycle Management was done with ENOVIA. For sure, other flexible PLM systems can do the same, as the solution lies in an adapted data model for ALM.
This picture shows what a PLM system can do:
It can provide all related information (documents, inventory, locations, and projects) to an asset with one click from within single system. In addition it can also give the actual status of the asset. Assets are often identified by tag numbers, and the lifecycle of an asset can be managed by default in a PLM system, combined with Asset Change processes.
Best Practices coming from the PLM world can be used here too. The major challenge for PLM vendors is to reduce the complexity for data handling, as ALM users will not be engineers experienced to complex CAD environments. They are information workers, who need with a short learning curve, direct access to the data they require (and they should be sure the data is reliable)
Note: the PLM system will need to interface with the MRO and ERP system. Like in the classical PLM concept, MRO and ERP are the transactional systems, controlling the day to day activities, where the PLM system provides the accurate plant information (IP) required for an activity.
Also the PLM system will manage the non-standard activities through projects, change processes and will rely on accurate information from ERP.
The major benefits reported from implementations based on a PLM system are: 
- Reduced down-time for the plant, due to better planning and accurate information when preparing a maintenance stop. Less surprises with unforeseen delays of production.
- More reliable and less effort to be complaint to safety, health, environment and governmental regulations as all information is available in a single, controlled and traceable environment
- Lower cost of ownership for ALM. Instead of maintaining various silos of information and provide access to certain users, a single system with a common interface is available for most of the users.
Conclusion: Owner/Operators should look into the benefits a PLM system can bring for them. Interesting the benefits are not based on the integration of product development, but on providing accurate information from different entry points for different roles
I am curious to learn who has seen a similar approach – feel free to comment
This is the third post on Bill of Material handling for different types of companies, this time the focus on Configure To Order (CTO). In the CTO process, products are assembled and configured based on customer requirements. This means there is no more engineering needed when customer requirements are known. CTO examples are, the ordering process of a car with all its options, or ordering a personal computer over the internet.
So what has Configure To Order to do with PLM as there is no engineering?
The main PLM activity takes places when designing the configurable product. Designing a product that is configurable, requires a complete different approach as compared to Engineering to Order or Build to Order. Although we see a similar Configure to Order activity in the R&D departments of companies that follow the Build to Order process. They are also designing products or modules that can be used as-is in customer specific orders as part of the solution.
The challenge of CTO is to design products that are modular, and where options and variants are designed on a common platform with common interfaces. If you look to the dashboard of a car you will see placeholders for additional options (in case you have the minimal car version) and also you might see that for example the radio display in a basic car version differs from the complete board computer in the luxury version. The common platform is one dashboard, fitting to numerous options.
An engineering department will not focus on designing and defining each of the possible combinations of options as this would be impossible to manage. What can be managed is the common platform (the baseline) and all different options on top of this baseline.
So what happens with the BOM?
The initial design of configurable products goes through similar steps as the BTO process, which means starting from a conceptual BOM, moving to an Engineering BOM (eBOM) and finally produce a BOM for manufacturing (mBOM). The difference is that in the CTO process the mBOM is not developed for just one product, but contains all definitions for all possible products. In this situation we talk about a generic mBOM.
Only when a customer order exists, the generic mBOM is resolved into a specific mBOM for this customer order, which then can be sent to the ERP system for execution.
In a generic BOM the relations are managed by filters. These filters define the effectivity of the link, in simple words if the relation between two parts in the BOM is valid (and shown) or not. There are various ways to define effectivity – with again a differentiation in usage
- revision based effectivity – which means the relation between two items is valid in case the revisions match
- date effectivity – which means the relation is valid during a certain time interval
Both methods are used most of the time for non-configurable products. The revision and date effectivity are used to be able to track the product history through time and therefore to have full traceability. But this does not work if you want to configure every time a customer specific order.
In that case we use unit or option based filtering.
- unit effectivity – which means the relation between two items is valid for a unit (or a range of units) produced. For example a batch of products or a unique product with a serial number
- option effectivity – which means the relation between two items is valid in case a certain condition is valid. Which condition depends on the configuration rules for this option. Example of options are: color, version, country
It is clear that unit and option based filtering of a BOM can lead to a conceptual complex product definition which goes beyond the BOM for Dummies target. Below an illustration of the various filter concepts (oops the animated gif does not work – i will investigate):
The benefit of this filtering approach is that there is a minimum of redundancy of data to manage. This makes it a common practice in the aerospace and automotive industry. An example describing all the complexity can be found for example here, but I am sure on this level there are enough publications and studies available.
And what about the CAD ?
I will write a separate post on this topic, as all the possible interactions and use cases with CAD are a topic on its own. You can imagine, having the 3D virtual world combined with a configurable BOM brings a lot of benefits
What PLM functions are required to support Configure to Order ?
- Project management – not so much focus here as the delivery project for a customer does not require much customer interaction. Of course, the product development processes requires advanced capabilities which I will address later in a future post.
- Document management – same approach as for project management. The product related documentation needs to exist and secured. Customer specific documentation can be generated often automatically.
- Product Management – managing all released and available components for a solution, related to their Bill of Materials. Often part of product management is the classification of product families and its related modules
- Item management – The main activities here are in the mBOM area. Capabilities for BOM generation (eBOM/mBOM), baseline and compare using filtering (unit based / option based) in order to support the definition if the manufactured product
- Workflow processes – As we are dealing with standardized components in the BOM, the Engineering Change Request (ECR) and Engineering Change Order (ECO) processes will be the core for changes. And as we want to manage controlled manufacturing definition, the Manufacturer Change Order process and Standard Item Approval process are often implemented
Optional:
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery to understand and handle the complex platform
- Service Management – as an extension of item management. When a customer specific order has been delivered it might be still interesting for the company that delivered the product to keep traceability of the customer configuration for service options – managing the Service and As-Built BOM
- Product Configurator – the reason I write it as optional, is because the target is order execution, which is not a PLM role anymore. The ERP system should be able to resolve the full mBOM for an order. The PLM product configuration definition is done through Product and Item management. Depending on the customer environment the role of configurator might be found in PLM in case ERP does not have the adequate tools.
Conclusion:
It is hard to describe the Configure To Order process in the scope of BOM for Dummies. As various detailed concepts exist per industry there is no generic standard. This is often the area where the PLM system, the PLM users and implementers are challenged the most: to make it workable, understandable and maintainable
Next time some industry specific observations for a change
Continuing the posts on Bill of Material handling for different types of companies, this time the focus on BOM handling in a Build to Order process. When we are talking about Build to Order process, we mean that the company is delivering solutions for its customers, based on existing components or modules. A typical example is the food processing industry. In order to deliver a solution, a range of machinery (ingredient manipulation) and transporting systems are required. The engineering tasks are focused on integrating these existing components. In many cases new or adjusted components are required to complete the solution.
Research and Development in a BTO company
In a typical BTO company you see actually two processes.
- The main BTO process, fulfilling the needs for the customers based on existing components
- An R&D department, which explores new technologies and develops new components or modules, which will become available for selling to new customers.
This is the innovation engine of the company and often can be found in a complete isolated environment – extra security – no visibility for other departments till release. The task for this R&D department is to develop machinery or modules based on new, competitive technologies, which are rapidly configurable and can be used in various customer solutions. The more these machines or modules are configurable, the better the company can respond to demands from customers, assuming a generic machine and interfaces does not degrade performance, compared to optimal tuned machinery.
I will describe the BOM handling for this department in a future post, as also here you will see particular differences with the ETO and BTO BOM handling.
Back to the core of BTO
I found a nice picture from 2003 published by Dassault Systems describing the BTO process:
We see here the Bidding phase where a conceptual BOM is going to be defined for costing. Different from the ETO process, the bidding company will try to use as much as possible known components or technology. The reason is clear: it reduces the risk and uncertainties, which allow the bidding company to make a more accurate and competitive cost estimate for these parts. When a company becomes mature in this area, a product configurator can be used to quantify the estimated costs.
The result from the bidding phase is a conceptual BOM, where hopefully 60 % or more is already resolved. Now depending on the amount of reuse, the discussion comes up: Should modifications being initiated from the eBOM or from the mBOM?
In case of 60 % reuse, it is likely that engineering will start working around the eBOM and from there complete the mBOM. Depending on the type of solution, the company might decide to handle the remaining 40 % engineering work as project unique and treat it the same way as in an ETO process. This means no big focus on the mBOM as we are going to produce it only once.
I have worked with companies, which tried to analyze the 40 % customer specific engineering per order and from there worked towards more generic solutions for future orders. This would mean that a year later the same type of order would now be defined for perhaps 80 %. Many companies try to change themselves from a project centric company towards a product centric company, delivering configured products through projects.
Of course when solutions become 100 % configurable, we do not speak from BTO anymore, but from Configure to Order (CTO). No engineering is needed; all components and interfaces are designed to work together in certain conditions without further engineering. As an example, when you buy a car or you order a PC through the internet – it is done without sales engineering – it is clearly defined which options are available and in which relation.
See below:
However the higher the amount of reuse, the more important it becomes to work towards an mBOM, which we will than push the order to ERP.
And this is the area where most of the discussions are in a PLM implementation.
- Are we going to work based on the mBOM and handle all required engineering modifications from there?
Or
- Do we first work on a complete eBOM and once completed, we will complete the mBOM?
The reuse from existing components and modules (hardware) is one of the main characteristics of BTO. Compare this to ETO where the reuse of knowledge is the target no reuse of components.
The animation shows the high level process that I discussed in this post.
What PLM functions are required to support Build to Order ?
- Project management – the ability to handle data in the context of project. Depending on the type of industry extended with advanced security rules for project access
- Document management – where possible integrated with the authoring applications to avoid data be managed outside the PLM system and double data entry
- Product Management – managing all released and available components for a solution, related to their Bill of Materials. Often part of product management is the classification of product families and its related modules
- Item management – The main activities here are in the mBOM area. As items in a BTO environment are reused, it is important to provide relevant ERP information in the PLM environment. Relevant ERP information is mostly actual costs, usage information (when was it used for the last time) and availability parameters (throughput time / warehouse info).
As historically most of the mBOM handling is done in ERP, companies might not be aware of this need. However they will battle with the connection between the eBOM in PLM and the mBOM (see many of my previous posts).
As part of the BTO process is around engineering, an EBOM environment with connections to specifying documents is needed. This requires that the PLM system has eBOM/mBOM compare capabilities and an easy way to integrate engineering changes in an existing mBOM.
- Workflow processes – As we are dealing with standardized components in the BOM, the Engineering Change Request (ECR) and Engineering Change Order (ECO) processes will be the core for changes. In addition you will find a Bidding Process, a Release process for the customer order, Manufacturer Change Order process and a Standard Item Approval process.
Optional:
- A Sales Configurator allowing the sales engineering people to quickly build the first BOM for costing. Working with a Sales Configurator requires a mature product rationalization.
- Supplier Exchange data management – as many BTO companies work with partners and suppliers
- Service Management – as an extension of item management. Often in this industry the company who Builds the solutions provides maintenance services and for that reason requires another Bill of Material, the service BOM, containing all components needed when revising a part of the machine
- Issues Management – handling issues in the context of PLM gives a much better environment for a learning organization
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery
Conclusion (so far):
When you compare these PLM requirements with the previous post around ETO, you will discover a lot of similarities. The big difference however is HOW you use them. Here consultancy might be required as I do not believe that by having just functionality a company in the mid-market will have time to learn and understand the special tweaks for their business processes.
Next post more on configurable products
This time a few theoretical posts about BOM handling, how the BOM is used in different processes as Engineering To Order (ETO), Make To Order (MTO) and Build To Order (BTO) organizations and finally which PLM functions you would expect to support these best practices.
I noticed from various lectures I gave, from the search hits to my blog and from discussions in forums that there is a need for this theoretical base. I will try to stay away from too many academic terminologies, so let’s call it BOM for Dummies.
Note: All information is highly generalized to keep is simple. I am sure in most of the companies where the described processes take place more complexity exists.
What is a BOM?
A BOM, abbreviation for Bill of Materials, is a structured, often multi-level list of entities and sub-entities used to define a product
I keep the terminology vague as it all depends to who is your audience. In general when you speak with people in a company that does engineering and manufacturing, you have two major groups:
- The majority will talk about the manufacturing BOM (mBOM), which is a structure that contains the materials needed to manufacture a product in a certain order.
We will go more in depth into the mBOM later. - When you speak with the designers in a company they will talk about the eBOM, which is a structure that contains the components needed to define a product.
Both audiences will talk about ‘the BOM’ and ‘parts’ in the BOM, without specifying the context (engineering or manufacturing). So it is up to you to understand their context.
Beside these two major types of BOMs you will find some other types, like Conceptual BOM, Customer Specific BOM, Service BOM, Purchase BOM, Shipping BOM.
Each BOM is representing the same product only from a different usage point of view
The BOM in an Engineering To Order company
In an Engineering to Order company, a product is going to be developed based on requirements and specifications. These requirements lead to functions and systems to be implemented. For complex products companies are using systems engineering as a discipline, which is a very structured approach that guarantees the system you develop is matching all requirements and these requirements have been validated.
In less complex and less automated environments, you will see that the systems engineering is done in the head of the experienced engineers. Based on the requirements, they recognize solutions that have been done before and they build a first conceptual structure to describe the product. This is a conceptual BOM, often only a few levels deep, and this BOM is mainly used for costing and planning the work to be done.
A conceptual BOM could like this (open the picture in a separate window to see the animation)
Depending of the type of engineering company, they are looking for the reuse of functions or systems. The reuse of functions means that you manage your company’s Intellectual Property (IP) where the reuse of systems can be considered as the reuse of standard building blocks (modules) to build a product. The advantage of system reuse of course is the lower risk, as the system has been designed and built and tested before.
From the conceptual BOM different disciplines start to work and design the systems and their interfaces. This structure could be named the eBOM as it represents the engineering point of view from the product. In Engineering to Order companies there is a big variation on how to follow up after engineering. Some companies only specify how the product should be made, which materials to use and how to assemble them. The real manufacturing of the product is in that case done somewhere else, for example at the customer site. Other companies still do the full process from engineering and manufacturing.
As there is usually no reuse of the designed products, there is also no investment in standardizing items and optimizing the manufacturing of the product. The eBOM is entered in the ERP system and there further processed to manufacture the product. A best practice in this type of environments is the approach that the eBOM is not a 100 % pure the eBOM, also items and steps needed for manufacturing might be added by the engineers as it is their responsibility to specify everything for manufacturing without actually making the product.
This animation shows on high level the process that I described (open the link in a separate window to see the animation)
What PLM functions are required to support Engineering To Order
The following core functions apply to this process:
- Project management – the ability to handle data in the context of project. Depending on the type of industry extended with advanced security rules for project access
- Document management – where possible integrated with the authoring applications to avoid data be managed outside the PLM system and double data entry
- Classification of functions and/or systems in order to have an overview of existing IP (what have we done) and to promote reuse of it
- Item management – to support the eBOM and its related documentation. Also the items go through a lifecycle representing its maturity:
– The eBOM might be derived from the mechanical 3D CAD structure and further extended from there.
– For design reviews it would be useful to have the capability to create baselines of the eBOM including its specifying documents and have the option to compare baselines to analyze progress
– The completed eBOM would be transferred to the ERP system(s). In case of a loose ERP connection a generic XML export would be useful (or export to Excel as most companies do) - Workflow processes – to guarantee a repeatable, measurable throughput of information – both approval and change processes
Optional:
- Supplier Exchange data management – as many ETO companies work with partners and suppliers
- Issues Management – handling issues in the context of PLM gives a much better environment for a learning organization
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery
- A configurator allowing the sales engineering people to quickly build the first conceptual BOM based on know modules combined with engineering estimates. This is the base for a better controlled bidding / costing
Let me know if this kind of posts make sense for you …..
Next time we will look at the BOM in a Build To Order process
This strange title came to my mind when I made an overview of my PLM posts in this blog so far. As I am working in the PLM space already for many years, I noticed by reviewing the topics below, that progress in PLM is slow. Yes, technology changes every 5 years, business models can change due to that, but most of the underlying concepts haven’t changed much.
At the implementation level, especially in traditional manufacturing companies, you notice a slow progress, although closely related to PLM, I believe 3D CAD has become a common practice, which could be one of the drivers for further change towards more PLM.
And this brought me to the Echternach procession, which currently is a dancing procession, where the pilgrims dance slowly to the church ( 1 mile / 1.6 km – dancing from left to right). In the Netherlands, we learned in primary school, that in the past the pilgrims made three steps forward and then two steps backward, which became an expression for a slow forward moving process in our idiom.
And if you look back to the topics overview underneath the movie , you see PLM adaptation is a slow process in the mid-market, still a way to go – perhaps dancing like the pilgrims this year ?
PLM and ERP
PLM and ERP – the culture change , continued, conclusion
Connecting PLM and ERP , continued
PLM and change
PLM for the SMB – a process of culture change
Culture Change in a mid-sized company a management responsibility
The gap between mid-market companies and PLM – 15 year ?
What not to do in a bottom-up PLM implementation approach
Implementing PLM requires a vision
What if SMB as vision for PLM and PLM vendors do not understand it
Can Chaos become order through PLM
What have PLM and Capitalism in common ?
Some users do not like the single version of the truth
PLM concepts
Working file based in the supply chain – manager have two options (actually one)
Where does PLM start beyond document management ?
PLM and ROI
5 reasons not to implement PLM
2. PLM implementations take too long
3. We already have an ERP system
4. Isn’t PLM the same as CAD data management ?
To PLM or not to PLM – start measuring
Measuring the development phase
Free PLM software does not help companies
Where is my PLM Return On Investment
Who decides for PLM in a mid-market company ? continued academic conclusion
Like many people, the meditation of the dark Christmas days and the various 2009 reviews give you a push to look back and reflect. What happened and what did not happen in 2009?
And what might happen in 2010?
Here my thoughts related to:
ERP-related PLM vendors
Here I think mainly about Oracle and SAP. They have already identified PLM as an important component for a full enterprise solution. They are further pushing their one-shop-stop approach . Where Oracle’s offering is based on a set of acquired and to-be-integrated systems, SAP has been extending their offering by more focus on their own development.
If you are one of those companies that require PLM, and believe all software should come from one vendor (beside Microsoft), it is hard to decide.
As there might be real PLM knowledge in the Oracle organization as an effect of the acquisitions, but is it easily accessible for you? Is it reflected in the company’s strategy ?
With SAP I am even more in doubt; here you might find more people with ERP blood having learned the PLM talk. Maybe for that reason, I saw mostly Oracle as a PLM option in my environment and very few SAP opportunities for real PLM.
I assume in 2010 Oracle will push stronger and SAP try harder.
CAD-related PLM vendors
In this group you find as the major players PTC, Siemens and Dassault Systems. Autodesk could be there too, but they refuse to do PLM and remain focused around design collaboration. All these PLM vendors are striving to get the PLM message towards the mid-market. They have solutions for the enterprise, but to my feeling, most of the enterprises in the traditional well-know PLM markets, like Automotive and Aerospace, are in a kind of stand-still due to economical and upcoming environmental crisis.
It is sure business will not be as usual anymore, but where will the sustainable future go? Here I believe answers will come from innovation and small mid-market companies. The bigger enterprises need time to react so before we see new PLM activities in this area it will take time.
Therefore all PLM vendors move in directions outside engineering, like apparel, life sciences, and consumer packaged goods. These industries do not rely on the 3D CAD, but still can benefit from the key building blocks of PLM, like lifecycle management, program and portfolio management and quality/compliancy management. The challenge I believe for the PLM vendors is: Will these CAD-focused organizations be able to learn and adapt other industries fast enough? Where does 3D fit – although Dassault has a unique vision here.
For the mid-market, the PLM vendors offer more OOTB (Out Of The Box) solutions, mostly based on limited capabilities or more common available Microsoft components like SharePoint and SQL Server. This is not so strange as according to my observation, most smaller mid-market companies have not really made or understood the difference internally between document management and product data management, including Bill Of Materials not to be managed in Excel.
I assume 2010 the CAD related PLM vendors initially will focus on the bigger enterprises and new industries, the smaller mid-market companies require a different approach
PLM-only vendors
This is an area which I expect to disappear in the future, although this is also the area where interesting developments start to happen. We see open source PLM software coming up with Aras leading and we see companies coming up with PLM on-demand software, Arena as the first company to sell this concept.
The fact that the traditional PLM-only vendors disappeared in this area (Eigner bought by Agile, Agile bought by Oracle, MatrixOne bought by Dassault Systems) indicates that the classical way of selling PLM-only was not profitable enough.
Either PLM needs to be integrated in companywide business processes (which I believe), or there will be PLM-only vendors that find a business model to stay alive.
Here I hope to see more clarity in 2010
Smaller mid-market companies
What I have seen in the past year is, that despite the economical crisis, PLM investments by these companies remained active. Maybe not in purchasing much more licenses or implementing new PLM features. Main investments here were around optimizing or slightly extending the PLM base. Maybe because there was time to sit still and analyze what could be changed, or maybe it was planned but due to work pressure, it was never executed. Anyway there was a lot of activity in this area not less than in 2008.
An interesting challenge for these mid-market companies will be to remain attractive for the new generation. They are not used to the classical ways of structured work as most of the current workforce is used to.
Social networking, social PLM, I have seen the thoughts, discussions and benefits, still trying to see where it will become reality.
2010 is another chance.
Sustainability and going green
This is an area where I am a little disappointed and this is perhaps not justified. I would expect with the lessons learned around energy and the upcoming shortage of natural resources, companies would take the crisis as a reason to change.
To my observation most of the companies I have seen are still trying to continue as usual, hoping that the traditional growth will come back. The climate conference in Copenhagen also showed that, we as human beings, do not feel pressured enough to adapt, by nature we are optimists (or boiling frogs).
Still there are interesting developments – I assume in the next few years we will see innovation coming – probably first from smaller companies as they have the flexibility to react. During the European Customer Conference in Paris, I heard Bernard Charles talking about the concept of a Bill Of Energy (The energy needed to create, maintain and demolish a product) As PLM consultants we already have a hard time explaining to our customers the various views on a BOM, still I like the concept, as a Bill Of Energy makes products comparable.
2010 the acceptance of Bill Of Energy
Here I want to conclude my post for this year. Thank you all for reading and sharing your thoughts and comments with this community. My ultimate conclusion for 2009 is, that is was a good PLM year for the mid-market, better as expected but the changes are going slow. Too slow – we will see next year.
A short intermediate post to conclude this topic. In August 2009, I wrote a post, How PLM is NOKIA, where I expressed my astonishment that a company as big and as professional as NOKIA did not react on launching problems of the new NOKIA N97. As I knew NOKIA as a company, which has implemented the basics of PLM, I would anticipate more customer centric activities.
Apparently, and now we are four months later, it is clear that NOKIA brought a product on the market too early with several design errors. Probably to be competitive with the iPhone, it was launched too early to maintain market share.
All early purchasers of the N97 were promised that in October 2009, the major software fix would come and then the N97 would be working as promised. As an early adopter, you feel swindled as the statement is more or less telling you: “We released a beta product – you paid the premium price – and in October the official release will be available”
So in November 2009, the software fix came (V 2.0) and after installing this new version, minor problems were solved, still the GPS was malfunctioning and also the camera lens could be scratched by the cover. Instead of making a firm and honest statement to its customers, NOKIA decided to keep things silent. On their support forum there was a discussion around the malfunctioning GPS. At the end, before it was removed by NOKIA, it was almost 30 pages long full of posts.
It started with loyal users, who thought that they had done something wrong, guessing and helping others trying to optimize the GPS reception. No contribution from NOKIA people in that forum. Later (page 25 and later), the posts became more and more angry, as these people, who were trying to make it work, were sent from repair centre to repair centre without getting a fix. Many were trying to get a statement from NOKIA support people.
At the end, NOKIA removed the forum to hide all these issues to new potential customers. Now, if you search again for NOKIA N97 and GPS issue, you find a few pages of new people trying to make it work.
Anyway, two weeks ago I received my ‘repaired’ N97 and still the GPS failed despite the NOKIA claimed to have replaced some components. My telephone network provider, who sold the N97 together in a bundle, now proposed to replace the NOKIA N97 with a similar phone from another brand, which I will do.
Back to PLM, what is the relation with this post ?
PLM allows you to become more customer focused, using field experience as feedback and input for your new models. Also virtual testing – not sure if GPS reception can be virtually tested – can save huge costs due to product recalls and repairs. This is the situation NOKIA is suffering now around the N97. And as they do not publicly communicate that there are errors, it might reduce the amount of claims they get from all N97 buyers as not everyone uses all features. Soon a new model will come up and everyone forgot the stinker with the N97. People inexperienced with GPS might think the behavior they experience with the N97 is normal finding only a few pages of other people with problems instead of 30+ pages.
The back side of this approach for NOKIA is that modern, loyal customers are expecting a customer centric company and they will move to another brand, only to come back when this competitor fails. It is worth to lose loyal customers to avoid claims ?
For me the NOKIA book is closed, now I will move to Sony Ericsson , thanks to my mobile phone provider. And as I learned on the recent ECF (European Customer Forum) last month in Paris, Sony Ericsson is using PLM for their global design and production process, striving to a single version of the truth. So also Sony Ericsson is connecting people and I hope they have a better connection with their customers as people are allowed to make mistakes but hiding them is the biggest mistake.
Just closing with a funny movie. This NOKIA marketing movie shows a guy with a N97 easily finds his friend through GPS. For sure it works in the dessert where you can see each other for miles – but in a dense city, you have to realize your friend can be 200 meters on either side from you, although you think you are in the same location.
The title of this post came in my mind when looking back on some of the activities I was involved in, in the past two weeks. I was discussing with several customers their progress or status of the current PLM integration. One of the trends was, that despite the IT department did their best to provide a good infrastructure for project or product related information, the users always found a problem ,why they could not use the system.
I believe the biggest challenge for every organization implementing PDM and later PLM is, to get all users aligned to store their information in a central location and to share it with others. Only in this manner a company can achieve the goal of having a single version of the truth.
With single version of the truth I mean – if I look in the PLM system I find there all the needed data to explain me the exact status of a product or a project.
If it is not in the PLM system, it does not exist !
How many companies can make that statement ?
If your company does not have the single version of the truth implemented yet , you might be throwing away money and even bring your company at risk in the long term. Why ? Let’s look at some undisclosed examples I learned in the past few weeks:
- A company ordering 16 pumps which on arrival where not the correct ones –
1 M Euro lost - During installation at a drilling site the equipment did not fit and had many clashes – 20 M Dollar lost, due to rework and penalties
- 7000 K Euro lost due to a wrong calculation based on the wrong information
- A major bid lost due to high price estimation due to lack of communication between the estimator and the engineering department
- 500 K Euro penalty for delivering the wrong information (and too late)
All the above examples – and I am sure it is just a tip of what is happening around the world – were related to the power & process industry, where of course high-capital projects run and the losses might look small related to the size of the projects.
But what was the source of all this: Users
Although the companies were using a PLM system, in one company a user decided that some of the data should not be in the system, but should be in his drawer, to assure proper usage (according to his statement, as otherwise when the data is public available, people might misuse the data) – or was it false job security as at the end you loose your job by this behavior.
People should bring value in collaboration not in sitting on the knowledge.
Another frequently heard complaint is that users decide the PLM system is too complex for them and it takes too much time for them to enter data. And as engineers have not been bothered by any kind of strict data management, as ERP users are used to work with, their complaints are echoed to the PLM implementer. The PLM implementer can spend a lot of time to customize or adapt the system to the user’s needs.
But will it be enough ? It is always subjective and from my experience, the more you customize the higher the future risks. What about upgrades or changes in the process ?
And can we say NO to the next wish of this almighty user ?
Is the PLM system to blame ?
The PLM system is often seen as the enemy of the data creator, as it forces a user in a certain pattern. Excel is much easier to use, some home-made macros and the user feels everything is under control (as long as he is around).
Open Source PLM somehow seems to address this challenge, as it does not create the feeling, that PLM Vendors only make their money from complex, unneeded functionality. Everything is under own control for the customer, they decide if the system is good enough.
PLM On Demand has even a harder job to convince the unwilling user, therefore they also position themselves as easy to use, friend of the user and enemy of the software developer. But at the end it is all about users committing to share and therefore adapt themselves to changes.
So without making a qualification of the different types of PLM systems, for me it is clear that:
The first step all users in a company should realize is that, by working together towards a single version of the truth for all product or project related data, it brings huge benefits. Remember the money lost due to errors because another version of data existed somewhere. This is where the most ROI for PLM is reported
Next step is to realize, it is a change process and by being open minded towards change, either motivated or pushed by the management, the change will make everyone’s work more balanced – not in the first three months but in the longer term.
Conclusion: Creating the single version of the truth for project or product data is required in any modern organization, to remain competitive and profitable. Reaching this goal might not be as easy for every person or company but the awards are high when reaching this very basic goal.
At the end it is about human contribution – not what the computer says:
As a consultant working with mid-market companies, I enjoyed reading this post from Al Dean and its related comments and posts. Although I must say Al’s statement:
PLM+ are looking to solve this by creating a rich application that engages the user, provides ease of implementation and ongoing maintenance (by allowing the user/admin, rather than costly consultant) and can be delivered over the web, in an on-demand manner (which saves hardware and infrastructure cost)
was a trigger to react, as I am a consultant.
The base of every PDM/PLM
First I believe the base of PLM and PDM is to agree inside your company that you share and centralize product data. This means not only files, but also Bill of Materials, Issues, etc, etc, ..
To share and centralize product data seems like an easy mission and this is what all PLM software as a base provides, and I assume PLM+ does the same, only they store the data in the cloud, like Arena.
Sharing data is not a natural process in all companies as there is always the culture to share the minimum and to keep the rest to prove your own value – the bigger the company the more this will happen. This is human nature and this differs case by case. To make people share data is an area where either the management has to push, or in very small companies, a power user. In larger companies, often an external consultant is doing this job, in the role of an ‘outsider’ who can moderate and explain the benefits for all, instead of the threats.
This is what consultants really do; they do not install or administer systems.
PLM solutions can vary in the way they make sharing of data available. Some solutions are very rigid in what they offer as data model, but most of the necessary entities and attributes are there. They are based on best practices and target the 80 %. Often this is good enough, if the customer has no alternative and has the power by themselves to enforce the system as their platform for sharing data.
More flexible PLM solutions have an advantage and in the same time this is their disadvantage. They can be extended beyond the 80 % scenario and both the implementer and the customer will be challenged to reach the 100 % satisfaction. However we all know from the 80-20 rule, this is where it gets complicated.
80 % of the project is done in 20 % of the time, or in other words: you spent 80 % of your time (and budget) on reaching the last 20 %
Once having reached a common platform for sharing all product related information, for me the real PLM is starting. This is where a company would implement processes, that streamline the product development or delivery process – it requires a cross departmental change.
And at this stage, it is often where a consultant comes in. It is very rare, that in mid-market companies, management reserves time and resources to come with a strategic plan to implement PLM – I wrote about this in an older post. PLM requires a change in the way the company currently works.
So I am curious to learn how PLM+ and other On-Demand PLM software companies will try to address this step, as change is needed and someone has to push for it.
In my last three consecutive posts, I wrote about who decides on PLM in mid-market companies (a generalization from 15 years experience). There I claim that the selection for a PLM system is subjective, very much based on personal relations with the mid-market company. Again how PLM+ will address this in their business model, as there is a need for someone to push.
Open Source PLM software has somehow similar challenges. You need the drive from inside the customer to agree on sharing product data and next to extend. This is where the traditional PDM and PLM vendors push their business in direct contacts. Of course Open Source PLM providers have their focus on after the initial installation of the platform to extend it with a consultative and service model.
Conclusion: As every PLM provider at the end needs revenue for a living, I am looking forward to see where On-Demand PLM will go and finds it place. What will be business model that makes people buy and create the change
Jos Voskuil's Weblog 
[…] (The following post from PLM Green Global Alliance cofounder Jos Voskuil first appeared in his European PLM-focused blog HERE.) […]
[…] recent discussions in the PLM ecosystem, including PSC Transition Technologies (EcoPLM), CIMPA PLM services (LCA), and the Design for…
Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…
Jos, as usual, you've provided a buffet of "food for thought". Where do you see AI being trained by a…
Hi Jos. Thanks for getting back to posting! Is is an interesting and ongoing struggle, federation vs one vendor approach.…