2.100.2 Integrated Process Management Standardization Process 2.100.2.1 Program Scope and Objectives 2.100.2.2 Introduction 2.100.2.2.1 Administration 2.100.2.2.2 Process Description 2.100.2.2.3 Objectives 2.100.2.2.4 Process Hierarchy 2.100.2.2.5 Process Classification 2.100.2.2.6 Workflow 2.100.2.2.6.1 Main Process Diagram 2.100.2.2.6.2 Inputs 2.100.2.2.6.3 Outputs 2.100.2.2.6.4 Activities 2.100.2.2.6.5 Roles 2.100.2.2.6.6 Procedure 2.100.2.2.6.6.1 IPM 1.0: Establish the Policy 2.100.2.2.6.6.1.1 Cross-Functional Flow Diagram 2.100.2.2.6.6.2 IPM 2.0: Design and Model the Process 2.100.2.2.6.6.2.1 Cross-Functional Flow Diagram 2.100.2.2.6.6.3 IPM 3.0: Document the Process 2.100.2.2.6.6.3.1 Cross-Functional Flow Diagram 2.100.2.2.6.6.4 IPM 4.0: Finalize and Approve the Process 2.100.2.2.6.6.4.1 Cross-Functional Flow Diagram 2.100.2.2.7 Process Control 2.100.2.2.7.1 Controls 2.100.2.2.7.2 Metrics 2.100.2.2.7.3 Policies 2.100.2.2.7.4 Tailoring Guidelines 2.100.2.2.8 Training 2.100.2.2.9 Exhibits 2.100.2.2.9.1 Exhibits 2.100.2.2.9.2 Glossary 2.100.2.2.9.3 BPMN Standard Elements Part 2. Information Technology Chapter 100. Integrated Process Management Section 2. Integrated Process Management Standardization Process 2.100.2 Integrated Process Management Standardization Process Manual Transmittal October 07, 2019 Purpose (1) This transmits revised IRM 2.100.2 Integrated Process Management (IPM), Standardization Process. Material Changes (1) This IRM has been updated to include the required Internal Controls. Effect on Other Documents IRM 2.100.2 dated January 31, 2017 is superseded. Audience The Integrated Process Management (IPM) Process is applicable to all information Technology (IT) organizations, contractors, and other stakeholders having responsibility for developing IT business processes. Effective Date (10-07-2019) Nancy A. Sieger Chief Information Officer, Information Technology 2.100.2.1 (10-07-2019) Program Scope and Objectives Overview - A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes. Purpose - This document serves as the process for the Integrated Process Management (IPM) program. This program will support the Capability Maturity Model Integration (CMMI), Information Technology Infrastructure Library (ITIL), Project Management Institute (PMI), and other process framework, model, and life cycle effort for the IT organization. Audience - This Process applies to all IT process owners establishing new or revised processes. Policy Owner - The Enterprise Operations (EOPs) Associate Chief Information Officer (ACIO) is the policy owner. Program Owner - The Demand Management and Project Governance (DMPG) Director is the policy owner. Primary Stakeholders - This Process applies to all IT process owners establishing new or revised processes. Program Goals - The goal of IPM is to enable a consistent and integrated approach to process implementation and execution across the IT organization. 2.100.2.2 (11-30-2016) Introduction This document describes the formal process for implementing the requirements of the Integrated Process Management (IPM) process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome. 2.100.2.2.1 (11-30-2016) Administration All proposed changes to this document must be submitted in writing, with supporting rationale, to the Demand Management and Project Governance Division, Enterprise Operations. 2.100.2.2.2 (10-07-2019) Process Description The Integrated Process Management (IPM) is the process for identification of the IT organization’s set of standard processes, establishing documentation standards, and institutionalizing the standard processes through the Internal Revenue Manual (IRM) process. 2.100.2.2.3 (10-07-2019) Objectives Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process: Institutionalize process standards and best practices, called Standardization, in order to enable IT capabilities to be successfully delivered within well-understood time, cost, scope, and quality constraints. Provide a centralized repository, called the IT Process Asset Library (IT PAL), to provide transparency and reuse of enterprise-wide IT process standards and best practices. Provide an enterprise view of an integrated process lifecycle, called Integrated Process Architecture, in order to enhance IT efficiency, customer service focus, and enable process improvements that will benefit project and service delivery. 2.100.2.2.4 (10-07-2019) Process Hierarchy The process hierarchy is derived from the International Business Machines’ Line of Visibility Enterprise Management model. It consists mainly of a policy or directive, process, and procedure. The directive is the formal and mandatory order or official pronouncement on a policy that establishes the organizational expectations and defines the process and procedures that will support it. The policy may consist of one or more processes facilitated by process areas, and its process characteristics are defined by its process description which may include one or more procedures for determining whether its provisions have been satisfied. The process hierarchy provides the framework, structure, and relationship between the process and its process assets. An example of a process hierarchy is illustrated in Figure 2-1a Simplified View of Process Hierarchy and Figure 2-1b, Complex View of Process Hierarchy. Figure 2.100.2-1a Simplified View of Process HierarchySimplified View of Process Hierarchy Please click here for the text description of the image. Figure 2.100.2-1b Complex View of Process HierarchyComplex View of Process Hierarchy Please click here for the text description of the image. 2.100.2.2.5 (10-07-2019) Process Classification This section describes the four (4) types of processes for classifying IT processes. The IPM Process classification is used for determining what is in-scope and includes the following: Core Process - Critical to the mission of the organization Tailored Process - Core process adapted to fit the need of the organization Cross-functional Process - Non-Core/Non-tailored process with cross-functional impact Local Process - Non-core/Non-Tailored process with impact isolated to the functional area Core or enterprise processes are sanctioned by the Chief Information Officer to establish and deploy the IT organization set of standard processes. These are processed through the IPM for standardization, centralization, and integration and facilitated through the IRM for institutionalization and application across the IT organization. The majority of the core processes align with industry standards such as (CMMI), (ITIL), and other processes institutionalized in the industry. Directives, process descriptions, and procedures are required for core processes. Tailored processes are modified versions of the core processes and require approval by the enterprise process owner in order to maintain the defined organizational process requirements and standards for the IT organization. Tailored processes are defined for specific process application within the local ACIO organization. Directives and process descriptions for tailored processes are defined under the core processes. Cross-functional processes are owned by another IRS business unit and support the operational needs of the business organization. Process descriptions are not required, but are highly encouraged for those that impact other IT organizations. Directives are not required since the IRS business unit owns the process. Local processes are functional procedures and are synonymous with standard operating procedures. Local processes are used to manage the technical and operational environment in the IT organization and are specifically applicable for each ACIO. Directives and process descriptions are not required for local processes. The table below, Types of Process Assets by Process Classification illustrates the types of process assets by process classification. Types of Process Assets by Process Classification Types of Process Assets Core Tailored/Defined Cross-Functional Local IRM Yes No No No Policy or Directive Yes No No No Process Description Yes No Optional No Procedure Yes Yes Yes Yes 2.100.2.2.6 (11-30-2016) Workflow A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process. 2.100.2.2.6.1 (01-31-2017) Main Process Diagram Main Process Diagram Figure 2.100.2-2 Main Process Diagram Please click here for the text description of the image. 2.100.2.2.6.2 (11-30-2016) Inputs Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process: Name Description Supplier Technology New technologies that are not covered by existing policies. Senior Leadership Laws or regulations New laws or regulations that are not covered by existing policies. Senior Leadership Operational New operational requirements that are not covered by existing policies. Senior Leadership Compliance New compliance requirements that are not covered by existing policies. Senior Leadership 2.100.2.2.6.3 (11-30-2016) Outputs Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality. Name Description Recipient Directive Establishes the policy and mandates for the process. ACIO Process Description Establishes the process workflow, inputs and outputs, process activities, and process control for the process. Director Procedure Establishes the roles, responsibilities, and tasks for each activity in the process. Director 2.100.2.2.6.4 (11-30-2016) Activities An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. ID Name Description IPM 1.0 Establish the Policy Defines the process and its mandates. IPM 2.0 Design and Model the Process Defines the process workflow using Business Process Modeling Notation (BPMN) standards, including inter- process dependencies, and key inputs that trigger the process to begin when defining the Process Description (PD). This same approach is used in defining the Procedure with the exception of swim lanes are used to assign roles and responsibilities to the tasks for each process activity. IPM 3.0 Document the Process Documents the process activities through its workflows including key inputs, outputs, and roles in the Process Description. This same approach is used for defining the tasks for each activity and assigning the roles using the RACI model in the Procedure (PR). IPM 4.0 Finalize and Publish the Process Defines the steps required to finalize and approve the process, including IPM Compliance Review and Section 508 Compliance. 2.100.2.2.6.5 (11-30-2016) Roles Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time. Name Description Process Owner Person who is held accountable for ensuring that a process is fit for purpose. Responsible for Sponsorship, design, change management, and continual improvement of the process and its metrics. Defines process strategy. Defines process policies and standards. Ensures process is documented. Audits the process. Ensures process resources available during lifecycle. Ensures proper process relevant communication. Reviews improvement opportunities. This role is assigned to both the ACIO, for all the core processes in their ACIO organization, and the Directo,r for a particular core process. Process Manager Person accountable for the operational management of the process. Plans and coordinates all process activities required to carry out, monitor, and report on the process. Assigns staff to required roles. Manages process performance. Works with Continual Service Improvement (CSI) Manager: Reviews improvements Prioritizes improvements This role is assigned to a senior manager. Author Develops and maintains the process documentation for the Process Owner and Process Manager. IPM Analyst Provides coaching and facilitation of the IPM process. Conducts review of core process documentation for compliance with IPM standards. 2.100.2.2.6.6 (11-30-2016) Procedure Procedure 2.100.2.2.6.6.1 (11-30-2016) IPM 1.0: Establish the Policy Establish the Policy ID Task Name and Description Role RACI Duties IPM 1.1 Define policy requirements and mandates A new or change in policy has been determined by senior leadership. Identify or update the process(es) that will support the policy. The process must identify with existing industry defined process(es) and leverage from the standard best practices. Process Manager Process Manager Author R R I Obtain organizational policy mandates from Process Owner. Identify process(es) that will support the policy. Prepare for documenting the policy. IPM 1.2 Document the policy The purpose of this task is to document the policy using the IPM Directive (DIR) template or the IT IRM Policy template if proceeding directly through the IRM process. Author Author Author R R R Review the IT Process List located in the IT PAL to ensure that the process has not already been defined. If not, research and obtain a copy of the process (CMMI, ITIL, PMI, etc.) that will support the policy. Obtain latest copy of the IPM DIR template or the IT IRM Policy template in the IT PAL. Document the policy using the appropriate template. Follow instructions for completing the template. IPM 1.3 Review the policy The purpose of this task is to review the policy mandate and its contents to ensure that the goal and objective of the policy has been addressed. Process Manager Author R I Review and update the policy as needed and provide concurrence to the Author. Obtains concurrence from the Process Manager and proceeds to Activity 2: Design and Model the Process. 2.100.2.2.6.6.1.1 (01-31-2017) Cross-Functional Flow Diagram Cross-Functional Flow Diagram Figure 2.100.2-3 Cross-Functional Flow Diagram Please click here for the text description of the image. 2.100.2.2.6.6.2 (11-30-2016) IPM 2.0: Design and Model the Process Design and Model the Process ID Task Name and Description Role RACI Duties IPM 2.1 Define the scope of the process The purpose of this task is to define the scope of the process and ensure that the process has scope and boundary so that its activities are not redundant with other processes. If there is an industry equivalent, recommendation is to use the industry process equivalent (e.g., CMMI, ITIL, PMI) as the source to define the scope. Author Author R R If industry equivalent, review the goal, objective, and process description of the process available from the source to define the scope of the process(es). If no industry equivalent, define the goal, objective, and process description based on the policy to define the scope of the process(es). IPM 2.2 Define the primary activities of the process The purpose of this task is to define the primary activities of the process. The preference is to use the industry defined process activities in lieu of redefining them. Author Author R R If industry equivalent, review and apply the defined activities or specific practices for the process. If no industry equivalent, define the activities based on the following considerations: Use words that are understandable to everyone. With a Verb-to-Noun convention, be brief (e.g. Submit Change Request). Assign activity numbers based on the sequence flow of the process. Recommended number of activities should be limited between 4 to 7 primary activities in order to control the detail. IPM 2.3 Identify process interfaces The purpose of this task is to identify the external- or inter- process interfaces for each process activity, and identifying whether they are inputs or outputs to the process. Author Author R R If industry equivalent, review and identify the recommended process interfaces that are applicable to the existing IRS IT environment. If no industry equivalent, review, identify, and validate process interfaces with IRS IT processes. Use the IT Business Process List to identify the IRS IT processes. IPM 2.4 Define process model The purpose of this task is to create the process flow diagram using BPMN to graphically represent the process model. Note: See Exhibit C for the most common BPMN standard symbols. Author R Create a process flow diagram based on the sequence of the activities and use the appropriate BPMN symbols for the type of object (i.e., event, activity, gateway, and external process) and use connecting arrows to show the sequence flow from one object to another object. IPM 2.5 Test and validate the process model The purpose of this task is to test and validate the process model for accuracy and completeness. Note: This activity is repeated (from IPM 2.2 thru IPM 2.5) for defining and developing the Procedure diagram. Each process activity will need to define more than one task and assign process role(s) for each task. A swim lane diagram is used to graphically represent and distinguish the roles and responsibilities for each activity in the process. Author R Review, test, and validate the process model based on the flow and sequence of the activities, BPMN standards, and process interfaces: Ensure the symbols are used correctly. Ensure the process activities (inputs, outputs, actions, decisions) are identified clearly and correctly. Make sure every feedback loop is closed, i.e., every path takes you either back to or ahead to another activity. Ensure that each activity box has one output arrow. If there is more than one arrow, you may need a decision diamond or gateway. Validate the process flow against the requirements. Validate interfaces with external process(es). Ensure that there are no more than 7 activity boxes for each process. If so, collapse or combine some of the activities together. Reduce or eliminate obvious complexities or redundancies. 2.100.2.2.6.6.2.1 (01-31-2017) Cross-Functional Flow Diagram Cross-Functional Flow Diagram Figure 2.100.2-4 Cross-Functional Flow Diagram Please click here for the text description of the image. 2.100.2.2.6.6.3 (11-30-2016) IPM 3.0: Document the Process Document the Process ID Task Name and Description Role RACI Duties IPM 3.1 Document the process The purpose of this task is to document the process using the process model. Note: For Simple Process (i.e., one Process with one Procedure) use the IPM Process Section template which combines the IPM PD and PR templates). For Complex Process (i.e., one Process with multiple Procedures or multiple Processes with multiple Procedures) use the IPM PD and PR templates. If directly proceeding through the IRM to document the process and procedure, use the IT IRM Process Section template. Author Author R R Obtain latest copy of the appropriate IPM template(s) based on the type of process (simple or complex) or if proceeding directly through the IRM. The templates are located in the IT PAL.Link for Templates Document the process using the appropriate template. Follow instructions for completing the template. IPM 3.2 Review and validate the process The purpose of the this task is to review and validate the process contents against the process model and key elements of the process. Author R Review and validate the process contents against the following: Process activities defined correspond with the process diagram. Process roles defined correspond with both the diagram and the document content (e.g. no new roles should be defined outside of the Roles section, and only roles with “R” in the Procedure section should be defined in the swim lane diagram). All key process elements (Input, Output, Roles, etc.) are completed. 2.100.2.2.6.6.3.1 (01-31-2017) Cross-Functional Flow Diagram Cross-Functional Flow Diagram Figure 2.100.2-5 Cross-Functional Flow Diagram Please click here for the text description of the image. 2.100.2.2.6.6.4 (11-30-2016) IPM 4.0: Finalize and Approve the Process Finalize and Approve the Process ID Task Name and Description Role RACI Duties IPM 4.1 Submit the process for review The purpose of this task is to submit for IPM completeness and compliance review of the completed or revised DIR, PD, and PR, or the IT IRM Policy and IT IRM Process Section. Author R Prepare and submit the DIR, PD, and PR, or the IT IRM Policy and IT IRM Process Section to the *IT.IPMO@irs.govLink to mailbox mailbox for IPM Compliance Review. IPM 4.2 Conduct completeness and compliance review The purpose of this task is to review for IPM completeness and compliance against the established requirements in the IPM Standardization process. Note: IPM response will be provided to the author within 10 - business days upon receipt of the request. IPM Analyst Author Author R I I Conduct review for completeness and compliance against IPM requirements. If corrective actions are identified, a response will be returned to the author to update the process documents. Follow-up within 10 business days to the author for the status until the corrective actions are closed. If no corrective actions are identified or all corrective actions have been satisfied, a response to proceed to the IT PAL or IRM will be returned to the author. IPM 4.3 Finalize and approve the process The purpose of this task is to finalize the process and proceed for signature approval. Note: Use the IRM 1.11.9 Internal Management Documents, Clearing and Approving Internal Management Documents (IMDs) for this step if the IRM path was taken. Note: Process documents (Directive, Process Section, Process Description, and/or Procedure) that are posted to the IT PAL must be converted to the IRM. There will be no revisions to process documents in the IT PAL but only through the IRM. Author Author Author Author Author R R R R R Prepare the process documents for Section 508 compliance standards. Submit the DIR to the ACIO for signature. Submit the PD and PR to the Director for signature. Submit the final and approved documents to the IT PAL using the *IT.PAL@irs.govLink to mailbox mailbox for posting to the IT PAL repository. Convert to IRM once the process documents are posted in the IT PAL. 2.100.2.2.6.6.4.1 (01-31-2017) Cross-Functional Flow Diagram Cross-Functional Flow Diagram Figure 2.100.2-6 Cross-Functional Flow Diagram Please click here for the text description of the image. 2.100.2.2.7 (11-30-2016) Process Control Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance. 2.100.2.2.7.1 (03-27-2014) Controls Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate. Name Description IPM Policy All enterprise or core processes must comply with IPM requirements. All enterprise or core processes must be published in the IRM. All enterprise or core processes must be revised in the IRM. IPM Compliance Review Review and ensure compliance against the IPM defined process templates. 2.100.2.2.7.2 (11-30-2016) Metrics Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the IPM process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL. 2.100.2.2.7.3 (11-30-2016) Policies Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals. Process Management Statement: The IPM process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on Return on Investment to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data. People Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process. Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding IPM will not be successful. Process Statement: Modifications to the IPM process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand. Rationale: The process must meet operational and business requirements. Technology and Tools Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following: None Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves. 2.100.2.2.7.4 (11-30-2016) Tailoring Guidelines The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the IPM owner. 2.100.2.2.8 (11-30-2016) Training Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. The training resources listed below are available for this process: ELMS Course # 60618, Driving Standards with Integrated Process Management 2.100.2.2.9 (11-30-2016) Exhibits Exhibits 2.100.2.2.9.1 (11-30-2016) Exhibits Acronyms Acronyms Definition ACIO Associate Chief Information Office BPMN Business Process Modeling Notation DIR Directive IPM Integrated Process Management IRM Internal Revenue Manual IRS Internal Revenue Service IT Information Technology IT PAL Information Technology Process Asset Library PD Process Description PR Procedure RACI Responsible, Accountable, Consulted and Informed 2.100.2.2.9.2 (11-30-2016) Glossary Glossary Activity Measurable amount of work performed to convert inputs into outputs. Process A collection of related, structured activities or tasks that produce a specific service or product for a customer or customers. Business Process Modeling Notation A graphical notation for expressing business processes in business process diagrams. Directive Formal and mandatory order or official pronouncement on a policy, process, or procedure that establishes organizational expectations. Internal Revenue Manual Primary official source of IRS “instructions to staff” relating to the organization, administration, and operation of the Service. See IRM 1.11.1.2.1. Procedure A written description of a course of action to be taken to perform a given task. A procedure contains how-to, step-by-step information, and comes with various types of implementation assets such as forms, checklists, step/action tables, and tools for facilitating or automating procedure activities. Process Asset Anything an organization considers useful in attaining the goals of a process area and relates to describing, implementing, and improving a process. This includes procedure assets. Examples include policies, measurement descriptions, process descriptions, implementation tools (i.e., templates, checklists, plans, training materials, and procedures). Process Asset Library A library of information used to store, and make available, process assets that are useful to those who define, implement, and manage processes in an organization Process Description A documented expression of a set of activities performed to achieve a given purpose and provides an operational definition of the major components of a process. Practitioner Those that have assigned roles and responsibilities in the process to perform. Standard A formal requirement created and prescribed in order to provide a consistent approach to service or development. Task Work to be done or a piece of work to be undertaken. 2.100.2.2.9.3 (01-31-2017) BPMN Standard Elements Core Set of BPMN Elements Figure 2.100.2-7 Core Set of BPMN Elements Please click here for the text description of the image. More Internal Revenue Manual
