©2015 Mark Henderson
Fair enough—it certainly sounds like common sense at first blush. The implied corollary is: “What value could we possibly add to what the OEM wrote for the equipment they designed and built?” Well, the answer may be “None”, as far as how that OEM manual or OMI or user’s guide is used in your business. But, if your business were my business, I would want to look at every tool I use—to do whatever it is I do to make profit—in order make darn sure that it’s (a) the right tool, and (b) being used the right way. In many applications, the OEM-provided information (e.g. manual, user’s guide, OMI) is a tool for me and my folks to do whatever it is we do—safely, efficiently, and of high-quality. So, how do we exercise our due diligence to ensure we are using the right stuff the right way?
What value could we possibly add to what the OEM wrote for the equipment they designed and built?
Well, we first start by reading the OEM document(s). This is just from my personal experience, but many of the folks who utter the “We just use the OEM book and we’re not going to improve on that…” line remind by of CEO Frank Shirley in the film Christmas Vacation when he growls to Clark Griswold (Chevy Chase), “And don’t bother me with all that techno-mumbo jumbo either!” Many times, the OEM document is foisted upon the technicians or programmers or whomever is actually doing the work by persons who have never even cracked the book.
After reading the OEM documentation, there are two similar, but different questions to ask: (1) “Is it good (or good enough)?” And (2) “Is it good enough to use for our purpose—the way we need to use it?” If after reading the OEM documentation and the answer to those two questions is “yes”, then there is no ROI to reproduce this in your company format.
Is the OEM documentation good enough, and is it good enough to use for our purpose—the way we need to use it?
However, in my line of work, I read ullottuv (i.e. piles, scads, tons, bunches, etc.) of OEM technical literature. And if you’re one of those whose job it is to try to use OEM technical documentation to accomplish your task, it will come as no surprise when I say that I find less than a third—maybe even less than a quarter—of the manuals or user’s guides I’ve studied to be even marginally comprehensible. Everything from the order in which the information is presented to the logic used in ordering the information to the actual words used, most OEM manuals are of little value to the actual users. In fact, most techs I work with use OEM documentation the first time the thingamajig is used. After that, it’s “tribal knowledge”, or this guy teaching the next how to do this or that to said thingamajig. And most of these folks are executing their tasks under some statement or requirement to utilize the OEM’s data to perform their work. Now, this is no way a lick on the techs—rather, it’s a testament to good people who will somehow find a way to make things work in spite of inadequate documentation!
Most OEM manuals are of little value to the actual users.
So, casting the above anecdotal information aside, let’s say the documentation you received from the OEM is high-quality, sensible, well organized, and technically valid. But, is the OEM documentation everything you need for you and your team to perform your tasks predictably and safely? Is it sufficient the way your team uses the thingamajig? Ask yourself, “Are we giving our people the best tools we can to accomplish our business’ mission?”
Make sure that we give our folks the best tools to do what they do.
Maybe we should reject the Mr. Shirley philosophy and go read all that “techno mumbo jumbo” to make sure that the tools we give our folks to do what they do to make our business profitable are the best tools—that the documents we require them to use are clear, concise, and valid for what we do—so they can do the best job we’ve hired them to do.