US20140096061A1 - Systems and methods for providing documentation having succinct communication with scalability - Google Patents
Systems and methods for providing documentation having succinct communication with scalability Download PDFInfo
- Publication number
- US20140096061A1 US20140096061A1 US13/794,671 US201313794671A US2014096061A1 US 20140096061 A1 US20140096061 A1 US 20140096061A1 US 201313794671 A US201313794671 A US 201313794671A US 2014096061 A1 US2014096061 A1 US 2014096061A1
- Authority
- US
- United States
- Prior art keywords
- activity
- activities
- chunk
- template
- decision
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/75—Indicating network or usage conditions on the user display
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
- H04M2201/42—Graphical user interfaces
Definitions
- the present invention relates to providing documentation having succinct communication with scalability.
- the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- process documentations are typically too large and bulky, and as a result are difficult to use. Processes and procedures can violate documentation design and writing principles, and are not designed with customers and users in mind. Process documentation typically mixes different types of information into the same paragraphs as if they were all used the same way. Current techniques make it difficult for users to find information quickly, and can cause frustration and prevent procedures from being followed.
- the present invention relates to providing documentation having succinct communication with scalability.
- the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- the present invention is implemented as a method for generating a process model representation for each of a plurality of activity chunks in a process such that each process model representation is arranged to be displayed on a single page.
- a template for a process is received.
- the template defines each work product that is used by the process, each activity performed by the process, and each role that performs an activity in the process.
- Each activity is associated with one of a plurality of activity chunks defined for the process.
- a process activity template is generated.
- a process model representation is generated for each process activity template.
- Each process model representation is arranged to be displayed on a single page and comprises a graphical representation of the flow between the activities in the represented activity chunk.
- FIG. 1 illustrates a representative system that provides a suitable operating environment for use of the present invention
- FIG. 2 illustrates a representative networked configuration
- FIG. 3 illustrates a representative process definition process in accordance with an embodiment of the present invention
- FIG. 4 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process planning stage;
- FIG. 5 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process requirements stage;
- FIG. 6 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process design stage;
- FIG. 7 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process modeling stage;
- FIG. 8 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process verification stage;
- FIG. 9 illustrates a representative process model corresponding to the process definition process of FIG. 3 , wherein the illustrated process model is a process validation stage;
- FIG. 10 illustrates a representative process work product, activities and rules (“WAR”) template for a representative decision process
- FIGS. 11-12 illustrate a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” of FIG. 10 ;
- FIGS. 13-14 illustrate a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” of FIG. 10 ;
- FIGS. 15-16 illustrate a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” of FIG. 10 ;
- FIGS. 17-34 illustrate a representative decision process guide, wherein FIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX process model format and FIGS. 25-30 illustrate chunked activities of the decision process in a swim lane process model format;
- FIG. 35 illustrates a representative process documentation design procedure in accordance with a representative embodiment of the present invention
- FIG. 36 illustrates a representative process modeling and documentation procedure in accordance with a representative embodiment of the present invention
- FIG. 37 illustrates a representative procedure for developing a procedure in accordance with a representative embodiment of the present invention
- FIG. 38 illustrates a representative form template
- FIG. 39 illustrates a representative checklist template
- FIG. 40 illustrates a representative ordered table template
- FIG. 41 illustrates a representative procedure for developing a standard in accordance with a representative embodiment of the present invention
- FIG. 42 illustrates a representative procedure for developing a policy in accordance with a representative embodiment of the present invention
- FIG. 43 illustrates a representative procedure for developing a process guide in accordance with a representative embodiment of the present invention
- FIG. 44 illustrates a representative process guide standard in accordance with a representative embodiment of the present invention
- FIGS. 45-46 illustrate a representative process work product, activities and rules (“WAR”) template for a representative configuration management (“CM”) process
- FIGS. 47-48 illustrate a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” of FIG. 45 ;
- FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” of FIG. 45 ;
- FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CSA” of FIG. 45 ;
- FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” of FIG. 45 ;
- FIGS. 55-74 illustrate a representative CM process guide.
- the present invention relates to providing documentation having succinct communication with scalability.
- the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- activity shall refer to a process building block and a process element that addresses the “what”.
- An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services.
- An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document).
- activity performed by shall refer to a relationship between an activity and a role, and is a role or roles performing or participating in an activity or activities.
- beginner mode shall refer to a process documentation that is defined for a beginner user or audience.
- beginner users are individual users who are not familiar with a particular process.
- Entry criteria shall refer to a process element that addresses the “when”. Entry criteria define the conditions under which an activity can be started, and are preconditions about the state of a work product, role, and/or activity.
- exit criteria shall refer to a process element that addresses the “when”. Exit criteria define the conditions under which an activity can be declared complete, and determine the next activity. The exit criteria are post conditions about the state of a work product, role, and/or an activity.
- expert mode shall refer to process documentation that is defined for an expert audience or user. Experts are individuals or users who are intimately familiar with a particular process.
- Input shall refer a process element that addresses the “what”.
- the input represents a relationship between an activity and a work product. Inputs are results of one or more prior activities, and are used or consumed by the activity being defined.
- intermediate mode shall refer to process documentation that is defined for an intermediate audience or user. Intermediates are individuals or users who are somewhat familiar with a particular process, but are not experts in that process.
- output shall refer to a process element that addresses the “what”.
- the output represents a relationship between an activity and a work product.
- Outputs are the results that are produced or used by the activity being described.
- policy shall refer to a process document based upon principles that guide and constrain an organization.
- the term “procedure” shall refer to a process document that is a set of activities that describe the “how to”. There are three types of procedures, namely (i) a checklist, (ii) a form, and (iii) an ordered table. A procedure provides step-by-step instructions or “how-to” information.
- process shall refer to an activity that is modeled by answering who, what, when, where and why (the five “W's”). Moreover, a process is a set of parallel or sequential activities that use and transform inputs, add value, and produce outputs and results that are directed towards achieving a purpose and a set of objectives.
- process context shall refer to answering “where”, and is usually represented by a block diagram or picture with the current process highlighted (e.g., “you are here diagram”).
- Process context is based on process identification along with sibling processes, as well as parent and children activities as appropriate, as well as any other contextual information (e.g., process owner). In at least some embodiments, if an activity must be performed in a specific location, that information is documented.
- process building block shall refer to one or more of the three process building blocks, namely activities, work products, and roles (collectively “WAR”).
- process documentation shall refer to polices, standards, processes and procedures.
- process element shall refer to a component of a process that answers who, what, when, where or why (the five “W's”).
- the nine process elements are purpose (why), activities (what), inputs (what), outputs (what), entry criteria (when), exit criteria (when), roles (who), process context (where), and process flow (where).
- Process flow shall refer to answering the “where”.
- Process flow is a conditional relationship between activities, work products, and roles.
- Flow defines the control and ordering of activities, timing of activities, and determines “where” inputs and outputs flow (e.g., the next process).
- Flow is represented in process models, block diagrams, or pictures, and controlled by entry and exit criteria.
- Control flow focuses on the entry and exit criteria control the states of work products, roles, and activities, and also determine the next process.
- Data flow relates to inputs and outputs (the data), and the flow of data among processes and is controlled by entry and exit criteria.
- Timing flow relates to when activities happen (e.g., daily, monthly, annually, etc.) and is also controlled by entry and exit criteria.
- process model shall refer to an abstraction of a process typically characterized by formal notations for representing roles, activities, and/or work products, and the relationships (e.g., events, transformations) among them.
- Types of process models include: descriptive models (as-is), which describe what is actually done or practiced; prescriptive models (to-be), which prescribes what to do (e.g., by new policies, standards, process guidelines, etc); and mixed models (both as-is and to-be), which are a combination of prescriptive and descriptive processes.
- descriptive models as-is
- prescriptive models to-be
- mixed models both as-is and to-be
- the term “purpose” shall refer to a process element that describes the rationale for an activity or process (i.e., the “why”).
- role shall refer to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”).
- sub-process shall refer to a process that is modeled by answering who, what, when, where and why (the five “W's”).
- One or more sub-processes make up a process.
- Sub-processes are also referred to as “chunks”, and can be made up of one or more sub-processes.
- template shall refer to a process document that comprises sections or parts.
- An “annotated template” is a standard (see also the definition of standard).
- Standard shall refer to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections.
- Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures.
- a list of just sections or parts is not a standard, but is a template.
- An “annotated template” is a standard because it also comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections.
- work product shall refer to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”).
- FIG. 1 and the corresponding discussion are intended to provide a general description of a suitable operating environment in which some embodiments of the present invention may be implemented.
- One skilled in the art will appreciate that the invention may be practiced by one or more computing devices and in a variety of system configurations, including in a networked configuration.
- Embodiments of the present invention embrace one or more computer readable media, wherein each medium may be configured to include or includes thereon data or computer executable instructions for manipulating data.
- the computer executable instructions include data structures, objects, programs, routines, or other program modules that may be accessed by a processing system, such as one associated with a general-purpose computer capable of performing various different functions or one associated with a special-purpose computer capable of performing a limited number of functions.
- Computer executable instructions cause the processing system to perform a particular function or group of functions and are examples of program code means for implementing steps for methods disclosed herein.
- a particular sequence of the executable instructions provides an example of corresponding acts that may be used to implement such steps.
- Examples of computer readable media include random-access memory (“RAM”), read-only memory (“ROM”), programmable read-only memory (“PROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), compact disk read-only memory (“CD-ROM”), or any other device or component (e.g., DVD) that is capable of providing data or executable instructions that may be accessed by a processing system.
- RAM random-access memory
- ROM read-only memory
- PROM programmable read-only memory
- EPROM erasable programmable read-only memory
- EEPROM electrically erasable programmable read-only memory
- CD-ROM compact disk read-only memory
- any other device or component e.g., DVD
- a representative system for implementing the invention includes computer device 10 , which may be a general-purpose or special-purpose computer.
- computer device 10 may be a personal computer, a notebook computer, a personal digital assistant (“PDA”) or other hand-held device, a workstation, a minicomputer, a mainframe, a supercomputer, a multi-processor system, a network computer, a processor-based consumer electronic device, or the like.
- PDA personal digital assistant
- Computer device 10 includes system bus 12 , which may be configured to connect various components thereof and enables data to be exchanged between two or more components.
- System bus 12 may include one of a variety of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus that uses any of a variety of bus architectures.
- Typical components connected by system bus 12 include processing system 14 and memory 16 .
- Other components may include one or more mass storage device interfaces 18 , input interfaces 20 , output interfaces 22 , and/or network interfaces 24 , each of which will be discussed below.
- Processing system 14 includes one or more processors, such as a central processor and optionally one or more other processors designed to perform a particular function or task. It is typically processing system 14 that executes the instructions provided on computer readable media, such as on memory 16 , a magnetic hard disk, a removable magnetic disk, a magnetic cassette, an optical disk, or from a communication connection, which may also be viewed as a computer readable medium.
- processors such as a central processor and optionally one or more other processors designed to perform a particular function or task. It is typically processing system 14 that executes the instructions provided on computer readable media, such as on memory 16 , a magnetic hard disk, a removable magnetic disk, a magnetic cassette, an optical disk, or from a communication connection, which may also be viewed as a computer readable medium.
- Memory 16 includes one or more computer readable media that may be configured to include or includes thereon data or instructions for manipulating data, and may be accessed by processing system 14 through system bus 12 .
- Memory 16 may include, for example, ROM 28 , used to permanently store information, and/or RAM 30 , used to temporarily store information.
- ROM 28 may include a basic input/output system (“BIOS”) having one or more routines that are used to establish communication, such as during start-up of computer device 10 .
- BIOS basic input/output system
- RAM 30 may include one or more program modules, such as one or more operating systems, application programs, and/or program data.
- One or more mass storage device interfaces 18 may be used to connect one or more mass storage devices 26 to system bus 12 .
- the mass storage devices 26 may be incorporated into or may be peripheral to computer device 10 and allow computer device 10 to retain large amounts of data.
- one or more of the mass storage devices 26 may be removable from computer device 10 .
- Examples of mass storage devices include hard disk drives, magnetic disk drives, tape drives and optical disk drives.
- a mass storage device 26 may read from and/or write to a magnetic hard disk, a removable magnetic disk, a magnetic cassette, an optical disk, or another computer readable medium.
- Mass storage devices 26 and their corresponding computer readable media provide nonvolatile storage of data and/or executable instructions that may include one or more program modules such as an operating system, one or more application programs, other program modules, or program data. Such executable instructions are examples of program code means for implementing steps for methods disclosed herein.
- One or more input interfaces 20 may be employed to enable a user to enter data and/or instructions to computer device 10 through one or more corresponding input devices 32 .
- input devices include a keyboard and alternate input devices, such as a mouse, trackball, light pen, stylus, or other pointing device, a microphone, a joystick, a game pad, a satellite dish, a scanner, a camcorder, a digital camera, and the like.
- input interfaces 20 that may be used to connect the input devices 32 to the system bus 12 include a serial port, a parallel port, a game port, a universal serial bus (“USB”), a firewire (IEEE 1394), or another interface.
- USB universal serial bus
- IEEE 1394 firewire
- One or more output interfaces 22 may be employed to connect one or more corresponding output devices 34 to system bus 12 .
- Examples of output devices include a monitor or display screen, a speaker, a printer, and the like.
- a particular output device 34 may be integrated with or peripheral to computer device 10 .
- Examples of output interfaces include a video adapter, an audio adapter, a parallel port, and the like.
- One or more network interfaces 24 enable computer device 10 to exchange information with one or more other local or remote computer devices, illustrated as computer devices 36 , via a network 38 that may include hardwired and/or wireless links.
- network interfaces include a network adapter for connection to a local area network (“LAN”) or a modem, wireless link, or other adapter for connection to a wide area network (“WAN”), such as the Internet.
- the network interface 24 may be incorporated with or peripheral to computer device 10 .
- accessible program modules or portions thereof may be stored in a remote memory storage device.
- computer device 10 may participate in a distributed computing environment, where functions or tasks are performed by a plurality of networked computer devices.
- FIG. 2 represents an embodiment of the present invention in a networked environment that includes a variety of clients connected to a server system via a network. While FIG. 2 illustrates an embodiment that includes multiple clients connected to the network, alternative embodiments include one client connected to a network, one server connected to a network, or a multitude of clients throughout the world connected to a network, where the network is a wide area network, such as the Internet.
- embodiments of the present invention embrace non-networked environments, such as where at least a portion of defining and documenting processes, procedures, standards and policies is generated utilizing a single computer device. At least some embodiments of the present invention further embrace defining and documenting processes, procedures, standards and policies that are succinct, usable and scalable, wherein at least a portion does not require a computer device.
- Server system 40 represents a system configuration that includes one or more servers.
- Server system 40 includes a network interface 42 , one or more servers 44 , and a storage device 46 .
- a plurality of clients illustrated as clients 50 and 60 , communicate with server system 40 via network 70 , which may include a wireless network, a local area network, and/or a wide area network.
- Network interfaces 52 and 62 are communication mechanisms that respectfully allow clients 50 and 60 to communicate with server system 40 via network 70 .
- network interfaces 52 and 62 may be a web browser or other network interface.
- a browser allows for a uniform resource locator (“URL”) or an electronic link to be used to access a web page sponsored by a server 44 . Therefore, clients 50 and 60 may independently access or exchange information with server system 40 .
- URL uniform resource locator
- server system 40 includes network interface 42 , servers 44 , and storage device 46 .
- Network interface 42 is a communication mechanism that allows server system 40 to communicate with one or more clients via network 70 .
- Servers 44 include one or more servers for processing and/or preserving information.
- Storage device 46 includes one or more storage devices for preserving information, such as a particular record of data. Storage device 46 may be internal or external to servers 44 .
- the networked system is used to define and document processes, procedures, standards and/or policies.
- processes and procedures are defined and communicated in such a way that is more succinct and usable to document, measure and improve business, as will be further discussed below.
- the networked system of FIG. 2 is a representative system in accordance with the present invention. Accordingly, embodiments of the present invention embrace other computer system configurations for performing methods disclosed herein.
- embodiments of the present invention relate to providing documentation having succinct communication with scalability.
- embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- a lean process is a business method or technique that allows processes and procedures to be defined in, for example, 25-50% of their usual size. A lean process helps organizations define processes and procedures that are shorter and more usable.
- a lean process addresses the common problems with process documentation and is based on such principles as process documentation types (i.e., policies, standards, processes, and procedures), process documentation usage modes (e.g., Expert Mode), lean policies (one page policies per process area), lean standards (one page standards), lean processes (e.g., addressing the 5 W's of who, what, when, where and why in a diagram on one page per process or sub-process), lean procedures (e.g., addresses the “how” in a checklist, form, or ordered table on one page), and lean documentation (one page) that can be used on websites.
- process documentation types i.e., policies, standards, processes, and procedures
- process documentation usage modes e.g., Expert Mode
- lean policies one page policies per process area
- lean standards one page standards
- lean processes e.g., addressing the 5 W's of who, what, when, where and why in a diagram on one page per process or sub-process
- lean procedures e.g
- FIG. 3 a representative block diagram is illustrated to provide a representative embodiment for generating a lean process.
- the iterative planning phase includes a process planning stage and a process requirements stage.
- the process planning stage comprises the following sub-processes: (i) product plan, which comprises the purpose, scope, audience, and usage; and (ii) work plan, which comprises the charter, schedule, and resources.
- the process requirements stage comprises identifying the following four types of requirements: (i) organizational requirements; (ii) industry model requirements (e.g., ISO, Baldrige, CMMI, etc.); (iii) representation requirements; and/or (iv) other requirements.
- the iterative modeling phase comprises a process design stage and a process modeling stage.
- the process design stage comprises (i) documenting design decisions (e.g., selecting a process model representation), (ii) documenting the initial process model, (iii) identifying activities, work products, and roles for each process and sub-process, (iv) grouping the activities into “chunks” or sub-processes with no more than ten activities (i.e., the seven plus or minus two rule), and optionally (v) completing the process activity templates for each process and sub-process.
- the process implementation stage comprises (i) modeling the process using the selected process modeling approach; (ii) modeling who, what, when, where and why (the five W's) on a single page for each process or sub-process (e.g., for expert mode); (iii) iterating for each level of the process model (can iterate the process definition phase or the entire lean process); (iv) developing process description tables (e.g., for intermediate mode), wherein the goal is one page for each process model; (v) developing the procedure(s) on a single page in expert mode; (vi) developing the policies on one page in expert mode; (vii) developing the standards on a single page in expert mode; and (viii) developing the process guide to put all of the pieces together.
- the iterative verification and validation phase includes a process verification stage and a process validation stage.
- the process verification stage comprises (i) verifying the process against the planning, requirements, and design; (ii) verifying the correctness, consistency, and completeness (the three Cs); and (iii) removing defects from the process.
- the Process Validation Stage comprises (i) validating the process with the process experts and users (e.g., using a walkthrough); and (ii) Pilot testing the process (this can also be a separate process).
- Process documentation refers to policies, standards, processes and procedures.
- policies are typically used by senior management to set direction in an organization, state principles that organizations should follow, and provide requirements for processes, procedures, and training.
- Standards typically specify the parts of a document, provide a description of what is to be included, make the content of documents repeatable, and provide requirements for processes, procedures, and training.
- Processes refer to what happens over time to produce a desired result, add value, answer the five W's of who, what, where, when, and why, and are supported by procedures, training, and tools.
- Procedures provide step-by-step information that implements at least part of a process. Training is used by beginners and taught by instructors (e.g., experts), and provides the necessary knowledge and skills Training can be voluminous.
- Processes and procedures have different levels of users. Some users have never used the process (e.g., beginner users). Some users have used the process a few times, but need guidance and lessons learned (e.g., intermediate users). Some users have used the process many times and may even be responsible for running the process (e.g., experts). The following describes the three levels of documentation: expert, intermediate, and beginner.
- Expert Mode documentation is short and concise. When a pilot flies an airplane, he or she does not pull out training manuals. Instead, pilots use expert checklists for take off and landing. Expert mode documentation is made for experts and it does not contain any training material. An advantage of expert mode documentation is that it is short, however not everybody is an expert. Thus, for example, not everyone can read a checklist for a rocket scientist (i.e., sometimes you really need to be an rocket scientist). Experts can utilize documentation because people can forget things. This is why checklists are so powerful. Experts can also leave your organization, taking precious organizational knowledge with them. This is why expert knowledge should be documented.
- “Intermediate Mode” documentation uses the expert mode documentation, but builds and adds to it by providing guidance and lessons learned. For example, guidance is very useful to people that don't have to follow a process or procedure very often. Even experts forget guidance and lessons learned for an annual process or an infrequently used process. Having guidance available to those who want it is very useful.
- a process should address who, what, when, where and why, answer key process questions, include both pictures and words, be short, usable, chunked, labeled, and well written.
- a lean process addresses the five W's (who, what, when, where and why) in a diagram or process model on a single page (Expert Mode), is chunked (e.g., having 10 or less activities), and fits on one page in a process description table (Intermediate Mode).
- the following provides a representative relationship between the five W's, key process questions to be answered by a process, and process elements identified by a process.
- a lean procedure includes “how to, step-by-step” information that may come in three forms: checklists, forms, and/or ordered tables, and is a single page long.
- Checklists are very powerful, repeatable representations of activities that need to be completed in order to declare a something completed. What makes checklists so powerful is that it usually doesn't matter what order the checklist is completed. This is why checklists are very useful for concurrent activities (e.g., versus flowcharts which are very poor at representing concurrency). Good checklists are kept to 1 page long.
- Forms along with instructions for completing the forms, are repeatable mechanisms for supporting processes.
- Forms are powerful mechanisms for collecting data in a repeatable way. If possible, keep forms to one page long (Form instructions may be on the back of a page (e.g., hardcopy), or by clicking for more information (e.g., online)).
- Ordered procedure tables are very useful when sequence or order matters. For example, if a person needs to track his or her time, starting to track time should not be the last step.
- the following is an example of an ordered procedure table:
- Step Action 1 Begin to track time (e.g., write down the start time). 2 Look for defects in the selected work product by using the appropriate data driven checklist. 3 Log the defects of the Defect Form. Continue logging defects until the work product is completely inspected using the checklist. 4 End tracking time (e.g., write down the end time). Calculate the total time spent looking for and logging defects, and record the total time on the Defect Form.
- time e.g., write down the start time
- 3 Log the defects of the Defect Form. Continue logging defects until the work product is completely inspected using the checklist. 4 End tracking time (e.g., write down the end time). Calculate the total time spent looking for and logging defects, and record the total time on the Defect Form.
- FIG. 3 provides a representative process definition process. The following provides a discussion relating to each of the process stages.
- the purpose of the process planning stage is to ensure process satisfies the customer's needs, to establish criteria to verify and validate process, and to obtain sponsorship and plan resources.
- Benefits of process planning are that (i) the customers/users of the process are identified, (ii) the scope and boundaries of the process are defined, (iii) how the customers/users will use the process is understood, (iv) there is buy-in and consensus on the process, (v) the process assumptions are documented and can be communicated to others, (vi) The process modeling team understands what process they are developing, (vii) the resources are planned so the lean process has a better chance to be on schedule and on budget.
- Measurable objectives for process planning includes that (i) process purpose, scope, customers, and usage are documented and understood, (ii) there is consensus on purpose, scope, customers, and usage for the process, (iii) the purpose, scope, customers, and usage assumptions are used to guide process development, and (iv) there is a process plan or charter that documents i-iii, and documents the necessary resources (i.e., time and money).
- process requirements stage is to identify and document process requirements (e.g., SEI CMMI, ISO, organizational, etc.)
- process requirements are that (i) documenting process requirements helps ensure that they are implemented and (ii) process requirements (e.g., ISO. CMMI, other industry process standards) can also be documented and met.
- process requirements e.g., ISO. CMMI, other industry process standards
- Measurable objectives of process requirements include (i) Organizational requirements, (ii) industry process requirements, (iii) process representation requirements, and (iv) other process requirements are documented and reviewed.
- process design stage The purpose of the process design stage is to document the process design and design decisions.
- process design Through process design, one may acquire the necessary process knowledge, answer the “how to” design questions (e.g., process representation, process tools, etc), document process design and key decisions, use initial model as a “frame of reference” for any process interviews (e.g., descriptive models), and translate organizational process documentation, interview data, leading-edge process documentation, etc., into the process templates and update initial process model.
- Benefits of process design include that it (i) increases understanding of the process (both prescriptive and descriptive), (ii) documents the design (e.g., process templates), critical design decisions, and why they were made, (iii) establishes a common “frame of reference” for communication, (iv) helps identify organizations, process experts, and users of the process, and (v) identify defects, missing information, or inconsistent information.
- Measurable objectives of the process design stage include that (i) all relevant process documentation has been identified and reviewed, (ii) that the process design and critical design decisions have been documented (e.g., process templates), (iii) that the process templates have been completed, (iv) that the initial process model has been updated (e.g., 3-10 activities, inputs, outputs, roles, etc., have been identified), and (v) that the initial process model defines the scope and perspective of the process.
- a successful process design includes listing all the process building blocks of work products, activities, and roles (i.e., Process WAR templates). For a given process, these WAR process templates are then “chunked” (i.e., 7 plus or minus 2). Activities are the most complex building block on the Process WAR Template, and are chunked into sub-processes. Reference is made to FIG. 10 , which illustrates a representative Process War Template for Configuration Management (CM). Please note the activity “chunks” (7.1, 7.2, 7.3, 7.4). Each chunk is a sub-process of the CM Process example.
- CM Process War Template for Configuration Management
- process modeling stage The purpose of the process modeling stage is to build the model using the process templates.
- process modeling one can translate the data from the design (i.e., process templates) into a more useful representation, and assist in process engineering, data analysis, measurement, planning, control, improvement, process simulation, etc.
- Benefits of process modeling include that (i) modeling leads to a detailed understanding of the process, and the many process relationships, (ii) models improve communication of the process to others, (iii) models can help identify missing requirements, design, inputs, outputs, etc., and (iv) models help identify defects in the process itself, and reduce defects when the processes used.
- Measurable objectives of process modeling include that (i) all data from the process templates are captured in the process model, (ii) the model accurately represents the process (i.e., the 5 W's) on one page in expert mode, and (iii) the model satisfies the process plan, the requirements, and the design.
- the intermediate mode process tables can be developed. For each step in the process model (i.e., activity), more detail is given (e.g., guidance, lessons learned, etc.). Policies, standards, and procedures also should be written to be 1 page (can be written either expert or intermediate mode).
- process verification stage The purpose of the process verification stage is to verify that the process meets the plan, requirements, design, and the process is free from defects. Through process verification, one can ensure the process plan, requirements, and design are satisfied in the model and the process guide, and eliminate defects.
- Benefits of process verification are that (i) the process meets the process planning, requirements, and design, (ii) verifying the process eliminates defects (mismatching inputs and outputs, inconsistencies, etc), (iii) verification reduces rework in subsequent iterations of building the process model (if using a top-down approach), and (iv) verification helps the process to be the three C's (correct, consistent, and complete).
- Measurable objectives of process verification includes that it is able to verify that the process (i.e., model and guide) (i) meets the process plan, requirements, and design, (ii) accurately represents the process templates, and (iii) has been inspected/reviewed to remove defects.
- One approach to successfully verifying a process model is to recognize that there are 6 relationships among the 3 process building blocks of work products, activities, and roles (i.e., N*(N ⁇ 1)).
- One verification objective is to verify these 6 relationships and ensure that they are correct.
- process validation stage The purpose of the process validation stage is to validate that the process meets the customers/users needs. Through process validation, one is able to ensure that the customers and users needs are met, and ensure that the customers and users agree that the process planning, requirements, and design are met.
- Benefits of process validation include that (i) process experts reach agreement and consensus on the process, (ii) you know that the process successfully meets the customer(s) and user(s) needs, (iii) you know when you are done, and (iv) it reduces rework in subsequent iterations—adds quality.
- Measurable objectives include that (i) customers and users reach consensus that the process meets their needs, (ii) customers and users reach consensus that the process meets the process plan, requirements, and design, and (iii) the process model effectively communicates the process it represents.
- a best practice to validate process models is to perform a walkthrough of the process models with the customers and users.
- the customers/users provide feedback on whether or not the process model meets their needs. They raise process issues and make suggestions for improvement.
- embodiments of the present invention embrace providing documentation having succinct communication with scalability.
- embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- FIG. 10 illustrates a representative process work product, activities and roles (“WAR”) template for the representative decision process.
- WAR process work product, activities and roles
- a WAR template focuses on a high level design prior to expanding out into specific details, which are eventually chunked and used to provide the succinct, usable and scalable documentation.
- a WAR template can be used as a basic building block as it defines the work products, activities and roles of the process.
- the illustrated WAR template identifies the work products that are used and produced by the decision process as being (i) a decision package, (ii) a decision matrix procedure, (iii) a decision presentation, (iv) a decision state, and (v) meeting minutes.
- the term “work product” refers to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”). As illustrated, each work product is assigned an identification code.
- the decision package includes the decision matrix procedure and decision presentation.
- the decision matrix procedure includes document information, such as the document version information (e.g., program name and identification, document title, document version number and/or date, program manager, name of preparer, preparation date, name of reviewer, review date, and/or other relevant information) and the document version history (e.g., identifying the version number, version date, name of the preparer, name of reviewer, description, and/or other information) that gather and organize information.
- the decision matrix procedure further includes a decision form that enables the gathering of information, such as relating to the decision team, decision makers, search results (e.g., historical data, decisions, lessons learned, etc.), alternative evaluation methods (e.g., simulation), decisions (e.g., recommendations), decision rationale, decision risks, decision benefits, and the like.
- the decision matrix procedure further includes a Decision Analysis Resolution (“DAR”) procedure.
- the DAR procedure identifies a particular sequence of actions that are to be performed.
- the DAR procedure includes the following sequence of actions (ordered table):
- a decision matrix procedure further includes a decision matrix (A representative decision matrix is illustrated as FIG. 34 , and will be discussed below.) and an advantage/disadvantage form that gathers information relating to the pros and cons of the process.
- a decision matrix A representative decision matrix is illustrated as FIG. 34 , and will be discussed below.
- an advantage/disadvantage form that gathers information relating to the pros and cons of the process.
- particular options are identified in a form that identifies and gathers information relating to advantages and/or disadvantages of each option.
- a decision presentation includes, for example, an outline of the presentation and then provides specifics relating to the (i) introduction, (ii) decision options, (iii) decision matrix form, (iv) DAR information, and (v) recommendations.
- the decision states are: (i) A—more information needed, (ii) B—no decision needed, and (iii) C—final decision.
- Decision state A is new information (e.g., a new option, criteria, criteria rank, or evaluation method) that is required or becomes available and the decision analysis and evaluation is to be repeated.
- Decision state B is determined by the decision maker(s) that a decision is no longer needed or necessary. This state exits the decision process.
- Decision state C is the decision of the decision maker(s) with consensus. The decision is final (unless new information becomes available later where the need for a new decision is be determined).
- the meeting minutes is, for example, a form that gathers and identifies information such as the meeting agenda (e.g., attendance, meeting title, date/time, location, purpose—respectively, who, what, when, where, and why).
- Tables may be provided to gather and/or document agenda item descriptions, action item descriptions, issue descriptions, and decision/agreement descriptions.
- the WAR Template of FIG. 10 identifies the activities that are to be performed.
- the term “activity” refers to a process building block and a process element that addresses the “what”.
- An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services.
- An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document).
- each chunk includes a maximum of 7 ⁇ 2 activities.
- embodiments of the present invention embrace chunking that includes more or less activities.
- the particular decision process is identified as identification code 6.0.
- the particular activities are identified as identification codes 6.1-6.3.5.
- the activities have been chunked into three chunks, specifically “Prepare for Decision” (6.1), “Conduct Decision Meeting” (6.2), and “Perform Decision Follow-Up” (6.3).
- Each activity chunk includes a corresponding process activity template, as illustrated in FIGS. 11-16 .
- Each chunk is a sub-process.
- Those skilled in the art will appreciate that embodiments of the present invention may include sub-processes having their own sub-processes.
- the WAR Template of FIG. 10 further includes the particular roles.
- the term “role” refers to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”).
- the illustrated roles are the decision makers, decision team, decision team representative, management and recorder.
- FIGS. 11-12 a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” of FIG. 10 is illustrated.
- the process activity template of FIGS. 11-12 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.1.
- FIGS. 13-14 illustrate a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” of FIG. 10 .
- the process activity template of FIGS. 13-14 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.2.
- FIGS. 15-16 illustrate a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” of FIG. 10 .
- the process activity template of FIGS. 15-16 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.3.
- FIGS. 17-34 illustrate a representative decision process guide for the present decision process, wherein FIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX format and FIGS. 25-30 illustrate chunked activities of the decision process in a swim lane format.
- the decision process guide enables a user to perform a particular process and includes corresponding procedures, standards and policies. While examples of manners for obtaining the process guide will be provided below, the following process guide is provided to illustrate the particular aspects of a representative process guide.
- the process guide includes the purpose, the scope and decision policy, the audience, usage, and particular definitions, acronyms and references.
- FIG. 18 a graphical representation of the decision process 80 is illustrated, which includes a phase for each chunked activity, namely 6.1 Prepare for Decision, 6.2 Conduct Decision Meeting, and Perform Decision Follow-up. Additionally the particular arrows of the graphical representation of the decision process 80 illustrate the various outputs, namely more information needed (A), no decision needed (B), and final decision (C).
- FIG. 19 an expert mode of activity 6.1 Prepare for Decision is provided in an ETMX process model format.
- FIG. 20 illustrates an intermediate mode of activity 6.1 Prepare for Decision.
- FIGS. 19-20 further include all of the activities that have been chunked. It is noted that in FIG. 19 , representation 90 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.1 in the overall decision process.
- FIG. 21 an expert mode of activity 6.2 Conduct Decision Meeting is provided in an ETMX process model format.
- FIG. 22 illustrates an intermediate mode of activity 6.2 Conduct Decision Meeting.
- FIGS. 21-22 further include all of the activities that have been chunked. It is noted that in FIG. 21 , representation 100 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.2 in the overall decision process.
- FIG. 23 an expert mode of activity 6.3 Perform Decision Follow-Up is provided in an ETMX process model format.
- FIG. 24 illustrates an intermediate mode of activity 6.3 Perform Decision Follow-Up.
- FIGS. 23-24 further include all of the activities that have been chunked. It is noted that in FIG. 23 , representation 110 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.3 in the overall decision process.
- FIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX process model format.
- Embodiments of the present invention embrace documenting in a variety of formats or manners to communicate in a succinct and understandable manner that is usable by a particular user and is scalable to the complexity of the process and to abilities of the individual user.
- FIGS. 25-30 illustrate same chunked activities of the decision process as are illustrated in FIGS. 18-24 , however FIGS. 25-30 illustrate the chunked activities of the decision process in a swim lane format.
- FIG. 25 an expert mode of activity 6.1 Prepare for Decision is provided in a swim lane process model format. Similar to FIG. 20 , FIG. 26 illustrates an intermediate mode of activity 6.1 Prepare for Decision. FIGS. 25-26 further include all of the activities that have been chunked. It is noted that in FIG. 25 , representation 90 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.1 in the overall decision process.
- FIG. 27 an expert mode of activity 6.2 Conduct Decision Meeting is provided in a swim lane process model format. Similar to FIG. 22 , FIG. 28 illustrates an intermediate mode of activity 6.2 Conduct Decision Meeting. FIGS. 27-28 further include all of the activities that have been chunked. It is noted that in FIG. 27 , representation 100 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.2 in the overall decision process.
- FIG. 29 an expert mode of activity 6.3 Perform Decision Follow-Up is provided in a swim lane process model format. Similar to FIG. 24 , FIG. 30 illustrates an intermediate mode of activity 6.3 Perform Decision Follow-Up. FIGS. 29-30 further include all of the activities that have been chunked. It is noted that in FIG. 29 , representation 110 is similar to representation 80 ( FIG. 18 ) and identifies to the user the location of activity 6.3 in the overall decision process.
- the process guide includes the relevant records, interfaces, metrics, forms and templates, training, and emergency decisions.
- a representative decision presentation standard is provided.
- the term “standard” refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures. A list of just sections or parts is not a standard, but is a template.
- FIG. 33 the representative decision matrix procedure (discussed above) is illustrated.
- the decision matrix identifies the various criteria (e.g., mission objectives, return on investment, cost, schedule, measure of potential impact, risk, safety, supportability, etc.) considered and the weight assigned to the criteria. It further includes a ranking scale, various available options that are being considered that are ranked by criteria, and the sums of each.
- criteria e.g., mission objectives, return on investment, cost, schedule, measure of potential impact, risk, safety, supportability, etc.
- Embodiments of the present invention embrace a variety of manners that enable documentation having succinct communication with scalability.
- a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure of FIG. 35 illustrates how to design lean process documentation in accordance with a representative embodiment of the present invention.
- the illustrated procedure documents the design phase for defining a process or sub-process in accordance with an embodiment of the present invention.
- a process WAR template is utilized for the scope of the process.
- the work products, activities and roles are identified.
- any list in the WAR template has more than a particular maximum number of items, wherein the maximum number can be any established number, then the list is selectively chunked. Roles, work products and/or activities may be identified as needing to be chunked. Duplicates are consolidated. In chunking activities, some embodiments look for process chunks, such as planning, control and improvement. If a meeting or event is to occur, chunking may be associated with being prior to, during, or after the meeting or event. In at least some embodiments of the present invention, chunks are named descriptively.
- the initial process model is updated to match the chunked activities.
- a block diagram may be used, wherein one box is provided for each chunked activity. Such activities may be sequential or concurrent.
- a process activity template is completed for each chunked activity.
- all nine process elements e.g., inputs, outputs, activities, process context, entry criteria, exit criteria, purposes, process flow, and roles
- process activity template is represented by a box in the initial process model.
- a process model representation is used to represent the processes.
- Embodiments of the present invention embrace a variety of representations and/or formats, including ETVX, SADT, Role/Flow, and other representations.
- a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure of FIG. 36 illustrates how to model and document a lean process in accordance with a representative embodiment of the present invention.
- the illustrated procedure documents the process modeling and documentation for the modeling stage for defining a process or sub-process in accordance with an embodiment of the present invention.
- the nine process elements are defined on one page in a process model or diagram (expert mode) for each process activity template.
- the nine process elements are mapped onto the process model diagram.
- the process modeling representation used is the one selected in the design stage. This is performed for each process activity template. If the process activity template was not used, the nine process elements may be defined on a single page (expert mode) using the process chunk identified in the process design stage.
- each step in the process model diagram is in expert mode, and that each expert mode step may include more sub-steps or detailed explanations for an intermediate mode.
- Information relating to guidance or lessons learned is included into the steps in the intermediate mode process table.
- a guidance label is used to document guidance and lessons learned, but is not required every step.
- a procedure is provided for developing a lean procedure in accordance with a representative embodiment of the present invention.
- a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure of FIG. 37 illustrates how to document the steps of the process modeling stage for defining procedures.
- FIG. 38 A representative form is illustrated in FIG. 38 as a Meeting Minutes Template.
- a form enables the collection of information.
- the form of FIG. 38 allows for the collection of information relating to who (meeting attendance), what (meeting title), when (meeting date/time), where (meeting location) and why (meeting purpose).
- the form of FIG. 38 allows for the collection of information relating to agenda items, action items, issues, and decisions/agreements.
- a representative checklist is illustrated in FIG. 39 .
- a checklist helps a user to not forget to perform any particular step or task. Additionally, the steps or tasks may be done in any order, which can allow for concurrency.
- FIG. 40 A representative order table is illustrated in FIG. 40 .
- An order table provides a particular sequence for which steps or tasks are to be taken or performed.
- procedure is chunked into logical groups with the chunks labeled. Procedures are needed when repeatability is needed for “how to” steps. In at least some embodiments, procedures are not needed for every activity (only the vital few activities that require repeatability for a given set of “how to” steps).
- a standard refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections.
- Standards make work products repeatable and identify a section number, a name and a description. While standards usually describe what goes into a work product, there can also be standards for policies, processes, and procedures.
- a standard provides an ability to provide uniformity to documentation. For example, a standard identifies particular sections and descriptions for such sections.
- a standard is provided on one page.
- the format for a standard can include a table or other format.
- embodiments of the present invention embrace standards that are in expert mode, intermediate mode and/or beginner mode.
- the illustrated procedure documents the steps for the process modeling stage for defining standards on one page (expert mode). Specifically, the title of the standard is identified using a descriptive name. The sections are listed through utilization of a table or by listing the sections using section numbers that become section numbers in the work products. A description is provided for each section, wherein the description is concise and includes a repeatable definition. Industry standards are also utilized. Standards may be combined together into a lean standard (i.e., a one page, expert mode standard).
- a policy refers to a process document based upon principles that guide and constrain an organization.
- a policy provides an ability to map out a principle that has been established or otherwise determined. For example, in the business world the senior management determines principles for a particular company, wherein the principles are how the company will be run.
- the policies are provided on one page.
- embodiments of the present invention embrace policies that are in expert mode, intermediate mode and/or beginner mode.
- the procedure of FIG. 42 documents representative steps of the process modeling stage for defining policies. Specifically, the policy is given a title using descriptive terms. The vital principles that the organization should follow are defined and chunked as needed. This can be done in a table or by listing the principles using numbers or bullets. Good sources for process principles come from industry standards and reference materials. Optionally, each principle may be labeled for summary purposes and ease of reading. An authorization/approval section may be added for the policies. Policies may have definitions, including operational definitions which are repeatable and measurable. Policies may be combined together into a policy document. Alternatively, the policy may be defined in the process guide along with the other process documentation.
- the process guide is a manner to package or otherwise provide documentation. It is a succinct output or deliverable having scalability.
- the procedure of FIG. 43 illustrates representative steps of the process modeling stage for defining a lean process guide. Specifically, the title of the process guide is determined using descriptive language.
- the process guide is similar to a user guide and is kept short and usable. It is the primary package used by a user/customer. The following is a checklist that is used to check the process guide:
- FIG. 44 a procedure is provided for developing a process guide standard in accordance with a representative embodiment of the present invention.
- the goal with the process guide is to keep it as short and usable as possible.
- the process guide standard of FIG. 43 includes the purpose, scope, audience, usage, definitions/references, process models, records, interfaces, metrics, forms and templates, training, miscellaneous information, and appendixes.
- FIGS. 10-34 provided a representative example relating to a representative decision process, wherein FIG. 10 illustrated a representative process work WAR template for the representative decision process, FIGS. 11-12 illustrated a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” of FIG. 10 , FIGS. 13-14 illustrated a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” of FIG. 10 , FIGS. 15-16 illustrated a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” of FIG. 10 , and wherein FIGS. 17-34 illustrated a representative decision process guide, FIGS. 18-24 illustrating chunked activities of the decision process in a representative ETMX format and FIGS. 25-30 illustrating chunked activities of the decision process in a swim lane format.
- FIGS. 45-74 provide another representative example that relates to a configuration management (“CM”) process, wherein FIGS. 45-46 illustrate a representative WAR template for the representative CM process, FIGS. 47-48 illustrate a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” of FIG. 45 , FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” of FIG. 45 , FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CS A” of FIG. 45 , FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” of FIG. 45 , and where FIGS. 55-74 illustrate a representative CM process guide.
- CM configuration management
- the illustrated WAR template identifies the work products that are used and produced by the CM process as being (i) a baseline, (ii) a configuration control board (“CCB”) meeting minutes, (iii) a change request (“CR”), (iv) a CM system, (v) a configuration audit report, (vi) a configuration identification report, (vii) a configuration item (“CI”), (viii) a change request/problem report (“CR/PR”) trend report, (ix) an organizational CM plan, (x) a problem report (“PR”), (xi) a project CM plan, and (xii) a project plan.
- work product refers to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”). As illustrated, each work product is assigned an identification code.
- the WAR Template of FIGS. 45-46 identifies the activities that are to be performed for the CM process.
- the term “activity” refers to a process building block and a process element that addresses the “what”.
- An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services.
- An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document).
- each chunk includes a maximum of 7 ⁇ 2 activities.
- a maximum chunking value that is less than or greater than 7 ⁇ 2.
- the CM process is identified as identification code 7.0.
- the particular activities are identified as identification codes 7.1-7.4.6.
- the activities have been chunked into four chunks, specifically “Perform CM Planning” (7.1), “Perform Configuration Control” (7.2), “Perform Configuration Status Accounting” (7.3), and “Perform CM Audits” (7.4).
- Each activity chunk includes a corresponding process activity template, as illustrated in FIGS. 47-54 .
- Each chunk is a sub-process.
- Those skilled in the art will appreciate that embodiments of the present invention may include sub-processes having their own sub-processes.
- the WAR Template of FIGS. 45-46 further includes the particular roles (see FIG. 46 ).
- the term “role” refers to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”).
- the illustrated roles are the Configuration Control Board (CCB), the Configuration Management (CM) Auditor, the Configuration Management (CM) Lead, the developers, the project manager (PM), the quality assurance (QA), and the requester.
- CBA Configuration Control Board
- CM Configuration Management
- CM Configuration Management
- PM project manager
- QA quality assurance
- FIGS. 47-48 a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” of FIGS. 45-46 is illustrated.
- the process activity template of FIGS. 47-48 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.1.
- FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” of FIGS. 45-46 .
- the process activity template of FIGS. 49-50 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.2.
- FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CSA” of FIGS. 45-46 .
- the process activity template of FIGS. 51-52 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.3.
- FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” of FIGS. 45-46 .
- the process activity template of FIGS. 53-54 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.4.
- FIGS. 55-74 illustrate a representative CM process guide, wherein FIGS. 57-64 illustrate chunked activities of the decision process in a swim lane format.
- the CM process guide enables a user to perform the CM process and includes corresponding procedures, standards and policies.
- the following CM process guide is provided to illustrate the particular aspects of the representative process guide.
- the process guide includes the purpose, the scope, audience, usage, acronyms, and references.
- a graphical representation of the CM process 120 is illustrated, which includes a phase for each chunked activity, namely 7.1 Perform CM Planning, 7.2 Perform Configuration Control, 7.3 Perform Configuration Status Accounting, and 7.4 Perform CM Audits. Additionally the dotted lines of the graphical representation of the CM process 120 illustrate concurrency.
- FIG. 57 an expert mode of activity 7.1 Perform CM Planning is provided in a swim lane format.
- FIG. 58 illustrates an intermediate mode of activity 7.1 Perform CM Planning.
- FIGS. 57-58 further include all of the activities that have been chunked. It is noted that in FIG. 57 , representation 130 is similar to representation 120 ( FIG. 56 ) and identifies to the user the location of activity 7.1 in the overall CM process.
- FIG. 59 an expert mode of activity 7.2 Perform Configuration Control is provided in a swim lane format.
- FIG. 60 illustrates an intermediate mode of activity 7.2 Perform Configuration Control.
- FIGS. 59-60 further include all of the activities that have been chunked. It is noted that in FIG. 59 , representation 140 is similar to representation 120 ( FIG. 56 ) and identifies to the user the location of activity 7.2 in the overall CM process.
- FIG. 61 an expert mode of activity 7.3 Perform Configuration Status Accounting is provided in a swim lane format.
- FIG. 62 illustrates an intermediate mode of activity 7.3 Perform Configuration Status Accounting.
- FIGS. 61-62 further include all of the activities that have been chunked. It is noted that in FIG. 61 , representation 150 is similar to representation 120 ( FIG. 56 ) and identifies to the user the location of activity 7.3 in the overall CM process.
- FIG. 63 an expert mode of activity 7.4 Perform CM Audit is provided in a swim lane format.
- FIG. 64 illustrates an intermediate mode of activity 7.4 Perform CM Audit.
- FIGS. 63-64 further include all of the activities that have been chunked. It is noted that in FIG. 63 , representation 160 is similar to representation 120 ( FIG. 56 ) and identifies to the user the location of activity 7.4 in the overall CM process.
- the process guide includes the general exit criteria for the CM process, the relevant records, interfaces, metrics, standards, training, and maintenance of the process.
- a representative CM policy is provided.
- policy refers to a process document based upon principles that guide and constrain an organization. It specifically identifies the CM purpose, the policy scope, the individual CM policies, and the authorization.
- CM plan standard refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures. A list of just sections or parts is not a standard, but is a template.
- CM report standards which identifies the required reports for the present embodiment.
- the reports include (i) a configuration identification report standard, (ii) a change request and problem report standard, (iii) a CCB meeting minutes standard, and (iv) a CM audit report standard.
- CM audit checklists are provided.
- the checklists include (i) a requirements baseline audit checklist, (ii) a code baseline audit checklist, and (iii) a product baseline audit checklist.
- FIG. 71 illustrates a representative establish CM system procedure.
- FIG. 72 illustrates a representative change control procedure.
- FIG. 73 illustrates a representative conduct CCB meeting procedure.
- FIG. 74 illustrates a representative release procedure.
- At least some embodiments of the present invention embrace performing at least portions of the methods and/or processes of the present invention through the use of a computer device, including processes, procedures, standards and/or policies. Moreover, embodiments of the present invention embrace electronic and/or hardcopy documentation. Furthermore, embodiments of the present invention scale up to complexity, provide the ability to chunk onto a single page, and/or include all nine process elements (i.e., inputs, outputs, activities, process context, entry criteria, exit criteria, purposes, process flow, and roles). Moreover, at least some embodiments include all nine process elements on a single page.
- embodiments of the present invention embrace providing documentation having succinct communication with scalability.
- embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
Abstract
The present invention relates to providing documentation having succinct communication with scalability. In particular, the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
Description
- This application is a continuation of U.S. patent application Ser. No. 11/409,522, filed Apr., 21, 2006.
- 1. Field of the Invention
- The present invention relates to providing documentation having succinct communication with scalability. In particular, the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- 2. Background and Related Art
- While a variety of techniques are currently used to document processes, a variety of challenges exist. For example, process documentations are typically too large and bulky, and as a result are difficult to use. Processes and procedures can violate documentation design and writing principles, and are not designed with customers and users in mind. Process documentation typically mixes different types of information into the same paragraphs as if they were all used the same way. Current techniques make it difficult for users to find information quickly, and can cause frustration and prevent procedures from being followed.
- Thus, while techniques are currently available to document processes, challenges still exist with such techniques. Accordingly, it would be an improvement in the art to augment or even replace current techniques with other techniques.
- The present invention relates to providing documentation having succinct communication with scalability. In particular, the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- In one embodiment, the present invention is implemented as a method for generating a process model representation for each of a plurality of activity chunks in a process such that each process model representation is arranged to be displayed on a single page. A template for a process is received. The template defines each work product that is used by the process, each activity performed by the process, and each role that performs an activity in the process. Each activity is associated with one of a plurality of activity chunks defined for the process. For each of the activity chunks, a process activity template is generated. For each process activity template, a process model representation is generated. Each process model representation is arranged to be displayed on a single page and comprises a graphical representation of the flow between the activities in the represented activity chunk.
- While the methods and processes of the present invention have proven to be particularly useful in the area of succinct and usable processes that have scalability, those skilled in the art will appreciate that the methods and processes can further be used in association with procedures, standards and policies.
- These and other features and advantages of the present invention will be set forth or will become more fully apparent in the description that follows and in the appended claims. The features and advantages may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Furthermore, the features and advantages of the invention may be learned by the practice of the invention or will be obvious from the description, as set forth hereinafter.
- In order that the manner in which the above recited and other features and advantages of the present invention are obtained, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. Understanding that the drawings depict only typical embodiments of the present invention and are not, therefore, to be considered as limiting the scope of the invention, the present invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
-
FIG. 1 illustrates a representative system that provides a suitable operating environment for use of the present invention; -
FIG. 2 illustrates a representative networked configuration; -
FIG. 3 illustrates a representative process definition process in accordance with an embodiment of the present invention; -
FIG. 4 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process planning stage; -
FIG. 5 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process requirements stage; -
FIG. 6 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process design stage; -
FIG. 7 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process modeling stage; -
FIG. 8 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process verification stage; -
FIG. 9 illustrates a representative process model corresponding to the process definition process ofFIG. 3 , wherein the illustrated process model is a process validation stage; -
FIG. 10 illustrates a representative process work product, activities and rules (“WAR”) template for a representative decision process; -
FIGS. 11-12 illustrate a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” ofFIG. 10 ; -
FIGS. 13-14 illustrate a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” ofFIG. 10 ; -
FIGS. 15-16 illustrate a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” ofFIG. 10 ; -
FIGS. 17-34 illustrate a representative decision process guide, whereinFIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX process model format andFIGS. 25-30 illustrate chunked activities of the decision process in a swim lane process model format; -
FIG. 35 illustrates a representative process documentation design procedure in accordance with a representative embodiment of the present invention; -
FIG. 36 illustrates a representative process modeling and documentation procedure in accordance with a representative embodiment of the present invention; -
FIG. 37 illustrates a representative procedure for developing a procedure in accordance with a representative embodiment of the present invention; -
FIG. 38 illustrates a representative form template; -
FIG. 39 illustrates a representative checklist template; -
FIG. 40 illustrates a representative ordered table template; -
FIG. 41 illustrates a representative procedure for developing a standard in accordance with a representative embodiment of the present invention; -
FIG. 42 illustrates a representative procedure for developing a policy in accordance with a representative embodiment of the present invention; -
FIG. 43 illustrates a representative procedure for developing a process guide in accordance with a representative embodiment of the present invention; -
FIG. 44 illustrates a representative process guide standard in accordance with a representative embodiment of the present invention; -
FIGS. 45-46 illustrate a representative process work product, activities and rules (“WAR”) template for a representative configuration management (“CM”) process; -
FIGS. 47-48 illustrate a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” ofFIG. 45 ; -
FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” ofFIG. 45 ; -
FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CSA” ofFIG. 45 ; -
FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” ofFIG. 45 ; and -
FIGS. 55-74 illustrate a representative CM process guide. - The present invention relates to providing documentation having succinct communication with scalability. In particular, the present invention relates to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- In the disclosure and in the claims the term “activity” shall refer to a process building block and a process element that addresses the “what”. An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services. An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document).
- In the disclosure and in the claims the phrase “activity performed by” shall refer to a relationship between an activity and a role, and is a role or roles performing or participating in an activity or activities.
- In the disclosure and in the claims the term “beginner mode” shall refer to a process documentation that is defined for a beginner user or audience. Beginners are individual users who are not familiar with a particular process.
- In the disclosure and in the claims the term “entry criteria” shall refer to a process element that addresses the “when”. Entry criteria define the conditions under which an activity can be started, and are preconditions about the state of a work product, role, and/or activity.
- In the disclosure and in the claims the term “exit criteria” shall refer to a process element that addresses the “when”. Exit criteria define the conditions under which an activity can be declared complete, and determine the next activity. The exit criteria are post conditions about the state of a work product, role, and/or an activity.
- In the disclosure and in the claims the term “expert mode” shall refer to process documentation that is defined for an expert audience or user. Experts are individuals or users who are intimately familiar with a particular process.
- In the disclosure and in the claims the term “input” shall refer a process element that addresses the “what”. The input represents a relationship between an activity and a work product. Inputs are results of one or more prior activities, and are used or consumed by the activity being defined.
- In the disclosure and in the claims the term “intermediate mode” shall refer to process documentation that is defined for an intermediate audience or user. Intermediates are individuals or users who are somewhat familiar with a particular process, but are not experts in that process.
- In the disclosure and in the claims the term “lean” shall refer to being concise/succinct and usable.
- In the disclosure and in the claims the term “output” shall refer to a process element that addresses the “what”. The output represents a relationship between an activity and a work product. Outputs are the results that are produced or used by the activity being described.
- In the disclosure and in the claims the term “policy” shall refer to a process document based upon principles that guide and constrain an organization.
- In the disclosure and in the claims the term “procedure” shall refer to a process document that is a set of activities that describe the “how to”. There are three types of procedures, namely (i) a checklist, (ii) a form, and (iii) an ordered table. A procedure provides step-by-step instructions or “how-to” information.
- In the disclosure and in the claims the term “process” shall refer to an activity that is modeled by answering who, what, when, where and why (the five “W's”). Moreover, a process is a set of parallel or sequential activities that use and transform inputs, add value, and produce outputs and results that are directed towards achieving a purpose and a set of objectives.
- In the disclosure and in the claims the term “process context” shall refer to answering “where”, and is usually represented by a block diagram or picture with the current process highlighted (e.g., “you are here diagram”). Process context is based on process identification along with sibling processes, as well as parent and children activities as appropriate, as well as any other contextual information (e.g., process owner). In at least some embodiments, if an activity must be performed in a specific location, that information is documented.
- In the disclosure and in the claims the term “process building block” shall refer to one or more of the three process building blocks, namely activities, work products, and roles (collectively “WAR”).
- In the disclosure and in the claims the term “process documentation” shall refer to polices, standards, processes and procedures.
- In the disclosure and in the claims the term “process element” shall refer to a component of a process that answers who, what, when, where or why (the five “W's”). The nine process elements are purpose (why), activities (what), inputs (what), outputs (what), entry criteria (when), exit criteria (when), roles (who), process context (where), and process flow (where).
- In the disclosure and in the claims the term “process flow” shall refer to answering the “where”. Process flow is a conditional relationship between activities, work products, and roles. Flow defines the control and ordering of activities, timing of activities, and determines “where” inputs and outputs flow (e.g., the next process). Flow is represented in process models, block diagrams, or pictures, and controlled by entry and exit criteria. Control flow focuses on the entry and exit criteria control the states of work products, roles, and activities, and also determine the next process. Data flow relates to inputs and outputs (the data), and the flow of data among processes and is controlled by entry and exit criteria. Timing flow relates to when activities happen (e.g., daily, monthly, annually, etc.) and is also controlled by entry and exit criteria.
- In the disclosure and in the claims the term “process model” shall refer to an abstraction of a process typically characterized by formal notations for representing roles, activities, and/or work products, and the relationships (e.g., events, transformations) among them. Types of process models include: descriptive models (as-is), which describe what is actually done or practiced; prescriptive models (to-be), which prescribes what to do (e.g., by new policies, standards, process guidelines, etc); and mixed models (both as-is and to-be), which are a combination of prescriptive and descriptive processes. A large number of process models are a mixture of prescriptive and descriptive processes.
- In the disclosure and in the claims the term “purpose” shall refer to a process element that describes the rationale for an activity or process (i.e., the “why”).
- In the disclosure and in the claims the term “role” shall refer to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”).
- In the disclosure and in the claims the term “sub-process” shall refer to a process that is modeled by answering who, what, when, where and why (the five “W's”). One or more sub-processes make up a process. Sub-processes are also referred to as “chunks”, and can be made up of one or more sub-processes.
- In the disclosure and in the claims the term “template” shall refer to a process document that comprises sections or parts. An “annotated template” is a standard (see also the definition of standard).
- In the disclosure and in the claims the term “standard” shall refer to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures. A list of just sections or parts is not a standard, but is a template. An “annotated template” is a standard because it also comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections.
- In the disclosure and in the claims the term “work product” shall refer to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”).
- The following disclosure of the present invention is grouped into two subheadings, namely “Exemplary Operating Environment” and “Providing Documentation Having Succinct Communication with Scalability.” The utilization of the subheadings is for convenience of the reader only and is not to be construed as limiting in any sense.
- While some embodiments of the present invention embrace the utilization of no computer device, other embodiments embrace the utilization of one or more computer devices in providing documentation (as a hardcopy and/or as an electronic copy) having succinct communication with scalability. Accordingly,
FIG. 1 and the corresponding discussion are intended to provide a general description of a suitable operating environment in which some embodiments of the present invention may be implemented. One skilled in the art will appreciate that the invention may be practiced by one or more computing devices and in a variety of system configurations, including in a networked configuration. - Embodiments of the present invention embrace one or more computer readable media, wherein each medium may be configured to include or includes thereon data or computer executable instructions for manipulating data. The computer executable instructions include data structures, objects, programs, routines, or other program modules that may be accessed by a processing system, such as one associated with a general-purpose computer capable of performing various different functions or one associated with a special-purpose computer capable of performing a limited number of functions. Computer executable instructions cause the processing system to perform a particular function or group of functions and are examples of program code means for implementing steps for methods disclosed herein. Furthermore, a particular sequence of the executable instructions provides an example of corresponding acts that may be used to implement such steps. Examples of computer readable media include random-access memory (“RAM”), read-only memory (“ROM”), programmable read-only memory (“PROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), compact disk read-only memory (“CD-ROM”), or any other device or component (e.g., DVD) that is capable of providing data or executable instructions that may be accessed by a processing system.
- With reference to
FIG. 1 , a representative system for implementing the invention includescomputer device 10, which may be a general-purpose or special-purpose computer. For example,computer device 10 may be a personal computer, a notebook computer, a personal digital assistant (“PDA”) or other hand-held device, a workstation, a minicomputer, a mainframe, a supercomputer, a multi-processor system, a network computer, a processor-based consumer electronic device, or the like. -
Computer device 10 includessystem bus 12, which may be configured to connect various components thereof and enables data to be exchanged between two or more components.System bus 12 may include one of a variety of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus that uses any of a variety of bus architectures. Typical components connected bysystem bus 12 includeprocessing system 14 andmemory 16. Other components may include one or more mass storage device interfaces 18, input interfaces 20, output interfaces 22, and/or network interfaces 24, each of which will be discussed below. -
Processing system 14 includes one or more processors, such as a central processor and optionally one or more other processors designed to perform a particular function or task. It is typically processingsystem 14 that executes the instructions provided on computer readable media, such as onmemory 16, a magnetic hard disk, a removable magnetic disk, a magnetic cassette, an optical disk, or from a communication connection, which may also be viewed as a computer readable medium. -
Memory 16 includes one or more computer readable media that may be configured to include or includes thereon data or instructions for manipulating data, and may be accessed by processingsystem 14 throughsystem bus 12.Memory 16 may include, for example,ROM 28, used to permanently store information, and/orRAM 30, used to temporarily store information.ROM 28 may include a basic input/output system (“BIOS”) having one or more routines that are used to establish communication, such as during start-up ofcomputer device 10.RAM 30 may include one or more program modules, such as one or more operating systems, application programs, and/or program data. - One or more mass storage device interfaces 18 may be used to connect one or more
mass storage devices 26 tosystem bus 12. Themass storage devices 26 may be incorporated into or may be peripheral tocomputer device 10 and allowcomputer device 10 to retain large amounts of data. Optionally, one or more of themass storage devices 26 may be removable fromcomputer device 10. Examples of mass storage devices include hard disk drives, magnetic disk drives, tape drives and optical disk drives. Amass storage device 26 may read from and/or write to a magnetic hard disk, a removable magnetic disk, a magnetic cassette, an optical disk, or another computer readable medium.Mass storage devices 26 and their corresponding computer readable media provide nonvolatile storage of data and/or executable instructions that may include one or more program modules such as an operating system, one or more application programs, other program modules, or program data. Such executable instructions are examples of program code means for implementing steps for methods disclosed herein. - One or more input interfaces 20 may be employed to enable a user to enter data and/or instructions to
computer device 10 through one or morecorresponding input devices 32. Examples of such input devices include a keyboard and alternate input devices, such as a mouse, trackball, light pen, stylus, or other pointing device, a microphone, a joystick, a game pad, a satellite dish, a scanner, a camcorder, a digital camera, and the like. Similarly, examples of input interfaces 20 that may be used to connect theinput devices 32 to thesystem bus 12 include a serial port, a parallel port, a game port, a universal serial bus (“USB”), a firewire (IEEE 1394), or another interface. - One or
more output interfaces 22 may be employed to connect one or morecorresponding output devices 34 tosystem bus 12. Examples of output devices include a monitor or display screen, a speaker, a printer, and the like. Aparticular output device 34 may be integrated with or peripheral tocomputer device 10. Examples of output interfaces include a video adapter, an audio adapter, a parallel port, and the like. - One or more network interfaces 24 enable
computer device 10 to exchange information with one or more other local or remote computer devices, illustrated ascomputer devices 36, via anetwork 38 that may include hardwired and/or wireless links. Examples of network interfaces include a network adapter for connection to a local area network (“LAN”) or a modem, wireless link, or other adapter for connection to a wide area network (“WAN”), such as the Internet. Thenetwork interface 24 may be incorporated with or peripheral tocomputer device 10. In a networked system, accessible program modules or portions thereof may be stored in a remote memory storage device. Furthermore, in a networkedsystem computer device 10 may participate in a distributed computing environment, where functions or tasks are performed by a plurality of networked computer devices. - While those skilled in the art will appreciate that the invention may be practiced in a variety of environments, including computing environments having any of a variety of computer system configurations, including networked environments,
FIG. 2 represents an embodiment of the present invention in a networked environment that includes a variety of clients connected to a server system via a network. WhileFIG. 2 illustrates an embodiment that includes multiple clients connected to the network, alternative embodiments include one client connected to a network, one server connected to a network, or a multitude of clients throughout the world connected to a network, where the network is a wide area network, such as the Internet. Moreover, embodiments of the present invention embrace non-networked environments, such as where at least a portion of defining and documenting processes, procedures, standards and policies is generated utilizing a single computer device. At least some embodiments of the present invention further embrace defining and documenting processes, procedures, standards and policies that are succinct, usable and scalable, wherein at least a portion does not require a computer device. - In
FIG. 2 , a representative networked configuration is provided for defining and documenting processes, procedures, standards and policies.Server system 40 represents a system configuration that includes one or more servers.Server system 40 includes anetwork interface 42, one ormore servers 44, and astorage device 46. A plurality of clients, illustrated asclients server system 40 vianetwork 70, which may include a wireless network, a local area network, and/or a wide area network. Network interfaces 52 and 62 are communication mechanisms that respectfully allowclients server system 40 vianetwork 70. For example, network interfaces 52 and 62 may be a web browser or other network interface. A browser allows for a uniform resource locator (“URL”) or an electronic link to be used to access a web page sponsored by aserver 44. Therefore,clients server system 40. - As provided above,
server system 40 includesnetwork interface 42,servers 44, andstorage device 46.Network interface 42 is a communication mechanism that allowsserver system 40 to communicate with one or more clients vianetwork 70.Servers 44 include one or more servers for processing and/or preserving information.Storage device 46 includes one or more storage devices for preserving information, such as a particular record of data.Storage device 46 may be internal or external toservers 44. - In the illustrated embodiment of
FIG. 2 , the networked system is used to define and document processes, procedures, standards and/or policies. In particular, processes and procedures are defined and communicated in such a way that is more succinct and usable to document, measure and improve business, as will be further discussed below. Those skilled in the art will appreciate that the networked system ofFIG. 2 is a representative system in accordance with the present invention. Accordingly, embodiments of the present invention embrace other computer system configurations for performing methods disclosed herein. - Providing Documentation Having Succinct Communication with Scalability
- As provided herein, embodiments of the present invention relate to providing documentation having succinct communication with scalability. In particular, embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- Organizations have the need to define their processes and procedures in order to document, measure, and improve how they do business. A common example of this process documentation relates to organizations that are ISO certified (e.g., a Quality Manual). A lean process is a business method or technique that allows processes and procedures to be defined in, for example, 25-50% of their usual size. A lean process helps organizations define processes and procedures that are shorter and more usable.
- A lean process addresses the common problems with process documentation and is based on such principles as process documentation types (i.e., policies, standards, processes, and procedures), process documentation usage modes (e.g., Expert Mode), lean policies (one page policies per process area), lean standards (one page standards), lean processes (e.g., addressing the 5 W's of who, what, when, where and why in a diagram on one page per process or sub-process), lean procedures (e.g., addresses the “how” in a checklist, form, or ordered table on one page), and lean documentation (one page) that can be used on websites.
- With reference now to
FIG. 3 , a representative block diagram is illustrated to provide a representative embodiment for generating a lean process. InFIG. 3 , there exists an iterative planning phase, an iterative modeling phase, and an iterative verification and validation (“V&V”) phase. The iterative planning phase includes a process planning stage and a process requirements stage. The process planning stage comprises the following sub-processes: (i) product plan, which comprises the purpose, scope, audience, and usage; and (ii) work plan, which comprises the charter, schedule, and resources. The process requirements stage comprises identifying the following four types of requirements: (i) organizational requirements; (ii) industry model requirements (e.g., ISO, Baldrige, CMMI, etc.); (iii) representation requirements; and/or (iv) other requirements. - The iterative modeling phase comprises a process design stage and a process modeling stage. The process design stage comprises (i) documenting design decisions (e.g., selecting a process model representation), (ii) documenting the initial process model, (iii) identifying activities, work products, and roles for each process and sub-process, (iv) grouping the activities into “chunks” or sub-processes with no more than ten activities (i.e., the seven plus or minus two rule), and optionally (v) completing the process activity templates for each process and sub-process. The process implementation stage comprises (i) modeling the process using the selected process modeling approach; (ii) modeling who, what, when, where and why (the five W's) on a single page for each process or sub-process (e.g., for expert mode); (iii) iterating for each level of the process model (can iterate the process definition phase or the entire lean process); (iv) developing process description tables (e.g., for intermediate mode), wherein the goal is one page for each process model; (v) developing the procedure(s) on a single page in expert mode; (vi) developing the policies on one page in expert mode; (vii) developing the standards on a single page in expert mode; and (viii) developing the process guide to put all of the pieces together.
- The iterative verification and validation phase includes a process verification stage and a process validation stage. The process verification stage comprises (i) verifying the process against the planning, requirements, and design; (ii) verifying the correctness, consistency, and completeness (the three Cs); and (iii) removing defects from the process. The Process Validation Stage comprises (i) validating the process with the process experts and users (e.g., using a walkthrough); and (ii) Pilot testing the process (this can also be a separate process).
- One way to address common problems with process documentation is to recognize that not all documentation is used the same way. Process documentation refers to policies, standards, processes and procedures. By way of example, policies are typically used by senior management to set direction in an organization, state principles that organizations should follow, and provide requirements for processes, procedures, and training. Standards, on the other hand, typically specify the parts of a document, provide a description of what is to be included, make the content of documents repeatable, and provide requirements for processes, procedures, and training. Processes refer to what happens over time to produce a desired result, add value, answer the five W's of who, what, where, when, and why, and are supported by procedures, training, and tools. Procedures provide step-by-step information that implements at least part of a process. Training is used by beginners and taught by instructors (e.g., experts), and provides the necessary knowledge and skills Training can be voluminous.
- Processes and procedures have different levels of users. Some users have never used the process (e.g., beginner users). Some users have used the process a few times, but need guidance and lessons learned (e.g., intermediate users). Some users have used the process many times and may even be responsible for running the process (e.g., experts). The following describes the three levels of documentation: expert, intermediate, and beginner.
- “Expert Mode” documentation is short and concise. When a pilot flies an airplane, he or she does not pull out training manuals. Instead, pilots use expert checklists for take off and landing. Expert mode documentation is made for experts and it does not contain any training material. An advantage of expert mode documentation is that it is short, however not everybody is an expert. Thus, for example, not everyone can read a checklist for a rocket scientist (i.e., sometimes you really need to be an rocket scientist). Experts can utilize documentation because people can forget things. This is why checklists are so powerful. Experts can also leave your organization, taking precious organizational knowledge with them. This is why expert knowledge should be documented.
- “Intermediate Mode” documentation uses the expert mode documentation, but builds and adds to it by providing guidance and lessons learned. For example, guidance is very useful to people that don't have to follow a process or procedure very often. Even experts forget guidance and lessons learned for an annual process or an infrequently used process. Having guidance available to those who want it is very useful.
- Typically guidance and lessons learned are not “auditable”. Process phases and procedure steps are required and auditable, but the supporting guidance and lessons learned are there for support only. One best practice is to distinguish between required steps and optional guidance. “Beginner Mode” documentation uses the intermediate mode documentation, but adds training to it. Beginners should feel free to use the training manuals until they become familiar with the process. Beginners should also be mentored as appropriate. Processes can vary from simple to complex. Complex processes should have formal training and be followed up by mentoring.
- A process should address who, what, when, where and why, answer key process questions, include both pictures and words, be short, usable, chunked, labeled, and well written. A lean process addresses the five W's (who, what, when, where and why) in a diagram or process model on a single page (Expert Mode), is chunked (e.g., having 10 or less activities), and fits on one page in a process description table (Intermediate Mode).
- The following provides a representative relationship between the five W's, key process questions to be answered by a process, and process elements identified by a process.
-
5 W's & How Key Process Question Process Element Why? Why is the process performed? 1. Purpose Who? Who performs the process? 2. Role(s) When? When does the process begin? 3. Entry Criteria When does the process end? 4. Exit Criteria Where? Where am I in the process? 5. Process Context (Optional: Physical Location) 6. Process Flow What? What work products are used? 7. Inputs What work products are produced? 8. Outputs What happens to produce results? 9. Activities How? How is the process implemented? Procedures - A lean procedure includes “how to, step-by-step” information that may come in three forms: checklists, forms, and/or ordered tables, and is a single page long. Checklists are very powerful, repeatable representations of activities that need to be completed in order to declare a something completed. What makes checklists so powerful is that it usually doesn't matter what order the checklist is completed. This is why checklists are very useful for concurrent activities (e.g., versus flowcharts which are very poor at representing concurrency). Good checklists are kept to 1 page long.
- Forms, along with instructions for completing the forms, are repeatable mechanisms for supporting processes. Forms are powerful mechanisms for collecting data in a repeatable way. If possible, keep forms to one page long (Form instructions may be on the back of a page (e.g., hardcopy), or by clicking for more information (e.g., online)).
- One effective way to represent a procedure is using an ordered procedure table. Ordered procedure tables are very useful when sequence or order matters. For example, if a person needs to track his or her time, starting to track time should not be the last step. The following is an example of an ordered procedure table:
-
Step Action 1 Begin to track time (e.g., write down the start time). 2 Look for defects in the selected work product by using the appropriate data driven checklist. 3 Log the defects of the Defect Form. Continue logging defects until the work product is completely inspected using the checklist. 4 End tracking time (e.g., write down the end time). Calculate the total time spent looking for and logging defects, and record the total time on the Defect Form. - Process modeling processes in accordance with embodiments of the present invention can generate processes that are clear, concise, precise, model-based, and repeatable.
FIG. 3 provides a representative process definition process. The following provides a discussion relating to each of the process stages. - With reference now to
FIG. 4 , a representative embodiment is provided relating to the process planning stage ofFIG. 3 . The purpose of the process planning stage is to ensure process satisfies the customer's needs, to establish criteria to verify and validate process, and to obtain sponsorship and plan resources. - Benefits of process planning are that (i) the customers/users of the process are identified, (ii) the scope and boundaries of the process are defined, (iii) how the customers/users will use the process is understood, (iv) there is buy-in and consensus on the process, (v) the process assumptions are documented and can be communicated to others, (vi) The process modeling team understands what process they are developing, (vii) the resources are planned so the lean process has a better chance to be on schedule and on budget.
- Measurable objectives for process planning includes that (i) process purpose, scope, customers, and usage are documented and understood, (ii) there is consensus on purpose, scope, customers, and usage for the process, (iii) the purpose, scope, customers, and usage assumptions are used to guide process development, and (iv) there is a process plan or charter that documents i-iii, and documents the necessary resources (i.e., time and money).
- With reference now to
FIG. 5 , a representative embodiment is provided relating to the process requirement stage ofFIG. 3 . The purpose of the process requirements stage is to identify and document process requirements (e.g., SEI CMMI, ISO, organizational, etc.) - The benefits of process requirements are that (i) documenting process requirements helps ensure that they are implemented and (ii) process requirements (e.g., ISO. CMMI, other industry process standards) can also be documented and met.
- Measurable objectives of process requirements include (i) Organizational requirements, (ii) industry process requirements, (iii) process representation requirements, and (iv) other process requirements are documented and reviewed.
- With reference now to
FIG. 6 , a representative embodiment is provided relating to the process design stage ofFIG. 3 . The purpose of the process design stage is to document the process design and design decisions. Through process design, one may acquire the necessary process knowledge, answer the “how to” design questions (e.g., process representation, process tools, etc), document process design and key decisions, use initial model as a “frame of reference” for any process interviews (e.g., descriptive models), and translate organizational process documentation, interview data, leading-edge process documentation, etc., into the process templates and update initial process model. - Benefits of process design include that it (i) increases understanding of the process (both prescriptive and descriptive), (ii) documents the design (e.g., process templates), critical design decisions, and why they were made, (iii) establishes a common “frame of reference” for communication, (iv) helps identify organizations, process experts, and users of the process, and (v) identify defects, missing information, or inconsistent information.
- Measurable objectives of the process design stage include that (i) all relevant process documentation has been identified and reviewed, (ii) that the process design and critical design decisions have been documented (e.g., process templates), (iii) that the process templates have been completed, (iv) that the initial process model has been updated (e.g., 3-10 activities, inputs, outputs, roles, etc., have been identified), and (v) that the initial process model defines the scope and perspective of the process.
- In at least some embodiments, a successful process design includes listing all the process building blocks of work products, activities, and roles (i.e., Process WAR templates). For a given process, these WAR process templates are then “chunked” (i.e., 7 plus or minus 2). Activities are the most complex building block on the Process WAR Template, and are chunked into sub-processes. Reference is made to
FIG. 10 , which illustrates a representative Process War Template for Configuration Management (CM). Please note the activity “chunks” (7.1, 7.2, 7.3, 7.4). Each chunk is a sub-process of the CM Process example. - With reference now to
FIG. 7 , a representative embodiment is provided relating to the process modeling stage ofFIG. 3 . The purpose of the process modeling stage is to build the model using the process templates. Through process modeling, one can translate the data from the design (i.e., process templates) into a more useful representation, and assist in process engineering, data analysis, measurement, planning, control, improvement, process simulation, etc. - Benefits of process modeling include that (i) modeling leads to a detailed understanding of the process, and the many process relationships, (ii) models improve communication of the process to others, (iii) models can help identify missing requirements, design, inputs, outputs, etc., and (iv) models help identify defects in the process itself, and reduce defects when the processes used.
- Measurable objectives of process modeling include that (i) all data from the process templates are captured in the process model, (ii) the model accurately represents the process (i.e., the 5 W's) on one page in expert mode, and (iii) the model satisfies the process plan, the requirements, and the design.
- Once the expert mode process models are completed, the intermediate mode process tables can be developed. For each step in the process model (i.e., activity), more detail is given (e.g., guidance, lessons learned, etc.). Policies, standards, and procedures also should be written to be 1 page (can be written either expert or intermediate mode).
- With reference now to
FIG. 8 , a representative embodiment is provided relating to the process verification stage ofFIG. 3 . The purpose of the process verification stage is to verify that the process meets the plan, requirements, design, and the process is free from defects. Through process verification, one can ensure the process plan, requirements, and design are satisfied in the model and the process guide, and eliminate defects. - Benefits of process verification are that (i) the process meets the process planning, requirements, and design, (ii) verifying the process eliminates defects (mismatching inputs and outputs, inconsistencies, etc), (iii) verification reduces rework in subsequent iterations of building the process model (if using a top-down approach), and (iv) verification helps the process to be the three C's (correct, consistent, and complete).
- Measurable objectives of process verification includes that it is able to verify that the process (i.e., model and guide) (i) meets the process plan, requirements, and design, (ii) accurately represents the process templates, and (iii) has been inspected/reviewed to remove defects.
- One approach to successfully verifying a process model is to recognize that there are 6 relationships among the 3 process building blocks of work products, activities, and roles (i.e., N*(N−1)). One verification objective is to verify these 6 relationships and ensure that they are correct.
- With reference now to
FIG. 9 , a representative embodiment is provided relating to the process validation stage ofFIG. 3 . The purpose of the process validation stage is to validate that the process meets the customers/users needs. Through process validation, one is able to ensure that the customers and users needs are met, and ensure that the customers and users agree that the process planning, requirements, and design are met. - Benefits of process validation include that (i) process experts reach agreement and consensus on the process, (ii) you know that the process successfully meets the customer(s) and user(s) needs, (iii) you know when you are done, and (iv) it reduces rework in subsequent iterations—adds quality.
- Measurable objectives include that (i) customers and users reach consensus that the process meets their needs, (ii) customers and users reach consensus that the process meets the process plan, requirements, and design, and (iii) the process model effectively communicates the process it represents.
- A best practice to validate process models is to perform a walkthrough of the process models with the customers and users. The customers/users provide feedback on whether or not the process model meets their needs. They raise process issues and make suggestions for improvement.
- As provided herein, embodiments of the present invention embrace providing documentation having succinct communication with scalability. In particular, embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- The following provides a representative example for defining and documenting a succinct and usable decision process that is scalable to the complexity of the process and to abilities of an individual user, wherein
FIG. 10 illustrates a representative process work product, activities and roles (“WAR”) template for the representative decision process. The WAR template is utilized in the process design stage, which enables the documentation and process design and design decisions, as referenced and discussed above in relation toFIGS. 3 and 6 . - A WAR template focuses on a high level design prior to expanding out into specific details, which are eventually chunked and used to provide the succinct, usable and scalable documentation. In other words, a WAR template can be used as a basic building block as it defines the work products, activities and roles of the process.
- With reference to
FIG. 10 , the illustrated WAR template identifies the work products that are used and produced by the decision process as being (i) a decision package, (ii) a decision matrix procedure, (iii) a decision presentation, (iv) a decision state, and (v) meeting minutes. - As provided herein, the term “work product” refers to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”). As illustrated, each work product is assigned an identification code. In the representative embodiment, the decision package includes the decision matrix procedure and decision presentation.
- The decision matrix procedure includes document information, such as the document version information (e.g., program name and identification, document title, document version number and/or date, program manager, name of preparer, preparation date, name of reviewer, review date, and/or other relevant information) and the document version history (e.g., identifying the version number, version date, name of the preparer, name of reviewer, description, and/or other information) that gather and organize information. The decision matrix procedure further includes a decision form that enables the gathering of information, such as relating to the decision team, decision makers, search results (e.g., historical data, decisions, lessons learned, etc.), alternative evaluation methods (e.g., simulation), decisions (e.g., recommendations), decision rationale, decision risks, decision benefits, and the like. The decision matrix procedure further includes a Decision Analysis Resolution (“DAR”) procedure. The DAR procedure identifies a particular sequence of actions that are to be performed. In the representative embodiment, the DAR procedure includes the following sequence of actions (ordered table):
-
- 1. Perform a literature search to consider applicable historical data, historical decisions, previous dissent, lessons learned, etc.
- 2. Document the decision criteria in the DAR Matrix.
- 3. Rank the decision criteria by using the weights (e.g., use team consensus for weights)
- 4. Complete the decision options in the DAR Matrix.
- 5. If there are other evaluation methods besides the DAR Matrix, document them in the DAR Form.
- 6. Complete DAR Matrix Form by filling in scores (e.g., select a number on a scale 1-5 using team consensus).
- 7. Use the DAR Matrix weighted total scores to help make a recommendation for a decision.
- 8. Complete the DAR Form and DAR Advantages/Disadvantages.
- 9. Develop/Update the Decision Presentation following the Decision Presentation Standard.
- 10. Continue to follow the DAR Process.
Completing a DAR Workbook is iterative in nature. Accordingly, in some embodiments versions are used to keep track of iterations.
- A decision matrix procedure further includes a decision matrix (A representative decision matrix is illustrated as
FIG. 34 , and will be discussed below.) and an advantage/disadvantage form that gathers information relating to the pros and cons of the process. By way of example, particular options are identified in a form that identifies and gathers information relating to advantages and/or disadvantages of each option. - A decision presentation includes, for example, an outline of the presentation and then provides specifics relating to the (i) introduction, (ii) decision options, (iii) decision matrix form, (iv) DAR information, and (v) recommendations.
- The decision states are: (i) A—more information needed, (ii) B—no decision needed, and (iii) C—final decision. Decision state A is new information (e.g., a new option, criteria, criteria rank, or evaluation method) that is required or becomes available and the decision analysis and evaluation is to be repeated. Decision state B is determined by the decision maker(s) that a decision is no longer needed or necessary. This state exits the decision process. Decision state C is the decision of the decision maker(s) with consensus. The decision is final (unless new information becomes available later where the need for a new decision is be determined).
- The meeting minutes is, for example, a form that gathers and identifies information such as the meeting agenda (e.g., attendance, meeting title, date/time, location, purpose—respectively, who, what, when, where, and why). Tables may be provided to gather and/or document agenda item descriptions, action item descriptions, issue descriptions, and decision/agreement descriptions.
- As provided herein, the WAR Template of
FIG. 10 identifies the activities that are to be performed. The term “activity” refers to a process building block and a process element that addresses the “what”. An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services. An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document). - As will be shown, the activities are identified, chunked and a process activity template is created for each chunk. In the present embodiment, each chunk includes a maximum of 7±2 activities. However, those skilled in the art will appreciate that embodiments of the present invention embrace chunking that includes more or less activities.
- In the illustrated embodiment, the particular decision process is identified as identification code 6.0. The particular activities are identified as identification codes 6.1-6.3.5. The activities have been chunked into three chunks, specifically “Prepare for Decision” (6.1), “Conduct Decision Meeting” (6.2), and “Perform Decision Follow-Up” (6.3). Each activity chunk includes a corresponding process activity template, as illustrated in
FIGS. 11-16 . Each chunk is a sub-process. Those skilled in the art will appreciate that embodiments of the present invention may include sub-processes having their own sub-processes. - As illustrated, the WAR Template of
FIG. 10 further includes the particular roles. The term “role” refers to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”). Specifically, the illustrated roles are the decision makers, decision team, decision team representative, management and recorder. - With reference now to
FIGS. 11-12 a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” ofFIG. 10 is illustrated. The process activity template ofFIGS. 11-12 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.1. -
FIGS. 13-14 illustrate a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” ofFIG. 10 . The process activity template ofFIGS. 13-14 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.2. -
FIGS. 15-16 illustrate a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” ofFIG. 10 . The process activity template ofFIGS. 15-16 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 6.3. -
FIGS. 17-34 illustrate a representative decision process guide for the present decision process, whereinFIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX format andFIGS. 25-30 illustrate chunked activities of the decision process in a swim lane format. The decision process guide enables a user to perform a particular process and includes corresponding procedures, standards and policies. While examples of manners for obtaining the process guide will be provided below, the following process guide is provided to illustrate the particular aspects of a representative process guide. - In
FIG. 17 , the process guide includes the purpose, the scope and decision policy, the audience, usage, and particular definitions, acronyms and references. InFIG. 18 , a graphical representation of thedecision process 80 is illustrated, which includes a phase for each chunked activity, namely 6.1 Prepare for Decision, 6.2 Conduct Decision Meeting, and Perform Decision Follow-up. Additionally the particular arrows of the graphical representation of thedecision process 80 illustrate the various outputs, namely more information needed (A), no decision needed (B), and final decision (C). - With reference to
FIG. 19 , an expert mode of activity 6.1 Prepare for Decision is provided in an ETMX process model format.FIG. 20 illustrates an intermediate mode of activity 6.1 Prepare for Decision.FIGS. 19-20 further include all of the activities that have been chunked. It is noted that inFIG. 19 ,representation 90 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.1 in the overall decision process. - With reference to
FIG. 21 , an expert mode of activity 6.2 Conduct Decision Meeting is provided in an ETMX process model format.FIG. 22 illustrates an intermediate mode of activity 6.2 Conduct Decision Meeting.FIGS. 21-22 further include all of the activities that have been chunked. It is noted that inFIG. 21 ,representation 100 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.2 in the overall decision process. - With reference to
FIG. 23 , an expert mode of activity 6.3 Perform Decision Follow-Up is provided in an ETMX process model format.FIG. 24 illustrates an intermediate mode of activity 6.3 Perform Decision Follow-Up.FIGS. 23-24 further include all of the activities that have been chunked. It is noted that inFIG. 23 ,representation 110 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.3 in the overall decision process. - As provided above,
FIGS. 18-24 illustrate chunked activities of the decision process in a representative ETMX process model format. Embodiments of the present invention embrace documenting in a variety of formats or manners to communicate in a succinct and understandable manner that is usable by a particular user and is scalable to the complexity of the process and to abilities of the individual user. Thus, for example,FIGS. 25-30 illustrate same chunked activities of the decision process as are illustrated inFIGS. 18-24 , howeverFIGS. 25-30 illustrate the chunked activities of the decision process in a swim lane format. - Thus, with reference to
FIG. 25 , an expert mode of activity 6.1 Prepare for Decision is provided in a swim lane process model format. Similar toFIG. 20 ,FIG. 26 illustrates an intermediate mode of activity 6.1 Prepare for Decision.FIGS. 25-26 further include all of the activities that have been chunked. It is noted that inFIG. 25 ,representation 90 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.1 in the overall decision process. - With reference to
FIG. 27 , an expert mode of activity 6.2 Conduct Decision Meeting is provided in a swim lane process model format. Similar toFIG. 22 ,FIG. 28 illustrates an intermediate mode of activity 6.2 Conduct Decision Meeting.FIGS. 27-28 further include all of the activities that have been chunked. It is noted that inFIG. 27 ,representation 100 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.2 in the overall decision process. - With reference to
FIG. 29 , an expert mode of activity 6.3 Perform Decision Follow-Up is provided in a swim lane process model format. Similar toFIG. 24 ,FIG. 30 illustrates an intermediate mode of activity 6.3 Perform Decision Follow-Up.FIGS. 29-30 further include all of the activities that have been chunked. It is noted that inFIG. 29 ,representation 110 is similar to representation 80 (FIG. 18 ) and identifies to the user the location of activity 6.3 in the overall decision process. - In
FIG. 31 , the process guide includes the relevant records, interfaces, metrics, forms and templates, training, and emergency decisions. InFIG. 32 , a representative decision presentation standard is provided. The term “standard” refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures. A list of just sections or parts is not a standard, but is a template. InFIG. 33 , the representative decision matrix procedure (discussed above) is illustrated. - In
FIG. 34 , the representative decision matrix (discussed above) is illustrated. The decision matrix identifies the various criteria (e.g., mission objectives, return on investment, cost, schedule, measure of potential impact, risk, safety, supportability, etc.) considered and the weight assigned to the criteria. It further includes a ranking scale, various available options that are being considered that are ranked by criteria, and the sums of each. - In at least some embodiments of the present invention, at least portions of the methods and/or processes of the present invention are performed by a computer device. For example, information from process activity templates may be used to document activities or processes that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- Embodiments of the present invention embrace a variety of manners that enable documentation having succinct communication with scalability. With reference now to
FIG. 35 , a lean process documentation design procedure in accordance with a representative embodiment of the present invention is provided. As provided herein, a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure ofFIG. 35 illustrates how to design lean process documentation in accordance with a representative embodiment of the present invention. In other words, the illustrated procedure documents the design phase for defining a process or sub-process in accordance with an embodiment of the present invention. - Specifically, as illustrated in
FIG. 35 , a process WAR template is utilized for the scope of the process. The work products, activities and roles are identified. - If any list in the WAR template has more than a particular maximum number of items, wherein the maximum number can be any established number, then the list is selectively chunked. Roles, work products and/or activities may be identified as needing to be chunked. Duplicates are consolidated. In chunking activities, some embodiments look for process chunks, such as planning, control and improvement. If a meeting or event is to occur, chunking may be associated with being prior to, during, or after the meeting or event. In at least some embodiments of the present invention, chunks are named descriptively.
- The initial process model is updated to match the chunked activities. A block diagram may be used, wherein one box is provided for each chunked activity. Such activities may be sequential or concurrent.
- A process activity template is completed for each chunked activity. In at least some embodiments, by completing a process activity template, all nine process elements (e.g., inputs, outputs, activities, process context, entry criteria, exit criteria, purposes, process flow, and roles) are identified for each chunked activity. Each process activity template is represented by a box in the initial process model. Those skilled in the art will appreciate that while some embodiments include nine process elements, other embodiments include less than nine or more than nine.
- A process model representation is used to represent the processes. Embodiments of the present invention embrace a variety of representations and/or formats, including ETVX, SADT, Role/Flow, and other representations.
- Additionally, all design decisions may be documented.
- With reference now to
FIG. 36 , a lean process modeling and documentation procedure in accordance with a representative embodiment of the present invention is provided. As provided above, a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure ofFIG. 36 illustrates how to model and document a lean process in accordance with a representative embodiment of the present invention. In other words, the illustrated procedure documents the process modeling and documentation for the modeling stage for defining a process or sub-process in accordance with an embodiment of the present invention. - Specifically, as illustrated in
FIG. 36 , the nine process elements (e.g., inputs, outputs, activities, process context, entry criteria, exit criteria, purposes, process flow, and roles) are defined on one page in a process model or diagram (expert mode) for each process activity template. Using one process activity template at a time, the nine process elements are mapped onto the process model diagram. The process modeling representation used is the one selected in the design stage. This is performed for each process activity template. If the process activity template was not used, the nine process elements may be defined on a single page (expert mode) using the process chunk identified in the process design stage. - For intermediate mode, an ordered process table is created with each step being mapped back to an activity in the process model. It is noted that each step in the process model diagram is in expert mode, and that each expert mode step may include more sub-steps or detailed explanations for an intermediate mode.
- Information relating to guidance or lessons learned is included into the steps in the intermediate mode process table. A guidance label is used to document guidance and lessons learned, but is not required every step.
- Once the expert mode process models or diagrams and intermediate mode tables are completed, they are verified and validated. Procedures are then followed for each policy, standard and procedure. Such representative procedures are for policies, standards and procedures are a procedure for developing a lean policy (
FIG. 42 ), a procedure for developing a lean standard (FIG. 41 ), a procedure for developing a lean procedure (FIG. 35 ), and a procedure for developing a lean process guide (FIG. 43 ). - With reference now to
FIG. 37 , a procedure is provided for developing a lean procedure in accordance with a representative embodiment of the present invention. As provided above, a procedure refers to a process document that is a set of activities that describe the “how to”. Accordingly, the procedure ofFIG. 37 illustrates how to document the steps of the process modeling stage for defining procedures. - In accordance with at least some embodiments of the present invention, there are three types of procedures, namely (i) forms, (ii) checklists, and (iii) order tables. Each type of procedure provides benefits for use. Additionally, embodiments of the present invention embrace procedures that are in expert mode, intermediate mode and/or beginner mode.
- A representative form is illustrated in
FIG. 38 as a Meeting Minutes Template. A form enables the collection of information. Thus, the form ofFIG. 38 allows for the collection of information relating to who (meeting attendance), what (meeting title), when (meeting date/time), where (meeting location) and why (meeting purpose). Additionally, the form ofFIG. 38 allows for the collection of information relating to agenda items, action items, issues, and decisions/agreements. - A representative checklist is illustrated in
FIG. 39 . A checklist helps a user to not forget to perform any particular step or task. Additionally, the steps or tasks may be done in any order, which can allow for concurrency. - A representative order table is illustrated in
FIG. 40 . An order table provides a particular sequence for which steps or tasks are to be taken or performed. - Thus, with reference back to
FIG. 37 , the procedure for developing a procedure in accordance with the present invention includes providing a title for the procedure, starting with an action verb, wherein the title is focused on the output of the procedure. Descriptive language is used to name the procedure. A checklist, form and/or ordered table is used depending on the purpose of the procedure, namely to perform a collection of activities in any order, to collect information, and/or to perform activities in a particular order. The primary purpose of a procedure guides the selection of the procedure type. The procedure templates are used and descriptive language is employed when documenting procedure steps. The procedures are kept focused on a single usage scenario. The information is ordered in a logical flow or presentation as possible. In expert mode, the procedures are kept to one page. Additionally, the procedure is chunked into logical groups with the chunks labeled. Procedures are needed when repeatability is needed for “how to” steps. In at least some embodiments, procedures are not needed for every activity (only the vital few activities that require repeatability for a given set of “how to” steps). - With reference now to
FIG. 41 , a procedure is provided for developing a lean standard in accordance with a representative embodiment of the present invention. As provided herein, a standard refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards make work products repeatable and identify a section number, a name and a description. While standards usually describe what goes into a work product, there can also be standards for policies, processes, and procedures. In accordance with at least some embodiments of the present invention, a standard provides an ability to provide uniformity to documentation. For example, a standard identifies particular sections and descriptions for such sections. In at least some embodiments, a standard is provided on one page. The format for a standard can include a table or other format. Moreover, embodiments of the present invention embrace standards that are in expert mode, intermediate mode and/or beginner mode. - In
FIG. 41 , the illustrated procedure documents the steps for the process modeling stage for defining standards on one page (expert mode). Specifically, the title of the standard is identified using a descriptive name. The sections are listed through utilization of a table or by listing the sections using section numbers that become section numbers in the work products. A description is provided for each section, wherein the description is concise and includes a repeatable definition. Industry standards are also utilized. Standards may be combined together into a lean standard (i.e., a one page, expert mode standard). - With reference now to
FIG. 42 , a procedure is provided for developing a lean policy in accordance with a representative embodiment of the present invention. As provided herein, a policy refers to a process document based upon principles that guide and constrain an organization. In accordance with at least some embodiments of the present invention, a policy provides an ability to map out a principle that has been established or otherwise determined. For example, in the business world the senior management determines principles for a particular company, wherein the principles are how the company will be run. In some embodiments, the policies are provided on one page. Moreover, embodiments of the present invention embrace policies that are in expert mode, intermediate mode and/or beginner mode. - The procedure of
FIG. 42 documents representative steps of the process modeling stage for defining policies. Specifically, the policy is given a title using descriptive terms. The vital principles that the organization should follow are defined and chunked as needed. This can be done in a table or by listing the principles using numbers or bullets. Good sources for process principles come from industry standards and reference materials. Optionally, each principle may be labeled for summary purposes and ease of reading. An authorization/approval section may be added for the policies. Policies may have definitions, including operational definitions which are repeatable and measurable. Policies may be combined together into a policy document. Alternatively, the policy may be defined in the process guide along with the other process documentation. - With reference now to
FIG. 43 , a procedure is provided for developing a lean process guide in accordance with a representative embodiment of the present invention. The process guide is a manner to package or otherwise provide documentation. It is a succinct output or deliverable having scalability. - The procedure of
FIG. 43 illustrates representative steps of the process modeling stage for defining a lean process guide. Specifically, the title of the process guide is determined using descriptive language. The process guide is similar to a user guide and is kept short and usable. It is the primary package used by a user/customer. The following is a checklist that is used to check the process guide: -
- Does the process guide match the process models?
- Does the process guide match the process description tables?
- Does the customer/user want the policies, standards and procedures combined in the process guide, or in separate documents?
- Have each of the policies, standards and procedures been kept to a single page?
- Has the process guide been verified?
- Has the process guide been validated?
- Has the grammar of the process guide been checked?
- Has the spelling of the process guide been checked?
- Have the process guide been edited, such as by a professional editor?
- Has the process guide been backed up?
- With reference now to
FIG. 44 , a procedure is provided for developing a process guide standard in accordance with a representative embodiment of the present invention. InFIG. 44 , the goal with the process guide is to keep it as short and usable as possible. The process guide standard ofFIG. 43 includes the purpose, scope, audience, usage, definitions/references, process models, records, interfaces, metrics, forms and templates, training, miscellaneous information, and appendixes. -
FIGS. 10-34 provided a representative example relating to a representative decision process, whereinFIG. 10 illustrated a representative process work WAR template for the representative decision process,FIGS. 11-12 illustrated a representative process activity template for the chunked activity 6.1 entitled “Prepare for Decision” ofFIG. 10 ,FIGS. 13-14 illustrated a representative process activity template for the chunked activity 6.2 entitled “Conduct Decision Meeting” ofFIG. 10 ,FIGS. 15-16 illustrated a representative process activity template for the chunked activity 6.3 entitled “Perform Decision Follow-Up” ofFIG. 10 , and whereinFIGS. 17-34 illustrated a representative decision process guide,FIGS. 18-24 illustrating chunked activities of the decision process in a representative ETMX format andFIGS. 25-30 illustrating chunked activities of the decision process in a swim lane format. -
FIGS. 45-74 provide another representative example that relates to a configuration management (“CM”) process, whereinFIGS. 45-46 illustrate a representative WAR template for the representative CM process,FIGS. 47-48 illustrate a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” ofFIG. 45 ,FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” ofFIG. 45 ,FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CS A” ofFIG. 45 ,FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” ofFIG. 45 , and whereFIGS. 55-74 illustrate a representative CM process guide. - Thus, with reference now to
FIGS. 45-46 , the illustrated WAR template identifies the work products that are used and produced by the CM process as being (i) a baseline, (ii) a configuration control board (“CCB”) meeting minutes, (iii) a change request (“CR”), (iv) a CM system, (v) a configuration audit report, (vi) a configuration identification report, (vii) a configuration item (“CI”), (viii) a change request/problem report (“CR/PR”) trend report, (ix) an organizational CM plan, (x) a problem report (“PR”), (xi) a project CM plan, and (xii) a project plan. - As provided above, the term “work product” refers to a process building block that consist of any draft or final product (i.e., inputs and outputs) or service used or produced by a process or activity (i.e., the “what”). As illustrated, each work product is assigned an identification code.
- The WAR Template of
FIGS. 45-46 identifies the activities that are to be performed for the CM process. The term “activity” refers to a process building block and a process element that addresses the “what”. An activity is an action or task that is taken to use or consume work products (e.g., inputs), to add value, and to produce work products (e.g., outputs) and services. An activity is any action, and can be as broad as organizational functions (e.g., accounting, legal, etc.), processes (e.g., configuration management, project planning, reviews, etc.), procedures (e.g., a checklist), or as specific as particular steps (e.g., sign your name and approve a document). - The activities are identified, chunked and a process activity template is created for each chunk. In the present embodiment, each chunk includes a maximum of 7±2 activities. However, as provided herein, those skilled in the art will appreciate that embodiments of the present invention embrace a maximum chunking value that is less than or greater than 7±2.
- In the illustrated embodiment, the CM process is identified as identification code 7.0. The particular activities are identified as identification codes 7.1-7.4.6. The activities have been chunked into four chunks, specifically “Perform CM Planning” (7.1), “Perform Configuration Control” (7.2), “Perform Configuration Status Accounting” (7.3), and “Perform CM Audits” (7.4). Each activity chunk includes a corresponding process activity template, as illustrated in
FIGS. 47-54 . Each chunk is a sub-process. Those skilled in the art will appreciate that embodiments of the present invention may include sub-processes having their own sub-processes. - As illustrated, the WAR Template of
FIGS. 45-46 further includes the particular roles (seeFIG. 46 ). The term “role” refers to a process building block and a process element that can be manual or automated, and roles perform the activities in a process (i.e., the “who”). Specifically, the illustrated roles are the Configuration Control Board (CCB), the Configuration Management (CM) Auditor, the Configuration Management (CM) Lead, the developers, the project manager (PM), the quality assurance (QA), and the requester. - With reference now to
FIGS. 47-48 a representative process activity template for the chunked activity 7.1 entitled “Perform CM Planning” ofFIGS. 45-46 is illustrated. The process activity template ofFIGS. 47-48 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.1. -
FIGS. 49-50 illustrate a representative process activity template for the chunked activity 7.2 entitled “Perform Configuration Control” ofFIGS. 45-46 . The process activity template ofFIGS. 49-50 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.2. -
FIGS. 51-52 illustrate a representative process activity template for the chunked activity 7.3 entitled “Perform CSA” ofFIGS. 45-46 . The process activity template ofFIGS. 51-52 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.3. -
FIGS. 53-54 illustrate a representative process activity template for the chunked activity 7.4 entitled “Perform CM Audits” ofFIGS. 45-46 . The process activity template ofFIGS. 53-54 identifies the purpose, inputs, entry criteria, activities and who performs each activity, sub-processes and procedures, outputs, exit criteria, process flow, and process context of chunked activity 7.4. -
FIGS. 55-74 illustrate a representative CM process guide, whereinFIGS. 57-64 illustrate chunked activities of the decision process in a swim lane format. The CM process guide enables a user to perform the CM process and includes corresponding procedures, standards and policies. The following CM process guide is provided to illustrate the particular aspects of the representative process guide. - In
FIG. 55 , the process guide includes the purpose, the scope, audience, usage, acronyms, and references. InFIG. 56 , a graphical representation of theCM process 120 is illustrated, which includes a phase for each chunked activity, namely 7.1 Perform CM Planning, 7.2 Perform Configuration Control, 7.3 Perform Configuration Status Accounting, and 7.4 Perform CM Audits. Additionally the dotted lines of the graphical representation of theCM process 120 illustrate concurrency. - With reference to
FIG. 57 , an expert mode of activity 7.1 Perform CM Planning is provided in a swim lane format.FIG. 58 illustrates an intermediate mode of activity 7.1 Perform CM Planning.FIGS. 57-58 further include all of the activities that have been chunked. It is noted that inFIG. 57 ,representation 130 is similar to representation 120 (FIG. 56 ) and identifies to the user the location of activity 7.1 in the overall CM process. - With reference to
FIG. 59 , an expert mode of activity 7.2 Perform Configuration Control is provided in a swim lane format.FIG. 60 illustrates an intermediate mode of activity 7.2 Perform Configuration Control.FIGS. 59-60 further include all of the activities that have been chunked. It is noted that inFIG. 59 ,representation 140 is similar to representation 120 (FIG. 56 ) and identifies to the user the location of activity 7.2 in the overall CM process. - With reference to
FIG. 61 , an expert mode of activity 7.3 Perform Configuration Status Accounting is provided in a swim lane format.FIG. 62 illustrates an intermediate mode of activity 7.3 Perform Configuration Status Accounting.FIGS. 61-62 further include all of the activities that have been chunked. It is noted that inFIG. 61 ,representation 150 is similar to representation 120 (FIG. 56 ) and identifies to the user the location of activity 7.3 in the overall CM process. - With reference to
FIG. 63 , an expert mode of activity 7.4 Perform CM Audit is provided in a swim lane format.FIG. 64 illustrates an intermediate mode of activity 7.4 Perform CM Audit.FIGS. 63-64 further include all of the activities that have been chunked. It is noted that inFIG. 63 ,representation 160 is similar to representation 120 (FIG. 56 ) and identifies to the user the location of activity 7.4 in the overall CM process. - In
FIG. 65 , the process guide includes the general exit criteria for the CM process, the relevant records, interfaces, metrics, standards, training, and maintenance of the process. InFIG. 66 , a representative CM policy is provided. As provided herein, the term “policy” refers to a process document based upon principles that guide and constrain an organization. It specifically identifies the CM purpose, the policy scope, the individual CM policies, and the authorization. - In
FIG. 67 , a representative CM plan standard is provided. The term “standard” refers to a process document that comprises sections or parts, and descriptions of those parts or descriptions of what goes into those sections. Standards usually describe what goes into a work product, but there can also be standards for policies, processes, and procedures. A list of just sections or parts is not a standard, but is a template. - In
FIG. 68 , a representative CM report standards is provided, which identifies the required reports for the present embodiment. Specifically, the reports include (i) a configuration identification report standard, (ii) a change request and problem report standard, (iii) a CCB meeting minutes standard, and (iv) a CM audit report standard. - In
FIGS. 69-70 , representative CM audit checklists are provided. The checklists include (i) a requirements baseline audit checklist, (ii) a code baseline audit checklist, and (iii) a product baseline audit checklist. -
FIG. 71 illustrates a representative establish CM system procedure.FIG. 72 illustrates a representative change control procedure.FIG. 73 illustrates a representative conduct CCB meeting procedure.FIG. 74 illustrates a representative release procedure. - As provided herein, at least some embodiments of the present invention embrace performing at least portions of the methods and/or processes of the present invention through the use of a computer device, including processes, procedures, standards and/or policies. Moreover, embodiments of the present invention embrace electronic and/or hardcopy documentation. Furthermore, embodiments of the present invention scale up to complexity, provide the ability to chunk onto a single page, and/or include all nine process elements (i.e., inputs, outputs, activities, process context, entry criteria, exit criteria, purposes, process flow, and roles). Moreover, at least some embodiments include all nine process elements on a single page.
- Thus, as discussed herein, the embodiments of the present invention embrace providing documentation having succinct communication with scalability. In particular, embodiments of the present invention relate to systems and methods for defining and documenting processes, procedures, standards and policies that are succinct and usable, and that are scalable to the complexity of the process and to abilities of the individual user.
- The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims (20)
1. A method, performed by a computer system, for generating a process model representation for each of a plurality of activity chunks in a process such that each process model representation is arranged to be displayed on a single page, the method comprising:
receiving, by one or more processors of the computer system, a template for a process, the template defining each work product that is used by the process, each activity performed by the process, and each role that performs an activity in the process, each activity being associated with one of a plurality of activity chunks defined for the process;
generating, by one or more processors of the computer system, and for each of the activity chunks, a process activity template;
generating, by one or more processors of the computer system, and for each process activity template, a process model representation, each process model representation being arranged to be displayed on a single page, each process model representation comprising:
a graphical representation of the flow between the activities in the represented activity chunk.
2. The method of claim 1 , wherein each process activity template defines:
any inputs used by the activity chunk;
entry criteria defining when the activity chunk is to be performed;
which role is responsible for performing each activity in the activity chunk;
any outputs produced by the activity chunk; and
exit criteria defining when the activity chunk is completed.
3. The method of claim 2 , wherein each process model representation further comprises:
a graphical representation of the inputs, entry criteria, roles involved in performing the activities of the represented activity chunk, outputs, and exit criteria.
4. The method of claim 1 , wherein each process model representation also includes an indication of which role performs each activity in the represented activity chunk.
5. The method of claim 4 , wherein the indication of which role performs each activity is provided by defining a column for each role and arranging the graphical representation of the flow between the activities so that the activities performed by a particular role are arranged in the particular role's column and activities performed by multiple roles are arranged to span the columns of each of the multiple roles.
6. The method of claim 1 , wherein each process model representation also includes a graphical representation of the location of the represented activity chunk within the process.
7. The method of claim 1 , wherein each process model representation also includes an indication of the purpose of the represented activity chunk.
8. The method of claim 1 , wherein the graphical representation of the flow between activities comprises a list of the activities.
9. The method of claim 1 , wherein the graphical representation of the flow between activities comprises a diagram including a box for each activity and arrows indicating the flow from one activity to another.
10. The method of claim 2 , wherein each process activity template includes an indication of which activity in the activity chunk uses each input defined in the process activity template.
11. The method of claim 2 , wherein the entry criteria defined in each process activity template defines a state or condition within the process that will cause the process flow to transition to the activities in the activity chunk.
12. The method of claim 11 , wherein the state or condition comprises Boolean logic applied to multiple states or conditions within the process.
13. The method of claim 2 , wherein each process activity template includes an indication of which activity in the activity chunk generates each output defined in the process activity template.
14. The method of claim 1 , wherein at least one of the process model representations also comprises an indication of measurements made by the activities of the represented activity chunk.
15. The method of claim 1 , wherein the graphical representation is organized based on the intended audience that will use the process model representation.
16. One or more computer storage media storing computer executable instructions which when executed by one or more processors performs a method for generating a process model representation for each of a plurality of activity chunks in a process such that each process model representation is arranged to be displayed on a single page, the method comprising:
receiving, by one or more processors of the computer system, a template for a process, the template defining each work product that is used by the process, each activity performed by the process, and each role that performs an activity in the process, each activity being associated with one of a plurality of activity chunks defined for the process;
generating, by one or more processors of the computer system, and for each of the activity chunks, a process activity template;
generating, by one or more processors of the computer system, and for each process activity template, a process model representation, each process model representation being arranged to be displayed on a single page, each process model representation comprising:
a graphical representation of the flow between the activities in the represented activity chunk.
17. The one or more computer storage media of claim 16 , wherein each process activity template defines:
any inputs used by the activity chunk;
entry criteria defining when the activity chunk is to be performed;
which role is responsible for performing each activity in the activity chunk;
any outputs produced by the activity chunk; and
exit criteria defining when the activity chunk is completed.
18. The one or more computer storage media of claim 17 , wherein each process model representation further comprises:
a graphical representation of the inputs, entry criteria, roles involved in performing the activities of the represented activity chunk, outputs, and exit criteria.
19. The one or more computer storage media of claim 16 , wherein each process model representation also includes an indication of which role performs each activity in the represented activity chunk.
20. The one or more computer storage media of claim 19 , wherein the indication of which role performs each activity is provided by defining a column for each role and arranging the graphical representation of the flow between the activities so that the activities performed by a particular role are arranged in the particular role's column and activities performed by multiple roles are arranged to span the columns of each of the multiple roles.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/794,671 US20140096061A1 (en) | 2006-04-21 | 2013-03-11 | Systems and methods for providing documentation having succinct communication with scalability |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/409,522 US8396736B2 (en) | 2006-04-21 | 2006-04-21 | Systems and methods for providing documentation having succinct communication with scalability |
US13/794,671 US20140096061A1 (en) | 2006-04-21 | 2013-03-11 | Systems and methods for providing documentation having succinct communication with scalability |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/409,522 Continuation US8396736B2 (en) | 2006-04-21 | 2006-04-21 | Systems and methods for providing documentation having succinct communication with scalability |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140096061A1 true US20140096061A1 (en) | 2014-04-03 |
Family
ID=38620580
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/409,522 Active 2030-12-27 US8396736B2 (en) | 2006-04-21 | 2006-04-21 | Systems and methods for providing documentation having succinct communication with scalability |
US13/794,671 Abandoned US20140096061A1 (en) | 2006-04-21 | 2013-03-11 | Systems and methods for providing documentation having succinct communication with scalability |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/409,522 Active 2030-12-27 US8396736B2 (en) | 2006-04-21 | 2006-04-21 | Systems and methods for providing documentation having succinct communication with scalability |
Country Status (2)
Country | Link |
---|---|
US (2) | US8396736B2 (en) |
WO (1) | WO2007127511A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109697055A (en) * | 2017-10-23 | 2019-04-30 | 北京京东尚科信息技术有限公司 | Generate the method and system of the mobile App page |
US11270067B1 (en) * | 2018-12-26 | 2022-03-08 | Snap Inc. | Structured activity templates for social media content |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080183537A1 (en) * | 2007-01-30 | 2008-07-31 | International Business Machines Corporation | Approach to comprehensive requirements specifications for complex workflows |
US20090299797A1 (en) * | 2008-05-30 | 2009-12-03 | Microsoft Corporation | Infrastructure planning and design series architecture education framework |
US20110153514A1 (en) * | 2009-12-18 | 2011-06-23 | International Business Machines Corporation | Generating Customer-Specific Solution Documentation |
US20150033189A1 (en) * | 2013-07-25 | 2015-01-29 | Sap Ag | Methods and systems of spiral navigation |
Citations (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5018082A (en) * | 1987-05-25 | 1991-05-21 | Fujitsu Limited | Guidance message display timing control using time intervals |
US5107332A (en) * | 1989-05-17 | 1992-04-21 | Hewlett-Packard Company | Method and system for providing closed loop color control between a scanned color image and the output of a color printer |
US5257363A (en) * | 1990-04-09 | 1993-10-26 | Meta Software Corporation | Computer-aided generation of programs modelling complex systems using colored petri nets |
US5493321A (en) * | 1993-02-25 | 1996-02-20 | Minnesota Mining And Manufacturing Company | Method and apparatus of characterization for photoelectric color proofing systems |
US5513308A (en) * | 1992-09-03 | 1996-04-30 | Matsushita Electric Industrial Co., Ltd. | Device and method for determining a series of operations for interactive assistance |
US5774118A (en) * | 1994-12-13 | 1998-06-30 | Fujitsu Limited | Method and device for displaying help for operations and concepts matching skill level |
US5774661A (en) * | 1995-04-18 | 1998-06-30 | Network Imaging Corporation | Rule engine interface for a visual workflow builder |
US6067357A (en) * | 1998-03-04 | 2000-05-23 | Genesys Telecommunications Laboratories Inc. | Telephony call-center scripting by Petri Net principles and techniques |
US6256598B1 (en) * | 1998-07-10 | 2001-07-03 | The Regents Of The University Of Michigan | Method and system for creating a control-flow structure which represents control logic, reconfigurable logic controller having the control logic, method for designing the controller and method for changing its control logic |
US6308224B1 (en) * | 1996-03-29 | 2001-10-23 | International Business Machines Corporation | Method of generating an implementation of a workflow process model in an object environment |
US6327362B1 (en) * | 1998-11-23 | 2001-12-04 | Lucent Technologies Inc. | System and method including dynamic differential treatment in workflows and contact flow |
US20010049615A1 (en) * | 2000-03-27 | 2001-12-06 | Wong Christopher L. | Method and apparatus for dynamic business management |
US6349238B1 (en) * | 1998-09-16 | 2002-02-19 | Mci Worldcom, Inc. | System and method for managing the workflow for processing service orders among a variety of organizations within a telecommunications company |
US20020055793A1 (en) * | 2000-05-18 | 2002-05-09 | Kenji Yoshioka | Information processing system, information processing process and recording medium |
US20020145750A1 (en) * | 2001-04-09 | 2002-10-10 | Hachirou Honda | Printing materials production supporting apparatus, printing materials production supporting system, and printing materials production supporting program |
US20020181017A1 (en) * | 2001-05-30 | 2002-12-05 | Alberto Such | Open coventuring in a remote hardcopy proofing service, with preserved clientele, through interface sharing |
US20030018512A1 (en) * | 2001-07-19 | 2003-01-23 | Dortmans Henricus M.J.M. | Method for creating a workflow |
US20030036940A1 (en) * | 2001-08-16 | 2003-02-20 | International Business Machines Corporation | Dynamic and adaptive definition of the evaluation sequence of transition conditions in workflow management systems |
US20030050800A1 (en) * | 2001-08-31 | 2003-03-13 | Siemens Medical Solutions Health Services Corporation. | System and user interface supporting task schedule configuration |
US20030055811A1 (en) * | 2001-09-20 | 2003-03-20 | Ricoh Company, Ltd. | Document controlled workflow systems and methods |
US20030065613A1 (en) * | 2001-09-28 | 2003-04-03 | Smith Diane K. | Software for financial institution monitoring and management and for assessing risk for a financial institution |
US6546364B1 (en) * | 1998-12-18 | 2003-04-08 | Impresse Corporation | Method and apparatus for creating adaptive workflows |
US20030072031A1 (en) * | 2001-03-23 | 2003-04-17 | Katie Kuwata | Electronic document assembly, proofing and printing system |
US20030144974A1 (en) * | 2002-01-31 | 2003-07-31 | Samsung Electronics Co., Ltd. | Self organizing learning petri nets |
US20030189724A1 (en) * | 2002-04-09 | 2003-10-09 | Nexpress Solutions Llc | Variable data printing using variants |
US20040066527A1 (en) * | 2002-10-02 | 2004-04-08 | Nexpress Solutions Llc | Finish verification in printing |
US20040078258A1 (en) * | 2002-07-31 | 2004-04-22 | Karsten Schulz | Transformations between private and shared workflows |
US20040083448A1 (en) * | 2002-07-31 | 2004-04-29 | Karsten Schulz | Workflow management architecture |
US20040153804A1 (en) * | 2002-10-22 | 2004-08-05 | Terrence Blevins | Integration of graphic display elements, process modules and control modules in process plants |
US20040190057A1 (en) * | 2003-03-27 | 2004-09-30 | Canon Kabushiki Kaisha | Image forming system, method and program of controlling image forming system, and storage medium |
US20050026129A1 (en) * | 2001-12-28 | 2005-02-03 | Rogers Kevin B. | Interactive computerized performance support system and method |
US20050071752A1 (en) * | 2003-09-24 | 2005-03-31 | Marlatt Jane E. | Forms management system |
US6876894B1 (en) * | 2003-11-05 | 2005-04-05 | Taiwan Semiconductor Maufacturing Company, Ltd. | Forecast test-out of probed fabrication by using dispatching simulation method |
US20050159968A1 (en) * | 2004-01-21 | 2005-07-21 | Stephen Cozzolino | Organizationally interactive task management and commitment management system in a matrix based organizational environment |
US6930790B1 (en) * | 2000-05-01 | 2005-08-16 | Adobe Systems Incorporated | Color rendering dictionary for testing color conversion |
US6937993B1 (en) * | 1998-09-16 | 2005-08-30 | Mci, Inc. | System and method for processing and tracking telecommunications service orders |
US6943915B1 (en) * | 1999-09-14 | 2005-09-13 | Fuji Photo Film Co., Ltd. | Color conversion method, color conversion apparatus and color conversion definition storage medium |
US6957418B2 (en) * | 2001-01-23 | 2005-10-18 | Altia, Inc. | System and method of designing, testing, and employing graphical computer code |
US20060044597A1 (en) * | 2004-09-01 | 2006-03-02 | Dumitrescu Tiberiu A | Print job workflow system |
US20060074734A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Declarative representation for an extensible workflow model |
US20060074733A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Framework for seamlessly authoring and editing workflows at design and runtime |
US20060074730A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Extensible framework for designing workflows |
US20060074731A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Unified model for authoring and executing flow-based and constraint-based workflows |
US20060074735A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Ink-enabled workflow authoring |
US20060074732A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Componentized and extensible workflow model |
US20060074736A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Programming interface for a componentized and extensible workflow model |
US20060092467A1 (en) * | 2004-09-01 | 2006-05-04 | Dumitrescu Tiberiu A | Print job workflow system |
US20060197977A1 (en) * | 2005-03-02 | 2006-09-07 | Canon Kabushiki Kaisha | Information processing apparatus, process control method, and program thereof |
US20070168065A1 (en) * | 2004-05-04 | 2007-07-19 | Fisher-Rosemount Systems, Inc. | System for configuring graphic display elements and process modules in process plants |
US20070203778A1 (en) * | 2006-02-28 | 2007-08-30 | Accenture Global Services Gmbh | Workflow management |
US7275039B2 (en) * | 2000-10-03 | 2007-09-25 | Michael Setteducati | Workflow management software overview |
US7283971B1 (en) * | 2000-09-06 | 2007-10-16 | Masterlink Corporation | System and method for managing mobile workers |
US7369918B2 (en) * | 2004-07-15 | 2008-05-06 | Rodger Cosgrove | System and apparatus for generating mailers on demand |
US7526722B2 (en) * | 2005-12-29 | 2009-04-28 | Sap Ag | System and method for providing user help according to user category |
US7580911B2 (en) * | 2004-04-30 | 2009-08-25 | Xerox Corporation | Workflow auto generation from user constraints and hierarchical dependence graphs for workflows |
US7620894B1 (en) * | 2003-10-08 | 2009-11-17 | Apple Inc. | Automatic, dynamic user interface configuration |
US7640548B1 (en) * | 2002-06-21 | 2009-12-29 | Siebel Systems, Inc. | Task based user interface |
US7830441B2 (en) * | 2005-11-18 | 2010-11-09 | Canon Kabushiki Kaisha | Image pickup apparatus and controlling method thereof |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5737727A (en) * | 1996-01-25 | 1998-04-07 | Electronic Data Systems Corporation | Process management system and method |
US6304259B1 (en) * | 1998-02-09 | 2001-10-16 | International Business Machines Corporation | Computer system, method and user interface components for abstracting and accessing a body of knowledge |
US8479109B2 (en) * | 1999-08-19 | 2013-07-02 | National Instruments Corporation | Programmatically generating a graphical program in response to user input |
US6760044B1 (en) * | 2000-02-02 | 2004-07-06 | Edutainment, Inc. | Method and apparatus for performing knowledge level conversion of hierarchical charts created as a learning aid |
US6771286B2 (en) * | 2000-02-02 | 2004-08-03 | Edutainment, Inc. | Method and apparatus for converting text files into hierarchical charts as a learning aid |
US6768500B1 (en) * | 2000-02-02 | 2004-07-27 | Edutainment, Inc. | Method and apparatus for converting image files into hierarchical charts as a learning aid |
US6795098B1 (en) * | 2000-02-02 | 2004-09-21 | Edutainment, Inc. | Method and apparatus for bringing together separately created information blocks into a single information block for creating multiple hierarchies |
US20010039002A1 (en) * | 2000-02-18 | 2001-11-08 | John Delehanty | System and method for implementing and managing training programs over a network of computers |
US6755659B2 (en) * | 2001-07-05 | 2004-06-29 | Access Technologies Group, Inc. | Interactive training system and method |
US20030172052A1 (en) * | 2002-03-11 | 2003-09-11 | Thomas Crandell | Conceptual framework and assessment tool for designing a personalized electronic textbook and other online educational software |
US8069413B2 (en) * | 2003-02-28 | 2011-11-29 | Bea Systems, Inc. | Systems for providing extensible help |
US20050288956A1 (en) * | 2004-06-16 | 2005-12-29 | Ewald Speicher | Systems and methods for integrating business process documentation with work environments |
US20060088806A1 (en) * | 2004-10-26 | 2006-04-27 | Clark Quinn | Learning integrating system and methods |
-
2006
- 2006-04-21 US US11/409,522 patent/US8396736B2/en active Active
-
2007
- 2007-01-24 WO PCT/US2007/060992 patent/WO2007127511A2/en active Application Filing
-
2013
- 2013-03-11 US US13/794,671 patent/US20140096061A1/en not_active Abandoned
Patent Citations (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5018082A (en) * | 1987-05-25 | 1991-05-21 | Fujitsu Limited | Guidance message display timing control using time intervals |
US5107332A (en) * | 1989-05-17 | 1992-04-21 | Hewlett-Packard Company | Method and system for providing closed loop color control between a scanned color image and the output of a color printer |
US5257363A (en) * | 1990-04-09 | 1993-10-26 | Meta Software Corporation | Computer-aided generation of programs modelling complex systems using colored petri nets |
US5513308A (en) * | 1992-09-03 | 1996-04-30 | Matsushita Electric Industrial Co., Ltd. | Device and method for determining a series of operations for interactive assistance |
US5493321A (en) * | 1993-02-25 | 1996-02-20 | Minnesota Mining And Manufacturing Company | Method and apparatus of characterization for photoelectric color proofing systems |
US5774118A (en) * | 1994-12-13 | 1998-06-30 | Fujitsu Limited | Method and device for displaying help for operations and concepts matching skill level |
US5774661A (en) * | 1995-04-18 | 1998-06-30 | Network Imaging Corporation | Rule engine interface for a visual workflow builder |
US6308224B1 (en) * | 1996-03-29 | 2001-10-23 | International Business Machines Corporation | Method of generating an implementation of a workflow process model in an object environment |
US6067357A (en) * | 1998-03-04 | 2000-05-23 | Genesys Telecommunications Laboratories Inc. | Telephony call-center scripting by Petri Net principles and techniques |
US6256598B1 (en) * | 1998-07-10 | 2001-07-03 | The Regents Of The University Of Michigan | Method and system for creating a control-flow structure which represents control logic, reconfigurable logic controller having the control logic, method for designing the controller and method for changing its control logic |
US6349238B1 (en) * | 1998-09-16 | 2002-02-19 | Mci Worldcom, Inc. | System and method for managing the workflow for processing service orders among a variety of organizations within a telecommunications company |
US6937993B1 (en) * | 1998-09-16 | 2005-08-30 | Mci, Inc. | System and method for processing and tracking telecommunications service orders |
US6327362B1 (en) * | 1998-11-23 | 2001-12-04 | Lucent Technologies Inc. | System and method including dynamic differential treatment in workflows and contact flow |
US6546364B1 (en) * | 1998-12-18 | 2003-04-08 | Impresse Corporation | Method and apparatus for creating adaptive workflows |
US6943915B1 (en) * | 1999-09-14 | 2005-09-13 | Fuji Photo Film Co., Ltd. | Color conversion method, color conversion apparatus and color conversion definition storage medium |
US20010049615A1 (en) * | 2000-03-27 | 2001-12-06 | Wong Christopher L. | Method and apparatus for dynamic business management |
US6930790B1 (en) * | 2000-05-01 | 2005-08-16 | Adobe Systems Incorporated | Color rendering dictionary for testing color conversion |
US20020055793A1 (en) * | 2000-05-18 | 2002-05-09 | Kenji Yoshioka | Information processing system, information processing process and recording medium |
US6791577B2 (en) * | 2000-05-18 | 2004-09-14 | Nec Corporation | Operation guidance display processing system and method |
US7283971B1 (en) * | 2000-09-06 | 2007-10-16 | Masterlink Corporation | System and method for managing mobile workers |
US7275039B2 (en) * | 2000-10-03 | 2007-09-25 | Michael Setteducati | Workflow management software overview |
US6957418B2 (en) * | 2001-01-23 | 2005-10-18 | Altia, Inc. | System and method of designing, testing, and employing graphical computer code |
US20030072031A1 (en) * | 2001-03-23 | 2003-04-17 | Katie Kuwata | Electronic document assembly, proofing and printing system |
US20020145750A1 (en) * | 2001-04-09 | 2002-10-10 | Hachirou Honda | Printing materials production supporting apparatus, printing materials production supporting system, and printing materials production supporting program |
US20020181017A1 (en) * | 2001-05-30 | 2002-12-05 | Alberto Such | Open coventuring in a remote hardcopy proofing service, with preserved clientele, through interface sharing |
US7327481B2 (en) * | 2001-05-30 | 2008-02-05 | Hewlett-Packard Development Company, L.P. | Open coventuring in a remote hardcopy proofing service, with preserved clientele, through interface sharing |
US7234140B2 (en) * | 2001-07-19 | 2007-06-19 | Oce-Technologies B.V. | Method for creating a workflow |
US20030018512A1 (en) * | 2001-07-19 | 2003-01-23 | Dortmans Henricus M.J.M. | Method for creating a workflow |
US20030036940A1 (en) * | 2001-08-16 | 2003-02-20 | International Business Machines Corporation | Dynamic and adaptive definition of the evaluation sequence of transition conditions in workflow management systems |
US20030050800A1 (en) * | 2001-08-31 | 2003-03-13 | Siemens Medical Solutions Health Services Corporation. | System and user interface supporting task schedule configuration |
US7120699B2 (en) * | 2001-09-20 | 2006-10-10 | Ricoh Company, Ltd. | Document controlled workflow systems and methods |
US20030055811A1 (en) * | 2001-09-20 | 2003-03-20 | Ricoh Company, Ltd. | Document controlled workflow systems and methods |
US20030065613A1 (en) * | 2001-09-28 | 2003-04-03 | Smith Diane K. | Software for financial institution monitoring and management and for assessing risk for a financial institution |
US20050026129A1 (en) * | 2001-12-28 | 2005-02-03 | Rogers Kevin B. | Interactive computerized performance support system and method |
US20030144974A1 (en) * | 2002-01-31 | 2003-07-31 | Samsung Electronics Co., Ltd. | Self organizing learning petri nets |
US20030189724A1 (en) * | 2002-04-09 | 2003-10-09 | Nexpress Solutions Llc | Variable data printing using variants |
US7640548B1 (en) * | 2002-06-21 | 2009-12-29 | Siebel Systems, Inc. | Task based user interface |
US20040083448A1 (en) * | 2002-07-31 | 2004-04-29 | Karsten Schulz | Workflow management architecture |
US20040078258A1 (en) * | 2002-07-31 | 2004-04-22 | Karsten Schulz | Transformations between private and shared workflows |
US20040066527A1 (en) * | 2002-10-02 | 2004-04-08 | Nexpress Solutions Llc | Finish verification in printing |
US20040153804A1 (en) * | 2002-10-22 | 2004-08-05 | Terrence Blevins | Integration of graphic display elements, process modules and control modules in process plants |
US20040190057A1 (en) * | 2003-03-27 | 2004-09-30 | Canon Kabushiki Kaisha | Image forming system, method and program of controlling image forming system, and storage medium |
US20050071752A1 (en) * | 2003-09-24 | 2005-03-31 | Marlatt Jane E. | Forms management system |
US7620894B1 (en) * | 2003-10-08 | 2009-11-17 | Apple Inc. | Automatic, dynamic user interface configuration |
US6876894B1 (en) * | 2003-11-05 | 2005-04-05 | Taiwan Semiconductor Maufacturing Company, Ltd. | Forecast test-out of probed fabrication by using dispatching simulation method |
US20050159968A1 (en) * | 2004-01-21 | 2005-07-21 | Stephen Cozzolino | Organizationally interactive task management and commitment management system in a matrix based organizational environment |
US7580911B2 (en) * | 2004-04-30 | 2009-08-25 | Xerox Corporation | Workflow auto generation from user constraints and hierarchical dependence graphs for workflows |
US20070168065A1 (en) * | 2004-05-04 | 2007-07-19 | Fisher-Rosemount Systems, Inc. | System for configuring graphic display elements and process modules in process plants |
US20070168060A1 (en) * | 2004-05-04 | 2007-07-19 | Fisher-Rosemount Systems, Inc. | Markup language-based, dynamic process graphics in a process plant user interface |
US7369918B2 (en) * | 2004-07-15 | 2008-05-06 | Rodger Cosgrove | System and apparatus for generating mailers on demand |
US20060092467A1 (en) * | 2004-09-01 | 2006-05-04 | Dumitrescu Tiberiu A | Print job workflow system |
US20060044597A1 (en) * | 2004-09-01 | 2006-03-02 | Dumitrescu Tiberiu A | Print job workflow system |
US20060074733A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Framework for seamlessly authoring and editing workflows at design and runtime |
US20060074730A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Extensible framework for designing workflows |
US20060074734A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Declarative representation for an extensible workflow model |
US20060074731A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Unified model for authoring and executing flow-based and constraint-based workflows |
US20060074736A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Programming interface for a componentized and extensible workflow model |
US20060074732A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Componentized and extensible workflow model |
US20060074735A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Ink-enabled workflow authoring |
US20060197977A1 (en) * | 2005-03-02 | 2006-09-07 | Canon Kabushiki Kaisha | Information processing apparatus, process control method, and program thereof |
US7701605B2 (en) * | 2005-03-02 | 2010-04-20 | Canon Kabushiki Kaisha | Information processing apparatus, process control method, and program thereof |
US7830441B2 (en) * | 2005-11-18 | 2010-11-09 | Canon Kabushiki Kaisha | Image pickup apparatus and controlling method thereof |
US7526722B2 (en) * | 2005-12-29 | 2009-04-28 | Sap Ag | System and method for providing user help according to user category |
US20070203778A1 (en) * | 2006-02-28 | 2007-08-30 | Accenture Global Services Gmbh | Workflow management |
Non-Patent Citations (3)
Title |
---|
Bharadwaj, V. R. (2000). Web-based workflow in secure collaborative telemedicine. West Virginia University). ProQuest Dissertations and Theses, , 120-120 p * |
Fontana, J. (1996). All on the SamePage -- WebFlow's new version boasts enhanced features. CommunicationsWeek, , 39-39 * |
Sharples, H. (1998). CTP: Long wait for the inevitable. Graphic Arts Monthly, 70(2), 53-58 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109697055A (en) * | 2017-10-23 | 2019-04-30 | 北京京东尚科信息技术有限公司 | Generate the method and system of the mobile App page |
US11270067B1 (en) * | 2018-12-26 | 2022-03-08 | Snap Inc. | Structured activity templates for social media content |
US11640497B2 (en) | 2018-12-26 | 2023-05-02 | Snap Inc. | Structured activity templates for social media content |
Also Published As
Publication number | Publication date |
---|---|
WO2007127511A2 (en) | 2007-11-08 |
WO2007127511A3 (en) | 2008-05-22 |
US20070250359A1 (en) | 2007-10-25 |
US8396736B2 (en) | 2013-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8200527B1 (en) | Method for prioritizing and presenting recommendations regarding organizaion's customer care capabilities | |
Perry | Effective Methods for Software Testing, CafeScribe: Includes Complete Guidelines, Checklists, and Templates | |
US20140096061A1 (en) | Systems and methods for providing documentation having succinct communication with scalability | |
Cimperman | Uat defined: A guide to practical user acceptance testing (digital short cut) | |
Richter et al. | User-centred engineering: Creating products for humans | |
Dionisio | A Project Manager's Book of Tools and Techniques | |
Tsui | Managing software projects | |
Howard et al. | UX Lifecycle: The Business Guide to Implementing Effective Software User Experiences | |
Korhonen | Supporting agile transformation with defect management in large distributed software development organisation | |
Koirala et al. | Software Testing: Interview Questions | |
Newell | Mastering Microsoft Dynamics 365 Implementations | |
Morris et al. | ITIL Intermediate Certification Companion Study Guide: Intermediate ITIL Service Lifecycle Exams | |
Donyaee | Towards an integrated model for specifying and measuring quality in use | |
Michel | Using an Accessibility Maturity Model to Facilitate the Inclusion of Accessibility in Design Practices | |
Oliveiraa et al. | Conciliating XBRL Financial Reporting and HCI | |
Zhang et al. | Applying six sigma in software companies for process improvement | |
Paulen et al. | Pro SQL Server 2008 Analytics: Delivering Sales and Marketing Dashboards | |
Webber et al. | It Governance: Policies and Procedures | |
Alshehri | Ahp-based methodology for a complex decision support in extreme programming | |
Vidal | Fail to Plan, Plan to Fail: How to Create Your School’s Education Technology Strategic Plan | |
Tinnirello | Systems development handbook | |
PMP | The business analyst as strategist: Translating business strategies into valuable solutions | |
Kaveh | A framework of the use of information in software testing | |
Macro | Evaluation of state-based integrated health information systems | |
QuantumPM | Microsoft Office Project Server 2007 Unleashed |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: PROCESS ASSEST, LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OLSON, TIMOTHY G.;REEL/FRAME:029966/0987 Effective date: 20130212 |
|
AS | Assignment |
Owner name: PROCESS ASSETS, LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OLSON, TIMOTHY G.;REEL/FRAME:029997/0738 Effective date: 20130212 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |