28
Process Redesign Stages Developing Business Vision Understanding the Existing Business Designing the New Business Installing the New Business

Process Redesign Stages Developing Business Vision Understanding the Existing Business Designing the New Business Installing the New Business

Embed Size (px)

Citation preview

Process Redesign StagesProcess Redesign Stages

Developing Business Vision

Understanding the Existing Business

Designing the New Business

Installing the New Business

Case for Action ElementsCase for Action Elements

The Company’s EnvironmentThe Customer’s ExpectationsThe Competitors’ ResponsesThe Companies Business DifficultiesThe Company DiagnosticsThe Risk of Inaction

Activities of ReengineeringActivities of Reengineering

Envisioning

Reversing the Existing Business

Engineering theNew Business

Installing the New Business

Business Development

Reengineering Directive

The Reengineered Corporation

EnvisioningEnvisioning

StrategyUnderstanding the Existing Business

CustomerDemands

Benchmarking

Model of the Existing Business

Reengineering Directive

Objective Specification

Business ModelingBusiness Modeling

Business Process (use case) Internal Process (business object)Deliverables (object)Work Flow

Use Case ModelUse Case Model

External Model– Satisfies the external customer

The Business SystemThe ActorsThe Use Cases

Use Case ModelUse Case Model

Good, comprehensive picture of what the business should do.

Does not show internal structures needed to support

Does not explain how to realize the activities

Use CaseUse Case

Collection of possible interactions between the system under discussion and its external actors, related to a particular goal.

Clause 1– All the interactions relate to the same goal

Clause 2– Interactions start at the triggering event and end

when the goal is delivered or abandoned, and the system completes its responsibilities with respect to the interaction

Use Case redefinedUse Case redefined

A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system’s declared responsibilities, showing how the primary actor’s goal might be delivered or might fail.

ScenariosScenarios

A sequence of interactions happening under certain conditions, to achieve the primary actor’s goal, and having a particular result with respect to that goal. The interactions start from the triggering action and continue until the goal is delivered or abandoned, and the system completes whatever responsibilities it has with respect to the interaction.

ActorsActors

Primary actor– Has a goal requiring assistance of the

systemSecondary actor

– One from which the system needs assistance to satisfy its goal.

One is designated system under design

Interaction modelInteraction model

Each actor has a set of responsibilitiesSets goals to fulfill responsibilitiesReach goals through actionsAction triggers interaction with actor Interactions invoke a hierarchy of goals,

responsibilities, actions, etc.

Characteristics of a Use CaseCharacteristics of a Use Case

Primary Actor or actorsGoalScenarios used

Characteristics of ScenarioCharacteristics of Scenario

Primary actorGoalConditions under which scenario occursScenario result or outcome (goal

delivery or failure)

Example - ScenarioExample - Scenario

System under discussion: the insurance company

Primary actor: me, the claimantGoal: I get paid for my car accidentConditions: Everything is in orderOutcome: Insurance company pays

claim

Example – Scenario contd.Example – Scenario contd.

Insurance company verifies claimant owns a valid policy (failure may mean goal failure)

Insurance company assigns agent to examine case

Agent verifies all details are within policy guidelines (interaction between agent and secondary actors)

Insurance company pays claimant (implies all preceding goals succeeded)

Controlling Scenario ExplosionsControlling Scenario Explosions

Variations– Often a section of use case text

• Payment types (cash, check, credit card)

Subordinate use cases– Each step is a use case. Apply hierarchical

decompositionExtensions

– Alternate use cases ( to handle failures)

Example – Use CaseExample – Use Case

System under discussion: the insurance company Primary actor: the claimant Goal: Get paid for car accident Steps:

1. Claimant submits claim with substantiating evidence2. Insurance company verifies claimant owns a valid policy3. Insurance company assigns agent to examine case4. Agent verifies all details are within policy guidelines5. Insurance company pays the claimant

Example – Use Case contd.Example – Use Case contd.

Extensions1. Submitted data is incomplete

1. Insurance company requests missing information

2. Claimant supplies missing information

2. Claimant does not own a valid policy1. Insurance company denies claim, notifies

claimant, records information, terminates proceedings

Example – Use Case contd.Example – Use Case contd.

3. No agents are available at this time1. (Where have they all gone?)

4. Accident violates basic policy guidelines1. Insurance company denies claim, notifies

claimant, records, terminates proceedings

2. Accident violates some minor policy guidelines1. Insurance company begins negotiation with

claimant for payment

Example – Use Case contd.Example – Use Case contd.

Variations1. Claimant

1. Person

2. Another company

3. Government

5. Payment1. Check

2. Inter-bank transfer

Use CaseUse Case

Levels of goalsLevel 1: Strategic & Systems Scope

– Benefits project sponsor, organizationLevel 2: User goal

– Summary goals, user goals, subfunctionsLevel 3: Interaction details

– Semantic interface

Goal refinementGoal refinement

Strategic-scopeSummary Goal

Strategic-scopeUser Goal

System-scopeSummary Goal

System-scopeUser Goal

System-scopeSubfunction

Structure of Use CasesStructure of Use Cases

Summary Goal

Summary Goal

SubfunctionSubfunction

User GoalUser GoalUser Goal

Summary Goal

Objects of BusinessObjects of Business

Three types of objects Interface objectsControl objectsEntity objects

Interface ObjectInterface Object

Represent set of operations Each performed by one & same resource Communicates with external environment Participate in several use cases Has coordinating responsibility

Control ObjectControl Object

Represent set of operationsLife span similar to use caseRepresent special tasksParticipate in several use casesHas no coordinating responsibility

Entity ObjectEntity Object

Represent occurrences of products and things

Exists throughout the life span of business

E.g., Product, Invoice, Order