Introduction
This article is a continuation of our discussion on the importance of having a FRACAS/DRACAS – “What is a FRACAS or DRACAS – part 1”.
In the previous article we discussed 2 things; the importance of data collection, and the two components that form a FRACAS/DRACAS, namely the process and the facilitating IT system.
In this article we will delve into more detail of how a FRACAS/DRACAS helps you achieve the top 2 points mentioned, out of the 3 below.
Point 3 – “Leveraging data“ will be covered in a separate article
- Collect data correctly
- Store data correctly
- Leverage this data
1. Data collection-using FRACAS
Note that we will be using ReliaSoft XFRACAS as an example software tool.
What data are we collecting?
“Data collection” is a wide net to cast, so let’s state now that we are not talking about streaming sensor data but rather, we are focusing on the recording of failure records, maintenance records, test results etc. We will discuss streaming sensor data and IIoT in a separate article.
The recording of this kind of data is typically completed by us humans, and is manually entered into a software system, such as a FRACAS. For example, an engineer could enter data about maintenance data to a centralized system through a web app, whilst on routine inspections.
Designing forms
As we would expect multiple users to be entering data at any given time, we must design ‘forms’ to ensure consistency and to guide the user to capturing the required data fields. We may also decide to have different forms available depending on the users’needs.
Because we are asking people to fill in these forms, their design deserves careful consideration. We must decide exactly what data we want to capture, without overwhelming those filling in our forms. History shows us that the more difficult or complicated this task is, the less likely we are to obtain complete and accurate data.
Here are some critical questions to ask:
- Which fields need to be captured?
- Some will be mandatory, some optional.
- Downstream usage of data needs to be considered.
- What is the maximum number of fields to include?
- No engineer wants to fill in 50 fields on a form, after attending a 3-hour breakdown; data which is critical for your FRACAS.
- How to capture each field?
- For example; should I use a drop-down menu, and how many options?
- Some ‘free text’ fields may be desirable, but include too many and you will have an incredibly difficult data set to work with.
Asking these question results in every company having unique data collection forms. A ‘typical’ FRACAS Incident form might contain the following fields:
Using forms
In reality, there will usually be at least double the number of fields, specific to the company, and depending on the data requirements.
Designing your forms is the hard part, building the form should be relatively straight forward – if you have the correct tools. When building your form, you can design its visual structure and the data types of the different fields.
Here is an example of an incident form built in ReliaSoft XFRACAS. This is what the engineer would see after accessing the XFRACAS website and choosing to open an Incident from:
2. Data storage–using FRACAS
This is the dreaded IT part; how you are going to store this data.
Can I just use Excel?
It is common for companies to start with something small scale and simplistic, which is good practice, as you shouldn’t wait until you have a fully capable system to start collecting data. Better to collect something in Excel than nothing at all.
Why use a database solution?
When the time comes to take on a more capable system (and it will come!), you will likely go down the route of a centralized database solution. This allows greater control and management of the data as it grows, as well as increasing data entry and reporting capabilities.
How to make the transition?
Sometimes, making the transition to a database solution (or moving from one database tool to another)can be an intimidating move. You may even simply ‘add on’ a tool like XFRACAS to manage a portion of a much larger data set.
The main road block to making this transition are:
- Justification for moving to a new system (to non-reliability folk)
- IT resourcing issues
- Transferring your data to the new system
The first two points are not really something I can address here, and are conversations to be had internally, however data transfer is one of the biggest hurdles facing those moving to a new system. This is because no-one wants to lose their data, but they want to improve their FRACAS solution.
99% of the time, manual transfer of data is out of the question, it is too laborious and error prone. But believe it or not, this is an option people are willing to consider! A fully or semi-automated approach is possible, however.
How to transfer your data?
ReliaSoft’s XFRACAS is one of the leading FRACAS solutions, nevertheless, the hurdle of transferring data still exists. Let us look at the two ways which Data Transfer can be achieved:
- One time transfer. Data is transferred from one or more systems to XFRACAS for the purpose of migrating to a new system.
- On-going transfer. Data is transferred from one or more systems into XFRACAS on a regular basis.
When it comes to XFRACAS, there are guidelines to help you perform mass data transfers, however, developing this yourself can be quite a daunting task.
Because of this, Wilde Analysis have developed the capability to perform mass data transfers from one or more systems into XFRACAS, using bespoke coding practices to aid in solution development.
This essentially removes the concern of not being able to transfer your data into a new system.
Summary
In this article we have discussed how you would collect data using FRACAS, first by designing forms and then building them in some kind of tool; we suggest a tool like XFRACAS.
We then illustrated different approaches to storing your data, favoring the database solution, due to general database benefits that come along with it.
Finally, we illustrated how migrating to a more advanced system can be problematic, specifically because of the difficulties transferring data from one system to another.
