eDocumentation™ ProcessPlan Phase         Knowledge Process, Inc.             www.DocumentationProcess.com                ...
Table of Contents – Plan                                                       Table of Contents – PlanTable of Contents –...
Table of Contents – Plan  Preliminary table of contents .....................................................................
Table of Contents – Plan   User verification ................................................................................
Project Scope and Objectives                                   Project Scope and ObjectivesThere is the saying ‘Schedule, ...
Project Scope and Objectives        Will there be new Policies, Processes, and Procedures or revisions to existing documen...
Project Scope and Objectives        System more extensive or complex than anticipated, causing changes.Activities that all...
eDocumentation™ Process Flow                               eDocumentation™ Process FlowThe eDocumentation™ Process is a se...
eDocumentation™ Process Flow    Change        The Change phase addresses the process that tracks and updates Policies, Pro...
eDocumentation™ Process FloweDocumentation™ Process phasePlanBuildImplementationChangeVersion 1.0               eDocumenta...
Policy, Process, and Procedure – What Is the Difference?              Policy, Process, and Procedure – What Is the Differe...
Policy, Process, and Procedure – What Is the Difference?Driving from Hollywood to Los Angeles – A Policy, Process, and Pro...
Policy, Process, and Procedure – What Is the Difference?eDocumentation™ Process phasePlanVersion 1.0               eDocume...
Policy                                                        PolicyPolicy aligns and supports the enterprise’s strategic ...
Policy        Management is not able to review Policy as a stand-alone document. The Policy becomes fragmented,        and...
Process                                                             ProcessA Process identifies all tasks within a Process...
ProcessThe following is an example of a Process that results in a Sub-process. Process maps can also have high leveltext a...
ProcessMust a Process always use a map? No, but determine what is easier for the user to read.        Content can be added...
Procedure                                                                ProcedureA Procedure is the detailed steps requir...
ProcedureeDocumentation™ Process phasePlanBuildVersion 1.0               eDocumentation™ Plan Phase   Page 20 of 56
Content Audit and Evaluation                                    Content Audit and EvaluationThe objective of a Content Aud...
Content Audit and Evaluation        Systems                If the system functions that will be utilized are known, list t...
Content Audit and Evaluation     2. List the departments or the functional area that is part of the major Process.     3. ...
Content Audit and EvaluationeDocumentation™ Process phasePlanVersion 1.0               eDocumentation™ Plan Phase         ...
Audience Evaluation                                         Audience EvaluationEvaluating the audience who will use the Po...
Audience EvaluationAudience identification evaluationThe project team will identify user groups that require Policies, Pro...
Audience Evaluation              Additional training may be required, before the new Policies, Processes, and Procedures c...
Audience Evaluation    The following questions give valuable information as to the type of documentation the audience need...
Audience EvaluationeDocumentation™ Process phasePlanBuildImplementVersion 1.0               eDocumentation™ Plan Phase    ...
Content Review Team                                        Content Review TeamThe Content Review team is comprised of subj...
Content Review Team              Technical supportMember responsibilitiesIndividual team members will have specific areas ...
Content Review Team        The team does not establish standards.eDocumentation™ Process phaseBuildVersion 1.0            ...
Support Team                                                Support TeamThe Policies, Processes, and Procedures developer ...
Support TeamExpeditorAn expeditor is a person who knows who to go to for a quick resolution of a problem - after all else ...
Content Classification                                           Content ClassificationThe initial research of a project c...
Content Classification           Type of content           Policy          Process         Procedure         Lists Cycle t...
Content Classificationsets for different audiences, providing all the information that is necessary to accomplish their re...
Content Classification    Procedures, reusing certain information, as opposed to writing the same information multiple tim...
Accessible Policies, Processes, and Procedures                     Accessible Policies, Processes, and ProceduresAfter cre...
Accessible Policies, Processes, and Procedures              What are the basic capabilities of the technology?    Category...
Accessible Policies, Processes, and ProceduresImplementVersion 1.0   eDocumentation™ Plan Phase                           ...
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
2. eDocumentation Process Plan Phase
Upcoming SlideShare
Loading in …5
×

2. eDocumentation Process Plan Phase

1,008 views

Published on

Published in: Business, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,008
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

2. eDocumentation Process Plan Phase

  1. 1. eDocumentation™ ProcessPlan Phase Knowledge Process, Inc. www.DocumentationProcess.com www.KCGGroup.com
  2. 2. Table of Contents – Plan Table of Contents – PlanTable of Contents – Plan ..................................................................................................................... 2Project Scope and Objectives ............................................................................................................. 5 Scope .............................................................................................................................................................. 5 Objectives ........................................................................................................................................................ 6 Scope changes ................................................................................................................................................ 6 eDocumentation™ Process phase .................................................................................................................... 7eDocumentation™ Process Flow ....................................................................................................... 8 eDocumentation™ Process phases .................................................................................................................. 8 eDocumentation™ Process phase .................................................................................................................. 10Policy, Process, and Procedure – What Is the Difference? ............................................................ 11 Policy qualities ............................................................................................................................................... 11 Process qualities ............................................................................................................................................ 11 Procedure qualities......................................................................................................................................... 11 Driving from Hollywood to Los Angeles – A Policy, Process, and Procedure ................................................... 12 eDocumentation™ Process phase .................................................................................................................. 13Policy .................................................................................................................................................. 14 eDocumentation™ Process phase .................................................................................................................. 15Process............................................................................................................................................... 16 eDocumentation™ Process phase .................................................................................................................. 18Procedure ........................................................................................................................................... 19 eDocumentation™ Process phase .................................................................................................................. 20Content Audit and Evaluation ........................................................................................................... 21 Sources.......................................................................................................................................................... 21 Level of detail ................................................................................................................................................. 22 Complexity of material .................................................................................................................................... 22 Critical nature of materials .............................................................................................................................. 22Version 1.0 eDocumentation™ Plan Phase Page 2 of 56
  3. 3. Table of Contents – Plan Preliminary table of contents .......................................................................................................................... 22 eDocumentation™ Process phase .................................................................................................................. 24Audience Evaluation.......................................................................................................................... 25 Audience identification evaluation ................................................................................................................... 26 Individual Audience Needs Assessment ......................................................................................................... 26 Management audience ................................................................................................................................... 28 eDocumentation™ Process phase .................................................................................................................. 29Content Review Team........................................................................................................................ 30 Composition of the Content Review team ....................................................................................................... 30 Member responsibilities .................................................................................................................................. 31 Team responsibilities ...................................................................................................................................... 31 eDocumentation™ Process phase .................................................................................................................. 32Support Team..................................................................................................................................... 33 Subject matter experts.................................................................................................................................... 33 Systems support ............................................................................................................................................ 33 Vendor contacts ............................................................................................................................................. 33 Technical contacts.......................................................................................................................................... 33 Expeditor........................................................................................................................................................ 34 eDocumentation™ Process phase .................................................................................................................. 34Content Classification ....................................................................................................................... 35 Classification type .......................................................................................................................................... 35 Content organization ...................................................................................................................................... 36 Overlapping content types .............................................................................................................................. 38 eDocumentation™ Process phase .................................................................................................................. 38Accessible Policies, Processes, and Procedures ........................................................................... 39 Factors........................................................................................................................................................... 39 Be prepared ................................................................................................................................................... 40 eDocumentation™ Process phase .................................................................................................................. 40Usability Factors ................................................................................................................................ 42 Factors........................................................................................................................................................... 42Version 1.0 eDocumentation™ Plan Phase Page 3 of 56
  4. 4. Table of Contents – Plan User verification ............................................................................................................................................. 44 eDocumentation™ Process phase .................................................................................................................. 44Consistent Terms – a Common Language ....................................................................................... 45 1. Dictionary .................................................................................................................................................. 45 2. Inconsistent terms ..................................................................................................................................... 45 3. Source ...................................................................................................................................................... 46 4. Search ...................................................................................................................................................... 48 5. Developing consistent terms ...................................................................................................................... 50 eDocumentation™ Process phase .................................................................................................................. 52Soft Skills ........................................................................................................................................... 53 What are team soft skills?............................................................................................................................... 53 eDocumentation™ Process phase .................................................................................................................. 55Knowledge Process, Inc. ................................................................................................................... 56 About Knowledge Process.............................................................................................................................. 56 Copyright ....................................................................................................................................................... 56Version 1.0 eDocumentation™ Plan Phase Page 4 of 56
  5. 5. Project Scope and Objectives Project Scope and ObjectivesThere is the saying ‘Schedule, budget, or quality – choose two’, implying that you may not be able to achieve thelevel of quality required for a project and also meet the schedule and the budget. However, quality is not to becompromised. It is a changing scope that causes increased budget and schedule. Therefore, fully understandinga project’s scope and objectives, in every aspect, will alert you to potential ‘scope creep’ that can adversely affectyour project.This chapter addresses the project scope and how it will affect the development of the Policies, Processes, andProcedures. Please note that this chapter does not address project management. Project management is aseparate discipline requiring trained expertise.ScopeThe scope should clearly establish a beginning and an end, including the project deliverables. Performing theplanning tasks in the eDocumentation™ Process will assist in defining the scope to research and thedevelopment and implementation of the required Policies, Processes, and Procedures for a project. Thedocumented project scope should include the following: Fully define the deliverable; not as a general statement such as ‘Develop the Policies, Processes, and Procedures for the XYZ implementation’. There should be a clear statement of the Policies, Processes, and Procedures to be researched, developed, updated, tested, and implemented. For example, ‘Research and develop Process and Procedures for the Billing Process. Process and Procedures will be accessible using the enterprise portal. The Processes and Procedures will be developed using Word ™ and converted to HTML’. Define what will not be included. For example, ‘Policy development and training materials for the Billing Process will not be part of the project. Indexing and online help will be developed after implementation’. Define the tasks that require support, such as research, testing, and training. For example, ‘Support resources will be required to research and test the Billing Process and Procedures’.Many times Policies, Processes, and Procedures projects are part of a larger project. Therefore, thedocumentation project success is often dependent on the planning of the larger project. Care must be taken toincorporate the Policies, Processes, and Procedures as a Subproject within the master project plan and to ensurethe two scopes are aligned. Therefore, the documentation project becomes dependent upon the master project.To understand how a documentation project fits within a master project requires further questions. Is this a major development project? Is this a new system or upgrades? How many sites are affected? How many users are affected? Are there available users who know the system or processes? What is the level of detail required for documentation?Version 1.0 eDocumentation™ Plan Phase Page 5 of 56
  6. 6. Project Scope and Objectives Will there be new Policies, Processes, and Procedures or revisions to existing documentation? Is their new Policy (for example, SOX) being implemented that will require new Processes and Procedures? Will the documentation be the source materials for training? Are the Policies, Processes, and Procedures a part of the overall project plan or simply a one-line task? How many Documentation developers will be available for the project? Are the Documentation developers dedicated to this project, or will subject matter experts set up the Policies, Processes, and Procedures, inclusive with their other project tasks? Have the Documentation developers been consulted for their input to the project plan?ObjectivesThe objectives of a documentation project define what the success will be. This ensures that there are nosurprises and disappointments.Clear, concise, complete, and correct™ documentation is always the objective. In addition, other objectives mayinclude the following: Establish categories and keywords to support the enterprise taxonomy project. Establish documented controls to support SOX compliance. Establish a Policies, Processes, and Procedures portal for global access. Establish an Issue Reporting system on global portal to support change management.Scope changesThe major reason a project goes ‘out of control’ is an increase in project scope. Increase of scope can be causedby many conditions - among them the following: No project champion to control scope and support team. Project becomes more complex than original project plan. Request for additional deliverables that were not part of the original project plan. Increased tasks to develop Policies, Processes, and Procedures that were not part of the original project plan. Unclear deliverables. Unclear objectives. Lack of meaningful controls, such as milestones and communication. Key team members are moved off the project or are not available. Interest and direction declines.Version 1.0 eDocumentation™ Plan Phase Page 6 of 56
  7. 7. Project Scope and Objectives System more extensive or complex than anticipated, causing changes.Activities that alleviate an increased scope include these: Perform the eDocumentation™ planning and research tasks so that you have a grasp of the project scope and objectives. Maintain a project plan to record, and notify the dependent tasks that affect the documentation project. Structure the documents so that they can be easily updated as changes are required. Have proper tools readily available to efficiently prepare the documentation. Keep consistency between all documents.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 7 of 56
  8. 8. eDocumentation™ Process Flow eDocumentation™ Process FlowThe eDocumentation™ Process is a set of guidelines, not decrees, that guide the Documentation developerthrough the research, development, and implementation of Policies, Processes, and Procedures. The objective isto create and produce Policies, Processes, and Procedures that are clear, concise, complete, and correct™.Although the Process is a somewhat sequential Process, each phase touches the other phases and relies on thediligence and quality of the previous phases. Previous phases may be revisited, and if conditions warrant,modifications may be made to previous assumptions and decisions. Phase 2: Phase 1: Build Plan Phase 3: Implement Phase 4: ChangeeDocumentation™ Process phasesThere are four major phases that comprise the eDocumentation™ Process. The phases encompass the tasksthat need to be reviewed and performed as the project progresses, depending upon the company, project, andscope. Plan The Plan phase incorporates the tasks that are required to ensure that the project is properly scoped with the correct focus, level of detail, team members, and proper content. Planning does not make a project longer or more complicated, but ensures that erroneous assumptions do not become part of the project approach and plan. Policies, Processes, and Procedures are usually dependent upon other resources; therefore, it is important that all the puzzle pieces fit. Build The Build phase researches and develops the Policies, Processes, and Procedures. Based on the decisions from the Plan phase, the Policies, Processes, and Procedures are researched, written, verified, and tested. This phase is often looked upon as ‘just writing’. However, there are other critical tasks that are performed in addition to writing. Implement The Implement phase rolls out the Policies, Processes, and Procedures to all the users. A Policies, Processes, and Procedures project is never complete until the users are trained. This is often an overlooked task, but it is – without a doubt – key to the success of the overall project. The Implement phase incorporates appropriate change management principles.Version 1.0 eDocumentation™ Plan Phase Page 8 of 56
  9. 9. eDocumentation™ Process Flow Change The Change phase addresses the process that tracks and updates Policies, Processes, and Procedures. Change is the nature of Policies, Processes, and Procedures. Updates are often overlooked, and at that point the Policies, Processes, and Procedures become outdated and less reliable. Therefore, guidelines and Processes are introduced to assist with keeping Policies, Processes, and Procedures current. Plan Build Implement Change Define Project Evaluate Policies, Perform Content Compile Scope and Processes, and Research Documentation Objectives Procedures Develop Policy, Perform Content Create Review Categories Process, Audit Tables of Contents and Usability Procedure Review Policy, Publish Policies, Project Review and Define Audiences Process, Processes, and Published Procedure Procedures Recommendations Test and Verify Receive Requests Define Determine Policy, Process, for Additions and Project Teams Training Approach Procedure Changes Test Define Content Training Review and Review Planning Categories and Classifications Approval Tasks Usability Revise Perform Subject Prepare Training Change Request Review Policy, Process, Matter Breakdown Materials and Approval Procedure Edit Train Define Standards Policy, Process, Policies, Procedure Processes, Procedures Define Approve Policy, Process, Archive Training Standardized Procedure Materials Terms Mark as Final Implementation and Training Define Preliminary Policies, Review and Published Table of Contents Processes, Recommendations Procedures Project Planning Phase Development Review and Review and Approval ApprovalVersion 1.0 eDocumentation™ Plan Phase Page 9 of 56
  10. 10. eDocumentation™ Process FloweDocumentation™ Process phasePlanBuildImplementationChangeVersion 1.0 eDocumentation™ Plan Phase Page 10 of 56
  11. 11. Policy, Process, and Procedure – What Is the Difference? Policy, Process, and Procedure – What Is the Difference?Many years the terms ‘Policies’, ‘Processes’, and ‘Procedures’ have been interchanged. ‘Policies’, ‘Processes’,and ‘Procedures’ should be considered distinct types of documentation.The researching and developing documentation requires understanding the distinctions between a Policy, aProcedure, or a Process. All address related subject matter, but at a different level and with different types ofcontent. Each type has a unique purpose that drives the content contained in each type of document. Describingthe distinctions using who, what, where, when, why and how often helps to understand and properly structurethem.Policy qualities Policies are the business rules and guidelines of a company that ensure consistency and compliance with the company’s strategic direction. The Policies lay out the business rules under which a company, division, or department will operate. Policies are the guidelines under which Procedures are developed. There is not a one-to-one relationship between a Policy and a Procedure. Policies are not part of the Procedure, because they cannot be properly structured. However, the Procedure must reflect the business rules contained in the Policies. Policies address what the Policy is and its classification, who is responsible for the execution and enforcement of the Policy, and why the Policy is required.Process qualities Processes are related activities that produce a specific service or product (example, Procurement to Payment). The majority of Processes cross departments or functional areas. Each Process designates the connect points and where it crosses department lines. The documentation presents the total Process. It is helpful to be able to reference or drill down to the applicable Policy or Procedure for a Process step. A Process map is a useful tool to graphically display the Process. Processes indicate where there is a separation of responsibilities and control points. They are also very helpful to identify Policy and Procedure requirements. Processes address who is responsible to perform the Process (department, division), what major functions are performed, and when the function is triggered.Procedure qualities Procedures define the specific instructions necessary to perform a task or part of a Process. Procedures can take the form of a work instruction, a desk top Procedure, a quick reference guide, or a more detailed Procedure. Procedures usually are structured by subject (for example, system instructions, report instructions, or Process tasks). A Procedure usually addresses only a single task. This separation enables Procedure components to be compiled into special Procedure manuals for specific audiences, end users, and purposes. Procedures detail who performs the Procedure, what steps are performed, when the steps are performed, and how the Procedure is performed.Version 1.0 eDocumentation™ Plan Phase Page 11 of 56
  12. 12. Policy, Process, and Procedure – What Is the Difference?Driving from Hollywood to Los Angeles – A Policy, Process, and ProcedureUsing common maps to illustrate the differences between a Policy, Process, and Procedure, the followingexample illustrates that different content is contained within each type of document. While all the informationrelates to the subject of driving from Hollywood to Los Angles, different content type is used for differentdocuments. Policy Policies are the guidelines or laws that drive the Processes and Procedures. Processes Processes are a high level view. The tasks within the overall process are identified. Procedure Procedures are the detailed steps required to perform an activity within a process.Version 1.0 eDocumentation™ Plan Phase Page 12 of 56
  13. 13. Policy, Process, and Procedure – What Is the Difference?eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 13 of 56
  14. 14. Policy PolicyPolicy aligns and supports the enterprise’s strategic plans, goals, and objectives. It is the foundation for thecontent of Processes and Procedures, as they should not contradict a Policy. Policy should remain fairly stableand not be subject to as frequent changes as a Process or Procedure. Policy should always have a review dateassociated with it, to ensure that it is compliant.Policy is the foundation for an enterprise, country, location, functional area, or department. Policy forms ahierarchy with each level, aligning with the policies above it. Policy may need to be adapted, based upon specificrequirements or regulations for a country or location. However, these adaptations must align with the policiesabove it in the hierarchy. For certain subjects, you may need an umbrella Policy that states the basic andunchanging content, such as Legal and Financial Reporting. While there may be different country Policies, theenterprise would have a Policy that is senior to all other Policies.Policy addresses the laws, guidelines, strategic goals, objectives, best practice, culture, and values of anenterprise.There are many purposes for Policy: obtain a high level of quality; understand the legal requirements; obtainaccuracy of processing; obtain consistent and reliable metrics; implement consistent and required controls; andreduce risks and penalties. Only through Policy can the purposes and requirements be communicated andimplemented.There are two types of Policies - passive and active: Passive Policies are stand-alone Policies: For example, a sexual harassment Policy. The Policy provides the implementation guidelines and requirements – because it is a legal requirement; therefore a Process or Procedure may not be required for implementation. Active Policies require supporting Processes and Procedures in order to implement the Policy: For example, control points within a Process. In order for the Policy to be implemented, the users must know the exact steps required by management.Many Policies are cross functional, which requires collaboration during development and reviews. Therefore,when developing Policy, know who is affected by the Policy.Because Policy is the foundation for a company, it is essential that management know that the correct version ofa Policy is being used by all who are affected. They will know that the correct version is being used, if they knowwho requires the policy; what the effective date is; when the next review is required; where the document islocated; and proper reviews and approvals have been obtained. The first step to achieve the objectives is to setup the Policy as a separate document. The following should be avoided: Many Processes and Procedures have a section called ‘Policy’. Processes and Procedures may reference or provide a link to the applicable Policy, but the Policy should never be incorporated in the Process or Procedure. There is usually a one to many relationship between Policy and Procedures. Therefore, one Policy, or several Policies, may be referenced in many Processes and Procedures. If the Policy is stated or detailed, not just linked, maintenance of the Policy then becomes impossible. Rather than updating just one Policy document, multiple Process and Procedure documents must be reviewed and updated. The Policy is not able to undergo scheduled reviews. Because the Policy can be fragmented between Processes and Procedures, it is not possible to ensure that all references to the Policy are updated.Version 1.0 eDocumentation™ Plan Phase Page 14 of 56
  15. 15. Policy Management is not able to review Policy as a stand-alone document. The Policy becomes fragmented, and this makes management reviews more difficult. Therefore, a standard review date is difficult to achieve.Policy subject matter experts are management and those who have knowledge of the law and legal requirements.It is necessary to provide management with the tools so that the Policy can be properly stored, accessed, andreviewed.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 15 of 56
  16. 16. Process ProcessA Process identifies all tasks within a Process and its boundaries, beginning to end. A Process may referenceother Processes, when they are cross functional (for example, Quality and Procure to Pay). Within a Process youwill drill down to a Sub-process or a Procedure. A Process does not present the steps to perform a Procedure.The Process is a high level view of an overall activity.Processes, as referenced here, refer to the user Processes; not necessarily Business Process Managementinitiatives that are used for enterprise business design. BPM is used to standardize Processes, to attain aconsistent outcome, and to add value for the enterprise. The results of BPM have multiple purposes and areused for different initiatives. Therefore, for our purposes we do not want to confuse BPM Initiatives with Processdocumentation. When it is applicable, Business Process Management maps are used as input for user Processmaps and Procedures. Enterprise Business Process Initiatives User Processes and Procedures Procedure Audits Business Process Six Sigma design Business Process Input to Process Procedure reengineering Process Documentation documentation To Be modeling maps and maps SOX work TQM Procedre flowsProcesses are often referred to as a Process map, because as a map or flowchart it is the easiest way to illustratetasks within a Process. A Process will usually be cross functional, as it pertains to multiple functional areas. Auser Process will have multiple purposes - training, research, documentation. Processes can easily become amaze, if not clearly defined. Process maps that are used for ‘to be’ Processes and are not updated for userdocumentation become lost assets and tools for users. Therefore, clear guidelines and standards must be set forProcesses. Determine the purposes, to prevent a map from having limited usage. Keep in mind that the Processes are untimely for users. Determine the hierarchy of the Processes. If a Process is referenced in another Process, single sourcing should then be used. Develop a stable reference system for the Processes, in order to link to other Processes.Version 1.0 eDocumentation™ Plan Phase Page 16 of 56
  17. 17. ProcessThe following is an example of a Process that results in a Sub-process. Process maps can also have high leveltext associated with it. Care should be given with the duplication of information. Procure to Pay Process Procurement 2.0 1.0 Purchase Requisition material Receiving 3.0 Receive material Accounts Payable 5.0 4.0 End Issue Invoice Process payment 3.0 Receive material Who: Receiving manager What: Reconcile When: Daily Where: Receiving system How: Report 99 Control: Quantity of goods received to Dollar value of POVersion 1.0 eDocumentation™ Plan Phase Page 17 of 56
  18. 18. ProcessMust a Process always use a map? No, but determine what is easier for the user to read. Content can be added describing Process overview and basic information. Process maps are excellent training tools. Process maps are excellent overviews for complex business Processes and system Processes. Process maps are excellent guides to applicable Procedures.The following example is a Process map with the same information in a text format. The Process map is a moreeffective tool for users. 3.0 Receive Material Receiving 3.1 3.2 Receive Create material receiver 3.3 3.4 Quality End Inspect Accept Yes process material material No Procurment 3.5 Disposition instructionseDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 18 of 56
  19. 19. Procedure ProcedureA Procedure is the detailed steps required to perform a task. The Procedure defines exactly how to perform thetask to obtain the desired result. Procedures can be in the form of keying instructions, approval instructions, orbalancing instructions.A Procedure guides the user through the steps to perform a specific task. Fundamentals of a Procedure are thefollowing: Correct sequence of steps so that the task can be properly performed. Correct and clear instructions so as not to add confusion. Easily referenced instructions for critical tasks such as error conditions, controls, cutoff dates. Proper breakdown of Procedures so that each Procedure is not too cumbersome to reference and use. There usually are multiple Procedures for a specific Process task. Complex Procedures, such as financial systems or monthly balancing, may require a Process map or checklist to help guide the user through a complex Procedure.Procedure content should adhere to Policy and may reference a Policy title or number using a link. However, thePolicy should not be part of the Procedure. The Procedure should contain only information that pertains toperforming a specific task.Procedures go hand-in-hand with Processes. Process is a high level roadmap. Procedure is the detailed instructions. 3.0 Receive Material Receiving 3.1 3.2 Receive Create material receiver 3.3 3.4 Quality End Inspect Accept Yes process material material No Procurment 3.5 Disposition instructionsVersion 1.0 eDocumentation™ Plan Phase Page 19 of 56
  20. 20. ProcedureeDocumentation™ Process phasePlanBuildVersion 1.0 eDocumentation™ Plan Phase Page 20 of 56
  21. 21. Content Audit and Evaluation Content Audit and EvaluationThe objective of a Content Audit and Evaluation is to determine the quality and quantity of existing content thatrelates to the project, and provide a ‘best guess’ as to the scope of Policies, Processes, and Procedures that willneed to researched and developed. During the task you will determine what documentation exists, who uses it,and the age of the content.SourcesExisting project related content is a source of knowledge that can be used to ‘get your arms around’ the potentialdocumentation. Provide Documentation developer with information to better understand the project. Provide users with information from which they may assemble issues and questions. Provide a starting point as to the scope of the Policies, Processes, and Procedures to be researched and developed. Legacy documentation In order to gain a basic understanding of the content, skim sources for major headings, charts, and other content from the following existing sources: Policies, Processes, and Procedures Vendor manuals System functionality documentation Individual cheatsheets and notes Organization charts Job descriptions (if available) New documentation New documentation may have been prepared during a feasibility study or extensive business process reengineering. This documentation contains the high level impact to Policies, Processes, and Procedures. Process maps Process maps may have been developed by other participants that map the new Processes. If so, these will identify the content that needs to be development and documented. List the business Processes that will be affected. List the business Processes that may be affected. Policies Determine if new Policies have been identified for development, due to the reengineering of business Processes.Version 1.0 eDocumentation™ Plan Phase Page 21 of 56
  22. 22. Content Audit and Evaluation Systems If the system functions that will be utilized are known, list those business functions and the associated system functions. If the system is new and not well known to people within the enterprise, list the business functions that will be affected with the new system.Level of detailBased upon the Audience Evaluation, who will use the functions has previously been identified. Determine thelevel of detail that will be required by the various audiences.To ensure consistency of operation, the documentation detail must be ‘just right’ so that users will reference anduse the documentation. Therefore, this task is completed during the content research task, when you are workingwith the users. You must understand their job, their needs, and their problem resolution requirements. Thatunderstanding will assist you in preparing the documentation with the proper amount of detail.Complexity of materialDetermine the complexity of the materials. Consider the following factors: Is the material intuitive? Are the actions clearly defined without supporting information? Does the material have multiple paths? Are these paths self documenting? Is the input dependent upon the input of other information? How many steps are required to research the desired result? Do the steps require multiple users? If the documentation is only a new version, the complexity may be low, even though the documentation, as a whole, is complex. Each audience may require only a part of the documentation. Therefore, each audience requires a complexity evaluation.Critical nature of materialsSome documentation is more important or more critical than other documentation. For example, a documentupdating SOX controls may be more critical than a document updating a system’s function keys. Differentaudiences may require a more complex part of the documentation to understand it. Understanding thisrelationship gives a priority for the development and implementation of the Policies, Processes, and Procedures.Preliminary table of contentsThe output of the content audit is the preliminary table of contents. This is not the table of contents that will begenerated by the Policies, Processes, and Procedures from the heading styles or tags. The content audit table ofcontents is manually developed and serves as an estimate of the Policies, Processes, and Procedures to bedeveloped.It is helpful to set up the preliminary table of contents using Excel ™, in order that the various columns can besorted, giving different views.To develop the preliminary table of contents, perform the following steps: 1. Determine major Process being audited.Version 1.0 eDocumentation™ Plan Phase Page 22 of 56
  23. 23. Content Audit and Evaluation 2. List the departments or the functional area that is part of the major Process. 3. List the sub processes for each functional area. 4. List the existing Procedures that support the sub process. 5. List the source of the Procedures. 6. List the owner of the major Processes.The following spreadsheet is an example of the existing Procure to Pay Policies, Processes, and Procedures.The existing materials would be reviewed to determine their use for new documentation. In addition, thespreadsheet would be distributed for others for collaboration. Procure to Pay Process Department Sub Process Procedure Source Owner Policy Source Owner Originating Prepare Prepare Department Purchase Req request Originator Mgr,Dept Approve request Generate Purchase Request Review Purchase Mgr, Purchase Order Prepare PO Request Notes Buyer Notes Purchasing Determine vendor Review terms Generate PO Approve PO Receive Receiving Materials Notes Mgr, Receiving Notes Mgr, Receiving Prepare Receiver Inspect Quality Materials Procedures Mgr, QA Procedures Mgr, QA Accept / Reject Materials Move to System Inventory Inventory generated Mgr, MM Mgr, MM Accounts Receive Vendor Payable Receive Invoice information AP Procedures Controller AP Procedures Controller Add vendor information Dated 01/01/01 Dated 01/01/01 Approve Post Invoice invoice Record invoice Generate Pay Invoice paymentVersion 1.0 eDocumentation™ Plan Phase Page 23 of 56
  24. 24. Content Audit and EvaluationeDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 24 of 56
  25. 25. Audience Evaluation Audience EvaluationEvaluating the audience who will use the Policies, Processes, and Procedures is one of the most importanteDocumentation™ planning tasks performed. The Audience Evaluation affects many of the tasks that comprisethe documentation process. The audience is the user and the reason for developing the Policies, Processes, andProcedures. There can be multiple audiences for the documentation, each having a unique set of requirementsfor the documents. Therefore, each audience must be evaluated independently. Upon completion of eachAudience Evaluation, you will be able to tailor the Policies, Processes, and Procedures to their needs andrequirements. Management Audiences Primary Audiences Secondary Audiences Policies and Procedures Policies and Policies and Procedures Procedures Applications Process Flows Forms Process Flows Applications Policies and Applications ProceduresVersion 1.0 eDocumentation™ Plan Phase Page 25 of 56
  26. 26. Audience EvaluationAudience identification evaluationThe project team will identify user groups that require Policies, Processes, and Procedures. The groups will beclassified into distinct audiences, based on the following factors. The initial evaluation identifies the audiencesand provides general information about how they use Policies, Processes, and Procedures. Where are the locations of the audiences? Determine the location of each audience. Are audiences global - in different cities and countries? What are the languages used by the audiences? Determine if a language translation is required for each location. If materials require translation, the writing style must be evaluated to ensure that it will accommodate the language translation. What is the number and the size of each audience? The number and size of the audiences determines the general approach for the development and the implementation of the documentation. For example, there may be 10 locations, each with 1 person; or there may be 2 locations, each with 200 persons. If the audience is small, but the material is complex, it is important that the materials have a high level of detail. Because the audience is small, there might be a critical and immediate need to train the users, due to potential turnover and lack of backfilling. A large audience requires electronic media and a formal training program, if the project is new or is a significant update. After implementation, a large audience will have a support system, as there should always be available members familiar with the materials. A large audience may present problems over time, in that they will ask an associate for information rather than referencing their documentation, which will cause consistency problems. Therefore, the size of the audience determines the general approach for the development, implementation, and training of the Policies, Processes, and Procedures.Individual Audience Needs AssessmentThe Needs Assessment of the individual audience evaluates the identified audiences and provides specificinformation about each audience. This assessment will ensure that the Policies, Processes, and Procedures willmeet their specific needs. The main factors used are the following: Is this the primary or secondary audience? Determine if a specific audience will be the primary or secondary users. Depending on the scope, size, and implementation approach of the project, multiple audiences can be designated as the primary audience. The primary audiences will be the highest priority for the Policies, Processes, and Procedures development and implementation. What is the job description of the audience? Determine the basic job description of the audience. Many times the job description will change with a major implementation. Having a before and after job description highlights those areas that will be new to an audience and, therefore, may need a higher level of detail for the Policies, Processes, and Procedures. This alerts you to the following important issues: Additional responsibilities to be addressed for the audience. Function should be performed by another audience, because of control issues.Version 1.0 eDocumentation™ Plan Phase Page 26 of 56
  27. 27. Audience Evaluation Additional training may be required, before the new Policies, Processes, and Procedures can be implemented for the audience. Does the audience process critical data or transactions? Determine how critical the information, which is processed by the audience, is to the company. If the information is key to the company or to upstream processes, this again highlights an area that requires a higher level of detail for the Policies, Processes, and Procedures. Some documentation is more important or critical than others. For example, a document updating SOX controls may be more critical than a document updating a system’s function keys. Different audiences may require a more complex part of the documentation to understand it. Understanding this relationship gives a priority for the development and implementation of the Policies, Processes, and Procedures. This factor will also highlight an area of Policies, Processes, and Procedures verification to ensure the information is correct and the desired results are obtained. What is the level of detail required by the audience? Each audience may require a different level of detail for their Policies, Processes, and Procedures. Understanding the proper level of detail for documentation is directly related to usability. If there is not enough detail, the user cannot get a question answered in a timely manner and must resort to other sources for the information. If there is too much detail, the user will become frustrated with the amount of information and attempt to get the information from another source. The results of this evaluation directly affect usability. To ensure consistency of operation, the documentation detail must be ‘just right’ so that users will reference and use the documentation. Therefore, this task may need to be completed during the content research task, when you are working with the users. You must understand their job, their needs, and their problem resolution requirements. That understanding allows you to prepare the documentation with the proper amount of detail. In addition, during the testing task, you may discover that you are missing critical information. How does the audience locate their Policies, Processes, and Procedures? Determine how the user searches to locate and access the Policies, Processes, and Procedures. Search criteria Meta data Taxonomy Manual searching through files or documents If the audience currently is using paper-based Policies, Processes, and Procedures, and you will be proving electronic Policies, Processes, and Procedures, additional training is required on searching and accessing the new documentation. In addition, many audiences may not be oriented to structured documentation. They will require training on the differences between a Policy, Process, and Procedure so that they will be able to efficiently access needed documents. How does the audience problem-solve? Determine how the audience solves problems or gets questions answered. This will inform you of the level of information available to the person. It will also be a lead-in to the level of training that will be required. Because consistency in results and outcome is desired, you want the audiences to reference the Policies, Processes, and Procedures for direction and answers. This may require additional training and follow-up to create this new culture.Version 1.0 eDocumentation™ Plan Phase Page 27 of 56
  28. 28. Audience Evaluation The following questions give valuable information as to the type of documentation the audience needs and wants. Does the person guess at an answer? Does the person ask another person? Does the person have existing documentation? Does the person use online help? Does the person keep their own notes? What is the person’s biggest problem during problem solving? What is the audience work environment? Determine the audience work environment. Do they work as an integrated group? Do they work alone in a separate environment? Are they on the phone or with customers a great deal of time? Is the work primarily transaction driven? Do they have critical dates on a weekly, monthly, or yearly basis? If they do, the audience may require check sheets that give critical tasks and their due dates that lead up to the weekly, monthly or yearly deadline. In addition, additional training may be required for those that ‘lend a hand’ during the critical deadlines.Management audienceManagement plays a major part in the development of Policies, Processes, and Procedures. Therefore,management must also be addressed as an audience. Management requirements will be different than primaryor secondary audiences. Management, with the exception of management directly responsible for primary andsecondary audiences, will always require Policies and Processes. What is the language of the management audience? What is the location of the management audience? What are the required critical Policies? What is the size of the management audience? How do they want to access their Policies and Processes? Is there a management portal where they want their documentation? Are there critical review dates for Policies and Processes? How is management currently informed of review dates? Does management author Policies, Processes, and Procedures? If they are the authors, they must receive and adhere to the eDocumentation™ Process standards.Version 1.0 eDocumentation™ Plan Phase Page 28 of 56
  29. 29. Audience EvaluationeDocumentation™ Process phasePlanBuildImplementVersion 1.0 eDocumentation™ Plan Phase Page 29 of 56
  30. 30. Content Review Team Content Review TeamThe Content Review team is comprised of subject matter experts and management personnel, who reviewspecific content contained in the Policies, Processes, and Procedures. Coordination is a key factor for thesuccess of the Content Review team. The individual members review only the documents that pertain to theirsubject area or area of responsibility. Some members may review only the final content.Identification of the subject matter experts is an important factor in the planning and scheduling of adocumentation project. A planning meeting with the Content Review team to determine their requirements,constraints, statutory issues, and control issues is advisable. Understanding these issues, before developing andwriting the Policies, Processes, and Procedures will prevent schedule delays.There may be multiple Content Review teams on a project. As an example, Procure to Pay includes expertise inPurchasing, Receiving, Accounts Payable, and General Ledger. Therefore, there may be a Procure to PayContent Review team acting with sub teams comprised of Purchasing, Receiving, Accounts Payable, and GeneralLedger. Your Content Review team structure depends upon the size of the project and the company. TheContent Review team should not be so large that it becomes burdensome or so small that vital content can beoverlooked.Composition of the Content Review teamThe Content Review team is comprised of subject matter experts and management personnel, who must guide,assess, and approve the content. The members of the Content Review team can be fluid. Some members mayserve for a limited period of time or for the length of the project, depending upon their review scope andknowledge of specific requirements and issues.Members can be removed and new members added as the content requires or if original members cannotsupport the project.Members are not assigned as a formality. If a person is assigned to the Content Review team, they must be ableand willing to provide the reviews as required and within the scheduled time frame. This may require providingextra support or backfilling for the team member to allow for the additional responsibility.The following are examples of the various areas that might be part of the Content Review team, based upon thetype of content being researched and developed: Management Process owners Legal Human resources Safety Subject matter experts Business processes (i.e. Procure to Pay) Policies Statutory (i.e. SOX, GAAP, HACCP) ControlsVersion 1.0 eDocumentation™ Plan Phase Page 30 of 56
  31. 31. Content Review Team Technical supportMember responsibilitiesIndividual team members will have specific areas of expertise and responsibility. In order to have a well-balancedteam, the individuals must represent the following: Expertise in the specific content area Familiarity with the structure of the organization Ability to relate information to other areas of the company Enthusiasm about the project Ability and willingness to commit time and energy to the project Determination to resolve issues within the scheduled time frameTeam responsibilitiesTeam coordination and cooperation will greatly impact the quality of Policies, Processes, and Procedures. Teamsthat view and execute the following duties earnestly will enable the Policies, Processes, and Procedures to beresearched and developed in a productive and timely fashion. Recommend and approve the subject matter breakdown, based on the quantity of content to be researched and developed. Set up method for reviewing Policies, Processes, and Procedures. Initially the team may conduct formal walkthrus to discuss and review the documentation. Determine the owner for the Policies, Processes, and Procedures. Determine the lead person for team coordination. Resolve questions and conflicts between departments as they pertain to the Policies, Processes, and Procedures. Identify the key and critical information for the Policies, Processes, and Procedures. Verify and approve the specific information communicated in the documentation. Assist with setting up consistent and standard terminology, as it relates to the content. Request scope of content be increased, if new requirements surface. Provide approval for the implementation and the distribution of Policies, Processes, and Procedures.It is also important to note those responsibilities that do not pertain to the Content Review team. If the ContentReview team performs tasks that are outside its scope, such as those listed, the project will begin to wander offtask. In addition, there will be further problems down the road; in that the team’s main purpose – content - will nothave been developed and analyzed. The team does not perform editing responsibilities. The team does not set up the implementation plan and approach.Version 1.0 eDocumentation™ Plan Phase Page 31 of 56
  32. 32. Content Review Team The team does not establish standards.eDocumentation™ Process phaseBuildVersion 1.0 eDocumentation™ Plan Phase Page 32 of 56
  33. 33. Support Team Support TeamThe Policies, Processes, and Procedures developer requires collaboration and support, within the company, toget answers to the many questions that arise during a documentation project. The Support team mustunderstand the myriad of issues and questions the documentation developer encounters and must furnish theanswers in a timely fashion.The Support team is not comprised of members of the Project team. They are supplemental and on-demand. Itis not unusual for the Support team to have members located in different cities or even different countries.The demands on the Support team are dependent upon the size and complexity of the project. The process thatis used to provide assistance for the documentation developer will vary, based on the size of the project and theproximity of the Support team.Two questions need to be answered: Who has the supplemental knowledge or expertise? How should the person be contacted?An enterprise, with an established knowledge culture, understands this need. A framework for available expertisemay currently exist. If a framework does not exist, it should be built as the project progresses, and the requiredexpertise is discovered.The Documentation developer should have a list of the members of the Support teams and their areas ofexpertise. The list may or may not be available to other members of the team. If the team is large, there shouldbe a process for contacting a person for assistance, so that it will not interfere with their daily responsibilities.Subject matter expertsSubject matter experts, that are not part of the project team, may need to be consulted at times during the project.These resources are very valuable for verifying information or providing quick answers. For example, if yourproject is not officially using the Training department, it may helpful to consult the department for trainingquestions. If your project is small, determine the type of support your company has that will be helpful to you.Systems supportAt times during the project, especially during testing, system support will be needed - some as simple as logonID’s. Because system support can be located in multiple locations, knowing the proper person to contact will savetime.Vendor contactsWhen preparing Processes and Procedures for software, a vendor contact may be required; particularly ifmodifications have been made to the software. You should know the contractual agreements between yourcompany and the vendor, before asking for support. However, most vendors do not object to periodic questions.It is more effective to thoroughly document the question (including screen captures) in an email than to discussthe issue on the phone. A prompt answer is often received, if the question is properly documented.Technical contactsTechnical support may include analysts and programmers. There are times when the Documentation developerhas a question that requires a technical person to consult.Version 1.0 eDocumentation™ Plan Phase Page 33 of 56
  34. 34. Support TeamExpeditorAn expeditor is a person who knows who to go to for a quick resolution of a problem - after all else fails. Theexpeditor can be the project manager, a person in management, or any person who knows the organization andhas a certain level of clout. The purpose of the expeditor is to keep the project from falling behind schedule, dueto issues that are not being resolved.If an expeditor cannot solve a problem, the issue should then be escalated, using the escalation matrix.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 34 of 56
  35. 35. Content Classification Content ClassificationThe initial research of a project can be quite overwhelming, because of the amount of data you will need toanalyze. Understanding begins when you are able to see classifications and relationships between the types ofdata.A vast amount of data requires analysis, during the research phase. From the analysis the data will betransformed into contents for a specific Policy, Process, or Procedure.When gathering the information, understanding where the information might belong can be a method of sortingthe information.One of the first tasks, during planning, is listing major functions that are affected. If major functions are performedin multiple locations, observe that each location might perform the same functions. Determine whether they arethe same functions or different functions, due to different systems, local statutory requirements, differentcompliance requirements, or other reasons.Classification typeSpecific types of information will be contained in a Policy, Process, or Procedure. However, content sourcedwithin a Policy can also be referenced or linked in a Process and/or a Procedure. It is vital that the information isconsistent between all types of documents.The following matrix refers to major types of content and where that content can be used. These are guidelines,not rules. Each enterprise should classify their content types to fit their needs. O Originates The content will originate within this specific type of document. All content in other document types align with the content in the originating document type. A Aligns The content in the document types must align with the content in the originating source document. When questions arise as to how to perform a specific Process or Procedure, the author reviews the originating source to ensure the content is aligned and in compliance. This prevents conflicting content between document types. Type of content Policy Process Procedure Lists Acronyms A A A O Balancing O A Business function O Business task O A Codes A O Contact information A O Controls O A AVersion 1.0 eDocumentation™ Plan Phase Page 35 of 56
  36. 36. Content Classification Type of content Policy Process Procedure Lists Cycle time O A Data elements / field names O Database O A Date and time requirement O A A Department guidelines / rules O A A Enterprise guidelines / rules O A A Escalation O A Exceptions or errors O A Forms O A Glossary of terms A A A O Industry best practices O A A Messages (error, warning) O Process task O A Regulatory – enterprise (SOX, O A A FEC) Regulatory - local O A A Reports O A Responsibility O A A Screens O A Service level agreements O A System O A Technical support / help O Workflow O AContent organizationThe scope of the project defined during the planning phase, defines the types of content – Policies, Processes,and Procedures - to be developed or updated. You will have either a list of existing documentation to be updatedand expanded or a major function list for the affected locations and departments, which you have prepared. Withthis blueprint you will be able to organize the content and determine the documents in which the content resides,or whether new documents should be created.Content organization is defined as ‘Where does the content belong?’ The following diagram shows therelationship between the information contained in the Policies, Processes, and Procedures. Policies, Processes,and Procedures are dependent upon each other and must be consistent in all ways (features, attributes,functions, characteristics). The content of the Processes and the Procedures must reflect the Policy guidelinesand rules. Without rewriting, the Policies, Processes, and Procedures must be aligned. Procedures also relate toeach other. Although they are written as separate documents, they can be assembled into different documentVersion 1.0 eDocumentation™ Plan Phase Page 36 of 56
  37. 37. Content Classificationsets for different audiences, providing all the information that is necessary to accomplish their responsibility andtask. Policies 3 3 Share Share Policies do not 2 Policy 2 Policy 2 duplicate Accounts Payable information. The Purchasing Policy Receiving Policy Policy Policy may be shared between functional areas. Processes Create Purchase Reference Receive Materials Reference Pay Vendor Order Only Only Processes should not duplicate functions. They may reference other Process where they 3 way match connect Set up Vendor Receive Material PO, Receiver, Invoice Procedures Create Purchase Inspect Materials Remit Vendor Requisition Payment Procedures should not duplicate Create Purchase Record Vendor tasks. They Order Invoice should be stand- alone. Classify Identify the content and classify it according to the document type that may use that type of content - Policy, Process, or Procedure. This will organize the content so that the documents will contain only the proper content types. Where used After classifying the content for each document type, define where the content is used, based on major business functions (for example, Procure to Pay). Content can be used in different documents, but you only want to write the content once. By defining where it can be used, you will select the document source of the content, and all other documents will link or reference it. For example, you are developing the Procure to Pay Processes and Procedures. When you are researching the system screen instructions, you will note that the screen is referenced in a business Process (Procure to Pay), a Procedure, and a system screen Procedure. You will define the source document for the system screen instructions, and other documents will refer to the source. Relationships and patterns When defining where content is used, look for relationships and patterns to be found in the content. For example, you may notice that, basically, all the vendor business functions refer to the same screens, with minor changes, based on the function being performed. You may then decide to structure the vendor screenVersion 1.0 eDocumentation™ Plan Phase Page 37 of 56
  38. 38. Content Classification Procedures, reusing certain information, as opposed to writing the same information multiple times. In the above graphic, the Create Purchase requisition and Create Purchase order may use the same screens, as the basic functions are usually the same. Different locations Standardizing Processes is achieved by having all locations perform the same tasks in the same manner. However, globally you might have each location performing a task in a slightly different way. Many times variations are required, due to local or statutory requirements. In most cases, however, the Processes are standard. Determine if localization can be achieved simply by adding a separate section, based on location, or whether the changes are so vast a new Process or Procedure is required.Overlapping content typesPolicies, Processes, and Procedures are interdependent, based upon the content contained within each one. Itmay emerge that the content types overlap between the document types, during classification and organization.Re examine the content types in order to determine where it actually belongs. This is usually determined by thepurpose and level of detail of the document type.Processes have different levels – high level overview to detail tasks. The Process, with more detail, may begin to‘look like’ a Procedure. If this is the case, you need to evaluate the Process and determine if it is actually aProcedure.Policies can be at an enterprise, location, or department level. Policies should always stand alone. But at thedepartment level, a Procedure will provide the detail to implement the Policy. Be sure that the Policy is notrestated in the Procedure. Policy Policy Content Types Content Types Process Process Content Types Content Types Change so there is no overlap Procedure Procedure Content Types Content TypeseDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 38 of 56
  39. 39. Accessible Policies, Processes, and Procedures Accessible Policies, Processes, and ProceduresAfter creating clear, concise, complete, and correct™ Policies, Processes, and Procedures, the main issuebecomes ‘How will the user quickly and easily locate and access the desired Policies, Processes, andProcedures?’ It should not involve an obstacle course to find the needed information. Users require a clear,intuitive roadmap, adapted to the user’s way of thinking about their content, regardless of the technology or lackof technology being used. Advanced technology does not guarantee ease of accessibility. Changes are not obvious if Policies, Processes, and Procedures are in a shared folder or listed in a Content Management system. Additional research is then required. Some companies put Policies, Processes, and Procedures in a shared folder on their server and expect users to find the Policies, Processes, and Procedures. However, the shared folder does not have any intelligence associated with it. Although in a central location, they are not easily and readily accessible. Some companies put in a Content Management system without the correct keywords or categories and expect users to find Policies, Processes, and Procedures among the hundreds of other documents. Although a system application may have online help, this is usually restricted to brief system Procedures. The online help does not address the Policies and Processes associated with the Procedure. Therefore, critical Policy and Process information would not be accessible. Some companies use paper manuals and group all of the relevant Policies, Processes, and Procedures in one place so that the users can scan thru the manual. This can be quite primitive.FactorsAccessibility takes into account a variety of factors, many of them identified in previous eDocumentation™ tasks.It is an analysis of the information and verification with the users that determine the final approach. Accessibilityis dependent on the user behavior and requirements, and cannot be comprised of a stand-alone solution – even ifyou are using only a paper-based approach. Audience Evaluation The Audience Evaluation, performed during the Planning phase, is used for accessibility planning. Each audience is evaluated to determine the parameters they use to access Policies, Processes, and Procedures. Such questions that would be asked to identify the factors are the following: Where are the department or functional Policies, Processes, and Procedures? Are the documents on a shared drive? Are the documents in a content management system? How are specific Policies, Processes, and Procedures located? Do the users read the file name? Do the users use the title? Is there a brief description associated with the document? How is a Policy, Process, or Procedure determined to be the proper document? Does the user have to open and read the document to determine if it contains the needed content to answer a question? Technology used The available technologies identified during the Planning phase is used for accessibility planning. The technology is evaluated to determine if it can be used for the project, and if it is appropriate for the project. What type of technology is used for storing and accessing the Policies, Processes, and Procedures? Is the technology available to every audience? If not, what is the access method for those audiences?Version 1.0 eDocumentation™ Plan Phase Page 39 of 56
  40. 40. Accessible Policies, Processes, and Procedures What are the basic capabilities of the technology? Category and keyword evaluation The categories and keywords identified during the Planning phase are used for accessibility planning. The categories and keywords are evaluated to determine if they can be used for the project, and if they are appropriate for the project. Is a search engine available to the users? Are categories and keywords defined? Are the categories and keywords successful in quickly locating a Policy, Process, or Procedures? Have the categories and keywords been verified and tested with the users? User functionality Users of Policies, Processes, and Procedures have unique accessibility requirements. Notify user of changes to documents so that they will know what to review and when to review. Provide email notifications to users of new or changed Policies, Processes, and Procedures. The email should contain a link to the new or changed documents. Provide alerts on the Home Page to alert users of new or changed documents. Provide a list of the Policies, Processes, and Procedures with the respective overview descriptions. Provide meaningful Policy, Process, and Procedure titles to identify the document. Provide specific and effective category and keywords to search and identify documents. Policy, Process, and Procedure categories and keywords must be tailored for those documents and users. They may or may not fit with an existing taxonomy. Provide a map that acts as a guide to the proper locations for the Policies, Processes, and Procedures. Provide users with the capability to sort the Policies, Processes, and Procedures in a way that is meaningful to them; by category, department, function, review date, author, or owner. Incorporate change management functionality; reporting needed changes, errors, issues, or suggestions. Separate – totally – from the source documents, what the user views and accesses. Do not allow changes to be made outside the change management Process.Be preparedIf your company does not currently have technology to support the access of Policies, Processes, and Procedures(i.e., a content management system; a search engine available to users; a taxonomy for Policies, Processes, andProcedures; or a web based access for users), it is probably only a matter of time before the technology isavailable.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 40 of 56
  41. 41. Accessible Policies, Processes, and ProceduresImplementVersion 1.0 eDocumentation™ Plan Phase Page 41 of 56

×