The number of companies in our industry that are investing in improving their PLM strategy is increasing. Most likely your company is looking at how it can improve its PLM strategy even if you have not heard the term PLM. There are specific PLM tools but do not be fooled into thinking that by investing in a tool which is branded as a PLM solution that that means you are automatically improving your PLM strategy. Your potential might be higher but if not implemented correctly, you will not be improving anything.
I often get questions revolving around the implementation of a PLM solution and my thoughts on PLM in general. I thought it would be a good idea to share them via my post in this blog.
There are many dimensions to PLM implementation; however, I have decided to narrow them down to 5 for this post:
- PLM System (Tool)
- Exchange Of Information
- Understand Your Processes
- Company Culture
- Milestones (Agile)
PLM System (Tool)
I almost always get the question, “Which PLM tool would you recommend?” My answer is always the same: “I have no idea.” The thing is that deciding on the PLM system to invest in requires a lot more knowledge of your challenges you want to solve, business goals you want to achieve, current culture, future culture you want to attain, team skills, other systems to integrate, and much more.
I say that a good relationship with the PLM vendor is required as they should be a partner. I also mention some items to consider:
- Managing models in our industry using the traditional check-in check-out mechanism is not going to work. Make sure the workflow of how you want your team to work is supported in the tool you invest in.
- Modifications of your 3D product model should be kept in your industry specific tool such as ShipConstructor and not in the PLM tool. PLM systems have some great features but in most cases it does not outweigh the benefit of using your industry specific tool to manage your 3D product model.
- Make sure you have a demonstration with a project that has a similar size number of items. Many compare shipbuilding to aerospace or automotive but the fact is that a ship can have 10x-50x the number of modeled items. Most systems do not scale linearly.
- Understand how items and “documents” are related. This is important since in our industry you will have multiple drawings (production, fabrication, modeling, etc.) for your parts (items). Examples are profile plots, arrangement drawings, pin jigs, class drawings, assembly drawings, lifting & turning, welding, profile nests, etc.) Drawings are not an authoring master but rather just a representation of the product. They should not be treated as the authoring source.
- Items with the same name does not mean they are the same part which some systems have an issue with. This may require another way to identify the part. An example is standard brackets which have the same name but can have different finishing, routing information, nest tape, assembly, etc.
- Make sure you work through your sister ship (fellow ship) strategy using the feature set of the PLM tool.
- In shipbuilding you include much more production (construction/manufacturing) in the design. It is impossible to find a 3D product model of a ship which does not already include many manufacturing decisions (material sizes, lifting constraints, block transportation constraints, forming capabilities, etc.). This is why it is very important that when selecting the PLM tool that you investigate the ability to manage the project and not just the “engineering” data.
Exchange Of Information
The process of transferring information is the topic I think most people concentrate on and worry about. In my opinion, at least for our clients, the process of transferring information from ShipConstructor to any other system has never really posed that much of a difficulty. This is due to our fully open architecture and our EnterprisePlatform.
The area of information which I would concentrate on is to determine what information needs to be transferred, linked and/or synchronized. Once this is determined the act of actually doing the work is relatively small.
Understand Your Processes
Most companies which are planning on implementing an approved approach to PLM are actually planning to change the way they conduct their business. This means they need to put a lot of focus on understanding their current processes and think very hard on how they want their future workflow to be. It will not matter what tool you have selected, your PLM implementation will fall short of your goals if you do not spend enough time on processes. The more time you invest in this stage the better your results will be.
There are many PLM specialists out there who I would suggest your company look at consulting. There is a shortage of PLM consultants who understand shipbuilding which is why I would also recommend to have an additional external (internal might work if they are the right person) who understands shipbuilding very well and also has a working knowledge of PLM. With these experts and your team you will get the best overlap of skills required to do this step successfully.
There are some PLM analysts who say that the PLM consultant should not be from the PLM vendor you are using. Even though I agree with this in principle, I do believe that there are exceptions to this rule. This will be a case-by-case decision and will be something you will have to make.
Company Culture
The hardest and probably the area most companies neglect to make appropriate changes in when implementing PLM revolves around people. People do not like change and in our very traditional industry it is very apparent.
It is not that PLM requires a culture change but rather the change to your business and its processes require people to change their daily tasks. I think most companies understand this but as mentioned above do not create an environment to ease the transition. A strategy of, “They will have to change or they will be fired” (yes I have heard this) is not a strategy and will not promote an adoption of the new process and tools.
I wish I had a silver bullet to recommend to you but I honestly do not. Actually I do not think anyone does. Here are some recommendations:
- Work closely with each team to define as-is processes and to-be processes. This will engage the team and reduce the resistance to change. Your PLM implementation is going to take a long time (relatively) which can work in your favor. During this time the team will slowly acclimatize to the type of changes to come.
- A champion on each team will be required. This champion does not need to be in “management” but ideally would be someone the team respects.
- Make sure you spend time with each team and explain how the changes will improve their job. I think this is just as important if not more important than explaining how the new process or tool will help the company. It would be nice if every employee would look at the bigger picture but that is a false reality for most. This obviously cannot be done for all teams since in some cases you will require a team to do more work to improve something more significant downstream.
Milestones (Agile/Lean)
I am a big advocate for implementing any project using Agile methodologies with milestones and your PLM implementation is no different. Each milestone should concentrate on a small subset of changes either by functionality, team, workflow, etc. and when complete should add value to your company. Value can be measured in many ways and is not just related to something you can use. For example a good milestone would be to test an assumption you may have. If you take one of the recommendations I mentioned above about ensuring your PLM tool can handle your project size, a good milestone would be to add information that is equivalent to your project in the PLM tool. This may or may not be 100% the way you will store your information but you will be able to at least test any assumption or “promise” made.
Here are some of the benefits of setting up good milestones
- Each milestone will provide value. A milestone can be a subset of production ready workflow which your team can use. This bite size milestone will allow a more manageable amount of change to be adopted by your team. It is also common that the first set of milestones can improve your processes with relatively little effort. As the saying goes “Pick the low hanging fruit.” Also milestones are a great way to test assumptions which if not tested early in the process can have a very negative impact on your project.
- Create a better system by allowing you to pivot after collecting information from a previous milestone. It is 100% guaranteed that when you start with your implementation of your PLM you will uncover issues and challenges you did not account for. With small milestones you will find these much earlier in the process and therefore it will be much easier and cost effective to pivot (change direction).
- Reduces overall risk. With bite sized milestones you will always have a good understanding of how the project is going and the ability to identify issues early.
- Good way to manage a schedule. With the smaller scope of milestone deliverables you are able to estimate much better. Also you will be able to better understand the progress of the entire implementation.
- Reduce cost by finding issues early and also reduce PLM tool investment slightly since your first milestones may only concentrate on a specific department or workflow.
Closing Remarks
Implementing a PLM tool in itself is not what many companies struggle with. The challenge most companies have is that they are taking the same opportunity to implement a PLM tool to optimize their business. Therefore the company is not going through a PLM implementation but rather a Business Transformation.
With any significant business alteration there are some key factors which need to be understood and incorporated in your implementation. Tool selection, information exchange, process optimization, changing company culture and implementing manageable milestones are just some of the areas you will need to consider.
There is definitely no shortage of information on PLM and some of the blogs I frequent are often related to this subject so, for your reference, I have provided them for you as well:
- Lifecycle Insights by Chad Jackson
- Beyond PLM by Oleg Shilovitsky
- Tech-Clarity by Jim Brown
- Virtual Dutchman by Jos Voskuil
- GrabCAD by Various Authors
- E[E] by Ed Lopategui
- Joe Barkai
- Engineering.com by Various Authors