Digital Shipyard - Digital Thread VS Digital Dread - Avoiding Being Up Ship Creek

The first time I heard the term Digital Thread used I had visions of advancements in medical suturing techniques running through my visual cortex. After further discussions with the person who threw the phrase into our conversation I realized they were talking about what I termed "Data Accessibility" which is a very important concept when it comes to Architectural Principles and increasing organizational and operational effectivity.

Data is a Shared Asset: Enterprises that start with the vision of data as a shared asset ultimately outperform their competition

Data in a modern organization is now deemed its most critical asset and rightfully so. Access to the right data in the right place at the right time can literally make or break an organization. I can name at least two organizations that were made insolvent within the last ten years as they didn't make the move from Excel spreadsheets and Access databases to enterprise applications. In fact one of them which I won't name had over 34,000 spreadsheets that were deemed to contain "Business Critical" information. It's no surprise that informed decisions were hard to make when the data that would help make those decisions was spread across so many digital assets.

The way I often explain the power of Digital Thread when asked is by likening it to the "Find and Replace" button in Microsoft Word. If I want to change a word like "Assembly X" to "Assembly Y" in a paragraph, it is relatively easy and won't take me long to do. If however I am doing the same thing in a document that was over ten thousand pages then that takes a lot of time and immense rework. It could take me a month.  However if I use the "Find and Replace" button I can update every instance of Assembly X to Assembly Y within seconds. So let me apply that analogy to a Digital Shipyard. If I change a part for an assembly on a ship in operations due to an issue encountered, i.e. it fails and causes fire, my "Find and Replace" analogy should make sure that update is reflected in the configuration baselines of all previous and subsequent builds of that specific platform (In the case of a shipyard, the same class of ship). That is Digital Thread.

It doesn't sound like it should be hard to achieve however the problem is that most if not all manufacturing organisations don't have one system that does everything they need to build products and platforms. Normally they have an ERP system, a PLM system, an MRP system, an EAM system, a Pipe Spool system, a Work Order system, and the list goes on. Normally these applications will have some level of data exchange and interoperability however that level can vary significantly and often be put into one of three connection categories as follows:

Tightly Coupled - applications that are very dependent on each other and are therefore well connected and interoperable. These type of connections are usually native, are built in conjunction with other application vendors and are provided out of the box

Loosely Coupled - applications that have some level of data exchange however due to the quantity are often overlooked when upgrades occur leading to broken connections. More often than not these connections are bespoke, hand coded or involve generic database connects which are rarely updated causing issues

Swivel Chair - applications that have some level of data dependency however no digital connection exists, instead a human operator will swivel chair between two applications and manually transfer information between the two. At scale this would be termed "Data Migration"

The other problem some organizations face is the fact that they have different instances of the same application for different phases of a program. For example as a Shipbuilding program can last thirty plus years, it is broken down into three to four distinct phases. That being Design, Build, Operate and Maintain (the latter two often being defined as a single phase). If an organization has a different instance of an application for each of those phases then often the only form of data exchange happens through migration from one phase to the next. What can compound this issue is when an organization has a different application for the same capability in each phase. i.e. Teamcenter PLM for the Design phase, Enovia PLM for the Build phase and Windchill PLM for the Operate and Maintain phase. These issues start to evolve into what I term "Digital Dread".

Digital Dread, also known as Spaghetti Architecture is not uncommon in medium to large organisations and it happens in every industry. In fact it is so common that organisations hire individuals specifically tasked to create and update interfaces between applications. I have spent a large part of my career on IT projects that invariably involved some form of data migration. On average those data migrations accounted for around one third of the cost of the project. So if you are talking about a ten million dollar program that is a lot of migration dollars for what could have been avoided if Digital Thread was a part of the architectural mantra from the start.

So let's take a look at what can go wrong with Digital Dread. As you can see in Figure 2 below, there are a number of significant consequences of having siloed data between the phases of a ship's lifecycle. Some may be considered relatively insignificant however some can be potentially disastrous. Let's take the example of when a part on an existing vessel in operations fails causing a part assembly to melt. Normally what would happen in that circumstance is that a safety alert would be issued and a maintenance order would be created to either check or replace that part on other existing vessels of the same class. However there is no guarantee that the shipbuilding organization building new vessels of that same class will have that alert and subsequent part number updated in their system. This could lead to a subsequent part failure on a new vessel leading to fire, injury or even fatality. There are a number of reasons that part might not get updated in the appropriate PLM system however more commonly it is due to the lack of feedback loops, i.e. Digital Thread. If all relevant systems had a way to handle this Digital Thread then even if the build of a new vessel was being carried out by a different organization than the operate and maintain of existing vessels, the change could be reflected in all systems across the supply chain. However for it to be economically viable the problem needs to be addressed early in the lifecycle of a ship class.

So how can organisations involved with long complicated programs deal with Digital Thread? To be honest it is technically easier than you might think however it requires a well thought out vision, a robust strategy, meticulous planning and experienced foresight. It is also significantly harder to achieve mid to late program than it is at the start. Preferably these critical steps should be undertaken before the mobilization of the program.

Although there are ways of creating interoperability of applications through "Enterprise Application Interfacing" (EAI) more often than not the nature of defence security requirements makes that really hard to achieve. It is not always possible to just open up the corporate firewall to an organization's supply chain and allow access to the crown jewels over the internet. And even if you could, every application is different and therefore interfaces would constantly require updating just to avoid things breaking. So a more intelligent way to achieve that is to limit the information to that which is required to provide digital thread and share that centrally in a secure "Data Ocean".

This Data Ocean provides the ability to not only make sure there is Digital Thread across the organisations enterprise applications but also across the applications in the organisation's supply chain. That makes the value proposition far more compelling as it provides a supply chain ecosystem where data is dynamic and immediately accessible.

So when the faulty part I referred to is updated with a new part number in the In-service-support PLM system, that record is instantly updated in the data ocean which is then instantly accessible to any other system across the supply chain of that class of ship and potentially others where ship systems overlap. That's Digital Thread. As you can see from the diagram below, if a part number is changed in the operational / maintenance PLM system of a vessel / class, that change can then be reflected across all associated systems within the supply chain of that ship class through the Data Ocean of the Digital Thread.

The role of Digital Thread becomes even more valuable when integrated into a Supply Chain Tower (SCT). This relatively new concept leverages the power of Artificial Intelligence and Machine Learning to amplify the power of intra and inter industry supply chain ecosystems. Lets look at an example:

Your SCT identifies that you are procuring a large quantity of stainless steel bolts which accounts for 7% or your current spend. Without being prompted it traverses other supply chain networks and identifies that there are twelve other in-country manufacturers of the same sized bolts (form and fit). It then determines that three of those manufacturers sell the bolts for as much as 23% cheaper than what you are buying them for. It then actively researches those three manufacturers using a number of resources including social media, information from industry bodies and search engines. The research identifies that one of those manufacturers has a bad safety record however the other two come up green. Without you even realising what your SCT was doing it sends you a report suggesting that if you use one of those two manufacturers as an alternative to the one you are currently using you could save up to 3.4 million dollars over the life of your shipbuilding program. If your Digital Thread is integrated into your SCT then the world is truly your oyster. It could undertake intelligent learning and advise on valuable initiatives such as co-op approaches to parts procurement where a number of organisations procuring the same parts could save millions of dollars through bulk purchasing.

So the value of Digital Thread isn't just in the thread itself. It is the value that can be extracted from the accessibility of information across an enterprise and its supply chain. This value isn't just measured by saving dollars, it is also measured by the quality of the end product and in some circumstances the potential to save lives. Who knows, if there was a digital thread across the Leaf class program (HMAS Westralia) maybe the wrong fuel hose would have never been fitted and there would have never been a fire. Unfortunately the technology was not as advanced back then but it is now. So shipbuilding organisations and ship owners can now consciously choose to introduce significantly more efficiency, effectivity, quality and safety into the platforms they build and own. There is now no reason complex programs should mobilise without addressing Digital Thread.