Introduction
Software packages and algorithms help speed up calculations in Reliability Engineering Analysis. And obviously in other specialties. They are known as Commercial Off-The-Shelf (COTS) Software. Preprogrammed formulas can be readily applied by the analyst to provide modeling results. Additionally, graphics and other informative visual representations can be obtained at a mouse click. This helps showcase issues in an operating environment. And lead to relevant action to address those issues. Our human brain has cognitive limitations when analyzing highly complex systems such as Reliability, Availability and Maintainability (RAM) Models. Software helps to overcome those limitations.
The same results could be obtained by programming inhouse software such as MS Excel, MatLab or Python just to name a few. However, this is tedious and often prone to programming errors. After all, why reinvent the “COTS wheel” that’s already offered, arguably for a fee. Don’t we all use handheld calculators even though we could do the same mathematical operations in our head or on paper?
Understanding the Fundamentals
Performing Reliability calculations on paper could be an important aspect of understanding the fundamentals of Reliability Engineering. An example of Reliability hand calculations is provided in Diagram 1 below. The objective is to graphically calculate the scale (η) and shape (β) parameters of a Weibull distribution. And subsequently modelling the data set provided. Therefore, mastering the Reliability fundamentals is like understanding what is under the bonnet of the automobile we are about to purchase.
Blindly applying formulas can lead to wrong interpretation of results. In Reliability Analytics, it is important to apply what we would qualify as “good engineering judgment” to a result. Asking for example, does the results or interpretation match reality? Often, a distribution that fits a set of data perfectly (such as the example in Diagram 1) could eventually be an incorrect model. Therefore, using software blindly can lead to major errors in decision making. And can be costly to an organization.
Software comes at a Cost!
Reliability Software, especially the most popular ones, are expensive. Both at purchase and over time as a lot of them require periodic upgrading and maintenance fees. They can also have additional functionalities we might never use.
The purchase of Reliability Software should therefore be carefully assessed. And this, as part of the overall Reliability Strategy of an organization. In other words, what processes must be established and implemented before the decision to “cut a cheque” is made?
Buying expensive software without mastering the fundamentals including required work processes, is akin to putting the cart before the horse. I can say with a lot of humility that I personally, have been guilty of this oversight in the past.
Asset Data and Records Availability
In order to feed our software “horse” with “fodder” so it can move our Reliability Analysis “cart”, we need data. Data is the fundamental input to Reliability Analysis. Typically, though not necessarily (1), this data comes from the Computer Maintenance Management System (CMMS). The latter might be another expensive COTS software addition to our list.
Then comes the question of: do we have good data management processes (e.g. ISO 14224) in order to enter and extract records from our CMMS? Again, the question of having a well-established Reliability Strategy comes up.
Therefore, sound reflection should be applied before spending a company’s hard-earned cash towards software purchase. One should also understand the basic theory behind the software algorithms. And avoid ending up with a “white elephant”.
References
1 – Larry George, 2024, Do the Best You Can With Available Data, Accendo Reliability.
Comments from Syed Dilawar Abbas (LinkedIn)
“Thanks for sharing these fundamental considerations regarding RAM software procurement—completely agree with your perspective.
We recently underwent a similar exercise and procured a solution with long-term utilisation in mind, treating it as a structured project rather than just a quick engineering fix. We started with a thorough requirements analysis to clearly define our operational and technical needs. This allowed us to evaluate available options based on functionality that directly aligned with our objectives.
Rather than building a solution from scratch, we opted for a commercial off-the-shelf (COTS) product and then made minor customisations to ensure it fit seamlessly within our environment. This approach not only accelerated implementation but also helped us stay within budget while still meeting key requirements.
Overall, the focus on a needs-driven selection process, combined with flexible customisation, proved to be both efficient and future-proof.”