You are currently browsing the category archive for the ‘ERP’ category.
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:
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 ….
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
Two weeks ago I was writing about the Silent PLM approach. What I showed in that post that often the PLM vision as a complete vision does not exist in all layers of the organization.
Often the management in is not aware of where and how PLM can have an impact. In the Silent Management approach, one or more visionary people believe they can introduce PLM by starting it in their department, and from there grow and extend the impact of PLM. As I concluded, this approach usually fails in most of the cases as when the decisive step comes to extend PLM to other departments and to change current processes, this is the point where is mostly gets stuck.
Other departments and the management do not see how this engineering / CAD extension could benefit for them and the whole organization. Why not extending our ERP system as this already exists ? And here a stand still will come up until a push comes. The push can come from the top or from the outside world. From my experience more then half of the companies that started this silent PLM approach got stuck where they are ……..
So this time another approach, called the academical approach. And again a disclaimer, I am generalizing and putting some points a little more in the extreme to demonstrate the difference between the approaches. Any similarity with the real world is pure coincidence
Approach 2: Academical PLM
Inside our mid-market company ACCPY, the management has understood that PLM will bring a lot of benefits and in case they were not aware of it, they have learned from analyst reports, from blogs and from their network that PLM should bring a lot benefit for them.
So the management decides to prepare and educate themselves and they start a PLM taskforce inside ACCPY to collect and digest all the information. The team has enthusiastic members from all departments and starts buying some books and reports on PLM. In addition they visit some PLM events all around the country and sometimes around the continent. These visits lead to contact with PLM Vendors who also start to educate why their PLM is the one fitting ACCPY the best. After one or two years of education they are theoretical skilled and know to differentiate between EDM, PDM, cPDM and even they learn to understand the difference between PDM and ERP.
As a conclusion of their learning stage the PLM taskforce presents to the management a firm report, explaining what is PLM and how ACCPY can benefit from it plus recommendations how to proceed.
The management is happy with the result, that what they thought two year ago was really valid and agrees with the report and recommendations. Now the selection of the PLM system needs to be done and who will be the implementation partner. Although all PLM vendors have been knocking on their door already to explain the benefits and implementation approach from their solution, ACCPY decides to hire an ‘independent’ PLM consultancy firm to assist with the selection of the solution.
The consultancy firm starts with interviewing the key members of ACCPY, in order to understand the major processes and the needs per department. A month later they present to the management a PLM Vendor Selection Procedure, where in 15 pages the PLM Vendor has to explain and confirm requirement per requirement, the implementation approach and give a budget estimate.
This RFQ will be sent to 5 PLM vendors which were already in touch with ACCPY since the PLM research started. Also the consultancy firm brought in a company which they new very well. It takes a few weeks for the consultancy firm to compile the RFQ and two months later the responses are there.
From the received proposals three PLM vendors are invited to benchmark their system and company based on a business case developed by the consultancy firm together ACCPY.
PLM Vendor 1
The first PLM vendor gives a standard demo of the system and explains that the business case is well known to them and therefore instead of showing it, they give a whole set of screenshots and references. The attendees had a good feeling with this vendor
PLM Vendor 2
The second PLM vendor tries to follow exactly the business case as defined. The attendees liked the fact that all was demonstrated so well, however the PLM system seems to be rather too complex and giving a lot of overhead to the engineers, according to their impression.
PLM Vendor 3
The third PLM vendor was already known to the company as they were also providing the 3D CAD system. In their presentation they explained how well they knew ACCPY already and that the business case was too artificial. They demonstrated some gadgets of their PLM system which none of the competing vendors could do, thanks to their tight integration with the CAD system. The attendees were impressed, however a few days later, they were asking themselves, why were those gadgets needed ? None of the other vendors talked about it and it was also not part of the RFQ.
So now it was time for the consultancy firm together with the task force to process all the information and to determine the final score. On product features they had a nice comparison – only hard to tell what was most important. On usage it was more difficult, as they got three different approaches during the benchmark, so the scores for this section was rather artificial. Also the financial part seemed to be hard to compare but at least it gave an indication.
As it is an academical approach, my post for this week ends here. We need to give the ACCPY task force together with the consultancy firm some time to build a justification for their choice and next week we will discover how this story ended. Meanwhile ask yourself:
- how much time has passed since the management decided PLM was good for their organization ?
- how independent is the consultancy firm ?
- did they consider open source PLM as a solution ?
- what was the ranking of the PLM vendors ?
- read the book Blink the power of thinking without thinking about intuition
Conclusion (so far): Academical PLM takes time and it would be unfair to explain it all in one post.
So next week the real conclusion.
This week I realized that, although I believe the benefits of PLM are more and more accepted in mid-market companies, the decision how to start and where to start with PLM is often not clear. I recognize several approaches which I will describe in this and some upcoming posts.
All persons in this post are fiction and in case you recognize these persons in your company, it is pure coincidence. Instead of talking about approaches,I was tempted to call it strategies, but when you read my observation you will realize the word strategy would not fit.
Approach 1: The silent PLM
Inside our company, often there is an engineer or an engineering manager, who got caught by the PxM virus. The PxM virus is a modern virus, which makes you a believer that PDM or PLM will bring your company a lot of benefits. Documents and proof points of the severe impact exist all around the world. However nobody has gotten infected so far in this company. Everyone is working the way they worked since many years and life is secure and predictable.
Now this infected engineer is getting exited and dreams about the introduction of PLM in his company and how he will become the hero of the company and gets a big promotion. Unfortunate for him in this kind of business there are no big bonuses to collect, so the honor of promotion is already a big achievement.
So the first thing this engineer does is chatting with his peers and friends to find out where PxM has been implemented successful and he studies some success stories which he learned from his network.
Now the challenge starts.
He goes to the management and shows a nice PowerPoint, explaining why the company needs PxM and what are the expected benefits, based on reference stories. The management has no real clue what he is talking about, but it looks promising and they allow him to select a PxM system for his department and to start a pilot.
The engineer already knows which PxM system to choose. The one, recommended by the friendly reseller, who sold them their 3D CAD system (which is a success) and worked hard with him to finalize the slides. As requested by the management he had to invite two other PxM vendors to make an objective selection and at the end an impressive comparison matrix is shown to the management why system A has been chosen.
Now the implementation starts and step 1 is very successful. The document management part around the CAD system goes smoothly and everyone in the engineering department starts to be happy.
Following this successful implementation there are two options:
- the engineer does not get promoted and the implementation ends. It will remain a silent document management implementation and the dream is put aside.
- the engineer gets promoted and continues to push his vision as now he has a broader audience to spread the PxM virus. We will follow this story line…….
The engineer gets promoted and continues to push his vision
This is the best that can happen and the engineer, who now became the head of engineering, starts to express his vision to his fellow managers, explaining the advantages of PLM. Notice, he is now talking about PLM as the scope has been extended beyond product data management, involving other disciplines in the organization.
And here the head of engineering discovers that his fellow managers are also infected by a virus. Not the PxM virus, but one of them has already for many years the ERP virus. And as the ERP virus addresses the operational and financial tasks in the organization, the management trusts him. The sales and marketing department seems to be infected by CRM, but currently they caught a social disease, which made them push for all kind of communities. The management either likes it (as their kids are also on Facebook) or dislikes it, because they believe work is a serious business and being on internet all day is considered gaming.
So the head of engineering realizes that he has some freedom within his department, but the other departments and the management have their own priorities. And PLM is not on their list. Together with the friendly CAD reseller, who meanwhile was promoted to be Senior PLM Consultant, they work on a perfect PLM environment within the engineering department and they believe their success will show off in the upcoming years.
And then the crisis came and the company had to cut budgets. To be continued in (hopefully) 1 or 2 years
Conclusion: The silent PLM approach has a huge chance to fail as there is no corporate vision and management push to get PLM implemented. PLM should be addressed top-down. As in many mid-market companies there was also no strategically partner, who could assist the management to build a vision and to set priorities.
Next week:
approach 2: Academical PLM
The past few weeks I have been busy in an area which I believe is crucial for understanding PLM. I had meetings, web meetings with prospects, with implementers and existing customers – of course all in the mid-market. And the generalized key question on the table was: “
Yes, we understand document management, and yes, CAD management is understandable to us, but why do you need to work with the BOM further down the product lifecycle, as this is ERP, isn’t it ?
I realized several topics play a role here:
- Mid-market companies usually do not think top-down in their approach. As an example: they will not look at their whole organization’s business processes and then try to map all the activities cross departments, cross suppliers, etc. Usually they are looking per department to optimize the way they are working.
Classical enterprise PLM implementations are designed to go top-down. Describe the as-is situation, describe the the to-be situation and then transform the company to meet the to-be situation. Decisions are pushed to the people in the company as the to-be situation seems to be clear. Many of the classical PLM implementers still believe in this approach – and the risk / challenge is always that the to-be situation was not well understood, or that at the time we reach the to-be situation the environment of the company has changed and another to-be is needed. - Mid-market companies understand a central storage for documents brings a lot of benefits. Most companies realize that all this departmental archives of documents and files create too much overhead and a higher quality risk. Finding the absolute right file for a certain product release might be a quest and of course each of the departments claims that their solution fits exactly their needs. This is what I believe the main driver behind the success of SharePoint. As Microsoft Office is used as a common document authoring tool among all departments, why not use the Office Document Management tool as our common backbone ? PLM and ERP vendors might say we also manage documents, but usually these documents are managed in a structured manner – related to revisions of a product or to a product order. Usually an infrastructure to manage unstructured documents does not exist in ERP systems.
- Mid-market companies do not understand the value of managing the BOM outside ERP. As I mentioned, everyone understands documents, but items seem to be the domain of an ERP system. Understandable as ERP was often the first IT-system implemented. As mid-market companies usually do not have a holistic view, items will remain to be managed there (“as we invested so much in the first implementation the management will say – no other source for items !!!”)
And here i believe is the crucial go-no/go point for a PLM implementation. Once the company starts to understand that the definition of items is not done in the ERP system, but is a result of the work done in the engineering department, only then the value of managing the BOM outside ERP become apparent. And here is the catch 22, we already manage our documents in environments without items (BOM’s) (SharePoint / CAD Documents management) – so no place for PLM ?
So what to do as a mid-market company ?
It is hard to understand the full picture (because of the above points), can you trust the selling PLM partner ?(we have been promised easy implementations in the past with other IT-systems too) and at the end you do not believe the value PLM can bring (as you cannot imagine and digest the impact of PLM to your company)
And just when thinking about this – three articles came to my attention as they all address this topic, somehow from a different perspective:
- An upcoming white paper written by TechClarity on ENOVIA SmarTeam Express solutions
- A blog post written by Jim Brown (TechClarity) on the TeamCenter Express solution
- A blog post written by Oleg Shilovitsky (PLMtwine): PLM action plan for dummies
The first two posts deal with a packaged approach for mid-market companies, allowing them to implement PLM faster and with a faster ROI. As Jim (and many others are stating – in an economical down turn you cannot focus on efficiency only (the ERP slogan). It is innovation – better and more customer oriented and attractive products – brings much higher revenue as compared to doing more of the same more efficient.
Oleg focuses on the steps to implement PLM and I agree with most of the statements there. It needs to be gradual and implementing the business processes comes as the last phase.
There is one difference I see in my approach compared to what Jim and Oleg are writing. Both believe that PLM brings value (and i support this statement 100 % based on experiences with customers I have worked).
However the missing point to be addressed is the lack of understanding (and often also trust) of companies talking with a PLM vendor and committing to PLM. I tried to explain these points in the above 3 statements. As long as those points are not addressed, each stepped approach will lead to the question: “When are we really going to do PLM instead of CAD Document management or enhanced ERP ? “
My experiences with guiding successful PLM implementations are the following:
- Start with basic document management and CAD data management. It aligns with the understanding of companies that a centralized and secure repository for documents brings ROI. This step introduces to the company that a company wide approach of data management brings value (and ROI). Some basic processes might be introduced here already- basic document approval as required by all quality systems.
- Once basic CAD and Document Management are introduced, the company will realize that it is missing ‘place holders’ to hook the information. If you work in a document management system only, the system implementer will say: Use projects to collect your product data and use folders to collect your item related data. A PLM vendor would say; Now you are ready to introduce Items in your system, as they are the logical place holders for information. Here PLM starts to be introduced.
- Once understood that the item is a needed place holder to manage development data, the understanding for managing items in a structure becomes clear. Here we introduce the EBOM and as Items also contain logistical data, this is the first point to start connecting PLM and ERP to work with a shared ‘place holder’ but with different focus on characteristics.
- Once the Engineering BOM is understood, the discussion starts around the MBOM. Who is responsible for defining how a product is manufactured ? PLM believes this is part of their duty, ERP vendors will say, we own the item historically ,so we manage the MBOM. As a 100 % PLM believer, I think it should be in PLM as it is not part of the execution but part of the product definition (See the post I wrote on this topic: Where is the MBOM).
At the end the defined MBOM can be pushed to ERP once required. - Once you are able to manage and centralize all data related to product development and definition, a company becomes ready to guarantee the quality and flow of the data, by implementing company wide engineering change and development processes. Much in line with Oleg’s PLM action plan.
I have supported implementations of the above approach in several mid-market companies and key success factors were:
- the company understanding PLM brings benefits but also understands it will take a time to realize this vision.
Management vision and support were always there. - a PLM system that allows you to start simple with centralizing documents and keeping things understandable but also allows you to scale up to a PDM system and finally supporting the whole PLM vision once accepted and understood .
Think Top-Down – Implement Bottom-Up - an implementer who understands that in the mid-market a push of concepts will bring rejections from the end-users, and where listening to the end-users only, it will result in an unguided system. The implementation partner needs to say No at the right time and to push for Yes when needed.
The implementer is 50 % of the success !
Conclusion: A management vision, a scalable PLM system and an experienced implementation partner are needed to bring the innovation to survive in the long term – document management and ERP alone will not bring this unique value. The phased approach allows a company with digestible steps to grow to their ‘to-be’ situation – as building trust and understanding is still required in the mid-market of PLM
See also: ENOVIA SmarTeam Express
I am writing this post as i come across this question on a regular base, and as a response on a recent post from Jim Brown. I addressed this topic already in previous posts in the past, for your convenience i have put all relevant links I considered at the bottom of this post.
I believe the question is hard to answers if asked this way. It all depends on where is your point of gravity. You can divide the PLM providers in different groups.
- PLM vendors with a focus pure on PLM – their major business is in providing the majority of the PLM related tasks, independent of a certain CAD or ERP package, but interfaces usually through a generic approach with these applications. Matrix One (now integrated in Dassault’s ENOVIA offering), Aras (Open Source), Arena (On-line) are examples of this type of PLM providers.
- PLM vendors coming from their CAD environment, initially manage their 3D CAD data and extending these capabilities to other authoring tools. ENOVIA VPLM and SmarTeam (main CAD system managed CATIA) are Dassault’s solutions, Siemens UGS (main CAD system managed NX) and PTC (main CAD system managed Pro/E) are examples of this type of providers
- ERP vendors who extended their offering with PLM functionality – either by developing PLM functionality themselves (SAP) or by acquisitions of PLM functionality (Oracle / BaaN)
- and there is still a vendor that does not do PLM, but calls it digital prototyping
As each of these PLM providers has their customers and market share – interesting to read is CIMDATA’s overview of the PLM market. What you see there is that it is hard for the independent PLM vendors to be ranked in the top 5. Also the biggest independent PLM vendor in the past, Matrix One, had a hard time to compete against the CAD or ERP based vendors. Why ??
I believe because the major reason lies in the fact that companies want to keep their IT-infrastructure as simple as possible. Buying a PLM system from the current major CAD vendor or from the current major ERP vendor keeps their situation manageable. Why deal with a third vendor that has to integrate with their CAD and ERP software ?
This would lead to a statement that there are only two type of major PLM providers: CAD based or ERP based. And here I am back to the initial question: Can ERP vendors provide PLM ?
Here I believe there is a major difference in the approach of PLM. Yes, both types of companies can provide PLM functionality but they offer it in a different way. It is like Ferrari and Volkswagen provide cars, but are they addressing the same audience ?
Some years ago I had a conversation with a SAP country manager about PLM. It was in the time that SAP did not recognize PLM yet as a business approach required in addition to ERP. He told me that SAP was managing all the company’s data and processes and that it was just a matter of time before also companies would recognize that engineers working with their CAD systems are nothing else but resources in the whole process. “Designers believe they are artists and cannot be managed but we will show them we can” . Here you see the focus is not on creating the environment for innovation or new products, but on managing existing processes as efficient in a certain way.
To generalize ERP vendors talk PLM but practice efficiency and neglect the fact that innovation and creativity are not manageable (sorry for the generalization but it make things more clear)
CAD based PLM vendors focus a lot on the product creation process. Supporting companies to design and develop new products, mainly in the virtual world. They do not try to manage the development process like a production process but work with mile stones to assure progress and managing quality and risk (NPI – new product introduction). Only when the product definition is mature and complete it will be handed over to ERP to produce the products where needed. Did you ever wonder why CAD based PLM vendors do not expand into ERP ?
And here lies the the difference I believe. If you choose for a CAD based PLM vendor, your company is focusing on innovation, creating new products, when you choose for an ERP based PLM system you will focus on efficiency and process management. Ask the ERP vendor to which level PLM is integrated in their company – is there a person responsible for PLM in the top management ? Technically you can integrate a full portfolio of products, but understanding and making PLM a part of the strategy is the decisive question for the future.
Conclusion
Yes, ERP vendors can provide PLM functionality and as a company you should decide where is your business focus.
If your focus on efficiency and not on innovation ERP providers can offer a total solution.
If your company focuses on new and better products, I believe that your focus should be on CAD based PLM vendors as they offer the best environment for innovation support and capturing design knowledge.
And be critical – as before you know the front falls off
PLM and ERP previous posts:
Last week I saw once more a post, where free PLM software was offered and combined with the open source aura it should be THE solution for companies that want to implement PLM during this economical downturn. I believe this is a big mistake and for the following reasons:
WYPIWYG (What You Pay Is What You Get)
I learned that the WYPIWYG rule usually applies in the software world. Free software is nice, but does not guarantee that in case some functionality is missing or corrupt, that it will be fixed. So in case a company wants to implement the free PLM software, what to do if you feel something important for your business is missing ? You can ask the software provider to implement it for you – but will this be done ? Probably only when it is easy to achieve it will be done, but no commitment as the software is for free.
To assure it can be done, the software vendor will say it is open source software, so it can be changed if you want it. But who is going to make the change ? The mid-market company that thought to have selected an economical solution is not an IT-company – so who to hire? The open source software development company ? And this is what their business model is based on – they have the expertise with their software, so probably they are the best to adapt the open source software – not for free of course – and they learn from that but the customer pays.
Conclusion: there is no such thing as a free lunch.
It does not mean that all open source software is bad. Linux has shown that for an operating system it makes sense. Operating systems are 100 % in the scope of IT. PLM is something different. PLM systems indeed need to provide an IT backbone to assure data collaboration and replication globally. However PLM is probably more focused on business process changes and NOT on IT.
PLM requires people with business skills and not software developers
From my experience, PLM projects fail in case there are no business knowledgeable people available. It did not only happen with free PLM software or open source software. Some years ago, ERP vendors started to provide free PLM software to their customers to keep PLM companies on a distance. Like free PLM software it looked nice business wise, the software is free when you buy their ERP system. But who is going to implement it ?
This free PLM software availability has changed in the past years for ERP vendors. Also ERP vendors see PLM as a growth market for their business, so they started also to invest in PLM, providing PLM consultancy and no longer for free PLM functionality. However in one of the projects I was involved, it is clear that PLM and ERP are complementary approaches. Interesting is that none of the PLM vendors focus on ERP, apparently ERP vendors believe they can master PLM. I won’t say it is impossible however I believe if there is no real PLM vision on the top level of an ERP company, you cannot expect the competitive focus to exist.
Are CAD vendors providing PLM ?
Some CAD vendors have an embedded data management solution to manage their own data. This is usually more a PDM system and often the word PDM (Product Data Management) is too much for that. These systems manage their own CAD data but have no foundation for a multi-discipline Engineering BOM. For me, this is the base for PDM, as most companies have several disciplines working with different tools all around the same product. So CAD data management for me is not a the base for PDM, so for sure not for PLM.
PLM vendors bring real PLM value !
For me it is clear having worked with different vendors in the past: an ERP vendor, several PDM and PLM vendors, it is clear for me in order to bring committed value to a customer, you need first of all people with PLM skills – the ones that can differentiate between business process adaptation and software development. In order to implement PLM successful companies need to change the way they were working (read many of my previous posts about this – in particular this one). Software developers tend not to take this approach, but they adapt or extend the software to support the old way of working.
Finally paying for PLM software guarantees that the development of this software has a continuation based on business drivers and best practices. A PLM software vendor has the drive to improve to stay in business, both by software capabilities but even more by providing industry best practices.
Therefor my conclusion is that free PLM software does not help mid-market companies.
Feel free to react as I believe it is an important topic in this market.
In the past year I shared with you my thoughts around PLM. Most of the post were based on discussions with customers, implementers, resellers and peers around the world. I learned a lot and will keep on learning I assume, as PLM has many aspects:
– the products, there are many products with the label PLM
– the concept, how do we interpret PLM per industry
– the customers, what do they want to achieve, without buzz-word
– the world, people and economic trends drive us sometime to irrational decisions
In this post I will give an overview from the 2008 posts, categorized by topic. I am looking forward to further suggestions in the comments if you are interested in more depth in certain areas. In parallel I will continue to share my experiences and provide an overview of best-practices and terminology experienced in the PLM space.
PLM concepts
Managing the MBOM is crucial for PLM
Is there a need for classification – and how should it be done ?
Is the PLM concept applicable for mid-market companies too ?
What will happen with PLM – looking towards 2050
PLM and ERP
PLM and ERP – the culture change, continued
Connecting PLM and ERP – part 1, part 2, part 3
PLM and ROI
Implementing PLM is too costly ?
Implementing PLM takes too long ?
Why implement PLM next to an ERP system ?
How is PLM different from CAD data management ?
Economical crisis creates the opportunity for change
Business Process Change
PLM in SMB requires a change in thinking
The management is responsible to initiate a change towards PLM
The change in automotive/aero supply chains to more advanced partners
How will mid-market companies pick-up the benefits from implementing PLM ?
Experiences
European Enovia Customer Conference (ECC)
PLM in Greece – does it exist ?
Is the concept for PLM mature enough ?
Don’t expect a bottom up PLM implementation to become successful
Conclusion
I would like to conclude with a quote from my favorite scientist, who taught us everything is relative, however:
“We can’t solve problems by using the same kind of thinking we used when we created them.”
Looking forward to your feedback, wishes in 2009 !
Jos Voskuil
Jos Voskuil's Weblog 
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM,…