You are currently browsing the category archive for the ‘ENOVIA’ category.

observation Last week was a week of transition. As I wrote in my previous post, I finalized a traditional PLM 1.0 project ( I will come back on this term ‘traditional’ PLM 1.0) and now probably because of the sunny days and some interesting articles I read (each word goes to a different article), I am reflecting what it means to think about the new trends:  WEB 2.0 or even PLM 2.0

In this post I will try to explain the developments I have seen so far in the mid-market and from there project what might happen.

In the 80’s there was no PDM or PLM in the mid-market. This was the time most companies were moving away from the drawing board towards CAD. Most of the CAD was 2D and at that time in the mid-market AutoCAD was the dominant CAD software.

CAD At that time I was working for the biggest AutoCAD distributor in the Netherlands (picture on the left). This was the golden age for hardware and software resellers – margins were high and there was little or none IT-knowledge inside mid-market companies. In order to keep the high margin we provided a free helpdesk for our customers to differentiate from others. It was an interesting time. Prospects came to our demo room to plot a drawing of A0 format and to discuss the quality of the lines and the hatching as compared to handmade drawings. There was always the discussion if CAD was more productive and must of us agreed that benefits only came when rework or changes were needed. In parallel we offered a training course for the heads of a design department how they learned to  understand if their designers were productive. They were used to observe the behavior of the draftsman and the minor bar on the drawing board and from there they understood if someone was productive. We were talking about the new digital generation that would replace the people at the drawing board.

Are there still drawing boards ? Is there still free support as the margins are high ? This was 20 years ago.

Then slowly 3D CAD was introduced for the mid-market, initially only on Unix boxes, but with the introduction of Microsoft Windows it became achievable – SolidWorks for sure was leading in this area. Hardware became already more a commodity so the customer relation changed from free support to paid support, which required quality and knowledge. At that time in my company, we also saw the first demands for what customers called an “engineering database”.  In the 2D world it was all about drawing management, now with 3D the focus was on managing the whole product. Initially called EDM (Engineering Data Management), later evolving in Product Data Management. The term PDM was not known at that time and I remember one of our customers visiting us with a sample of 13 reports – drawing list, spare part list, manufacturing BOM, etc. He told us:  “I need a system that can generate these reports for me at anytime”.  The solution: we implemented a PDM system for this customer. At the end of the nineties 3D was introduced in the mid-market combined with PDM. We were talking about the new generation of people that thinks in 3D which would replace the people who still worked in 2D

Are we still working with 2D ? Do we still look for support on hard- and software ? This was 10 years ago.

express Then came the era of connectivity, initially  through the first internet wave, leading to terms as cPDM and ultimately PLM.  Instead of focusing on productivity in a single department, the intention was to focus on collaboration between departments, development teams and to address the whole product lifecycle. Specially Dassault Systems extended this concept by focusing on the process and virtualization: test and build your product virtually before you spend any money on prototypes. Autodesk does the same in different words, they call it Digital Prototyping and they try to avoid talking about the processes as here we touch the most sensitive point in mid-market companies: touching or changing processes – ‘classical PLM 1.0. And this is also what I read between the lines of Jim Brown’s post Is innovation or product pipeline killing profitability ? As long as we do not change our product development process but focus still on doing the same with better tools, the real innovation will not come. We are now talking about the global collaboration generation that has to learn to work together and replaces the people who are not changing their processes.

Are we still solving our departmental problems only ? Can we survive keep on doing the same ? This is now !

And meanwhile mid-market companies are learning to understand and digest the above, we already see the new wave coming. WEB 2.0 – social networking – social collaboration – PLM 2.0 – communities and more. Instead of companies working on their own data, the future is to work in communities, live data, cross-company with employees, who are focused as a team to bring a result, we do not send so much emails anymore, we chat, we twitter, we …….. and more. In addition as we will see the trend that teams have members from all around the world, the question comes up: What is the standard communication language ? German (past) , English (present), Chinese  (future) ?  Here I am a big fan and believer of the Dassault vision that 3D becomes the global language for communication as the people participating do not come from the same educational background anymore – so it easier to see what you mean. Meanwhile the futurists are all the time talking about the aging workforce (a lot of people plan to retire), but if you read back, you will notice every ten years we are talking about an aging workforce. Every time there was a new generation picking up the new capabilities and challenging the next generation.

Are we in 2020 a global, 3D twittering world ? What is each individual’s added value ? What are companies doing to anticipate to the above trends ? It looks like it is going to happen and the current economical downturn allows us to anticipate even earlier till the next pit stop.

A thought I take with me on the summer holidays.

(Yes, in Europe we still have holidays that are so long you have time to think about work –
you can find me on the island below in August)

anafi

observation The last month I have been working with Aerosud Aviation in South Africa to finalize and conclude on ROI and the lessons learned around their PLM implementation, which started in May 2007.  I was lucky to be involved in the initial scoping of the project in 2007 and assisted the local Value Added Reseller together with the team from  Dassault Systèmes UK team in a step by step project towards PLM.

planningWhen I met the people in Aerosud the first time in 2007, I noticed it was a young company, with open-minded people, everyone trying to improve their daily activities per department. There was the need for PLM as some of their major customers required Aerosud to have a PLM system in place. Also Configuration Management was mentioned many times in the interviews and what I learned that time: Excel was the tool for configuration management.

Based on the initial interviews a plan needed to be developed in which steps to implement PLM.  The following three major points were the guidance for the implementation:

  1. The company was thinking documents and understanding documents especially Excel
  2. The company had no clear understanding of what PLM would mean for them as real awareness was not inside the company. Customers like Boeing and Airbus talked about the importance of PLM, but how this could impact Aerosud as a company was no commonly clear
  3. People in the company had a major focus on their department and there was no availability of a overarching group of people leading the implementation

You could say you will see the above points in many smaller and medium-sized companies. I wrote about it also in one of my previous posts: Where does PLM start beyond document management ?

The project phases

riaan The good news for Aerosud was that their PLM Champion was an expert in CATIA and was familiar with writing macros in Visual Basic plus the fact that everyone in the company was open for using the system as standard as possible – no demands for special behavior of the system:  “because we do this already for 100 years”

The last phrase you hear a lot in ancient Europe

The choice was to start with implementing ENOVIA SmarTeam Design Express and to focus in two phases around design data management (phase 1) and the usage of design data by other users (phase 2)

The plan was that each phase would take maximum 2-3 months and we would give the users the time to digest and change their habits towards the standards in the system. In reality it took almost a year, not due to technical or conceptual issues, but this was the maximum pace we could have with the amount of time and available resources. The good news after these two phases was that the first bullet was much clearer understood – the difference between having a system with a single version of the truth or Excel management.

businesssystem In the summer of 2008 (our summer – as it was winter in South Africa) there was a management workshop in Aerosud and here after three days of discussion the position of PLM became clear. One year ago this would not have been possible, now people had seen ENOVIA SmarTeam and they could imagine what benefits the system could further bring. This addressed the second bullet I mentioned before. Although this workshop was not scheduled upfront, looking back now I see this was a crucial point to get understanding for the next PLM steps.

 

The next PLM steps were extending to a real Item-centric data model, because if you want to do PLM you need to work around Bill of Materials and all related information to the items in the Bill of Material. At the end this gives you configuration management without chasing Excels.

Again the next steps were divided in two phases with again a scope of 2 – 3 months. The implementation would be based on the ENOVIA SmarTeam Engineering Express methodology which came as a logic extension of the current implementation, without having to change the database or existing data model.

In the first phase we had awareness sessions for BOM (discussing EBOM / MBOM / Effectivity, etc) plus in parallel we introduced the item as place holder for the information. Not longer folders or projects as the base.

Introduction of the item was conceptual not a big issue and the major activities in this phase were focused on connection legacy data or current data from projects to the items. Data coming from various sources (directories, legacy databases) plus NC data became connected and visible in the single version of truth.

In the second phase of moving to PLM the focus was on EBOM and MBOM. Initially assuring that from the designer point of view the CATIA design and EBOM were connected as smoothly as possible, trying to avoid a lot of administrative overhead on the designer (sometimes unavoidable – see my previous post: Where is my ROI, Mr. Voskuil)

ebom_mbom

After having implemented a streamlined CATIA – EBOM connection, the focus moved to the MBOM. For me this is the differentiator for companies if they implement PLM or just Product Data Management). Implementing the MBOM requires a culture change and this is the place where the ERP people need to see the benefits instead of the threats . Luckily in Aerosud the manufacturing engineers were working in their Excels initially and not in the ERP system – which happens a lot in older companies.

For that reason the concept of MBOM in PLM was much better understood. Now Aerosud is experiencing these capabilities and once they become obvious for everyone the third bullet will be addressed: people start to work in processes cross-departmental instead of optimizing their department with a specific tool.

phased implementation As this activity will continue, I also conducted with the Aerosud management and PLM implementation team an ROI assessment. Estimates about the experienced and projected benefits were kept low and on the realistic side. The result was that the outcome for the ROI period was approx 27 months, almost the same time as the whole project had as throughput time. This proved again the statement about a phased PLM approach. payback of project comes in parallel with the implementation and will ultimately fund the next steps.

 

 

shout_left End of July I will be holding a webinar with more details about this implementation for the Dassault VAR Community. I will be happy to expand this information for a wider audience afterwards, as I believe the project is representative for many mid-market companies that struggle to find the place where PLM fits ….. and brings ROI

 

Let me know if you are interested in this follow up and I will collect the inputs for a follow up.

observation 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: “

 

question

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 ?

point 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:

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:stepped

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:coop

  • 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 !

expressConclusion:  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

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 analyzing 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.

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.

observation This week was a week full of discussion with customers and VARs (Value Added Resellers) around PLM, PDM and implementation approaches and I will come back on this topic in an upcoming post. First I want to conclude the sequel on reasons why companies believe they should not implement PLM.

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 #4

4. Isn’t PLM the same as managing CAD files ?

As most of our customers do not have the time to study all the acronyms that exist in our business, it is understandable that it leads to a different interpretation as expected. In non-academic language I will roughly outline the differences.

In the eighties when most of the mid-market companies designed their products in 2D, bigger enterprises were investing in 3D CAD. In parallel these companies were working on concepts to manage all their engineering data in a central place.EDM (Engineering Data Management) was the word in fashion that time. We have to realize that networks were not as affordable as nowadays and that there was no Internet. It was the first concept to centralize and manage engineering data (files – no paper drawings). An EDM system was of course a system purely for the engineering department.

More and more companies started to expand the scope of data managed, it became the central place to store product related information plus being an infrastructure to collaborate on product data. The acronyms PDM (Product Data Management) and cPDM (collaborative Product Data Management) became in fashion in the nineties. A PDM system still focuses on the engineering department but no multi-discipline and if available in dispersed locations.

In 2000 the focus of PDM was again expanded to other departments in the company working on the product in different lifecycle stages. Instead of a static data management environment, it became a target to connect all departments working on the product through its lifecycle. By having all departments connected, the focus could switch to the process. The acronym PLM (Product Lifecycle Management) was introduced and this created a lot more areas of interest:

  • connecting the bidding phase and concept phase with feedback from production and the field.
  • bringing the sourcing of parts and suppliers forward in the product lifecycle
  • testing and planning on a virtual product
  • and more

But what should be clear from the scope of PLM compared to PDM and EDM, that it has become a cross-departmental approach and not only a system to enhance the way engineering departments work.

PLM is a strategic approach to enable innovation, better portfolio management and response to the market. The focus is on changing the traditional way of working into an approach where the process is as lean as possible still providing flexibility to adapt to global changes – changing customer demands, changing business situations.

Overview

EDM Focus mainly on centralizing mechanical design data
in an engineering department – mainly files
PDM Focus mainly on centralizing product related data in an engineering department – files, BOMs, etc
PLM Focus on the product development lifecycle cross departments and locations – files, BOMs, processes, resources.

Conclusion

No, it is not the same, where managing CAD files is mainly an engineering department related activity which can be solved by a product, PLM is a cross organization approach which requires a PLM system as enabler to implement various best practices

This time a short post, I am off to the ECCAP (September 9-10) to meet customers, implementers and peers all around ENOVIA

Adiosu

eccap

observation Last week I conducted another ENOVIA SmarTeam Express training, this time in the Coventry office from Dassault Systems. The conclusion from the audience was that the SmarTeam Engineering Express concept is a perfect entry PLM system for the mid-market. It show the general best practices of PLM for a mid-market from concept to manufacturing. Additionally is provides the company a flexible PLM platform to further grow and expand to directions that bring more benefits.

But here I want to stop, as you will start to believe it is a marketing speech. In a certain way it is marketing. Marketing is needed to influence people and companies to change their way of thinking. Without marketing we would never buy Personal Computers, mobile phones, MP3 players, certain drinks and more. We tend to forget why we need certain products and what the real benefits are. PLM is not at that level of market understanding yet.

For that reason I will give the 5 objections why not to implement PLM that I heard the most and comment on them.

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

In this post I will address the first reason. Others in upcoming posts.
Note: I use generalizations in this post as specific cases my vary – specially when talking about comparisons with ERP system.

1. The cost for a PLM implementation are too high.

This is the argument I heard the most. And indeed, if you accumulate the total costs of a PLM implementation after 2-3 years, you might get that impression. The main reason for this perception is the fact that often companies have suffered from an ERP implementation in the past. I do not want to blame the ERP companies for the high costs of implementation, as they were the first major business system implemented in manufacturing companies. There were many horror stories in the past, but now you can say ERP has become mature and processes to implement are clear too. For that reason ERP companies now can provide an estimated cost and ROI (Return On Investment) for manufacturing companies. I guess that manufacturing companies that have not invested in ERP the past 20 years, probably stopped to exists, so benefits for ERP are clear.

But at what costs ? PLM is not as mature as ERP. This means a PLM vendor cannot come to a manufacturing company, identify its main business process and apply a PLM template. The major reason for that is the fact that the PLM vision encompasses many different processes in a company, many of them currently not even identified in mid-market companies. This leads to the situation where PLM implementers together with their customers spend time to learn and pay the price for learning. Most of the learning has been done already by the big enterprises, now the mid-market companies need to understand what is relevant for them.

We know learning has it costs, and specially when external (paid) resources are involved, the costs might add up too high. In parallel the biggest mistake made to implement PLM is to consider it the same way ERP is implemented. A project team builds in a isolated environment a new ‘to be’ PLM environment, once and a while involving key users for their feedback. Then after 8 months – 1 year they role out the PLM implementation to the users as a ‘big boom’. As a logical reaction the users object to this radical change, which leads to compromises, and rework of some of the project deliverables. At the end after 2 years the company might have an acceptable PLM implementation, meanwhile having a bad taste of a failed and costly project. And the ROI still to come……

See the diagram below:

big boom

So how can we avoid these high costs ?

First of all the investment of a PLM is done because we believe there is a Return On Investment. Companies invest in order to improve their competitiveness and PLM is a main driver for manufacturing companies. So how can we assure ROI and lower the total costs ?

A first best practice is the phase a PLM implementation into small, digestible steps with a durations of 3 to 6 months. Each step will have its investment and its limited scope. The result will be that even after the first step, people can start working with the new system, experience the impact of the new PLM system and start bringing ROI as the benefits will start paying of.

These benefits plus the fact that the company and their users start to understand what a PLM system can bring for them and this leads to a clearer and lower cost of implementation for the next phases. The figure below gives an impression of how costs and ROI will work out in this situation.

phased implementation

The Express offerings from ENOVIA, SDE (SmarTeam Design Express) and SNE (SmarTeam Engineering Express) are exactly targeting this approach. Instead of imagining what PDM and PLM could do for a company. They allow the company to quickly start and experience and later grow to the optimized environment.

The management of the company should always keep their ultimate PLM vision in mind, still anticipating changes as business evolves. Each implementation phase should fit in the ultimate PLM vision and its implementation should be judged on bring ROI.

This is a main difference between PLM and ERP. An ERP implementation focuses on a specific logistical process to implement. This implementation cannot be done for 50 % and than later another 30 % and again another 10 % till the ultimate ERP vision has been reached. It must be done in one implementation as it targets the whole production process.

A PLM implementation however is an implementation of Best Practices all around Product IP and innovation. The world in which products are defined has changed drastically due to globalization, customer focus and changed technologies. This means that the way companies define and develop their products have to be flexible and changeable. PLM implementations require a step by step approach, every time improving those areas that bring the best ROI. Still the company needs to remain flexible in to anticipate for future changes, merges, acquisitions or even different business processes.

Conclusion: PLM systems are not costly in case of a phased implementation targeting immediate ROI per phase and flexibility in the future.

Last week I was in Greece together with the Dassault Systems Value Added Reseller OVision. Everyone would expect from the first sentence I was on holiday. Yes I agree, the settings were holiday like always temperatures above 35 C (approx 100 F) and never far from the see.

 

However,……

….we were visiting ENOVIA SmarTeam prospects and discussed existing customer specific implementation wearing business suits – not wearing shorts. However the most interesting issue was, that we were working with companies that were in the early stages of data management.

image If you look around the world, to my understanding, and would rank countries on PLM awareness and need for data management, I would rank Western Europe, Scandinavia, Japan as the countries where concepts for PLM are understood, although in many mid-market companies I would still expect on the long term a culture change to real PLM. In my previous posts, I addressed several thoughts on that.

North America and the United Kingdom I rank differently, as somehow, there are big PLM implementations, but the majority of mid-sized companies is supplier of an OEM network or sees no return on investment on a PLM implementation

Then I would rank countries like Turkey, South Africa, India, and China as the next level. As they participate in manufacturing of global companies – mainly automotive and aerospace, they are driven into the basic needs of PDM as requirement from the OEMs. This pushes in parallel the country’s infrastructure – Internet / Intranet availability.

At the fourth position, I would rank a country like Greece. As due to the local economy there is not a focus on manufacturing or a huge participation in a global supply chain, they have to introduce their data management, growing to PDM or PLM slowly on a still developing infrastructure

Disclaimer: Countries not mentioned here can fall in any of the above categories (or even below). The fact that I did not mention them, is because I have not enough experience working with these countries to judge.

Back to Greece 

Apparently, due to all the beautiful islands in Greece, there are thousands of ferries traveling from island to island or other Mediterranean destinations. For that reason, there are companies that build ships, companies that refurbish ships and companies that maintain ships.

At the end, a ferryboat can be seen like single process plant. Like in a plant, you have equipment that needs to be operational and maintained during operation.

This requires a well-defined form of data management, often driven by quality processes around ISO 900x.

Companies often consider quality processes as a kind of document management. You have your manuals with procedures, templates spread around the company, and you update them before the next audit. Everyone is supposed to follow the procedures and supposed to know the latest procedures.

This is a labor-intensive activity if you want to execute as best as possible. In companies where the cost of labor is an issue, you will see that most people are loaded with work and usually the quality issue is the last activity these people will execute, first the operational issues then the rest.

image

In order to improve the quality of the information, document management and workflow processes are functionalities used to address the availability of the documents and the workflow ensures information to be pushed and published in a guaranteed manner.

Instead of pushing the information to all the users, the company is now able to centralize the data and users can pull the latest information from the system. The workflow processes and the document management system guarantee the right steps are followed and you are always looking to the latest versions. Also you are aware of on-going changes.

When it comes to ships however, there is more to address than ISO documentation and procedures. The ship itself has maintenance or refurbishing projects running on certain systems or locations in the ship. Here the advantages of a PDM system like ENOVIA SmarTeam appear. In the ENOVIA SmarTeam data model you are able to manage information (CAD documents and Bills or Materials too) related to a project, to a ship, to a location or system in the specific ship. There is no need for keywords on the document to describe where it applies, or have copies from a document because if applier to several ships. The data model below shows the types of information that can be stored around a ship.

image

Once the company has the vision, what to achieve in the upcoming years, a roadmap can be defined. Keeping user understanding, flexibility but still a continued move towards the PDM data model are parameters for the management to monitor and drive. Companies that build or refurbish ships of course have even higher needs to integrate their engineering activities with the ships maintenance data. This avoids a costly hand-over of data that already could be available in the right format.

Conclusion: Although Greece is in the fourth rank of PLM needs and awareness, the benefits to gain from PLM are there too, however due to awareness and infrastructure, they are not as visible as in the countries ranked as number one.

As Greece is the birthplace of many sciences, I am sure the awareness for where to apply PLM concepts is for sure something they will achieve.

This week was again a week with several customer visits and discussions around PLM implementations. As analysts like CIMdata, AMR Research, the Aberdeen group are all claiming that PLM will be the next thing for small and medium manufacturing companies, the discussion around PLM is on-going. Of course PLM vendors are adapting their messaging and sometimes their products towards the SMB.

Some vendors like PTC and UGS try to downscale their existing products mainly by changing the packaging of the product (but it remains a PLM system originally designed for enterprises) others like Dassault Systemes have a special SMB offering with full PLM capabilities, ENOVIA SmarTeam.

But let’s assume we have the ideal PLM solution for an SMB company. This was the startpoint, I had during my meetings this week.  How would you motivate a company to implement PLM, knowing all the constraints of SMB companies. Miki Lumnitz wrote about it in his blog –PLM for SMB who are those companies ?

I noticed one of the main issues for discussion is the handling of the MBOM (Manufacturing BOM). So let’s look at the different view points in a company.

EBOM (Engineering Bill Of Materials)

 “The EBOM reflects the way a product was functionally designed”

When engineers define a product, they design (or reuse) assemblies (modules) and add new parts and assemblies to the design. When working with a 3D CAD system, saving the product results in a document structure which resembles a lot the engineering BOM. Traditionally companies got the impression that by changing this EBOM structure a little, they would have a structure ready for manufacturing, called the MBOM.

MBOM (Manufacturing Bill of Materials)

image “The MBOM reflects the way a product will be manufactured”

The MBOM is a structure derived from the EBOM. Main changes from EBOM to MBOM are:

  • removal of subassemblies that do not exist in the physical world. For example a grouping of two parts which are logically grouped by the designer, but as a group do not make sense for manufacturing (Assembly B). And in addition of non-design items which are needed for manufacturing the product. For example paint or grease. (Item F)

Traditionally – and also in the companies I was visiting – the EBOM is domain for the engineering department and with additional modifications they provide a BOM (is it EBOM or MBOM ?) to the ERP system.  Some companies add non-engineering items to their design – they draw a can of paint in their design to make sure the paint is part of the BOM . Some work with phantom production order to address the usage of subassemblies by engineering.

image

Both EBOM and MBOM definition are preparations before production can start. The EBOM and MBOM contain the product knowledge how to build and how to manufacture a product. For that reason they should be handled in the PLM system. The main reasons for that are:

  • during process engineering there is a need to use, analyze and sometimes adapt engineering data. This can be done in the most efficient way within one system where all product data is available
  • PLM systems, like ENOVIA SmarTeam contain tools to create quickly based on certain rules a MBOM derived from the EBOM and when changes occur even compare both structures again, to adapt to these changes
  • Having a single environment for product definition and manufacturing improves the total product understanding

So where is the MBOM ?

Ask yourself as a company ” where do I handle the MBOM ?”  Some of you might say, we do not have an MBOM as our EBOM with some modifications is already good enough for manufacturing.  Many companies might say, we manage the MBOM in the ERP system as this is (was) the only system we had where we could define such structures. These companies are candidate for improving their Concept to Manufacturing process, as for sure either users or working methods are compromised to work with the MBOM in the ERP system.

image

Some might says: Do we still need ERP systems ?

Yes, as ERP systems are built to schedule and execute the production of well defined products in the most efficient way. ERP systems are needed for the execution, often the core activity for manufacturing systems.

PLM systems are reason that ERP systems can execute, they bring the product definition and information to produce a product. And in case the company designs and manufactures excellent and innovative products the future is bright.

But we should not consider engineering activities in the same way as production activities.

Einstein once said (and he is not an expert anyway):

Innovation is not the product of logical thought, even though the final product is tied to a logical structure

I am curious to learn where your manage your MBOM

%d bloggers like this: