Posts Tagged ‘equipment manufacturers’

Transitioning Tribal Knowledge to Training (Part 2)

Thursday, April 8th, 2010 - Posted By: Scott McDonough

A couple of posts ago I was talking about subscription-based e-learning and training services. The gist of that post was simply that “yes those options have their place,  but by their nature they aren’t very good at addressing a need for turning tribal knowledge into effective training.” (More or less…you can find that post here.) 

This is a challenge that presents itself to organizations frequently,  and while not much of a stretch to accept, the question then becomes “how?”.  If you acknowledge that yes, we have a need to capture our tribal knowledge and then make it accessible to and train others on within the organization,  you probably understand all too well that this is not something you are going to be able to purchase off-the-shelf. Therefore the next step is determing how to get it done.

The “how” depends greatly on the organization. A large company equipped with an internal training group may have access to tools, personnel, and budgetary resources that a smaller, mid-market manufacturing company does not. The challenge is the same, but the approach can be vastly different.

I call out this differential in organizational size for a reason. Again, the challenge to capture and make use of tribal knowledge is similar, but the problem can be more difficult for the mid-market company. Their business is manufacturing; most of the organization is dedicated to making product. They often lack the resources of a larger organization, so the requirement to not only solve the problem, but to do so in a way that has a minimum impact on the budget and sans dedicated internal training resources. Which is not to say that any of these suggested tips would not be beneficial for the larger organization as well; I just feel it’s important to acknowledge the often overlooked and unique challenges that the mid-market faces.

Here’s some tips to keep in mind as you develop your own program to capture and train on tribal knowledge:

1. Acknowledge the need. Well, duh. Seems obvious, but you can’t develop a plan to capture the tribal knowledge that exists within your organization until you’ve assessed that there is a need.

2. Make a clear business case that shines a spotlight on the need and will help win support for the initiative.  Is a good percentage of your workforce of retirement age? Are organizational silos preventing the exchange of critical business process information? Make a list and write down the specific reasons why developing a system to capture and train on tribal knowledge will benefit the organization. The process of writing down and working through the “why” will help shape and hone the eventual “how”. This can be a long and drawn out process; be prepared to remind everyone why you’re undertaking this effort, especially in those times where it gets difficult and progress seems slow at best.

3. Implement a workflow process that encourages sharing. Sounds pretty vague, but the basic idea here is that you need to shift away from the old way of communicating. This will no doubt be very difficult, but instead of sending an e-mail to Joe down the hall to ask about a specific process that needs to be documented for training, send him a link to a intranet or web page where he can enter the information. Done the old way, Joe believes he’s told someone how something is done, but that’s part of the problem, he’s told someone. Really take the time to think about how you can facilitate a collaborative method of capturing knowledge. This way, even in-process, the information that will eventually be developed into some type of formal training program can be accessible and useful to others. We’ve seen greater frequency of the use of internal wikis that can be incredibly useful in this regard.

4. Go talk to people, but don’t hassle them. Not everyone in the organization, especially in a manufacturing environment, will have access to the company intranet. Therefore, you’re going to have to go talk to those people that often times, know “the real story” about what makes your company tick. Be smart about it though, you’ll get little cooperation if you just hang around and randomly appear to pick their brains. Instead, make a plan of what information needs to be captured. Identify those individuals that are likely to be the most knowledgeable by talking to the person responsible for maufacturing operations. Schedule time to meet with those people and have a clear agenda of the type of information you need to capture before sitting down with them.

5. Determine how you will present the training information and make it accessible.  As a manufacturer, you may not have the staff resources or know-how to develop an effective training program, but don’t panic. The good news is that there are numerous options available these days to help with the technology side of your training program. Break the technology requirements into pieces that correspond with specific goals rather than trying to find one application that will do everything.  In this way, you can focus on tools that are right for your specific requirement, rather than pay for a single service or suite of tools that are more than what you really need. 

  • Composing the content. Widely reviled by training experts everywhere, there’s a good reason Power Point remains prevalent. Organizations exactly like mid-market manufacturers already have it, and most everyone knows or can figure out how to use it. There is no shame in using PowerPoint, especially now that there are many training development applications that will allow you to directly import .ppt files. Is it the best or most capable application in which to develop training? No, not by a long shot. However, if software selection is the obstacle preventing  you from starting the process of formalizing captured training content, by all means fire up Power Point.
  • Distributing the training. Your company intranet is an obvious, simple way to start. Share Point is particularly well-suited to the delivery of training materials. Or, you could create a simple HTML-based portal to display links to the training content. Microsoft and Adobe also offer applications that allow group collaboration that can be useful for hosting real-time instructor-led training directed to a group of people. Dedicated learning management systems sure offer some great functionality, but don’t let that stop you from finding other ways to distribute your content.
  • Measuring retention. How do you know if someone has actually acquired the knowledge you’ve attempted to pass along? You’ll want to develop quizzes, tests, or practical hands-on skill evaluations. These can be accomplished in many different ways. Be sure to think about not only the format of these retention-measuring devices, but how they will need to be managed as well. What adminstrative requirements will there be?  Most professional training development software, like Adobe Captivate for instance, integrate the ability to add quizzes and tests into the training course, as well as allow for the  delivery of these results. However, get creative and see what low-cost or free services are out there as well. These may not be permanent solutions, but a Google search for “develop online quizzes” should get you started and perhaps thinking outside the software box as well. Again, when cost is a primary concern, try to identify simple services to meet specific requirements for each major function of your training course.

6. Be realistic and patient. Most of us can appreciate really great training when we see it, and most of us always want to create the best we can. However, understand that all the bells and whistles have some cost associated with them. It might be nice to have an interactive, exploded view of equipment for the maintenance technicians, but how realistic is that today? Think of your tribal knowledge capturing and training project as a living one. True that the 3D animation of a process might make it easy for some learners to visualize, but it’s not worth stalling out the development of your training. You may have to settle on a handful of static images or engineering drawings for now, but that’s ok.  As the organization as a whole recognizes the importance of and progress made on capturing and delivering tribal knowledge training, these things will come. It is far more important now, during the first stages of formally developing this training that something gets done as opposed to nothing at all.

Granted, this is not the sum total of the concerns you’ll be dealing with as you take the first steps towards developing your own tribal knowledge training program, but I hope you find these items useful as guidelines.

Good luck, drop us a note here if you’d like further information or need some help.

 

 

Technically Exhaustive, Literally Unusable

Thursday, April 1st, 2010 - Posted By: Scott McDonough

Nobody reads these things anyway.”

If you’ve spent any time thinking about, developing or using technical documentation, it is likely you’re familiar with this old chestnut. The reasons behind this dismissive utterance may vary: too much information, not enough information,  problems with accessibility and navigation, language translation issues, etc. but any or all of these reasons are assuredly more than enough to relegate “the manual” to dust-collecting duty on a shelf somewhere.

Those responsible for creating technical documentation bristle at this sentiment, even as a generality. We are very quick to counter and extol at great length ( just ask next time you’ve got a few hours to spare…) the absolute critical necessity of quality technical documentation and the positive business benefits it can bring.  Yet somehow and despite this fact, there is no shortage whatsoever of product support documentation that yet again, will elicit from the user a resounding “huh?” at best.

It’s the “why” of this that remains of great interest to me. If the people who write the documentation know that there are ways to create something that would be more well-received, why aren’t they doing it?

It is because at the end of the day, the organization creates technical documentation through its business processes and policies, not the technical writers. Technical writers learn from day one that “above all else, consider your audience.”  However,  the vast majority of technical documentation we encounter on a daily basis would never lead you to believe that the user was of much concern at all.

By and large we accept this. Poor or unusable documentation perpetuates the notion that most of it is terrible, and therefore it’s not news nor a surprise to anyone. It’s just the way it is. The attitude that “nobody reads these things anyway” persists.

Why does this happen? What’s going on inside the organization which clearly places some measure of value on the importance of technical documentation, yet continues to put out materials that their customers aren’t using?

Well, here are some of the more common symptoms and causes that we’ve observed:

  • TMI (Too Much Information).  Apparently, if it has been written down and has to do with the product, then it must be included. All of it. Not only does this super-level of content make it extremely hard on the user, it makes the documentation development process extremely time consuming. The focus shifts away from usability to making sure there’s enough time to pack everything possible in, regardless if its quality or usefulness. “Better to have it in there than not!” is the default decision on questions of content and all too often this just makes things worse.
  • Writing style “of the engineer, for the engineer”. Often times when dealing with documentation that covers a particularly complex product, the end result can end up looking like a mildly breathed-on series of engineering white papers. However, if the user of the product is not a design engineer, but perhaps a technician or operator, this documentation will be of little use. It is the job of the technical writer, as the advocate for the audience, to make this information as accessible as possible. However, not all documentation is created by professional technical writers, and sometimes there’s just not time to properly re-work the content to a level that is sufficiently palatable for users. If the former is the case, perhaps those responsible for the development of the technical documentation should be trained on how to interview technical subject matter experts.
  • Failure to focus on the audience.  This dovetails in with the above, but much of the technical documentation we see regularly would benefit greatly simply by assessing it through the eyes of the user. If I am told that it is my responsibility to maintain a piece of equipment, then I, as the user of the manual that came with the equipment  want to be instructed on how to troubleshoot and repair. Chapter and verse regarding theory of operation will mean very little to me. Tell what to expect from the moment I open the box through installation, configuration and maintenance. Any information beyond that may be of little concern to me right now, so simply tell me where to find the rest and if I need it I’ll go looking for it. Most often, this lack of focus on the audience happens because it gets squeezed out in favor of trying to get every possible piece of information included as a priority. It is absolutely worth questioning and re-evaluating who the users of your technical documentation really are.
  • Deadlines and Industry Specification Requirements. For those companies that manufacturer many and diverse products, there’s simply not enough time to pay too much attention to usability. It’s hard enough to keep up with getting out any sort of documentation much less pieces that really focus in on and work for the users in a meaningful way. If you manufacturer certain products that are subject to regulation, it’s easy to fall into the routine of just meeting the minimum requirements for the documentation; requirements that do not necessarily account for what might work best for your users.

All of the above are symptomatic of the widely-held opinion that technical documentation is regarded as a “necessary evil” .

The realities of business processes and policies often limit the potential advantages that technical documentation can offer both the manufacturer and their customers. However, this can only be properly addressed when the organization chooses to make a proactive change. Otherwise the cycle of “it’s no good but no one reads these anyway/no one reads these anyway so it’s ok if it’s not that good” will continue to persist.

 

What is a Structured Document?

Monday, March 22nd, 2010 - Posted By: John Crews

This is a question commonly asked by our customers when we begin working with them on a single-source solution.  There is a short answer:

A structured document organizes paragraphs (elements) in a logical hierarchy, provides a means to attach tags (attributes) to individual paragraphs (elements), and gives you the ability to view the document in multiple ways.  FrameMaker ® (and other editors) also gives you the ability to manipulate the content of structured documents so that you can supply different outputs from the same document.

For this discussion, I will be using Adobe® FrameMaker® as my editor.  FrameMaker’s what-you-see-is-what-you-get view of structured documents is called the Document View.  If you have worked in unstructured Frame, this should look very familiar:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note, that all text is enclosed in brackets.  These brackets indicate element boundaries on the WYSIWYG view (Document View).  This correlates to the Structure View hierarchy described later.

The second way to view the document is called Structure View in FrameMaker.  The Structure View shows all elements (paragraphs) arranged in a hierarchy.  Each box represents an element.  An excerpt of the element text is displayed to the right of the element.  Below each element are Attributes assigned to the element.

The example highlighted below shows that the first element Bullet1 is assigned a value of 1 for the attribute Output.  The second element Bullet1 is assigned a value of 2 for the attribute Output.

In addition to managing the attributes and hierarchy of elements, you can also perform some edits in the Structure view.  If you right-click on an element, a context menu appears that describes several possible actions.  Typical shortcut buttons (ctrl+C for copy, ctrl+v for paste) function normally.  You can also drag-and-drop elements to move their location or to change their place within the hierarchy.

Most users who are accustomed to unstructured FrameMaker are used to working with the formatting toolbar.  Structured Frame does have this functionality; however, it also introduces an Element Catalog in place of the paragraph catalog.  The Element Catalog lists elements that may be selected to insert into the document and provides a tool-set for managing elements as you create them.  Using this catalog, you can insert an element into an existing element, wrap an existing element inside of a new element, and change the type of an existing element.  This tool set helps to minimize the complexity of managing the content from the Structure View.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Once you have an element in place, you can assign attributes using the Attribute Editor.  The editor displays potential attributes for a selected element and lists the predefined values that may be assigned.  Select the desired attribute, assign an attribute value, and then select the Set Value button.  This assigned value is then visible in the Structure View.

 

 

 

 

 

 

 

 

 

 

Using the Structured FrameMaker tool set helps to make management of complex single-sourced documents easier.  Creating a functional hierarchy allows you to manage content at all levels.  Attributes allow you control several output levels and types while ensuring that you are able to maintain accurate content.

Import Images by Reference – Advil for Drawing Revision Headaches

Wednesday, March 10th, 2010 - Posted By: John Crews

Our Customers Ask…

“Our company frequently revises our engineering drawings.  Several of these drawings are included in our product guides.  How can we efficiently ensure that the latest drawings are included in our manuals?”

PPI Answers…

We use a repeatable method to ensure that our customers’ latest drawings are always included in documentation.  The key lies in the way we import images.

When you insert a drawing into an Adobe® FrameMaker® document, you have the option of either embedding or referencing the image file.  If you select the embed option, the file is imported as a static part of the document.

Instead, selecting the Import by Reference option tells FrameMaker® to check the source file each time you open the document.  This means that if you change your drawing, save it in the same location by the same name, then FrameMaker® will display the updated image next time it opens the document. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Voila! Automatic drawing updates!   The tricky part is building a sustainable file structure that allows you to manage the images while retaining revision control.  Most organizations use the name of their drawing files to track revisions.  This can still be done while setting up a file structure that promotes referencing vs. embedding image files.

 A common file structure might look like this:

Each file name includes a brief description of the file and shows what revision.  Users can tell at a glance what file is the latest revision.

 In order to make the best use of the Import by Reference option, you might consider adding an Active folder to your file structure.  The files in the Active  folder should not have the revision information in the title.  For example

 

 

When you update a drawing, follow these steps;

  1. Save the file as you normally would.
  2. Save a copy of the drawing to the Active folder
  3. Rename the file so that it has the same name as the previous revision.  This way, FrameMaker knows what drawing files should be displayed. 

Managing your files this way saves you the nightmare of hunting through existing documents and replacing images every time a drawing is revised.

Is Your Product Documentation Letting the Side Down?

Tuesday, March 2nd, 2010 - Posted By: Scott McDonough

Look at any trade magazine, industry e-newsletter or website and you’ll continue to find evidence of dollars being spent in the pursuit of the next sale.  Even in economic downturns, (or perhaps exactly because of an economic downturn), it seems manufacturers are still willing to go to just about  any length to get the word about their company and extol the virtues of their products.

In today’s world of user-friendly and largely free social media tools, it’s understandable that this trend continues. In relatively little time, with relatively little cost, manufacturers large and small can stake their claim on the web and create a fresh,  forward-facing identity to engage potential customers with a whole new strategy. Manufacturers across the country and the world are scrambling to become experts in the brave new world of social media. Facebook, Twitter, and YouTube used to be banned during working hours, now they’re almost a requirement.

And let’s not forget the more traditional methods of marketing, including the entirety of various MarComm initiatives, as well as ad buys in the aforementioned trade journals and/or banner space in e-newsletters, trade websites and the like.

However you as a manufacturer define your strategy of getting the word out about your products, it adds up to a significant, concerted series of costs and efforts designed to generate leads, and from leads, sales.

But what happens after the sale? Have you considered that your product documentation is letting the side down? Or even worse, could your product documentation be preventing a sale?

For your consideration:

  • Given all the time and effort that go into creating a brand that properly targets and engages your customers, does your product documentation support the perception of your brand? Is the gleam of your world-class marketing effort being dulled by a ratty binder of photocopied sheets that you affectionately refer to as the “operator’s manual”? At a minimum, stop and consider what kind of impression is left on your customer by your documentation after the sale.
  • Are you using your product documentation to sell after the sale? If your product requires consumables, service parts, or optional upgrades, you should be.  From the correct contact information for service reps to detailed information on the benefits of genuine OEM consumables to instructions on how to get spare parts, it’s always worth your while as a manufacturer to ensure you are taking advantage of this opportunity to make these additional sales. Do you offer product or process-specific training for customers? Why not include this type of information in your product documentation as well?
  • Is your product documentation available online? Many people use the availability and quality of product documentation as a factor in their purchase decisions. Is yours available online, and if it isn’t today, would you have any reservations about making it available online as it stands today? Could be one more reason for your customer to decide to buy from you. Even if you deal strictly in custom equipment, it may be worth creating a “generic” sample and make it available to potential customers of an example of your world-class products and support.
  • Take a look at your competitors’ product documentation. Is yours comparable? What things do you think they do a better job of, and what things do you feel you do a better job of? Next time your boss asks you to sit in on a marketing strategy session, it would be worth your time to have this list or some examples handy.

Product documentation is often overlooked or dismissed as a necessary evil, yet it should have just as an important role as every other play in your marketing strategy playbook. Don’t make the mistake of allowing it to let your side down.