System of Record – It’s Not that Simple

Imagine for a moment that an auditor has asked the team for evidence that a particular process has been executed from start to finish. It should be an easy matter to provide what the auditor is looking for, assuming that the business is following their documented processes and leaving an evidence trail in the computing systems they use to perform the steps of the business process. 

But this is rarely the case. Most of the time, the team will need to extract information about the business process from multiple systems and then blend them into a single view for the auditor. This is not necessarily a problem if the team is well versed in where the record and process information is stored, but it does point to an area of potential improvement. 

Usually, there is no single “system of record” 

Let’s use the case of a lowly work order. If the work order record begins and ends its lifecycle within a single EAM system, then one could argue that the EAM is the “system of record” for the work order. All information from the creation to the closure of the work order record is contained in a single system. 

What about a situation where the work order is generated/created via an external system? The trigger or the interface from the external system is part of the work order record lifecycle. In this case, both systems are storing information about the work order record as it moves along in its lifecycle. In fact, the process may be that when the work order is closed in the EAM system, that fact and other information may be fed back to the external system for further processing. 

The point here is that when looking for the “system of record,” one needs to look at the entire process from end to end where the record plays a role or is acted upon. It is easy to see that while the bulk of the information about the record will be captured in a single system like the EAM, it might not be the full picture of the record’s lifecycle. 

Let’s use another common situation where a new asset (equipment) record is created in a mapping system and then interfaced into an EAM system. 

In this case, the new asset record may only contain spatial information such as what kind of asset it is and where it is geographically located. This information may (or may not) be passed into an EAM system for further refinement. Attributes such as the description, EAM location, specifications, ownership, preventive maintenance records, safety plans, inspection forms, etc. may all be refined and established in the EAM system around the asset record. 

As the asset is worked on, moved around, and eventually decommissioned, the bulk of the information about the record will be stored in the EAM system. However, we cannot lose sight of the fact that the asset record did not begin its life in the EAM… rather it came from the mapping system. 

System of Creation vs. System of Record 

The point so far in this article is that a clear understanding of the difference between where a record begins its life and where it spends most of its life is important to have documented. The system of creation may play a brief yet important role early in the life of the record. In fact, the system of creation may never “see” the record again until it is decommissioned or otherwise removed from the business processes. 

Documented processes are necessary to keep these two systems—specifically the records they are “sharing”— in sync with each other. If, after creation, that initial record needs to be updated at some time in the future, then it may be necessary to also update the “mostly system of record.” This can be tricky depending upon how the two systems interact with each other. 

It is very common that the system of creation will only provide a few basic attributes (data points, fields, etc.) about the record, leaving the bulk of the lifecycle attributes for the other system(s) to populate. Automation may be developed between the systems so that when a new record arrives in the system of record, the record is acted upon using templates and other sources of information to more fully populate it. The record may also be put into a “not quite ready” status until a person deems it ready for consumption by other systems or users. Once made “active,” the record can continue its lifecycle.  

System(s) of Interaction 

One aspect to consider is the system(s) used to interact with the record. While the record may be the same, the impact of the applications on the record as users go about their business is important. 

For example, is there a difference in what users can do to the record whether they are using a desktop/browser-based application or a true mobile application on their phone or tablet? How about the impact to the record if the user’s mobile device is off- or online? It can be surprising when looking at changes to a record during its lifecycle if there are differences in what the user can do to it depending upon the system of interaction they are using. 

Avoid the “How did this happen?” situation by having a clear understanding of the applications that users employ to manipulate the record. Is there a difference between the system of creation and the official “system of record,” in relation to the record they are working with? 

Pulling all the data together in one place 

Given the most likely scenario where the data elements of the record are spread across systems, this can cause difficulty for those who are trying to report or respond to auditor requests. A process where a reporter needs to gather disparate information about a record across systems is not the most efficient approach. 

If this is the situation, the use of business intelligence tools (like what tools) can not only make the process more efficient, but also greatly reduce errors in the final product. Through clearly documenting where the asset began and where it lives as well as documenting the prosses is helpful to maintain the connection between systems.   The reporting requirements can be pre-established, and the joining of the data elements into a cohesive view of the record can be far more easily performed, or even simply automated. 

TRM has been in the EAM, mapping, and system integration business since 1993. We have vast experience across industries in integrating multiple systems to pass records back and forth to suit the needs of the business and the related processes.  

TRM is in a unique position with not only our across-industry experience, especially those that are heavily regulated, but also our ability to work with clients from the initial planning and requirements gathering all the way to the end of the implementation… and beyond. 

Reach out to us to discuss what your requirements are and let’s see which options we offer can be supportive. Of course, we can form a full proposal and project plan that will cover the entire process and any ongoing support.