Corporate Equipment Reliability Insights: The Reliability Issues Affecting Your Bottom Line

Tony Ciliberti PE

High-quality data is fundamental to producing reliable models and deriving insights for equipment reliability and performance. Insights from the smart use of data are powerful; if they are smart and actionable they will have a real impact on your business.

Companies that are able to develop smart, actionable insights will be winners. The fundamental objective of collecting, analyzing, and deploying equipment reliability data is to make better decisions for equipment assets. Better decisions lead to safer and more profitable operations.

The ISO 14224 standard gives companies a data structure and data quality management processes that enable corporate insights for equipment reliability, such that shown in Figure 1. While companies strive for corporate metrics, many are unable to generate metrics for even individual equipment items. The reasons are given below, along with recommendations to address them.

Dashboard of corporate equipment reliability insights

Figure 1: Dashboard of corporate equipment reliability insights. Consequence definitions are from ISO 14224:2016 and supplemented with loss amounts in US dollars. The metrics shown are from standard SAP-delivered reports for all facilities in a global operation over a set time period, roughly 10,000 events.

Typical equipment reliability data issues

1. Lack of data digitalization

Data are stored as unstructured text and scanned images. Datasets cannot be queried programmatically. Analyses are inefficient; they require single record reviews and data mining.

Recommendation: Use a relational data model to digitalize data. Each required datum should be structured and stored discretely in a unique data field created for that purpose. This practice enables programmatic analyses of thousands of records simultaneously.

2. Improper work segmentation

Companies frequently consolidate dissimilar work into the same notification types, e.g., one notification type for general maintenance and failure reporting. Lack of logical segmentation affects relevancy of form fields, picklist selections, and the ability to regulate data compliance. Data requirements that are significantly different for a given notification type cannot be validated; e.g., when consolidating general maintenance and failure reporting into one notification type, failure mode is irrelevant to general maintenance and thus cannot be validated for either type.

Recommendation: Reliability Dynamics recommends separate notification types and discrete work streams for General Maintenance (non-malfunctions), Equipment Failure Reporting, and Inspections/Preventive Condition Reporting, with each notification designed with data fields relevant to and system-validated for its respective purpose. This practice creates three distinct data sets for each workstream and, with proper data quality control, eliminates the need for data mining to eliminate irrelevant records when generating metrics.

3. Lack of standard terms and definitions for equipment

Standard definitions of equipment are needed to make reliability data from different sources compatible. Without them, data collected may be incomplete, incompatible, and non-standard.

Recommendation: Use ISO 14224 taxonomy definitions, which provide a standard data structure for reliability data collection, merging, and analysis. Companies should develop additional taxonomy definitions for equipment classes not in ISO 14224 content.

4. Use of a nonstandard lifecycle data model

Use of a non-standard data model complicates data maintenance and analytics and may result in:

  • Inability to track position/specific service of materialized assets
  • Incoherency with data aggregated at the equipment unit when component-level failure code sets are used

Recommendation: Use the ISO 15926-2:2003 data model “Coincident Individuals” (Section E3.3), which specifies a 1:1 relationship between functional and materialized objects, where the functional object describes process duty and position, and the materialized object (equipment) describes the installed physical asset.

5. Inconsistent application of equipment boundaries

Without standard interpretations of equipment boundaries, data collected may be incompatible. Additionally, a lack of system-defined equipment boundaries affects data aggregation processes.

Recommendation: Structure equipment boundaries into the corporate technical hierarchy in a manner consistent with ISO 14224:2016 taxonomy definitions and specify a taxonomy level for each functional location record. This ensures one “version of the truth” for equipment boundaries between all users.

6. Lack of taxonomy-level specifications for functional location (FL) objects

Users have difficulty in determining which functional locations are relevant for failure reporting and, in many cases, will specify administrative FL objects versus technical tags. This affects:

  • Relevancy and availability of metadata used to describe failures and inspection results, a significant data quality issue
  • Equipment unit metrics, making them overly optimistic as failure reports with incorrect reference objects are not selected in metrics reports

Recomendation: Companies should specify a taxonomy level for each functional object and make it visible to users in the technical hierarchy structural display. This helps them identify which are administrative, which are equipment units, and which are components. This practice enables system validation that the correct taxonomic level has been specified during record creation and enables automated data aggregation to the equipment unit level.

7. Lack of reliability data specifications and discrete data fields in data-collection forms

Specifications of required data for equipment failures (and associated data fields in the data collection forms) are imperative for structured data collection. Missing data fields result in required data being collected in an unstructured format. Irrelevant data fields are confusing to users and cannot be validated.

Recommendation: Companies should use ISO 14224, Tables 6 and 8, and/or an equivalent corporate specification to define which data shall be collected on equipment failures and maintenance events. Data-collection forms should be digitalized; that is, designed with discrete fields for required data. Data fields should have picklists to ensure standard input. Required data should be system-validated to ensure compliance with specifications.

8. Lack of data aggregation

Many companies neglect both taxonomy level specification (Issue 4) and component-level aggregation to the equipment unit. This does not give a true picture of reliability and results in metrics that are overly optimistic.

Recommendation: Reliability data for an equipment unit should be an aggregation of notifications registered for the equipment unit-tag number and its component tag numbers.

9. Inadequate data quality management processes

Lack of data quality can make equipment reliability metrics meaningless (garbage in equals garbage out). Plus, gleaning insights from low-quality data requires data mining and individual record reviews. Data mining is fraught with inefficiencies, assumptions, and inconsistent results.

Recommendation: Data quality management should be a combination of system-driven and user-executed steps, comprised of quality assurance (QA) and quality control (QC) steps. QA processes are used to assure completed notifications are compliant with data specifications, e.g. with system-driven data validations. QC is a review of completed notifications to ensure compliance with specifications and remedial steps to address non-compliance.

Learn more about the recently announced SAP S/4HANA and SAP Business Suite 7 maintenance commitment on this Webinar.

Tony Ciliberti PE

About Tony Ciliberti PE

Tony Ciliberti is the founder of Reliability Dynamics, an engineering and technology company specializing in the application of asset performance management methods in corporate software. He has 30 years of international experience as a maintenance and reliability engineer in petrochemical, oil and gas, and public utilities sectors. Tony's experience includes four years with SAP Americas' National Consulting Practice as a solution architect for large corporate SAP Plant Maintenance implementations. He is the ANSI-appointed U.S. Expert Member in the ISO/TC67/WG4/PG1 (ISO 14224 project group), was actively involved in developing Version 3 of the ISO 14224 standard, and participates internationally as an instructor in ISO PG1 seminars and courses.