IIoT, Small Data and PLM

Big Data and Internet of things is big (sorry about the pun). There is a lot of promise of golden opportunities and discussions on how to get to smart connected products and opening up new business opportunities. And a lot of anxiety among many smaller companies wondering how to approach this. A pragmatic approach and easier start can be small data within industrial IoT (IIoT).

Big Data and full blown IoT can be too intimidating and a too big step for smaller companies. Yet it is possible for them to enter the race without too high investment.

I am assuming that a PLM backbone with all product data is in place. PLM in context of IoT has been mentioned by for instance Beyond PLM and the Virtual Dutchman. There is also an excellent paper from HarvardBusiness School.

The companies that will have the easiest path here is the business to business companies that delivers physical products that are used by another company in a larger system of products. E.g. a conveyor belt that goes into a larger material transportation system. You have control of the conveyor belt while your customer manages the whole transportation system. If your conveyor belt can be a smart connected product we have IIoT.

A large portion of Big Data is unstructured information that you do not know clearly what you will use it for when you design your product. Small data is instead logical additional data sets that you define up front, you know how it is related to other information and you know what the purpose is.

“Small data connects people with timely, meaningful insights (derived from big data and/or “local” sources), organized and packaged – often visually – to be accessible, understandable, and actionable for everyday tasks”

Making a “dumb” product into a slightly smart connected product can give you very powerful information. Define up front what (small) data you want and how to manage it. You can limit the IT infrastructure investment since the amount of data is limited and as a manufacturing company you probably have an IT infrastructure that can manage the additional data. And it is quite easy to know how to relate the information to other information sources. As the small data can be well defined and structured it can easily be combined with your existing well defined and structured data. The typical information sources will be CRM, ERP and PLM. You can combine your new (small) data with your existing product data sources. This can give you new insights.

Aspects that makes IIoT and Small Data attractive

• Sensors are smaller, cheaper and more flexible than just a few years back
• As the data amount is limited it is manageable
• You have a strong product information backbone in place in PLM and/or ERP
• The small data and how it must be related to other enterprise data to give meaning is defined up front. You don’t need advanced analytics tools or experts.

Taking the conveyor belt as an example. Take your existing product and how it is delivered and operated and serviced. Think about: What business benefit do you want if you could get anything from your product in use at your customer? Is it possible to get that data somehow? Then decide what you want to achieve, what data you need and how to get it.

What do you want to achieve?

• Improved service margin – you can do better and more accurate service since you have better insights. Perhaps selling more spare parts.
• You can provide improved operational efficiency for the customer as you can optimize the usage based on the data feedback.
• You can sell a service instead of a product. E.g. you promise a certain output in a certain time period. And you make it happen.
• You can improve the customer experience with new automated functions, remote control or better interaction with other equipment.

Decide up front and design your product accordingly and extend your IT infrastructure to support this. It is still not done by itself, but taking small steps instead of diving into Big Data at once is perhaps more appealing.

Engineering.com has an interesting article about using PLM and IoT in an old industry to create new business opportunities.

Summary

The key is understanding your product, how it is used by your customer and what additional data that could give you an advantage. You have a lot of valuable data already and it can become much more valuable if you add some smart small data on top of it. Use the data and the IT infrastructure you have, add some sensors and connectors and get started.

Tore Brathaug

www.infuseit.com

PLM and PIM – what’s the difference?

Product Information Management (PIM) and Product Lifecycle Management (PLM) must surely be something similar. Yes and no. There are similarities, overlaps and they can complement each other. At the same time there are clear distinctions and you will probably need both.

Similarities and differences

From Wikipedia:

“PIM refers to processes and technologies focused on centrally managing information about products, with a focus on the data required to market and sell the products through one or more distribution channels”

“PLM is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products”

Interestingly they say similar things. At least the product information is in focus. It can also seem from this definition that PIM covers a hole in the PLM processes. PLM jumps from Manufacture to Service. PIM covers what is in between – Sales and Marketing. This should be a perfect match as has been discussed by Tech-Clarity.

ERP is also highly relevant in this context. In some industries also CRM. The picture below explains some of the differences between PLM, ERP and PIM.

Positioning of PIM

When we look at the purpose of PIM we understand the difference better. PIM is focused on providing accurate and good quality sales and marketing information to various sales and marketing channels. Today this is often done manually or semi-automatic for each different channel. The objective is to gather all relevant sales and marketing material in one place and publish it in a controlled and efficient manner.

PLM/ERP feeds PIM

The best approach is to take product information that is controlled and released somewhere else (PLM or ERP typically) and enrich the products with additional information (such as images, video etc) and publish to different channels and markets. Which channels to publish to is controlled in PIM. Which markets to publish to might come from PLM or ERP or can be defined in PIM. The best flow is when PIM can trust that the products and their information is valid at the point it enters PIM and PIM can focus on enrichment and publishing. One reason for this is that PIM is typically poor on revisioning and approval control.

Change and status control in PIM is typically done by using catalogues to show status and control what you can do with the data. An example is shown above. Someone or something pushes the data over to another catalogue. In that catalogue it is defined what you can and cannot do on a general level. The access is not product by product, but more often market by market. PIM works typically on the latest released product information.

Can PIM replace PLM or vice versa?

I have heard PLM people saying that as PLM has most of the product information already; why not extend the data model and processes to also cover PIM? PLM is quite flexible and can be integrated for example to a web portal for product catalogues. Why not?

PLM and PIM are both focused on product information. At the same time they have very different strengths and capabilities. It is better to utilize those differences than trying to build missing functionality in PLM or PIM.

PLM is not good at the marketing side of product information. Like creating print material or publishing to various sales and marketing channels. PLM is focused on detailed control needed by engineers.

PIM on the other hand has ready-made mechanisms for print materials and publishing to different markets and channels. And it has sufficient change control from a sales and marketing point of view. On the other hand PIM is no good at detailed change control, revisioning and management of design data.

Focus from a PLM perspective

Look at the product information from start to end. Where is it born and where is it used? What you have to focus on is ensuring that the product information is structured in such a way that you CAN use it for other purposes than just a design point of view. E.g. if you need grouping of products in PIM; perhaps use the same grouping in PLM. Ensure that you have sufficient information. You might want to add more information early on to be able to streamline processes and information flow. E.g. In which countries can you sell a product?

The success of PIM will be greatly enhanced if you tie the whole information flow together. From design to procurement and manufacturing to marketing and sales and to service. You will be able to re-use information from PLM and give it additional value.

Summary

PIM plugs a hole in the product lifecycle that PLM should not. From a true lifecycle perspective it makes perfect sense to integrate PLM and PIM. They complement each other well and you get even more value out from your structured data in PLM.

Do not try to extend a PLM system to also cover PIM functionality. PLM systems are complex enough as they are.

Tore Brathaug

www.infuseit.com

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

Change before you have to...!

It is no longer enough to improve what you have. You have to be innovative both when it comes to your product offering and how you do business. So how does PLM fit into this?

The Innovation Evangelista

“Optimizing business processes and products has been the way to improve margins, and companies and managers are fairly good at making this by improving efficiency and productivity.

Nowadays change has to be done through innovation to create new business value on corporate level.

If you look at companies today and their ambitious goals, and you break down these goals to what you need to achieve you will find that in many places it’s not enough to optimize the current setup of the business. To achieve the goals, you need to make business innovation part of the strategy on corporate level.

Optimizing already made investments will look like a safe bet. But it will not be enough to ensure that you will meet your strategic goals. It has to be the top managers business to make the company shift focus from optimizing resources to change management and business and product innovation, and to find a healthier balance between optimization and innovation to meet the world of today.

There was a time when change within a company was gradual and that you could take them step-by-step within the boundaries of a department. This is not the case anymore…”

The Digital Transformer Evangelista

“IT transformation must be on the managements agenda and seen as an enterprise initiative.

Both simplification and focus is required to deliver the flexibility that digitalization is aiming to achieve. Without it you will lose important business agility.

Digital transformation will also allow you to scale your business as well as experiment on large scale through the usage of feedback enabled by Internet of things and big data analytics. 

You need to proactively invest in technology and people, as well as being aware of startups and what is going on. 

Make sure to stop fueling “shadow IT” initiatives. This will allow you to push resources towards initiatives which move your organization in the direction stated by your transformation strategy.”

So what's this have to do with PLM?

You might have heard all this before and it’s perhaps not new to you but how does it relate to PLM?

I will not go into product innovation strategies and the different trends that you ought to explore because you probably know better than I what is disrupting and trending in your particular business.

Instead we will focus on the affect it has on the way one should mold a PLM system landscape and its strategies?

• Modularize your application(s) so that it can be seen more as a set of capabilities, giving you a healthy flexibility through well-defined interfaces
• Make sure to implement processes and practices on the right level so that you don’t get limited by it (blog)
• Make sure that the challenges are on the managers agenda and that your PLM strategies are on enterprise level; giving you the mandate and the right focus (blog)
• Make sure to have focus on enabling collaboration and feedback loops
• Focus on the consumers of information by making your data available
• Keep benchmarking your business, processes and tool support. Get inspired by others within and outside your industries as well as the consumer world (blog)
• Make sure to use the right technology; suiting your purpose and your path ahead. You need to be aware of disruption and evolution in technology as this can enable your future journey
• Have operational analytics feeding back to your product lifecycle processes (development, procurement, manufacturing, logistics, service), allowing users to make well founded decisions (blog) as well as improving the way you work (blog)
• Make sure that information about your product in the field are fed back to you. Knowing how your products are used is an excellent source for further innovation. You need to have an ear to the ground to listen to what the consumers are saying and doing with your products.
• Have your organization setup for continuous business improvements, and make sure that this is reflected in your processes and tools. 
• Implementing PLM is not a one-time thing. It is something that should be a continuous development independent if you look at it as a tool, process or mindset. It’s a journey! (blog)

Summary

Recognizing the bullets? Once again the stars are pointing us towards the same direction. Only this time they are called innovation and digitalization.

Can’t remember who kicked the dust of this quote by Jack Welch, but I read it recently and for me it resonates well with what we need to have in mind at all time when we embark on the PLM journey because that is the reality of today:

“Change before you have to...”

If you understand that the business you support is dictated by this, you will be better suited to make the PLM system something that actually supports the business without holding you back and allowing you to take on new business opportunities. PLM systems should be flexible to adjust to business changes. Too often systems are cementing the current way of working. Instead they should be managed with continuous change in mind – both processes and IT tools.

Robert Wallerblad

www.infuseit.com

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

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