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

Why PLM often fails to reach its potential

Having worked with PLM for the last 17 years, I have seen many PLM implementations failing to fulfill the vision and potential. Why is that? And what are the typical circumstances we see in such cases? Maybe you recognize some of them in your organization? In this blog, I will focus on the bad cases and not the successful ones. The successful ones can be a topic for later. 

There are two main situations we see in the companies having trouble fulfilling the PLM vision. Either they were not able to meet the vision or they did not have the vision in the first place.

The companies with a vision usually had some visionaries aiming for the full PLM scope who were willing to fight for it, but it took too long and required more effort than anticipated. So, gradually they lost the steam. The reasons vary, but Machiavelli (1469 –1527) showed some insight to one of the main reasons: 

"There is nothing more difficult and dangerous than the establishment of a new order (PLM), as those promoting it will be fiercely attacked by those profiting from the old order, yet gaining only lukewarm support from those that will benefit from the new one."

On the other end of the scale we see several companies with a PLM system which came in the “back door” with their CAD system and consequently initiated by the design/engineering people. Many of those companies focused just on that: managing 3D CAD data and perhaps stretching it to PDM. Maybe the vendor sold in some bold ideas about what PLM could be in the future, but those were not adapted as a guiding star for the implementation. The long term PLM vision was not in place.

In both cases, there are some statements that we typically hear:

"Our PLM is just PDM"

Many companies are using their PLM system exclusively for PDM. Some companies even use PLM just for CAD management. In both cases they have an unfulfilled potential in PLM. Some people may see the potential and want to do more with the system, but are prevented by lack of funding to start on the journey towards more advanced PLM.

"PLM is just for Design/Engineering"

As a consequence of the above, the PLM tool is typically owned by the Design or Engineering department. In that case, PLM has ended up as a costly tool to manage their internal data and processes before delivering to surrounding systems or processes. Other departments are probably not interested in, or maybe even afraid of PLM. The processes and functionality is put in place for engineers with specific needs. The “engineering mindset” often leads to complex and user-hostile solutions and processes. You cannot easily expand such a solution to other people in the organization. For that, you need a much more simplified and possibly different solution.

"Management is not interested in PLM"

PLM is seen as a necessary evil for the engineers and something that only comes on the management agenda once a year during budget time and they see the costs for it. In this case management no longer has or maybe never has had a strategic plan and a vision for PLM. PLM has become a costly tool with limited benefits. The ones concerned and responsible for PLM have limited possibilities to do things as they lack management support to invest even more and other departments don’t see PLM as something that can help them.

"We have had it for years and very little happens"

Maybe there was a grand plan for PLM at some time, maybe not. The situation at many companies, however, is that they have had PLM for years. It has become cemented and very little happens. The wheels go round and the PLM tool and processes have become part of the everyday operation. Some see the need for a facelift or even some bold revolutions, but do not get the attention and funding to do so. Probably because of the situation described earlier.

"Our PLM system is hard to change and hard to upgrade"

Another reason for a cemented situation might be on a more technical level. The PLM system has over years grown in size and complexity. There are integrations with CAD, ERP and others. There are complex built-in processes and specialized functionality. The amount of data is huge. There are so many dependencies that it has become very hard to change it as no-one dares to touch the integrations, the processes, the functionality or the data, since it is very hard to overview all the consequences. An upgrade to a newer version that could revitalize the usage and open up for new possibilities is effectively prevented by the complexity and costs related to the upgrade.

What to do?

The situations described above are hard to get out of. You might end up thinking that the only way to solve the problem is to replacing the PLM tool with another one. This is very seldom the case. It is not the tools fault, it is how it has been implemented and used. Perhaps it is time to create an updated PLM strategy? Take the opportunity to reassess and analyze the needs to see what role PLM should have, based on current and future goals and challenges. PLM should not be seen merely as a tool to improve engineering efficiency. It should be seen as a means to achieve strategic business goals. For that you need management attention and a long-term vision.

Tore Brathaug

www.infuseit,com

PLM for plant design projects?

When I started out on my PLM (Product Lifecycle Management) journey more than a decade ago it was hard for me, coming originally from oil & gas, to understand the difference between  the functional decomposition (tag structure) used in multi-discipline plant design, and the EBOM (Engineering Bill Of Material) used in traditional manufacturing industry. It was easy however, to see the language differences and the fact that PLM focused on BOM and serial production

Having worked with PLM in different industries it is now clear for me that PLM can have a significant role in project-focused industries like in plant design projects. What PLM systems are really good at is creating a globally accessible information backbone, connect this information to processes and connect the processes to people to ensure that the right information is there at the right time so that people can take decisions based on the latest approved “version of the truth”.

Using a PLM system can give a lot of benefits over the traditional way of doing plant design projects, where information and experience tend to be locked in different information repositories and systems in each project. Each project has its own IT infrastructure and setup of tools, and it becomes very hard to reuse knowledge, processes and parts of the design from one project to the next.

If all design information was in a PLM system, an EPC could consolidate all the plant design disciplines, connect the design information as deliverables in the project plan and monitor the projects progress in real-time.  Change management processes could be enforced, design templates could be used, partial designs could be copied from one project to another, equipment requirements could be selected from a catalog and all of it across projects. These are just a few of the benefits that could be harvested.

So why has this not been done a long time ago?

Well, in my view there are two main factors.

One is that there have not been sufficient drivers to do so in the past. One of the primary drivers for changing from a project centric approach to an approach that promotes reuse, harmonization of processes and standardization is cost pressure and competition. We’ve seen this in every industry that has adopted PLM. It’s not until the margins really suffer that PLM gains any real traction. At the moment we see that as a result of the above mentioned factors, there is a growing interest in PLM among several large EPCs.

 The other factor is the actual design process and the tools used. They differ quite a lot between plant and product design.

The difference in process however is not the main challenge. There are several PLM systems that are flexible enough to allow such processes to be created.

The main challenge lies in the fact that in order for a PLM system to work effectively, all the design information must flow from the design tools into the PLM platform. Not many PLM systems today have good integrations to plant design tools, so hence it is difficult to leverage all the benefits that a PLM system could bring. In product design it is quite different, since almost all PLM systems have integrations to most product design tools.

So am I saying that PLM should not handle plant design projects?

Actually no, because there is one other development in the industry that has led to a golden opportunity to get all the needed information into PLM systems and start harvesting the benefits.

There has been a lot of pressure recent years especially from Owner/Operators to standardize information exchange between all the parts of the value chain. From Owner/Operator, through EPCs and  product companies.

The need to consolidate internal disciplines for the EPC, but also to communicate with outside parties like product companies and especially to support the big handover of information from EPC to Owner Operator after installation and commissioning has led to a lot of focus on standardizing information exchange. One such example is ISO 15926 and the preferred exchange format XMpLant. Most plant design authoring tools are claiming to support this standard today. In my view, this is the key to bringing all of the engineering information under process control in a PLM system. From here it can be shared with internal parties, but also to externals, like the Owner/Operator or product companies.

Essentially, this is killing two birds with one stone.

What is my conclusion?

PLM systems “out of the box” are not suited to support plant design projects. However, PLM systems are very much suited as a platform for consolidating plant design information and processes across all disciplines in a plant design project provided that they support information exchange in a standardized manner like with ISO 15926 and XMpLant.

Such a PLM system would solve two major headaches for the EPCs. Firstly, the internal consolidation and follow up of the internal disciplines, and secondly the ability to exchange information with other stakeholders in the project in a standardized manner.

Those PLM platforms that are capable of scaling well enough, support standardized information exchange and handle the sheer amount of information involved in handling multiple plant design projects could have a bright future in this domain.

Doing Things the Right Way?

In a previous blog, titled Doing the Right Thing, the question was if we would add value if we shifted focus from a processes centric approach when implementing a PLM tool. Today it's time to look at the other side of that coin - why would you want to focus on doing things the right way, or in other words being process centric? And to repeat - the main point here is not to dwell over the question if we need business processes or not, it’s about creating IT support for them in a PLM system, or not.

First of all let’s be frank; it's not necessarily the right way we are talking about, it's more a way; a way that has been chosen as the "right one". The criteria of being the right one could be many; what we know to be the best way at this point in time, a way prescribed by a standard or required to become compliant, or simply something that the stakeholder could agree upon.

So why would we want to implement processes into an IT tool?

• Compliance to different standards and regulations is a huge driving force. Being able to enforce and show auditors that you are following the directives prescribed by a authoring body is sometimes a good enough argument. Having change management, review processes, approval processes, follow-ups, document management, history records, etc supported by an IT tool makes life easier (even if your business isn't regulated), at least if you have the right IT support.
• Consolidate and unite companies/subsidiaries/sites/etc in their way of working it's quite often a requirement for initiatives such as joint manufacturing facilities, sourcing, procurement, eCommerce, PIM, or effective after-market support. But I would dare to say that in most cases it's more about securing the data rather than the processes. Call the cards, and you will probably find that besides the initiatives listed above the motive could be found among the softer aspects of implementing IT support for a process - unification across borders through enforcement, thereby creating the notion of one company.
• Complex development processes which require consolidation and exchange of information across multiple disciplines and organizations will also have a great benefit of harmonizing data and processes using a system to support their tasks.
• Scalable "know how" as it's captured in the tool allowing it to guide people in their work. Phase-in of new employees will thereby be easier if there is process support guiding and enforcing the user in the way they should work.
• Improve and enforce quality as you get control and are able to guide users through the companies working procedures
• Automatisation of process steps will become much easier as we have a repetitive flow of events

So as you can see; there is no "That is the question" in Hamlets monolog. It all depends. There are basically advantages of both approaches. And that is how it is; depending on your needs (some could perhaps be more justified than others ;) you could see the advantages of getting a PLM system to support your processes. But don't take it as something that you have to do! If you start using the approach from the previous post as a "reflex standpoint" - don't tie down your IT system with intricate rules to support an ever-changing process, then I bet you will get a better Total Cost of Ownership (TCO) at the end and a happier customer (the end user).

Robert Wallerblad

www.infuseit.com

Doing the Right Thing?



This post is inspired by a definition found in the comments which followed Oleg's post and a discussion with a friend of mine who is PLM responsible at a small car manufacturing company.

First, let's apply the definition of processes and practices, that Michael Grieves use:

“Processes are well defined routines that give organizations the outcomes they desire. However, a great deal of what companies do, such as innovation, is driven by a desired end result, which is what practices are all about. “

You could also rephrase this to "processes are about doing things the right way”; dictating how work should be done. Focusing on the what instead, we would allow decisions by knowledged workers and IT automation determine much of the how.   

To generalize, traditional PLM implementations are focused on data capturing and processes (according to the above definition). Capturing data in a common repository enables transparency, access and being able to connect the dots (data) in new ways. Usually, we then cover the data with a process layer, targeted for effective and repetitive management of that data. 

But what if we would focus on supporting “doing the right thing” instead? What would that mean? For me, that would mean focusing our effort on data, functions to manipulate, communicate and collaborate around it. Another critical role for a PLM tool would be to have capabilities to analyze that data, helping workers make informed decisions which would allow them to “do the right thing”.  

Are we on to something? What about "best practice" processes? Could we say that we can deliver value without them? Can we do this without being banged in the head by sales and marketing saying that we can't sell without a out of the box process support?

What if we state that "best practices" are on data level, basically how we choose to model the reality in a smart way? But to not become a consolidating integration hub, we would have to have tools to manage that data accordingly. With decoupled features we then address "best practices" of managing data without "tying it down" with processes.

To not "just" become a good data management tool we would need to wrap the whole thing with communication and analytic capabilities allowing the user to collaborate and making “the right” decisions.

What would we have then?

- A replacement to mail, excel and other data silos, which was exactly the thing that my friend at the car company was asking for; a tool which would allow him to still have the required flexibility but with transparency and the synergy of previously disconnected data sets. This would give him the means to reach the desired result in a perhaps unstructured way but secured via data and supported through communication and visual analytics. Wouldn't that add value? Wouldn’t that create an innovation pull as we then focus on "doing the right thing" rather than paving complicated cow paths?

Robert Wallerblad

www.infuseit.com