Sidney, good point but company has to be careful to not allow the tail to wag the dog, so to speak. Ideally, the process is defined and the tool implements the process. Having a tool define the process is, from my experience, a risk that can lead to all sorts of process deviations ("well if the tool supports it, it must be ok"). This is especially true in a large, "do all" application like Trackwise (from what I understand of it).
A software application should be used to meet its intended purpose. You don't want to end up using your hammer to drive a screw.
A software application should be used to meet its intended purpose. You don't want to end up using your hammer to drive a screw.
What if one site uses the software and one site does not? The process concepts may be identical, but the identifying best practices from one location or another could be benefit the organization (and process) as a whole.
The audit may also uncover that the tool DOES NOT support the process. What if data is not able to be viewed in such a way for trend analysis and the site is unable to speak to recurring issues other than 'I remember this one time...' examples (i.e., impact on failure analysis)? What if the documented procedure is not aligned with the steps the software takes (i.e., impact on training)?
Standardizing a process should include more than just a documented procedure. It is also helpful to standardize the tools used, be it a software or a manual log. When assessing a process, my own experience has been that it is valuable...and value-added...to include how the tools support the process on a day-to-day basis, as well as from an improvement perspective.
Last edited: