PLM and ERP – 10 steps on how to do it

In PLM vs ERP we looked at how hard PLM-ERP discussions and integrations can be and why it is so. Here is a 10-step approach for how to get a typical PLM - ERP integration in place.

A very important assumption here is that we have got PLM and ERP, IT and Business people into the same room and they understand each other. The driving force is the business and what they need to do their job efficiently. These 4 groups must be involved in most of the activities.

Note also that the steps are in a logical order, but clearly not sequential. All steps will be iterated several times and an agile approach is recommended.

1. Objective & Ambition

The single most complex and yet important task is to agree on what we want to achieve (business needs and benefits) and what ambition level we shall have. This will require process walk-throughs where the overall business process is covered and all stakeholders give their input. It is important to understand and agree on a high level:

What does the business need?

• What processes goes across PLM and ERP?
• What information should flow in these processes?
• What users are impacted?
• What type of information is needed across the systems?
• Is it a one-way or two-way transfer?
• How often must the information be transferred?
• Is there a clear owner of the information or does it change over time?

The PLMuERP Handbook from PLMIG gives a good indication of which topics to address in this step.

2. Information Architecture (Data Model)

Now we know the high level needs from the business. The next step is to agree on a more detail level what information we are talking about. An integration requires very good quality of the data. It is not enough that the data on both sides are almost the same. They have to match 100%.

This is also an exercise to ensure that the PLM, ERP, IT and Business people understands and agrees.

Build a data model showing the data elements (objects) and how they are related (relationships) that focuses on the data that is to be shared between PLM and ERP. Ensure that the Part, The Item, The Material or whatever you call it is understood and defined in the same way across all PLM, ERP, IT and Business people and in the PLM and ERP solution. Continue and do the same with the metadata.

Too often this is not the case when you look into the details. Use real examples and look into the IT tools, follow the processes to build a common information architecture you can agree on.

3. Information Flow

Now you know what information to manage. The next step is to detail where it flows. Where is the information created, updated and used on the PLM side and on the ERP side? Is the information only enriched as it goes through the processes or can it be changed? Are there exceptions to the information flow? Is there a clear transfer point in the process?

4. Business Rules

This step is of course not done isolated. It is done together with the others steps and gradually understood, detailed and defined. The purpose of this activity to look at certain rules that has to be followed and/or built into the integration to ensure data and process consistency.
Some simple examples can be: Transfer bottom-up and transfer only released data. When a new revision is released: Transfer again. There are typically also more advanced business rules that has to be applied to support the way you are working and using the information. E.g. you might convert data in the transfer based on several parameters, you might transfer to different ERP systems based on certain criteria, etc.

5. Processes

The processes has of course been addressed all the way. This is though the step to detail and finalize the information related processes. What are the processes that do at least one of the following:

• Goes across PLM and ERP
• Trigger transfer of data
• Ensures consistency

Crucial processes are the:

• Engineering Change process
• The Part release process
• EBOM to MBOM

If other information than one-way transfer of BOM information is to be managed there will be additional processes that must be covered.

6. Transfer Mechanisms

The next step is to decide what triggers the transfer of information. You must decide the information carrier and what triggers the transfer. There is something in your data model that groups the information you want to transfer in one go. It can be a Part with its children or it can be an ECO and its released Parts that shall be transferred from PLM to ERP. Or it can the Part itself with cost information to be transferred from ERP to PLM.

There is also a point in your process when the information is in such a state that it can and should be transferred. The data is mature, it is deemed correct and it will not change. If it changes it will be transferred again.

7. Data mapping

Part of data mapping is done together with the data model mentioned above. This is for the remaining details. Different tools and to some extent different processes have different terminology for the same thing. This is the detailed activity of mapping all data fields in PLM and ERP that are to be transferred.

8. Data ownership

Data ownership and Master Data is linked. You must decide what data is originated where and owned by whom at what point in the lifecycle. Data ownership might change as the process moves forward. That is ok as long as there is consistency and you always can trust the data you are using.

9. Integration Technology

Usually this point is mostly influenced by the existing methods, tools and guidelines already present in your company. Modern PLM and ERP tools are quite open and flexible when it comes to integration – Maybe not as much as we would wish though. You want to avoid building point to point integrations and focus instead on some kind of integration engine that gives you more future flexibility. Usually you don’t start from scratch. Some building blocks are probably available from the PLM or ERP supplier or from the integration engine.

10. Technical Implementation

If you have done the previous 9 steps thoroughly it should be quite straightforward doing the technical implementation. You now know what you want and how you want to achieve it. You need someone who knows PLM, someone who knows ERP and someone who knows the integration technology. And most important: You need someone with the knowledge and understanding gained in the first 8 steps to follow the implementation.

Summary

PLM can be ERP best friends. They complement each other and make each other stronger. Sometimes they argue, but it is always possible to get to an agreement.

The data, processes, principles and mechanisms to ensure that you get the data you need in a consistent manner is the challenging part of a PLM-ERP integration. As long as you know what you want you will be able to implement it.

A challenge is that PLM and ERP overlaps more and more and it might be difficult to find and define the integration points in the process. The picture below from PLM Technology Guide illustrates this well.

Tore Brathaug
www.infuseit.com

2 years of PLM blogging – pick a future topic

Time flies. We have a 2 years anniversary as bloggers. Here are some reflections about the previous blogs. What is getting the most attention? What is a bit scary? You also get the opportunity to vote for a future blog topic.

Some statistics

• 26 blogs in two years.
• Close to 15000 readings. We aim higher the next 2 years.
• Most of the readers are in USA, Sweden, Norway or France. Our main market is in the Nordics. Hello Denmark and Finland! You are not even in top 10…

What gets most attention?
As independent PLM advisors we have had very different topics. Some of them are generic views of PLM challenges and how to overcome them. Others are deep dive into specific processes, industries or solutions. Others are on the outskirt of PLM.

The 3 with most attention (percentage of total readings):

• PLM vs ERP – the everlasting trench war or the best PLM ROI? – 6%
• Why PLM often fails to reach its potential – 5%
• You don’t know what you don’t know about PLM – 4%

It is a bit scary that the top topic is PLM vs ERP. This has been on top of the mind in most PLM implementations and clearly one of the selling points of PLM; Get control with PLM and feed downstream processes automatically with quality data. This is still a struggle, 20 years after I started with PLM. It should not be so.

The other two topics are related to PLM challenges in general. Why is it so hard with PLM? And what do you need to know in order to succeed? This is less as a surprise as people struggling will look for tips and tricks and learn from other failures. These are still on a very generic level.

Some other of the top ones:

• The Strategy of Divide & Conquer and its pitfalls – 3%
• PLM – Vision or micro-ambition? – 3%
• How to select a PLM system – 3%

These are more to the point and explains or discusses pros and cons of a strategy or method. There is a hunger out there to get inspiration or tips in their PLM tasks. Maybe we should be even more concrete and deep dive into some of our experiences?

Some reflections
I have been working with PLM for two decades. It is a bit sad that many of the topics are the same today as when we started. And there is not commonly agreed definition of what PLM is? Is it a tool, an approach, a process or what? And many companies seem to have to do the same mistakes as many have done before them.

I don’t know, but I guess that many of our readers are really interested in PLM and have some specific PLM responsibility. Then it is like kicking in an open door for some of the topics. Sometimes it seems that the PLM community is for a secluded group of men in their 40’s and 50’s, with a white shirt and little hair, and have been working with PLM for at least 15 years – like myself and my colleagues. Where are the hipsters and our better halves?

It would be very nice if some of the posts also would be read by senior managers or non-PLM people. Then we could have some interesting discussions. There is still a need for raising PLM awareness and understanding. It is fully up to us to attract new audience.

Many are happy to share their experience and there are some really good sources for PLM inspiration. Here are some of the ones that I appreciate the most.

• Beyond PLM
• The virtual Dutchman
• Tech Clarity
• Engineering (Engineering)

We want to focus on PLM as an approach covering many tools and processes and not that much on PLM solutions as such.

Vote for a future topic
We want to share our experience and want your input on what topics that are of biggest interest. The topic with the most votes will be a future blog post. Please spend a minute and vote for a topic.

Summary
It seems that the interest is in both strategic high level, process or industry specific and deep dive into solution areas. There are a lot of possible topics. Please help us select the most interesting topics.

Thanks for reading our blogs and interacting in discussions. We will continue as long as there is an interest in our posts.

Tore Brathaug
www.infuseit.com

How do we get PLM right?

How do we get PLM right and who is the PLM expert? Who knows best how it fits the users and the company? Can we get it right without involving the end users?

I’m not claiming to be a user experience (UX) expert of any kind but I have reflected and learnt some during the years, and one thing is that the best way of really getting it right is by testing it on end-users. And I intentionally expressed this in plural – you need a group of people to validate the chosen solution. It is arrogant to think that you will get it right just because it states expert (or PLM advisor as in my case) on your business card.

But a UX expert wouldn’t ask an end-user; so what is it that you want? To put it into a classic T-Ford example: If you would have asked what the people would have wanted they would have said "faster horses", instead their need was faster transportation. So it's not solutions that one should ask for and seek, it is the underlying problem that you want to solve.

After having talked to the users about their challenges, wishes and dreams, she would bring a suggestion to the table to try it out, preferably before and during implementation. That’s where the UX expert has its domain; understanding the end-user, suggesting solutions and validating them (which is a craft of its own to master). 

So how is it with PLM? Should we consider that the same applies to this domain? That the crowd knows better than the expert? And the expert’s job is to suggest solutions and then validate them?

Who knows the customer best?

Well, I would say it would be strange if it wouldn’t be the customer itself. The customer though, might need some assistance in understanding, expressing, describing and documenting their needs, problems and challenges.

Who knows the domain best?

The customer knows how they are doing things but that is not necessarily the same thing as stating that it is the best way (even for that customer). External “experts” will bring ideas to the table, as they have experience from many different companies, thereby allowing them to have another view on the topic.

Who knows what to aim for, and what the vision should be?

Is it the ones working in the process day-to-day? Well, you need to have some perspective to your own work. And be exposed to input from others to be the one with a goal that has a trajectory which aims high enough.  Don’t get me wrong! You will get good initiatives going by listening to the end-users. But, you might find them to be “micro-ambitious” – targeting to solve the challenges and evolve the work of few, but not taking the enterprise view of the PLM agenda. Also, it is most likely that you will get feedback targeting to solve the problems of today which leads to a more reactive behavior than a proactive approach targeting to get your enterprise to the next "level".

Who knows the tools?

There is actually at least one more “expert” to this equation, at least once you actually talk about IT solutions and not just strategies and processes – The above questions don’t take into account that there are constraint in the IT tools, which are limiting your options. This is where the application expert finds his place. The platform/application will create constraints which the expert, whether it is UX or PLM, has to consider at least to some extent when it comes to deciding on solutions.

The other side of the coin can be processes or solutions in the application that you did not think about, but can give short term improvements with little effort.

Have we found all the “experts” now?

We have a good mix, but there is one more which could spice up things and could be used as a catalyst; the generalist. In some situation you will benefit from not being an expert in the field - an outside perspective will allow you to see new connections and reframing your situation with expertise and experience from other industries and business domains.

An interesting take on this is whether you are looking for someone who should help you solve a problem or find a problem. To truly take your PLM vision and strategy to another level it’s not enough to solve a known problem; you need to find problems that you didn’t know you have. Who is most suited to guide you in that quest?

But what happend to the crowd/the end-user?  

They are there. Because whether you are implementing processes or tools to support them the end-user will still be the judge if it fits with her needs or works in the reality of conducting her work. 

Conclusion

Implementing PLM (and knowing how and what to do) is not a one-man job. You need to ensure that your team is multi disciplinary; with both broad and deep knowledge in the domain, business, and technology. I would also emphasize that you need real end-user involvement to make sure that you, at the end, get their acceptance.

I leave you with a quote that stuck in my mind after a conversation with a colleague:

"A 'newbie' will look for evidence to guide her in the path to the most appropriate actions to a greater extent than an expert would. Therefore she will win in the long run."

What if you would have a team of experienced people which uses the tools and mindset of the newbie?

Robert Wallerblad

www.infuseit.com

How to select a PLM system

During my 15 years in the PLM industry, I have seen my share of PLM evaluation processes, both from the vendor’s side and from the customer’s side. Selecting an enterprise IT system is a comprehensive exercise. The selection of a PLM system is no exception. This is due to the wide range of functions and the fact that PLM can involve many departments (if not all) in a company; all the way from sales, through design and engineering, manufacturing, and even service and after-market.

In this blog I will share my top tips on what to focus on when selecting a PLM system.

• Define the strategy Before diving in to the detailed technical requirements of the PLM system, it is important to set the ambition level and to define the strategy. Start with the big questions: What shall the PLM system do? Is it a strategic enterprise-wide system or just a tool for a specific department? Is the focus on the extended enterprise and global collaboration, or just to have revision control of CAD models? There is no right or wrong answer here, but it is critical to have a clear view on what the focus should be and what you want to achieve.

• Plan ahead When selecting a PLM system, it is important to look at both the needs of the business today and for the future. Think both short-term (what is important to solve today?) and long-term (what do you want to achieve in the next 3-5 years?). Typical short-term needs can be CAD integration, document management and change management, while long-term needs can be supplier collaboration, installed base tracking and systems engineering. It is important to select a tool that caters for both short and long term requirements, and then evaluate solutions based on those ambitions and needs.

• Educate yourself Before starting the evaluation process you should gain knowledge of the PLM discipline. This is important in order to be able to define the requirements properly and to have productive discussions with others on PLM (internally and with vendors). You can gain this knowledge yourself by attending a training class or browsing the Internet, or you can hire an external consultant to assist you.

• Don’t underestimate the importance of usability At first sight, most PLM systems look flashy and quite similar. It is only when you look deeper that you see the differences and how user-friendly a system really is. To secure end user adoption of the system, it is critical that the system is intuitive, user-friendly and easy to learn. This is especially important for ad-hoc/light users of the system who will use the system only sporadically. My advice is to invite non-engineering users with no PLM experience to attend one of the demonstrations, and let them give input on usability.

• Focus on what’s important All the major PLM systems on the market today cover all the required basic PLM functionality. So there is no need to spend time specifying this in the evaluation process. Instead of over-specifying, focus on what is really important. This may be integration to a specific MCAD system, compliance management or other areas outside the PLM core (PDM). All PLM vendors claim they have this, but the level of support varies.

• Select an experienced partner A PLM system is an enterprise IT system that will be around for many years after it has been implemented. Selecting an experienced and solid supplier and implementation partner is an important criterion for a successful PLM installation. It doesn’t matter how good a PLM system is if it isn’t implemented in a proper way, so take a look at the track record of the supplier: Have they done similar implementations before? Are they financially solid? Will they be there in 5-10 years? These are important questions that need to be addressed.

• Talk to other PLM customers By looking at the websites of the PLM vendors, or by attending a demonstration, it can be difficult to distinguish the PLM systems from each other. The best way to really learn what a PLM system and the implementation partner are capable of is to talk to someone with experience of the specific tool and implementation partner. Ask the PLM vendors for a list of reference companies (with contact persons). Ask for references in the same industry and references that use the same functions/modules (e.g. integration to a specific ERP system) that you will be using. Take the time to talk to as many references as possible. They can give valuable input that you will not get from the sales guys.

Conclusion

When selecting a PLM tool it is as important to look at the non-functional requirements as it is to look at the functional requirements of a PLM system. All the major PLM systems on the market today deliver more or less the same functionality. Focus on the local supplier, their solidity and ability to implement. Talk to other companies using PLM systems. Don’t underestimate the importance of usability, especially for ad-hoc users. User adoption is critical for a successful implementation. And before diving into the technical details, spend time defining the PLM strategy, look at what role PLM should have both today and in the future, and make sure this is backed up by management.

Lars

www.infuseit.com

The Strategy of Divide & Conquer and its pitfalls

Have you used the strategy of “Divide and Conquer” in your PLM (product lifecycle management) project? I’m sure you have – it’s the commonly used “best practice” to solve a problem by “slicing the elephant”.  Or as the Romans would phrase it: to break another power into smaller, more manageable pieces, and then take control of those pieces one by one.

• It’s used in software implementation projects to slice processes into activities which are realized through features and functions which are again sliced into technical tasks
• It’s used in problem solving to get a grip of the challenge in front of you
• It’s used in change management and rollout strategies both in terms of scope and organization

Losing the Big Picture

Dividing the world into manageable chunks is powerful and has become a de-facto approach to take on challenging tasks. It’s a reasonable thought and it is a good strategy in many cases but it has its pitfalls. And looking at the other side of the coin: The “Divide and conquer” strategy is about keeping smaller powers and governments from uniting. This might have been a winning concept for Romans and the British Empire to conquer their enemies. But PLM and software implementation projects using this strategy require some mitigation actions to avoid falling into a trap of sub-optimization, lack of transparency and losing the sight of the actual goal. Because, even though you want to cut your elephant into digestible chunks, you still need to be able to see what you are eating. You become the victim of the strategy itself as its whole purpose is to separate, while both PLM initiatives and most software projects require a holistic approach throughout its implementation.

Conveying the Big Picture

If you don’t keep the bigger picture in mind while working on the details, you will deviate from the guiding vision and strategies, the architectural principles, the business goals and actual business needs, the overall processes, and the UX (user experiance) guidelines. Let’s look at the symptoms for each of the listed areas above:

• Vision and Strategies – Sub-optimized efforts which doesn’t contribute to the overall vision or strategy
• Architectural Principles – Platform, application, design decisions breaking the IT strategy will create silos, interconnectability issues, customized solutions, and a diverse spectrum of used technologies. This results in high TCO (total cost of ownership) and a situation where it becomes hard to support and maintain solutions (read: higher risk)
• Business Goals and Needs – Functions and features might be developed according to guidelines and conform with good architectural principles but that doesn’t make anyone happy if it doesn’t help in achieving business goals or addressing business needs
• Processes – If you don’t know how things are stitched together, the risk is pretty big that you will miss something along the way, resulting in a set of “disconnected” features
• UX – The perceived usability of an application will suffer if the look and behavior diverge across functions. This will result in more need for support, more user errors, more training and lower efficiency

The Right Decision at the Right Time

So one challenge we have identified with the strategy is that we need to find ways to convey the “big” picture, so that we can make the right decisions while working on the details, as we want the pieces to still work together to achieve the objective of the whole.

But, we need to find the right level of details describing this big picture. And the timing of setting these details (= make certain decisions) is also crucial. Finding this balance is important as we will lose important freedom too early in the process and thereby our agility.

I hope that it’s clear that it’s not a waterfall approach that I’m promoting. It’s just that I don’t believe that you can work effectively with enterprise software implementations, such as PLM systems,  if you don’t have some ground work done both in terms of processes/methods and involved technology. The output is as much an artifact to be used further down the lane as it should be used to anchor the stipulated way forward and keeping stakeholders involved.

Conclusion

The challenge lies in the way we slice the elephant, while maintaining the big picture and manage the balance between too much or too little of the ground work: taking the right decision at the right time. The next trick is to actually use that knowledge to communicate and anchor our way forward and give input to activities further down the lane. That is what will cater for success.

Do you agree? Have you found this balance and do you have an effective way of conveying guidelines, principles and decisions?

Robert Wallerblad

www.infuseit.com

The Mountain Code for PLM

In this Easter time there are a lot of Norwegians going to the mountains to go skiing in the remaining snow. There are guidelines on how to behave to be safe in the mountains. They are called “Fjellvettreglene” or the Norwegian Mountain Code. As it turns out, they are also strangely relevant for PLM.

1. Be prepared (Don’t go on a long trip without practice)

A good plan is half the job. If you also have people with PLM experience and preferably some PLM implementation experience you are in a good position. It is hard doing a PLM selection and implementation if you don’t have any experience at all. Start small and learn along the way, don't try to take the whole elephant in one bite.

2. Leave word of your route

A twist on this is that you have a better chance of getting the rest of the organization along on your PLM journey if you inform and educate. Let the others know what you plan to do and why you do it. Communicate the visions, plans and achievements. Keep management informed along the way of both good and bad.

3. Be weather-wise (listen to the forecast)

Listen to the weather forecast and show respect for the weather. In a PLM context this can mean that there might be circumstances and events out of your control that can influence the PLM project in a negative manner. A typical one is: “we will do PLM after ERP. And, by the way, the ERP project is delayed”. Others kinds of “bad weather” can be: downsizing, financial troubles, the company is about to or recently has been sold. You should try to listen around for the most obvious ones and be prepared to handle them, and if the forecast is really bad: postpone the trip.

There is also a positive twist to this. Take the opportunity if the weather forecast looks good. If the financial situations is good, management is supportive and there are some clear areas where PLM can contribute: Start now and get a positive momentum.

4. Be equipped for bad weather and frost.

Even if the forecast is good, you might be surprised with bad weather. Be prepared for challenges and troubles. Do risk management properly and have plans for problems before they appear. If the company has financial troubles; how can you cope with a smaller budget and less people? What can you take out of scope if circumstances demand it?

5. Listen to experienced mountaineers

If this is your the first PLM project in your company and you don´t have people with PLM experience, you should listen to others who have done this before. Learn from others and avoid the mistakes done by others. Contact similar companies in your industry, companies in your neighborhood or personal network that have implemented PLM. There are amounts of good advice to get from others. And finally: don´t always trust the vendors ;-)

6. Use map and compass

Create a vision, a roadmap and a plan. And follow it. Of course you might have to adjust the course along the way, but you should always know where you are and where you want to go. You might have to change the destination as well, if you are surprised by bad weather. But that is better than getting lost.

7. Don't go solo

PLM is not a one-man or a one-team job. You must ensure that your project group consists of people from several departments and disciplines. You need involvement of and commitment of all key stakeholders. Make sure that they share your vision and trust your plans.

8. Turn back in time; sensible retreat is no disgrace

PLM projects can be hard and you will meet some trouble. If the trouble is big enough you should consider turning back. In a small scale it can be a new module or functional area just ready for roll-out, which turns out to not be of good enough quality. In a larger scale it can be the whole PLM solution. Turning back to stop the whole implementation is a tough decision, but in some cases it must be done. And it should be done sooner rather than later. Whether it is possible to turn back gracefully is another matter ;-)

9. Conserve energy and build a snow shelter if necessary

Instead of turning back you can stay where you are and conserve energy. Instead of continuing at high speed you take a break and evaluate your position. Did the map or direction change? Are there any unforeseen obstacles? Maybe it is time to re-visit the vision and plan. If worst comes to worst; you can of course book a one-way ticket to Hawaii and relax in the sun. Or, as the Norwegians do during Easter; Go up in the mountains and enjoy the last remnants of snow.

Conclusion

Mountain trekking or skiing has a lot in common with PLM. Following common-sense guidelines is helpful in both cases. From time to time you meet problems, but the better prepared you are; the more likely it is that you can handle it and progress without any danger. Respect the challenge and don’t plan for a harder route than you are trained and equipped to take.

Enjoy the PLM journey and have a nice Easter

Tore Brathaug
www.infuseit.com

PLM Success – Knowledge within the operational data that you produce

This blog continues a discussion which has been the topic of two other blogs; PLM – Vision or micro-ambition? and  PLM Success - Think Inside the Box. Previous blogs was about the importance of embracing changes and input along the way of implementing PLM and not only working blindly towards a set goal.  And the usage of your employees and cross-fertilization as a source for input.

Today we will deal with the usage of operational data as input for process improvements. 

I’m talking about the data generated while executing the company’s processes, and not “product data”. I believe that this is one of the “untapped” or at least underestimated sources for input we have, as it’s already collected to a large extent, to manage the company’s day-to-day business.

IT is traditionally a service and infrastructure provider for the business-side of the company; giving them the tools to execute their work and make well founded decisions. But, what if we could use IT to also provide the means to turn the “eye” inwards in terms of methods? Providing that a PLM system doesn’t always force a process and way of working upon you (read: not controlled in detail by the system), there is potential work to be done to see how the stipulated methods are followed. What if we analyzed how work is done and thereby receive feedback on current working methods and potential areas for improvements or alignment to reality (does it look shiny enough?).

Data warehouse analysis related to PLM processes, that I’ve seen, usually has their focus in time, money, quality and risk. Sometimes you’ll find this type of analysis in dashboard in today’s PLM systems and other enterprise systems. But they are almost always used to support the operational aspect of the business. What if we looked at the list but with method improvement focus?

• Time – How many iterations does it take to get to a certain status in the development and what are the underlying reasons for it (communication, education, etc)?
• Money – are we selling to the right price in the different markets? Are we able to get our “raw material” to the right price? How is our sourcing affecting transportation cost?
• Quality – sustainable sourcing and material statistics, scrap- and recall-statistics
• Risk – are we placing our orders “right” to get the right risk exposure? How is our in-stock volume? Could we use more low fair transportation alternatives? How good are we at forecasting and thereby being able to book, buy and commit so that we get better in-price?

With the information that we get from the data; processes and practices could be followed up to see how they are adopted and applied by business. We could also analyze good performing teams, and thereby improve company methods and best practices.

We could even take this one step further – with tools such as dynaTrace we could analyze on application level what functions are being used and how to optimize the flow and usability within the specific application in a prioritized way.

The important point here is that we could get input for the PLM journey by looking at how the company is performing and acting in its current processes. Changes doesn’t always have to be revolutionary and ground breaking, in this case they are evolutionary. Derived from the knowledge we get by analyzing data.

This is definitely not science fiction. All technology is there to be used; it’s more a question of maturity and determination to use the data with long term strategic focus and not only making the coming quarter look good.

Robert Wallerblad
www.infuseit.com

PLM Success – Think Inside the Box

This blog will deal with two of the “shiny things” mentioned in PLM – Vision or micro-ambition? – Cross-Fertilization and Knowledge from within the organization.

Usually when talking about “thinking inside the box”, the message is simple - look within your own organization and you will find an untapped source for innovation.

But creating an entrepreneurial culture within a company resulting in innovation is a challenge, and it has primarily to do with people and less with tools. If outside forces don’t push for a change, it really requires strong leadership to create a culture which will make it happen (culture of innovation by Dilbert). Simply having ideas is not enough; you need to have a way of capturing, screening and executing upon the right ones. So the solution is to bring the knowledge of the employee and the means of the company together. According to a study, made by Accenture, 85% of ideas from employees have been focused on internal improvements, so there is a large potential.

More and more industries are forced to change their way of working, making it more focused on reuse, repeatability and knowledge sharing.  Even industries such as Plant Design, which traditionally look at themselves as one-off project oriented, are moving towards PLM. But looking for possibilities to reuse components, modules or products should not be the only goal. Processes, practices and tools should also be considered part of these initiatives. A colleague of mine, Bjørn Fidjeland, wrote a blog about it some time ago; PLM for Plant Design Project?

This takes us smoothly into another way to look at the “box”; look at it as the PLM domain and the untapped resource other industries. What could we learn from each other and how can we combine our knowledge? Or, in other words Cross-fertilization.

Getting inspiration from other industries is a low hanging fruit as both business concepts and new ways of tool utilization don’t have to be reinvented; they are just there ready to be discovered and utilized with minor adoptions to a new context. It’s an “easy” way to inject your practices with good ideas from others; basically adopting the old and proven concept of “steeling with pride”.

You don’t know what you don’t know so the challenge here is to interface with other industries.

An excellent example of the strength of cross-fertilization is Jack Andraka. With only his mind, the enthusiasm of a 15-year-old, YouTube, Google, Wikipedia, and some helping hands from “people in the business” he invented a new diagnostic test for pancreatic cancer. By connecting the dots, using his knowledge and others,  Andraka managed to create a test which according to him is 168 times faster, 1/26 000 as expensive (costing around three cents), over 400 times more sensitive than the current diagnostic tests, and only takes five minutes to run.

(If you want to see something that will make your day, please have a look at this clip of Jack winning the grand prize of the Intel International Science and Engineering Fair)

Just by looking at the headlines used to outline different take-aways from different industries, see picture below, there is a lot to learn.

And if we then, look at the challenges that the different industries are facing we will find a lot of touch points again, but dealt with in different ways - Market regulation, global and local sourcing, simulation, design collaboration, traceability, reuse of information/components/modules/products, … Isn’t it time to stop inventing the wheel?

Robert Wallerblad
www.infuseit.com

PLM – Vision or micro-ambition?

The journey itself is the goal, not the actual destination. A cliché, I know! But clichés are clichés because they contain some truth. You might have heard that people are often referring to PLM implementations as being a journey.  And I tend to agree.

I agree because I believe that implementing PLM is a spiral of continues change. In my view you are never done, there are always areas of improvements or completely new ones to discover and conquer. A grand vision is important to have, everybody will tell you that, and I will probably not be the first one to tell you that a big bang approach is neither preferred nor feasible in most scenarios.

Just as the first line of the blog states; I believe that there are great values in areas not necessarily tied directly to the envisioned goal. Areas that will emerge throughout the journey of implementing the PLM vision, as your knowledge expand in the domain and outside influences force itself upon your company.

The comedian and all round geniuses Tim Minchin expressed his thoughts around big dreams and goals in this speech in a way that I found also suitable for PLM. Below is a segment of it (if you have time, its 12 min well spent to listen to the complete speech):

“I never really had one of these big dreams. And so I advocate passionate dedication to the pursuit of short-term goals. Be micro-ambitious. Put your head down and work with pride on whatever is in front of you… you never know where you might end up. Just be aware that the next worthy pursuit will probably appear in your periphery. Which is why you should be careful of long-term dreams. If you focus too far in front of you, you won’t see the shiny thing out the corner of your eye.”

I believe that these “shiny things” are very important for PLM initiatives, as a complement to a vision, as it will allow the company to keep the momentum, strength, and passion and show the surrounding world (read: “non-believers” within your own organization) that one can be responsive and deliver value.

An incremental way to slice the “elephant” is often discussed when one debates how PLM goals should be “digested”, but this is something else. This is a piece of the strategy that embraces agility, as it will allow new input throughout the journey. It is also an approach that brings an evolutionary mindset to the table, as it pushes for enhancements based on the outcome of already implemented initiatives. Don’t see this as something that is less valuable than the big vision - the outcome of this could be as innovative as the big visionary goal but perhaps smaller in scale.

Another important reason to address these emerging needs is that, in most cases, if the business requires a change they will find a way to get it. In other words; solutions addressing the challenges will be built to support their daily work – May it be excel or db, silo or no silo.

So what are those “shiny things”, if we put it into PLM context, and where can we find them?

Here are five sources, which I believe we could use to air refuel your PLM initiative:

• Cross-Fertilization – get inspiration from how other industries and domains are doing things. What is it that they are good at? And then apply the well-known concept of “stealing with pride”.
• New Industry and Market “trends” – market situations and trends will push business to act in areas neglected before and allow for tools and processes to emerge or evolve.
• New Technology Opportunities – new technology, maturity and adoption will allow for new ways of doing things.
• Knowledge from within the organization – look within your own organization and you will find an untapped source of innovation in your own employees.
• Knowledge within the operational data that you produce – operational data that companies collect to manage their day-to-day business can also be used to get input for process and tool improvements, and not only focus on supporting the operational aspect of the business.

My intent is to elaborate further on some of the topics above to illustrate better how these sources can be used and how one can expect to benefit from them. Stay tuned for more details in coming blogs …

Robert Wallerblad
www.infuseit.com

Other blogs in this series are:

PLM Success – Think Inside the Box
PLM Success – Knowledge within the operational data that you produce

PLM failures - how to address them?

In my previous blog, I talked about why PLM often fails to reach its potential. Now I will look at how to address this. Is it possible to re-vitalize PLM if it has been stagnant for years? It might. Just ask Henry Ford.

These were some of the typical situations I discussed:

• Our PLM is just PDM
• PLM is just for Design/Engineering
• Management is not interested in PLM
• We have had it (PLM) for years and very little happens
• Our PLM system is hard to change and hard to upgrade

The last one – cemented solutions and challenging upgrades – I’ll save as a topic for later.

Should you rethink your PLM strategy?

You should ask yourself that question. If you have a limited PLM solution it might still be right for you. Maybe CAD management is the most crucial area to your business? Is it sufficient to handle parts, BOM, documents and controlling changes (PDM)? Yes, PLM have bigger potential but it comes with extra complexity and cost – if there is no business justification for expanding the scope of PLM, don’t do it.

If you believe that your business would benefit from a renewed focus on PLM, however, there are some steps you could take. Which steps, how to take them and whether you need to take them all depend on the size of the company, the business culture and your own position.

You might be fortunate enough to possess the necessary power and money to change things yourself. More likely, you’ll have to maneuver through several levels of management and surrounding departments where some of them don´t even have a clue of what PLM is all about.

To help you get started, here are some steps you can take to get PLM on the management agenda:

Get inspired
To get new ideas and to get other people start thinking about possibilities with PLM you probably need inspiration and facts. In other words: education and awareness. There are several ways to do that. This inspiration should be spread both upwards to management and downwards to users. Just be careful not to create too high expectations. Failure to meet new expectations will be devastating.

What are other companies doing? Maybe there are new solutions and approaches today than when you started 5-10 years ago? Get inspiration from others. Talk to companies that have done interesting things with PLM. Not only in your own industry. There is a lot to learn about new ways of doing things from industries that at first glance seem completely different. There is a reason why apparel, food and beverage or service companies have started to embrace PLM. They have taken PLM from discreet manufacturing and put their own flavor in it, focusing on additional areas, processes and functionality, which again can be of interest for other industries. This will be a topic in a future blog.

One tip is to challenge your PLM vendor. They would probably be more than happy to arrange a PLM inspiration day where they talk about all the exiting possibilities and what fantastic solutions other customers have implemented. The effort from your vendor is typically for free as they see potential new license sales somewhere in the future. Visiting PLM conferences and seminars is also a good place to listen to other’s PLM stories and establish new contacts. Even better: convince your manager to attend the conference as well – it could be an eye opener. Resources on the internet, including blogs and focused LinkedIn groups, have also developed into quite viral arenas for knowledge sharing on PLM related matters.

What is your PLM vision?
What should PLM bring to your company? Why should you invest even more in PLM? Which parts of the enterprise strategy can PLM support or even be mandatory for? It could be global internal collaboration ("Design Anywhere - Build Anywhere" or "One Company»). It could be reduction of non-conformance costs (One version of the truth). It could be simplified IT landscape (Replace local isolated tools with integrated enterprise PLM). The key here is to understand what is important for management and see if and how PLM can support that. An alternative approach could be: Pick a part of PLM that you believe in and figure out which part of the enterprise strategy it supports ;-).

Establish a PLM strategy
If you start to get some traction with management and they start to see some potential in PLM, you are in a good position. Use that position to get acceptance for establishing (or re-establishing) a PLM strategy. How to achieve the PLM vision? Which steps to take? What are the short term and long term goals & objectives? What main functionality and processes should PLM cover? Which roles and business units should use PLM? What information should be handled? Which systems should be integrated or replaced?

Build a solid business case
Earlier it was enough to justify PLM by showing functional capabilities. To convince management you must speak their language. And the language they most certainly understand is money. Build a business case with justified costs, earnings, ROI and the plan for how to get there at minimum risk. This is also a good test of your PLM vision. Can you provide enough facts and considerations to build a proper case? Maybe it will show you that you should spend your money elsewhere where it gives a better ROI?

For the business case to be accepted you anyway must get management believe in PLM and take ownership. Show them that you know what you are talking about, how it supports the enterprise strategy and that you know how to get there. You will need management support not only to get started, but also to be successful in reaching the objectives.

Enterprise PLM architecture
If the business case is accepted, you can continue to enterprise IT architecture where you go more in detail than in the PLM strategy. You position PLM in the IT landscape, main information flows, processes and functional areas. Which IT systems to integrate, replace, change or leave as-is.

Finally
Now you can start thinking about implementation. Note that the above activities are quite independent of which PLM tool you have. And it might not be your existing PLM tool that is the problem. Replacing it with another PLM tool will not help unless you do some re-thinking.

Depending on your position and the complexity of your company, this whole process can take a couple of weeks and a level of documentation that you can do yourself or it can take months or even years and a big team. You might be able to skip some of the steps. What you definitely should have is a PLM vision as inspiration and guiding star. Or you might end up unsuccessful again.

Tore Brathaug
www.infuseit.com

PLM – Tool or Mindset?

When we talk about PLM it very often ends up with an IT discussion. What tool is the best one or how much does the PLM system cost? Does OOTB (Out Of The Box) fit our processes?

The questions are valid, but in my view it is a very little part of a PLM project, and certainly not the ones to start with.

First: If you want to implement PLM, or re-implement for that matter,  You now have a golden opportunity to evaluate your product development processes and  Your business processes.  You should look at what they are like, and then ask: Is this process really the best one for you or is it a creation of boundaries from earlier systems or constraints? If it still is a good one, well implement it. If it is not, now is the time to make it better or evaluate OOTB processes from a PLM vendor. A bad process will not get better if it is implemented in PLM, it might only get faster.

Second: It is crucial to map the information flow to your processes. What information is available in what process and at what time. Is this optimal? Would it be better if some information is available earlier or if some information could be deferred until a later stage? The last one could be the difference between creating and maintaining a vast number of product variants up front or maintaining a generic product definition to support Configure To Order.

Third: Having the best IT solution in the world with first class processes and superb data quality will not help you one bit if the organization is not ready to embrace it. This is why PLM is often described as a journey, and in my view, it is. There is no way an organization can fathom a full blown PLM system with processes in one go. That’s why organizational roll-out and gradual maturing and rollout is essential in my view. This is also why it is very important to have sufficient support from management.

Fourth: At last we come to what is very often debated too early, namely the selection of PLM tool and vendor. My advice is that you select a tool that is able to adapt to your changing processes, because they will change, that the vendor has the bandwidth to support You and that he understands your business.

Conclusion: In my view the success of any PLM implementation is hugely dependent on a healthy overlap between processes, information, organization and IT-tool.

 In order for any organization to absorb and cope with the complexity it is useful to have a PLM strategy (think big).  After the grand thoughts are defined then start small with clearly defined areas that can be tested and rolled out in the organization. Now you have tested the internal processes needed for defining, migrating and deploying parts of your PLM system, so the time has come to start to scale faster to achieve the PLM strategy. Will it ever be finished? Well not until your company is finished…..