Developing a RAM (Reliability, Availability and Maintainability) Modeling and Simulation exercise seems to be a smart thing to do, when trying to fight the uncertainty during project’s early stages, or while trying to define and tune asset management strategies. As in many other things in life, just applying the recipe may not end well. A good understanding on where to focus the attention and effort is required. Here some clues that may work in your next RAM Assignment.
Mind the name
“RAM modeling and simulation” is a misleading name, and the method itself is arguably one of the less understood reliability methods out there. Most engineering teams simply don’t know what to expect from a RAM analysis, so always make sure people: get what this thing of RAM is about, what the possible levels of analysis are, and what the effort required is for valuable results to be obtained.
RAM Models are sold as the holy grail of objectivity and accuracy for business performance forecasting, and so is true, but only under ideal conditions which are rarely present. Performance references generally require some judgment to be used inside the model, operational rules may need to be simplified before being integrated into the model. Other things are simply unknown at a certain project stage of maturity, so sensitivities need to be defined and played to size a range of possible outcomes. Check these and other sources of variability and make sure never over promise. RAM is deeply sensitive to inputs and such inputs are rarely 100% controllable for the modeling or engineering teams. Be conscious of such restrictions, make such limitations known to the rest of the team, always record and show your references and when possible size the uncertainty of the forecasted model outcomes.
When possible, don’t be late:
Nothing worse than having a RAM modeler standing up to the angry faces of engineering teams with the “now you tell us?” painted in red in their faces. Be aware that RAM analysis called late will suffer the pressure to “match” previously approved decisions, so take the energy required to substantiate and show the value of your results.
Never jump to the tool:
I’ve never seen a brochure where the software vendor tells me something like “keep in mind that this software doesn’t do all you need”, or “brain still required”, but that’s the case always in RAM Modeling and Simulation. Take the time to sketch your model in paper, take the time to decide among the modeling resources that may better fit to your needs, visualize the implications of using each modeling alternative to represent the system, and keep an organized record of the modeling and simulation requirements and assumptions. Those small things will save lots of hours wasted “trying” to represent a behavior, and will allow you to control when the model is going to be ready, and results available.
Don’t be boring:
Showing forecasted results and improvement ideas is your moment of glory, so avoid long explanations on how smart you were to represent such a miserably super complex process with just two blocks. You were hired for saving business value, so focus your talk on explaining how to save business value; just make it clear what threatened the business value, how discovered options solved the issue, and why you’re so sure your findings are correct! Luckily someone will ask you the “how” and then you’ll do your show, but meanwhile keep the results presentation simple.
Thanks for your reading!
That’s all for now. It would be nice to read some other [thrive_2step id=’749′]key advices[/thrive_2step] from experienced modelers in the comments.
…Be good and keep alive!