Could a similar approach be used in the field of technical authoring – could we have federated Help authoring systems?

There’s a number of situations where a federated Help authoring system might be needed:

A company is selling a system that includes products from other organisations. For example, a telephony solution might include handsets supplied from a third-party manufacturer. This systems integrator is likely to want the handset manuals to use their product name, “look and feel”, contact details and company logo.

Another subsidiary or department is creating documentation in their own Help authoring system, and you need to include some of their content in your user documentation. For example, these could be Knowledge Base articles created by the Support department, or embedded Help written into the application screens by the programmers. They cannot or do not want to use the same authoring system as you, and you don’t have the authority or desire to enforce your system on them.

There are a number of ways a federated Help authoring system can be set up:

One is to agree a common data structure. You could require your suppliers to make their user guides accessible in DITA format (instead of, for example, InDesign). You would need to define which text you wanted to be conditional – such as the company name, product name and contact details. In a federated model, their content would stay in their system, but could be integrated with your content when you generate the user documents. This means if they updated the manual, these changes would appear in your system.

Another approach is to simply have the content as an embedded object in your authoring system. You would need to get your colleagues to create content where the formatting information was not embedded with the content itself, and again you’d need to agree which text you wanted to be conditional.

The attraction of this approach is it minimises the effort required by the other writing teams, and it provides a solution where you don’t have the ability to establish a single authoring solution.

Web-based product documentation is often the quickest way to learn how to resolve an issue, and we can see this from statistics provided recently by both Mindtouch and Atlassian.

Mindtouch is reporting organic searches account for almost 60% of referrals to its client Autodesk’s WikiHelp product documentation community. Online Help is also the number one lead source for RightScale, another Mindtouch user. According to Mindtouch:

Rather than relying on marketing to educate customers on how Autodesk products are solving real issues, they’re using SEO-friendly documentation on WikiHelp and the WikiHelp community to show 13 Autodesk products in action.

Here is an interesting interview between Robert Scoble and Aaron Fulkerson of Midtouch on how MindTouch’s technical communication software is changing how people work together at big companies.

“We started seeing more and more of our customers—Intuit and Microsoft, Intel and Autodesk and Mozilla – launching these documentation communities where they have a body of content for user manuals,” explains Fulkerson. “Just imagine taking ten DVDs of video and text and putting it on the internet for the first time. What does that do for your search engine optimization? And then building a community around that where [customers] can contribute to it. They’re registering with the site, they’re sharing information with you about how you can improve this or that—of course it’s helping lead generation.”

“Enterprise wikis and documentation communities may sound like rather different applications, but Fulkerson asserts that they’re actually the same use case—they’re just applied to two different things. “One is internal around enterprise systems, the other one is external more around social media sites. But they’re both delivering collaboration and social capabilities in a web-based environment that’s connecting systems together.”

It’s important not to think that wikis only = Wikipedia. You could argue that applications such as Confluence and Mindtouch 2010 are wikis as well – wikis enhanced with powerful tools for software user documentation, but wikis, nonetheless.

As Scott Abel says in the introduction, most organisations have yet to manage the art of managing content. They make two common mistakes: (1) they see content as either documents or structured data, and (2) they see it as purely a software problem.

Wikis offer technical communicators a handy route into an organisations for them to tackle poor content. That’s because wiki software is generally very cheap and the techies like them. There are still issues around “round tripping” (getting content in and out, and back in again) and link management, but these are not insurmountable.

Alan, I’m pleased to say, has not been seduced by the software, but has set the use of a wiki within a very usable framework. He’s spot on when it comes to the benefits a wiki can offer and the implementation approach to take.

Standards and processes permeate nearly every area of business today. They enable management to control, direct and delegate, giving people the ability to focus attention on the more difficult issues the business faces. Processes drives predictability, consistency and efficiency.

Despite all these benefits, sales departments have been much slower to move down this path. Sales people usually baulk at the idea of processes, complaining that “form-filling gets in the way of actual selling”.

Our research clearly shows that “Winning Sales Organizations” take a much more scientific approach to selling and sales management than others. While there will always be a certain art to selling, it’s an increasingly sophisticated business world…How much better would a CEO sleep at night if he knew his sales force had a consistent, professional approach to interacting with customers! An improvement in these factors helps drive revenue predictability, reduces cost of sales and increases sales force productivity—all critical business objectives.

Miller Heiman argues that a sales process can help sales people “sell more and sell faster”.

Any successful initiative must include tools to streamline the process and remove any barriers to change. In this context, it makes sense to streamline one of the most time consuming aspects of selling – responding to Request for Quotation and other forms of sales proposals.

As we mentioned in our post “Building intelligence into business documents“, it’s now possible to create a system that can build the bulk of the document in a matter of minutes, leaving the writer with the task of customising the information to suit the requirements of each particular situation. These systems can even include training videos and text to guide a writer through the process of developing a new document, as well as enforce consistency and standards.

In the near future, we’ll be providing details on some the solutions available to organisations that want to improve the process of writing sales proposals and RFQs.

In this video clip, Ecademy’s Thomas Power talks about how business leaders will have to switch between “institutional thinking” (closed, selective and controlling) and “network thinking” (open, random and supportive).

You have to be very selective what you absorb, and the people you connect with..And you have to be in control of everything. Because public policy demands it. Shareholders demand it. Staff demand it. The law demands it. That’s institutional thinking.

Thomas has seen a shift in recent years to a new style of business. This is a shift has been away from closed institutional thinking, towards a new kind of thinking: network thinking.

When you jump into a network, you have to change all of those things..You have to be open. You have to accept everything that comes at you. You have to be random. The disorder that things arrive in your life. Completely chaotic. And you have to be supportive of everyone around you.