Case Design Flashcards
Case vs Process
1.
Case (what: a business transaction to resolve, a case is a business transaction we want to complete, moves through series of stages, provides visibility into the transactions
Process (how): the path a case may take, the path, or paths, the case follows as it is completed.
2.
All cases have at least one associated process, whether that process is formalized or not - or even structured or not. As a person works through a case, he or she is tracing a process for how to handle that case.
3.
Case has assigned: people, tasks, data (relevant documents and correspondences), status, a history of actions taken; and a resolution.
What is case management?
The management of these artifacts:
Case has assigned: people, tasks, data (relevant documents and correspondences), status, a history of actions taken; and a resolution.
Case management vs Process management
- Case:
The business transaction - the case - as it moves from one person to the other, from one part of the organization to another. “Work moves through stages and through milestones.” - Case: Holistic view of a business transaction from beginning to end. Not the traditional prcess management view: a series of forms to complete and individual, “atomic” processes controlled by business rules to follow.
- Case: allows the business to see, and interact with, the business transaction the way it moves through the organization.
- Process management is simply a way of ensuring a business transaction can be adapted to frequently changing business conditions.
- case management design principles allow you to define the business application based on the work that moves through your organization.
- Using a case management design approach, you have visibility into what is already defined in the application.
Reasons to adopt Case management design?
- maximizing business success requires understanding context
- visibility into what is already defined in the application and how each piece fits
- express and interpret business requireiments consistently
Best practices for case management design
- engage the business at the beginning and keep them engaged
- enter DCO information where and when its needed (always tie business and project goals, objectives, processes, specifications, and requirements to implementations)
- use an all-in-the-model design approach (shared understanding of the business transaction; dramatically cuts time to value; errors due to misinterpreted requirements are greatly reduce)
What is an application?
- are agile solutions for automating work
- contain related case types (few to several)
- named after the solution it provides
What is a case type?
- represent a specific/singular business transaction we want to automate
- named after the business transaction it represents
- use meaningful and relevant names, 1-2 words (application name is the context)
- represents a singular context
- top level or parent case types represent the goal(s) of the application
- Tasks and decisions needed to complete a business transaction.
- Representing a specific business transaction.
- A collection of Pega-related artifacts used to implement the tasks for a case.
What is a Stage?
- high-level grouping of tasks - the first level of case decomposition
- business stake-holders usually already have the stages identified and named.
- stages typically represent the transfer of the case from one authority to another, or from one part of the organization to another; or maybe a significant change in the status of the case.
Best practices for Stages?
- use names that are most meaningful and relevant to the business users.
- use a noun, or noun phrase, to describe the context of the stage
- limit the stage name to no more than two words
- consider limiting the number of stages in any given case type to 7 (plus or minus 2)
- finally, it is important to ask: What best practices are defined in your organization? Knowing, and following these best practices will help you make the most of your case management design efforts.
- start with identifying the stages – not the details of the case
- separate the “happy path” from the exceptions
Different stage types and their features?
- primary path stages
- alternate stages
x. resolution stages
“Primary path” stages:
- the case would pass through in a “normal course of events” and are generally free of exceptions. (happy path)
- can be configured to automatically transition to the next primary stage when all steps in that stage are complete or, set to manually transition to another stage by an end user or as defined in a process model
“Alternate stages”:
- not part of the “normal course of events” but must be available under certain circumstances – or exceptions to the normal course of events.
- can only be accessed manually, and therefore have no sense of sequence relative to other stages – there is no sense of being ‘next’
- if you have more than one alternate stage, there is no sense of order in the way they are presented. Alternate stages never imply a sense of order.
- can only ever use a manual transition to a next stage
“Resolution” stages:
- not a stage “type” but a stage “behavior,” or “classification.”
- both primary path stages and alternate stages can be defined as a “resolution” stage.
- provides a visual indicator that a case can be resolved, or closed, in that particular stage
- useful to understand that is where the case can come to a close.
- you can also have more than one resolution stage in the primary path or alternate stages
- a resolution stage has no functional behavior – other than setting the stage to a manual transition. Changing the status of a case, or closing the case completely must still be specifically called for in a step in the stage.
- can only ever use a manual transition to a next stage
“Legend”: from the “Actions” menu in the upper right corner of the Case Designer. Shows: The types of stages and their icon are presented on the left side.
