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.

there are 2 choices: 1.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. 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.

3. 4. 2. 5. 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. 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. and who can I talk to is that person is not available? .Concern 1.

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

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

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

Some of the more hands on activities can be delegated to the director and manager levels based on the organization of your business units. . It is important that stakeholders buy in to the project implementation process. and that they communicate to success to other levels of the organization.8.

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 .

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 .Implementation Methodology Characteristics  Your Project methodology should:  Define each implementation stage.

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. BA’s 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 .

.

.  BA’s can get involved in this process too. second and third iteration done by the project team.Deliver the process commander solution with 3 iterations  First.

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 .

secondary and abstract flows  Develop the interfaces to a level where they are functionally independent  Build custom 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.

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” .

.

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

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

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

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. ROI is a measure of success which can only truly be established after the project is completed. the BVA provides a business case that will serve as the foundation for justifying current and future projects.

general picture  Determine customer enterprise implementation requirements.Conception stage goals and best practices  Conduct a conception stage for complex. stakeholders to verify business drivers and objectives .  Identify the overall implementation solution and identify business units or product modules for a phased approach  Learn as much about the customer’s business as possible  Work directly with customer. multi – phase projects. Get a higher.

 Elicit additional business drivers and objectives as appropriate.  Facilitates decision – making and drives the implementation forward.  Present these objectives to users for validation. .  Review drivers and objectives  include any drivers and objectives already identified y the sales team. Obtain frequent confirmation with and sign off by the business.

based .Objective should be  S : pecific  M : easurable  A : chievable  R : elevant  T : ime .

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

.

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

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

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.Project Rationale: PRPC has been successfully implemented in the HR department . . 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 HR application has been successfully implemented and this project is next. where the customer satisfaction rating have been in the mid – 70’s. the company will begin to implement this solution to the Home and Auto Insurance Quoting and Underwriting departments to improve processes there. We’d like to improve those rating to 80% or higher. The goal is to first improve internal processes before deploying these changes to our customers to ensure success. If successful.

.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 – 70’s 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. and user acceptance. sign off.

 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 .Develop detailed requirements  Additional elaboration stage workshops are driven by the business process to maintain context and business focus.

Identify gaps for detailed requirements  Consult the SA’s 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 .

.

documenting the properties needed. build a requirements matrix. .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.

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

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

000. unit price and total.  Each individual line item must include a proper description.  Line item totals and grand totals should be calculated automatically. .The following are requirements for the entry of purchase requests  Employees must specify the name of their department on the order entry form. quantity.  The maximum total amount of any purchase request is $500.

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 .Based on the requirements.

Answer: Organizational Structure Company Finance Purchasing .

 Work Object(s): Purchase Request  Work Pool(s): Purchasing .

2 002.3 002.000 Purchase Request Decimal .# 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.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.1 002.

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 .

isolate the primary flow.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. 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 .

Manual Steps System Steps . 2.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.

. Intermediate and End  Activity  Represented by a rounded-corner rectangle  Types of Activities: Task and Sub .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.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 .

text and other artifacts with flow objects .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.

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 You’ve 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. The requestor never sees the purchase request in the system. At some point every day. there are incorrect characters or amounts entered in the purchase request as there is no validation to what is entered . It flows as follows: The requestor of the purchase request logs into the homegrown system and creates the purchase request. 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 purchase request then gets assigned to an account for the Finance Department. the Finance representative has to manually calculate the total amount of the Purchase request Often times.

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 .

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 requestor’s manager Priority Medium High High .Description If a PR is rejected.

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. . Once the finance representative cleans up and finishes the purchase request. 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 PR’s 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 UC’s  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 reviews and approves the leave request . Cost center manager selects a leave request from the list 3. Cost center manager logs into PRPC 2.

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) .

.

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

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 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.

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 requestor’s 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. If valid data. 2. user is not allowed to proceed . user proceeds to next step If not valid.

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. If valid data. user proceeds to next step If invalid. user is not allowed to proceed . 2.

Sign up to vote on this title
UsefulNot useful