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

In my previous post, the PLM blame game, I briefly mentioned that there are two delivery models for PLM. One approach based on a PLM system, that contains predefined business logic and functionality, promoting to use the system as much as possible out-of-the-box (OOTB) somehow driving toward a certain rigidness or the other approach where the PLM capabilities need to be developed on top of a customizable infrastructure, providing more flexibility. I believe there has been a debate about this topic over more than 15 years without a decisive conclusion. Therefore I will take you through the pros and cons of both approaches illustrated by examples from the field.

PLM started as a toolkit

The initial cPDM/PLM systems were toolkits for several reasons. In the early days, scalable connectivity was not available or way too expensive for a standard collaboration approach. Engineering information, mostly design files, needed to be shared globally in an efficient manner, and the PLM backbone was often a centralized repository for CAD-data. Bill of Materials handling in PLM was often at a basic level, as either the ERP-system (mostly Aerospace/Defense) or home-grown developed BOM-systems(Automotive) were in place for manufacturing.

Depending on the business needs of the company, the target was too connect as much as possible engineering data sources to the PLM backbone – PLM originated from engineering and is still considered by many people as an engineering solution. For connectivity interfaces and integrations needed to be developed in a time that application integration frameworks were primitive and complicated. This made PLM implementations complex and expensive, so only the large automotive and aerospace/defense companies could afford to invest in such systems. And a lot of tuition fees spent to achieve results. Many of these environments are still operational as they became too risky to touch, as I described in my post: The PLM Migration Dilemma.

The birth of OOTB

Around the year 2000, there was the first development of OOTB PLM. There was Agile (later acquired by Oracle) focusing on the high-tech and medical industry. Instead of document management, they focused on the scenario from bringing the BOM from engineering to manufacturing based on a relatively fixed scenario – therefore fast to implement and fast to validate. The last point, in particular, is crucial in regulated medical environments.

At that time, I was working with SmarTeam on the development of templates for various industries, with a similar mindset. A predefined template would lead to faster implementations and therefore reducing the implementation costs. The challenge with SmarTeam, however, was that is was very easy to customize, based on Microsoft technology and wizards for data modeling and UI design.

This was not a benefit for OOTB-delivery as SmarTeam was implemented through Value Added Resellers, and their major revenue came from providing services to their customers. So it was easy to reprogram the concepts of the templates and use them as your unique selling points towards a customer. A similar situation is now happening with Aras – the primary implementation skills are at the implementing companies, and their revenue does not come from software (maintenance).

The result is that each implementer considers another implementer as a competitor and they are not willing to give up their IP to the software company.

SmarTeam resellers were not eager to deliver their IP back to SmarTeam to get it embedded in the product as it would reduce their unique selling points. I assume the same happens currently in the Aras channel – it might be called Open Source however probably it is only high-level infrastructure.

Around 2006 many of the main PLM-vendors had their various mid-market offerings, and I contributed at that time to the SmarTeam Engineering Express – a preconfigured solution that was rapid to implement if you wanted.

Although the SmarTeam Engineering Express was an excellent sales tool, the resellers that started to implement the software began to customize the environment as fast as possible in their own preferred manner. For two reasons: the customer most of the time had different current practices and secondly the money come from services. So why say No to a customer if you can say Yes?

OOTB and modules

Initially, for the leading PLM Vendors, their mid-market templates were not just aiming at the mid-market. All companies wanted to have a standardized PLM-system with as little as possible customizations. This meant for the PLM vendors that they had to package their functionality into modules, sometimes addressing industry-specific capabilities, sometimes areas of interfaces (CAD and ERP integrations) as a module or generic governance capabilities like portfolio management, project management, and change management.

The principles behind the modules were that they need to deliver data model capabilities combined with business logic/behavior. Otherwise, the value of the module would be not relevant. And this causes a challenge. The more business logic a module delivers, the more the company that implements the module needs to adapt to more generic practices. This requires business change management, people need to be motivated to work differently. And who is eager to make people work differently? Almost nobody,  as it is an intensive coaching job that cannot be done by the vendors (they sell software), often cannot be done by the implementers (they do not have the broad set of skills needed) or by the companies (they do not have the free resources for that). Precisely the principles behind the PLM Blame Game.

OOTB modularity advantages

The first advantage of modularity in the PLM software is that you only buy the software pieces that you really need. However, most companies do not see PLM as a journey, so they agree on a budget to start, and then every module that was not identified before becomes a cost issue. Main reason because the implementation teams focus on delivering capabilities at that stage, not at providing value-based metrics.

The second potential advantage of PLM modularity is the fact that these modules supposed to be complementary to the other modules as they should have been developed in the context of each other. In reality, this is not always the case. Yes, the modules fit nicely on a single PowerPoint slide, however, when it comes to reality, there are separate systems with a minimum of integration with the core. However, the advantage is that the PLM software provider now becomes responsible for upgradability or extendibility of the provided functionality, which is a serious point to consider.

The third advantage from the OOTB modular approach is that it forces the PLM vendor to invest in your industry and future needed capabilities, for example, digital twins, AR/VR, and model-based ways of working. Some skeptic people might say PLM vendors create problems to solve that do not exist yet, optimists might say they invest in imagining the future, which can only happen by trial-and-error. In a digital enterprise, it is: think big, start small, fail fast, and scale quickly.

OOTB modularity disadvantages

Most of the OOTB modularity disadvantages will be advantages in the toolkit approach, therefore discussed in the next paragraph. One downside from the OOTB modular approach is the disconnect between the people developing the modules and the implementers in the field. Often modules are developed based on some leading customer experiences (the big ones), where the majority of usage in the field is targeting smaller companies where people have multiple roles, the typical SMB approach. SMB implementations are often not visible at the PLM Vendor R&D level as they are hidden through the Value Added Reseller network and/or usually too small to become apparent.

Toolkit advantages

The most significant advantage of a PLM toolkit approach is that the implementation can be a journey. Starting with a clear business need, for example in modern PLM, create a digital thread and then once this is achieved dive deeper in areas of the lifecycle that require improvement. And increased functionality is only linked to the number of users, not to extra costs for a new module.

However, if the development of additional functionality becomes massive, you have the risk that low license costs are nullified by development costs.

The second advantage of a PLM toolkit approach is that the implementer and users will have a better relationship in delivering capabilities and therefore, a higher chance of acceptance. The implementer builds what the customer is asking for.

However, as Henry Ford said, if I would ask my customers what they wanted, they would ask for faster horses.

Toolkit considerations

There are several points where a PLM toolkit can be an advantage but also a disadvantage, very much depending on various characteristics of your company and your implementation team. Let’s review some of them:

Innovative: a toolkit does not provide an innovative way of working immediately. The toolkit can have an infrastructure to deliver innovative capabilities, even as small demonstrations, the implementation, and methodology to implement this innovative way of working needs to come from either your company’s resources or your implementer’s skills.

Uniqueness: with a toolkit approach, you can build a unique PLM infrastructure that makes you more competitive than the other. Don’t share your IP and best practices to be more competitive. This approach can be valid if you truly have a competing plan here. Otherwise, the risk might be you are creating a legacy for your company that will slow you down later in time.

Performance: this is a crucial topic if you want to scale your solution to the enterprise level. I spent a lot of time in the past analyzing and supporting SmarTeam implementers and template developers on their journey to optimize their solutions. Choosing the right algorithms, the right data modeling choices are crucial.

Sometimes I came into a situation where the customer blamed SmarTeam because customizations were possible – you can read about this example in an old LinkedIn post: the importance of a PLM data model

Experience: When you plan to implement PLM “big” with a toolkit approach, experience becomes crucial as initial design decisions and scope are significant for future extensions and maintainability. Beautiful implementations can become a burden after five years as design decisions were not documented or analyzed. Having experience or an experienced partner/coach can help you in these situations. In general, it is sporadic for a company to have internally experienced PLM implementers as it is not their core business to implement PLM. Experienced PLM implementers vary from size and skills – make the right choice.

 

Conclusion

After writing this post, I still cannot write a final verdict from my side what is the best approach. Personally, I like the PLM toolkit approach as I have been working in the PLM domain for twenty years seeing and experiencing good and best practices. The OOTB-box approach represents many of these best practices and therefore are a safe path to follow. The undecisive points are who are the people involved and what is your business model. It needs to be an end-to-end coherent approach, no matter which option you choose.

 

 

 

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.

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

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

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

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

Last week I was working with several people on data management issues for the supply chain. As I mentioned in my previous post from the ECC in Munich, there is a trend where OEMs require more and more cooperation from their suppliers. Most of these suppliers are mid-sized companies and these companies often lack the management support to implement changes top-down in an organization.

supply_chain_change

In mid-market companies the concept for quality guarantee and consistent responses is often implemented in design data management (control the product data), a quality system (ISO,—–) and the ERP system. See also PLM and ERP culture change. As these systems could be implemented on department level, not touching each other too much, it is relative easy from the cultural point of view to implement them. Each department can optimize themselves and often the quality system is not enforcing the users to work completely different.

But who and where is innovation managed ?

Large enterprises discovered that, in order to innovate, you need to connect and analyze all information around the products they are manufacturing. In simple words they realized PLM is needed to connect everyone around the product lifecycle from the concept phase till the production and after-sales phases. For these companies PLM became the backbone for their specific knowledge – we call it IP (Intellectual Property). Big companies could implement PLM because they had the management vision, the resources (people and budget) and the top-down approach to enable (and sometimes enforce) this change.

In mid-sized companies there might be the management vision, but resources and a top-down approach are rare. When it comes to a top-down approach, often the management believes that the goal is to enforce one IT system to the organization to manage all the critical data. Naturally this is the ERP system, and ERP vendors remain claiming that they can do PLM. It is a kind of overestimation of these companies as their nature lies in processing data, resources as efficient as possible, not in being creative to find new innovations.

Innovation is not CAD design as others may believe. These beautiful 3D designs smell like innovation, but in fact before a designer could start working on a concept, a lot of work has been done before. Analysis about what is it that the market, the customers require?  What is de feedback on our current products in the field ? What is the competition doing etc, etc.

PLM requires culture change

As long as an organization remains thinking around 1 or 2 major IT systems (CAD data management and ERP) to manage all, there is no chance for PLM to be implemented successful. All departments and disciplines around the product lifecycle need to work together, change their departmental habits and learn to adapt to PLM best practices.

There is enough argumentation why to implement PLM and I believe solutions like ENOVIA SmarTeam Engineering Express are from the technology point a good start. See all related posts and comments to my previous post.

What I wanted to stress is that changes in a mid-market company are not done from the logical point of view. As the top-down vision and implementation often are not available, we are waiting for all departments to decide let’s change our way of working as we read all these beautiful benefits of PLM. This is of course not going to happen, only in advertisements.

Culture change even in mid-sized companies is a management responsibility and requires an open mind. We often forget that we have two sides in our brain. One side the logical side, analyzes all the arguments and stores them logically as good or bad. The other side of the brain, the emotional side is making the decisions, grabbing arguments that suit from the logical side in order to explain to others and ourselves why a decision is taken.

If you read books like The Language of Change (very theoretical, but the groundwork) or Blink: The power of thinking without thinking (very popular) you will understand that changes won’t happen if we stick to the traditional way of posting our arguments and keep on doing what we feel good with.

It is the management responsibility to think how to enforce a change in their companies. But as they also have a two sided brain, for that reason, management consultants were invented to reflect and discuss the emotional and logical side.

If after reading this post, you are more aware of the fact that one side of your brain fools you, then I achieved something. If however you will say “This is nonsense”, your other half of the brain has won.

Footnote:  No more words about soccer – Holland is out

This week, I was in Bruxelles conducting a Engineering Express training for ENOVIA SmarTeam resellers. The feedback I got from the participants during the training made me again more aware from the culture change needed or dreamed about in the small and medium manufacturing enterprises.

As I wrote before in PLM and ERP – the culture change , there is for sure a conservative vision in the small and medium enterprises to stay with their major IT systems they invested in, usually ERP and (3D) CAD.

From the bigger enterprises and reading all the analyst reports, many of us project that the small and medium enterprises also need PLM in the same way as the bigger enterprises, but then in a more packaged, ready to use manner, instead of a custom implementation guided by PLM experts like the bigger enterprises did.

So ENOVIA SmarTeam Engineering Express is a prepackaged solution bringing PLM closer to the mid-market. However during the training many of the questions were not around the capabilities of the Engineering Express, but more about why do we(customers) need to use the same approach as bigger enterprises, why do we have the same needs?

Where big companies focus on defining and implementing processes in order to have a predictable outcome, I noticed in talking with SMB companies, they are proud of explaining they exist without these processes enforced, but work in a more flexible, human task oriented manner.

If we look to a classical ECR/ECO process, we see in bigger companies there are several steps to be identified to react on a outside request (the ECR) and to implement it (ECO).

image

An Engineering Change Request (ECR) process

image

An Engineering Change Order (ECO) process

In smaller companies the ECR process is already embedded in one singe ECO process. Sometimes a formal (email) based activity takes place before a change is requested and implemented. One of the participants in the course – a manufacturing company – mentioned that they had the notice of a CCB in their company but all engineering change requests were sent to the CCB by email and as the CCB was meeting on a weekly base, this was the process to filter engineering change requests.

image

So here is the question: Big enterprises need processes to remain manageable – like a big tanker needs a predefined methodology to navigate through a harbor. Small and medium enterprises are more relying on their flexibility and they need a reliable and sustainable way to react – like a small ship in a harbor – as it can react quickly there is no need for the anticipation, still the capability to change direction is needed.

So are small and medium enterprises that behave like small ships in the harbor ?

If yes, they need to remain open for change as going straight ahead at the end will lead to a collision – and the challenge remains to make the (culture) change.

Or if no, how can you provide small and medium enterprises with means that enforce change without creating the overhead that compromises the flexibility ?

image

I am looking forward to comments and thought on this question – please post them.

However my first priority tonight is to survive in Milan where the match Italy-France will decide who continues to the next round in the European Soccer Championship. Worst case in parallel the Netherlands looses from Romania, in that case both Italy and France are gone and this might be my last post:)

Hoping to write my next post at the end of this week.  ciao – adieu

%d bloggers like this: