In previous articles on engineering.com, I have looked into a dozen critical aspects of digital transformation enablement, delving mainly into the “what.” This article is the second to look beyond the “what” into the “why” and “how” of the critical dozen—particularly how they relate to the digital thread.

For the “what” on digital threads, read: Mastering Tools and Techniques of Digital Transformation.

Regular readers will recall that we previously examined new technologies that are revolutionizing the design and production of goods and the delivery of services and how they enhance, or are being enhanced by, the enablement of a true end-to-end product lifecycle management (PLM) strategy. We also looked into a half a dozen “Forcing Factors,” broad trends that are disrupting manufacturing industries worldwide and even impacting the overall economies of nations.

In this article, we deal with an essential and foundational part of digital transformation: the digital thread. It is commonly described as a communications framework that connects data flows. These data flows can be used to produce an integrated and holistic view of an asset’s data, from physical and virtual systems (i.e., its digital twin), throughout its lifecycle across traditionally siloed functional perspectives.

Digital Thread Recap: What Is It?

In essence, the digital thread is a chart, or a map, of decisions that looks like a web. In a recent CIMdata educational webinar, my colleague Tom Gill pointed out that a digital thread or digital web must effectively connect data and processes so that digital twins can be created, maintained and leveraged. The digital web is a more realistic representation of how data and processes are interconnected in enterprises than any other representation, Gill says.

Each of these frameworks connects hundreds of informational nodes and data repositories. These range from simple flat files to model-based structures, each packed with information critical for making sound process decisions about products, tasks and services. The value of any process lies in its myriads links to data and information that feed and validate decision-making in product development, design engineering, production, sales, service, support and more.

Throughout its length, a digital thread must enable the current digital twin of an asset—an exact, up-to-date digital representation of one of the enterprise’s physical products or services, or even its manufacturing system.

A digital thread captures and represents all the decisions made throughout the lifecycle of a product or service, and the impacts of those decisions. Building a digital thread, the “how” is about choosing which informational nodes and repositories to link in any given process and how best to digitize those links. This is a significant effort, typically requiring the skills of people representing different organizational functions across the enterprise.

Once the effort needed to build a digital thread is understood, it is more than reasonable to ask, “Why go to all this trouble?” Fundamentally, a digital thread helps us see into every product- or service-related decision, and better understand how and why each decision was made. If we fail to remember why a decision was made and what we considered in reaching it, we will fail to learn from our past mistakes and risk repeating them. Worse, we will be unable to build on our prior successes.

How to Create a Digital Thread

Which brings us to the heart of this article: “how” a digital thread is created. This means choosing and connecting to the many data repositories relevant for any given process. No two business units or departments organize their information in the same way, so establishing these connections can be tedious. But they are crucial.

We will start at the beginning of product conceptualization: marketplace information on what sells and what does not. Add to this any related competitive analyses that try to predict which product features and capabilities will be snapped up and which may be ignored.

With marketplace requirements clearly understood, CIMdata recommends that digital thread developers should:

• Examine regulatory requirements databases, which are everywhere in industries such as aerospace and defense, medical services and pharmaceuticals, public utilities, power generation and distribution, and so on.
• Examine industry standards. Even free-wheeling industrial components markets have do and do-not data that must not be overlooked.
• Find repositories that aggregate customer wants and needs. Every marketplace has its equivalents to Yelp and Foursquare where frustrated customers let off steam; don’t be blindsided.
• Connect with systems and tools used by developers and design engineers to do the primary geometric configurations of new products—CAD/CAE, EDA/MDA, PDM/PLM, simulation and analysis.
• Identify additional configuration refinements for which developers and designers use CAM, MES/MOM, M&S, MRP/ERP and the technical data packages (TDPs) that introduce new products to workers on the factory floor.
• Build connections to the engineering bill of materials (eBOM) and other BOMs in production, and to the systems that generate BOMs for downstream and upstream use, such as sales and marketing and service.
• Identify key repositories in the model-based systems engineering (MBSE) domain that the business unit or enterprise implemented in its move away from paper documents and two-dimensional graphics.
• Reach deeper into downstream data repositories where modifications are generated in every new product’s later development stages; these sources include QA/QC, test and inspection, sales/distribution, MRO, verification and validation, and warranty claims.

A vital connection is engineering change process execution, a consistent approach to managing and tracking engineering change. Engineering change process execution helps prevent do-overs and other hiccups in new-product development.

Bear in mind that a digital thread is required to support a digital twin’s creation and management. The more comprehensive and effective the digital thread, the greater the value of its digital twin to its users. A digital twin is an orphan unless connected to its digital thread.

Developers of digital threads who work in any of the previously mentioned areas should be on the lookout for feedback loops. Even simple processes may have dozens of loops feeding changes and decisions back “upstream” to the beginnings of processes. These loops keep processes up to date, playing a major role in the organization’s drive for continuous improvement.

My final two connections to consider for the digital thread’s enablement are intended to avoid disruptions from outside the business unit or enterprise. One connection is to databases in design engineering that track fast-moving developments in CAD/CAE and EDA, CAM, MES/MOM, and of course PDM and PLM. Monitoring these developments helps digital thread users keep up with developers’ and designers’ new techniques.

The other connection is to databases that monitor the impacts of technology and economics on customer expectations. Tracking these impacts can help users of digital threads anticipate decisions that developers and designers are likely to face near-term.

Both can help keep complexity from overwhelming us—and both are easily overlooked.

The Human Side of Digital Threads

I want to conclude this “how” analysis of digital threads with a few words on human factors. In the development, production and service of any product, there is a very human tendency to underestimate the range of factors impacting each decision. Also commonly underestimated is the vast amount of information available, the variety of repositories and other sources, the likelihood of unexpected change and the complexity of other parts of any process when compared to one’s own role. All of these result in short-sightedness. All can be averted or overcome with digital threads.

A key point to consider by those contemplating the enablement of any process as a digital thread is to seek outside expertise. Digital thread implementations are never straightforward, and changes to connections to any one repository may affect feedback loops and links to other data stores. Not all the repositories are to be found in your business unit or even in your enterprise. Additionally, almost every organization is part of another organization’s digital thread. Lots of coding and testing is inevitable.

A final few points:

• Any process can be enabled with a digital thread in different ways for different purposes. Get off to a good start by reaching agreements with all users on what the digital thread should achieve—its purpose and expected value, why it is needed and by whom. Do the same for every digital twin that your digital thread feeds. These agreements will prove invaluable in keeping everyone on the same page.
• To assure access to the internal technical expertise and outside resources, you will need to actively promote the benefits of the digital thread and its digital twin.
• Delve deeply into the tools available in your PLM solution(s); they are numerous and powerful, but many require significant experience to use effectively.
• Enlist help with technical issues, especially connectivity to the variety of repositories and data formats (old and new) that will be encountered.
• Develop a sound plan to maintain and enhance the digital thread throughout its useful life, just as the underlying process would be maintained.

In conclusion, every digital process is precious to its users and vulnerable to a host of detrimental changes. Incorporating a process into a digital thread maximizes the value of its information to its users, including the soundness of the decisions it supports and captures, as well as the completeness of the associated digital twin. Ultimately, ensure vulnerabilities are minimized and maintenance is streamlined.