You are currently browsing the category archive for the ‘ERP’ category.
In my series describing the best practices related to a (PLM) data model, I described the general principles, the need for products and parts, the relation between CAD documents and the EBOM, the topic of classification and now the sensitive relation between EBOM and MBOM.
First some statements to set the scene:
- The EBOM represents the engineering (design) view of a product, structured in a way that it represents the multidisciplinary view of the functional definition of the product. The EBOM combined with its related specification documents, models, drawings, annotations should give a 100 % clear definition of the product.
- The MBOM represents the manufacturing view of a product, structured in a way that represents the way the product is manufactured. This structure is most of the time not the same as the EBOM, due to the manufacturing process and purchasing of parts.
A (very) simplified picture illustrating the difference between an EBOM and a MBOM. If the Car was a diesel there would be also embedded software in both BOMs (currently hidden)
For many years, the ERP systems have claimed ownership of the MBOM for two reasons
- Historically the MBOM was the starting point for production. Where the engineering department often worked with a set of tools, the ERP system was the system where data was connected and used to have a manufacturing plan and real-time execution
- To accommodate a more advanced integration with PDM systems, ERP vendors began to offer an EBOM capability also in their system as PDM systems often worked around the EBOM.
These two approaches made it hard to implement “real” PLM where (BOM) data is flowing through an organization instead of stored in a single system.
By claiming ownership of the BOM by ERP, some problems came up:
- A disconnect between the iterative engineering domain and the execution driven ERP domain. The EBOM is under continuous change (unless you have a simple or the ultimate product) and these changes are all related to upstream information, specifications, requirements, engineering changes and design changes. An ERP system is not intended for handling iterative processes, therefore forcing the user to work in a complex environment or trying to fix the issue through heavy customization on the ERP side.
- Global manufacturing and outsourced manufacturing introduced a new challenge for ERP-centric implementations. This would require all manufacturing sites also the outsourced manufacturers the same capabilities to transfer an EBOM into a local MBOM. And how do you capitalize the IP from your products when information is handled in a dispersed environment?
The solution to this problem is to extend your PDM implementation towards a “real” PLM implementation providing the support for EBOM, MBOM, and potential plant specific MBOM. All in a single system / user-experience designed to manage change and to allow all users to work in a global collaborative way around the product. MBOM information then will then be pushed when needed to the (local) ERP system, managing the execution.
Note 1: Pushing the MBOM to ERP does not mean a one-time big bang. When manufacturing parts are defined and sourced, there will already be a part definition in the ERP system too, as logistical information must come from ERP. The final push to ERP is, therefore, more a release to ERP combined with execution information (when / related to which order).
In this scenario, the MBOM will be already in ERP containing engineering data complemented with manufacturing data. Therefore from the PLM side we talk more about sharing BOM information instead of owning. Certain disciplines have the responsibility for particular properties of the BOM, but no single ownership.
Note 2: The whole concept of EBOM and MBOM makes only sense if you have to deliver repetitive products. For a one-off product, more a project, the engineering process will have the manufacturing already in mind. No need for a transition between EBOM and MBOM, it would only slow down the delivery.
Now let´s look at some EBOM-MBOM specifics
EBOM phantom assemblies
When extracting an EBOM directly from a 3D CAD structure, there might be subassemblies in the EBOM due to a logical grouping of certain items. You do not want to see these phantom assemblies in the MBOM as they only complicate the structuring of the MBOM or lead to phantom activities. In an EBOM-MBOM transition these phantom assemblies should disappear and the underlying end items should be linked to the higher level.
In the EBOM, there might be materials like a rubber tube with a certain length, a strip with a certain length, etc. These materials cannot be purchased in these exact dimensions. Part of the EBOM to MBOM transition is to translate these EBOM items (specifying the exact material) into purchasable MBOM items combined with a fitting operation.
EBOM end-items (make)
For make end-items, there are usually approved manufacturers defined and it is desirable to have multiple manufacturers (certified through the AML) for make end-items, depending on cost, capacity and where the product needs to be manufactured. Therefore, a make end-item in the EBOM will not appear in a resolved MBOM.
EBOM end-items (buy)
For buy end-items, there is usually a combination of approved manufacturers (AML) combined with approved vendors (AVL). The approved manufacturers are defined by engineering, based on part specifications. Approved vendors are defined by manufacturing combined with purchasing based on the approved manufacturers and logistical or commercial conditions
Are EBOM items and MBOM items different?
There is a debate if EBOM items should/could appear in an MBOM or that EBOM items are only in the EBOM and connected to resolved items in the MBOM. Based on the previous descriptions of the various EBOM items, you can conclude that a resolved MBOM does not contain EBOM items anymore in case of multiple sourcing. Only when you have a single manufacturer for an EBOM item, the EBOM item could appear in the MBOM. Perhaps this is current in your company, but will this stay the same in the future?
It is up to your business process and type of product which direction you choose. Coming back to one-off products, here is does not make sense to have multiple manufacturers. In that case, you will see that the EBOM item behaves at the same time as an MBOM item.
What about part numbering?
Luckily I reached the 1000 words so let´s be short on this debate. In case you want an automated flow of information between PLM and ERP, it is important that shared data is connected through a unique identifier.
Automation does no need intelligent numbering. Therefore giving parts in the PLM system and the ERP system a unique, meaningless number you ensure guaranteed digital connectivity.
If you want to have additional attributes on the PLM or ERP side that describe the part with a number relevant for human identification on the engineering side or later at the manufacturing side (labeling), this all can be solved.
An interesting result of this approach is that a revision of a part is no longer visible on the ERP side (unless you insist). Each version of the MBOM parts is pointing to a unique version of an MBOM part in ERP, providing an error free sharing of data.
Life can be simple if you generalize and if there was no past, no legacy and no ownership of data thinking. The transition of EBOM to MBOM is the crucial point where the real PLM vision is applied. If there is no data sharing on MBOM level, there are two silos, the characteristic of the old linear past.
(See also: From a linear world to a circular and fast)
What do you think? Is more complexity needed?
I will be soon discussing these topics at the PDT2015 in Stockholm on October 13-14. Will you be there ?
And for Dutch/Belgium readers – October 8th in Bunnik:
Op 8 oktober ben ik op het BIM Open 2015 Congres in Bunnik waar ik de overeenkomsten tussen PLM en BIM zal bespreken en wat de constructie industrie kan leren van PLM
This time I would like to receive some feedback from my readers as I believe the topic I am discussing here might be similar to a PLM / ERP discussion – a discussion between religions. I have preached the past two years a more data-centric approach for PLM, instead of file management and related tot this data-centric approach, the concept of a PLM platform / Business Platform – CIMdata/ Innovation Platform – Gartner becomes clear.
What´s the issue?
As I wrote in my earlier post (random PLM future thoughts), I realized that talking about platforms is not that straight-forward when meeting companies with their history and terminology. Some claim they are already using a business platform, others have no clue what makes a platform different from a their current PLM implementation ? Therefore I will summarize the different approaches I have seen in my network and give a non-academic opinion as a base for discussion. Looking forward to your opinion.
The platform approach
My definition of a PLM platform:
- A central repository of data based on a core data model. Information is stored as data in a unique way
- On top of this repository, applications can run, using a subset of the overall data elements, proving dedicated functionality and user interface to a particular user / role
- Access to the platform is provided through web-technology. Storage could be on the cloud.
- External applications and data can be connected through an open (standardized?) API embedded or federated
- The PLM platform can be a collection of services and functionality coming from various vendors / suppliers – the app store concept
- The platform approach is THE DREAM for business, being flexible to combine and edit data in any desired context in dedicated apps / environments
In the PLM world, Dassault Systems with their 3DExperience approach is following this trend although here you might argue about the ease of use to add external apps to this platform – is it open ? Aras and Autodesk might also claim they have a PLM platform, where you might question the same and if the depth of the data model and the provided solutions on top of the data model are mature enough. Finally also SAP can be considered as a platform, but I would not name it a PLM platform at this moment in time. An important question for me would be: How can achieve openness of a PLM platform?
The PLM backbone approach
My definition of a PLM backbone:
- The core PLM functionality is provided by a single, proprietary PLM system
- Additional functionality that is not part of the core development (acquisitions) is connected to the backbone through proprietary interfaces
- External authoring tools are linked to the backbone through integrations or interfaces which could be developed by third parties
- External system can interface to the PLM backbone through open interfaces
- The PLM backbone is THE DREAM for engineering, as historically this was the domain where PLM started to be implemented
I would consider Siemens and PTC (see picture) the best examples of a PLM backbone approach with their PLM portfolio. Teamcenter and Windchill are both rich PLM systems further connected to several systems, covering the product lifecycle. I am not expert enough to state that the same conclusion is valid for Oracle´s Agile, where I believe the backbone is bigger than the PLM system. What do you think ? Will these PLM vendors also move to a platform approach? And what will be the platform?
The Service Bus approach
My understanding of the Service Bus (I am not an IT-expert):
- Service Bus has a standardized interface to request for data or to post data that needs to be stored in other systems
- The Service Bus approach reduces the amount of (custom) interfaces between systems by requiring standardized inputs and outputs per system
- Providing a user with information that is not entirely available in a single system, the service bus needs to acquire the data from other systems, which might not give a high-performance as expected by business people
- The Service Bus is the IT DREAM as it simplifies the complexity for IT to manage point-to-point solutions between systems and makes an upgrade strategy easier to support.
From a very high-level view, the service bus approach has some similarities to a platform. The service bus concept allows business to select the systems they like the most (provided they connect to the service bus) – Image property of IBM.com
The main difference would be the persistence of information, where is the real data stored? I came across the service bus approach more often in the past, where the target was most of the time to integrate the PDM functionality (PLM as an enterprise solution was never in scope here).
For the Service Bus approach, I am curious to learn its relevance for future PLM implementations as the challenge would be to provide any user in the company with the relevant information in context. Is the service bus going to be replaced by the platform? Who would be the major players here?
The Business Intelligence approach
This method I discovered in project-centric companies (Oil & Gas companies, EPCs, Construction companies) but strangely enough also at some manufacturing companies, where I would assume integration of systems would bring large benefits.
- Each type of information is managed only in one single system avoiding interfaces or duplication of data.
- Only where needed, data will be pushed from one system to other systems
- Business Intelligence applications extract information from the relevant system and present this in context to the user, giving him/her a better of understanding
- Business users will work have to work in multiple systems to complete their tasks
- The BI approach is the ULTIMATE IT DREAM as it simplifies their works dramatically and shuts down business demands.
I have seen an example where IT dictated that for document management we use product ABC (well-known Content Management system). Next for internal documents we use SharePoint. For CAD, we use product PQR as much as possible (heavily adapted) or AutoCAD 2D (to support the minimum). For ERP, the standard system is XYZ (a famous ERP system – you do not lose your job by selecting them) and of course everyone uses Excel as a common interface of information between people.
It was impossible in this company to have a business view on the solution landscape. As you can imagine, this company’s margins are not (yet) under pressure as their industry is very conservative.
What do you think?
Is the future for PLM in platforms? If Yes, what about openness? Who are the candidates to offer such a platform? Or will lack of industry standards and openness block wider adoption? If No, will there be a massive PLM system in the future, connected to other enterprise systems (ERP/CRM)? Or will PLM be implemented as a collection of smaller systems communicating through an enterprise service bus?
I am looking forward discussing the topic here and soon during the upcoming Product Innovation conference in Düsseldorf
Some 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
I 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.
From 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.
Meanwhile, 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.
PLM 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
So 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
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 !
Last year, I read Clayton Christensen’s book “The Innovator’s dilemma – When New Technologies Cause Great Firms to Fail “. I was intrigued how his theory also applies to PLM and wrote about it in a blog posts last year.
Recently, I attended an HBR Webinar “Innovating over the Horizon: How to Survive Disruption and Thrive” , which raises serious implications for PLM. As presented by Clayton Christensen and Max Wessel, both professors in the Harvard Business School, I foresaw numerous consequences demanding attention.
I’d like to highlight some observations for you:
- Disruptive innovation will hit any domain – so also the PLM domain
- You are less impacted if your products/services are targeting a job to be done
- ERP has a well defined job – so not much discussion there
- PLM does not have a clear job – so vulnerable for disruption
- Will PLM disappear?
The above diagram explains it all. Often products come into the market with a performance below customer expectations. The product will improve in time, and at a certain moment it will reach that expectation level. Through sustaining innovation, the company keeps improving their product(s) to attract more customers, and start delivering more than a single customer is asking for.
This is for sure the case in PLM. All the PLM vendors are now able to deliver a lot of functionality around global collaboration, covering the whole product lifecycle. Companies that implement PLM, just implement a fraction of these capabilities and still have additional demands. Still the known PLM vendors nearly always win when a company is searching for a new PLM solution.
Disruption comes from other technologies and products. In the beginning, they are not even considered by companies in that product space as a possible solution. As these products improve in time at a certain moment, they reach that level of functionality and performance, a potential customer can use these products to address their demands.
At this stage, the disrupters will nearly always win the battle. The reason is that they are more close to what the customer wants than the incumbents. Their product performance and price point are most likely to be more attractive than the incumbents´ portfolio.
Translating this to PLM it would mean: “Do not look for PLM systems as they already provide too much functionality, way above the line of customer desire”
As a PLM consultant, I need to provide some second thoughts to keep my job. There is much more behind Prof. Christensen’s theory, and I recommend before agreeing with what I write, read his books ! And although there is a horizontal time axis where the disruptive technology comes in, it does not indicate it will be this year or next year.
If you are aware that disruption can kill your business, how likely is it that it will happen in your business and when?
Professor Christensen makes two key points:
- Disruption will always happen, but this does not mean it is going to be fast and totally overtaking the old products. It might be a slower process as expected and incomplete. Here, I was thinking about disruptive cloud technology, which came in fast on the consumer level, but will it reach the business level too, in the same manner that it overrules the classical PLM platforms ? I am not sure about that (yet)
- If your company’s value is on delivering products, instead of delivering means to get the job done for your customer, you are extremely vulnerable for disruption.
As companies are looking to get their job done in the most efficient manner, they will switch at any time to new solutions that provide a better way to get the job done, often with a better performance and at a lower price point.
ERP has a well defined job
I realized that this is one of the big differences between PLM and ERP. Why is there such a discussion around the need for PLM and I do not catch the same messages from the ERP domain ? Maybe because I am a PLM consultant?
ERP has a clear mission: “To get the job done – deliver a product as efficient and fast as possible to the customer”. ERP is an execution system. Although ERP vendors as well are delivering more than their individual customers ask for, the job is more clear defined.
PLM does not have a clear job
For PLM, it becomes fuzzy. What is the job that PLM does ? Here, we get a lot of different answers. Have a look at these definitions from some vendors
CIMdata calls PLM “the most effective investment you can make to achieve product leadership.” AMR Research says “Companies committed to time to value in product innovation certainly cannot succeed without a sound PLM foundation.”
Product Lifecycle Management, or PLM, is a driver of successful product development, and a strategic contributor to business value across the enterprise. PLM helps product manufacturers manage complex, cross-functional processes, coordinating the efforts of distributed teams to consistently and efficiently create the best possible products
For companies of any size, Autodesk PLM 360 helps to streamline your business processes for more efficient product development, improved profitability, and higher product quality.
I also reviewed the websites from the other PLM vendors, and I can confirm: None of them is talking in a clear way which job needs to be done. All PLM solutions are around technology and products.
Companies want to get the job done
And here I come back to the webinar’s conclusion. If you want to secure your future as a company, you need to focus on the job to be done. And even better, focus on the experience to do the job and the best integration of these experiences in a total framework. See the slide below:
My interpretation is that PLM has not even reached level 1. Still many companies are struggling to understand the fundamental need(s) for PLM.
Interesting to see is that Dassault Systemes in their messaging and approach is already targeting level 2 – the experiences. If potential customers will embrace the experience approach without passing level 1, is something to observe.
Will PLM disappear ?
In my December 2008 blog post PLM in 2050 and recently in The Innovator’s dilemma and PLM, I wrote that I believe PLM as it is currently defined, will disappear. Perhaps made redundant by a collection of disruptive technologies. Main reason is that PLM does not do a single, clear job.
One of these disruptive candidates to my opinion is Kenesto. They deliver “social business enterprise software to empower teams” as stated on their website. Kenesto is not considered as a competitor of classic PLM, starting on a different trajectory. For sure there will be more disruptive candidates aiming at different pieces of the PLM scope.
What do you think:
- Does PLM have too many jobs ?
- Will PLM survive disruption ?
The brain has become popular in the Netherlands in the past two years. Brain scientists have been publishing books sharing their interpretations on various topics of human behavior and the brain. Common theme of all: The brain is influencing your perceptions, thoughts and decisions without you even being aware of it.
Some even go that far by claiming certain patterns in the brain can be a proof if you have a certain disorder. It can be for better or for worse.
“It was not me that committed this crime; it was my brain and more…”
Anyway this post will be full of quotes as I am not the brain expert, still giving the brain an important role (even in PLM)
“My brain? That´s my second favorite organ” – Woody Allen
It is good to be aware of the influence of the brain. I wrote about this several times in the past, when discussing PLM vendor / implementer selection or when even deciding for PLM. Many of my posts are related to the human side of justifying and implementing PLM.
As implementing PLM for me primary is a business change instead of a combination of IT-tools to implement, it might be clear that understanding the inhibitors for PLM change are important to me.
In the PLM communities, we still have a hard job to agree between each other what is the meaning of PLM and where it differs from ERP. See for example this post and in particular the comments on LinkedIn (if you are a member of this group): PLM is a business process, not a (software) tool
And why it is difficult for companies to implement PLM beside ERP (and not as an extension of ERP) – search for PLM and ERP and you find zillions of thoughts and answers (mine too).
The brain plays a major role in the Why PLM we have ERP battle (blame the brain). A week ago I read an older publication from Charles Roxburgh (published in May 2003 for McKinsey) called: Hidden flaws in strategy subtitle: Can insights from behavioral economics explain why good executives back bad strategies. You can read, hear and download the full article here if you are a registered user.
The article has been written long before the financial and global crises were on the agenda and Mr. Roxburgh describes 8 hidden flaws that influence our strategic decision making (and PLM is a strategy). I recommend all of you to read the full article, so the quotes I will be making below will be framed in the bigger picture as described by Mr. Roxburgh. Note all quotes below are from his publication.
Flaw 1: Overconfidence
We often make decisions with too much confidence and optimism as the brain makes us feel overconfident and over optimistic about our own capabilities.
Flaw 2: Mental accounting
Avoiding mental accounting traps should be easier if you adhere to a basic rule: that every pound (or dollar or euro) is worth exactly that, whatever the category. In this way, you will make sure that all investments are judged on consistent criteria and be wary of spending that has been reclassified. Be particularly skeptical of any investment labeled “strategic.”
Here I would relate to the difference in IT-spending and budget when you compare ERP and PLM. ERP spending is normal (or strategic) where PLM spending is not understood.
Flaw 3: The status quo bias
People would rather leave things as they are. One explanation for the status quo bias is aversion to loss—people are more concerned about the risk of loss than they are excited by the prospect of gain.
Another reason why adapting and implementing PLM in an organization is more difficult than for example just automating what we already do.
Flaw 4: Anchoring
Anchoring can be dangerous—particularly when it is a question of becoming anchored to the past
PLM has been anchored with being complex and expensive. Autodesk is trying to change the anchoring. Other PLM-like companies stop talking about PLM due to the anchoring and name what they do different: 3DExperience, Business Process Automation, …..
Flaw 5: The sunk-cost effect
A familiar problem with investments is called the sunk-cost effect, otherwise known as “throwing good money after bad.” When large projects overrun their schedules and budgets, the original economic case no longer holds, but companies still keep investing to complete them.
I have described several cases in the past anonymously; where companies kept on investing and customizing their ERP environment in order to achieve PLM goals. Although it never reached the level of acceptance and quality a PLM system could offer, stopping these projects was impossible.
Flaw 6: The herding instinct
This desire to conform to the behavior and opinions of others is a fundamental human trait and an accepted principle of psychology.
Warren Buffett put his finger on this flaw when he wrote, “Failing conventionally is the route to go; as a group, lemmings may have a rotten image, but no individual lemming has ever received bad press.”
A quote in a quote but so true. Innovative thinking, introducing PLM in a company requires a change. Who needs to be convinced? If you do not have consensus (which usually happens as PLM is vague) you battle against the other lemmings.
Flaw 7: Misestimating future hedonic states
Social scientists have shown that when people undergo major changes in circumstances, their lives typically are neither as bad nor as good as they had expected—another case of how bad we are at estimating. People adjust surprisingly quickly, and their level of pleasure (hedonic state) ends up, broadly, where it was before
A typical situation every PLM implementation faces: users complaining they cannot work as efficient anymore due to the new system and their work will be a mess if we continue like this. Implementers start to customize quickly and we are trapped. Let these people ‘suffer’ with the right guidance and motivation for some months (but this is sometimes not the business model the PLM implementer pushes as they need services as income)
Flaw 8: False consensus
People tend to overestimate the extent to which others share their views, beliefs, and experiences—the false-consensus effect. Research shows many causes, including these:
- confirmation bias, the tendency to seek out opinions and facts that support our own beliefs and hypotheses
- selective recall, the habit of remembering only facts and experiences that reinforce our assumptions
- biased evaluation, the quick acceptance of evidence that supports our hypotheses, while contradictory evidence is subjected to rigorous evaluation and almost certain rejection; we often, for example, impute hostile motives to critics or question their competence
- groupthink, the pressure to agree with others in team-based cultures
Although positioned as number 8 by Mr. Roxburgh, I would almost put it as the top when referring to PLM and PLM selection processes. So often a PLM decision has not been made in an objective manner and PLM selection paths are driven to come to the conclusion we already knew. (Or is this my confirmation bias too )
As scientists describe, and as Mr. Roxburgh describes (read the full article !!!) our strategic thinking is influenced by the brain and you should be aware of that. PLM is a business strategy and when rethinking your PLM strategy tomorrow, be prepared to avoid these flaws mentioned in this post today.
Two years ago I wrote a post called PLM in 2050 as the concluding post for 2008. Now two years later it is time to see what has changed my landscape during this period. Are we going to a predictable future or are new trends arising ?
These were the points I raised at that time:
1. “Data is not replicated any more – every piece of information that exists will have a Universal Unique ID, some people might call it the UUID. In 2020 this initiative became mature, thanks to the merger of some big PLM and ERP vendors, who brought this initiative to reality. This initiative reduced the exchange costs in supply chains dramatically and lead to bankruptcy for many companies providing translators and exchange software.”
I believe this trend is still happening only the big risk here is that it requires an open standard definition of this UUID. I am sure that before my retirement (see later below), there will be no global standard. There will be platform-vendor specific UUIDs and the challenge will be to operate in a heterogeneous platform-heterogeneous vendor environment. I feel less discussion on this topic in my environment, therefore the downward arrow.
2.”Companies store their data in ‘the cloud’ based on the previous concept. Only some old-fashioned companies still have their own data storage and exchange issues, as they are afraid someone will touch their data. Analysts compare this behavior with the situation in the year 1950, when people kept their money under a mattress, not trusting banks (and they were not always wrong)”
For sure this is the most important trend and I would rank it now as the number one trend for 2010. I just read an interesting article about Cloud Computing Predictions which addresses all dimensions of a cloud strategy and execution – very much worth reading.
What you see in that article and also around you, is that there is going to be a battle between legacy vendors, who will try to transform the cloud definition to a private cloud into a way it suits their platform, and the new cloud solution vendors which also require a platform and from there build and extend their services. It relates to one of the other trends I also mentioned in the 2008 post:
3. “Then with a shock, I noticed PLM did not longer exist. Companies were focusing on their core business processes. Systems/terms like PLM, ERP and CRM did not longer exist. Some older people still remembered the battle between those systems to own the data and the political discomfort this gave inside companies”
Combined with the new battle around the services platform it will be clear that in this approach dominant business systems, like CRM, ERP and PLM will no longer exist, as the focus will be to build business processes based on services and apps on a platform. Here I see PLM as the last hurdle to take. CRM already is understood by the market that it can be replaced by a cloud based solution, the first ERP attempts are already there too, but as PLM is a more, diverse and wide set of non-standardized functions, you will see that in this area the challenge to offer the required PLM capabilities will be the biggest. Another rising trend PLM vendors will move more towards the manufacturing execution, where ERP vendors will provide more PLM services.
The battle will be around, who owns the intellectual property of the company and where it is stored and managed.
4. “After 3D, a complete virtual world, based on holography, became the next step for product development and understanding of products. Thanks to the revolutionary quantum-3D technology, this concept could be even applied to life sciences. Before ordering a product, customers could first experience and describe their needs in a virtual environment”
This trend will also continue I believe and combined with different types of user-interfaces, mainly from the gaming world; the virtual reality will be the space where we do the most of our engineering work, shopping experience and entertainment. Big question will be, especially for the Matrix fans, will the real world stop to exist? So also here a growing trend – 3D television, 3D communication narrow the gap between the real and virtual world and understanding.
A trend I did not pick up at that time was the issue of social media and their influence on the existing business processes. At that time I wrote:
5. “As people were working so efficient, there was no need to work all week. There were community time slots, when everyone was active, but 50 per cent of the time, people had the time to recreate (to re-create or recreate was the question). Some older French and German designers remembered the days when they had only 10 weeks holiday per year, unimaginable nowadays.”
And I have to say I was completely wrong there. Thanks to social communities, I am spending now more time per day to jump from community to community, from blog post to blog post (I admire my colleagues who have time to produce blog posts). Meanwhile I try to follow all my Twitter and Facebook friends and meanwhile processing the messages coming from everywhere, without having time to really dig into a problem I want to solve.
So quickly I post a question in various forums to see if someone has the answer, as I have not time to solve it anymore – hopefully somewhere in the world there will be a person who has the answer or time. Where to position this new trend into the relation of PLM is still a question for me. Yes, collaboration becomes easier, less boundaries, but also less structure to store data. Intelligent search engines which also understand the context of the information become more and more important, as we cannot structure upfront all information as we did in the classical past.
Due to the economical crisis another trend came clear. There is no retirement money left for the older workforce that should retire in the next 20 years. So companies will have a new generation of people asking the questions and if the older workforce adapts the new social media capabillities, they can be the ones that provide the answers.
In 2050 I will just be retired at the age of 90, and according to statistics, I have still another 20 years to enjoy my bionic life.
I wish you all a happy and successful new year and that the good dreams may come true.
Keep innovation and sustainability on your agenda
In 2008 and 2009 several analysts predicted that the mid-market was now ready for PLM and that most of the PLM vendors were building a targeted offering for the mid-market. I was, and still am, a believer that mid-market companies will benefit from PLM in case ………… they implement it.
When you review my observations in my blog from the past two years, apparently this does not seem to happen. Therefore in the past months, I have been analyzing posts and discussions around the ‘old’ and ‘new’ PLM, I have been talking with representatives from various PLM and PDM vendors, and last but not least analyzed what was the implementation process of a PLM system in companies, where I could get these insights.
This all lead to this post, perhaps too big for a blog, too small for a report.
First the definitions
Before giving my opinion, first my definitions of PLM and mid-market (as everyone has their own definition):
PLM means for me the management of all product related data and processes, from the initial concept phase, through planning, development, production planning and after sales/service. When talking about PLM, I have always a circular process in mind. Experiences from products in the market are again inputs for new product development. Instead of a linear process where every department manages their own data, the challenge is that every discipline contributes and collaborates around the product data. This implies that a PLM implementation always requires a business change process for a customer
Mid-market companies are for those companies where there is no strategic layer available plus a minimized investment in IT-resources. This leads to organizations where most changes are happening inside departments and cross-departmental changes are hard to implement. The IT-department might be a facilitator here but usually IT people focus on architecture and infrastructure instead of business change. This implies that a PLM changed should come from external people.
And who are doing PLM?
On the enterprise level, there is a battle between the big three (Dassault Systems, Siemens and PTC) and they are challenged mostly by the two big ERP vendors (SAP and Oracle) and on the PLM front by Aras, competing through its Open Source model. Of course there are many other vendors. These observations come from the area where I am active.
There are various ways to group these PLM vendors; one is from the CAD engine point of view: DS-CATIA / Siemens-NX / PTC-Pro/E. Although all claim to support a multi-CAD environment, the main focus in these companies is around the PLM integration with their primary CAD engine.
Where in the past, CAD independent PDM systems existed (Metaphase, MatrixOne), they could only survive in the major PLM industries by being integrated with CAD tools and were acquired for that reason. It will be interesting to see if Aras can play a major role in the PLM only domain, where others failed in the past due to lack of integration capabilities.
SAP and Oracle took a different path; they have understood that PLM cannot be neglected in an enterprise, so they need to address it. SAP did this by developing a PLM module as a logical extension on their infrastructure. Oracle has chosen to add PLM to their portfolio by the acquisition of two different PLM vendors. Where SAP does not have the challenge to explain to customers a full integrated story, Oracle has to spend more time on marketing to make it look like a single platform, which will come in the future. Big question however for both companies: do they really understand PLM? Is it in their veins and core strategy or does it remain an extension to gain market share, especially as you have no connections to the design world? (Try to find PLM on their corporate website).
Interesting to see how Aras will evolve. In their business model, the initial purchase of software is not needed, but once working with Aras you pay also for maintenance like with other PLM vendors. Their advantage is that switching from an existing legacy PLM vendor is less painful, as there are no initial software costs, which can be huge for an enterprise. I believe they have a good chance to succeed in industries where there is less a dependency on the CAD engine.So on the enterprise level the need for PLM is justified. Resources exist and are budgeted both at the customer level as at the supplier level. The PLM suppliers are either the PLM vendors themselves with service teams, or big, global service providers specialized in implementing the PLM software. They can do strategic PLM projects and support the required business change.
So why does it look like a mission impossible in the mid-market ?
The big enterprise vendors (PLM/ERP) believe that you can just strip down your enterprise software in a kind of prepackaged mode – PLM Out of the Box is a common heard expression. Also the analysts praise in their reports the mid-market approach from some of these vendors.
But do they really address the mid-market or only the high-end mid-market? Again it is all about the definition of where is the mid-market and in this post I stay with my definition of mid-market.
There are two main characteristics for this mid-market:
- Sales and implementation of software is done through Value Added Resellers and not through the vendors or big service companies. The software revenue per customer does not justify high expenses for global consultants with additional high expenses due to travel costs (and sometimes the local language issue). The local VAR is supposed to be the point of contact.
- Mid-market companies do not change their main company processes. Depending on the type of core process, let’s assume ETO or BTO, they have sales and engineering working close together on product/solution definition and they have manufacturing planning and production working close together on product/solution delivery. In term of functionality a PDM focus for sales/engineering and an ERP focus for manufacturing.
A mid-market company can be characterized as a two pillar company :
Who are successful in the mid-market ?
There are two software vendors, touching our PLM prospects , that really understand the mid-market, Autodesk and Microsoft.
Autodesk has a huge range of products and when we focus on the area of manufacturing, Autodesk does not talk about PLM. And I believe for several reasons.
Autodesk has never been a front-runner in making new technology and concepts available for the mainstream. They are more a company providing functionality for mainstream concepts, as compared to a company pushing new concepts and technology for premium pricing.
And this is what their customers like, as they also do not have internal strategic resources to push the company to new directions and surely no one wants to take the risk.
Thus risk avoidance and understandable concepts are key targets for mid-market companies.
Autodesk tries to avoid reaching beyond their engineering domain, the maximum they cover is presented in their Digital Prototyping solution. With their Vault product range they stay close to PDM, but do not go into the concepts of PLM, like mBOM handling. PLM is not established enough in the mid-market, so a no-go area for Autodesk.
Microsoft addresses the mid-market more from the IT-infrastructure. Slowly SharePoint has reached a certain status of an infrastructure component for content management – so why not for all the engineering data? SharePoint is the most relevant component related to PDM or PLM in my review and what I observed here is that the IT-manager often is the person who supports and enables a cross-departmental implementation of SharePoint. So not pushed from a strategic business level but from a strategic IT architecture approach.
PLM providers and implementers jumped on this opening in the mid-market by providing PLM capabilities on top of SharePoint. This to get their software used in the mid-market. It does not mean they do PLM, it means they expand the visibility of engineering data across the organization. Microsoft apparently does not want to enter the area of managing CAD or engineering data. You see mainly investments in the Microsoft Dynamics software, where ERP and CRM are targeted. Again PLM is not established enough in the mid-market to provide common functionality, so a no-go area for Microsoft.
And the impact of a indirect sales channel….
VARs are the next challenge for PLM in the mid-market. The PLM Vendors, who work with VARs, expect that these VARs are an extension of their sales organization. And sales means here selling software . PLM means however also selling services and I learned in the hard way in my past that companies selling products and services within the same group of people are constant in internal conflict how to balance software and service budgets
Selling and implementing PLM software is also difficult in mid-market companies as these companies buy software because they want to solve a pain in one of their departments. It is not common that they have a holistic approach. So VARs trying to sell PLM are engineering centric – often with their roots in CAD Selling. And as their nature comes from product selling, they feel comfortable in selling data management and PDM as this remains close to product features easy to justify. PLM requires different people, who can guide a business change across departments at the customer.
It is very rare for VARs to have these skilled people in place due to lack of scale. You need to act local to be cost efficient and close to your customer. As a VAR has only visibility of a limited group of implementations, the consultancy practices often are not based on global experience and best practices, but defined on their own best practices, sometimes bring their ‘magic’ to be even more different than required, to differentiate from other VARs.
The companies implementing PLM for enterprises can afford to share global knowledge; VARs need to build up the knowledge locally, which leads to an extreme dependency on the person who is available. And to be affordable on the payroll a VAR, the consultant often is an experienced application engineer, who knows to satisfy his customer by providing services on top of the product.
And as PLM is not established enough in the mid-market, they will not invest and push for PLM which requires a long term experience build-up, so almost a no-go area for VARs
So no PLM in the mid-market?
I believe real PLM in my mid-market will be a rarity, based on a lucky coincidence of the right people, the right company and the right product at a certain time. It will not become a main stream solution in the mid-market as there is the design world and the ERP world.
PLM SaaS (Software As A Service) delivered by Arena or PLMplus will not bring the solution either for the mid-market. You might remove the IT complexity, but you are missing the resources (internal and external) for business change – who will be there to initiate and guide the change . PLM SaaS probably will be implemented as a PDM environment.
I give more credits for Social PLM (Facebook alike collaboration, Google Wave). This approach might bypass the classical way of working in companies and lead to new concepts, which probably will not be tagged PLM – will the new trigram be SPC (Social Product Collaboration) ?
Still it will not happen fast I believe. It requires a change of the management in mid-market companies. Most of the managers are representative of the older generation, not wanting to take the risk to jump on a new hype they haven’t made themselves familiar yet
Conclusion: PLM in the mid-market seems like a mission impossible and although PLM concepts are valuable for the mid-market as analysts report, the typical mid-market characteristics block PLM to become a common practice there.
I am looking forward to learn from your comments
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:
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 ….
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.
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?
- 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.
- 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
- 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