First of all, what is documentation? In the industrial machinery environment, documentation can be thought of as the total collection of information resources pertaining to how a complex system functions, how to install, commission and operate it, and how to maintain and troubleshoot it. For a system that has been in place for a number of years, documentation should also include a historical record of changes, repairs, maintenance activities and developed best practices.
Is it reasonable to expect a team of equipment operators and maintainers to do their best possible work without a comprehensive collection of well designed, accurate information resources? If we look to the world of commercial aircraft we find that the standard and expectation for up to date and accurate documentation is very high. This is understandable given the reliable nature of gravity and the burden of responsibility that falls on those in charge of public transportation.
The reality for many industrial environments on the ground seems to include a story or two about a system or a number of systems within the machinery fleet, or at the mill, plant or mine site where some or many of these resources have gone missing, were never created or are badly out of date. A system schematic is one example of a document that is often not accurate and therefor not useful for system learning and problem solving. There are a good number of reasons that can explain how a schematic turns out to be inaccurate. What is more interesting is how a good number of years can go by with no resolution for these inaccuracies.
Another example of the documentation crisis involves the experience of individuals who work with the complex systems in question for a period of time. It seems like an obvious loss of intellectual property or capital knowledge to find these individuals moving on from the plant or the machinery team without having recorded or passed on what they've learned over the years. Yet this is precisely what happens at so many sites.
One last example among many comes from the program running within a programmable logic controller (PLC). While I don't compile precise statistical data, a fairly high percentage of PLC programs are very poorly documented. If the original programmer doesn't stick around or make it a goal to train another person at the site, the electrical and instrumentation team is left to struggle through their use of the PLC as a plant system diagnostic tool.
The question I often pose to team members in the industrial environment is; how will operational performance and equipment reliability goals be reached without addressing the documentation crisis that seems so prevalent? If the documentation crisis is not an impediment to reaching those goals, then perhaps the goals are not set high enough. Perhaps in that case the goals are not sufficiently based on the expectation of deep learning within the team.
How are you addressing the documentation issues at your site?
