PLM and Document Management Systems (DMS)

PLM tools have document management functionality. Does that mean that your PLM tool can and should cover general document management needs in your company? Should it handle ALL product related documentation or just the CAD files?

If you already have or are about to implement a PLM tool you might consider using it for general document management, not only management of strictly product related documentation. Is that a wise way to go? Or should you use a common Document Management System (DMS) instead? I will shed some light on the areas you should consider in such situations.

I agree with the Virtual Dutchman that a data centric approach instead of documents is the right way to go. But for the time being there will still be a few documents around.

Document Management in PLM

Document Management functionality in PLM (or PDM) is focused on structure and control. In PLM you gather product related documentation in one place, put it in a product context under formal control. The primary documentation is documentation that defines the product from a design or manufacturing perspective.

PLM tools typically focus on advanced document management functionality for expert users. Some examples:

• Formal review and approval processes
• Rigid change management principles
• Automatic conversion to PDF with stamping
• Strictly defined document types with metadata and other behaviour
• Strong mechanisms for access control
• Integration to authoring tools to manage drawings

The documents are put into context and their behaviour is depending on the context. E.g. You cannot change a document unless the part is open for change.

You end up with an advanced and complex functionality to reach the level of control you need. An example can be complying with FDA regulations in the medical industry. Engineers can live fine with such solutions, but it is harder for other people managing large volumes of general documentation.

What you typically don’t get is easy-to-use and flexible document management for general documentation. The processes and functionality is often too specific and far from user-friendly enough.

Too often we also see that the PLM solution has ended up as an archive solution and not the working tool it was supposed to be. The users start on and work on their documents on file folders until they are approved and “must” be put into PLM for control and tracking purposes. The result is that a document can be found several places. On the file server (probably several different places), in your mail system and in the PLM solution.

Document Management in DMS

DMS come in many different shapes and colours. Some of them are highly specialized for a specific purpose or industry while others are more generic and focuses on general document management. I focus on the last group here. An example is Sharepoint for document management.

DMS typically focuses on large user groups with various needs for document management. Some examples:

• Easy creation and update of a new document
• Smooth collaboration around documents
• Flexibility to handle any kind of document
• Flexibility to define your own processes, document types and metadata

You can handle any kind of document as single documents that live their lives independent of context.

You get a solution that is generic and flexible. You can extend to support certain domains. The focus is on replacing file folders with something that is easy to use and yet gives more collaboration possibilities and more control.

What you typically don’t get is the possibility for functionality that requires that the document is put into a certain context. It is not recommended to replicate the PLM functionality with for example change processes with dependencies to the status of the product.

You can of course add advanced functionality and many solutions are very rich in functionality. If you already have a PLM solution you should be careful of introducing a complex DMS.

Positioning PLM with DMS

If you take requirement for requirement for document management you will see that a PLM solution on paper probably can cover all document management in your company. In reality this is not true. I have yet to see a PLM solution successfully being used for all document management in a company (if you have more than 50 users). It is not easy enough to use and lacks flexibility.

DMS cannot cover the PLM document management needs. It lacks the product context capability.

In my view PLM and DMS has different profiles, approaches, focus, content and audience. If you have PLM needs it is not recommended to try to manage that in DMS. And vice versa: It is not recommended to use PLM for the general audience and documents that are not related to the product somehow. You will be better off having both. See also this blog at Beyond PLM.

The question is how to define the roles of PLM and DMS in such a way that the boundaries are clear. You do not want users to wonder where to put a document or where to look for it. You should have easy-to-understand guidelines for PLM and DMS. One simplified approach can be:

• PLM for all product related documentation and for documentation that requires formal configuration management (change control) - Streamline PLM for this and do not attempt easy management of large volumes of general documents
• DMS for all other documentation - Streamline DMS for easy management and collaboration and get rid of your file servers. Leave the complex context related functions to PLM

What you should have is a clear strategy for both. What is the role for PLM and DMS? What do you do in each and not least: What do you not do? Try to have as little overlap as possible. Both in terms of what documents and users you target. As well as what functionality and processes you cover.

Summary

PLM and DMS has complementary roles. They fill different purposes and in most cases should not replace the other. Try to find clear boundaries and have an overall strategy for document management that covers both. The strategy must be easy to understand to avoid unclear roles and usage. PLM and DMS together should make it possible to turn off your file folders.

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

Can a true PLM initiative be decentralized?

In a previous blog I was looking for the PLM expert. The conclusion was that implementing PLM is a team effort (which is perhaps not a surprise), as a PLM implementation includes process, tool and organizational aspects. The executing team should possess knowledge within the customers’ business, the targeted domain, and available technology. Strengthened by having a reference group working in the day-to-day business and the support of management.

But we didn’t address the question on which level this “body of expertise” should act. Where should this organization reside, and what mandate should it have?

In short: what would the impact be of having a centralized or decentralized ownership of PLM?

A Decentralized PLM Ownership

From a process and method point-of-view you could probably find reasons to actually move the responsibility from the corporate level and allow local flexibility:

• Risk management through diversification, which would allow business units to try out things which could then benefit others in the organization
• Ownership of your own working methods would potentially allow easier change management
• Less compromises in the way you work and the tools you use in your daily work would probably generate less friction
• Closer to the immediate challenges will allow the organization to be more agile and finding solutions to emerging threats, opportunities and trends

Okay, so there might be good things with decentralized processes and methods. But let’s have a look at what a decentralized PLM (both process and tool) does to some of the (old) core values of P L M:

• Manage Information - Manage data and processes
• Find Information - Search, where used/referenced, process status
• Share Information - Real-time collaboration. Information attached to workflow

Doesn’t a “local” PLM system contradict with those values? I assume it has to do with your definition of local. If it is a site with 5000 employees does it have to be integrated with the rest of the company? It all depends on the business.

But let’s flip the coin completely and look at some more challenges you might find in an environment which has a decentralized PLM ownership:

• No one will be responsible for thinking horizontally and aligning the company across departments and across functions/disciplines
• Each department is measured and rewarded by their own results, blocking a strategic change as this requires an investment
• Hard to have job-rotation and change staff as the processes, working methods and tools differ
• More costly to have an effective tool support as it’s not consolidated
• Less efficiency further down the chain or even loss of opportunities and inability to execute on initiatives completely. In many cases the lack of a common way of doing things is hurtfully exposed once you have a need of unified processes and information at one end while having a diversified way of working and/or structuring and storing information at the other. It works as long as you don’t think of others … Typical initiatives and areas which will put their demands on what and the way information is delivered are: business analytics, procurement, manufacturing, e-commerce, and aftermarket.
• In many cases (to my experience) a decentralized ownership means more “let’s just make it work” which means that the experienced employees will have a way of dealing with things but the new ones will have to “find their way”. Is that really making things smooth and efficient?

Decentralized Processes and Methods but Consolidated PLM Tool(s)

Providing that you believe in decentralized processes and methods but also in the need for a consolidated application support for effective distribution of information you might avoid some of the bullets above. And looking at the core PLM values stated above; “only” the process part might not be accomplished.

The concept of self-organizing teams is not new. It is a great part of the agile software development movement. Isn’t this what we would talk about when we put PLM in a decentralized process environment but with consolidated tools and information, having common PLM tool(s) orchestrate these “teams” to deliver information and use tools in an uniting way?

In such an environment process support might be hard to implement within the commonly used tools, which might not always be a bad thing. Having processes tightly implemented into the IT tools assume a deterministic look at the world, but as we all know the world and the way we work is an ever changing parameter. So this could actually trigger a healthy look at how you architect and build your tool support as it will require modularization and flexibility.

The trap which you might fall into is that the consolidating system will become the “scapegoat” as it will have to unite and be a compromise from an end-user point of view. Also, many regulated businesses don’t have this option. To unite under one proven and compliant process is a matter of necessity and survival for these companies.

Decentralized PDM and Consolidated PLM

A trend we see at large companies is that they move away from one enterprise PLM solution covering everything. We see several examples of local PDM solutions allowing local flexibility feeding an enterprise PLM which has information and processes harmonized, but on a higher and more generic level.

Processes and ”how to do things” (methods or practices if you will) are not the same, and to be able to deliver and consolidate information in a coherent and consistent way “the way you do things” might very well have to be aligned as well. An example of an area which requires this thinking is CAD / CAM. In other words it’s important to understand if you have these type dependency so that you act accordingly in your decentralized PDM environment.

Using a PDM tool closer to the authoring tools will often result in better connection and less translation issues and richer details as a result. But keeping the innovation loops within PDM and consolidate in PLM cements the functional silo as it delays the point in which a cross functional view can be “visualized”.

Conclusion

As I can see it you actually don’t need to centralize everything under the PLM “umbrella”. This is of course a bit depending on your type of business.

Processes and methods should be carefully implemented. You could reap a great deal of benefits by aligning and consolidating tools and information across the enterprise and still allow processes to be more autonomous in nature. One trick is to implement the processes on the right / high enough level (in the applications) which would allow people to work within it, while still keeping important flexibility and agility in the tool. It is important to keep a clear distinction between processes and methods so that you consciously decide what it is that you want the tool to support and what you keep outside it, as this will allow you to adjust the way you work to temporary situations and differences in business models, while still delivering and using commonly structured information and tools.

Are you convinced that one approach is better than the other? What’s your view on this?

Robert Wallerblad
www.infuseit.com

The PLM-user Pitch

The PLM system pitch and the related discussions is almost always focused on the decision makers - how should you convince the management to buy, and how should you show that you provide value with your implementation?

The topic is most often focused on the disconnect between IT and Business and how to bridge the gap.

It’s of course an important topic but today we will look at it from another angle.

There is another void to fill and that is the one between the benefit of the enterprise and the actual user of the system.

Neither vendors nor the companies looking for PLM systems have (enough of) this in focus. There is a functional focus, I can agree on that, but that is not necessarily the same thing as a user oriented PLM focus. It’s more about having a checklist to see that an application can fulfill the functional requirements, which is not really the same as having the user in the center.

So what would happen if we would focus on the users? Because once bought, a system such as PLM is not only good for the business as a whole, it is also intended to help users in their everyday work.

Tools and processes for the greater good

An enterprise tool is often emphasized as the tool which should support the complete company’s need and not necessarily the individual. We focus on overall process/information improvement and harmonization and not the end-users tasks and daily work.

A company oriented pitch is also often more future oriented, than what you would like to phrase it to an end-user. The employees are more focused on the present and solving the challenges of today. That’s where our pitch should be focused – the present and what it means for the individual.

An individual productivity tool

If you take the scope of PDM, you should be able to pitch the actual idea to make it about enabling the individual; making it easier to find the right information, enabling earlier transparency as well as collaboration. For complex data sets and/or tasks it will help out in keeping data integrity, and dependencies thereby offloading the workers from otherwise tedious and error prone tasks.

But unfortunately there are challenges with this pitch:

• The end user and the way they want a system to behave and support them in their daily work is diversified. What makes a good fit for one will not necessarily fit others. Basically I don’t believe that there is a “Heinz ketchup of PLM”, fitting all tastes. I rather believe that the need is as diverse as the salsas that you can buy in your local supermarket.
• If we talk about PDM systems - functions associated with PDM comes with quite a heavy baggage in terms of old system behavior which has not always been perceived as enabling. A shift in technology and the ability to work more seamlessly will most likely help out in making PDM applications less of a struggle in the future.

A Tool for Knowledge

The productivity pitch will not get that much traction if your PLM system is used to “only” specify your products once you have developed them, instead of being develop within it. Unfortunately this (mis)usage is not as uncommon as you might think. In many cases putting things into the system is an administrative task at the end of what one consider value adding activities, and this really undermines the individual’s perception of having the system support her needs.

But, independent of scenario you would probably gain one thing and that is a knowledge bank. The system will create transparency which would benefit the individual, as searchable and structured information will allow for higher productivity second time around.

This transparency will also benefit the people further down the chain. The earlier you manage to accomplish it the more power you will get of it, and it’s also an opportunity for business intelligence to analyze trends earlier which again could be used as a pitch for certain end users or consumers of information.

Democratization

By sharing knowledge we will enable decentralizing and distribution of tasks. Technology will enable this. Because by systemizing knowledge we can put it in the hands of “anyone”.

Think about simulation which previously was something that only highly specialized people worked with. Today software is taken the first hit through checking the output of the individuals work before integrating it with the rest of whatever solution one is working on. All domains have it; software, hardware, mechanical design, electronics, etc. And some will take the step to create mockups which brings multiple disciplines together.

There will always be a place for specialized skills but the frontier is and will continue to move as we manage to systemize knowledge. And this should appeal to the expert as it will allow her to focus on things which are less bread and butter, at the same time as it gives the non-expert more confidence in the output she produces.

A trendy phenomena is Internet of Things; think what we can do with data collected from products in the field and once we systemize that knowledge. How will that translate into the way we design our products or conduct or service and maintenance business? Once that data is cracked it can be used as BI put into the hands of the individual.

Could this bottom-up approach result in benefits on company level (for “the greater good”)?

Could we flip this around to make it about the company, and what is best for it? Of course we could. Thinking about and addressing the needs of the individual will at the end find its way to the bottom line, resulting in better overall quality, better flows, higher productivity, higher data quality, etc.

Conclusion

IT and PLM should not be seen as a support function next to the core business – your PLM processes is actually part of your business. In many companies today it is therefore within your PLM systems that you conduct your business. If we embrace that fact, the focus can’t always be on the benefits on company level, the day-to-day work has to find its way to the PLM pitch.

Robert Wallerblad

www.infuseit.com

Variant management in engineer-to-order?

Many products come in a lot of different variants, for equally many different reasons. Growth in variance can be a big challenge, in the virtual world, as well as the physical world. Taking a structured approach to variant management can help you get back in control – if you do it right.


First of all: variant management is not equal to product configuration (even if it is a closely related topic which may very well be part of a variant management solution). Also, the solution for variant management might look very different depending on type of product and type of industry: Is it a highly industrialized product, like a car, where all variants are made from a finite set of standardized modules? Or, is it a complex, low volume product, where new variants are created “on-the-fly”, based on customer requirements?

Many industrial companies are in the latter category, supplying highly advanced products to demanding customers in industries like oil & gas, aerospace & defense and health care. Common to all of these are that they typically come from a very project oriented mode of working, which is reflected in the way they are organized and how information is managed. They do talk about products, they do have product catalogues, but every delivery of a product is organized as a project, which typically includes a substantial engineering effort. The product information tends to be treated as project specific, even if the major part stays unchanged between each delivery project. Reuse between projects is frequently done by copying rather than referencing, resulting in massive duplication of documentation as well as part numbers.

The economy of scale

Variant management in high volume manufacturing is driven by a desire to cover a wide variety of customer preferences with a limited number of products. This has resulted in products that are configurable by the end customer, as part of the ordering process. The emergence of product platforms has brought this concept further, allowing a large number of models to be derived from a common technical platform. One of the latest developments in automotive is "scalable platforms", from which car models of almost any size can be derived, with VW and Volvo as early movers with their MQB and SPA platforms respectively. It is no secret that these initiatives are huge investments, but both manufacturers expect to gain a significant competitive advantage through the economy of scale for shared components and modules, as well as shortened development cycles for future models.

For low volume products, where the typical mode of operation is engineer-to-order (ETO), variant management is not needed as an enabler to provide a larger number of variants, as each delivered product is anyway tailored to satisfy the requirements of each individual customer. Rather, variant management should be seen an approach to rationalize the way products are delivered, while maintaining the competitive advantage of being flexible towards the customer. The economy of scale is still a valid motivation for improved variant management, as far too many activities end up as a redundant effort, repeated in every single delivery project.

Where to start and what to do?

Although the streamlined configure-to-order (CTO) process of the automotive industry might be out of reach when you are dealing with low volume products, there are still many concepts which can be applied, if you are in the ETO-business.

First of all, you need to step back and take a look at your business model and strategy: are you aiming at speeding up your current delivery process, or are you looking for new ways to design and deliver your products? There might very well be a potential in automating repetitive tasks in the engineering process, employing for instance parameterized CAD-models to speed up drawing generation and CNC-preparation. In many cases, however, there is a much greater potential to be gained from avoiding repetitive tasks, rather than automating them. This is where modularization and product platform thinking can be of help. If most variants of a product can be made from a limited number of standardized modules, there are huge benefits to be harvested all along the product lifecycle, far beyond the engineering department. A few examples:

• It is easier to predict the cost of the complete product, when the cost of each individual module is known from experience.
• Component and material cost will be reduced when enabling the procurement to order larger volumes, gaining lower prices from suppliers. Better predictability for expensive, long lead items is another advantage.
• Quality cost is reduced, as each module has a standardized set of design documents, which can be improved over time.
• Production processes can be industrialized and optimized to a much larger extent, as the number of identical items increase.

Some companies might object that customer requirements will still force them to deliver unique products (and documentation) every time. This may be true today, but will it still be true if the customer was confronted with the choice of a standard product and a custom product at twice the price? Certain types of products are custom by nature, because of the surrounding environment. It would still make sense to standardize what can be standardized to reduce the engineering effort in the delivery process, saving time and money.

Success criteria

To succeed with variant management in a project oriented environment, it is critical that the organization is set up to properly manage the standardized building blocks, and that the information management systems in use support the new way of working. Most PDM and PLM systems have specific functionality for variant management, as well as the required support for engineering change management across projects. The single most important criterion, still, is to establish a dedicated organization for product management with sufficient funding to develop and maintain the standard product definition, to ensure that it is complete and up to date. Otherwise, there is a high probability that the project engineers will continue managing variants as they have always done: using "Save As".

Johannes Storvik
www.infuseit.com

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