Something we run into as we educate companies about the power of digitized procedure content and the benefits thereof is this idea that if procedures are PDF’d and stored on a network drive, that’s enough to check the box that procedures are in fact “digital” and therefore no action is needed.
Why is the word “digital” so important? It carries weight because most industrial companies are ploughing ahead with digital transformation efforts to make their businesses more efficient, more productive, automated, and rich with data that can be used to measure improvements to processes, mandates, and production goals.
If something is digital, that could mean it possesses attributes or characteristics useful to a user that are more beneficial than an analog version of the same (non-digital). If you have procedures as individual files loaded onto a drive or access point somewhere in the organization, isn’t it reasonable to say that you’ve traded one form of a library for another? Card catalog vs green screen computer if you will to look up something in that library? You gain speed yes, but I think you see where I’m going.
Adobe has gotten wealthy on the PDF format. Portable Document Format (notice D doesn’t stand for Digital) has served an invaluable purpose to exchange documents for business and for personal reasons. We can’t live without it, and nobody has stepped up to the plate to replace it. It’s just too prolific. Let me say right now that I’m not here to bash PDFs whatsoever, they serve their purpose. What I’m about to illustrate is that PDFs don’t equal digital transformation and don’t constitute the endgame for procedure operational excellence.
Let’s say for instance that you want to get procedure content onto a mobile device, a perfectly logical thing to try in a digital transformation journey. Is this possible with PDFs? Yes, in theory, but with a heavy dose of scrolling up, down, back, and forth as your screen becomes a magnifying glass of sorts on a document not intended for that purpose. What about integrating step signoffs and readings? That’s only possible if every PDF is altered by technical writers to enable those features. And those readings and signoffs go nowhere but the printer in many cases. Not digital for sure.
Where am I going with all this? To have the power to perform procedures on a mobile device natively or in other words data on the screen is not a PDF but instead is content designed for mobile devices, you must digitize the procedure steps and get them into a database. Only then can you serve up the right content to a tablet or smartphone. In this scenario, all procedure content is normalized, categorized (step types, step properties, etc.), and augmented to make it compatible with a mobile experience. This is starting to sound like operational excellence.
I just used a few phrases related to procedure content that are worth defining. Normalizing procedure data means making the data consistent without variation. For instance, action step sentence structure is predictably organized, and formatting is hard-coded into the output renderer so that everything looks right without lots of heavy lifting by technical writers who loathe formatting.
Step types are important because we need to know how to present the step content to the user. It’s obvious that action steps should look and behave differently than caution and warning steps. Finally, step properties are huge because that’s where we determine if steps require sign-off, by whom, if equipment or other assets are associated along with all their properties, and if we are going to require readings from those assets. These example attributes of digital procedure content: normalized, step types, and step properties allow you to take command of your procedures.
We shouldn’t quite yet eliminate the ability to print paper PDFs of procedures. In the future, paper procedures will be a thing of the past but until then you should want and accept no less than the flexibility to get the procedure content “in any format, on any device”. Paper PDFs will never get you there as they are intended for only one purpose, to be printed. And you’ll likely not have one interactive version (the dreaded PDF “form”) and one non-interactive. Technical writers don’t have time for that, and operators tell us using PDFs on a mobile device is painful at best.
The only way forward is to adopt a digital procedure database, a hub-and-spoke approach that allows procedure content to be created any way a user wants, from various print views fit for purpose to a mobile device, for training, and for administration, all human factored for the best experience possible. ATR’s SmartProcedures accomplishes this by design, enabling the right tool for the job at hand, on-demand. Now that’s power.