Process Design

Question 1

Draft flows by a BA

Answer 1

BA:

• owns draft flows
• order of steps
• names and connectors
• aligned with specs

SA:

• consult (re-use, automation, efficiency)
• takes flows out of draft mode (at the end)

Question 2

best practices

Answer 2

Best Practices for Process Design

• start with high-level information.
• focus on describing what an actor must do at each step, and how the system should react
• include information such as the intent of a step and any basic instructions for the end user.
• identify any changes to the status of the case, including the new status and where in the flow it should be set.
• use draft flows and review them with SMEs
• associate a specification with each of the shapes that make up the process. (configuration details for each processing action; the fields and other controls to appear on a user interface, data required by the application; protocols and data conversions for an integration)
• shape-level specifications are secondary to the overall process specification. (first:process specification, second: shape-level specifications)
• identify opportunities to improve the process. (e.g. automating business policies)
• automate any business policy that relies on one or more well-defined conditions to arrive at a decision
• automatically enforce a processing goal for an individual assignment. (SLA)
• automate routing logic to push assignments to a pool of end users or the most appropriate end user (e.g. skills), rather than wait for an end user to select an assignment.
• process design is an iterative process: 1. requirements 2. specifications, 3. draft process modell 4. review with SMEs 5. update the drafts

Question 3

Pega BPM Modelling Phases

Answer 3

Descriptive modeling:

• where we document the process as-is
• high-level description of the existing processes
• focus on the project vision, its goals, and any key performance indicators (KPIs)
• LSA application expresss (to identify work objects/cases, data objects, objectives)

Analytical modeling:

• analyze the “as-is” process and identify/propose areas for improvement.
• document detailed business requirements, and the use cases/user stories that correspond to them.
• model the proposed, or “to-be” process, indicating all of the actions that can be performed (all paths)
• focuses on the business and process requirements.
• capture stages and steps
• reengeneer processes
• create high-level specifications
• create dreaft processes, data model and UI

Executable modeling:

• implement the “to-be” process
• document the detailed functional requirements
• create the executable process
• QA the result and repair any identified defects
• focuses on detailed requirements and specifications that describe the behavior of the application.
• develop data model and UI
• config integrations and policies
• test & deploy to production

Pega’s model-based approach:

• allows us to develop applications that addresses business needs and also reflect organizational culture.
• provides a framework to assess existing processes – if they exist – and propose changes that provide more-efficient and more-accurate methods of conducting business
• changes can be incorporated into the application design from the beginning, and allow the business to review and understand their impact during development, rather than after we complete the application

Question 4

Flow modelling principles

Answer 4

Single Step Assignment:
- single action performed by an end user
- corresponds to a single user interface, or form.
when to use:
- need to model a single interaction with an end user to accomplish a task
- an automated action related to an assignment (routing, correspondence)
- need simple yes/no logic to determine a course of action

Multi Step Process:
- a series of actions performed by one or more actors – end users, PRPC itself, or even external systems by means of an integration.
when to use:
- need to integrate with an external system, i.e., web service
- an automated action not related to an assignment
- need to coordinate multiple actions with advanced decision logic
- complex decision logic requires a decision shape
-reusable sequence of assignments

Case:
single, automated action to create one or more cases – either a subset of the work required for our case, or new work altogether.
when to use:
- need to create either a new top-level case or a new sub-case

Question 5

Flow rule

Answer 5

• each step in our case lifecycle corresponds to a flow rule, regardless of whether the step corresponds to an assignment, a sequence of actions, or a case to create
• provides a visual method for modeling a process, known as a process diagram.
• connects a series of shapes that represent configurable rules to create a workflow for our case
• Case Designer/process outline
• use to arrange and connect shapes to model our process

Question 6

Shapes and Connectors

Answer 6

• each shape represents a specific processing task to be performed (by end user, PRPC, external system)

Basix flow shapes (6):
Start, End, Assignment, Decision, Utility, and Subprocess

Smart shapes:

• preconfigured to perform specific task
• provide configurable shortcuts to implement common tasks (1. Attach content, 2. create pdf, 3. Push notification, 4. Change state, 5. Persist case, 6. Send email, 7. Create case 8. Post to pulse, 9. Update a case, +1: Cascade approvals, +2 Duplicate search)

Advanced flow shapes (LSA, SSA)
- provide additional functionality that may require a strong technical understanding of PRPC to configure it properly.

BAs role:

• understands how to configure the basic flow shapes to model a process
• understands the purpose of the Smart Shapes and advanced flow shapes available for flow modeling
• use shapes in draft flows to represent functionality that a more-technical member of the development team can later configure.

Connectors:

• establish the path between these shapes, we use connectors.
• one shape many uses
• from assignment: represents a user interface
• from a decision: represents either a decision outcome or a testable condition.
• other connectors simply link two flow shapes

Optional actions:

• an assignment: local action
• stage: optional action or process
• case type: supporting process or local action

Question 7

Intent driven process modelling

Answer 7

Modelling order:

1. Identify used shape types
2. Name the shapes
3. Connect the shapes
4. Name the connectors (+%)
5. Add instructions
6. Add audit log
7. Set up the required case status update

• To ensure that the process we create can be understood by all of our stakeholders, both technical and non-technical
• help business stakeholders to understand each of the actions performed during the case lifecycle, and system architects to verify the intent with their configuration.
• the label for each shape should clearly communicate the purpose that shape serves in the flow
• provide clear instructions for each assignment, so that end users understand what the assignment entails
• connectors should clearly communicate their purpose within the overall process, and the likelihood that the case will advance along them
• the work status should accurately reflect the state of the case at any point in time
• work history, or audit trail, should clearly indicate every action performed in the flow.
• until we start to create our UIs, the flow design provides the only clues to communicate the work to be done at any point within the process.

Question 8

Work Status

Answer 8

• pyStatusWork (Field Value rule defines the values)

- Field Value rule fields: Translate from, translate to

Question 9

Best practices

Answer 9

• limit process flows to a maximum of 15 actionable shapes (use subprocess)
• develop intent-driven process flows
• label flow shapes to clearly identify their intent (helps project stakeholders to quickly understand the flow logic during DCO playbacks, and also when creating application documentation)
• provide instructions for each assignment (help end users to prioritize the tasks pending for them by determining the effort needed to complete the assignment)
• provide audit notes for each shape and action in the flow (provides verification for each action taken to process a case)
• update work status frequently to communicate the state of the case.
• add a likelihood to each connector (even if it’s 100%)
• limit each assignment to a maximum of four connectors
• reuse standard flows and flow elements
• flow modeling is an iterative process of discovery, construction, and assessment.
• design first, configure later
  Shape names:
• labels in the flow
• business-friendly
• verb phrases
• reflect intent (task, action)

The Case Management Gallery, UI Gallery, and Process API include a number of customizable flows and flow elements that conform to Pega best practices, and can be used as-is, or configured as needed.