Digital Asset Management

So, what is Digital Asset Management?

If you search the term “Digital Asset Management” on Google, the most likely set of results will relate to the management of digital assets, such as software, audio, graphics, photos, documents, etc.

Well, this is not what I mean by Digital Asset Management in the context of myActivo.

When I wrote a couple of chapters for the Power Transformer Condition Monitoring and Diagnosis book, I touched on some aspects of Digital Asset Management.

When I talked about automation as an aid for lifecycle management, I said:

Whilst there are many different and valid ways in which this problem [consistent asset analysis] could be attacked, an automated data acquisition and analysis framework could possibly be used as a solution. This framework would help realise additional value particularly in organisations where some level of automation already exists. When properly designed, the concepts and tools used to build such a system would not only be useful to manage transformers, but also be extensible to other asset classes.

Carlos Gamez, Lifecycle Management of Power Transformers in a New Energy Era

The way I would define Digital Asset Management is:

The use of Information and Communications Technology to maximise the value delivered by the Asset Management practice.

Of course this is a fairly generic definition, but it captures the essence of this concept, the juncture of performing asset management tasks leveraging all the productivity that digital technologies have to offer.

And, what are these asset management tasks? In my view, and for the purpose of defining the functionality I’d like to build in this software, these tasks revolve around the flow of asset data. This asset data goes through a series of transformations that give it meaning and ultimately allow us to make effective asset management decisions.

This is where digital technologies shine. By managing this data in digital ways, we can efficiently connect each decision to its point of origin.

For any given decision at a point in time we should be able to trace:

• the condition of the asset
• the gaps in the desired performance
• the risk that this asset represented
• the strategy applicable to that asset
• the investment that was necessary to bring that asset into the desired state

We can then think of Digital Asset Management as a framework to manage and transform asset data. This transformation enables turning raw asset data into valuable decision-making knowledge.

This framework can be built with six core components. Each of these components would have a specific responsibility and enable a specific group of activities in this data flow.

These six components and their interrelation can be visualised in the diagram shown at the start of this post.

Below is a brief explanation of each of the elements in this framework. I will talk about these in more detail in future posts as I go through their implementation in myActivo.

Define

The clear and consistent definition of the structure of the data that flows through this framework is critical to its successful implementation.

The modularity and interoperability of the various components of a system like this heavily relies on “speaking the same language”.

This is what we do on this element. We define a clear language in the form of data structures that will be used by all other modules.

The Define component of the framework provides a clear definition of what data we want to capture.

Acquire

The Acquire component identifies how we are going to capture the data structures created in the Define element.

In this regard, we don’t make any assumptions about what the acquisition mechanism is. The data could be captured by sensors or people and it might reach myActivo in a variety of ways.

This element should be as modular as possible in order to cater for current and future data acquisition processes.

The key to this element is that all data has the same structure regardless of how it is obtained.

Analyse

The Analyse element implements any formula, rule, model or algorithm used to turn the acquired data into a useful insight about the asset.

For example, if we have captured condition data for a particular asset class, in this element we might define formulas to assign each asset a health index or calculate its probability of failure.

This element of the framework should be generic enough that it allows the implementation of any algorithm.

To make an analogy with a spreadsheet, if the Acquire element contains the raw data input on the spreadsheet cells, the Analyse element contains all the formulas that manipulate the data.

Visualise

Having performed the necessary calculations to assign meaning to raw asset data, the best way to gain insights about this knowledge is to visualise it.

The visual representation of information is a whole discipline in itself and there are multiple tools available for this purpose.

In the Visualise element of the framework we aim to gain insight of the cause and effect mechanisms that might not necessarily be readily evident otherwise.

The fact that we have all information about the asset lifecycle in one place, promotes the use of visualisation techniques to enable Systems Thinking.

Decide

Having gathered all this knowledge about the asset’s lifecycle, we can then make well-informed strategic decisions around investment plans.

Why don’t we just make a decision? Why do we need to explicitly define it in this framework?

The reason of why there a Decide element is necessary in this framework is that by recording each decision made at a point in time we have full traceability of that decision.

If we made an investment decision, we can trace back our steps and know exactly what the state of the asset and its context at the time that decision was made.

This not only allows the transparent auditing of the decision, but it allows us to learn from incorrect decisions too.

Store

Last but not least, we need to ensure we have a robust storage mechanism.

The Store element exits to formalise the selection of storage mechanisms and the interoperability of all the other elements in the framework.

A particular important aspect of this element is the modularity of each storage mechanism. As technology evolves, so do the data storage mechanisms.

It is important that this framework doesn’t “lock” the user to a particular storage medium or technology. As new data storage technologies become available we would like to be able to swap one for another with the least amount of hassle possible.

Next steps

So this is the conceptual framework that I will be using to build myActivo.

I will be interested to hear from the community on whether the concepts described above resonate with your experience and requirements.

In the end my goal is to make myActivo a practical and useful tool that solves real-world problems.