Knowledge Networks

Knowledge Networks deal with communication strategies between participants (which include networking of key and similar participants) as well as documentation strategies.

Communication

While process owners have their own teams, the process end users are the team leaders for teams implementing those process. This separation of concerns allows for efficiencies by focusing on what is required by who. This also requires a robust communication strategy between process owners and users.
The benefits for this is a triaging of problems within the team as "first-tier support" to solve the majority of problems affecting users. Advance problems are escalated by the Local Business Experts back to the process owners for resolving. This allows a more streamlined approach and a reduction of repetitive support requests. It also provides a trigger for a training needs analysis within the teams which can be actioned and supported separately to reduce re-occurrences.

Knowledge Networking

Forming working parties or "user groups" with Local Business Experts as members allows for a synergy and sharing of ideas and solutions as well as a way of finding common problems that may lead to further enhancements to processes or supporting systems. Business improvement can tap directly into the these groups since they are the experts in the implementation of the processes.

Knowledge-bases and Documentation

A robust and easily accessible knowledge store is the cornerstone of Knowledge Networks. Previously, documentation has consisted usually of multiple read-only files stored in a number of locations. An example of this can be found with the Case Study: Achievement Planner - Documentation. The end result is a juggling of multiple documents from different sources with analysis and user feedback of the Achievement Planning system indicating that the documents are not being referred to when initiating the plan process, causing a loss of quality. The barrier to maintain that quality seems higher than what is expected from the end users.
The fact that they are documents causes limitations in their use. Ultimately, what the end user is looking for is the context-based information within the documents, not the documents per se. If a user was to search for a specific term, keyword or phrase across multiple documents then it would be a case of opening each document and searching within them individually. For efficiency and ease of use, people today are expecting web search-engine experiences. Two software products that have extensive search-engine capabilities specifically for documents are Xerox's "Docushare" and Microsoft "Sharepoint" - both able to search within documents for specific terms returning easy to understand results in a format comparable to those found from web search engines.
This leads to a second limitation: the relationship between information contained across multiple documents. By using documents to store information, the ability to link or cross-reference different information sources is often impossible, or at best fragile and easily broken when documents are updated or the link targets are moved. This makes it difficult for users to drill down for additional detail or easily find supporting or related information. A typical end-user is not concerned about documents per se, they are simply trying to access information as fast and as easily as possible to then support their duties. Difficulties to finding the required information easily has impacts on productivity and occasionally quality as end-users give up looking for the information they require.
Exceptions: The exception to the limitations of using documents are forms used for capturing data for processing. Such documents are designed to be controlled but they do have a specific role, different to providing information to users. Supporting documentation (instruction guides, etc.) can be easily become the containers of such documents with the forms available as attachments to that information.

Using Wiki Software as a Knowledge Base

The use of a Wikis as a knowledge base has become increasingly popular. They solve the problems of easy storage and retrieval of information as well as providing cross-linking and drilling down to child/supporting information. More information on the benefits of wiki use can be found here: Wiki - 111 reasons.xls (from http://blogs.atlassian.com/2010/08/111_reasons_why_enterprise_wiki/)

Documentation Formats

When using documentation to support end-users of processes, the core aim is provide information to the users in a way that will adequately support them. Some possible formats include
User manuals: suitable for the use of software or "click this, do that" approaches.
Flow Charts and Process diagrams: providing a visual aid to understanding the steps in a process.

More information about creating documentation.

Advanced Documentation Formats

Frequently Asked Questions (FAQ): provides easy to read answers to common questions.
Lesson Plans: Small processes or sub-process examples captured as distinct series of steps or instructions
Packaged Training: A collection of lesson plans (including content and examples) developed by, or on behalf of, the process owners. The training would be delivered officially to Team Leaders (or wider: Local Business Experts) and would then be used as the basis of internal team training. Packaged Training provides the content for "Train The Trainer" strategies.
Simulation Animations: animations are designed to look and work like the real product
Presentation and Demonstration Recordings: The recordings provide "just-in-time" training and knowledge transfer.

Finding Information from Multiple Documentation Sources

There are many examples where a "kitchen sink" approach to documentation means the end-user is overwhelmed with information. In some cases this is acceptable if the users have time to sift through and find what is relevant for the user at that time. For efficiency, however, some advanced searching capabilities are required as a way of handling the volume of information. Some Advanced Searching techniques include:

• keyword or specific phrase search
• being able to excluded a keyword or specific phrase
• Search by Author and/or date published/last updated
• Search by Subject/process area

The ability to combine multiple advanced searching techniques provides even more power to find specific information. NOTE: Where this is not available (such as documentation across multiple systems), a more pragmatic approach should be adopted: providing the minimum accepted amount of information in the easiest to comprehend format.

Multiple Responsibilities

Documentation within the Knowledge Networks strategy has a focus on being created for the benefit of the end-user, with compliance, while important, a consideration after satisfying end-user needs.

Above is a workflow showing the process of updating documentation in concert with system upgrades. Highlighted in red are the sections dealing with documentation updates. Who has the responsibility for updating what documentation depends on their access and use. A process owner can provide core documentation to the teams using this process. It is the responsibility of the teams to ensure this documentation is sufficient for their needs and either negotiate with the process owner to expand on this as necessary or develop their own resources. It is also the responsibility of the teams (and specifically the team leader) to ensure they correctly and fully understand the business rules and workflow of the process when expanding the documentation for the teams needs.

Training Champions and Networking

Training Champions, whether they are team leaders responsible for their local (team) documentation, or system/process owners needing to support their end-users, have a stake in ensuring their documentation becomes valuable asset for their target audience.
In the case of teams, fast and efficient access and accuracy is paramount. A team member should not be required to ask a fellow staff member to find out information about a process (the exception is changes of data that occur over a short space of time).
If the team leader becomes aware that implementation (use) of a process is not clear or incomplete (perhaps by their team members bringing it to their attention), it is the responsibility of the team leader to notify the process owner of where the documentation is deficient and then collaborate with the owner for a suitable improvement.
For system/process owners, the documentation needs to adequately support the end users without being an unsustainable burden to the owners themselves. This can, in a lot of cases, mean a lot less documentation may need to be written, or written in a simpler format.
NOTE: Team Leaders (as Local Business Experts) and system/process owners need to be granted the responsibility to create and publish documentation for their end users (i.e.: team members, system/process users) with minimal need to have such documentation further verified, amended or approved. It is the responsibility of the system/process owners to be the experts of the processes they own and that between themselves (as a team leader of their process) and their own Power Users, know all the pertinent business logic and factors their processes require. Similarly, Local Business Experts (and specifically the Team Leader) are responsible for ensuring they are fully knowledgeable on all aspects of the parts of the system that have a direct impact on their team. Documentation published by system/process owners (for their process users) or Team Leaders (for their team) reflects this responsibility.
With this in mind, documentation requiring further verification or approval becomes redundant, providing no further value. The responsibility of authoring correct and suitable documentation, and it's subsequent verification of quality, is recorded as a performance outcome within the achievement plans of the affected staff members (see Achievement Planning).
If documentation does not match the organisational style required, this is corrected as a learning process for the authors based on feedback and best practices that must be followed, but is not an impediment of publishing. Another performance outcome (again, see Achievement Planning) for these authors of documentation is the ability to write usable documentation suitable for their target audience of an acceptable quality. This is NOT to mean that such authors must be proficient in writing documentation for a myriad of formats, simply that the documentation written matches the needs of their end user, following standard templates, formats and style-guides that are applicable.
Example: for a series of FAQ written by a team leader for their team, use of suitable templates, following style guides for layout (fonts, heading use, etc.), correctness of content, and accuracy in grammar and spelling would be sufficient. The format would mimic other acceptable quality FAQ's, and where the quality is unacceptable, this would be a recorded performance measurement, and the improvement placed on the author as an action item.
The aim for this process is to be able to publish as quickly as possible and allow the documentation to evolve rapidly over iterations as required, with feedback from users to suit the end-users needs.

More Communication Strategies

txt here

• subscribing to important pages within a wiki so any changes will send a notification to subscribers alerting them to the changes (and prompting their review of the changes for updating their own knowledge or providing feedback or corrections to the authors). Related to this is the ability for some Wiki software to send a periodical (usually daily) summary of changes within a  specific "Wiki Space" to all subscribers (team members) of that space. The induction process for new staff members within that team would include information of what Wiki spaces the staff member is required to subscribe to.
• Email newsletter broadcasts regarding areas of expertise (eg systems or processes). This is already occurring at BNIT, but may benefit from more use. It is important for Team Leaders and Power Users to ensure they are abreast of all broadcast changes of system/processes they deal with and then disseminate this information to their teams accordingly.
• Invitations to new systems previews, workshops and User Acceptance Testing. This works hand-in-hand with "Train-the-Trainer" approaches in upskilling the Team Leaders and Power Users to then disseminate this new knowledge back to their teams, incorporating it into the induction process of new staff members and ensuring the knowledge is shared within the team.
• More points here