1. eDocumentation Process Introduction Phase

839 views

Published on

Published in: Business, Education
  • Be the first to comment

1. eDocumentation Process Introduction Phase

  1. 1. eDocumentation™ ProcessIntroduction Knowledge Process, Inc. www.DocumentationProcess.com www.KCGGroup.com
  2. 2. Table of Contents - Introduction Table of Contents - Introduction  Table of Contents - Introduction ........................................................................................................... 2 eDocumentation™ Process ................................................................................................................... 4  What is the eDocumentation™ Process? .............................................................................................................. 4  Who should know about the eDocumentation™ Process? ................................................................................... 4  How is the eDocumentation™ Process organized? .............................................................................................. 5  What subjects does the eDocumentation™ Process address?............................................................................. 6  eDocumentation™ Process phase ........................................................................................................................ 6 eDocumentation™ Process Flow .......................................................................................................... 7  eDocumentation™ Process phases....................................................................................................................... 7  eDocumentation™ Process phase ........................................................................................................................ 9 Clear, Concise, Complete, and Correct™ ........................................................................................... 10  Clear ..................................................................................................................................................................... 10  Concise ................................................................................................................................................................ 10  Complete .............................................................................................................................................................. 10  Correct ................................................................................................................................................................. 10  eDocumentation™ Process phase ...................................................................................................................... 10 Data, Information, Knowledge, and Wisdom ...................................................................................... 11  Data ...................................................................................................................................................................... 11  Information ........................................................................................................................................................... 11  Knowledge ........................................................................................................................................................... 12  Wisdom ................................................................................................................................................................ 12  Understanding ...................................................................................................................................................... 12  Summary .............................................................................................................................................................. 13  eDocumentation™ Process phase ...................................................................................................................... 13 Policy, Process, and Procedure – What Is the Difference? .............................................................. 14  Policy qualities ..................................................................................................................................................... 14 Version 2.0 Page 2 of 20
  3. 3. Table of Contents - Introduction Process qualities .................................................................................................................................................. 14  Procedure qualities .............................................................................................................................................. 14  Driving from Hollywood to Los Angeles – A Policy, Process, and Procedure ..................................................... 15  eDocumentation™ Process phase ...................................................................................................................... 16 Policies, Processes, and Procedures Developer ............................................................................... 17  Skills ..................................................................................................................................................................... 18  eDocumentation™ Process phase ...................................................................................................................... 19 Knowledge Process, Inc....................................................................................................................... 20  About Knowledge Process ................................................................................................................................... 20  Copyright .............................................................................................................................................................. 20 Version 2.0 Page 3 of 20
  4. 4. eDocumentation™ Process eDocumentation™ ProcessDeveloping and maintaining Policies, Processes, and Procedures that are clear, concise, complete, and correct™for the proper users is the simple objective of the eDocumentation™ Process. This has always been the objectivefor all Policies, Processes, and Procedures developed by Knowledge Process. When developing Policies,Processes, and Procedures, specialized skills and disciplines are essential. Change is clearly a major factor forthe Policies, Processes, and Procedures user and developer and is an integral part of the eDocumentation™Process.There is no doubt that technology has greatly assisted in creating Policies, Processes, and Procedures such asContent Management systems. In addition, Policies, Processes, and Procedures are accessed and viewed viathe Web or a Portal. Therefore, Policies, Processes, and Procedures have evolved from a paper media to anelectronic media. However, technology is only part of the Process. Although there are many tools available toassist with the process, the fact remains that a person must perform the research, development, and verificationtasks when developing and maintaining Policies, Processes, and Procedures. The content acquired must then betransformed into applied knowledge for user training and reference. It is then published so that the diverseaudiences can access it and use it. The issues facing the Documentation developer is combining the technologyand processes related to the Policy, Process, or Procedure. It can be a daunting task, if all tasks are notaddressed.The importance of training and implementation support cannot be overstated. The end users must understand allaspects of the Policies, Processes, and Procedures; it is not enough to simply review and figure-them-out. Theusers, who are responsible and accountable for the application of the Policies, Processes, and Procedures, musthave a complete understanding of them.What is the eDocumentation™ Process?The eDocumentation™ Process is a structured and comprehensive guideline for developing and maintainingPolicies, Processes, and Procedures. It breaks down the effort into a series of manageable tasks and steps. Theapproach emphasizes tasks that can be defined, analyzed, evaluated, and measured. It produces predefined endproducts that measure progress and quality. It is a guideline, not a rigid set of instructions. TheeDocumentation™ Process can be used in various ways such as the following: • An introduction to developing Policies Processes, and Procedures • A reference guide to review, when developing work plans for phases and steps to ensure that all appropriate activities and tasks have been identified • A source for the development of standards within the organizationThe eDocumentation™ Process addresses the specific needs of Policies, Processes, and Procedures projectsand the Documentation developers.Who should know about the eDocumentation™ Process?Policies, Processes, and Procedures are unique types of documentation that have distinct requirements (asopposed to marketing, engineering, or white papers). Policies, Processes, and Procedures are internaldocumentation for the users of the company and, generally, are not for external distribution. If parts aredistributed externally, it is usually as a subset.Policies, Processes, and Procedures are central to the successful operation of an enterprise or department. Thetraditional approach to developing Policies, Processes, and Procedures has been to view it as a task, not aprocess. Developing Policies, Processes, and Procedures is a Process, not a task or event. A Process is agroup of structured tasks that produce a specific product for a particular user. The eDocumentation™ Processdefines the Process necessary to research, develop, verify, and implement Policies, Processes, and Procedures.Version 2.0 Page 4 of 20
  5. 5. eDocumentation™ ProcessThe eDocumentation™ Process requires that all resources needed for the Process are identified and thenparticipate as needed. This assists with breaking down the silos within an organization and therefore, starts theprocess of collaboration. Because a Process usually depends upon several business functions for support, theexpertise for eDocumentation™ tasks may depend upon different departments, depending upon the structure ofthe organization. The eDocumentation™ Process defines the phases and tasks that will lead to Policies,Processes, and Procedures that can be accessed, used, maintained, and - most important - are clear, concise,complete, and correct™ for the users.How is the eDocumentation™ Process organized?There 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 enterprise, 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. 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 an often overlooked task, but it is – without a doubt – key to the success of the overall project. The Implement phase incorporates appropriate change management principles. 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 your Policies, Processes, and Procedures current.Version 2.0 Page 5 of 20
  6. 6. eDocumentation™ ProcessWhat subjects does the eDocumentation™ Process address?When developing Policies, Processes, and Procedures, the Processes are separated, based on those relating tothe user, the developer, and the supporting disciplines or technologies. Because there are numerous supportingdisciplines and technologies (example, taxonomies), these must be considered and a determination made as torelevance. However, the disciplines and technologies do not become the objective of the Policies, Processes,and Procedures; the user is always the major focus. It is important not to lose sight of the many aspects thatmust be considered, when developing Policies, Processes, and Procedures. Considerations must include, butare not limited to the following: • Authoring • Reviews • Categories • Searches • Change management • Taxonomy • Editing • Template structure • Metadata • Verification and testing • Modular writing • Version control • Publications • Writing standards and style • QualityeDocumentation™ Process phaseIntroductionVersion 2.0 Page 6 of 20
  7. 7. 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.eDocumentation™ 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™ Introduction Page 7 of 20
  8. 8. 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.Version 1.0 eDocumentation™ Introduction Page 8 of 20
  9. 9. eDocumentation™ Process FloweDocumentation™ Process phasePlanBuildImplementationChangeVersion 1.0 eDocumentation™ Introduction Page 9 of 20
  10. 10. Clear, Concise, Complete, and Correct™ Clear, Concise, Complete, and Correct™The objective for Policies, Processes, and Procedures, using the Knowledge Process eDocumentation™Process, is that they are Clear, Concise, Complete, and Correct™.ClearPolicies, Processes, and Procedures must be clear in their intent, meaning, and instructions - not ambiguous orconfusing.ConcisePolicies, Processes, and Procedures must be concise. They should be written in a simple and consistent style;their structure intuitive so that they are easily referenced and comprehended. They should not be wordy orneedlessly complex.CompletePolicies, Processes, and Procedures must be 100% complete for the intended audience. They must have all theinformation required to understand and execute a Policy, Process, or Procedure.CorrectPolicies, Processes, and Procedures must be 100% correct in order for the user to properly comprehend andperform a task. Errors and omissions in the Policies, Processes, and Procedures cause errors and omissions inthe execution.eDocumentation™ Process phaseIntroductionVersion 1.0 eDocumentation™ Introduction Page 10 of 20
  11. 11. Data, Information, Knowledge, and Wisdom Data, Information, Knowledge, and WisdomThe concept of transforming Data, to Information, to Knowledge, to Wisdom has been utilized in numerousstudies and by industries. However, we can take this concept and use it for the research and development ofPolicies, Processes, and Procedures.Researching and developing Policies, Processes, and Procedures requires transforming data to information, toknowledge, and then to wisdom. Through this progression, understanding is increased. As you perform theresearch and development phases, you will transform the data into information, knowledge, and wisdom for usersand the enterprise.The goal is for the Policies, Processes, and Procedures to be clear, concise, complete, and correct™.Understanding the relationship and progression between data, information, knowledge, and wisdom helps youassess where you are within the Understanding scale during the research and development phases; and whetheryou are properly positioned to develop and test the documentation. If you build Policies, Processes, andProcedures before you are at the proper point on the scale, they will be fragmented and incomplete.As you progress through the scale from data through wisdom, understanding increases; and the Policies,Processes, and Procedures will be clearer, more concise, more complete, and more correct. We refer to this asthe Understanding Scale. Clear, concise, complete, and correct Wisdom Understanding priciples Knowledge Information Data UnderstandingData Data is a fact that alone is not significant, as is doesn’t relate to other data. Data may answer a very basic what question; such as a glossary definition, directory entry, or code listing. However, a definition or code may require knowledge, if the definition or code is complex.Information Information is data that is related and is therefore in context. It can then be transformed into a Process or Procedure, making it useful. Information is data that relates who, what, where and when to each other,Version 1.0 eDocumentation™ Introduction Page 11 of 20
  12. 12. Data, Information, Knowledge, and Wisdom providing a baseline for a Process (i.e. control point, cycle time) or a Procedure (i.e. date, code, screen description). While information may become input for a Process or Procedure, the level of understanding may limit that Process or Procedure to an individual or department level. Enterprise and more complex Processes and Procedures require Knowledge.Knowledge Knowledge is the application of information. Knowledge addresses how and why, in addition to who, what, where and when. The knowledge links all the information together to produce a comprehensive Policy, Process or Procedure. Knowledge allows management to gain an accurate and complete picture of the enterprise Policies, Processes, and Procedures. The Policies, Processes, and Procedures become transformed into an enterprise asset.Wisdom Wisdom is complete understanding of the effects and outcomes of Knowledge. Wisdom addresses how and why, in addition to who, what, where and when at the Enterprise level. Enterprise Policies, Processes, and Procedures must be at this understanding level to be considered permanent, otherwise the Policy and Process may be considered Conditional. Having clear, concise, complete, and correct™ Policies, Processes, and Procedures, an enterprise may now assess best practices and compliance issues. Wisdom allows for Policies, Processes, and Procedures to be modified so they reflect the strategic vision, functional alignment, best practices and operational objectives of the enterprise. Management is able to standardize Policies, Processes, and Procedures across enterprise locations, business units and departments. Policies, Processes, and Procedures become a tool for others within the enterprise for remodeling and initiatives; in that they reflect the As-Is guidelines and functions of the enterprise. They can also be referred to as a map to the organization.Understanding Understanding is what increases and supports the transition from data, to information, to knowledge, and to wisdom.Version 1.0 eDocumentation™ Introduction Page 12 of 20
  13. 13. Data, Information, Knowledge, and WisdomSummaryThe following summarizes the use of the Understanding Scale. What is represented? What is answered? How is it used? Who is the Audience? Presents data with no What Simple glossary, Individuals Data context. lists, codes Departments Information is data that Who, what, where, Simple Processes Individual Information is useful and has and when and Procedures Department context. Checklists Individuals Cheatsheets Knowledge is How and why Policies Department Knowledge instructions and know- Who, what, where, how. and when Processes, and Department Procedures Business Unit Wisdom is applying Who, what, where, Policies, Enterprise level Best Practices, strategic and when, why and Processes, and Business Unit Wisdom goals, functional how Procedures alignment, and operational objectives. Understanding is the Research and Documentation level of comprehension Develop Policies, developer and application of Processes, and Subject matter expert Understanding principles and concepts. Procedures ManagementeDocumentation™ Process phaseIntroductionVersion 1.0 eDocumentation™ Introduction Page 13 of 20
  14. 14. 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™ Introduction Page 14 of 20
  15. 15. 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™ Introduction Page 15 of 20
  16. 16. Policy, Process, and Procedure – What Is the Difference?eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Introduction Page 16 of 20
  17. 17. Policies, Processes, and Procedures Developer Policies, Processes, and Procedures DeveloperThe Policies, Processes, and Procedures developer is a vital member of a project. The Documentation developerhas the ultimate responsibility of documenting the Policies, Processes, and Procedures so that they are clear,concise, complete, and correct™. The documentation becomes the basis for training and implementation for theusers. The user’s acceptance of the new or changed system and implementation will depend upon how well thePolicies, Processes, and Procedures have been researched and developed.The Policies, Processes, and Procedures developer contributes to the documentation of the Policies, Processes,and Procedures in a number of vital ways: Interfaces with all people on the project that have any knowledge thatwill affect the documentation; coordinates information; relays information; reports issues; resolves issues; andcarries out many other coordinating tasks. The developer is the bridge between the many people who areinvolved on the project but, unfortunately, is often looked upon as simply a writer or someone that makes thedocumentation look nice. It is thought that anyone can perform the function.A company entrusts a Policy, Process, and Procedure developer with the tasks of documenting critical businessdata and processes; legal compliance requirements; and daily functions that support strategic objectives. Duringimplementation the developer provides the users with the information that is necessary to perform these criticalfunctions. Therefore, the developer must be viewed by the organization as a vital interface. The developer mustbe part of the entire project process. The developer must be part of the team during the planning anddevelopment of a project. The developer cannot operate in a vacuum and then be expected to deliver theknowledge at the end of the project.There are many horror stories about problems that could be prevented with clear, concise, complete, andcorrect™ documentation and well-trained users. A company will spend a great amount of resources developingnew strategies and the systems to support those strategies. However, it will not support the tasks that provide theneeded tools for the user - Policies, Processes, and Procedures and the subsequent training. Knowing and usingthe eDocumentation™ Process assists the developers with their critical task. Those who don’t recognize this willbe deprived of a tremendous asset.Version 1.0 eDocumentation™ Introduction Page 17 of 20
  18. 18. Policies, Processes, and Procedures DeveloperSkillsThe Documentation developer has a broad set of skills which include - but certainly not limited to - writing. Writing The Documentation developer must have solid basic writing skills to develop Policies, Processes, and Procedures that are clear and concise. They must communicate complex ideas in a straight-forward manner that a specific audience can understand and apply. Writing Policies, Processes, and Procedures is not creative writing. This can be difficult to accept for those who view themselves as creative writers. In many respects writing Policies, Processes, and Procedures is the antithesis of creative writing; the writer strives to remove excess words and flowery descriptions. Documentation developers strive to write in the same style so that all documentation appears to be written by the same person. Systems The Documentation developer works in different industries - healthcare to manufacturing. There are many unique factors within each of those industries (for example, legal issues and controls). The developer must be able to learn those factors quickly and have knowledge of tools (for example, process mapping) necessary to develop clear and consistent Policies, Processes, and Procedures. Technical There are many technologies that directly affect the Policies, Processes, and Procedures (for example, content management, search engines, taxonomies, information architecture, and training). The developer may not be an expert in these areas but must know how the technology will affect the development and implementation of Policies, Processes, and Procedures; so that the documentation will not require major modifications, if the technology is adopted by the company in the future. The Documentation developer works with different types of industry software, from retail to complex manufacturing systems. They must be able to quickly learn each, based on a foundation of previous knowledge. Using industry specific software, the Documentation developer does not require the depth of knowledge of the subject matter experts and technical personnel. However, the developer must be able to put that knowledge in context and develop a methodology to understand and prioritize the functionality and details of the software. Organization Researching and developing Policies, Processes, and Procedures requires knowledge of the organization and its goals, structure, systems, and processes. The Documentation developer must interface with people from many different departments in order to access the knowledge that is needed for clear, concise, complete, and correct™ Policies, Processes, and Procedures. Research The nature of developing Policies, Processes, and Procedures requires the Documentation developer to perform extensive research and fit all the pieces together. This is a critical skill required for the Documentation developer. Collaboration Collaboration is the skill that intertwines writing, systems, technical organization, and research together and produces clear, concise, complete, and correct™ Policies, Processes, and Procedures.The Documentation developer has a vital role to play on any project. If the project involves cross-functionalbusiness processes, which most major project do, the developer is the person that understands those areas. TheVersion 1.0 eDocumentation™ Introduction Page 18 of 20
  19. 19. Policies, Processes, and Procedures Developerdeveloper understands the issues and the complexity of the project and becomes an essential figure on theproject.eDocumentation™ Process phaseIntroductionVersion 1.0 eDocumentation™ Introduction Page 19 of 20
  20. 20. Knowledge Process, Inc. Knowledge Process, Inc.About Knowledge ProcessKnowledge Process provides services and expertise for the research, development, and validation of Content andDocumentation for Policies, Processes, and Procedures. For more information, contact: Knowledge Process Web: http://www.DocumentationProcess.comCopyright ©2009-2012 by Knowledge Process, Inc. All rights reserved Use of this site/document indicates approval and acceptance of our Terms of Use and Privacy PolicyVersion 1.0 eDocumentation™ Introduction Page 20 of 20

×