When Every System Has an Owner, Who Owns the Relations Between Them?

In the previous blog, More Enterprise Systems. More PLM Integrations. That’s Not the Problem, we discussed about why a growing number of PLM integrations is not necessarily a sign that something has gone wrong. As companies become more digital, more systems need access to product data, and the integration landscape naturally grows with them. The real challenge is making those connections manageable as the business changes.

But there is another question that comes after that. Once PLM, ERP, manufacturing, quality, service and other systems are connected, who is actually responsible for the information that flows across those systems?  That is where the discussion about the digital thread starts to become more interesting.

In most PLM projects, finding the owner of a system is not very difficult. There is usually a team responsible for PLM, another team looking after ERP, and separate people responsible for manufacturing, quality, service, requirements or software tools. If something stops working inside one of those systems, people normally know where to go.

Things become less clear or challenging when the problem is not inside one system, but somewhere between two or three of them. A company can have good system ownership and still have a weak digital thread.

Each System ownership is clear. The Digital Thread ownership is not.

In an organization structure, teams are usually responsible for business processes and applications within their own area. Engineering makes sure the engineering information is correct. ERP teams focus on material data, purchasing, planning and finance. Manufacturing teams’ responsibility is to ensure production information is available where it is needed. Service responsible teams manage their own processes and records.

There is nothing wrong with this setup. Each area needs people who understand the details and can make decisions about the systems they use. However. the real problem starts when a business question crosses a specific system’s boundary.

A component is released in PLM and sent to ERP. Later the same component becomes part of a manufactured product. A few years after that, there may be a service problem in the field. At that point, the company may want to know which engineering change introduced the component, why the change was made, which product variants used it, which tests were completed before release and which customers received products containing that configuration.

These questions don’t belong completely to one department. The weakness only becomes visible when somebody asks a question that needs information from more than one place.

This is normally seen in perspective integration discussions. A lot of attention goes into making sure that a released part is transferred correctly from PLM to ERP. The cross functional teams agree on the fields that need to move. Part number, revision, description, unit of measure and other properties are mapped. The interface is tested and the transfer works.

It ends up in a successful integration, but it does not automatically mean that the digital thread is complete. The data moved correctly. The context did not.

A digital thread is not only about moving information from one application to another. It is also about keeping enough of the relationship between pieces of information so that someone can understand the product later.

This becomes more important as products become more complex. A mechanical product may now include electronics, software, configuration rules and connected services. A requirement change can affect several other areas at the same time. If the  relationships are not properly maintained, the team may still have all the individual records but no easy way to understand how they belong together.

Integration IT teams cannot own the business meaning

Because weaving a digital thread across an organization involves several applications, it is tempting to treat it mainly as an IT or integration responsibility. IT teams definitely has a large role in this. Interfaces need to work. APIs need to be maintained. Authentication needs to be handled. Failed transfers need to be monitored. If a PLM system sends data to ERP, somebody must make sure the integration is reliable.

However, the integration team cannot decide everything that needs to survive in the product history. They cannot always decide whether the information being transferred is enough for the business. This process requires people who understand the product lifecycle. This is why creating a digital thread ownership is different from integration ownership.

The same problem appears during system replacements and upgrades as well. A company replaces an old PLM application with a new one and carefully migrates all the data. All the important objects are moved, the interfaces are rebuilt and the new system goes live. Later, business users discover that an old relationship is no longer available in the same way. The data itself survived, but some parts of the product history became impossible to follow in the new system

What could be a better way? Start with the questions people need to answer

The most usual way to start a digital thread initiative is by looking at the application landscape. There is PLM, ERP, MES, requirements management, quality, service and many other systems. The data discussion is often about which system needs to connect to which other system.

It is a necessary discussion from systems perspective, but should it really be the starting point? A better place is to start is with the questions the company needs to answer about its products when need arises. If a component in a product fails, how easily should we be able to find every product that contains it? Or if a requirement changes, how can we see which designs and tests are affected? If a supplier makes a change to the used material, how easy is to find the products, drawings and manufacturing processes that depend on it?  Or when a customer reports a problem on a product that was delivered six years ago, to identify and reconstruct the configuration that was delivered years back?

These questions are easier for business teams to understand than a large architecture diagram. They also help define what the digital thread needs to contain and solve. This is also where ownership starts to become clearer. If the company agrees that a certain relationship is important, someone needs to make sure that relationship continues to exist. When a process changes, that person or group should ask whether the digital thread is affected. When a new system is introduced, they should check whether the required product relationships can still be followed. When an integration is changed, they should look at more than whether the data transfer still works.

This does not mean that one person needs to own the entire digital thread. For larger organisations, this would not be realistic. The digital thread sits across multiple teams including engineering, manufacturing, quality, service, IT and other functions, so ownership will almost always be shared. That is fine.

The important part is that the responsibility does not disappear between teams.

The arrows matter as much as the boxes

Most architecture diagrams are made up of boxes and arrows. The boxes are the systems: PLM, ERP, MES, quality, service and everything else. A lot of time is spent discussing the boxes because they are large investments and they support important business processes.

The arrows usually look much simpler. But from a digital thread point of view, those arrows deserve more attention than they normally get. That is why digital thread should not be treated only as another integration programme or another piece of PLM functionality. It is also a question of how a company takes care of the relationships in its product information over time.

All organisations already know who owns the boxes. The valid question to ask is who owns the arrows.