BPI Process/User's Manual – Build Phase

BPI Process/User's Manual – Build Phase

Description

• A description of the new processes and workflow from the user's perspective. These     manuals include:   
• A clear explanation of the process and its underlying purpose   
• Simple, step-by-step explanation of the activities that the user must perform (describes both manual and automated procedures, as well as human/computer interactions).   
• Visual aids (e.g. pictures of computer screen layouts) to illustrate required activities, where appropriate   
• References to other support material and help desks.

Customer Value

• Process/User's manuals are an important support to the Learning Strategy and Materials on the new work environment. They provide users with readily-accessible references to the new procedures and are instrumental in helping 'targets' of the redesign effort understand and complete the new work required of them.
• Process/User's manuals allow control and consistency in the implementation of the     business solution.
• When a new solution is deployed without well-written, comprehensive and formally documented support manuals, inconsistency in the approaches taken by employees in adopting the business solution will naturally arise. This will result in many important procedures and techniques being passed on to new employees in an inconsistent manner-solely by word-of-mouth (or not at all).

Approach

Drawing upon the details of the process, technology and organization, the Process/User's Manual documents the new work environment that will result from the designed solutions. It describes to the affected employees what and how work will be accomplished, by incorporating the new processes, technology and organization into a single manual(s). This manual may be written or automated, and be high-level or detailed, depending on the needs of the client.

1. Design a structure for the Process/User's Manual, by taking into consideration:   
• Requirements of use (how often, where, when, how)   
• Type and level of user (i.e. technical support, data entry, etc.)
• Layout and design, amount of detail, and format
• Mechanisms for recording and maintaining consistency in the techniques of user     manuals (e.g. on-line, hyper-text, paper manuals, computer-assistance 'wizards', etc.)   
• Methods for controlling the distribution and modification of documentation.
2. Formulate individual procedures and compile a 'strawman' manual (in rough draft form).
3. Review strawman Process/User's Manual with selected process stakeholders. Test procedures using the documentation. Revise, as appropriate.   
4. Develop and compile the final version of the manual. Design and print any 'forms' needed by users to complete the new procedures.    
• Existing forms generally require significant changes in order to be usable in the new environment. When information technology solutions are involved, it is often best to have the new forms mirror precisely the format of the new screens.   
• Where the forms are to be professionally printed (e.g. when an excellent presentation format or multi-part stationery is required), a substantial amount of time may be required to design the proofs, revise them, and gain approval. Adequate time should be made in the Migration Plan for such delays (although a temporary draft version might also be used as a contingency measure).

Guidelines

Problems/Solutions

• Avoid the following common pitfalls with documented procedures and instructions:   
• Inadequate validation of procedures
• Incomplete and inconsistent level of documentation   
• Lack of control in distributing and changing/improving procedures   
• Lack of verification that procedures are followed.

Tactics/Helpful Hints

• Ensure that procedures explain how users should perform their work in the new environment and that they are clear, easy-to-follow, and readily-accessible. The procedures should cover both normal and abnormal conditions that the user might face.
• Note that users will have varying levels of understanding of the environment and will need information concerning different aspects of the overall environment. It is therefore, not normally a good idea to produce a single, all-encompassing book containing everything that everyone needs to know.
• To save time and effort when writing user manuals and other design documentation, write in a common style that can be directly copied into the user documentation. Standard templates are useful tools in this regard.
• Where existing vendor information is relevant in a customized document, first check with the vendor to see that there is no problem with the copyright, and to see if the vendor can supply information already in an electronic format. It is important to balance the value added from custom-developed reference documentation with the ongoing cost of maintaining it.    
• When writing user documentation, keep each section distinct to reduce the costs of maintaining it. Even if the complete manual is redistributed after revisions, omit cross-references to keep costs down.
• Most organizations traditionally produce user manuals in paper form. However, particularly where the documentation allows 'expert system' logic and/or search facilities (permitting the rapid location of information), consider preparing the documentation in electronic forma. Some approaches that may be considered include:
• Workflow Automation systems
• Customizable On-line HELP facility (within software packages)
• 'Wizards' / 'Bubble HELP' (optional help text constantly appears on-screen to guide the user through each step)       
• Other electronic media for holding/accessing information (similar to External Consultant Consulting Toolkit).   
• User procedure 'crib notes' (very brief summaries of what to do)
• Partitioned user manual with appropriate sections distributed only to those needing them.

Resources/Timing

Writing user procedures requires dedicated resources (e.g. someone familiar with the package and the system being built with it and someone familiar with the business). Writing user procedures can be good introduction for those who will take over systems administration in the post-implementation era.