22112007178In 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 ?

Too busy to implement PLM ?

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 !

8years

Jos Voskuil

sleep As the year ends, I decided to take my crystal ball to see what would happen with PLM in the future.  It felt like a virtual experience and this is what I saw:

 

 

  • 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 bankcrupcy for many companies providing translators and exchange software.
  • 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)
  • 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
  • Finally the cumbersome keyboard and mouse were replaced by voice and eye-recognition. Initially voice recognition and eye tracking were cumbersome. Information was captured by talking to the system and capturing eye-movement when analyzing holograms. This made the life of engineers so much easier, as while researching and talking, their knowledge was stored and tagged for reuse. No need for designers to send old-fashioned emails or type their design decisions for future reuse
  • Due to the hologram technology the world became greener. People did not need to travel around the world and the standard became virtual meetings with global teams(airlines discontinued business class). Even holidays could be experienced in the virtual world thanks to a Dutch initiative based on the experience with coffee. The whole IT infrastructure was powered by efficient solar energy, reducing the amount of carbon dioxide drastically
  • 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
  • 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.

As we still have more than 40 years to reach this future, I wish you all a successful and excellent 2009.

I am looking forward to be part of the green future next year.

This post is a reply on a post from YML, with whom I have been working in the past. At that time we had interesting discussions on various topics around PLM and I am happy to continue this discussion in blog space. Please read his post in order to understand the full reasoning below.

myplmFirst I want to make a statement to avoid misconception. I am a PLM evangelist and perhaps my definition of PLM is wider than what PLM vendors currently offer. For me PLM focuses not only on storing and managing the product data (PDM), but also on the whole process of how new products or improved products are created, designed, produced and supported.
From the Dassault Systemes and Autodesk (read Jim Brown’s comments on them) perspective, there is a lot of focus on the collaboration around the virtual product, however for me personally, when working with mid-market customers, I am mainly focusing on capturing design knowledge and IP plus creating visibility of knowledge inside a company, without being dependent on knowledge stored in people brains.

Interesting development in that area I am observing recently is in www.vuuch.com. An initiative to empower design discussions.

Now back to the reply on YML’s post:

So when Yann writes:

However I disagree with the statement that you use as foundation : Software vendor are proposing excellent product with a good ROI and SMB customer don’t understand it because they do not have a vision.

I must say: read my statement above – there is still work to be done. When I am talking about the lack of vision in the mid-market companies, I will provide an update based on some experiences I had the past few weeks, where lack of vision is blocking process improvements.

Next Yann is mentioning all the propriety formats of all vendors, PLM vendors, vendors of authoring tools (CAD, Content,…) and even limited version support. Yann makes a point for open-source solutions, which are part of the WEB 2.0 evolution. Interesting to see that at the same time Kurt Chen writes an interesting post on What Can PLM Offer for SMBs? in the same context.

My main comment on this topic is that I understand the beauty of open source, however I also believe that if you want to work with open source solutions, you need to have a 100 % clear concept of what the product should do (that is why Linux is successful – I believe PLM is not there yet) or you need companies that have strong IT-knowledge/support to adapt the software to their needs.However, this contradicts the fact that mid-market companies usually do not have these resources to invest in this kind of activity. So what would they do ? Hire consultancy firms or software companies (sometimes the original developer of the open source software) to adapt the software to their needs. This creates almost the same dependency as what customers would have with traditional PLM vendors – they rely on their software provider as the resource to drive PLM.

Then the question comes up:

Who would I trust to assist my mid-market company to evolve towards PLM ?

A company developing software or a company that has experience in my industry and perhaps does not deliver the best in class product (yet).I have met a company that decided to discontinue PLM software as the provider only brought programmers into the game, they tried to solve requests from the users and at the end – after 1.5 year of programming the system became so complex but crucial details were missing. An industry knowledgeable person with PLM knowledge would approach it different – first focusing on the process and then analyze where automation would bring benefits.Also Yann mentions:

It is interesting to note that nobody is blaming Ford, GM, … of not being able to see that they have good chance to go bankrupt in some month from now. It is interesting that many people blame now these companies of not being able re-invent/adapt their products to their market. when all of them where using PLM systems and had huge PLM projects on going

and additional:

In order to develop this agility SMB need to put very high in the list of capabilities for their information system the following features : Agility, re-configuration, continuous evolution / transformation, openness, ease of integration with unknown system, overall strategy of the PLM vendor

Here I disagree with the first quote. Ford and GM have no PLM implementations, they built a dinosaur type of implementation with focus on product development – yes provided by PLM vendors, but so rigid implemented that they lost the capabilities to be connected to the market.And I fully agree with the second quote – nothing to add. PLM should be implemented in such a way that it does not restrict a company in its flexibility – as innovation does not come from doing a process more efficient – it comes from doing things different 

So to conclude for today:

  • Yes, current PLM vendors are not perfect and there is a challenge to reach the mid-market
  • Open Source solutions make only sense if combined with industry knowledge
  • Agility, re-configuration, continuous evolution / transformation, openness, ease of integration with unknown systems should be the overall strategy of the PLM vendor (not only mid-market)

Thanks Yann, and enjoy your fishing, take notice of what could happen:

observation The past few weeks a had various moments to interrogate myself about the values for PLM and what would be the best way to address PLM for a mid-market company.

First I was in Copenhagen, attending the Microsoft Convergence event. A meeting where Dynamic customers, resellers and partners from all around Europe came together to learn the latest from Microsoft, to network with other partners and discuss their business processes.

Of course the focus from all of the 4000 attendees was around logistical processes, I was very curious to learn how manufacturing companies would describe their needs and where they feel the missing link – PLM.

But they did not feel it ……….

I believe this is one of the most challenging issues for mid-market companies. They have been investing in their ERP system and consider this as the company’s backbone. Their production and finance is dependent on it. Other departments, like sales and engineering provide somehow their inputs to the system, often Excel is here the information carrier. No PLM vision exist – or in case it exists – it is perfectly hidden.

I touched this topic in one of my previous post, called:  “We do not need PLM, we already have ERP”

So why is PLM not yet adopted by mid-market companies and I raise this question mainly for those companies that obvious would benefit from PLM ?

I believe the major reason is the fact that often in mid-market companies there is no high-level strategy available analyzing where the company should be in 5 years from now and what are the challenges to overcome. Most of the companies I am currently working with want to implement something they call PLM, but often it is just PDM.

The big difference between PLM and PDM is that PLM requires the company to work different across departments, where PDM is considered more as an automated way to centralize product data, without changing the department responsibilities.

And now some generalizations

shout_left In addition mid-market CAD resellers try to explain their customers that PLM is only for big enterprises and that they just need PDM. This of course makes their sales beyond CAD easier, as touching cross-departmental processes requires different knowledge (which their resellers do not have), a different product (which they do not sell) and of course a longer sales cycle.

shout_right The same happens from the ERP side. ERP resellers consider what happens in the engineering department as a black box, where product data is generated and at the end a (configurable) Bill Of Materials. ERP vendors do not jump on PLM as extending the process to engineering requires different knowledge (which is not their domain) , a more extended product (which they do not have (yet))

Mid-market companies are of course influenced by these resellers of their core components and as mentioned before do not have the time and budget to take a strategic, holistic view where the company should be in 5 years. Usually their focus is on solving the pains they experience in their organization. For example we have too many databases and spreadsheets per department, let’s put them all in one central place – more an IT focus then a business focus.

So how to get the vision ?

Companies should ask themselves the following questions:

  • what is the success of my company ?
  • will I still be successful in 5 years from now if I keep on doing the same ?
  • how does globalization affect me ? Risks but also challenges.
  • how do I capture the knowledge of my (experienced) workforce before they retire ?

To answer these questions (and the above ones are only the most probing) it requires time and understanding to build a vision. Perhaps the economical downturn creates the opportunity or need to prepare for the future (survival).

And if you are working in a mid-market manufacturing company, chances are big that implementing PLM is a way to guarantee the company’s future and success. This has been proven in big enterprises and mid-market companies are not so different at the end.

Adapting business processes and connecting the whole product lifecycle are key activities. Beyond PDM and ERP it brings portfolio management (which product bring the real revenue) and innovation (New Product Introduction – how do we make sure we introduce a good product in the market).

Conclusion

listen PLM requires a company vision and strategy. Building the vision is something that PLM vendors, business consultants and others can assist you with. Each group has its own pro’s and con’s but at the end it is the vision that is needed before making the change – it requires first of all an investment in brain power – not in products

Interesting to read:

Stay with the business processes or change them ?

The gap between PLM and Mid-market companies

NPI and PLM

Economic Downturn – an option for success ?

This time a more theoretical post about classification in PLM. A topic that always has been around for more than a decade. Recently classification also came up in some discussions both with customers and on discussion groups on the Internet. So what I will try to do in this post, is to explain the goals of classification, the ways classification is implemented and finally how I see classification will evolve. As always feel free to comment or extend my post.

The goals

Classification is a generic understanding, so to start I want to narrow classification to item classification. Companies might use classification in various ways, for products, for knowledge, for supported functions and more. The most discussed topic in the context of PLM however is item classification. The idea of item classification is twofold: understand what you already have (designed) and promote reuse. Historically the item definition has been stored in the ERP system and reuse was mainly based on recognizing parts of the description. Sometimes the ERP system also supported a kind of classification id to group certain parts – like fasteners, frames, base materials etc.

With the introduction of electronic parts this rough classification as defined in ERP became insufficient as already the description and classification id were not enough to really understand if an item could be reused. During that same period of time more and more companies where merging or acquiring other companies and they want to understand and benefit from items already used in one of the companies.

So this brings back the challenge for the two goals mentioned:

  • How can I make sure my engineering reuse existing items in future products ?
  • How can i consolidate and understand items i have used in my company ?

Item reuse

In order to promote item reuse companies have used various classification systems in engineering to promote reuse and standardization within the company. Design catalogs with standard purchase parts, extended with company standard parts were implemented to limit the variety of choices for a designer. Companies & Products  like Trace Parts, SolidWorks Toolbox, Inventor Content Center address this need.

Additional mostly in the German speaking countries a classification standard exists, called sachmerkmahl leiste (sorry only in German) or often referred to in the context of the DIN 4000 standard. This is also a standard classification standard, less CAD design centric. Interesting to analyze why this standard does not exist in other countries.

One of the reasons might be that classifying all your engineering data takes a lot of time – specially when you haven’t done it from the start. I worked with some companies where more than a man-year was spent on classifying information. This work had to be done by someone with engineering knowledge, so you can imagine the investment for classification, beside the software was huge. Main question is, what will be the (expected) Return On Investment ?

In this area I think that a cultural difference plays a role here. Some countries invest more in their working methodology and processes than others where the focus might be only on the single result. From my global experience to be fair, i have not seen and heard the real benefits of this type of classification for reuse. I am looking forward for statements from companies that have measurable result here. Like many IT projects we have the emotional feeling that this approach should bring benefits

Item Consolidation

In the mid nineties when companies started to merge, PDM became PLM, CRM became important, also another trend became visible. The need for item classification systems, more on the inventory side, for companies to understand which items they were using around their (merged) enterprises. One of the first companies that time was Aspect Development Inc, later in 2000 merged with I2. Customer case studies learned us that in some of these enterprises a single item could exist with 100 different ID’s, all described or classified in various departments a little different, so hard to reuse. Only by classifying items within an enterprise based on their specific characteristics, people start to recognize identical items. Also in smaller mid-market companies I have seen situations where items have been named or identified just a little bit different, although they were the same.

Here benefits of item consolidation can be easier justified. I assume most companies can estimate what is the total cost of handling an item through its lifecycle and what are the purchase benefits by consolidating for example 10 different named into a single item to be purchased in a much bigger quota.

The benefits really come when you control your inventory and from this base feed the engineering department with an optimized selection of validated items for reuse. And this is to my opinion the most important goal of classification

How to implement classification ?

As described above classification is needed to promote reuse of engineering knowledge and to standardize on inventory (purchased items).

To address the first need I believe PLM offers various ways to support a classification. Some might believe DIN 4000 is a useful standard. From my experiences with companies it appears that it is important to bring rational to what you classify. Where is the ROI. Classification brings a lot of constraints and overhead to the engineering department – all parameters needs to be mandatory managed for each part, otherwise your classification looses its value. Probably you will realize that classifying metal strips does not bring the reuse value as the overhead for maintaining the classification is higher then the cost of producing a new strip. So I am not so convinced about classification for this need.

For the second need – inventory optimization – here i believe the classification brings a measurable ROI, specially when the company uses  a New Item Approval process  or Standardization Process, where every new item will be reviewed (and classified) to guarantee its unique need. Of course it depends very much on the type of industry and main business process if this approach brings value. Listed in a more relevance order: Engineering To Order / Configure To Order / Design For Manufacturing

Folksonomy versus Taxsonomy

A new trend for classification is the way search engines work on massive unstructured data. No one tries to classify all the web pages that exist (although there might be a standard for that). It is easier to perform a context search and specially with new web development you see that tagging information becomes more and more important for retrieval. For example I tagged this article with PLM, ERP, Classification, Item Reuse and Item Consolidation. These tags will be used by search engines and I do not have to worry on which level and where Item Reuse is stored. As a creator of this text part I tag my information for reuse.

This is called Folksonomy, this in contrary to Taxsonomy, the classical method for ordering information. See for more background the related wiki hyperlinks.

Conclusion

Implementing Folksonomy in a PLM environment depends on the type of PLM system you are using (in case you use a PLM system). It requires a way to tag information in an user-friendly way and to retrieve information by tags in an easy way – the ease of use of a search engine. In case it is too futuristic this approach, evaluate your engineering classification needs based on your expected ROI and goals, keeping in mind in the classical way of classification will evolve.

Do you have examples of classification with a proven ROI for engineering, let me know

observationThe words used in this title are the ones that I heard the most the past weeks- only all of them in a different (more pessimistic) context. Speaking with potential customers  and vendors I heard most of the times the combination: Can we do PLM when there is an economical crisis ?

A famous Dutch soccer player (Johan Cruyff) once said: “Every disadvantage has its advantage” and this is also valid for the economical crisis. It forces companies to think (different) as their future is challenged. Less orders means less works and probably less pressure on the organization – companies might decide to lay off people to reduce costs. This is in many cases a pity as knowledge (IP = Intellectual Property) might be lost.

One of the benefits of PLM is that the IP (stored in people’s brain) becomes available and visible inside the company without the need to consult these experienced persons.  Would this mean implementing PLM would reduce they amount of people in engineering ? No, it reduces the risk for a company to be held hostage by these people and even more. By making internal IP available inside the company, it allows companies to overlook their portfolio and performance – and from there to decide where to focus an innovate. It creates a competitive future.

In some of my previous posts, I mentioned that one of the most heard excuses not to implement PLM was the fact that companies claimed they are too busy. This means reduced work creates the opportunity to invest time in PLM – and as the budget for implementing PLM might not be available, at least the time exists. The work done during this time assists the company once we are in an economical upward move – usually at that time companies become stressed as more work needs to be done with few resources available – and new resources need to be hired.

For me a PLM implementation can be compared with a journey through an unknown area. As companies usually do not understand what is the impact of PLM to their company – the ultimate goals somehow are known, but how to get there, no one knows.  A company can hire consultants and implementers to guide them during this journey, and i believe this is required, to avoid going in the wrong direction.

However the knowledgeable people inside the company know best which changes in business processes will bring value and which are not yet understood. And this is crucial in a PLM implementation – a company needs to digest and understand the impact of PLM.

So considering the points above and the fact that as a company you do not want to invest much in a PLM implementation at this moment due to the financial situation, what can you do:

  • Spend time inside your company to decide where you want to be in two to five years, assuming that once you have a more promising market you need there to be ahead of your competitors
  • Learn and invest with PLM providers who can offer you a solution. Pay attention in this phase on which partner understands your business and can guide you in a step by step approach towards your goals. Do not get distracted by function and feature comparison of systems at this stage as most PLM systems can do the same, it is more about your implementation / consultancy partner.
  • Define a step by step implementation roadmap, where each step brings you ROI (return on investment) and closer to your goals.

Considering the three points above you will be able to say:

Economical Crisis and PLM ?
YES we can (start)!!

observationThe past month I was involved in a two ENOVIA SmarTeam projects, where both had the target to become the company’s PLM system. However the way these projects were executed lead to the conclusion that the first one was probably going to fail as a PLM system, were the second project was going to be successful. 

And only by looking back to the history of the first implementation, it became clear what prevented it from becoming implemented as a PLM system. It had all to do with a bottom-up approach and a top-down approach. I guess ENOVIA SmarTeam is one of the few products that allows a customer to make a choice between bottom-up or top-down.

Somehow also Jim Brown’s post was in line with this observation, but judge yourself.

Most classical PLM systems require a top-down approach as the PLM scope requires departments to work in a different way and to enforce a change on the organization. Organizational change usually only happens top-down based on the vision of the management.

cad ENOVIA SmarTeam however has the option to be implemented as a CAD data management system, managing the Product Data in the form of documents. This brings a lot of value to the engineering department and depending on the PLM awareness of the company they might try to replace the Excel based Bill Of Materials  into a BOM inside the system. As we are working in the scope of engineering this is in most of the cases the Engineering BOM.

There are also other CAD data management systems that claim to be an enterprise PDM system as they manage the product data (usually only the native CAD data) and the engineering BOM. As these systems do not contain capabilities to become an enterprise PLM system, it will be clear for the organization, where to position it – and to keep it in the engineering department.

There are engineering managers in mid-market companies that have the PLM vision and this was the case in the first implementation I mentioned. As his initial mission was to manage the product data based on SolidWorks and AutoCAD, the company decided that ENOVIA SmarTeam was the best multi-CAD data management solution for the company. Meanwhile the engineering manager had the hope (or dream) that once this implementation was completed all other departments would stand in a queue to get connected to ENOVIA SmarTeam too………

…. and this did not happen. Why ?

The main reason for that was that at the time the management had understood the PLM benefits and considered implementing PLM, they looked at SmarTeam and it was implemented too much as an engineering solution, too rich in functionality (and complexity) to be used and integrated by other departments. But when the company was looking to an PLM extension from their ERP system, the engineers refused to work with that system, as according to their opinion the system did not support their needs.

How could this be prevented ?

express This was done exactly in the second project. Also here the implementation started in the engineering department, but from the start it was clear for the management, that they would extend the implementation towards a full cross-departmental PLM implementation. The main difference was that the implementation was not focused on satisfying the designers, but from the start it was clear ENOVIA SmarTeam should be useful for other departments too. This implicated less customization on the existing product, more standard functionality. Yes, the designer had to change their way of working as they worked file-based before. But as the focus of the implementation was always on providing data access across the organization, the system remained attractive for the production planning and manufacturing people. It was not an engineering tool only.

Additionally the standard ENOVIA SmarTeam system required from all departments adaptations to their working methods, but as it was not heavily customized, it was much easier to extend the scope beyond engineering.

So what is the conclusion:

  • Do not try to build the ultimate engineering solution as step 1 in a PLM project. Remain with the core capabilities.
  • Keep the focus on storing information in such a way that it becomes usable for departments outside engineering. This requires less detailed data and more reporting capabilities
  • Do not hide the intentions to the management that ENOVIA SmarTeam can become the company’s PLM system. Make the management aware of that but also explain the benefits of a step-by-step implementation, starting with engineering and expanding when the time is ripe
  • It would not be the first time that ENOVIA SmarTeam was the best kept secret for the management. The engineering department was happy, but no-one made the effort to explain the full capabilities to the top management

And now a small advertisement add the end

sde The ENOVIA SmarTeam Express offering allows a customer to start design centric (SDE = SmarTeam Design Express) and to extend the scope step by step by applying engineering capabilities extending the scope from Concept to Manufacturing (SNE = SmarTeam Engineering Express), guiding a bottom-up implementation step-by-step.

observationThe last two weeks I spent around two events for the automotive industry. First the SAE event in Chicago and this week the COE Automotive in Detroit to give a lecture around the future possibilities of a supply chain in a web 2.0 (PLM 2.0) world. For many of the lower tiers suppliers in the automotive supply chain this seems to be something far from their daily business. I guess one of the issues here is, that these companies are used to solve their problems per department, without having a corporate vision or strategy where the company should be in five years from now.

And here I see many challenges (in Europe we would call them possible problems). As the smaller mid-market companies try to solve their problems per department, you will find all around the world bright engineering managers who conclude that their company needs PLM. As they understand all the engineering challenges, they understand that in order to really understand what their department is doing, they should work in a different way than file based.

This is what companies working file-based think

When working file based companies rely on the following main contributors for getting information (in order of importance)

  • we do not need these expensive solutions for PLM etc …
  • the most important is the experienced engineer who knows what has been done in the past and where to possible find it
  • the company directory structure which allows everyone to find and store data related to a customer, project or product
  • the file name of the designs and documents which ‘exactly’ describes what’s inside the file

You just need to follow this order and you will always find the right information (or be close to it).

 

..and these are the issues they do not tell you.

  • I guess we really do not know what to do with PLM as we never studied it, what it would be for our company
  • we cannot bypass our experienced engineers – although at a certain moment they will retire, currently they would feel very insecure if we tried to collect their explicit knowledge and make it available for all. They would feel their jobs are less secure
  • there are some issues with this directory structure. Sometime someone deletes or overwrites a file that we needed, and of course we are not sure if all the data we need is really there. We always need to double check with the people to be sure – and sometimes it hurts, but we are used to it
  • or people are creative that only they understand what is in their own files and even from the file name, which can be long, we do not fully understand where it fits, what is the status and where is it also used.

Seeing these two opposite messages, we need to understand what are the challenges for these companies in the near future.

Challenges for these companies

The current workforce is aging all around the world – i recently read that although many believe China is the next promising country for the future, due the the one-child-per-family strategy in the past, they also will face in the near future (10-20 years) the same problems Europe and the US will have.

A huge part of the population will retire and especially in Europe and the US with this retirement a lot of real knowledge will disappear. The new generation will come with different skills, a different background and attitude to engineering. And due to the difference in attitude there is little or no communication between these generations.

So if you are an (aging) manager in a mid-market company in an automotive supply chain, you have two options to react:

  • you become fatalistic and believe that the new world is bad and you cling as long as possible to the old habits you are familiar with

or

  • or you understand every few decades a change in the way of working is required, which means moving away for the traditional knowledgeable people with their files to an internal, knowledge sharing environment where everyone has access to understand what exists and in which status it is.

So only one conclusion

 Survival for the future requires a change in the way these companies are working. It reminds me of the boiling frog story. We do not see the world is changing around us, till it is too late. I guess human beings should be more clever than frogs and they are able to collect information from outside their ‘pan’. 

Working with ENOVIA SmarTeam solutions, in particular the Design Express solution, I learned that this solution is an excellent entry point to move away from file based work towards data management.

Still not convinced ? Challenge me by adding a comment (public exposure)  or sent me a private email for a one-to-one discussion

As there are many engineering managers who believe that they understood the issue and started to implement an implement a PLM solution in their department, I will address in my next post they challenges they face with this bottom-up approach to convince the company PLM is unavoidable

Below just a goodie to enjoy

observationThe past weeks I have been traveling and visited several implementers and potential PLM customers in Europe. Afterwards I presented and joined a panel session in the SAE 2008 Commercial Vehicle event.

Between the traveling I had enough time to reflect what i saw and heard and I realized that in the mid-market and perhaps in the lower tiers of the automotive industry, people are locked in by the way they are working and thinking, meanwhile seeing PLM vendors already coming with future concepts, talking about PLM 2.0

Many of the mid-market manufacturing companies I met in Europe are just realizing PDM (Product Data Management) in their company, usually as an extension of CAD data management. If you look to the demands of these companies through RFQs, they are trying to build a complete environment for their product data mostly around the engineering department.

This is the classical way bigger companies were implementing 15 years ago, and now mid-market companies see and understand the maturity of this concept.

Is PDM the first step to PLM ?

In my previous posts I already argued that implementing PLM (which goes beyond PDM) brings the real benefit for manufacturing companies, but this requires a change in the current way of working. Disciplines (marketing/sales,engineering, production engineering, maintenance & service) have to collaborate around the major business processes from the company, instead of optimizing each department and then forward information to the next department as we can see from the (classical) picture below:

old_process

Now these companies implement PDM, but what is the result ?

engineering_pdm

For mid-market companies the above step is easier to implement as it has not so much impact on the organization, however the fundamental way of working does not improve and does not provide the full benefits that bigger enterprises experience. The main benefits in the above situation are quality and efficiency benefits for engineer. As there is still no connection between the customers (marketing/sales) and the field (customers / service), the engineering department will work in an ivory tower, knowing what’s best. Only the real problems will reach them but the fine, combined information from the field will not reach them, and for that reason innovation is much harder to come from this approach.

Although PDM can be a first step towards PLM, it is only a step to get organized

The real benefits come when the collaboration around the whole product lifecycle is implemented. This is mostly not going to happen by a bright individual in the company. It requires a strategic vision and approach from the management, to change the way departments are working and connected.

In the very small mid-market companies this kind of collaboration has always existed ad-hoc. Quotes I heard in the past weeks were:

“if there was an issue, we all gathered around the machine in production and we solved it on the floor. This is collaboration.”

or:

“we do not need workflow and other tools to spend time informing each other. If there is something required, we just talk to each other”

These quotes above show, that people are not prepared for a structured, global approach. The main manufacturing process should be defined in such a way that exceptions like the first quote do not occur. Also the talking from the second quote is replaced by something that is traceable and secure, in order to guarantee repeatable results. This is the major task for the management in mid-market companies.

Meanwhile it is the role of the PLM providers to talk and understand the language from the mid-market companies.  Not technology but work/task-oriented solutions will narrow the gap between the user and the software. Once the gap becomes smaller, mid-market companies might understand and feel the benefits of PLM.

So is the gap 15 years ?

I guess not, and for the following trends:

  • More and more early adapters from PLM in the mid-market report the benefits from their PLM implementation. So the acceptance for PLM becomes mature.
  • Mid-market companies will become more and more part of enterprises, which will bring the strategic vision of PLM to them.
  • The aging workforce requires companies to capture knowledge that will disappear if they keep on working the same way. Joe, who knows everything, will retire in 5 – 10 years. This is where the management will get alerted to act – in time we hope.
  • The new workforce comes with different, multi-tasking skills, used to work with a computer on parallel sessions. It is to the management to understand these new talents and develop them.

As most of the points are addressed to the management, I want to point once more to the following posts from the past:

culture change in a mid-sized company a management responsibility

Reason #5-not to implement PLM: We are too busy

observation Just back from the ECCAP in Tokyo  where the Dassault Systemes roadmap for V6eccap combined with V5 was discussed and presented in the context of the Asian Pacific customers and companies.

As most of the activities around V6 are focusing on the future around a Service Oriented Approach (SOA), it might be interesting to look at Oleg Shilovitsky’s blog around PLM 2.0 . The conference kept me busy, so busy that I had almost no time to write this post, which actually targets a frequently heard message: We are too busy (to implement PLM / to do something else / etc …)

So in this post I want to conclude the sequel around reasons not to implement PLM. As a reminder:

The 5 reasons not to implement PLM I heard the most were:

  1. The costs for a PLM implementation are too high
  2. A PLM implementation takes too long
  3. We already have an ERP system
  4. Isn’t PLM the same as managing CAD files ?
  5. We are so busy, there is no time to have a PLM implementation in our company

And now, we reached #5

5. We are so busy, there is no time to have a PLM implementation in our company ?

Indeed a PLM implementation should not be underestimated. The impact on a company is significant if implemented correctly.  I encountered two types of PLM implementations:

  1. implementations where the implementer automated the existing customer processes as-is, with a slight change due to chosen PLM capabilities.
  2. implementations where the implementer assisted the company in changing their current business process towards PLM capabilities and best practices provided by the system.

Both type of implementations might have consumed the same amount of money and implementation services. The impact on the company however is completely different.

NoProcessChange

In case 1 the benefits are relative low as mainly automation of repetitive tasks or data entry was optimized. People in the company did not need to change there way of working too much, and the impact on the way they worked was relative low.

Note: we have a work pressure of max 110 % (no big changes) but at the end we reach an effectivity below 120 % where the work pressure remains close to 100% (98 %)

This means thanks to automation we achieve 20 % more and feel just a little less pressure
(20 points difference between effectivity and pressure)

ChangeProcess

In case 2 the benefits were much higher as the changing of business processes lead to an optimized process for innovation and engineering changes, based on core PLM system capabilities and tuned for the company.

However the impact on people in the company was also much higher. Different ways of working, changed responsibilities, sharing of data all lead to a learning process.

Note: we have a work pressure close to 120 % but at the end we reach 95 % where the effectivity reaches 125 %

This means thanks to the automation we achieve 25 % more and feel approx 5 % less pressure
(30 point difference between effectivity and pressure)

The graphs are a generalization based on facts i learned in the field and I tried to visualize the impact of a PLM implementation on a company.

So now we have three options to:

  • We have no time to implement – we are too busy
    This leads to a dead end – assuming PLM is relevant for your company – it means the competitors will implement and get ahead of you. Making survival even harder and lead to stressed employees till it cracks
  • We can implement PLM without changing our processes too much
    This is what an inexperienced implementer will suggest. “Tell us how you want to work and we build it for you” . This leads to higher customization costs but probably less pressure on the organization to make changes. At the end as described in case 1 it will bring benefits but not affect the pressure so much. Consider it a band-aid till the next fix.
  • We implement PLM as it supposed to improve our processes.
    Implementing PLM with an experienced PLM implementer and a clear vision will lead to a higher pressure on the organization for approx a year and probably lower costs of customization, but higher temporary resources costs. However at the end it will provide the company with a base to be more competitive. Effectiveness has increased significant and reduced pressure
    can lead to new innovation

 

Conclusion

If your company would benefit from PLM according to its core business, delaying the implementation is giving your competitors more chances and will affect your market share. Next if you decide to implement PLM be aware that only by changing the way you work more in line with the PLM best practices for your industry you will gain the real benefits. For that reason you need an experienced PLM implementer as partner to guide you in this path.

Translate

  1. Unknown's avatar
  2. Håkan Kårdén's avatar

    Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…

  3. Lewis Kennebrew's avatar

    Jos, as usual, you've provided a buffet of "food for thought". Where do you see AI being trained by a…

  4. Håkan Kårdén's avatar