Pegasystems Product Implementations:

Use a standardized implementation methodology Are based on supporting business processes with a

broad set of reusable functionality Leverage existing software capabilities and maximize custom development Should not be a software development project Should not be an exercise on gathering and developing software features

2 Ways to satisfy user requirements

Match current legacy system/ processes Modify PRPC through extensive configuration Meet all relevant user requests that drive daily business operations Modify the organizations current business processes
Leverage the advanced functionality of PRPC Prioritize user requests based on sound business principles.

Anticipate Return On Investment (ROI) impact

Perform a cost/ benefit analysis to select the best approach
Expected benefits Expected costs = ROI

Choose the approach that maximizes ROI Is the expected cost budgeted?
If the available budget is insufficient, there are 2 choices:
1. 2.

Approve additional expenses Prioritize modifications and only complete those that can be achieved within budget

Defined Project Rules

Benefit: Tasks will be doe at the right time by the right

person Clearly define what tasks belong to what role Some roles are filled by multiple team members Additional roles are filled by key members of the user community

Defined Project Scope

Benefit: Right tasks will be accomplished, without

scope creep Base scope on key business drivers Business drivers and objectives should steer the entire project
Determine business processes based on business

objectives Determine requirements based on business processes Prioritize processes and requirements based on drivers and objectives

Drivers
Objectives Business Processes Requirements
Defined Activity Sequence
Benefit: Ensures orderly execution Manage the project timeline

Pega Implementation Methodology

Pega uses pega implementation

methodology

Helps pega align with the needs and goals of the

organization Accounts for end user adoption and training Helps keep the project on time and within budget Facilitates efficient communication between members of the implementation team Supports a phased implementation approach

Exercise 1
Goals :
Scenario:

To be able to alleviate customer concerns by providing a justification for the implementation methodology. As a business architect for a companies implementation project, the customer has asked you to justify your approach to the project.

Concern
1. 2. 3. 4. 5.

How can we b sure that we are focusing on the right requirements? How will we track our return on investment? Implementing this new application is great, but how can we make sure that people will actually use it? How will I be able to report progress to my internal stakeholders? Who is my contact person, and who can I talk to is that person is not available?

6. Why do we want to send out regular notices about

the project to end users? 7. Why are we spending so much time upfront to define the business? Can we just start configuring the application? 8. The project team has recommended that stakeholders should be actively involved in the process. The board doubts that they will have the time to do some of the activities the team is recommending, why is it important for them to be involved?

Justification of Implementation methodology

1. 2.

3.

4.

Business drivers and business objectives are identified early in the project, and these will steer all requirements. By stating some clear outcomes associated to business drivers and objectives, we can determine baseline metrics. We will also incorporate monitoring and measurement directly in business processes to compare against this baseline. Change management for end users is built into the methodology. It is important that we manage end user expectations for how the new application will positively impact their day to day work. The Implementation methodology facilitates regular communication between team members, as well as to project team members

Project roles ad responsibilities are clearly defined early in the project and communication to all project team members. Your contact person and backup contact person will be clearly defined. 6. This is one technique for ensuring end user buy in on the final product. Regular communication keeps them informed of any upcoming changes to business processes, and assures tat they have opportunity to offer their support. 7. In order to know exactly what business processes will be supported, we need to clearly define the current challenges to your business. Implementing the software alone will not solve your business problems. The solution needs to be targeted to your needs, and will include change management strategies in addition to application configuration.
5.

8. It is important that stakeholders buy in to the project

implementation process, and that they communicate to success to other levels of the organization. Some of the more hands on activities can be delegated to the director and manager levels based on the organization of your business units.

Successful PRPC Implementations

Are achieved by project teams that:
Adhere to a standardized implementation methodology

that uses a multi phased deployment approach Maximize return on investment (ROI) by building a strong reuse model into the design

Implementation Methodology Characteristics

Your Project methodology should:
Define each implementation stage, the deliverables for each

stage and the time frames for the stages Identify who is responsible for which components of the plan and how the plan is to be implemented Pegasystem methodology is based on Rational Unified Process(RUP) Helps identify ad address key strategic and tactical issues Helps develop an outline for the progress of the project Prescribes activity stages that are iterative in nature Enables the implementation team to bring the system up in phases so employees and customers can begin to use it quickly

Stages of the Pegasystem approach

BVA Conception
Business Value assessment

Elaboration
Construction Transition

defines the success factors and expected ROI Discover detailed business requirements and solutions Design solution tailored to the business requirements Build the application to meet business requirements Validate the application for the appropriate implementation of the business

Advantages of a Multi Phased Approach

Allow for manageable project size and scope
Helps achieve implementation benefits sooner Applies knowledge and experience from earlier phases

Business Value Model (BVA)

Quantifies the business value a customer can gain

from PRPC Develops a framework from projects that can be prioritized Provides a business case that will serve as the foundation for justifying current and future projects. BAs are Involved in this process

Goal is to establish a sound understanding of the scope of what is to be delivered

BA roles o As Is business model o To Be business model o Reporting o Use case Model SA roles o As Is Architecture model o To Be Architecture model

Goal is to establish the foundation requirements and design definition that serves as the base line design for the common components of solution

BA roles o Use Case package o Test strategy and testing plans (testing team assisted by BA)

SA role o Environment setup

Deliver the process commander solution with 3 iterations

First, second and third iteration done by the project

team. BAs can get involved in this process too.

Build Phase 1: BA and SA role

Case Structure
Develop Primary Flow Build Data Structure UI Placeholders Standard reports

Build the rule sets and

class structure Develop the primary flow Build generic processes and data structures Use out of box components to build UI structure Use out of box reports

Build Phase 2: BA and Developer role

Secondary and Exception flows

Complete the reusable

Place holder interface

Build custom reports

application by adding exception, secondary and abstract flows Develop the interfaces to a level where they are functionally independent Build custom reports

Build Phase 3: BA and SA role

Complete specialized flow Build decisions and calculations

Complete specialized

Build custom interface

Connect interface placeholders

application and flows Build the decision and calculation rules Build out custom flow actions and section layout screens Ensure that the interface can communicate successfully This is the final application which is ready to go to the QA team

Establish a production environment that is maintainable by IT and useable by the business community
Environment Migration SA role
QA/Testing team Business owners/sign off Project team

Process QA testing process

Production acceptance

process End user support and roll out

Methodology Adoption Workshop(MAW)

Are provided by pegasystems to explain how best to implement a PRPC solution
Helps map the pegasystems methodology to your organizations internal processes
Minimal : minimum you have to do in each phase Optimal : Optimum sequence for performing activities Not Optional : The activities which must be performed

BA Roles and Responsibilities

Business analysis and definition of functional

processes/rule in the system Gathering business requirements Mapping As Is and To Be business processes Designing flows Determine reporting needs Working with the testing team Conduct business walkthroughs

Exercise 2
Goals :
Scenario:

To describe components of the pegasystem Methodology. As a business architect for an implementation project, you need to be bale to describe the methodology you will use for this implementation.

Questions:
Describe the difference between the project manager and business architect roles on an implementation team. 2. Name two advantages to a multi phased implementation approach. 3. What is meant by the term Business Value Model (BVA) and how does it differ from ROI?
1.

Answers:
The project manager focuses on coordinating timelines and deliverables for all areas of the project and all project team members. The business analyst focuses on understanding the customers business processes, requirements, and solutions. 2. A multi phased approach facilitates manageable project size and scope, helps achieve implementation benefits as soon as possible, and increases success is subsequent phases by applying knowledge and experience from previous phases.
1.

3. The BVA quantifies the business value a customer

can gain from a PRPC deployment and based on this assessment develops a framework from which projects can be prioritized. In effect, the BVA provides a business case that will serve as the foundation for justifying current and future projects. ROI is a measure of success which can only truly be established after the project is completed.

Conception stage goals and best practices

Conduct a conception stage for complex, multi phase

projects. Get a higher, general picture

Determine customer enterprise implementation

requirements. Identify the overall implementation solution and identify business units or product modules for a phased approach

Learn as much about the customers business as

possible
Work directly with customer, stakeholders to verify business

drivers and objectives

 Obtain frequent confirmation with and sign off by the

business.
Facilitates decision making and drives the

implementation forward.

Review drivers and objectives include any drivers and objectives already identified y the sales team.
Elicit additional business drivers and objectives as

appropriate.

Present these objectives to users for validation.

Objective should be
S : pecific
M : easurable A : chievable

R : elevant
T : ime - based

BA activities in conception
Conduct executive interviews
Map business objectives to drivers Identify business processes Conduct first round workshops Build the conception document

Exercise 3
Goals :
Scenario:

Determine the business drivers and business objectives for he internal purchase request implementation. You were just provided with the project charter and you have to determine the business drivers and business objectives for the project.

Project Description:
Improve the internal purchase request process (they currently take on average 3 days to be processed). The company currently uses a homegrown application to provide this functionality. The homegrown system currently sends internal purchase requests to any number of individuals for approval. PRPC will change this focus to the Internal Purchasing group, which will additionally cut the time it takes for purchase requests to be processed in half.

Project Rationale:
PRPC has been successfully implemented in the HR department . PRPC will help define the internal purchase request process to ensure that requests are completed in a timely manner and are signed off by the correct individuals. If this implementation is met with success, the company will consider expanding the PRPC application to other parts of the organization.

Initiative/Strategy Supported:
This project is part of an initiative to improve customer satisfaction and relations. The goal is to first improve internal processes before deploying these changes to our customers to ensure success. The HR application has been successfully implemented and this project is next. If successful, the company will begin to implement this solution to the Home and Auto Insurance Quoting and Underwriting departments to improve processes there, where the customer satisfaction rating have been in the mid 70s. Wed like to improve those rating to 80% or higher.

Business Drivers
Internal purchase request

Business Objectives
Cut the amount of time it

process takes 3 days for a decision on average The Home and Auto Insurance Quoting and Underwriting departments have had customer satisfaction ratings in the mid 70s

takes to approve or reject a purchase request by 50% Ensure that customer feedback ratings show satisfaction measurements of 80% or higher.

Elaboration stage goals

The project team documents and refines the

functional and technical requirements The major deliverables include:

Detailed business requirements and solutions to direct

the work in the construction stage Use cases to add context and a narrative representation of business processes that facilitate test script writing, sign off, and user acceptance.

Develop detailed requirements

Additional elaboration stage workshops are driven by

the business process to maintain context and business focus.

Focus on each process independently in more detail

During workshops go through previous requirements

generated by each step in the process

Break down each requirement into supporting

requirements

Identify gaps for detailed requirements

Consult the SAs to determine if requirements are

supported by standard PRPC functionality Identify any gaps and determine a complexity rating for each
Usage gap : Requires light to moderate configuration of

standard functionality Functional gap : Ned to add to or significantly enhance standard functionality Capability gap : there is no standard PRPC functionality

Develop solutions for detailed requirements

Identify possible soltions for each detailed

requirement Determine configuration needed to address requirements

Work classes
Properties Flows

External interfaces

Types of information to gather

Define work objects
Define work pools Define properties Define the organizational structure Define reporting requirements Define localization requirements

Work Objects : Provides the foundation for the class hierarchy

SA will design reusable class hierarchy based on what work is going to be performed by the users of the system

Work Pools: Provides a grouping mechanism for related work

Known as a class group

It is common to group work into a work pool

Work types are similar in definition and purpose
Users want to see related work in a single report Users want to choose among the work types when entering or

searching for work Work needs to be converted from one type to another Associate each property with the Use case where it will be used Identify properties that are used by more than one work class

Organizational Structure
Organization Division
Unit Unit

Division
Unit Unit

Organizational Structure
Consists of 3 level of hierarchy
Organization Division Unit

Design to reflect your PRPC deployment An operator must belong to

An organization A division of the organization A unit of that division

Exercise 4
Goals :
Scenario:

Gather detailed requirements and build a requirements matrix based on an application proposal The company has given you an application proposal. Based on this document, build a requirements matrix, documenting the properties needed.

Consider this requirement: The purchasing section of the Finance department is responsible for handling all purchase requests at the company. In this phase of the implementation, the system will allow the conversion of purchase requests into purchase orders using PRPC.

When submitting a purchase request, the submitter must indicate their department. At this stage, purchase requests may only originate from the following departments: Accounting Education Human Resources IT Marketing and Sales

The following are requirements for the entry of purchase requests

Employees must specify the name of their department

on the order entry form. Each individual line item must include a proper description, quantity, unit price and total. Line item totals and grand totals should be calculated automatically. The maximum total amount of any purchase request is $500,000.

Based on the requirements, determine the following

Organizational Structure
Work Object(s) Work Pool(s)

Based on the requirements, complete the requirements matrix below:

# Use Case Name Description Applies To Types

Answer: Organizational Structure

Company

Finance

Purchasing

 Work Object(s):

Purchase Request
Work Pool(s):

Purchasing

# 001

Use Case PR 1

Name Department

Description Department of PR originator Repeating group of Line Items Item Description Price per unit Number of units Total Price

Applies to Purchase Request Purchase Request Date Class Date Class Date Class Date Class

Type Text

002

PR 1

Line Items

Repeating Group Text Decimal Integer Decimal

002.1 002.2 002.3 002.4

PR 1 PR 1 PR 1 PR 1

Description Price Unit Quantity Total

003

PR - 1

Grand Total

Total of all line items must <= $500,000

Purchase Request

Decimal

Construction stage goals

The project team begins building the application to

meet business requirements Deliverables

Three deployment iterations allowing the business

direct input into the system deployment

Activity Diagrams
Are used to model the workflow behind the system being designed

Often the flow may traverse multiple use cases

Are Industry standard

Defined by the Object Management Group(OMG)

Extract the business flow from the events specifies in the Use Case package Using Use Cases, isolate the primary flow, the normal course of events

Business Process Modeling Notation (BPMN)

Is a standardized graphical notation for drawing

business processes in a workflow

Maintained by the Object Management Group (OMG)

Used to communicate a wide variety of information to

a wide variety of audiences

Business users that create the initial drafts of the processes Technical developers responsible for implementing the

technology that executes the processes Business people that will manage and monitor the processes

Use Cases
Are a description of how end users will use the

system
They describe a task or a series of tasks that users will

accomplish using the software and includes the responses of the software to user actions

Are represented in three forms

Use Case diagrams Use Case specification documents Use Case activity diagrams

Using BPMN with PRPC

As Is and To Be flows are typically documented

using BPMN
Are generated during the Requirements Gathering

sessions Are contained in the conception stage documentation

BPMN is not used to document system flows Instead it is used to capture all steps of the process including
1. 2.

Manual Steps System Steps

Flow Objects
Event
Represented by a circle

Something that happens during the course of a business process

Usually have a cause(trigger) or an impact(result) Three types of events: Start, Intermediate and End

Activity
Represented by a rounded-corner rectangle Types of Activities: Task and Sub - Process

Gateway
Represented by a diamond shape
Used to control the divergence and convergence of sequence flow.

 Event Start Intermediate End Activity Task and Sub Process Gateway

Connecting Objects
Sequence Flow
Represented by a solid line with a solid arrowhead Used to show the order that activities will be performed in a process

Message Flow
Represented by a dashed line with an open arrowhead
Used to show the flow of messages between two separate process

participants that send and receive them

Association
Represented by a dotted line with a line arrowhead
Used to associate data, text and other artifacts with flow objects

Swim Lanes
Pool
process Acts as a graphical container for partitioning a set of activities from other pools Used when the diagram involves two separate business entities or participants and are physically separated in diagram
Name Name Name
Represents a participant in a

Lane
Sub Partition within a Pool Used to organize and categorize

activities

Artifacts
Data Objects
Mechanism to show how data is

required or produced by activities Connected to activities through associations

Name [State]

Group
Can be used for documentation

or analysis purposes Does not affect the Sequence Flow

Annotation
Mechanism to provide

additional text information for the reader of a BPMN diagram

Text annotation allows a modeler to provide additional information

Exercise 5
Goals : Document the As Is Process and design the To Be process for the internal Purchase Request Implementation Youve just conducted a Business Process Workshop and documented the steps in the As Is Process and the requirements for the new Implementation

Scenario:

As Is Process

The current Purchase Request process is based on a homegrown application that was developed at the company several years ago. It flows as follows: The requestor of the purchase request logs into the homegrown system and creates the purchase request. The purchase request then gets assigned to an account for the Finance Department. The requestor never sees the purchase request in the system. At some point every day, someone from the finance department logs into the Purchase Request application to see if any new purchase requests have been entered If there are new purchase requests, the Finance representative has to manually calculate the total amount of the Purchase request Often times, there are incorrect characters or amounts entered in the purchase request as there is no validation to what is entered

Requirements
Description Ensure employee enters all of the required information Automate as many steps as possible Speed up the cumbersome homegrown system Ensure all PRs are properly filed for auditing purposes Calculate the PR totals automatically Ensure end users cannot enter bad or incorrect values on the PR Do not allow end users to create PRs over $500,000 Ensure PRs are processed expeditiously by making a manager process a request within one business day Offer a $100 voucher (for future purchases) to the education department if it spends at least $5000 Priority High High High Medium Medium High Medium High Low

Ensure all managers either approves or rejects PRs in a timely manner High

Description If a PR is rejected, notify the requestor of the rejection and allow them to edit the existing PR and send it back to their manager automatically Automatically determine the manager of the requestor in the system Finance should only receive the PR until after it is approved by the requestors manager

Priority Medium

High High

 Once the finance representative cleans up and finishes the

purchase request, they open another application to determine who is the manager of the requestor They then send email to the manager asking for approval of the Purchase request Whenever they hear back from the manager, they update the Purchase request in the system as being Approved or Rejected and then send an email to the requestor to notify them of the resulting status If the purchase request is rejected for any reason, the requestor needs to call his manager to find out why and then submit a new purchase request rather than update the existing one that already exists in the system.

AS IS Internal Purchase Request Process

Request System Manager Finance Dept.

To Be Internal Purchase Request Process

Request System Manager Finance Dept.

As Is Internal Purchase Request Process

Request Start
Submit PR` Work with Finance PR

No
Get answer Appr oved ?

End Yes

Finance Dept.

Yes
Review s PRs

Is PR valid?

Determine manager

Email Manager

Receive answer and notify requestor

Manager

Receive email

Approve or Reject PR

Email Finance with answer

System

To Be Internal Purchase Request Process

Request Start
Submit PR Make changes and Re - submit

Finance Dept.

No
Notified of Accepted PR

End
Submit paperwork

Yes
Approve or Reject PR Appr oved?

System

Manager

Determine Manager

Move to worklist of Manager

To Be Internal Purchase Request Process

Requestor

Start

Enter PR

Fin. Dept.

No
Notify requestor with a reason Review PR

Manager

No
Appr oved ?

End Yes
Notify Financ e dept.

Calculate PR total System

Yes Yes No
Determine Manager >1 Day?

No
Edu. & >5000? Sending filing notification

Yes

Valid & <= 500,000 ?

Offer $100 voucher

Yes

No

Using Use Cases with PRPC

A Use Case is a definition of a meaningful interaction with

a computer system Use Cases are represented as:

Diagrams o Shows the relationships between the parts of the system being used and the order in which they are used Specifications
o Details the steps taken in each part of the interaction

Activity Diagrams
o Diagrams the steps taken in each interaction documented by a

specification

Use Case
Is drawn as an oval
Models a dialogue between a user and the system

Use Case

Actor
Are drawn as Stick Men
Represent users or systems that use or interface with

the system, such as:

Employee

Actor

Cost Center Manager

HR Manager

Relating Actors and Use Cases

An actor may use many Use Cases

A Use Case may interface with many Actors

We draw a simple line to indicate interaction The arrowhead indicates who initiates the interaction

Employee

Enter Leave Request

Cost Center Manager

Management Approval

Include Use Cases same piece of Is used when use cases share the
functionality
The second Use Case is always invoked as part of the execution of

the first Is drawn with an arrow pointing to the Use Case that is included, with the label <<include>>tagged to the line <<include>> Enter Leave Request <<include>>

Enter Dates Required

Update Leave Request

Extending Use Cases

Used when the second Use Case is only called

occasionally
Often used to support an alternative path or an execution

Is drawn with an arrow pointing to the calling Use

Case <<Extend>>

Approve Leave Request

HR Approval

Use Case Specifications

Are detailed sequences of user behavior
Contain primary and alternative paths of user interaction

Detailed Use Cases are essential to prevent vagueness

later in the analysis and design process

The level of description offered by Use Case specifications is

suitable for showing to the users of the system

Preamble
Use Case ID : A unique number given to each UC Use Case Name : The name used when referring to this UC Description : A high level description of the UCs Actors : Defines users or systems that use or interface with

the system Preconditions : Any conditions that must be met prior to beginning this UC Post Conditions : Any conditions that must be met after completing this UC Frequency of use : How often this UC will be used

Example of a preamble
Use Case ID : LR -2 Description : Actors : Preconditions : Post conditions : Frequency of Use : Use Case Name : Management Approval Allows the manager approve or reject the leave request Cost Center Manager None (in this case) None (in this case) Sporadic, can be busy at certain times of the year

Primary Path
The normal course of events which occur in relation to

the Use Case also known as the Happy Path

Normal Course of Events 1. Cost center manager logs into PRPC 2. Cost center manager selects a leave request from the list 3. Cost Center Manager reviews and approves the leave request

Alternative Paths
The alternative course of events which may occur in

relation to the Use

Alternative Course of Events

3a. Cost center manager reviews and rejects the leave request

Closing
Associated Use Case diagrams
Lists the diagrams in which this Use Case appears

Exceptions
Details any extension Use Cases

Includes
Details any included Use Cases

Special Requirements
Details any special requirements for this Use Case

Assumptions
Details any assumptions made when documenting this Use Case

Notes and Issues

Documents any additional pertinent information

Example of Closing
Associated Use case diagrams :
Exceptions : Includes : Special Requirements : Assumptions : Notes and Issues

Name the diagram

If the Leave Request is over 15 day, calls another relevant Use Case None (in this case) None (in this case) All departments will use the same process None (in this case)

Exercise 6 - 1
Goals : Scenario: Create a Use Case diagram. Now that you have built the To Be process, use that process and the requirements to create the requirements to create the Use Case diagram.

Description Ensure employee enters all of the required information Automate as many steps as possible Speed up the cumbersome homegrown system Ensure all managers either approves or rejects PRs in a timely manner Ensure all PRs are properly filed for auditing purposes Calculate the PR totals automatically Ensure end users cannot enter bad or incorrect values on the PR Do not allow end users to create PRs over $500,000 Ensure PRs are processed expeditiously by making a manager process a request within one business day Offer a $100 voucher (for future purchases) to the education department if it spends at least $5000

Priority High High High High Medium Medium High Medium High Low

Description If a PR is rejected, notify the requestor of the rejection and allow them to edit the existing PR and send it back to their manager automatically Automatically determine the manager of the requestor in the system Finance should only receive the PR until after it is approved by the requestors manager

Priority Medium

High High

Answer
Enter Purchase Request

Employee Manager Approval <<Extent>>

Manager

Finance Approval Finance

Validation
Ensure that data inserted into the application satisfies predetermined formats and other defines input criteria
Client side Validation Server side Validation

Client Side Validation

Processing takes place on the client
User enters data into a field A script is run within the web browser
1. 2.

If valid data, user proceeds to next step If not valid, user is not allowed to proceed

Server Side Validation

Processing takes place on the server
User enters data into a field User makes a request to move to ext step Request is sent to server Data is then validated on server
1. 2.

If valid data, user proceeds to next step If invalid, user is not allowed to proceed