• Written by Azhar Aliyar, Director

When a maintenance manager tries to query the organisation's data to find out which assets are due for maintenance, but the query returns a list of assets with different descriptions, it becomes clear that something is wrong with the data foundations. This is known as a data inconsistency issue, caused by the lack of standardisation in the asset descriptions. To resolve this, the maintenance manager needs to review the data and standardise the asset descriptions, ensuring that each asset is described consistently across the system.

Field-level meaning and why column names are not documentation

The issue of data inconsistency is often rooted in the lack of clear field-level meaning. Column names such as "asset_id" or "maintenance_date" are not sufficient documentation, as they do not provide enough context about what the data represents. For instance, does "asset_id" refer to a unique identifier for the asset, or is it a reference to a specific location or system? Without clear documentation, it is difficult to ensure that the data is accurate and consistent.

A shift supervisor checking the maintenance log may assume that the "asset_id" column refers to the unique identifier, but if it actually refers to a location, the query results will be incorrect. This highlights the importance of having clear and consistent documentation for each field, to avoid misunderstandings and ensure that the data is used correctly.

The systems that get left out of scope and the partial answers that follow

When implementing a system like AsscherAi, it is easy to focus on the main systems and data sources, but often smaller systems or legacy data sources are left out of scope. This can lead to partial answers, as the system is not considering all the relevant data. For example, a category manager comparing two suppliers may not have access to the data from the legacy system, which could provide valuable insights.

This can be particularly problematic in maintenance, where data from multiple systems is often required to get a complete picture. By leaving out smaller systems or legacy data sources, the organisation may be missing critical information that could impact the accuracy of the query results.

The maintenance data this depends on: work orders, asset history, spare parts inventory, condition data where it exists

The maintenance data required for AsscherAi to function effectively includes work orders, asset history, spare parts inventory, and condition data where it exists. This data provides a complete picture of the maintenance activities, allowing the system to provide accurate and relevant results. For instance, the work orders data provides information on the maintenance activities that have been performed, while the asset history data provides information on the asset's performance and maintenance requirements.

The spare parts inventory data is also critical, as it provides information on the availability of spare parts, which can impact the maintenance schedule. Condition data, where it exists, provides real-time information on the asset's performance, allowing for predictive maintenance and reducing the risk of unexpected failures.

What it changes about: reactive work crowding out planned work and the same asset recurring under different descriptions

By having a solid data foundation, AsscherAi can help change the way maintenance is performed, shifting from reactive to planned work. With accurate and consistent data, the maintenance manager can identify patterns and trends, allowing for predictive maintenance and reducing the risk of unexpected failures. This can help reduce the amount of reactive work, which can crowd out planned work and impact the overall efficiency of the maintenance team.

Additionally, by standardising asset descriptions, the system can help reduce the occurrence of the same asset recurring under different descriptions, which can lead to incorrect query results and impact the accuracy of the maintenance schedule. By providing a single, consistent view of the asset, the system can help ensure that maintenance activities are performed correctly and efficiently.

Measured with: planned versus reactive ratio, mean time between failures, spares availability

The effectiveness of the maintenance data foundation can be measured using metrics such as the planned versus reactive ratio, mean time between failures, and spares availability. These metrics provide insights into the efficiency and effectiveness of the maintenance team, and can help identify areas for improvement. For example, a high planned versus reactive ratio may indicate that the maintenance team is performing well, while a low mean time between failures may indicate that the assets are not being maintained correctly.

By tracking these metrics and using production data, the organisation can refine its maintenance strategy and improve overall efficiency. For more information on how to implement AsscherAi and improve your maintenance data foundation, please contact us.

What this does not do, or when it is the wrong choice

AsscherAi is not a replacement for a computerised maintenance management system (CMMS), but rather a tool to provide insights and answer questions about the organisation's data. It is not designed to manage work orders or track maintenance activities, but rather to provide a high-level view of the maintenance data. If the organisation is looking for a system to manage its maintenance activities, a CMMS may be a better choice.

Additionally, AsscherAi is not suitable for organisations with very small amounts of data or simple maintenance requirements. In these cases, a simpler system or manual processes may be more effective. However, for large organisations with complex maintenance requirements, AsscherAi can provide valuable insights and help improve the efficiency and effectiveness of the maintenance team.