The quality of data is a difficult concept; you can approach it intuitively: for example data that is ‘good'. But it quickly becomes trickier when there are several users of the same data, and trickier still if each one of these users wants to achieve different goals with that data.
That is precisely the challenge that large asset owners face in a time when data availability and analysis is really starting to take flight. Now that (I)IoT and Industry 4.0, as well as scalable data storage and more accessible analysis possibilities are leading to a new string of developments in this area, the smart thing to do is consider this question: Why is it important for us to collect data in this way and what do ‘we’ do with it?
Data quality is expressed in the aspects of accuracy, completeness, topicality, relevance, consistency (of data between different sources and over time), reliability, correctness of presentation or notation, as well as the accessibility.
Data quality is not an unambiguous parameter. It is a perception of a result of an assessment of quality in relation to a specific goal. What's more, it should also include the environment or context in which this goal needs to be achieved. The demands for accuracy or completeness of certain measurement data can vary for the same analysis in different environments.
An example: your smartphone features a number of sensors: GPS, a compass (magneto meter), an accelerometer, a microphone, a light sensor and maybe even a fingerprint scanner. These sensors allow app developers to measure (for you) how well you sleep, where your car is parked or how many steps you take each day. You can also control a drone, play games, etc. So you already have all these sensors, but the information you turn this data into is up to you and is based on whether or not you combine this sensor data via an application.
When we link this to the practice of Asset Management, we already encounter data at a very early stage in the asset life cycle: in the study and the FEED stage (Front-End Engineering & Design) of a large installation, we consult different data sources, carry out an array of calculations, studies and models. These are not only done by the future asset owner, but also by suppliers, governments and sometimes also by neighboring residents.
In this multitude of data, we very quickly run into the quality aspects of relevance and accessibility, because: What's the point of data that will never be able to answer your current and future questions? Or, what good is data that you know is there but you don’t have access to (any more)?
The problem with data is that you are often (too) late in discovering that you need the data now. The consequence is that you no longer have the time to start gathering data or that enriching data afterwards is a complex and costly issue. Also, the relevance of data can be reduced from very big to zero in a millisecond; for example an alarm signal that is too late in converting to preventive action(s). Just think of an airbag that needs to be inflated in a matter of milliseconds under specific circumstances.
Good data is crucial in reaching your business objectives. Data quality starts with relevance: What data is needed? Every organization will have to redetermine on a regular basis what data is relevant in achieving the business objectives. These objectives change from time to time, and with them the relevance of the data that needs to be collected, stored and managed.
What is data relevance?
In other words: the extent to which data answers of gives insight into the question of the individual user.
That is why every asset owner and the various stakeholders in every organization need to take the time every once in a while to think about which question they would like to have answered based on a thorough analysis of data. Only when the desired (new) analysis has been defined is it possible to work out and implement a data strategy, configure alarms, modify dashboards, etc.
The implementation of these new dashboards, too, will be easier if the relevance of the data can be communicated clearly to everyone: Why do we need to collect this data and who will be using this data? This also allows you to create a link between ‘value’ and data, and make a decision as to how the data is to be collected, processed and stored.
Let's take a quick look at your daily operation: you are responsible for the management of an asset. Your asset produces a large quantity of data and you have many data sources. It all started with drawings, specifications, operating manuals, maintenance manuals, material codes, bills of material and relevant internal standards. All your assets have been given functional locations and TAG numbers in the CMMS by your organization. Usage and production data is collected from the operations department, and then there are inspection reports with photos, text, conclusions and recommendations.
Who is the owner of the data that is relevant to your organization and who already uses the data? These questions become increasingly urgent: devices and machines will keep producing more data (both in breadth and in depth) and all that data relates to the state of your installation and the performance of your organization. Is the asset owner also the owner of this data? And what if he or she doesn't agree with you? Isn't it therefore time to appoint an owner for each piece of data?
Ownership of data is often a balancing item, a shared responsibility within the IT domain. But IT can possibly best be compared with a printer of books, who masters the technique of making and keeping information accessible, but is not responsible for the content!
A great example of this can be found on the website of the Dutch organization PWN, where the materiality matrix shown below (in Dutch) forms the starting point of the report on the performance of the organization.
But if we can imagine for a moment that the organizational goals are stable, we can notice that your company assets are aging. Because of this changing condition, the reliability of resources changes and this alone will also change the information need with regard to the reliability, performance or remaining service life of that company asset.
Compare it to a critically ill patient in a hospital, lying in a bed hooked up to a heart monitor: measuring the beating heart wasn't relevant until an incident took place and this vital organ required 24/7 monitoring until the problems could either be resolved or kept under control.
In short: data quality is not a constant figure. It is context sensitive and, from time to time, demands the attention of a broad group of stakeholders in the organization to keep the relevance in focus.