How to launch an Asset Management project in Manufacturing

Industry 4.0

,

Manufacturing

How to launch an Asset Management project in Manufacturing

Martin Horvath | Jun 28, 2019

Assets build the foundation for any business - no matter if it’s the axe to chop down a tree or a robot that assembles a car. The last post gave a brief introduction to what asset management can and in particular, what it does - so one can calculate the Asset-Turnover-Ratio automatically.

Today I'd like to introduce some procedures, patterns and templates which derive from successful projects and help you to get started with an asset management project.

Asset Management Standard

Whenever possible, best practices within an industry should be applied to new project and this also applies to Asset Management. For some years now, ISO standards are dedicated to this topic as well and serve as a good starting point. The ISO 55001/ISO 55002 standards state that “Asset Management System… should fit and result from the organizational objectives and the organizational plan” (ISO 55002, 2015, p.1).

They also recommend that an asset management system includes:

  • An asset management policy
  • Asset management objectives
  • A strategic asset management plan
  • Asset management plans which are implemented in
    • Operational planning and control
    • Supporting activities
    • Control activities
    • Other relevant processes

In other words: the asset management is tightly coupled to the organization using it! 

Onboarding the business

As with every IT or investment project, it is important to get the business on board at an early stage and to ensure that the "value" of the result is visible from the beginning on. Everyone should be keen on using the solution which is created!

Therefore, a simple requirements analysis should be done together with the key business users. This is not only needed to get a set of requirements. It’s the best place to get insights about the organization, understand how it works and evaluate if any governance is in place!

In these non-technical sessions, the most important demands are collected and in a guided discussion, you should focus on expressing a demand in money (remember the first post and the described KPIs like Asset-Turnover-Ratio). Focus on demands that really have a measurable impact on the business: either sharpen unclear demands or move them to a "wish list".

Let's see an example:

Julia: “I need to have an overview about all our axes in the company and when they were used”
Jack:“How does this have an impact on the business?”
Julia:“We are paying a maintenance fee for each axe. If we’re having 100 axes and are using only 80 of them, then we have to opportunity to reduce the stand-by equipment by 15 axes, keeping 5 on stand-by - unless someone has a reason for having 20 on stand-by”
Jack: “Excellent, so fulfilling your need helps the company decreasing the maintenance costs by 20% in your department.”

Obviously, the audience in the business session is not able to talk about technical assets. If there were technically versatile users participating who provided already information about assets - thumbs up, if not you shouldn't be worried at all because that's what you can refactor quite easy using the requirements and planning a Q&A session with a hands-on user.

Getting the business on board of your asset management project is key

Every system needs to have a boundary

An important step to be taken, once the organization was analyzed and the requirements were collected, is the definition of the asset management scope. This is also an essential part of the ISO standard where the scope should consider:

  • The assets, asset portfolios, their boundaries and interdependencies
  • Other organizations involved (e.g. through outsourcing)
  • The organizational aspects, e.g. involved departments/functional units/…
  • The organizations period of responsibility. E.g. a chemical plant asset owner that retains liability for ground contamination
  • The interactions with other parts of the organizations management system (e.g. quality control, finance,...)

The strategic asset management plan (SAMP) is a place to document this. Of course, such a scope is not a static thing and will evolve over time. It’s a good idea to structure the SAMP into phases and define the scope per phase!

Get assets out of requirements

With the scope in place, it’s time to identify the physical assets. Assume a requirement like this was collected and defined as included in the scope:

"We need to see the up-time, breakdown-time and repair-time for a paper cutting machine on production line A23 because every hour of unproductivity cumulates a loss of $4000,-"

Start on the highest level, generalize the objects and treat them as assets or create artificial/compound assets which are then registered in an architecture/planning document.

You can try to compensate insufficient process knowledge of the industry your customer is working in with a bit of creativity and imagination, but in general, you really should know how the industry and this customer are working!

In the given example, we can read (between the lines) that the business is interested in a particular machine (paper cutter). But most likely, the business means a station on a production line that consists of a paper-feeder, the cutter and the sorter. So rather than defining the “paper cutter station” as the only asset, it makes sense to model the station as a compound asset, consisting of several sub-assets.

Design decisions like those are what a good architect needs to recommend so that the customer gets a sophisticated and flexible solution. As a rule of thumb: you can always aggregate but it’s challenging to divide once a system is setup and running.

Download Predictive Maintenance Whitepaper

Develop the asset management backbone

Once the architectural asset management model was drawn, discussed, revised and then finalized, the metadata can be derived from it. I found it quite useful to develop a comprehensive metadata document for the identified assets. This does not only serve as a blueprint for upcoming configurations and tailorings of the desired software product. It’s also the foundation for any quality assurance programs, acceptance tests, and system interfacing.

There’s no unique truth for such a metadata document as every organization has different information stored on the asset, but the following should give you a good starting point to get an idea of how to structure such a document:

Attribute

Data type

Description

Sample value

ManufacturerID

Text

The global ID of the manufacturer

ASDF123

ProductionDate

Date

The date when the asset was produced

2019-01-01

PurchaseDate

Date

The date when the asset was purchased

2019-03-10

ProductNumber

Text

The global ID of the product

ASF9912

RegisteredBy

Text

User-ID of the registering person

EMP001

RegisteredAt

Date

Date when the asset was registered

2019-04-10

EndOfWarranty

Date

Date when the warranty expires

2020-01-01

InspectionInterval

Number

Interval of inspection in days

34

RiskRating

Number

Number expressing the “risk” of this product on any dimension (safety, business,...)

3.8

Weight

Number

Weight of the asset

12.3

Dimensions

Text

Dimensions of the asset in cm

12x44x123

 

This registry needs to be as complete as possible and must allow the system to provide the right information according to the business requirements. I said “information” for a good reason: an asset management system is responsible for collecting, storing and offering asset data.

But the real value is the information that is created by combining data or analyzing it: the two data parts, inspection-interval from asset management and cost-per-inspection from finance don’t say much about the business or motivate people to optimize. But the derived information inspection-cost per asset is something feasible and real.

Turning data into information and turning information into knowledge is something that I highlight in many analysis sessions to remind the stakeholders that the pure data is just the beginning.

Data governance in an organization

The purpose of creating documents, dictionaries and sketches is not just producing paper. Those documents are essential for the continuous awareness sessions that you should plan anyhow! Confronting the organization with collected and pre-processed information is the impulse for organizational change and -evolution.

Most of the activities can be grouped under the hood of data governance and include:

  • Data- and asset-quality control - To ensure that the data which is collected is usable, data entering the (asset management) system should be quality controlled and this needs a process and/or tools. E.g. ensuring that the data format is correct, that all fields are filled, etc.
  • Functional hazard assessment - Knowing what can go wrong is the first step to improve reliability. Because once this is known, the impact can be analyzed and appropriate actions can be planned, executed and controlled to manage the risk. E.g. What’s the severity, likelihood and impact of an engine losing power?
  • Defining data stewards for assets - There should always be one responsible person per asset category, type etc. 
  • Data- and asset-policies - It should be generally described and defined what a person enables/allows to use an asset or update its data. All those access rules and policies are part of data governance policies.

Data governance is a huge topic and touches many parts of an organization. The reason why I am mentioning it here is that everybody should be aware of the fact that Asset management is not just a piece of software.

What’s the take-away for today?

I would like you to remember that asset management has much more to do with the organization, it’s values and the people working there than with a software product. Creating the awareness for this is the essential first step to a proper asset management and justifies to analyze the business in detail before choosing a particular software product.

Especially if internal human resources are rare or new to asset management, it’s a good idea to bring in external help to properly do the homework before a request-for-proposal is sent to potential implementation partners. This will not just ensure that the organization gets what it needs, it will also lower the costs because the software implementers/developers have all the needed information available and do not need to estimate a deep analysis phase.

And last but not least, products like an asset dictionary, an asset metadata document, a business value analysis or the cost breakdown for whole organizational functions are used by many more people than just the asset management stakeholders.

 

Interested in Learning More?

Are you ready to start deploying smarter asset management in your business? View our services and solutions for better asset management.

LEARN MORE

Subscribe!