IBM web spehere en ingles

IBM WebSphere Lombardi Edition V7.1 Process Modeling (Course code WB001/VB001)

Student Notebook ERC 1.1

IBM WebSphere Lombardi Education

Trademarks IBM® and the IBM logo are registered trademark of International Business Machines Corporation. The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both: BlueprintTM

WebSphere®

Lombardi®

JavaScript, and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

August 2010 edition The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. © Copyright International Business Machines Corporation 2010. This document may not be reproduced in whole or in part without the prior written permission of IBM. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents Introduction

7

Course Overview Course Goal

. . . . . . . . . . . . . . . 7

. . . . . . . . . . . . . . . . . 8

Course Objectives . . . . . . . . . . . . . . . 8 Course Materials. . . . . . . . . . . . . . . . 8 Technical Support . . . . . . . . . . . . . . . 9 Other Resources. . . . . . . . . . . . . . . . 9 Prologue: The Foundation for Process Modeling

11

Objectives and Topics . . . . . . . . . . . . . . 11 Business Process Management . . . . . . . . . . 12 BPM Vision . . . . . . . . . . . . . . . . 12 The BPM Project . . . . . . . . . . . . . . 13 BPM Project Components . . . . . . . . . . 13 BPM Project Team Members . . . . . . . . . 14 About Process Modeling

. . . . . . . . . . . . 15

Business Process . . . . . . . . . . . . . 15 IBM BPM Blueprint and WebSphere Lombardi Edition How do they fit in Process Modeling?

16

. . . . . 16

How do they fit in BPM Project Methodologies? . 17 The Hiring Requisition Project . . . . . . . . . . . 18 Core Requirements . . . . . . . . . . . . . 18 Challenge Requirements . . . . . . . . . . . 20

Lombardi Process Modeling iii

Unit 1: Playback 0 - Process Discovery

23

Objectives and Topics . . . . . . . . . . . . . . 23 About Process Discovery

. . . . . . . . . . . . 24

Collaboration . . . . . . . . . . . . . . . 24 Why IBM BPM Blueprint . . . . . . . . . . . . . 26 Creating a Discovery Map . . . . . . . . . . . . 28 Discovery Map Elements and BPMN . . . . . . 29 Milestone

. . . . . . . . . . . . . . . . 30

Activity. . . . . . . . . . . . . . . . . . 32 Sub-process. . . . . . . . . . . . . . . . 36 Modifying the Discovery Map . . . . . . . . . 38 Exercise 1.1 Creating a Discovery Map . . . . . 44 Capturing the Process Details

. . . . . . . . . . 46

Exercise 1.2 Capturing the Process Details

. . . 58

The Conceptual Data Model . . . . . . . . . . . 60 When do I move from a Discovery Map to a Process Diagram? . . . . . . . . . . . . . . . . . . 64 Unit 2: Playback 0 - Process Diagram

67

Objectives and Topics . . . . . . . . . . . . . . 67 IBM BPM Blueprint Process Diagram

. . . . . . . 68

About BPMN . . . . . . . . . . . . . . . 68 Core Elements

. . . . . . . . . . . . . . 68

Create a Process Diagram in Blueprint . . . . . 69 Exercise 2.1 Creating a Process Diagram . . . . 72 When do you migrate from Blueprint to Lombardi? . . 74 About WebSphere Lombardi Edition . . . . . . . . 75 Lombardi Authoring Environment . . . . . . . 76 The Process Center . . . . . . . . . . . . . 76 Designer . . . . . . . . . . . . . . . . . 77 Exercise 2.2 Subscribing to a Blueprint Process

iv

Table of Contents

. 78

Unit 3: Playback 1, Part 1 - Process Flow

81

Objectives and Topics . . . . . . . . . . . . . . 81 About Process Flow

. . . . . . . . . . . . . . 82

Normal Sequence Flow . . . . . . . . . . . 82 Conditional Sequence Flow. . . . . . . . . . 83 Default Sequence Flow . . . . . . . . . . . 84 About Tokens . . . . . . . . . . . . . . . . . 85 About Gateways . . . . . . . . . . . . . . . . 88 Exclusive Gateway (X/OR) . . . . . . . . . . 89 Inclusive Gateway (AND/OR) . . . . . . . . . 90 Parallel Gateway (AND) . . . . . . . . . . . 91 Splits and Joins . . . . . . . . . . . . . . 92 Using Gateway Splits and Joins . . . . . . . . 93 Evaluating Conditions . . . . . . . . . . . . 94 Exercise 3.1 Adding Gateways . . . . . . . . 96 Unit 4: Playback 1, Part 2 - Intermediate Events

99

Objectives and Topics . . . . . . . . . . . . . . 99 Intermediate Events . . . . . . . . . . . . . 100 A Way to Model an Escalation . . . . . . . . . . 102 Intermediate Timer Events . . . . . . . . . 102 Intermediate Timer Event Implementation . . . 103 Exercise 4.1 Adding Intermediate Timer Events

104

Unit 5: Playback 1, Part 3 - Validate the Process Model

107

Objectives and Topics . . . . . . . . . . . . . 107 The Process Inspector

. . . . . . . . . . . . 108

Exercise 5.1 Validating the Process Model . . . Appendix: Challenge Exercises

110 113

Lombardi Process Modeling v

IBM WEBSPHERE LOMBARDI EDUCATION

Introduction

Course Overview The IBM WebSphere Lombardi Edition 7.1 Process Modeling course teaches the basics of process modeling. Concepts are presented in a systematic way, building upon each other to facilitate a good understanding of process modeling. We begin by creating a Descriptive Model of the process. This starts with mapping the expected process flow, or happy path, which includes the identification and capture of the process milestones, activities, the participants in those activities, and the normal order in which activities are performed. We move to a more detailed model to allow for analyzing the process performance and capturing business and functional requirements for an IT implementation. This effort includes adding process decision flow and intermediate event patterns. Hands-on exercises demonstrate the application of these concepts in a real life process scenario. The inclusion of practical tips and techniques further enhance the learning process. The key take-away is knowing how to create process models that stand on their own - models that are clear and complete from the diagram alone and that can ultimately be used as an executable Business Process Definition (BPD) in IBM WebSphere Lombardi Edition (Lombardi).

Lombardi Process Modeling

7


COURSE GOAL

COURSE OBJECTIVES

COURSE MATERIALS

8

Introduction

Model a business process using IBM Blueprint and IBM WebSphere Lombardi Edition

After completing this course, you should be able to: •

Perform process discovery mapping and detail capture in IBM Blueprint

•

Capture key business data requirements in the context of the process participant interactions

•

Create a process diagram using IBM Blueprint

•

Control the process flow using Gateways in IBM WebSphere Lombardi Edition

•

Use an Intermediate Timer Event to ensure process deadlines are met

•

Validate the process model meets all business and functional requirements and is ready for implementation

The materials created for this course are supplements for training, including lecture, and class activities: •

Student Notebook

•

Class Activity and Individual Exercise Environments •

IBM BPM Blueprint

•

IBM WebSphere Lombardi Edition


TECHNICAL SUPPORT

IBM BPM Blueprint •

Process Mapping 101 Self-Paced Online Course

•

Performance Support Tutorials - Blueprint Help System

•

Product Blog

•

User/Developer Forums

IBM WebSphere Lombardi Edition (Lombardi)

OTHER RESOURCES

•

WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide

•

Business Process Modeling Notation Specification 1.2

•

Email Questions about Websphere Lombardi Training, upcoming courses, or course materials to [email protected]

•

Technical questions can be directed to Support by visiting http://www-947.ibm.com/support/entry/portal/


9


Prologue:The Foundation for Process Modeling

Organizations seeking to improve their business processes will turn to Business Process Management (BPM) to provide a systematic approach to accomplish this improvement. BPM initiatives gain momentum from early adoption to designation of first critical or first launch projects. Regardless of the project, big or small, it all begins with a Process Model. A clear model that communicates the process and where improvements can be achieved is the key to maintaining the initial executive level momentum. A good Process Model thus aligns the interest of the business and the execution of the IT groups.

Objectives The objectives for this section are to: •

Describe Business Process Management (BPM)

•

List the components of a BPM project

•

List and describe BPM Project Team members

•

List and describe the Process Modeling phases

•

Describe how IBM BPM Blueprint fits in Process Modeling

•

Describe how WebSphere Lombardi Edition fits in Process Modeling

Topics This section includes the following topics: •

Business Process Management

•

About Process Modeling

•

IBM BPM Blueprint and WebSphere Lombardi Edition

•

A Process Narrative: The Hiring Requisition Project


11


Business Process Management Business Process Management (BPM) is described in a variety of ways by many different sources, but the common themes throughout are the goal, the system, and the expected results. •

The BPM goal is efficient business processes with visibility.

•

The BPM system is the management of people-to-people work steps, system-to-system communications, or person-tosystem interactions.

•

The BPM expected result is process improvement. Business process improvement brings about multiple benefits to an organization.

BPM Vision Does BPM have or even require a vision? If the ideal were to match the proper toolset with the stated goal, system, and expected result, then the vision might be limited to the execution of a process application build. This would also impact what a Process Model might look like and what it would communicate to a process application development team. What if a broader vision for BPM were the following: “BPM is the means by which companies and governments improve their operations by leveraging internal business expertise in new, scalable ways. This is achieved by directly engaging business people in the design, definition and creation of enterprise-class process applications.” NOTES

12

Prologue: The Foundation for Process Modeling


The BPM Project Project lifecycles for any IT initiative are typically reinforced by well established standards and methodologies. A BPM project, especially one that includes the broader vision and definitions provided, would not fit the typical project lifecycle because the key BPM project components are slightly different. BPM Project Components

The top-down diagram view of the BPM components provides a quick view of how a typical BPM project lifecycle will evolve. Any of these components missing from a project would interrupt the effective design, definition, and creation of the process application, and perhaps curtail the engagement of business people.


13


BPM Project Team Members The unique lifecycle and components of a BPM project require a specific set of project roles, including:

14

•

Process Sponsor - Responsible for establishing the project goals and scope, securing organizational support and resources, and ensuring alignment with organizational business goals

•

Process Owner - Person who knows everything about the process

•

Program Manager/Project Lead - Person responsible for the project’s success

•

Subject Matter Experts - Those with knowledge of specific process resources, or systems

•

Core BPM Project Development Team - Business Process Management (BPM) development teams typically include a BPM Analyst, BPM Developer - Process, BPM Developer Integrations, and a BPMS Administrator

•

Facilitator - (Optional) Typically manages the collaboration meetings for a BPM Team.



About Process Modeling An understanding of a business process is necessary before it can be modeled. Business Process A business process is a repeating set of coordinated tasks or activities and transactions used to achieve organizational objectives. Process Modeling captures the ordered sequence of these tasks or activities, the roles performing the activities, conditional branching, and the sequencing of the flow of work between activities along with the supporting information from start to end.

Descriptive Modeling Analytical Modeling Executable Modeling

Process Modeling can be described as a three phase approach: •

Describe the process - High-level description of the process easily communicated across the organization

•

Analyze/Improve the process - Analytical, more detailed modeling, showing all pertinent activities and flow including exception paths. Used to create detailed functional requirements for the process

•

Implement the process - The executable process implementation Lombardi Process Modeling

15


IBM BPM Blueprint and WebSphere Lombardi Edition With a vision in place to launch a BPM project, the next task would be to find the right toolset not only to build the process application, but to maintain the project lifecycle synergy between business and IT when it comes to Process Modeling. How do IBM BPM Blueprint and WebSphere Lombardi Edition fit in Process Modeling? IBM BPM Blueprint (Blueprint) and WebSphere Lombardi Edition (Lombardi) offer the ability to efficiently handle each component of a BPM project and the three phases of Process Modeling. They also provide built-in functionality to involve business people throughout the modeling phases, whether it is through direct collaboration or effective model validation meetings, called “playbacks”, that are part of the functional charter for both tools.

KEY INFORMATION

16

•

It is very important to note that both tools do not have a clear demarcation where one stops and the other begins in terms of the lifecyle of project. That varies from project to project. However, both work well together to engage business people early and often while still offering sophistication for robust process application implementations.



How do IBM BPM Blueprint and WebSphere Lombardi Edition fit in BPM Project Development Methodologies? While BPM development strategies and methods vary from the standard IT development strategies and methods, some BPM toolsets are more closely aligned with the latter. Blueprint and Lombardi incorporate features and functionality that will make support use of unique and effective methodologies that increase development success factors. Here is a quick snapshot of three methods and approaches:

NOTES

•

Shared Model Approach - WebSphere Lombardi Edition uses a single shared environment for design and development. All process artifacts are stored in a single shared model architecture.

•

Iterative Approach - a development method where a process application is created through discreet development sections and repeatedly elaborated until the application reaches maturity. WebSphere Lombardi Edition supports a fully iterative development approach aligned with best practices for BPM development.

•

Playbacks - the built-in WebSphere Lombardi Edition “playback” functionality encourages IT and Business to collaborate and share feedback on the process application much more frequently during development. A playback between business and IT is a focused demonstration of a partially implemented process model with the goal of discussion, consensus bulding, collaborative improvement, and ultimately approval of the model. Playbacks thus enable the iterative development of the process application. Obviously the BPM team will want to reach milestone deliveries in the development of the process application to know when to move on, so Playback 0 through 3 designate the sign-off phases for the development lifecycle.


17


The Hiring Requisition Project The following process narrative is an example of what a BPM team might develop in collaboration with a process owner. It is provided here as the foundation for the Process Modeling effort needed for the Hiring Requisition Project.

Process Narrative Core Requirements A Hiring Manager will submit a hiring requisition to the HR Department containing the following information: General Details • Requisition Number • Date of request • Requestor • Date Position Available Position Details • Job Title • Job Description • Job Level (from company database) • Number of direct reports (only display if the job level requested is Technical Lead or above) Department Details • Division (from company database) • Department (from company database) Compensation Details • Salary to Offer • Bonus Amount (default to 10% of salary to offer, but in no case shall exceed 50%) Recruiting Details • Multiple Employees Needed? (Y/N) • Number of Employees Needed (only display if multiple employees are needed) • New Position? (Y/N) Hiring Manager Comments

18



Core Requirements 2.1 If the answer to “New Position” is YES, the request shall be forwarded to the appropriate General Manager based on the values specified under Division. Once the General Manager receives the request, they will indicate approval or disapproval. 2.2 If the request is not approved, the General Manager should specify a reason and the request is terminated. If the request is approved, a salary compliance check should be performed. 2.3 The Hiring Manger should be notified of the GM’s decision before the process is ended. 2.4 An automated check for salary compliance should be performed. If the request meets salary compliance the hiring request should be automatically posted to the HR Positions database and made available for dissemination. 2.5 When a request violates the company’s established salary guidelines, the HR Administrator can approve or reject the requested salary override. 2.6 If the requested salary is approved, the request should be posted to the HR Positions database and made available for dissemination. 2.7 If the HR Administrator rejects the requested salary they must provide comments regarding the violation, add a proposed salary, and send the request back to the originator for resubmission or cancellation. 2.8 The HR Administrator has 4 hours to complete the review. If the review is not completed within 4 hours, the task priority shall be changed to Urgent and an email shall be sent to the HR Administrator notifying them of the missed deadline. 2.9 When the Hiring Manager gets the request back because of a rejection, they have the option to attempt to negotiate an adjusted salary or they can cancel the request. 2.10 All hiring requests must be added to the HR Positions database regardless of the disposition. 2.11 This process can be started from hiring requests received from external Hiring Manager resources. Lombardi Process Modeling

19


Challenge Requirements Hiring Request 3.1 The Hiring Manager must complete all information on the Hiring Request form. Please do not display the form with any excess required field styling. Validation should be transparent to the end user. 3.2 In the General Details section, add the following automatic functions: •

Requisition Number (Auto-generated)

•

Date of request (Automatic date/time stamp)

•

Requestor (Automatic user name stamp)

3.3 If the answer to New Position is NO, the following information must be provided: Who is being replaced? •

Name

•

Status (drop down - Full Time, Part-Time, Contractor, Temp)

•

Manager

•

Job Level

•

Pay Type (drop down – Hourly, Salary)

•

Notes

This information should only be displayed if the answer to New Position is NO. HR Administrator Salary Override Review 3.4 The HR Administrator should be able to retrieve a list of current positions in the Positions database that match the current request. This will provide the HR Administrator with a salary comparison. This is optional and by request of the HR Administrator, it should not automatically appear. The list of Positions should appear in a pop-up window. 3.5 If the HR Administrator does not complete the review within 8 business hours, the review should be reassigned to another HR Administrator.

20



Salary Negotiation 4.1 If the salary to offer is changed by the HR Administrator, the original salary offer must be preserved. Additionally, the name of the HR Administrator who made the change should appear next to each proposed salary change. Each time a new salary is proposed, this list should be updated. 4.2 The HR Administrator or the Hiring Manager should be able to select from this list if they want to revert to a previously suggested salary. Selecting from this list should populate the “Salary to Offer” field. 4.3 If the Hiring Manager wants to attempt to renegotiate the salary offer, they should provide a proposed salary and a new override justification. 4.4 Each time the proposed salary, signing bonus, Hiring Manager salary override reason, and HR rejection reason is changed; the original information should be added to lists that are available during the negotiation phase. 4.5 The Signing Bonus must behave the same way. 4.6 A total of three attempts by the Hiring Manager to negotiate a salary override are allowed. After the third attempt to negotiate a salary override, their only option is to cancel the request, or select a previously offered salary from the HR Administrator.

New Position Review 4.7 If the General Manager cannot approve the request for a New Position, the Hiring Manager should indicate whether a Temporary Contract position is acceptable. 4.8 If a temporary position is not acceptable, the request is cancelled. 4.9 If a temporary position is acceptable, the request shall be forwarded to the HR Recruiting department. If the HR Recruiting department can fulfill the request, the GM and Hiring Manager are notified and the request is submitted for salary compliance.


21



When a process has been identified and it is ready for a Business Process Management (BPM) initiative, the first undertaking is to model the process. Process Modeling begins with a descriptive process modeling effort, otherwise known as Process Discovery. Process Discovery encompasses mapping the process, a capture of the process details, and creation of the initial process diagram. All of this is accomplished during the Playback 0 phase of development. The project team meets with each business stakeholder during this phase, leading up to the final milestone session where sign-off is obtained. This final Playback 0 sign-off should validate that the model accurately reflects the expected process flow, that identified process roles are verified, and that process details and process improvement needs are well documented.

Objectives After completing this unit, you should be able to: •

Capture process Milestones for a Discovery Map

•

Capture process Steps and Activities for a Discovery Map

•

Create a sub-process from Discovery Map Activities

•

Document process details including process participants and intended process improvements in a Discovery Map

•

Create a Conceptual Data Model

Topics This unit includes the following topics: •

About Process Discovery

•

Creating a Discovery Map

•

Capturing the Process Details

•

The Conceptual Data Model

•

When do I move from a Discovery Map to a Process Diagram?


23


About Process Discovery There are two main goals for process discovery, the first of which is highlighted in this unit: •

Communicate the process across all team members and the organization. What is the process? What is not the process?

Collaboration Process discovery leads to the creation of a Discovery Map and is accomplished through collaboration sessions with process subject matter experts and the process owner. These session provides the information needed to create the initial Discovery Map: a high-level process map diagram that communicates the expected order of process task accomplishments and the process details surrounding these tasks.

Process Discovery

24



Collaboration (continued) Once important process details are fully captured, the Discovery Map is shared with the process team to get everyone aligned. It is also shared with the business stakeholders for review, validation, and input. The Discovery Map powerfully communicates very important process information with business process owners, facilitating effective collaboration. Collaboration does not end when the Discovery Map is converted into a Process Diagram -- it is enhanced. Engaging business stakeholders early on in developing the Process Diagram ensures their interest and understanding throughout the entire process modeling lifecycle. NOTES


25


Why IBM BPM Blueprint? IBM BPM Blueprint is a software as a service (SaaS) application well suited for descriptive process modeling. Blueprint is an easy to use and highly effective way to map, document and diagram a business process. Participant and Contributor tool modes allows for input from BPM team members and Business. You avoid having to maintain multiple files to accomplish the process discovery with Blueprint. IBM BPM Blueprint provides: •

A real-time collaborative descriptive process modeling platform

•

A business facing process diagramming tool

•

Process documentation in a fraction of the time of typical documentation efforts

•

A centralized up-to-date version of the process available to many across an organization

•

A standard approach to process discovery, documentation and diagramming across an organization

NOTES

26



NOTES


27


Creating a Discovery Map An IBM BPM Blueprint Discovery Map is created by focusing on these elements: •

Milestones

•

Activities

•

Sub-processes

Each of these elements can be captured during the collaborative process mapping sessions with the process owner and subject matter experts. The elements can also be extracted from a comprehensive process narrative when one is available. It is important to understand when to map each of these elements and how each relates to each other.

NOTES

28



Discovery Map Elements and BPMN Creating a Discovery Map is about making sure the expected order of activities in the process is described effectively. This is the reason why Business Process Management Notation (BPMN) standards are limited in terms of use at this point of the modeling effort. Eventually, these elements will become part of a larger set of components in the process model in Blueprint and then WebSphere Lombardi Edition.

Discovery Map Element

Description Use a Milestone in a Discovery Map to communicate a particular process phase. Milestones are not a BPMN standard, but a very important component in Blueprint and Lombardi. Use an Activity to communicate a process task accomplished by a single business unit in a Discovery Map. Activity is a BPMN standard.

Use a Sub-process to communicate an Activity that is executed by multiple business units. Sub-process is a BPMN standard.

NOTES


29


Milestone For a Discovery Map, a milestone is used to define a particular process phase, representing a change in state or status of the intended process output. For the entire process, milestones are listed in a sequential manner. Each milestone consist of a group of activities intended to produce a specific deliverable within a given time frame. Early collaboration or review of a process narrative should yield the process milestones. This is the first task to accomplish to create a Discovery Map. Expense Reimbursement Process EXAMPLE

While contributing information for the Discovery Map of an Expense Reimbursement process, the process owner identified the following milestones:

Submission

NOTES

30


Approval

Payment

Archive


GUIDELINES

•

Arrange milestones in the order in which they are performed.

•

Consider using nouns to label the milestones

•

Milestones are process phases; they should indicate the significant subdivisions of the whole process, not each individual step

•

Milestones highlight portions of the process that may be good candidates for implementation of process tracking intervals during process implementation, and may provide a useful way to organize discussion of process metrics with process owners and other stakeholders

NOTES


31


Activity Now that the Discovery Map milestones are in place, it is time to add the associated Activities for each milestone. In process modeling, an Activity represents an atomic unit of work, those things that a responsible party in a process does to complete a task. Collaboration with a process owner or information from a process narrative should yield all the process steps needed to identify all tasks (activities). Steps Elaborating the Discovery Map begins with the capture of process steps placed under each milestone. EXAMPLE

In the example provided below, three steps captured from the Expense Reimbursement process information are placed under the first milestone. These are the steps someone would take to submit an expense report.

Submission

Approval

Payment

Archive

Submit Expenses

Scan Receipts Submit Expense Report

Each of the three steps is assigned to the same responsible party in the process.

32



GUIDELINES

•

If there is an unusally high number of steps for a given milestone, this may be an indication that more milestones need to be added

•

Label steps, tasks, and activities with a verb-noun combination

NOTES


33


Activity (continued) If there is no change of ownership from one step to the next under a milestone in your Discovery Map, then these steps should be converted to a single task. EXAMPLE

In the example from the Expense Reimbursement process, the Discovery Map now communicates one atomic unit of work or activity.

Submission

File Expense Report

NOTES

34


Approval

Payment

Archive


Activity (continued) EXAMPLE

Action such as Submit or Send to are represented with workflow direction symbols in the Discovery Map.

Submission

Approval

Payment

Archive

File Expense Report

Approve by Manager

Confirm Payment

Archive Expense Report

Approve by Accounts Payable

The initial Expense Reimbursement Discovery Map is complete. The goal was to list the Milestones and Activities in a sequential manner following an order of accomplishment. At this stage, the lack of detail such as who and when in the Discovery Map is deliberate. The intent of the process map is to provide visibility into what the business process actually is, without regard to any conditions or exceptions. NOTES


35


Sub-process An Activity in a Discovery Map can also be communicated as a Sub-process. Sub-processes are tasks that are owned and executed by different business units. EXAMPLE

The example Expense Reimbursement process Discovery Map shows a candidate Milestone and set of Tasks that could convert to a single Sub-process.

Expense Reimbursement Process

Submission

Approval

Payment

Archive

File Expense Report

Approve by Manager

Confirm Payment


Approve by Accounts Payable

NOTES

36



Sub-process (continued) EXAMPLE

The revised Discovery Map with the Sub-process in place.

Expense Reimbursement Process Submission

Approval

Payment

Archive

File Expense Report

Approve Expense Report

Confirm Payment


NOTES


37


Modifying the Discovery Map A stated goal of the Discovery Map is to provide visibility into the essential elements of the business process, without regard to any conditions or exceptions. “What is the process? What is not the process?” becomes clearer as the Discovery Map is modified into a concise diagram of the expected path of the process. Opportunities to improve the Discovery Map in this regard include modification of any element, including the Milestones if necessary. The process owner or project team may suggest deleting unnecessary information that hinders the goal of defining the essential elements of the process. NOTES

38



Modifying the Discovery Map (continued) EXAMPLE

The example Expense Reimbursement process Discovery Map, with a highlighted portion of the map under consideration for modification.


Approval

Payment

Archive

File Expense Report


Confirm Payment


NOTES


39


Modifying the Discovery Map (continued) The example Expense Reimbursement process Discovery Map modified to a concise, clear diagram of the process.


Approval

Payment

File Expense Report


Confirm Payment Archive Expense Report

NOTES

40



GUIDELINES

•

For ease of use, use the outline view of the Blueprint Discovery Map to edit and modify elements during a real-time collaboration session

•

Use the snapshot feature in Blueprint to capture and label the initial version of the Discovery Map once you have completed the effort

NOTES


41


Expense Reimbursement Process Discovery Map

Submission

Approval

Payment

File Expense Report



NOTES

42



Discovery Map Best Practices and Guidelines •

When you create your process in IBM BPM Blueprint, provide a simple and clear process name

•

Agree on naming conventions for Milestones and Activities across your organization so names mean the same thing to all process team members and key stakeholders

•

Arrange Milestones in sequence.

•

Use nouns to label the milestones

•

Milestones are process phases; they should indicate the significant subdivisions of the whole process, not each individual step

•

Milestones highlight portions of the process that may be good candidates for implementation of process tracking intervals during process implementation, and may provide a useful way to organize discussion of process metrics with process owners and other stakeholders

•

Start by adding process Steps to the Discovery Map under each appropriate Milestone

•

Convert multiple concurrent Steps that are assigned to one owner into a single Task

•

If there is an unusally high number of steps for a given milestone, this may be an indication that more milestones need to be added

•

Label steps, tasks, and activities with a verb-noun combination

•

Process conditions, exceptions, and “who” and “when” details are not the focus of a Discovery Map at this stage of process modeling

•

For ease of use, use the outline view of the Blueprint Discovery Map to edit and modify elements during a real-time collaboration session

•

Use the snapshot feature in Blueprint to capture and label the initial version of the Discovery Map once you have completed the effort


43


1.1 Creating a Discovery Map The Hiring Request Process Owner provided a comprehensive process narrative and a set of requirements. To accomplish the task of creating a Discovery Map for the Hiring Requisition Project, this narrative and set of requirements must be used to capture the process Milestones, Activities, and Sub-processes. Exercise Objective After completing this exercise, you should be able to: •

Create a Discovery Map in IBM BPM Blueprint using either a Process Owner’s collaboration or narrative of the process

Key Steps

44

•

Capture the Milestones found in the New Hire Request process

•

Place the individual process Steps you find in the New Hire Request process underneath the appropriate Milestone

•

Modify those individual process Steps into comprehensive Tasks or Activities accomplished by a single entity

•

Create Sub-processes from the Task or Activities where necessary

•

Make sure the Discovery Map describes the expected order of the Tasks and Activities in the process, without conditions or exceptions



NOTES


45


Capturing the Process Details Another facet of Process Discovery is the capture of process details. Thus the focus shifts to: •

Who does what in our process?

•

When does a task start and finish?

Capturing process details in the Discovery Map in IBM BPM Blueprint allows for the addition of key information about the process task owners, known as Participants, and other process documentation not communicated in the diagram. The first goal of our Discovery Map is to communicate “what is the process?” and adding these details amplifies that effort. The second goal of a Discovery Map is to reveal problem areas in our process. This is accomplished through a capture of the process problem details in Blueprint, including the severity and frequency of each problem. Documenting process problems moves the project from mere process description to a process improvement effort. NOTES

46



Example expense reimbursement process details in IBM BPM Blueprint NOTES


47


Participants The Discovery Map is now ready for us to identify and capture process task owners, or Participants. •

The Participant provides the responsible role detail for the Activities in a process. Capturing Participants in the Discovery Map is crucial for creating a Process Diagram later in IBM BPM Blueprint and WebSphere Lombardi Edition.

NOTES

48



Participants (continued) EXAMPLE

In the example Expense Reimbursement process Discovery Map, the Participant identified for the first Activity is Employee. Notice that a Participant represents a role and not a particular person. Also, had this process been scoped for used by a specific group or department then the Participant would be different, such as Salesperson. In the same manner, if the process has a wider scope in terms of Participants (if, for example, the process includes contract labor and vendors), then the role would probably be an Expense Submitter. Expense Reimbursement Process

Participant Employee Business Owner(s) HR Director Expert(s)

Submission

Approval

Payment

File Expense Report



GUIDELINES

•

Business Owner(s) are the accountable party for the process.

•

Adding an Expert or Experts to your map details will identify the core subject matter experts that you should consult on process details.


49


Inputs and Outputs While adding Participants to the Discovery Map helps answer the question “who does what in the process”?, Inputs and Outputs will help answer “when does a Task begin and finish?”. Inputs and Outputs do not pertain to data as much as they deal with process task upstream and downstream details. NOTES

50



Inputs and Outputs (continued) EXAMPLE

The example Expense Reimbursement process Discovery Map provides a quick look at input and output details for the first Activity. In this case, the upstream Input for the Task is a “blank standardised expense report”, while the downstream output is a “completed expense report”. This is the level of information needed for a Discovery Map. Expense Reimbursement Process

Input and Outputs Blank Standardised Expense Report (I) Completed Expense Report (O)

Submission

Approval

Payment

File Expense Report



GUIDELINES

•

Use the Supplier(s), Input(s), Output(s), and Customer(s) fields in IBM BPM Blueprint to describe passive BPMS interactions. Start with supplier inputs and outputs to customers that match an ideal case. NOTE: This is not a capture of data inputs and outputs; that information is better served when it is detailed in a Conceptual Data Model.


51


Problems Surfacing process problems is a very important aspect of Process Discovery. It is a Process Discovery goal to document these problems so the project team can easily transition from a descriptive to an analytical process modeling. First, identify and document these Problems in the Discovery Map. The Severity of the Problem should be documented along with the Frequency in order to rank and prioritize each. NOTES

52



Problems (continued) EXAMPLE

The example Expense Reimbursement process Discovery Map has an identified Problem that is both Frequent and Severe in the first Activity. “Receipts not attached” is cause for concern because it delays the ability to complete the task and all subsequent tasks in the desired timeframe.

Expense Reimbursement Process Problems Receipts not attached

Submission

Approval

Payment

File Expense Report



GUIDELINES

•

Document Problems when they are mentioned, including severity and frequency if provided. However, avoid investing time to solve these problems at this point in the Discovery effort.


53


Documentation/Attachments Process details are important for the Discovery Map so even if the information offered by SMEs or stakeholders for a particular Task or Milestone does not fit a category, capturing that information in the Documentation area in Blueprint will be valuable for the next phase of process modeling. In the same way, legacy materials and existing process documentation should be included as attachment items. NOTES

54



Documentation/Attachments (continued) EXAMPLE

For the example Expense Reimbursement process Discovery Map, the BPM Team added an attachment to the first Task so there will be a reference point for actual documents used in the current process. The reference material will be valuable later on during the implementation of the process.

Expense Reimbursement Process Documentation/ Attachments Attached: Current PDF version of the expense report.

Submission

Approval

Payment

File Expense Report



GUIDELINES

•

Use the Documentation section to capture the process sponsor vision, improvement targets, and implementation details not yet captured or documented.

•

IBM BPM Blueprint gives you the ability to communicate details about a process to a wide range of interested parties within your organization. It is up to you what level of detail you use based on how much you want to communicate. If you feel like you’re doing needless or redundant data entry and you’re not going to share or discover anything new about the process, it is okay to stop adding details to your process.


55


Expense Reimbursement Process Discovery Map

Submission

Approval

Payment

File Expense Report



Details Added (Activities and Milestones) •

Partcipants

•

Inputs and Outputs

•

Suppliers

•

Customers

•

Attachments

•

Problems (Severity and Frequency)

NOTES

56



Capturing Process Details Best Practices and Guidelines •

The Participant provides the responsible role detail for an Activity in a process. Capturing Participants in the Discovery Map is crucial for creating a Process Diagram later in IBM BPM Blueprint and WebSphere Lombardi Edition.

•

Business Owner(s) are the accountable party for the process.

•

Adding an Expert or Experts to your map details will identify the core subject matter experts that you should consult on process details.

•

The System, Cycle Time and Cost is information you can add to outline both functional and business requirements

•

Use the Supplier(s), Input(s), Output(s), and Customer(s) fields in IBM BPM Blueprint to describe passive BPMS interactions. Start with supplier inputs and outputs to customers that match an ideal case. NOTE: This is not a capture of data inputs and outputs; that information is better served when it is detailed in a Conceptual Data Model.

•

Risk and Value Add is information identified in the process analysis phase of modeling.

•

Document Problems when they are mentioned, including severity and frequency if provided. However, avoid investing time to solve these problems at this point in the Discovery effort.

•

Use the Documentation section to capture the process sponsor vision, improvement targets, and implementation details not yet captured or documented.

•

IBM BPM Blueprint gives you the ability to communicate details about a process to a wide range of interested parties within your organization. It is up to you what level of detail you use based on how much you want to communicate. If you feel like you’re doing needless or redundant data entry and you’re not going to share or discover anything new about the process, it is okay to stop adding details to your process.


57


1.2 Capturing the Process Details The Hiring Request Process Owner provided a comprehensive process narrative and a set of requirements. To accomplish the goal of capturing and documenting Process Details in a Discovery Map for the Hiring Requisition Project, this narrative and set of requirements must be used. Exercise Objective After completing this exercise, you should be able to: •

Capture and document important Process Details in a Discovery Map in IBM BPM Blueprint using either a Process Owner’s collaboration or narrative of the process

Key Steps

58

•

Add Participant information for each Task in the Discovery Map

•

Add Inputs and Outputs information, including Supplier and Consumer information, in the Discovery Map

•

Document Problems in the Discovery Map Tasks where necessary

•

Add any necessary Documentation to each Task in the Discovery Map

•

Add any Attachments available for Tasks in the Discovery Map



NOTES


59


Conceptual Data Model Until this point, the focus has been on the business process and how to model this process effectively. BPM solutions, however, are composed of much more than just the business process. Business Data Models contribute to the success of a process application as well as the effectively articulated Business Process Models. At times business data is only considered during final implementation modeling and will not comprehensively involve any business stakeholders. This is where a bridge between the developer driven Business Data Model and the Business Process Model can help. A Conceptual Data Model allows the business and project team to work through the Inputs and Outputs for Task (Activities) more indepth. Conceptual Data Models provide a business friendly way to visualize actual business data and data relationships within the process. When defining the Conceptual Data Model for your process, look at the process as a whole. For each Activity or core element, ask “what data does the process need to complete that task?”. This is part of the Blueprint and Lombardi “process flow” system.

NOTES

60



GUIDELINES

•

Capture of business data entities requires using either Blueprint documentation, real-time creation of Lombardi variable types, UML case tools, or spreadsheets

•

During the Process Discovery sessions, capture the nouns used when business entities are mentioned

NOTES


61


EXAMPLE

Captured conceptual data in the Expense Report process first Activity:

Expense Report 1. Name 2. Department 3. Manager 4. Expense Date 5. Expense Amount 6. Expense Reason

NOTES

62



EXAMPLE

Captured conceptual data in the Expense Report process second Activity: Expense Report 1. Name 2. Department 3. Manager 4. Expense Date 5. Expense Amount 6. Expense Reason 7. Approval Status 8. Reason Rejected

NOTES


63


When do I move from a Discovery Map to a Process Diagram? Part of Process Discovery is the creation of a Process Diagram. Up until now, the focus has been the creation of a comprehensive Discovery Map complete with as much process detail as possible. The most common question when in the midst of a Process Discovery effort is: •

When do I move from a Discovery Map to a Process Diagram?

Several aspects need to be considered to answer this question. When a Discovery Map has exhausted all requirements to communicate what a process is, complete with documented problems within the process, then it is close to the time to transfer over to a Process Diagram. Another item to consider is the conversations in the process collaboration sessions during Playback 0 meetings. If the questions no longer center around “what does this process do?” and start to center around “what does this process look like?”, then the move to the Process Diagram is at hand. NOTES

64



Blueprint Discovery Map

Blueprint Process Diagram


65


Unit 2: Playback 0 - Process Diagram

The process Discovery Map has the information in place necessary for stakeholder validation of the high-level process. Up to this point the objectives have been to make sure the process was mapped in its current state, make sure to have all the appropriate process details in place, be precise on the expected order of steps, and capture all process problems. Now the goal is to create a process diagram to graphically represent the process. The core element flow-chart based notation will be used to further communicate process needs to the BPM team. The diagram allows BPM teams to analyze the process for improvement and to create the functional requirements for process application implementation.


Create a process diagram from the Discovery Map in IBM BPM Blueprint

•

Import a IBM BPM Blueprint Process Diagram into WebSphere Lombardi Edition (Lombardi)

•

List the major components of the WebSphere Lombardi Edition (Lombardi) Authoring Environment


IBM BPM Blueprint Process Diagram

•

When Do I Migrate from Blueprint to Lombardi?

•

About WebSphere Lombardi Edition


67


IBM BPM Blueprint Process Diagram As described earlier, Process Modeling captures the ordered sequence of activities within a process along with supporting information from start to end. In Modeling, the business process is framed using a workflow model to reflect component activities, the roles performing those activities, conditional branching and the sequencing of the flow of work between activities. In IBM BPM Blueprint, this workflow model is called a Process Diagram. About BPMN To communicate this model clearly within your organization, a notation standard must be applied. The primary goal of Business Process Management Notation (BPMN) is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation. This single notation has been agreed upon among multiple BPM vendors for the benefit of the user community. Core Elements Both IBM BPM Blueprint and WebSphere Lombardi Edition use six core BPMN 1.2 elements: •

Activity

•

Event

•

Gateway

•

Flow

•

Pool

•

Lane

The manner in which each tool uses these six elements varies because the focus of each is different. Blueprint’s focus is to maintain a very close relationship with Business, while Lombardi is meant to carry the process model through to implementation and then to deployment of the process application. In Lombardi, the BPMN elements have robust constructs not found in Blueprint. 68



Create a Process Diagram in IBM BPM Blueprint To continue the descriptive process modeling in IBM BPM Blueprint, a Process Diagram must be created. This is not a new experience or handoff, but an extension of the work already produced in the Discovery Map. In IBM BPM Blueprint, creation of a Process Diagram is a simple matter of one click to convert from the Discovery Map. IBM BPM Blueprint automatically does the work for you. The elements created from the Discovery Map retain all the details entered previously. Milestones are translated to process diagram section headers, the Participant details into Lanes, also known as Swimlanes, and the Activities assigned to each Participant fall into the proper Lane for each. Because the expected order of tasks is the focus of the Discovery Map, conversion to a Process Diagram causes a Start and End Event to be automatically assigned with connectors for each task. Process Diagram Elements

Description

Activity

An Activity is an atomic unit of work and can be represented as a Task or a Sub-process.

Lane

A Lane is a sub-partition within a process Pool. Pools are not as evident in a Blueprint Process Diagram and will be discussed later in Lombardi. Lanes are used to organize and categorize Activities within a Process Diagram.

Event

An Event is something that “happens” during the course of a business process. EventTypes like Start will indicate where a process starts and End will indicate where a process will end. Another EventType - Intermediate - will be discussed later in the course.

Start

KEY INFORMATION

End

•

Creation of the Process Diagram does not preclude you from continuing to modify the Discovery Map through on-going collaboration sessions. Once you create a Process Diagram, it is linked to the Discovery Map and any revisions are reflected in both areas of the IBM BPM Blueprint process.


69


EXAMPLE

Expense Reimbursement Process Diagram The example below is an example of a Process Diagram that has been created from an existing Discovery Map and then modified. BPMN elements were added and the diagram was adjusted to articulate the clearest view of the process model to a business audience.

Example modifi ed expense reimbursement process diagram in Blueprint modified

NOTES

70



Process Diagram Best Practices and Guidelines The following is a list of guidelines for IBM BPM Blueprint that you can use to accomplish the task of creating and modifying a Process Diagram. •

Each activity you create must reside in a swimlane

•

Start activities at the top and work down as new swimlanes are added

•

If an activity has an either/or responsible party, create a swimlane that includes both participants

•

Decision Gateways should be labeled as a question, with the answers to the question documented on outgoing lines

•

Blueprint will try to represent the ideal Process Diagram initially, however, it is a good idea to maneuver the elements in this initial diagram until you get an optimal representation of your process

•

The use of color for your Activities in the Process Diagram is dependent upon your organization’s need

•

Swimlanes in a Process Diagram are the articulation of roles in that process so use naming conventions that describe the role, not the person responsible

NOTES


71


2.1 Creating a Process Diagram The Hiring Request Process Owner provided a comprehensive process narrative and a set of requirements. To accomplish the task of creating a Process Diagram for the Hiring Requisition Project, this narrative and set of requirements must be used to identify any diagram modifications. Exercise Objective After completing this exercise, you should be able to: •

Create a Process Diagram in IBM BPM Blueprint from a Discovery Map

•

Modify the Process Diagram in IBM BPM Blueprint

•

Add elements to a Process Diagram in IBM BPM Blueprint based on a process narrative

Key Steps

72

•

Capture the Process Diagram requirements found in the New Hire Request process

•

Convert the existing Discovery Map to a Process Diagram

•

Modify the diagram to include any elements that will enhance the communication of the model to the Business

•

Create a linked Sub-process for the required Activity

•

Use color schemes to your Activities to indicate process problems



NOTES


73


When do you migrate from Blueprint to Lombardi? IBM BPM Blueprint allows modification of the Process Diagram in order to migrate towards analytical process modeling. At some point in the process modeling effort, the decision to move to WebSphere Lombardi Edition needs to be made. When the questions in the collaboration sessions shift to “how will we improve this process?”, you are ready to make the shift towards analytical process modeling and Lombardi. Your modeling effort is now closer to an executable process model with a few modifications and updates left to accomplish. This is when you are engaged in the actual Lombardi implementation. The first thing you must do is to import the IBM Blueprint process diagram into Lombardi. KEY INFORMATION

•

Import of a Blueprint Process Diagram to Lombardi does not mean that Blueprint has exhausted its value in the project lifecycle. There are still many reasons why Business will want to continue to look towards Blueprint as the centralized process modeling communication and documentation.

GUIDELINES

•

A process diagram or model is referred to as a Business Process Definition (BPD) in Lombardi

•

Any sub-process in your BPD is referred to as a Nested BPD in Lombardi

•

In general, a BPD should be as simple an abstraction as you can make it. A highly conceptual BPD will be very resilient to change.

•

Make sure you use the Documentation tab in the Properties section in Lombardi to include important requirement notes for each BPD Activity, Decision Gateway, Events and other core elements.

For More Information, Refer To: WebSphere Lombardi Edition7.1.0-Authoring Environment User Guide>Basic modeling tasks>Creating a BPD

74



About WebSphere Lombardi Edition WebSphere Lombardi Edition is an enterprise application that: •

Allows you to build faster, work smarter, constantly improve your business process model

•

Employs a graphical process development tool

•

Provides process visibility and performance data

•

Provides process simulation and optimization


75


Lombardi Authoring Environment Lombardi’s Authoring Environment (AE) is composed of three key applications: •

Process Application Designer (Model and Service)

•

Process Inspector

•

Process Optimizer

The Process Center WebSphere Lombardi Edition’s unique design environment includes a central repository called the Process Center. True to its name, the Process Center is the central place for BPM teams to store, retrieve, and deploy process applications. The Process Center provides a centralized development environment for distributed authoring of all project artifacts, some of which can be designated as resuable applications.

A previously stored process app can be launched from the Process Center by clicking on the “Open in Designer” option.

New process apps can be created by clicking on the “Create New Process App” option.

Either option will allow access to the Process Application Development Environment (Designer).

For More Information, Refer To: WebSphere Lombardi Edition7.1.0-Authoring Environment User Guide>Basic modeling tasks>Managing the Process Center Repository 76



Designer To continue the process modeling effort, use the Designer, an environment composed of a Process Modeler and a Process Library. Discovered and developed processes in Blueprint can easily be accessed from the Designer. Once in Lombardi, alterations can be made to improve the process and add the conditions and exceptions required by the Business. Blueprint subscriptions (imports) are only available in existing Process Apps, so creation of a new app or use of an existing app is necessary. EXAMPLE

The example Expense Reimbursement Blueprint process diagram subscription in the Designer Authoring Environment Element Palette

Library

Blueprint Subscription

Modeler

Attributes


77


2.2 Subscribing to a Blueprint Process The Hiring Request has been modeled in Blueprint using a comprehensive process narrative and a set of requirements provided by the Process Owner and other SMEs. Accomplish the task of subscribing to a Blueprint Process from the Lombardi Designer Environment for the Hiring Requisition Project. Exercise Objective After completing this exercise, you should be able to: •

List the steps necessary to import a IBM Blueprint Process Diagram into Lombardi

•

Manage a IBM Blueprint import in the WebSphere Lombardi Edition Library structure

•

Alter the Blueprint subscription in Lombardi

Key Steps

78

•

Make sure you have a Blueprint account and the process you created is in your account name

•

Make sure you are subscribing from an existing Process App in the Process Center and not a Toolkit

•

Access the Blueprints option in the Library and subscribe to the Blueprint Process you wish to import

•

Modify the Blueprint subscription once accessed from the Library



NOTES


79


Unit 3: Playback 1, Part 1 Process Flow

Not all business processes can follow a single path from start to end. Conditions and exceptions are usually unavoidable and must be dealt with to capture the functional requirements of your process BPMN allows us to create a business process diagram, which represents the activities of the business process and the flow controls that define the order in which they are performed.


Describe Process Sequence Flow and the runtime use of Process Tokens

•

Describe the three Gateways as implemented by WebSphere Lombardi Edition

•

Model a Decision Gateway

•

Model a Simple Split Gateway


About Process Flow

•

About Tokens

•

About Gateways


81


About Process Flow Process Sequence Flow refers to the flow that originates from a Start Event in your process and continues through activities via alternative and parallel paths until it ends at an End Event. Normal Sequence Flow The simplest example of this is a single Sequence Flow connecting two activities. This is referred to as Normal Sequence Flow.

NOTES

82



Conditional Sequence Flow Sequence Flow can have condition expressions that are evaluated at runtime to determine whether or not the flow will be used.

NOTES


83


Default Sequence Flow In Lombardi, when using conditional sequence flow, a Default flow is required. This Default flow will be used only if none of the other outgoing flow conditions are true at runtime. These types of Sequence Flow have a slash added to the beginning of the flow line.

NOTES

84



About Tokens A token is a descriptive construct used to describe how the flow of a process will proceed at runtime. By tracking how the Token traverses the Flow Objects, the sequence flow should be definable.

NOTES


85


Tokens (continued) By tracking how the Token gets diverted through alternative paths, the sequence flow should be definable.

NOTES

86



Tokens (continued) By tracking how the Token gets split into parallel paths, the sequence flow should be definable.

NOTES


87


About Gateways A Gateway can be thought of as a question that is asked at a point in the process flow. The question has a defined set of alternative answers, which in effect act as gates—the process cannot proceed until a valid answer is provided.

!

! ! A Gateway provides a point where the process may select one, or more, of a number of paths, depending on the type of gateway, and some known condition in the process. For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Using Gateways NOTES

88



Exclusive Gateway (X/OR) Lombardi uses the term Decision Gateway to identify a Exclusive Gateway (X/OR) Split. Decision Gateways are used to direct the process flow along only one of the available outgoing conditional sequence flows. An outgoing default sequence flow (a line with no condition) must be modeled. The outgoing default sequence flow is only followed if none of the preceding conditions are true.

•

Outgoing sequence flow conditions are evaluated in order— from top to bottom—as defined in the gateway’s Properties tab.

•

Only one outgoing sequence flow condition can be true.

•

Once a condition is met, evaluation of subsequent outgoing sequence flow conditions stops.

For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Using Gateways NOTES


89


Inclusive Gateway (AND/OR) Lombardi uses the term Conditional Gateway to identify a Inclusive Gateway (AND/OR) Split. Conditional Gateways are used to direct the process flow along one or more outgoing conditional sequence flow. All conditions must be met before the process can execute the next task in the flow. An outgoing default sequence flow (a line with no condition) must be modeled. The outgoing default sequence flow is only followed if none of the preceding conditions are true.

The difference between a Conditional Split and a Decision Gateway is, essentially, this: a Decision Gateway allows a process to take only one of the available paths, while a Conditional Split can allow it to take one or more paths, but not all at once. For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Using Gateways NOTES

90



Parallel Gateway (AND) Lombardi uses the term Simple Split to identify a Parallel Gateway (AND). Simple Split gateways are used to direct the process flow along every outgoing sequence flow in parallel. There are no conditions for Simple Split gateways.

For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Using Gateways NOTES


91


Splits and Joins Typically, Gateways have two distinct modes: •

A Gateway splits the incoming path into multiple outgoing paths (split)

•

A Gateway merges several incoming paths into one outgoing path (join)

In Lombardi, and contrary to BPMN, a Decision Gateway cannot be used to join multiple tokens. Conditional and Simple Split Gateways allow for joins to be used. NOTES

92



Using Gateway Splits and Joins Gateway Splits allow for concurrent activity. However, there are times when some actions must not proceed until a set of previous activities have completed (i.e. a summary task of the results of previous actions). GUIDELINES

As such you need an accompanying join to: •

make the process work in a sensible, simple manner

•

make the process diagram easy to understand by different audiences

A good rule of thumb for modeling splits and joins is one token into the process, one token out of the process For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Using Gateways

NOTES


93


Evaluating Conditions If the conditions are simple expressions of process data, you could put the decision logic in the outgoing Sequence Flows of the Gateway. Invalid

OK

Receive Order

NOTES

94


Validate Order


Evaluating Conditions (continued) GUIDELINES

The best practice is to externalize the decision logic—make it independent of the process model. Use a Task preceding the Gateway to make the decision, and use the outgoing Sequence Flows from the Gateway to route the flow based on the decision. No

Yes

Validate Order Receive Order

Order Valid?

NOTES


95


3.1 Adding Gateways The Hiring Request Process Owner provided a comprehensive process narrative and a set of requirements. To accomplish the task of adding all the Gateways necessary to model the flow control for the BPD in the Hiring Requisition Project, use the narrative and set of requirements to identify any alterations that must be made to the model. Exercise Objective After completing this exercise, you should be able to: •

Add Gateways to a Business Process Definition in Lombardi

•

Model the appropriate sequence flows for each Gateway

Key Steps

96

•

Drag the type of Gateway you need from the element palette to the BPD

•

Using the Sequence Flow tool, click to anchor the flow line from a Gateway and then click to connect the flow line to an Activity in the BPD

•

To enter conditions in Gateways that require them, click the Gateway Implementation tab and for each outgoing sequence line, enter the condition (in JavaScript) that controls whether the path is followed

•

Make sure that the sequence line shown as Default Line in the Implementation Tab is the one you want the process to follow if all conditions evaluate to false

•

To designate a different Default Line in your Gateway Implementaton tab, use the arrow icon to move the one you want to be the default as the last line listed



NOTES


97


Unit 4: Playback 1, Part 2 Intermediate Events

Process modeling requires us to find opportunities to integrate activities or task responsibilities with automated nonhuman performance. We look to model behaviors of people and organizations. At times, these behaviors also involve exceptions, delays and deadlines. Prescribed delays or deadlines can be represented with an Intermediate Timer Event in the BPD.


Model an escalation path using an Attached Intermediate Timer Event

•

Identify and list the functions within an Intermediate Timer Event


Intermediate Events

•

A Way to Model an Escalation

•

Intermediate Timer Event

•

Intermediate Timer Event Implementation


99


Intermediate Events Intermediate Events occur between a Start Event and an End Event in the BPD. The Intermediate Event is a circle that is drawn with a double thin black line. An internal marker indicates the type of intermediate event.

100

Intermediate Event Types

Description

Intermediate Timer Event

Responds to the passing of time.

Intermediate Message Event

Responds to the receipt of (catches) a message.

Intermediate Exception Event

Responds to the occurrence of (catches) an exception.

Intermediate Tracking Event

Used to indicate a point in a process at which you want to track the run-time data for reporting purposes. NOTE: This is a Lombardi specific intermediate event.

Unit 4: Playback 1, Part 2 - Intermediate Events


All Intermediate Events behave the same way, depending on how they are implemented. An Intermediate Event placed in the sequence flow will pause the process flow until the specified event occurs.

An Intermediate Event attached to the boundary of an activity will generate a separate token and, if the specified event occurs while the activity is active, the Intermediate Event will release its token along the outgoing sequence flow. Once this flow occurs, you can specify whether to create parallel or alternate process flow. NOTE: Intermediate Tracking Event does not conform to these behaviors. NOTES


101


A Way to Model an Escalation Tasks or Activities assigned to a Participant may have set completion rules, such as “complete this task by a specified date or time”. If the task is not completed, the model must communicate what should happen, including how the task is escalated and to whom. This provides visibility for your business process and implements controls to manage important process cycle times. It also assists with service level agreements for the process steps that need to be met. Intermediate Timer Event One method used in Lombardi to model an escalation is through an Attached Intermediate Timer Event. If an Activity takes longer to complete than a defined period of time, an Attached Intermediate Timer Event is triggered and the process follows the path from the Attached Timer Event to an escalation Activity.

For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Adding Events to a BPD

102



Intermediate Timer Event Implementation Attached Event Details These options will only appear when the Intermediate Timer Event is attached to an activity. Close Attached Activity: Closes attached activity after time elapses Repeatable: Resets timer to countdown again after time elapses

Ti ti Timer P Properties Trigger On: Specifies when Timer Event should start Custom Date: Use JavaScript to calculate and specify a date Before/After Difference: Amount of time Tolerance Interval: Specifies an additional delay if work is in progress. Will only measure once.

For More Information, Refer To: WebSphere Lombardi Edition 7.1.0 Authoring Environment User Guide>Modeling Processes>Basic Modeling Tasks>Adding Events to a BPD


103


4.1 Adding Intermediate Timer Events The Hiring Request Process Owner provided a comprehensive process narrative and a set of requirements. To accomplish the task of adding all the Intermediate Timer Events that help satisfy both Core and Challenge requirements for the Hiring Requisition Project, use the narrative and the set of requirements to identify the alterations that must be made to the model. Exercise Objective After completing this exercise, you should be able to: •

Add an Intermediate Timer Event to a BPD based on business requirements

•

Select the appropriate functionality for the Intermediate Timer Event based on the business requirements

•

Model an Escalation path in a BPD in IBM WebSphere Lombardi Edition

Key Steps

104

•

Drag the Timer Event component you need from the element palette to the BPD

•

If an Attached Intermediate Timer Event is needed, place the element in the boundary of the desired Activity

•

If an sequence flow Intermediate Timer Event is needed, place the element in the desired sequence flow in the BPD

•

Define the Intermediate Timer Event properties in the Implementation tab of each

•

If modeling an escalation, place an Activity from the palette in the BPD where the Participant responsible for the escalated task is located

•

Use the Sequence Flow tool to connect the Attached Intermediate Event to the Activity

•

Use the Sequence Flow tool to modify the sequence flow where the Intermediate Timer Event is located



NOTES


105


Unit 5: Playback 1 -Validate the Process Model

An effective BPM initiative strives to have a Business group that is as engaged, if not more so, as the IT development group. An iterative development approach allows the BPM development team to involve the Business as much as possible. WebSphere Lombardi Edition is built to facilitate collaboration and discussions on the accuracy and completeness of the model during those iterative development cycles. This is accomplished through the built-in functionality called “playbacks” in the Process Inspector, a powerful component of the WebSphere Lombardi Edition Authoring Environment.


List the components of the Process Inspector

•

Describe how to validate a Process Model using Playbacks

Topics This unit includes the following topic: •

The Process Inspector


107


The Process Inspector The Process Inspector, a vital component of the WebSphere Lombardi Edition Authoring Environment, is key to an iterative approach to process development. Using the Process Inspector, individual developers can run processes and services on the Process Center Server or remote runtime Process Servers. Likewise an entire development team can use the Inspector to demonstrate current process design and implementation to stakeholders in playback sessions. Playback sessions help capture important information from different stakeholders in a process, such as management, end users, and business analysts. Taking an iterative approach to process development ensures that process applications meet the goals and needs of everyone involved. It also helps maintain an involved Business group throughout the lifecycle of the project. For More Information, Refer To: WebSphere Lombardi Edition7.1.0-Authoring Environment User Guide>Basic modeling tasks>Running and debugging processes with the Inspector NOTES

108

Unit 5: Playback 1 - Validate the Process Model


Inspector Toolbar Options Resumes a suspended process instance Pauses selected process instance

Removes any record of a selected process instance

Stops a running process instance

Opens a debug session in the default Web Browser

Pages through the BPD instances

Refreshes the current list of process instances

Runs the selected task

Current and previously active Process Instances Current BPD Task

BPD Diagram

Execution Progress Shows the variables used in the current step Lombardi Process Modeling

109


5.1 Validating the Process Model Playbacks for the Hiring Requisition Process have been scheduled in order to validate that the model is ready. Exercise Objective After completing this exercise, you should be able to: •

Validate that the BPD will function as modeled using the Process Inspector

Key Steps

110

•

Run the Hiring Requisition BPD

•

Change the interface to the Process Inspector

•

Highlight the process instance you wish to inspect, perferrably the one you just initiated

•

Select an icon from the toolbar options that that matches the action you want to take for the process instance

•

Choose to step through a process instance

Unit 5: Playback 1 - Validate the Process Model


NOTES


111


Appendix: Challenge Exercises

Vacation Request An employee requesting time off fills out a Vacation Request form. All Vacation Request forms must be submitted to the manager of the employee for review and approval/nonapproval. A manager will use the criteria of conflicts with other employees requesting the same time off and enough work resource coverage for an approval. If the manager decides to decline the request, the manager notifies the employee of the denial. The employee is allowed to select a new set of dates for vacation request submittal. If the request is approved, the manager will walk the form over to HR for review. The HR Administrator will check whether the employee’s available accrued vacation days matches the days requested. The HR Administrator must approve or reject the request within 4 hours of receiving the request. If rejected, the HR Administrator will notify the employee of the available days accrued, allowing the employee to adjust the days requested. Once approved by the HR Administrator, the approval is sent to a HR Specialist who updates the HR Employee database, notifies the employee, the manager and payroll of the approved Vacation Request form.


113


Publishing

NOTES

114

Appendix

•

Publishing model: When an article is submitted for publishing, the editor first reviews it, after which it goes in parallel to the copy editor for text editing and to the art director for graphics. When both are done, it goes to final layout.

•

Publishing model 2: When an article is submitted for publication, the editor first reviews it, after which it goes to the copy editor for text editing. If the article contains graphics, it goes in parallel to the art director for graphics. When both are done, it goes to final layout.


Insurance Claim •

When reviewing an insurance claim, the adjuster may request additional supporting information. If no additional information is required, the claim can be processed by central processing. If additional information is required, suspend the claim until the supporting information is received.

•

If the required information is not received within 7 days, send a reminder. If the information is not received within 5 additional days, notify the claimant and terminate the claim

NOTES


115


Building Damage Reporting Process

NOTES

116

Appendix

•

When damage occurs to the building, the Facilities Manager must submit a Damage Report

•

If the damage was caused by fire, the Fire Department must be notified

•

If the amount of damage is greater than $5000, the Insurance Agent must be notified

•

The Building Manager must always be notified


Submit Auto Damage Claim •

If claim amount is less than $1000, conduct Small Claims Review

•

If claim amount is $1000 to $5000, conduct Standard Claims Review

•

If claim amount is greater than $5000, conduct Fraud Claims Review

NOTES


117


New Hire On-boarding Process •

On the first day of employment,employees must complete the HR New Hire forms

Then, they must:

NOTES

118

Appendix

•

Apply for a Security Badge

•

Requisition a computer

•

Apply for a Network ID and email address


Determine Route Home •

Check the weather

•

If the weather is not clear, take route A home, otherwise check the time

•

If the time is after 6 pm, take route B home, otherwise check congestion on primary route

•

If the primary route is OK, take the primary route home, otherwise take route A home

NOTES


119

IBM web spehere en ingles

Recommend Documents