You are currently browsing the category archive for the ‘SmarTeam’ category.
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.
When 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:
- The company was thinking documents and understanding documents especially Excel
- 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
- 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
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.
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)
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.
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.
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.
In the past year I shared with you my thoughts around PLM. Most of the post were based on discussions with customers, implementers, resellers and peers around the world. I learned a lot and will keep on learning I assume, as PLM has many aspects:
- the products, there are many products with the label PLM
- the concept, how do we interpret PLM per industry
- the customers, what do they want to achieve, without buzz-word
- the world, people and economic trends drive us sometime to irrational decisions
In this post I will give an overview from the 2008 posts, categorized by topic. I am looking forward to further suggestions in the comments if you are interested in more depth in certain areas. In parallel I will continue to share my experiences and provide an overview of best-practices and terminology experienced in the PLM space.
PLM and ERP
PLM and ROI
Business Process Change
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 !
The 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 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
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:
- The costs for a PLM implementation are too high
- A PLM implementation takes too long
- We already have an ERP system
- Isn’t PLM the same as managing CAD files ?
- 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.
|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.|
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
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.
….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.
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.
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.
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)
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)
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.
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.
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.
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. At the end the computer decides – see movie
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).
An Engineering Change Request (ECR) process
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.
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 ?
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
Last week I visited the ECC in Munich, a conference where around 1000 people attended. It was an excellent event for networking and being in touch with customers, implementers of the ENOVIA brand. The V6 announcement and demonstrations were the major key-note sessions and they showed the focus on real global collaboration for big enterprises.
In the industrial tracks I followed the Aerospace / Defense track (approx 80 attendees), where European companies like Airbus, Aermacchi and Messier-Dowty gave their status and vision on their core development processes, supported by sessions from IBM and Dassault Systems.
Interesting to learn from this session was that all agree that the classical hierarchical structure in the supply chain will disappear and that it will be more and more a network of suppliers working together, with much more responsibility and risk sharing for the supply chain partners. This higher responsibility and risk requires supplier to work with a PDM system too, and Airbus stated that for future contracts with suppliers this is a must – either integrated or interfaced.
Suppliers who do not meet these quality standards by having PLM implemented will not get new contracts anymore and in the next three years we will see a change in the supplier network and collaboration technology, based on solutions upcoming from Dassault and other software suppliers.
On the second day I attended the ENOVIA SmarTeam track (approx 100 people) where beside the current roadmap an interesting scenario was explained how the smaller and medium enterprises could work on V5 but thanks to the coexistence capabilities of V6 could collaborate with V6 companies or even inside their company could work on both levels in the future. It will be interesting to follow this approach.
Finally on June 9th the European soccer championship started. The Dutch team did not perform well during the qualification rounds and we were all afraid for the real tournament.
But miracles still happen – enjoy