Page i
California Department of Technology
Business Process Reengineering Framework
Business Process
Reengineering
Framework
State of California
California Department of Technology
Business Process Reengineering Framework
Contents
Overview
3
Overview of the CA-BPR
7
Framework Conventions and Structure
12
Alignment to Other Frameworks
14 BPR Knowledge Areas
Templates
3
Approach
7 CA-BPR Templates
Concept
3
Approach
7
Knowledge Areas
28
Process Phase Checklist
Page ii
California Department of Technology
Business Process Reengineering Framework
Document Control
Version History
Document history and version control is used to record detail of minor and
major changes to the California Business Process Reengineering Framework
(CA-BPR).
Version # Date Author Changes
1.0 7.18.2017 CDT Initial Publication
Page v
California Department of Technology
Business Process Reengineering Framework
Overview
This chapter provides an overview of the
California Business Process Reengineering
Framework, its purpose and use, and how it
will help you with your projects.
Overview | Page 1
3
California Department of Technology
Business Process Reengineering Framework
In this chapter...
Overview
1
Overview of
the CA-BPR
Framework
Page 3
1.1 Purpose and
Use of the
CA-BPR
1.2 The Value of
the CA-BPR
1.3 A Thoughtful
Approach
to BPR
2
Framework
Conventions
and Structure
Page 7
2.1 Colors and Icon
Conventions
2.2 Chapters
2.3 Key Navigation
Elements
2.4 Call-Out Boxes
3
Alignment
to Other
Frameworks
Page 12
3.1 Related
Frameworks
4
BPR
Knowledge
Areas
Page 14
4.1 Purpose of
Knowledge
Areas
4.2 BPR Knowledge
Areas
Overview | Page 2
California Department of Technology
Business Process Reengineering Framework
Overview
Overview of the CA-BPR Framework
Page 1
Technology is a transformative element within California state government
used to achieve improvements to its business. And while technology solutions
alone can produce outcomes, optimization of the related business processes
can maximize the realization of eiciencies and benefits. Technology
implementations demand varying degrees of change to business processes
within and across an organization. It is important for projects to plan, assess,
design, and optimize their business processes to leverage and maximize the
capabilities of technology.
To aid state organizations in this eort, the California Project Management
Oice (CA-PMO) has developed the California Business Process Reengineering
Framework (CA-BPR or BPR Framework) to provide practitioners with a solid
foundation to successfully eect business process changes within their
organization. The CA-BPR provides guidance on Business Process Reengineering
(BPR) methods and approaches through the use of resources, tools, and
templates, as well as narratives describing when specific BPR activities should
be performed throughout the Project Management Lifecycle (PMLC).
While the CA-BPR Framework is written in the context of information technology
(IT) implementation eorts, it is applicable to any type of project that requires
changes to an organization’s business processes. This must be done with
a thoughtful approach that navigates California’s unique environment and
characteristics. This framework aligns to and can be used with the California
Project Management Framework (CA-PMF) and the California Organizational
Change Management Framework (CA-OCM or OCM Framework).
1.1 Purpose and Use of the
CA-BPR
Business Process Reengineering is a specific process improvement approach
introduced by Michael Hammer and James Champy in the early 1990s. BPR
employs the fundamental redesign of business processes to achieve major
improvement over a relatively short amount of time. Because improvement
goals are larger than those of incremental improvement strategies including
Overview | Page 3
California Department of Technology
Business Process Reengineering Framework
Overview
Total Quality Management and Six Sigma, BPR embraces technology as a
cornerstone of the approach. The CA-BPR provides a roadmap to conduct BPR
to improve an organization’s performance in areas such as service, cost, and
quality. The CA-BPR includes recommended practices, activities, tools and
templates, as well as leverages multiple industry standards and resources.
The intended audience for the CA-BPR includes practitioners responsible for
performing or managing BPR activities, roles that may be held by state and/or
contractor resources. The CA-BPR also provides useful information to project
sponsors, project participants, and Stakeholders regarding BPR concepts and
best practices. Practitioners should leverage these tools and templates, as
applicable, and modify them to fit their specific project needs.
Projects vary in size, type, and complexity. No matter what a project’s size or
complexity, the objective(s) of BPR remains consistent; however, the approach
and methods may dier to meet a specific project’s needs. BPR practitioners
should adjust the level of complexity and rigor to match the needs of an
individual project. The CA-BPR provides guidance and adaptability to account
for these project dierences.
1.2 The Value of the CA-BPR
The CA-BPR provides a common foundation for state organizations to leverage
and apply to project implementation eorts, to strive for a level of eiciency
and consistency in BPR practices across the state. The many benefits include:
1. A guide for BPR Practitioners across a range of experience levels,
with practical language that is easy to understand and use.
2. A BPR framework, nomenclature, and toolset with templates,
examples, and instructions that can be customized to meet dierent
project needs, but are structured to be consistently applicable across
a wide range of project types, sizes, and complexities.
3. Guidance based on BPR standards, industry best practices, and
lessons learned.
4. A statewide BPR perspective that addresses the relationships between
project management activities, organizational change management
activities, project approval lifecycle activities, and system
development activities.
Overview | Page 4
California Department of Technology
Business Process Reengineering Framework
Overview
1.3 A Thoughtful Approach
to BPR
The CA-BPR oers a set of useful tools and techniques to provide a structured,
disciplined, and repeatable approach to BPR. Though a set of tools and
techniques can increase the likelihood of success, BPR also requires the
appropriate skills and experience to apply them. The ultimate success of a BPR
eort depends on the knowledge, skills, and abilities of the BPR Practitioner.
Every BPR eort should have a common goal of achieving improvements
in performance: reduced costs, improved services, increased revenue, and/
or improved quality including a potential need driven by large scale system
changes. In leading these eorts, the BPR Practitioner should possess the
knowledge, skills, and abilities described below:
Knowledge
• Operational knowledge. Eective decision-making relies on past
experience and knowledge. The BPR Practitioner oen draws upon
his/her knowledge and experience of an organization’s operations to
ask relevant questions, draw out required detail, and design the most
eective processes.
• Technology knowledge. An eective BPR Practitioner should have an
understanding of various technologies and their potential applications.
Furthermore, understanding an organization’s existing technology
applications and infrastructure enables the BPR Practitioner to
bridge the potential communication gap between operational and technical
resources.
• Business process concepts and methodology knowledge. While the
CA-BPR describes key concepts, it is important for the BPR Practitioner
to have BPR experience in order to eectively apply BPR activities, tools,
and templates.
• Organizational change management knowledge. Oen, the BPR
Practitioner works closely with the OCM Practitioner. Having an
understanding of OCM concepts and principles helps the BPR Practitioner
know when and where to leverage the OCM resources on a project.
Overview | Page 5
California Department of Technology
Business Process Reengineering Framework
Overview
Skills
• Collaboration and negotiation. The BPR Practitioner should demonstrate
an ability to foster collaboration among a variety of business and
technical resources from an organization. Oen, the practitioner must
help negotiate potential solutions to address potential gaps between
the business and technology.
• Facilitation. Facilitation skills and techniques enable the practitioner to
focus attention and elicit an appropriate level of detail during working
sessions. These skills help maximize the productivity of resources.
• Interviewing. Strong interviewing and listening skills are critical for
obtaining a correct understanding of current business processes,
Stakeholder priorities, and requirements.
• Problem-solving. The BPR Practitioner identifies business problems,
assesses those problems, and determines the most appropriate solutions.
The BPR Practitioner routinely uses problem-solving throughout the project
and draws upon past experience to aid in decision-making.
Abilities
• Grasp new concepts. The BPR Practitioner oen does not have the subject
matter expertise on a specific business process. The BPR Practitioner must
be able to actively listen, learn, and appropriately apply new concepts when
documenting current processes and designing future states.
• Create visual representations of business processes. A critical ability for a
BPR Practitioner is to capture information from Stakeholders and eectively
translate it into a visual model for analysis and validation. The accuracy of
the models enables the project team to make informed decisions regarding
the design of the future solution.
Overview | Page 6
California Department of Technology
Business Process Reengineering Framework
Overview
Framework Conventions and Structure
Page 2
This section of the CA-BPR describes the conventions and structure that is used
throughout. The graphical elements, strategic use of color, and call-out boxes
are used to clearly communicate practical BPR concepts, as well as engage the
reader’s attention and improve information retention. The structure of the CA-
BPR also organizes information through the use of chapters, knowledge areas
(which are described later in this chapter), and key navigational elements to
guide the reader.
2.1 Colors and Icon Conventions
Each chapter of the CA-BPR correspond to the process phases of the PMLC and
is identified with a specific color and distinct icon. These unique colors and
icons are presented at the beginning of each chapter and continue throughout
to visually guide readers as they progress through the document.
Groupings of related BPR activities are organized into knowledge areas. These
serve to organize sets of BPR activities that share a common objective and
purpose. Activities from multiple knowledge areas may occur within a single
process phase. These knowledge areas are represented by their own icons and
colors placed below each PMLC process phase chapter header. The methodical
use of color is designed to help readers navigate the CA-BPR quickly and easily.
Icons used throughout this framework are shown by grouping for your reference:
Recommended
Practices
Inputs
Roles
Skills
Activities
Tools
Outputs
Overview | Page 7
Project Management
Lifecycle
Concept
Initiating
Planning
Executing
Closing
California Department of Technology
Business Process Reengineering Framework
Overview
Business Process
Re-engineering
BPR Lifecycle
Management
Business Analysis and
Future Definition
Business Process Design
Performance
Measurement
Overview
Templates
Additional Resources
Overview | Page 8
California Department of Technology
Business Process Reengineering Framework
Overview
2.2 Chapters
The CA-BPR is comprised of eight chapters. These chapters organize content
into logical domains to help readers easily navigate the document. The eight
chapters of the CA-BPR Framework are:
Overview
This initial chapter provides an introduction to the CA-BPR and its
purpose and use. It discusses how specific icons and colors are used
to facilitate navigation. It also oers a high-level overview of the BPR
lifecycle and knowledge areas that are a core part of the BPR Framework.
Templates
This chapter contains information about the collection of templates
that are available to help the BPR Practitioner successfully conduct
BPR activities.
Concept
This chapter helps the BPR Practitioner determine the basis of the
eort by first identifying whether BPR is the correct approach and
beginning the development of the business case.
Initiating
This chapter focuses on justifying the BPR eort by clearly defining
the business issues and opportunities for improvement.
Planning
This chapter provides information on how to establish the future
state at a high level and determine performance targets for those
business processes.
Executing
This chapter describes principles and activities to fully develop the
future state processes such that they can be implemented.
Closing
This chapter provides guidance for closing the project and
transitioning to support and continuous improvement.
Additional Resources
This chapter provides resources to support the CA-BPR. It includes a
glossary of project roles and common BPR terms.
Overview | Page 9
California Department of Technology
Business Process Reengineering Framework
Overview
2.3 Key Navigation Elements
The CA-BPR contains seven categories of information to help the BPR
Practitioner navigate the framework. These categories, referred to as key
elements include:
Recommended Practices
Techniques or methods that, through experience and research, help
achieve a desired result.
Inputs
Information and/or documents that feed into a process.
Roles
Roles for project Stakeholders, including a list of key responsibilities
associated with process phase and knowledge area activities.
Skills
Special or unique human expertise that should be applied to achieve
a successful project outcome.
Activities
Actions or activities for BPR practitioners to undertake.
Tools
Templates or other resources to help create project outputs. Templates
are documents that have been pre-developed for project use.
Outputs
Work products that are developed.
Overview | Page 10
California Department of Technology
Business Process Reengineering Framework
Overview
2.4 Call-Out Boxes
Throughout the CA-BPR, “call-out” boxes are used to bring attention to
information that further supports the narrative. These graphics have been
integrated into the document to highlight useful information at a glance.
Examples of call-out boxes may include:
• Navigation elements: recommended practices to consider, roles involved,
knowledge areas, activities to undertake, tools available for assistance,
and outputs to create
• Skills that are helpful for a particular process
• Website links or other references for additional information
• Guidance on when to use a tool based on project complexity
• Quotes and tips that are called out for greater emphasis
Recommended
Practices
Review recommended
practices at the start of
the process phase.
Inputs
The following is an
input to the activity:
• Organizational
Process Assets
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Skills
Use the following skills to
complete the activity:
• Interviewing
• Facilitation
Tools
A template is available:
BPR Approach Assessment
Outputs
The following is an
output to the activity:
• Identified
Customer Needs
Web Link/ Info
See the Schedule
Management section
within the Planning
Chapter of the CA-PMF.
i
If the root causes are not
well understood and/or
there is a lack of well-
documented evidence,
the business case will
not be compelling.
Overview | Page 11
California Department of Technology
Business Process Reengineering Framework
Overview
Alignment to Other Frameworks
Page 3
3.1 Related Frameworks
The CA-BPR aligns with the CA-PMF and other frameworks that support the
project implementation eort. It is important to recognize the integration points
between the dierent frameworks and their associated lifecycles. The BPR
lifecycle spans throughout the entire PMLC and refers to a series of activities
that are conducted to transform and improve the way an organization conducts
business. This design accommodates projects that vary in size, complexity, and
type, and all project BPR eorts can be aligned to the PMLC structure.
In addition to the PMLC, the BPR Lifecycle also aligns with:
• Organizational Change Management (OCM) Lifecycle
• Project Approval Lifecycle (PAL)
• System Development Lifecycle (SDLC)
During project implementations, the BPR Lifecycle, PMLC, OCM Lifecycle, and
SDLC may support one another and oen occur in parallel. Figure 3-1 depicts the
BPR Lifecycle in association with the other lifecycles. The successful management
of each lifecycle can greatly aect the others and contribute to the success of the
overall project. In addition to these lifecycles, California has adopted the Project
Approval Lifecycle (PAL) to improve the quality, value, and likelihood of success of
technology projects undertaken by the State of California.
Overview | Page 12
California Department of Technology
Business Process Reengineering Framework
Overview
Project Management Lifecycle (PMLC)
Overview | Page 13
Figure 3-1
ClosingExecutingPlanningInitiatingConcept
System Development Lifecycle (SDLC)
Project Approval Lifecycle (PAL)
Business Process Reengineering (BPR) Lifecycle
Organizational Change Management (OCM) Lifecycle
Project Appro
Project Appro
California Department of Technology
Business Process Reengineering Framework
Overview
BPR Knowledge Areas
The CA-BPR is comprised of four knowledge areas. A knowledge area is an area of
specialization that groups a set of BPR activities that share a common purpose
and objectives and can span across multiple PMLC process phases. This section
describes the four BPR knowledge areas including the purpose, objectives, and
timing within the PMLC.
4.1 Purpose of
Knowledge Areas
The purpose of the BPR knowledge areas is to define what the BPR Practitioner
needs to understand and the associated activities to perform. It is important
to note that knowledge areas and their associated activities oen have
interdependencies and interrelationships with other BPR knowledge areas. The
four knowledge areas of the CA-BPR are:
• BPR Lifecycle Management
• Business Analysis and Future Definition
• Business Process Design
• Performance Measurement
The CA-BPR provides guidance on when specific knowledge area activities
should occur during a project. Each BPR Practitioner will need to determine
applicability and align BPR activities to the specific needs of a project. Guidance
on tailoring BPR eorts to specific projects and project needs is provided
throughout the CA-BPR.
Overview | Page 14
4.2 BPR Knowledge Areas
Knowledge areas span multiple process phases and occur at dierent times
during the PMLC. Figure 4-1 identifies the BPR knowledge area goal within
each process phase where there are associated activities. Additionally, a single,
overarching goal is presented for each knowledge area.
va
l Lifecycl
e
Concept Initiating Planning Executing Closing
Identify
Performance Baseline
Define
Performance Reports
Generate
Performance Reports
Performance
Measurement
Ensure Improvements are Measurable
Determine
Future Measures
and Performance
Understand
Current Processes
Identify
Business Impact
Define
Future Processes
Elaborate
Future Processes
Business
Process Design
Ensure the Future State is Established
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Ensure the Future State is Sound
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Ensure the Performance of the BPR Eort
California Department of Technology
Business Process Reengineering Framework
Overview
Figure 4-1
The following provides a brief description of the four BPR knowledge areas:
BPR Lifecycle Management
BPR Lifecycle Management focuses on managing the performance of the BPR
eort through planning and scheduling activities. These activities guide the
direction and govern the sequence and resourcing of all other knowledge area
activities. BPR Lifecycle Management requires continuous coordination with
the Project Manager to ensure the BPR eort is integrated with other project
activities and milestones.
Overview | Page 15
California Department of Technology
Business Process Reengineering Framework
Overview
Business Analysis and Future Definition
During Business Analysis and Future Definition, the BPR Practitioner ensures the
viability of the future state through analysis of the structure, mandates, policies,
and operations of an organization, and development of the future vision.
The principle benefit of business analysis is to understand an organization’s
current environment, thereby creating a foundation based on documented and
validated facts.
Business Process Design
The focus of the Business Process Design Knowledge Area is to ensure that the
future state is achieved through the reengineering and modeling of business
processes to improve eiciency, eectiveness, quality, and/or service. Activities
in this knowledge area are core to BPR and initially involve using specific
facilitation and modeling techniques to document current processes. Aer the
current state is documented, the BPR Practitioner leads the design of the future
state processes which are then implemented by the project team.
Performance Measurement
The purpose of the Performance Measurement Knowledge Area is to ensure
improvements to current state processes are measurable. This is achieved
by establishing a baseline of performance, identifying future performance
targets, and measuring results aer implementation. Ongoing performance
measurement provides the factual basis to assess the eectiveness of business
processes. Process measures include cycle time, backlogs, errors and exceptions,
costs, scrap or waste, handos, and volume.
Overview | Page 16
California Department of Technology
Business Process Reengineering Framework
Templates
This chapter describes the collection of
templates that are referenced in the California
Business Process Reengineering Framework
(CA-BPR). These are designed to support
the BPR eort throughout the entire project
lifecycle.
Templates | Page 1
California Department of Technology
Business Process Reengineering Framework
In this chapter...
Templates
1
Approach
Page 3
1.1 Advantages of
Using Templates
1.2 Template
Sources
Referenced in
the CA-BPR
1.3 CA-BPR
Template Types
1.4 Templates by
Knowledge Area
and Process
Phase
2
CA-BPR
Templates
Page 7
2.1 Concept
Process Phase
2.2 Initiating
Process Phase
2.3 Planning
Process Phase
2.4 Executing
Process Phase
2.5 Closing
Process Phase
Templates | Page 2
California Department of Technology
Business Process Reengineering Framework
Templates
Approach
Business Process Reengineering (BPR) is a discipline that follows a consistent
series of activities. The CA-BPR provides standardized templates to accompany
key activities. These templates are a core component of the CA-BPR and will help
the BPR Practitioner document these activities and provide clear, meaningful
results. In some cases, the CA-BPR refers to these templates as “tools.” A template,
just like any other tool, helps get the job done.
1.1 Advantages of
Using Templates
Pre-developed templates oer the BPR Practitioner a standardized method for the
collection, analysis and documentation of BPR-related content required throughout
the PMLC. This standardization reduces the time to complete BPR activities,
increases transparency into BPR activities, reduces risk, and improves outcomes.
Some organizations may already possess well-developed BPR templates; however,
the BPR Practitioner may still benefit by supplementing templates that exist within
the organization with those that are part of the CA-BPR.
1.2 Template Sources
Referenced in the CA-BPR
The CA-BPR references and links to a variety of supporting templates designed for
a specific purpose and with the objective of guiding project teams through their
projects. There are two main sources of templates referenced in the CA-BPR.
1.2.1 CA-BPR Templates
The CA-BPR templates are designed to enable project teams to complete BPR
projects successfully, consistently, and eiciently. These templates are specific
to BPR activities and will help the team document, analyze, model, design,
Templates | Page 3
California Department of Technology
Business Process Reengineering Framework
Templates
Web Links
Leverage the CA-PMF
templates where
applicable: CA-PMF
Templates.
and implement business processes. The CA-BPR templates support BPR
activities through all process phases, focusing on the transition from the current
to future state.
1.2.2 CA-PMF Templates
The California Project Management Framework (CA-PMF) templates are
designed to help project managers keep the project on schedule, on budget,
and on time. The CA-PMF templates provide project managers with the
resources to manage all aspects of a project, including requirements, risk,
schedule, scope, deliverables, cost, communication, and changes. CA-PMF
templates are leveraged to support BPR activities where there are outputs
that are the same or similar in content. CA-PMF templates are
available at: http://cdt.cdt.ca.gov/Templates.html.
1.3 CA-BPR Template Types
The CA-BPR templates have been developed to accommodate dierences in the
experience of the BPR Practitioner. As a result, the CA-BPR templates have been
designed in two formats or types: templates with instructions for those that
require more guidance and template shells for those with more experience.
1.3.1 Templates with Instructions
The templates with instructions contain a significant amount of instructions
describing how to complete the template. The templates with instructions are
intended for the less experienced BPR Practitioner. The instructions serve as a
guide and can be deleted as the template is completed. Many templates with
instructions also contain examples and sample text that may be helpful. This
text may also be deleted or modified to suit the needs of the project as the
template is completed.
1.3.2 Templates Shells
The template shells contain the same template structure and content headings
as the templates with instructions; however, they do not include significant
amounts of instructional text or examples. These template shells are intended
to assist the more experienced BPR Practitioner who is already familiar
with similar tools and prefer to use a shell template, and/or those that have
previously worked with the template with instructions and prefer to now start
with a template shell.
i
Templates| Page 4
California Department of Technology
Business Process Reengineering Framework
Templates
1.4 Templates by Knowledge
Area and Process Phase
Some of the templates that are used during the CA-BPR are used throughout
multiple process phases and knowledge areas. The table below lists each of the
templates by knowledge area and identifies which process phases it is being
used in.
To access the templates in a fillable format see the CA-BPR website at the following
link: http://projectresources.cdt.ca.gov/bpr or by clicking here and expand
the templates tab. CA-PMF templates can be accessed at: http://capmf.cdt.ca.gov/
Templates.html or by clicking here.
Process Phase
Knowledge Area/ Template Name
Concept Initiating Planning Executing Closing
BPR Lifecycle Management
BPR Approach Assessment Template
X
BPR Schedule Template X X X
Lessons Learned Template (CA-PMF) X
Business Analysis and Future
Definition
Project Charter Template (CA-PMF) X
Current State Assessment Template X
BPR Improvement Plan Template X
Business Process Design
Business Process Modeling Tool
X X X X
Templates| Page 5
California Department of Technology
Business Process Reengineering Framework
Templates
Process Phase
Knowledge Area/ Template Name
Concept Initiating Planning Executing Closing
Performance Measurement
Current State Assessment Template X
Performance Metric Assessment Template X X
Performance Target Inventory Template X X
BPR Performance Report Template X
Note: This table does not include the BPR Process Phase Checklists that
correspond with each process phase chapter.
Templates| Page 6
California Department of Technology
Business Process Reengineering Framework
Templates
CA-BPR Templates
The templates that are used in the CA-BPR are grouped by the five project
process phases: Concept, Initiating, Planning, Executing, and Closing. Each of
the CA-BPR templates is listed and described along with the CA-PMF templates
that support them. Note that the same template may be listed in multiple
process phases as it may be used throughout the eort. T o access the CA-
BPR templates in a fillable format see the CA-BPR templates web page at
the following link: http://projectresources.cdt.ca.gov/bpr or by clicking here
and expand the templates tab.
2.1 Concept Process Phase
The following CA-BPR templates accompany the Concept Process Phase:
• BPR Approach Assessment Template - The BPR Approach Assessment
provides a method for determining if BPR is an appropriate approach for
the proposed project. The assessment involves evaluating the project’s
magnitude of change and the disruptiveness of the potential technology
solution in order to determine the appropriate approach.
• Business Process Modeling Tool – The Business Process Modeling Tool
is used by the BPR Practitioner to capture, model, and document various
levels of an organization’s current and future state business processes. The
tools contain templates for the model and narrative elements including
process steps, preconditions, process triggers, key inputs, key outputs,
policies and regulations, and supporting systems.
• Project Charter Template (CA-PMF) – This CA-PMF template is available
at http://capmf.cdt.ca.gov/Templates.html. The Project Charter formally
authorizes a project. It describes the business need for the project and the
anticipated project results. It formalizes the existence of the project and
provides the project with the authority to expend organizational resources
to support project activities.
• BPR Concept Process Phase Checklist Template – The checklist
identifies the key activities that are to be completed during the Concept
Process Phase.
Templates | Page 7
California Department of Technology
Business Process Reengineering Framework
Templates
2.2 Initiating Process Phase
The following CA-BPR templates accompany the Initiating Process Phase:
• BPR Schedule Template – This template provides a structure to
document the BPR activities and tasks required during the current process
phase required for the project. The BPR Practitioner coordinates closely
with the Project Manager when developing the process phase schedule.
Though other tools to develop and manage the schedule may be available
to the BPR Practitioner, this template may be useful to help gather
information from multiple team members that may not have access or be
familiar with other project schedule tools.
• Business Process Modeling Tool – The Business Process Modeling Tool
is used by the BPR Practitioner to capture, model, and document various
levels of an organization’s current and future state business processes. The
tool contains templates for the model and narrative elements including
process steps, preconditions, process triggers, key inputs, key outputs,
policies and regulations, and supporting systems.
• Current State Assessment Template – The Current State Assessment is a
structured document that contains the BPR work products resulting from
the Initiating Process Phase. This document supports the case for change by
demonstrating that the BPR Practitioner performed the necessary analysis
of the current state.
• Performance Metric Assessment Template – The Performance Metric
Assessment describes criteria by which the BPR Practitioner can assess
performance metrics under consideration. Criteria include accuracy,
alignment to goals and objectives, and availability.
• BPR Initiating Process Phase Checklist Template – The checklist identifies
the key activities that are to be completed during the Initiating Process
Phase.
Templates| Page 8
California Department of Technology
Business Process Reengineering Framework
Templates
2.3 Planning Process Phase
The following CA-BPR templates accompany the Planning Process Phase:
• BPR Schedule Template – This template provides a structure to document
the BPR activities and tasks required during the current process phase
required for the project. The BPR Practitioner coordinates closely with the
Project Manager when developing the process phase schedule. Though
other tools to develop and manage the schedule may be available to the
BPR Practitioner, this template may be useful to help gather information
from multiple team members that may not have access or be familiar with
other project schedule tools.
• Business Process Modeling Tool – The Business Process Modeling Tool is
used by the BPR Practitioner to capture, model, and document various levels
of an organization’s current and future state business processes. The tools
contain templates for the model and narrative elements including process
steps, preconditions, process triggers, key inputs, key outputs, policies and
regulations, and supporting systems.
• Performance Metric Assessment Template – The Performance Metric
Assessment describes criteria by which the BPR Practitioner can assess
performance metrics under consideration. Criteria include accuracy,
alignment to goals and objectives, and availability.
• Performance Target Inventory Template – Documents the performance
metrics and targets identified during the planning process phase. The
template contains fields for Business Process ID, Performance Metric ID,
Performance Metric Description, Target Value, and Target Date. Targets
are used in future process phases to determine the level of performance
improvement realized through the BPR eort.
• BPR Planning Process Phase Checklist Template – The checklist
identifies the key activities that are to be completed during the Planning
Process Phase.
Templates| Page 9
California Department of Technology
Business Process Reengineering Framework
Templates
2.4 Executing Process Phase
The following CA-BPR templates accompany the Executing Process Phase:
• BPR Schedule Template – This template provides a structure to document
the BPR activities and tasks required during the current process phase
required for the project. The BPR Practitioner coordinates closely with the
Project Manager when developing the process phase schedule. Though
other tools to develop and manage the schedule may be available to the
BPR Practitioner, this template may be useful to help gather information
from multiple team members that may not have access or be familiar with
other project schedule tools.
• Business Process Modeling Tool – The Business Process Modeling Tool is
used by the BPR Practitioner to capture, model, and document various levels
of an organization’s current and future state business processes. The tools
contain templates for the model and narrative elements including process
steps, preconditions, process triggers, key inputs, key outputs, policies and
regulations, and supporting systems.
• Performance Target Inventory Template – Documents the performance
metrics and targets identified during this process phase. The template
contains fields for Business Process ID, Performance Metric ID,
Performance Metric Description, Target Value, and Target Date. Targets
are used in future process phases to determine the level of performance
improvement realized through the BPR eort.
• BPR Executing Process Phase Checklist Template – The checklist
identifies the key activities that are to be completed during the Executing
Process Phase.
Templates| Page 10
California Department of Technology
Business Process Reengineering Framework
Templates
2.5 Closing Process Phase
The following CA-BPR templates accompany the Closing Process Phase:
• BPR Improvement Plan Template – This document is used to capture
incremental improvement opportunities identified affer solution
implementation. Elements captured include opportunity description,
priority level, timeframe, and resources assigned.
• BPR Performance Report Template – This template documents the baseline,
target, and actual performance metrics associated to the reengineered
business processes. The template helps to identify underperforming business
processes that may be candidates for post-implementation improvements.
• Lessons Learned Template (CA-PMF) – This CA-PMF template is available at
http://capmf.cdt.ca.gov/Templates.html. The lessons learned documentation
represents knowledge and experience gained during the project. It documents
how project events were addressed, and how they should be addressed in the
future, with the purpose of improving future performance.
• BPR Closing Process Phase Checklist Template – The checklist identifies
the key activities that are to be completed during the Closing Process Phase.
Templates| Page 11
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Reengineering (BPR)
activities within the Concept Process Phase
focus on establishing a foundation for the
BPR eort by defining the business needs and
aligning these needs with the organization’s
mission and strategy.
Concept | Page 1
California Department of Technology
Business Process Reengineering Framework
In this chapter...
Concept
1
Approach
Page 3
1.1 Introduction
1.2 Recommended
Practices
2
Knowledge
Areas
Page 7
2.1 BPR Lifecycle
Management
2.2 Business
Analysis
and Future
Definition
2.3 Business
Process Design
3
Process Phase
Checklist
Page 28
3.1 Complete the
Checklist
Concept | Page 2
California Department of Technology
Business Process Reengineering Framework
Concept
Approach
BPR Business Analysis and Business Process Design Performance Metrics
Lifecycle Management Future Definition
Figure 1-1
The Concept Process Phase is the first phase of the California Project Management
Framework (CA-PMF) Project Management Lifecycle (PMLC). It begins defining the
business drivers, problems, and opportunities in order to gain support to formally
launch and initiate a project. As indicated in Figure 1-1, activities from three BPR
knowledge areas occur within this process phase which focus on understanding
the business problem, identifying aected business processes, and establishing
the initial scope of the BPR eort.
1.1 Introduction
The objective of BPR within this process phase is to understand the scope of the
BPR eort for subsequent PMLC process phases. This is done by evaluating the
impact the project concept has on the current environment to determine the
need to design or redesign business processes. Three knowledge areas are active
during this process phase to scope the BPR eort: BPR Lifecycle Management,
Business Analysis and Future Definition, and Business Process Design.
Concept | Page 3
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
The primary objective for BPR Lifecycle Management is to determine whether
BPR is an appropriate approach for the project. This requires outputs from
the Business Analysis and Future Definition and Business Process Design
knowledge areas that are completed in this process phase and will occur aer
their respective activities are performed.
Business Analysis and Future Definition
Clearly establishing the business rationale for the BPR eort is essential for
project success. This is established in Business Analysis and Future Definition
by clearly defining the business problem or need and aligning it to the mission,
goals, and objectives of the organization. The resulting Business Problem
Statement is used as an input to both BPR Lifecycle Management and Business
Process Design activities within this process phase.
Business Process Design
The identification of the end-to-end business processes that will be aected
by the proposed project is a key activity of Business Process Design during
the Concept Process Phase. Knowing the aected business processes sets the
stage for assessing the size of the eort and the BPR activities needed in future
process phases. The output of Business Process Design activities is the Business
Process Scope Model which is used as an input to BPR Lifecycle Management
activities in this process phase.
Once all BPR-related Concept Process Phase activities have been completed, the
BPR Practitioner will complete the BPR Concept Process Phase Checklist. Figure
1-2 lists all of the goals, inputs, activities, and outputs for each knowledge area
during the Concept Process Phase.
Sequence of Activities
Although the knowledge areas are presented in a specific order for consistency
throughout the CA-BPR, the order in which the activities occur is independent
of each other. Activities may occur simultaneously and iteratively rather than
sequentially. Where an output from one knowledge area is an input to another,
it is not required that they have to be in final form; however, they should be
reasonably draed to contain a majority of the information the input/output
is expected to contain. The experience and knowledge of past projects and
individual judgment should be used to determine the most appropriate
sequencing of activities for each unique project.
Concept | Page 4
Initiating Planning Executing ClosingConcept Initiating Planning Executing Closing
Business Analysis
and
Future Definition
BPR Lifecycle
Management
Business
Process Design
Inputs Activities Outputs
• Define Vision and Align with Mission
• Business Problem Statement
• Business Goals and Objectives
• Mission Statement
• Organizational Process Assets
• Strategic Goals and Objectives
• Identify Current End-to-End
Business Processes
• Business Goals and Objectives
• Business Problem Statement
• Organizational Process Assets
• Business Process Scope Model
• Determine if BPR is the Right Approach • Business Goals and Objectives
• Business Problem Statement
• Business Process Scope Model
• Organizational Process Assets
• Completed BPR Approach Assessment
Concept Process Phase Goal: Determine the Basis for the Eort
California Department of Technology
Business Process Reengineering Framework
Concept
Figure 1-2
Concept | Page 5
California Department of Technology
Business Process Reengineering Framework
Concept
1.2 Recommended Practices
The following recommended practices support the activities to conceptualize
and define the project. The practices apply to all BPR knowledge areas in this
process phase and will help establish a sound basis for the project.
Recommended
Practices
Review recommended
practices at the start of
the process phase.
Business Need should Drive the BPR Project
Successful BPR projects are driven by the need to satisfy business problems
or opportunities. BPR projects normally involve significant technology
implementations and are large, involved, and cause significant changes in the
workforce and business processes. Without strong business drivers that are
supported by the organization’s leadership, the rationale for a BPR project is
likely to be called into question. Focus on identifying business drivers such as
financial benefit, improvements to service delivery and quality, satisfaction of
mandates, and reduction of risk; technology by itself should not be the driver
of the changes.
Engage Business Process Owners Early
Stakeholder engagement is a key success factor for BPR and it begins early in
the project. Identifying and involving Stakeholders in the first discussions about
problem definition and approach fosters collaboration and support at an early
stage. This practice will help identify project champions as well as those who
may challenge assumptions or analysis going forward.
Concept | Page 6
California Department of Technology
Business Process Reengineering Framework
Concept
Knowledge Areas
BPR Lifecycle Management
2.1 BPR Lifecycle Management
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Concept Initiating Planning Executing Closing
Ensure the Performance of the BPR Eort
Figure 2-1
BPR Lifecycle Management includes planning and management activities to
ensure the successful performance of the BPR eort, as shown in Figure 2-1. In
the Concept Process Phase, the project concept is assessed to determine if BPR
is the appropriate methodology to utilize for business process improvements.
This is done using the outputs of the other two knowledge areas in this process
phase to understand the initial scope of the eort. A summary of the inputs,
roles, skills, activities, tools, and outputs for BPR Lifecycle Management in this
process phase are presented in Figure 2-2.
Concept | Page 7
BPR Lifecycle Management
Inputs
• Business Goals and
Objectives
• Business Problem Statement
• Business Process
Scope Model
• Or
ganizational Process Assets
Roles
• BPR Practitioner
•
Project Sponsor
•
Stakeholders
Activities
• Determine if BPR is the
Right Approach
Skills
• Judgment
• Analysis
• Facilitation
Tools
• BPR Approach
Assessment Template
Outputs
• Completed BPR Approach
Assessment
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
Figure 2-2
2.1.1 Inputs
In order to complete the Concept Process Phase BPR Lifecycle Management
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Goals and Objectives: These describe specific goals and objectives
for the proposed project and are main inputs when considering approach and
scope. The Business Goals and Objectives are developed under the Business
Analysis and Future Definition Knowledge Area in this process phase.
Business Problem Statement: The Business Problem Statement is a clear,
concise articulation of the business problem or opportunity under consideration.
The Business Problem Statement is developed under the Business Analysis and
Future Definition Knowledge Area in this process phase.
Business Process Scope Model: Understanding the project’s approach and the
scope of the BPR eort requires an understanding of the scope of the processes
Concept | Page 8
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
that will be aected. These processes are modeled in the Business Process Scope
Model, which is developed under the Business Process Design Knowledge Area
in this process phase.
Organizational Process Assets: These include existing procedures, methods,
and guidelines the organization may employ for business analysis, BPR, or
other related processes. Examples include the CA-PMF, PAL, organization charts,
enterprise architecture documents, existing process models, desk guides,
manuals, and prior project work that will be useful for the BPR Practitioner.
2.1.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in BPR Lifecycle Management activities during the Concept Process
Phase.
Role Responsibilities
BPR
Practitioner*
• May be an informal, transitory role during the
Concept Process Phase
• May be held by the Project Sponsor or delegated
to others
• Completes the BPR Approach Assessment
Project Sponsor • Either completes the BPR Approach Assessment or
delegates to the BPR Practitioner
• Key to allocating initial resources needed to complete
the necessary tasks in the Concept Process Phase
Stakeholders • Any person or group with an active interest in the
project outcome or process who wishes to participate,
or is invited to participate, in the tasks associated with
the Concept Process Phase, including SMEs
*Depending on factors such as project complexity or resource constraints, the
BPR Practitioner role may be informally assigned to one or more resources
with other responsibilities, or a project may formally commit a resource that
is focused on BPR. The BPR Practitioner is the role of the person completing
the activities outlined in the CA-BPR and may evolve or transition to a dierent
resource as the project is planned, formalized, and completed.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Concept | Page 9
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
2.1.3 Activities
The tasks completed under the BPR Lifecycle Management Knowledge Area are
sequenced and organized into logical groupings of activities to help determine
if BPR is the right approach for the project.
Tools
A template is available:
BPR Approach
Assessment
Determine if BPR is the Right Approach
During the Concept Process Phase, the BPR Practitioner evaluates if BPR is the
best suited approach for the proposed project concept by performing a BPR
Approach Assessment that evaluates the project’s magnitude of change and
the disruptiveness of the potential technology solution. Depending on the
magnitude of the change created by the technology solution, there are a variety
of business process improvement approaches that may be utilized and are
described in the table below.
Skills
Use the following skills to
complete the activity:
• Judgment
• Analysis
• Facilitation
Improvement
Methodology
Description
Total Quality
Management
TQM focuses on orienting manager and employee
attitudes to embrace continuous quality improvement
through the measurement of the outputs of
redesigned work processes.
Six Sigma Six Sigma seeks to improve process outcomes
by establishing acceptable levels for defects and
modifying processes until the defect level is achieved.
Lean Six Sigma This is a blended methodology that incorporates
the principles of Lean and Six Sigma to mitigate the
weaknesses inherent in both methodologies if applied
individually. It focuses on reducing waste and variation
to add customer value.
Kaizen Kaizen means "continuous improvement" in Japanese.
Its core principle is that small changes should be made
by all employees with the aim of improving overall
organizational performance.
Concept | Page 10
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
Improvement
Methodology
Description
Business
Process
Reengineering
Business process reengineering advocates the idea of
starting again with processes to invent a better way of
getting work done via those processes.
To determine if BPR is the suitable approach for the project, the BPR Practitioner
must complete the following tasks:
• Assess the Magnitude of Change
• Assess the Disruptiveness of the Technology
Assess the Magnitude of Change
Using the Business Problem Statement, the Business Goals and Objectives,
the Business Process Scope Model, and organizational process assets , the
BPR Practitioner will assess the magnitude of the potential change on the
organization’s business processes. In evaluation, the BPR Practitioner should also
leverage past experiences and good judgment to determine how much change
will be required of the current business processes.
Using the Business Process Scope Model (which is developed under the Business
Process Design Knowledge Area in this process phase), the BPR Practitioner
determines if the potential changes to the existing business operations are
significant (evaluated as a large on the scale) or if the changes are minor or
incremental (evaluated as a small on the scale). For example, if the proposed
project only aects a sub-process, BPR may not be the best option to address
the scale of change. If the project will most likely aect an end-to-end business
process, then BPR is likely a suitable and relevant approach. The BPR Practitioner
should answer the following questions in the BPR Approach Assessment to help
determine the magnitude of the change:
• Is it likely that the project would result in major changes to existing
business processes?
• Is it likely that changes would aect the entire end-to-end business process?
• Is it likely that the project would require significant training for employees?
• Is it likely that the project requires significant performance improvement
to succeed?
Inputs
The following are
inputs to the activity:
• Business Problem
Statement
• Business Goals
and Objectives
• Business Process
Scope Model
• Organizational
Process Assets
Concept | Page 11
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
Assess the Disruptiveness of the Technology
The next area for the BPR Practitioner to evaluate is the disruptiveness of
implementing the potential technology solution from the current system
environment. The BPR Practitioner will assess the likelihood and extent to
which the potential technology solution will contribute to and enable changes
by reviewing the Business Problem Statement, Business Goals and Objectives,
and the Business Process Scope Model. If it is high, the technology likely plays
a significant role in changing and aecting the current business operations.
If it is low, the technology likely plays a minor or smaller role in the business
process changes. For example, an entire system replacement with new soware
will likely be disruptive to operations compared to a minor soware upgrade
with limited changes to functionality. The BPR Practitioner uses the following
questions in the BPR Approach Assessment to estimate the likelihood and
extent to which technology will be used:
• Is it likely that technology would play a central role in achieving
business changes?
• Is it likely that the project would involve technology that is new to
the organization?
• Is it likely that the project would involve the replacement of a
legacy system?
• Is it likely that the project would involve technology to automate and/or
eliminate manual processes?
• Is it likely that the project would involve technology that will integrate
disparate data or systems?
Figure 2-3 illustrates the relationship between the magnitude of change to
business processes and the disruptiveness of the technology.
Concept | Page 12
Disruptiveness of Technology
Business Process
Reengineering
Business Process
Reengineering
TQM
Six Sigma
Lean Six Sigma
Kaizen
Business Process
Reengineering
Magnitude of Change
California Department of Technology
Business Process Reengineering Framework
Concept
BPR Lifecycle Management
Figure 2-3
Once the impact of the proposed project concept has been assessed , the BPR
Practitioner then determines the relevant business process improvement
approach. If the impact to the business process is large, or technology is likely
and highly disruptive, then BPR is likely the most suitable approach and the
BPR Practitioner should continue with the BPR activities outlined in the
following process phases. However, if the magnitude of change is small and the
disruptiveness of technology is low, the other business process improvement
methodologies should be explored to better align with the work eort.
2.1.4 Tools
The tool that the BPR Practitioner will use within BPR Lifecycle Management
during the Concept Process Phase includes the following:
• BPR Approach Assessment Template
Tools
A template is available:
BPR Approach
Assessment
2.1.5 Outputs
BPR Lifecycle Management produces the following output during the Concept
Process Phase:
• Completed BPR Approach Assessment
Outputs
The following is an
output of the activity:
• Completed BPR
Approach Assessment
Concept | Page 13
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
2.2 Business Analysis and
Future Definition
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Concept Initiating Planning Executing Closing
Ensure the Future State is Sound
Figure 2-4
Business Analysis and Future Definition seeks to ensure the project’s vision is
sound by firmly aligning it to the organization’s mission and strategic goals
and objectives. The goal of BPR within this process phase as depicted in
Figure 2-4 helps to root the project’s vision with the organization’s mission
and is key to moving the project forward. The main activity of the Business
Analysis and Future Definition knowledge area in the Concept Process Phase
consists of defining the business problem or need, determining clear goals and
objectives, and aligning those with the organization’s purpose. A summary of
the knowledge area’s inputs, roles, skills, activities, tools, and outputs for this
process phase are presented in Figure 2-5.
Concept | Page 14
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
Business Analysis and Future Definition
Inputs
• Mission Statement
• Organizational Process
Assets
• Str
ategic Goals and
Objectives
Roles
• BPR Practitioner
• Project Sponsor
• Stakeholders
Activities
• Define Vision and Align
with Mission
Skills
• Analysis
• Facilitation
Tools
• Project Charter Template
Outputs
• Business Problem Statement
• Business Goals and
Objectives
Figure 2-5
2.2.1 Inputs
In order to complete the Concept Process Phase Business Analysis and Future
Definition activities, the BPR Practitioner will need a thorough understanding of
the following inputs:
Mission Statement: The mission statement identifies the core purpose of the
organization and provides the basis for the alignment of goals and objectives of
the proposed project. Mission statements may exist for divisions as well as the
overall organization.
Organizational Process Assets: These include existing procedures, methods,
and guidelines the organization may employ for business analysis, BPR, or other
related fields. Examples include the CA-PMF, PAL, organization charts, enterprise
architecture documents, existing process models, desk guides, manuals, and
prior project work that will be useful for the BPR Practitioner.
Concept | Page 15
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
Strategic Goals and Objectives: In addition to the mission statement,
organizations oen have strategic goals or objectives that document its intent
and guide its actions over a period of time. Strategic goals and objectives may
exist for divisions as well as the overall organization.
2.2.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Business Analysis and Future Definition activities during the Concept
Process Phase.
Role Responsibilities
BPR Practitioner • Creates the Business Problem Statement
• Documents Business Goals and Objectives
• Aligns the project vision to the organization
Project Sponsor • Either performs or delegates the activities of
the BPR Practitioner
• Key to allocating initial resources needed to
complete the necessary tasks in the Concept
Process Phase.
• Approves the Business Problem Statement
• Approves the Business Goals and Objectives
Stakeholders • Any person or group with an active interest in
the project outcome or process who wishes
to participate, or is invited to participate, in
the tasks associated with the Concept Process
Phase, including SMEs.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Concept | Page 16
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
2.2.3 Activities
The tasks completed under the Business Analysis and Future Definition
Knowledge Area in the Concept Process Phase create the foundation for the
BPR eort by making it relevant to the organization’s mission. This eort creates
strong agreement between existing organizational goals and the goals of the
proposed project.
Define Vision and Align with Mission
During this activity, the BPR Practitioner creates the project’s Business Problem
Statement and Business Goals and Objectives, and ensures that they are aligned
to the organization’s mission statement and strategic goals. These elements
are documented in the Project Charter and serves to articulate the business
rationale for the project. While the creation of the Project Charter is performed
by the Project Management workstream during the Initiating Process Phase,
the BPR Practitioner provides inputs to the development during the Concept
Process Phase.
Skills
Use the following skills to
complete the activity:
• Analysis
• Facilitation
Concept | Page 17
The tasks for this activity include:
• Define the Business Problem Statement
• Define Business Goals and Objectives
• Align Business Goals and Objectives with Organizational Mission an
Strategy
d
Define the Business Problem Statement
Creating a clear and concise business problem for the BPR eort is critical to
focusing project eorts. For instance, the team might agree that a purchasing
process is too cumbersome. However, this simple formulation provides little
actionable detail. Is the process too manually intensive? Do users not fully
understand the process? Does it take too long? Is there a lot of rework due to
frequent errors? In helping teams answer these types of questions, the BPR
Practitioner can clearly articulate and document the business problem with
greater focus and precision. Documenting the business problem is especially
important during the Concept Process Phase as it will help identify a suitable
approach. Additionally, a clearly stated business problem will ultimately enable
the technology solution to focus on and solve specific business needs.
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
An initial step in defining the business problem is collecting the results of any
relevant work that has already been produced. The output from previous
meetings and analyses can help frame the problem statement or serve as a way
to validate the project concept. Useful outputs can include discussion notes,
existing performance metrics, current reports, or recent examples of the business
problem. In some cases, work groups may have already started to informally
document concerns or even map processes visually. The BPR Practitioner should
determine if there is any history or other organizational process assets that can be
leveraged to help define the project’s scope and objectives.
Inputs
The following is an
input to the activity:
• Organizational
Process Assets
Once relevant background material has been gathered and reviewed, the BPR
Practitioner’s next step is to create the Business Problem Statement that will
be solved by the proposed project. Developing and refining the business need
helps reveal the root causes of the problem and how it aects the organization.
Furthermore, clarifying and defining the relationship between the problem’s
cause and eect will help the BPR Practitioner develop a viable approach to
solving it. This clarification provides a basis for defining a vision and eventually
aligning it with the organization’s mission. Without these elements, the Business
Problem Statement is too vague to guide the BPR eort.
Inputs
The following is an
input to the activity:
• Mission Statement
The following examples present two Business Process Statements about the
same problem. However, they are presented dierently, with the second example
being more refined and precise.
• Example 1 - “We need to improve our recruiting and hiring process because
it takes too long to execute. We seem to invest too much time reviewing
applications and getting interviews set up.”
• Example 2 - “We need to improve our recruiting and hiring process. We
spend too much time manually getting the paperwork together for a
recruitment, and it takes too long to process handwritten applications. As
a result, we are losing good candidates to other organizations, and we are
seeing reduced service levels as positions remain open too long.”
The first example states the problem but does not go beyond that. It suggests that
the recruiting and hiring process is cumbersome and too long. It does not oer a
possible cause and eect and the description is general and somewhat vague.
The second example suggests that the recruiting and hiring processes are
manually intensive and might benefit from automation. We also see that the
business problem has a clear impact on the organization – they are losing
candidates to competitors and their service levels are declining. Neither of these
details can be gleaned from the first example. Example two is a more refined,
precise, and complete example of a problem statement.
Concept | Page 18
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
The BPR Practitioner should encourage the Project Sponsor and Stakeholders
(as necessary) to discuss, clarify, and refine the Business Problem Statement,
focusing on potential causes and impacts. Once finalized, the Business Problem
Statement can be documented in a preliminary dra Project Charter.
Tools
A template is available:
Project Charter
Define Business Goals and Objectives
Goals are a high level statement of purpose while objectives are specific targets
that support the goal. With a completed Business Problem Statement, the BPR
Practitioner can focus on articulating the individual goals of the BPR eort. The
practitioner should start with business goals first as it makes defining specific
objectives easier.
Developing a solution to the business problem depends greatly on an
organization’s goals and what it is trying to accomplish. For instance, if the
goal is to improve eiciency in small increments, the best approach might
be to eliminate time-consuming and unnecessary steps. If the goal is to
significantly reduce costs, the BPR Practitioner may consider new technology
to support organizational and process changes. It is very diicult to outline the
right approach without understanding what is driving the change. Similarly,
alignment of the improvement eort with overall organizational goals cannot
be accomplished without a clear understanding of those goals.
The most eective objectives share similar characteristics – quantifiable,
realistically achievable, singular, business-based, and specifically related to
the Business Problem Statement. The BPR Practitioner can use the mnemonic
acronym, SMART (specific, measurable, achievable, realistic, time-bound) to
help when specifying objectives. When objectives follow these guidelines, they
are better defined and more actionable. For example, an objective of “getting
better at this process” might be accurate, but it does not specifically define the
organization’s desired future state. This example objective limits the ability to
develop an approach or to investigate alignment. In comparison, an objective
of “reducing recruitment times by 25% or more within 5 years” clearly states
expectations for the future state and provides a basis for evaluating the desired
outcome against organizational goals.
The BPR Practitioner will help the Stakeholders identify two or three specific,
clear goals and supporting objectives of the project eort. Try to avoid vague
objectives such as “improve eiciency” or “increase productivity” and focus
instead on measurable ones such as “cut processing time by 30 percent by the
end of the fiscal year.” Once the goals and objectives have been specified, the
BPR Practitioner will document them in the preliminary dra Project Charter,
so they can be communicated and discussed by Stakeholders.
Outputs
The following is an
output to the activity:
• Business Problem
Statement
Concept | Page 19
California Department of Technology
Business Process Reengineering Framework
Concept
Business Analysis and Future Definition
Align Goals and Objectives with Organizational Mission
and Strategy
Following the definition of specific goals and objectives, the BPR Practitioner will
compare them to the organization’s mission and strategic goals. It is important
to remember that alignment with the organization’s strategy increases the
level of support and likelihood of success of the BPR eort. For example, if
the organization has a strategic goal of reducing costs and improving service
through automation of manual processes, and the BPR eort is seeking to
automate the recruitment and applicant process, the BPR goals and objectives
and the organization’s strategy are in strong alignment.
Inputs
The following are
inputs to the activity:
• Mission Statement
• Strategic Goals
and Objectives
If the goals and objectives of the BPR eort are not aligned with organizational
strategy, the BPR Practitioner will need to make adjustments. For example, the
BPR Practitioner may need to focus more on cost reduction than on automating
manual processes. Oen, this process is simply a matter of restating an existing
goal, but the BPR Practitioner may need to revisit assumptions or constraints.
Once BPR goals and objectives have been aligned with organizational strategy,
it is important for the BPR Practitioner to document the alignment in order
to communicate with executives and the rest of the organization. If the BPR
Practitioner can eectively demonstrate that the project will help achieve
organizational goals, the team should achieve a higher degree of acceptance,
less resistance to change, better access to resources, and faster decision-making.
2.2.4 Tools
The tool that the BPR Practitioner will use within Business Analysis and Future
Definition during the Concept Process Phase includes the following:
• Project Charter Template
2.2.5 Outputs
Business Analysis and Future Definition produces the following outputs during
the Concept Process Phase:
• Business Problem Statement
• Business Goals and Objectives
Outputs
The following is an
output to the activity:
• Business Goals
and Objectives
Concept | Page 20
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
2.3 Business Process Design
Understand
Current Processes
Identify
Business Impact
Define
Future Processes
Elaborate
Future Processes
Business
Process Design
Concept Initiating Planning Executing Closing
Ensure the Future State is Established
Figure 2-6
The overarching goal of the Business Process Design Knowledge Area is to ensure
the future processes and vision are established, as detailed in Figure 2-6. During
the Concept Process Phase, the BPR Practitioner focuses on identifying and
documenting the major business processes that will be impacted by the project.
Prior to documenting the business processes, the BPR Practitioner will conduct
research on internal processes and external influences, and elicit feedback
from Stakeholders. The BPR Practitioner then documents business processes
by creating an inventory of those that will be aected by the proposed project.
The resulting Business Process Scope Model is used as an input for BPR Lifecycle
Management to help determine the approach and understand the scope of the
BPR eort. A summary of the knowledge area’s inputs, roles, skills, activities,
tools, and outputs for this process phase are presented in Figure 2-7.
Concept | Page 21
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
Business Process Design
Inputs
• Business Goals and
Objectives
•
Business Problem Statement
• Organizational
Proc
ess Assets
Roles
• BPR Practitioner
• Project Sponsor
• Stakeholders
Activities
• Identify Current End-to-End
Business Process
Skills
• Interviewing
•
Facilitation
•
Analysis
• Modeling
Tools
• Business Process
Modeling Tool
Outputs
• Business Process
Scope Model
Figure 2-7
2.3.1 Inputs
In order to complete the Concept Process Phase Business Process Design
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Goals and Objectives: Business Goals and Objectives establish
purpose and targets and are important in determining which business processes
will be aected. The Business Goals and Objectives are outputs of the Business
Analysis and Future Definition Knowledge Area in this process phase.
Business Problem Statement: The Business Problem Statement is a clear,
concise articulation of the business problem or opportunity under consideration.
The Business Problem Statement is developed under the Business Analysis and
Future Definition Knowledge Area in this process phase.
Concept | Page 22
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
Organizational Process Assets: These include existing procedures, methods,
and guidelines the organization may employ for business analysis, BPR, or other
related fields. Examples include the CA-PMF, PAL, organization charts, enterprise
architecture documents, existing process models, desk guides, manuals, and
prior project work that will be useful for the BPR Practitioner.
2.3.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Business Process Design activities during the Concept Process
Phase.
Role Responsibilities
BPR
Practitioner
• Collaborates with the Project Sponsor and
Stakeholders to discuss business process inputs
and outputs
• Gathers and reviews business process input and
output documents
• Identifies impacted end-to-end business processes
• Documents high-level business process impact of
proposed project
• Develops the Business Process Scope Model
Project Sponsor • Either performs or delegates the activities of the
BPR Practitioner
• Provides input regarding impacted
business processes
• Reviews and approves the Business Process
Scope Model
Stakeholders • Any person or group with an active interest in the
project outcome or process who wishes to participate,
or is invited to participate, in the tasks associated with
the Concept Process Phase, including SMEs
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Concept | Page 23
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
2.3.3 Activities
The main activity of Business Process Design in the Concept Process Phase is
to explore the potential impact of the project by identifying which end-to-end
business processes are involved. Although the BPR Practitioner may intuitively
know which processes these are, the act of defining and documenting them at a
high level will aid in impact analysis and developing a common understanding
of the scope of the BPR eort.
Identify Current End-to-End Business Processes
In BPR, business processes are categorized by levels of detail which provide
a structured way to organize and relate processes and sub-processes to each
other. The levels of detail range from 0 (the least detail) to 4 (the most detail).
Level 0 business processes are also known as “end-to-end business processes”.
The BPR Practitioner needs to be familiar with the definitions of these levels
prior to documenting the impacted processes by reviewing the Business Process
Modeling Tool.
Tools
A template is available:
Business Process
Modeling Tool
The BPR Practitioner uses the Business Problem Statement and works with the
Project Sponsor and Stakeholders to identify the business processes that will be
aected. The BPR Practitioner does this by completing the following activities:
• Research and Analyze the Internal Organization
• Research and Assess the External Environment
• Create the Business Process Scope Model
Inputs
The following are
inputs to the activity:
• Business Problem
Statement
• Business Goals
and Objectives
• Organizational
Process Assets
Research and Analyze the Internal Organization
To identify the end-to-end business processes that are aected by this project,
the BPR Practitioner will begin by identifying all of the organization’s operating
and supporting processes.
Skills
Use the following skills to
complete the activity:
• Interviewing
• Facilitation
• Analysis
• Modeling
Concept | Page 24
• Operating processes are those process that directly add value to the
organization’s vision and mission. For example, for an agency that delivers
social services, the provisioning of a constituent’s social service benefits
would be an operating process. To help identify operating processes, the
BPR Practitioner can ask the following questions:
◦ What products or services does the organization provide in support of its
mission?
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
◦ What are the high-level processes related to the identified product or
service?
• Supporting processes are the processes that do not directly contribute
to achieving the organization’s mission, but they indirectly enable it. For
example, the social services agency’s human resources (HR) process hires
employees that in turn provide social services benefits for constituents;
hence, the HR process supports the operating process. To help identify
supporting processes, the BPR Practitioner can ask the following questions:
◦ Does this process directly impact the customers/constituents of the
organization?
◦ Does this process directly relate to the vision or mission of the
organization?
Most organizations will have similar supporting processes. Examples of supporting
processes include managing HR, managing IT, or managing financial resources. In
contrast, operating processes will be unique to a specific organization and will
focus on the organization’s delivery of its unique services to its constituents. It is
important to identify both types of processes and understand the relationships
between them.
Aer identifying all of the organization’s operating and supporting processes,
the BPR Practitioner should identify those that are impacted by the proposed
project. BPR projects can be focused on redesigning either operating processes,
supporting processes, or both. Sometimes the redesign of one process type will
lead to a change in another. For example, the social service agency implements
a new financial system and redesigns a supporting process: how it processes
payments to third-party vendors. But if this change aects how the agency
disburses its benefits to constituents, it might aect its operating processes.
Whether the BPR project is focused on operating or supporting processes, the
BPR Practitioner needs to identify and understand all of the internal end-to-end
processes that will be impacted by the BPR eort.
Research and Assess the External Environment
Because business processes oen extend beyond the organization itself, it is
also important to consider the relationships with the external environment.
Business processes can be influenced by external factors, including other
government agencies, legislative bodies, and other constituents and groups.
In order to fully understand the organization’s processes and the extent of the
BPR eort, the BPR Practitioner needs to know how the external environment
aects them and vice versa.
Concept | Page 25
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
Many end-to-end business processes begin and end somewhere outside of the
organization itself. For example, a social services agency wants to hire a new
employee. The agency has its own internal hiring process, but the first step in
that process actually takes place outside the agency: the applicant submits a
general application on the state website and the state routes the application
to the social services agency. This step is an external “input” to the agency’s
internal hiring process. On the other end of the process, once an employee is
hired, he or she must be registered with the agency that issues payroll. This step
is an “output” of the agency’s internal hiring process.
Inputs and outputs extend beyond the organization itself, but they are still part
of its business processes and can influence BPR projects. Organizations must
account for constraints imposed by external partners in the BPR eort. For
example, the format and type of data that an input will include, or the format
and type of data that must be included in an output must be considered in a
business process design. Inputs are dictated by how the external Stakeholder
provides them and outputs are influenced by how the receiving external
Stakeholder uses them.
The BPR Practitioner needs to identify the external inputs of end-to-end business
processes and should use the following questions to help uncover them:
• What is the starting point (or trigger) for the end-to-end processes that
were identified in the internal research and analysis?
• What information is needed in order for the organization to take action?
• What actions cause the organization to take action?
Outputs are identified in a very similar way, except the processes are traced
through to their end (instead of back to their beginning). The practitioner should
use the following questions to uncover outputs of an organization:
• Who is a service or product being provided to and why?
• How are customers/constituents of this organization being helped?
• Are there other external organizations that benefit from the process?
• What are these external organizations gaining from the process?
With an understanding of the process inputs and outputs of an organization,
the BPR Practitioner can document the end-to-end business processes more
accurately. It is important to remember that most organizations do not operate
in isolation and that external inputs and outputs need to be considered—a key
activity in this phase.
Concept | Page 26
California Department of Technology
Business Process Reengineering Framework
Concept
Business Process Design
Create the Business Process Scope Model
Aer assessing the internal and external environments, the BPR Practitioner
will document the results of the analysis as a high-level Business Process Scope
Model. Business Process Scope Models are visual representations of the end-to-
end business processes and serve many important purposes:
• It establishes a common understanding of the scope of the project.
• It identifies the end-to-end business processes that will be impacted.
• It aligns the inputs, impacted end-to-end business processes, and
outputs with the project’s vision and organization’s mission
• It defines the business processes that need to be further analyzed
and decomposed.
It is important to keep in mind that in this phase, the process model captures
high-level processes. The BPR Practitioner may choose to depict relationships
and sequences between processes, but it is not necessary to identify every
relationship or sequence at this stage. As BPR progresses, processes will be
decomposed into more detail, including relationships and supporting processes.
2.3.4 Tools
The tool that the BPR Practitioner will use within Business Process Design
during the Concept Process Phase includes the following:
• Business Process Modeling Tool
2.3.5 Outputs
Business Process Design produces the following output during the Concept
Process Phase:
• Business Process Scope Model
Outputs
The following is an
output to the activity:
• Business Process
Scope Model
Concept | Page 27
va
l Lifecycl
Project Appro
Project Appro
California Department of Technology
Business Process Reengineering Framework
Concept
Process Phase Checklist
3.1 Complete the Checklist
Once all of the BPR activities within the Concept Process Phase are done, the
process phase checklist should be completed. The checklist provides a list of
“why, how, what, who, where, and when” questions to verify that all items in the
process phase are complete.
Tools
A template is available:
BPR Concept Process
Phase Checklist
The process phase checklist helps to identify and document r
e
epeatable steps,
from project to project, to ensure that the correct activities are completed at the
right time, every time.
Process phase checklists assist the BPR Practitioner in quickly and confidently
identifying areas of c
Project Appro
oncern within this process phase. In this case, completion
of the checklist provides a clear milestone that the Concept Process Phase is
complete, including:
• BPR Approach Assessment
• Business Problem Statement
• Identified Business Goals and Objectives
• Business Process Scope Model
• Completed BPR Concept Process Phase Checklist
Outputs
Complete the BPR Concept
Process Phase Checklist
to validate that all
process phase activities
are complete.
Concept | Page 28
California Department of Technology
Business Process Reengineering Framework
Initiating
The Initiating Process Phase focuses Business
Process Reengineering (BPR) activities on
developing a clear understanding of the business
drivers for the change initiative. The focus
includes documenting the business process
issues and opportunities for improvement.
Initiating | Page 1
California Department of Technology
Business Process Reengineering Framework
In this chapter...
Initiating
1
Approach
Page 3
1.1 Introduction
1.2 Recommended
Practices
2
Knowledge
Areas
Page 8
2.1 BPR Lifecycle
Management
2.2 Business
Analysis
and Future
Definition
2.3 Business
Process Design
2.4 Performance
Measurement
3
Process Phase
Checklist
Page 42
3.1 Complete the
Checklist
Initiating | Page 2
California Department of Technology
Business Process Reengineering Framework
Initiating
Approach
BPR Business Analysis and Business Process Design Performance Metrics
Lifecycle Management Future Definition
Figure 1-1
The Initiating Process Phase is the second process phase of the California Project
Management Framework (CA-PMF) Project Management Lifecycle (PMLC).
During this process phase, the BPR activities focus on defining and justifying the
prospective project. As show in Figure 1-1, activities from all four BPR knowledge
areas occur and include defining the opportunities, documenting current
processes, and identifying the performance baseline.
1.1 Introduction
During the Initiating Process Phase, the BPR Practitioner performs the work
necessary to build the case for change and justify the project by performing an
assessment of the current state which includes:
• The identification of customer needs
• The identification of business process issues
• The identification of the performance baseline
• The prioritization of opportunities.
This information is aggregated into the Current State Assessment that documents
all of the work completed in this process phase. It becomes a foundational
document for subsequent process phases and provides the context for why the
eort is taking place and the overall goals to be achieved.
Initiating | Page 3
California Department of Technology
Business Process Reengineering Framework
Initiating
BPR Lifecycle Management
The BPR Practitioner works closely with the Project Manager to establish a
schedule to document the activities and resource needs for all knowledge areas
in this process phase.
Business Analysis and Future Definition
The BPR Practitioner performs a number of business analysis activities,
including the identification of customer needs; business process issues; leading
practices and benchmarks; and prioritized opportunities. With inputs from
other knowledge areas, these activities culminate in the completion of the
Current State Assessment.
Business Process Design
The BPR Practitioner performs the modeling and documenting of current
business processes that results in the development of the Current State Process
Model and is included in the Current State Assessment. These models are used
as an input to the business process issue identification activities within the
Business Analysis and Future Definition Knowledge Area and in the Planning
Process Phase to help determine process improvements.
Performance Measurement
The current performance levels of existing business processes are identified and
documented by the BPR Practitioner to create the performance baseline and is
included in the Current State Assessment. This baseline establishes a frame of
reference from which future improvement can be compared and is used during
the Planning Process Phase.
Once all BPR-related Initiating Process Phase activities have been completed,
the BPR Practitioner will complete the BPR Initiating Process Phase Checklist.
Figure 1-2 summarizes the inputs, activities, and outputs for all active knowledge
areas in the Initiating Process Phase.
Initiating | Page 4
Concept Planning Executing ClosingConcept Initiating Planning Executing Closing
Business Analysis
and
Future Definition
BPR Lifecycle
Management
Business
Process Design
Performance
Measurement
Inputs Activities Outputs
• Identify Customer Needs
• Identify Business Process issues
• Identify Leading Practices and
Benchmarks
• Identify, Validate, and Prioritize
Opportunities
• Document the Current State
Assessment
• Identified Customer Needs
• Identified Business Process Issues
• Identified Benchmarks
• Identified Leading Practices
• Prioritized Opportunities
• Completed Current State Assessment
• Business Goals and Objectives
• Business Problem Statement
• Business Process Scope Model
• Completed Current State
Process Model
• Completed BPR Schedule
• Identified Performance Baseline
• Document Current State
Business Processes
• Business Process Scope Model
• Completed BPR Schedule
• Organizational Process Assets
• Completed Current State
Process Model
• Determine the Performance Baseline • Business Goals and Objectives
• Business Process Scope Model
• Completed Current State
Process Model
• Completed BPR Schedule
• Identified Customer Needs
• Identified Performance Baseline
• Completed Performance Metric
Assessment
• Determine and Plan for BPR Activities • Business Process Scope Model
• Stakeholder Register
• Completed BPR Schedule
Initiating Process Phase Goal: Justify the Project
California Department of Technology
Business Process Reengineering Framework
Initiating
Figure 1-2
Initiating | Page 5
California Department of Technology
Business Process Reengineering Framework
Initiating
1.2 Recommended Practices
The following Recommended Practices will help the BPR Practitioner build the
business case. These recommended practices apply to all BPR knowledge areas
and help establish a sound basis for the project.
Recommended
Practices
Review Recommended
Practices at the start of
the process phase.
Initiating | Page 6
Have a Compelling Business Case for Change
It is important to clearly understand and analyze the business problems and
issues. If the root causes are not well understood and/or there is a lack of
well-documented evidence, the business case will not be compelling. It then
can potentially be criticized and can lead to many downstream undesirable
consequences, such as not obtaining the necessary approvals or increasing
the resistance to change. The case for change needs to be compelling for the
organization to obtain the necessary support and buy-in.
Focus on the Perspective of the Customer
The customer’s needs should be documented based on their perspective.
Oen, current processes in a state organization have been defined over years
of legislation and policies. With an opportunity to design new processes, it is
important to understand the customer perspective in order to design processes
that create the most value for the organization.
Have a Clear Baseline to Measure Performance Against
In order to measure improvements, it is important to clearly define key metrics
and establish a baseline for each business process that is in scope for the BPR
eort. This will allow the project team to determine the amount of progress
towards meeting project goals as the change is being implemented.
Don’t Over-Document the Current State
Documenting the current state facilitates discussions with Stakeholders to
determine business process problems, issues, and challenges that help define
the future state. To this goal, the BPR Practitioner should use good judgment
and their experience to manage the level of detail obtained and avoid falling
into the trap of “current state paralysis”—a situation where participants spend
unnecessary time documenting the details of how process steps occur which
are subsequently rendered obsolete aer the processes are redesigned. It is
important to understand “who,” “what,” “when,” and “where,” but not the “how.”
California Department of Technology
Business Process Reengineering Framework
Initiating
Keep Lessons Learned in Mind Throughout the Project
Early in the BPR eort, it is important to take the time to seek out lessons
learned that have been developed by other projects or dierent parts of the
organization. By reviewing and implementing these lessons learned, it reduces
the chance of repeating the mistakes others have experienced and build upon
their successes.
On an ongoing basis, project team members should be encouraged to informally
document their own lessons learned as they are executing the project. Lessons
learned sessions are normally conducted at the end of the project or with the
completion of a phase or milestone; in some cases, a lot of time may have passed
from when an event occurred to when a lessons learned session takes place.
Individually documenting the lessons learned ahead of time will ensure that
project team members are able to remember all the successes and challenges
that have happened.
i
For More Info...
For more information on
Lessons Learned see the
Closing Process Phase of
the CA-PMF.
Initiating | Page 7
California Department of Technology
Business Process Reengineering Framework
Initiating
Knowledge Areas
BPR Lifecycle Management
2.1 BPR Lifecycle Management
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Concept Initiating Planning Executing Closing
Ensure the Performance of the BPR Eort
Figure 2-1
The goal of BPR Lifecycle Management in the Initiating Process Phase is to
determine and plan for the BPR activities necessary to support the case for
change, as shown in Figure 2-1. The BPR Practitioner will work closely with
the Project Manager to establish a BPR schedule for this process phase that
identifies activities and resources necessary for BPR activities.
A summary of the inputs, roles, skills, activities, tools, and outputs for BPR
Lifecycle Management in this process phase is presented in Figure 2-2.
Initiating | Page 8
California Department of Technology
Business Process Reengineering Framework
Initiating
BPR Lifecycle Management
BPR Lifecycle Management
Inputs
• Business Process
Scope Model
• Stakeholder Register
Roles
• BPR Practitioner
• Project Sponsor
• Project Manager
Activities
• Determine and Plan for
BPR Activities
Skills
• Project Management
• Analysis
• Estimation
Tools
• BPR Schedule Template
Outputs
• Completed BPR Schedule
Figure 2-2
2.1.1 Inputs
In order to complete the Initiating Process Phase BPR Lifecycle Management
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Process Scope Model: This model, which identifies all of the end-to-
end business processes aected by the proposed project, is developed during
the Concept Process Phase.
Stakeholder Register: In order to identify resources needed for Initiating
Process Phase activities, the BPR Practitioner will refer to Stakeholders and
SMEs identified in the project’s Stakeholder Register. This register is an output
of the Project Management workstream.
Initiating | Page 9
California Department of Technology
Business Process Reengineering Framework
Initiating
BPR Lifecycle Management
2.1.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in BPR Lifecycle Management activities during the Initiating Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Leads the eort to determine the specific BPR
activities that will be conducted during the
Initiating Process Phase
• Develops BPR staing and resource estimates
Project Sponsor • Provides input to the BPR schedule
• Assists with identifying BPR resources
Project Manager • Assists with developing project staing and
resource estimates
• Assists with BPR schedule development
• Maintains the BPR schedule
2.1.3 Activities
The tasks completed under the BPR Lifecycle Management Knowledge Area revolve
around establishing the resource and scheduling needs for this process phase.
Determine and Plan for BPR Activities
The Initiating Process Phase focuses on building the case for the BPR eort.
To support the case for change, BPR activities within this process phase must
be identified, resourced, and scheduled. The BPR Practitioner will identify
tasks, document them in a BPR schedule, and support the Project Manager in
identifying the necessary resources to complete the tasks.
Tools
A template is available:
BPR Schedule
Initiating | Page 10
California Department of Technology
Business Process Reengineering Framework
Initiating
BPR Lifecycle Management
To develop the schedule, the BPR Practitioner should complete the following:
• Review the entirety of this chapter to identify the various activities and
outputs that must be developed within each knowledge area in the Initiating
Process Phase.
• Based on the project and organizational characteristics, identify the tasks
necessary to complete the identified activities. Consider any constraints
that will dictate the timing, frequency and order the activities need to
be completed.
• Estimate the duration and eort to complete each task. Consider the scope
and complexity of the project to come up with appropriate numbers.
• Work with the Project Manager to identify available resources to complete
the tasks. The availability of resources to support the eort may require
re-work of the schedule. Resources assigned to BPR tasks should have
essential skills and experience to perform them. These include previous
business process modeling, meeting facilitation, and business analysis
experience. This experience is essential for tasks to be completed eiciently
and with the appropriate level of detail.
Skills
Use the following skills to
complete the activity:
• Analysis
• Estimation
• Project Management
In addition to BPR Practitioner tasks, a pool of resources needs to be identified
for a number of key activities during this process phase. The pool will consist of
Stakeholders, SMEs, and customers who are familiar with the business processes
in the project scope. They are needed for the following activities:
• Participation in business process elicitation sessions
• Identification of customer needs
• Identification of business process issues
• Identification of performance metrics
Inputs
The following is an
input to the activity:
• Business Process
Scope Model
The BPR Practitioner should work with the Project Manager and leverage
the Stakeholder Register to identify and allocate these resources in the BPR
Schedule. Once the schedule has been developed, the BPR Practitioner will work
with the Project Manager to integrate the tasks into the greater project schedule
to monitor and control. The management of the BPR eort should not occur in
isolation, but should be fully integrated with the project management eort for
the entire project.
Inputs
The following is an
input to the activity:
• Stakeholder Register
Initiating | Page 11
California Department of Technology
Business Process Reengineering Framework
Initiating
BPR Lifecycle Management
2.1.4 Tools
The tool that the BPR Practitioner will use within BPR Lifecycle Management
during the Initiating Process Phase includes the following:
• BPR Schedule Template
2.1.5 Outputs
BPR Lifecycle Management produces the following output during the Initiating
Process Phase:
• Completed BPR Schedule
Initiating | Page 12
California Department of Technology
Business Process Reengineering Framework
Initiating
Business Analysis and Future Definition
2.2 Business Analysis and
Future Definition
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Concept Initiating Planning Executing Closing
Ensure the Future State is Sound
Figure 2-3
The goal of Business Analysis and Future Definition in the Initiating Process
Phase is to build the case for change, as show in Figure 2-3. The case for change
is built by creating the Current State Assessment that documents customer
needs, business process issues, leading practices and benchmarks, and
prioritized business opportunities that address the issues. This activity formally
establishes the business case which drives subsequent design activities.
A summary of the inputs, roles, skills, activities, tools, and outputs for Business
Analysis and Future Definition in this process phase are presented in Figure 2-4.
Initiating | Page 13
California Department of Technology
Business Process Reengineering Framework
Initiating
Business Analysis and Future Definition
Business Analysis and Future Definition
Inputs
• Business Goals and
Objectives
• Business Problem Statement
•
Business Process
Scope Model
•
Completed Curr
ent State
Process Model
• Completed BPR Schedule
• Identified Performance
Baseline
Roles
• BPR Practitioner
• Project Sponsor
• Project Manager
• Stakeholders
Activities
• Identify Customer Needs
• Identify Business
Proc
ess Issues
• Identify Leading Practic
es
and Benchmarks
• Identify, Validate, and
Prioritize Opport
unities
• Document the Current
Stat
e Assessment
Skills
• Analysis
• Documentation
• Facilitation
•
Interviewing
• Root Cause Analysis
• Surveying
Tools
• Current State Assessment
Template
Outputs
• Identified Customer Needs
• Identified Business Process
Issues
• Identified Benchmarks
• Identified Leading Practices
• Prioritized Opportunities
• Completed Current State
Assessment
Figure 2-4
2.2.1 Inputs
In order to complete the Initiating Process Phase Business Analysis and Future
Definition activities, the BPR Practitioner will need a thorough understanding of
the following inputs:
Concept Process Phase Work Products: These include the Business Problem
Statement, Business Process Scope Model, and Business Goals and Objectives.
Completed Current State Process Model: The BPR Practitioner uses these
process models to guide discussions with Stakeholders on process issues. The
Completed Current State Process Model is an output of the Business Process
Design Knowledge Area in this process phase.
Initiating | Page 14
California Department of Technology
Business Process Reengineering Framework
Initiating
Business Analysis and Future Definition
Completed BPR Schedule: BPR Schedule describes the allocation of Stakeholder
resources for key BPR activities. The schedule is an output of the BPR Lifecycle
Management Knowledge Area in this process phase.
Identified Performance Baseline: The Performance Baseline is an output of the
Performance Measurement Knowledge Area in this process phase and helps the
BPR Practitioner determine benchmark metrics.
2.2.2 Roles
The following table lists the roles and their associated responsibilities of
those involved in Business Analysis and Future Definition activities during the
Initiating Process Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR
Practitioner
• Facilitates the activities of Business Analysis and
Future Definition, organizing and conducting work
sessions with Stakeholders
• Determines the availability of Organizational
Process Assets
• Elicits and documents customer needs
• Elicits and documents process issues
• Identifies and collects information from other
organizations for benchmarking and identifies
leading practices
• Validates and prioritizes business opportunities
• Completes the Current State Assessment
Project
Sponsor
• Approves any purchasing and resourcing decisions
regarding benchmarking and leading practices research
• Participates in the identification of opportunity
prioritization criteria
• Approves the Current State Assessment
Initiating | Page 15
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 16
Initiating
Business Analysis and Future Definition
Role Responsibilities
Project
Manager
• Provides input to purchasing and resourcing decisions
regarding benchmarking and leading practices research
• Assists in identifying opportunity prioritization criteria
Stakeholders
(Including
SMEs)
• Has domain knowledge regarding specific
requirements or needs
• Participates to identify business process issues
and opportunities
2.2.3 Activities
The tasks under Business Analysis and Future Definition include the identification
of customer needs, business process issues, leading practices, benchmarks, process
improvement opportunities, and the completion of the Current State Assessment.
The completion of these activities will help justify the need for this eort.
Identify Customer Needs
Understanding the customers of a business process is critical to any
reengineering eort. A customer-centered approach optimizes the business
value of the process in service of those who are aected the most. The BPR
Practitioner will elicit and document customer needs to complete the business
analysis.
Elicit and Document Customer Needs
During the BPR Lifecycle Management Knowledge Area, a pool of customers were
identified for customer needs elicitation. In this activity, the BPR Practitioner will
perform elicitation with these customers and document their needs. As a first step,
the BPR Practitioner determines the best elicitation method for the project. SMEs
that are familiar with the customers should be consulted to help determine what
methods may be most beneficial. If the customer needs are perceived to be simple
and/or homogeneous, interviews with a handful of customers may be suicient.
Inputs
The following is an
input to the activity:
• Completed BPR Schedule
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 17
Initiating
Business Analysis and Future Definition
Larger, more diverse groups of customers may be better served by a survey. Each
method will require that a series of questions be posed about the customer’s
perception of the service, product, and/or process. Example questions include:
• What is the main reason you participate in the process?
• What are the most important factors to you regarding the service/
product/process?
• What do you feel are the strengths of the current service/product/process?
• What areas do you feel need improving in the current service/
product/process?
• What one thing would you change regarding the current service/
product/process?
Skills
Use the following skill to
complete the activity:
• Analysis
The BPR Practitioner will perform whatever number of elicitation sessions
are needed to gain an understanding of the customer’s needs. Once this data
is collected, an analysis is performed on the information with the goal of
identifying the core needs to be considered for the project. The BPR Practitioner
reviews the data for common themes and impactful items.
Outputs
The following is an
output to the activity:
• Identified Customer
Needs
Customer needs are summarized and documented as a needs statement. For
example, “The customer service desk needs to provide prompt resolution to
basic requests.” The customer needs serve as an element by which process
improvement opportunities are aligned in subsequent activities. Once
identified, they are documented in the Current State Assessment.
Tools
A template is available:
Current State Assessment
Identify Business Process Issues
A key activity during this process phase is the identification of business process
issues. Understanding the issues associated with the business processes will
help to identify areas that, once addressed, will lead to better performance and
increased satisfaction.
These issues are usually identified by Stakeholders and SMEs that use the system
and have the necessary domain knowledge. Aer business process issues are
collected, they are converted to opportunities and are prioritized in subsequent
Inputs
The following is an
input to the activity:
• Completed Current
State Process Model
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 18
Initiating
Business Analysis and Future Definition
activities. These prioritized opportunities become the basis of the design eorts
in the Planning Process Phase. This activity consists of the following tasks:
• Determine Elicitation Method
• Elicit and Document Business Process Issues
Determine Elicitation Method
During this activity, the BPR Practitioner again references the pool of
participants identified during the BPR Lifecycle Management Knowledge Area.
These participants consist of Stakeholders and SMEs that have the process
knowledge and experience to describe process issues. The BPR Practitioner’s
first step in this activity is to determine the best way to elicit the data from these
participants. Common methods include focus groups, one-on-one interviews,
and surveys. Each method is suitable to specific circumstances:
Inputs
The following is an
input to the activity:
• Completed BPR Schedule
• Focus groups – Useful when Stakeholders are in a single location rather
than being geographically dispersed. With focus groups, the BPR Practitioner
serves as a facilitator, asking a series of questions and letting the participants
discuss and provide feedback. Focus groups are valuable because they
present opportunities for the group to confirm their thoughts and provide
a consensus view. They also allow for the BPR Practitioner to ask follow-
up questions for clarity. A potential drawback of focus groups is that some
participants may feel uncomfortable sharing their views in a group setting.
• One-on-One Interviews – Useful for situations where scheduling diiculties
and geographic challenges prevent focus groups. With interviews, the BPR
Practitioner asks a series of questions of the Stakeholder and records their
answers. Interviews, which can be done in person or remotely, are valuable
in that individual attention is given to each Stakeholder. In this way, certain
information may be revealed that may be missed in a focus group or survey.
Additionally, interviews allow for follow-up questions for clarity. The main
drawback to interviews is that they are labor intensive.
• Surveys – Useful for situations where large groups of Stakeholders need to
be addressed and/or are geographically dispersed. Surveys are valuable in
that they are cost eective and can yield large amounts of data in short time
frames. However, the quality of the survey data depends greatly on how
questions are written; experienced BPR Practitioners should employ this
method or leverage the appropriate expertise to help dra the survey. One
drawback for surveys is they do not allow for ad hoc follow up questions for
clarification.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 19
Initiating
Business Analysis and Future Definition
Another method to elicit information from Stakeholders is to combine the
activity with other activities already scheduled. For example, the activity of
gathering information on the current business processes covered in the Business
Process Design Knowledge Area can be leveraged for identifying business
process issues as well. Suitability is dependent on factors such as project size
and Stakeholder composition. For smaller projects, this combination can be
achieved without overburdening participants. However, on larger projects with
more diverse Stakeholder groups, it may be more beneficial to separate the
eorts and have a clear agenda and objectives for each. The BPR Practitioner
should take the time to assess these factors to make a determination.
Aer taking the previous areas into account, the BPR Practitioner determines
the appropriate elicitation methods and schedules sessions as needed.
Elicit and Document Business Process Issues
During elicitation activity, the BPR Practitioner should pose a series of questions
that are meant to identify business process issues. The nature, wording, and
context of the questions may vary from process to process and according to the
elicitation method selected; the BPR Practitioner needs to apply knowledge,
judgment, and experience when creating questions that best suit the project.
The following are example questions that may be used for the elicitation activity:
Questions to identify process problems and issues:
• What are the major goals or objectives associated with the process?
• How are these goals/objectives measured?
• What barriers or constraints are faced in meeting these goals/objectives?
• How would you rate the performance of the program/process?
• What are the process’s key strengths?
• What are the process’s weaknesses?
• Are there any backlogs associated with the process?
• Are there any resourcing issues?
• Does sta possess the right knowledge, skills, and abilities?
• How is process-related work prioritized?
• Is there any duplication of eort?
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 20
Initiating
Business Analysis and Future Definition
• What tools and/or systems do you desire that you currently do not have?
• How urgent are decisions/actions dealt with? Are decisions made in a
timely manner?
Once the data has been collected, the BPR Practitioner performs an analysis on
the information. The goal of the analysis is to identify the core issues that warrant
process reengineering. The BPR Practitioner reviews the data for common
themes and impactful items to identify process issues that are documented
with the following elements:
Skills
Use the following skill to
complete the activity:
• Analysis
• Problem Statement – a short statement of the problem itself. For example,
“Manual prioritization of customer service requests require significant
expenditures of employee time.”
• Impact – what significance does this problem or issue have? What is the
impact to the organization in terms of cost, ineiciency, lost productivity,
dissatisfied customers, etc.
• Causes and notes – to the extent possible, identify root causes for the
problem, and document any background, context, or extraneous items that
would help the reader better understand the improvement opportunity.
Skills
Use the following skill to
complete the activity:
• Root Cause Analysis
The resulting documentation of business process issues serve as the basis for
opportunity prioritization in subsequent activities and for process redesign
activities in the Planning Process Phase. Once identified, the business process
issues are included in the Current State Assessment.
Outputs
The following is an
output to the activity:
• Identified Business
Process Issues
Identify Leading Practices and Benchmarks
Another key activity for the BPR Practitioner during the Initiating Process
Phase is the identification of leading practices and benchmarks. In addition
to business process issues identified in the prior activity, leading practices are
an important source of improvement opportunities. Benchmarks, on the other
hand, help the BPR Practitioner in determining future performance targets in
the Planning Process Phase.
• Leading practices are eective strategies, operations, or processes that
are employed by peer organizations with a record and reputation of high
performance in the industry. For example, a leading practice may be to
co-locate information technology infrastructure with similar agencies in
order to save on facility operation costs.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 21
Initiating
Business Analysis and Future Definition
• Benchmarks are known levels of performance from peer organizations
that allows for performance comparison. For example, a benchmark may
be a 24 hour processing time for application forms.
While leading practices and benchmarks are dierent and used for separate
purposes, they are grouped in this activity because they are oen collected
from the same organizations. This activity consists of the following tasks:
• Identify Leading Practice or Benchmark Organizations
• Identify Collection Methods
• Collect and Document Leading Practices and Benchmarks
Identify Leading Practice or Benchmark Organizations
As a first step to identifying leading practices and benchmarks, the BPR Practitioner
needs to identify an appropriate pool of organizations from which to elicit data.
Characteristics the BPR Practitioner should consider include type of product/
service and types constraints, such as mandates and legislation. Additionally,
organizations should have a record and reputation of high performance.
Skills
Use the following skill to
complete the activity:
• Analysis
A number of research organizations exist that specialize in providing leading
practices and benchmarks. Examples include Gartner and Forrester Research.
These may be cost-eective options and should be considered. In cases where
costs are prohibitive or the data is not readily available, the BPR Practitioner
can reach out to industry associations such as the National Association of Chief
Information Oicers, the Government Finance Oicer’s Association, or the Center
for Digital Government to identify top performing government organizations.
It should be noted that while government agencies frequently look to other
government agencies for leading practices and benchmarks, private sector
companies should also be considered. The private sector is more responsive to
market changes due to factors such as more lax governing rules and regulations
and cultural dierences. Though it may be diicult for the state organization
to wholly adopt and strive for the leading practices and benchmarks of private
sector organizations, they may oer innovative methods that can be leveraged
for improvement.
Identify Collection Methods
Once organizations are identified, the BPR Practitioner needs to determine a
suitable method for collecting the information. The BPR Practitioner should
first determine what level of data may already exist. As mentioned previously,
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 22
Initiating
Business Analysis and Future Definition
research firms oen oer leading practice and benchmark research. However,
such research is oen proprietary and the information may need to be
purchased, so the BPR Practitioner will need to weigh the applicability of the
research against cost.
If existing research cannot be obtained, the BPR Practitioner will need to perform
research to collect the data from the identified organizations. One successful
method of data collection is telephone interviewing. This allows the Practitioner
to receive immediate results and ask follow-up questions as necessary. Another
viable and oen complementary option is a survey. The survey can be useful in
gathering information from a large number of targets at one time, but doesn’t
allow for impromptu follow-up questions or additional context that may be
needed. In order for a survey to work properly, the BPR Practitioner needs to
ensure the readability of the questionnaire and applicability of each question and
answer choice. The BPR Practitioner will need to weigh the pros and cons of the
available methods and use good judgment to determine a suitable approach.
Skills
Use the following skills to
complete the activity:
• Interviewing
• Facilitation
• Surveying
Collect and Document Leading Practices and Benchmarks
Aer the collection method has been determined, the BPR Practitioner executes
upon the collection activity. Depending on the method and the amount of
desired data, this may require a significant amount of time and expenditure of
resources, something that will need to be considered. The questions below are
recommended in order to capture a larger set of answers.
When eliciting leading practices, the BPR Practitioner can use questions such as:
• What do you consider as leading practices regarding [business process]?
• What practices regarding [business process] sets your organization apart
from your peers?
• What innovations regarding [business process] do you think are
instrumental in your organization’s success?
Benchmarks can be elicited by using questions such as:
• What performance metric(s) do you currently use for [business process]?
• What is your current performance value for this metric?
• What is your target performance value for this metric? What timeframe is
tied to this target?
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 23
Initiating
Business Analysis and Future Definition
Aer the data collection is complete, the BPR Practitioner documents the
leading practices and benchmarks in the Current State Assessment. Each
leading practice should be summarized into a succinct statement for readability
since leading practices are typically narrative in nature. Benchmarks are oen
numeric in nature and may include ranges of performance. At a minimum,
documentation should include a description of the leading practice or benchmark
and the business process(es) to which it is relevant. Once the documentation is
complete, the BPR Practitioner will utilize the identified leading practices and
benchmarks in opportunity prioritization and determining future performance
targets, respectively.
Tools
A template is available:
Current State Assessment
Outputs
The following are
outputs to the activity:
• Identified Leading
Practices
• Identified Benchmarks
Identify, Validate, and Prioritize Opportunities
During this activity, the BPR Practitioner evaluates the previously identified
business process issues and leading practices to identify the organization’s
opportunities for improvement. These are then documented in the Current
State Assessment. The resulting prioritized opportunities become a useful
input for the Project Manager when developing the Project Charter. Specifically,
they aid in identifying in-scope and out-of-scope activities. Furthermore, the
prioritization becomes the basis for future reengineering and redesign activities
in the Planning Process Phase. This activity consists of the following tasks:
• Identify Opportunities
• Validate Opportunities
• Determine Prioritization Criteria
• Prioritize and Document Opportunities
Identify Opportunities
To identify opportunities, the BPR Practitioner converts each identified process
issue or leading practice from prior activities into opportunity statements. An
opportunity is a chance to make a change resulting in a benefit. The statement
should succinctly define the improvement opportunity that would resolve the
process issue. For example, the problem statement, “manual prioritization
of customer service requests require significant expenditures of employee
time” is converted to “improve the ability to automatically prioritize customer
service requests.”
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 24
Initiating
Business Analysis and Future Definition
Validate Opportunities
Valid opportunities are ones that align to the project’s Business Goals and
Objectives and meets customer needs. The BPR Practitioner should validate the
opportunities by assessing if these criteria are met. The following questions can
be used for this validation:
• Which Business Goals and Objectives does it support?
• Which customer need does it support?
Inputs
The following are
inputs to the activity:
• Business Goals
and Objectives
• Business Process
Scope Model
• Business Problem
• Statement
Only opportunities that demonstrate alignment to these criteria should be
prioritized and included in the scope of the project.
Determine Prioritization Criteria
Aer validating that the opportunities are appropriate, the BPR Practitioner
needs to establish criteria by which to prioritize them. The criteria will vary
from project to project, so the BPR Practitioner should work with the Project
Manager and Project Sponsor to identify the appropriate prioritization criteria.
The BPR Practitioner can begin by using the following list and add or subtract
criteria as needed:
• What level of expenditure does it require?
• How many Stakeholders will it impact?
• What level of expertise is required to implement it?
• What is the timeframe for implementing it?
• Is it dependent on other opportunities?
• Does it enable other opportunities?
• What is the level of urgency of the associated issue?
• Is the process associated with it critical to the organization?
• Does it require changes to labor agreements?
• Does it require any legislative or regulatory changes?
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 25
Initiating
Business Analysis and Future Definition
One criteria the BPR Practitioner should make note of is regarding policy
or legislative changes. It is somewhat rare that a process improvement
opportunity of any consequence can be realized without considering governing
policies, state law, or federal law. The BPR Practitioner should investigate these
and any other constraints identified through this process with Stakeholders to
understand any regulations or internal policies that govern the process or may
impact the process in some way.
Once identified, the constraints should be documented along with a brief
discussion as to the possibility of addressing them. For example, in many
organizations, there are administrative policies that have existed for decades
but no longer reflect operating needs. It may be possible to ask a governing
body to allow changes, or to eliminate certain policies altogether. In other cases,
state law may govern a process, and the likelihood of changing such a situation
is either low or would take considerable time.
Skills
Use the following skill to
complete the activity:
• Documentation
Prioritize and Document Opportunities
Outputs
The following are
outputs to the activity:
• Completed Current
State Assessment
• Prioritized Opportunities
A final step is to assign a priority to each opportunity based on the established
criteria and document them in the Current State Assessment. This is typically a
simple A, B, C classification, or High, Medium, Low.
The resulting prioritized opportunities are used to both build the case for change
by illustrating which opportunities can be seized and articulating the high-level
benefits that would result. This in turn helps the Project Manager in developing
the Project Charter’s in-scope activities by identifying which improvement
activities have the highest potential value. Furthermore, they serve as the basis
for reengineering activities in the Planning Process Phase.
Document the Current State Assessment
Lastly, the BPR Practitioner will document the current state in a formalized
document. This incorporates the work products from the Business Analysis and
Future Definition, Business Process Design, and Performance Measurement
Knowledge Areas. It provides the foundation for the project in building the
business case for change as well as demonstrates that the BPR Practitioner has
completed a thorough analysis of the current state. In documenting the current
state, the BPR Practitioner includes the following:
• Documented current state business processes
• Documented customer needs
Inputs
The following is an
input to the activity:
• Completed Current State
Process Model
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 26
Initiating
Business Analysis and Future Definition
• Identified business process issues
• Prioritized improvement opportunities
• Defined current performance baseline
The BPR Practitioner incorporates these components of work products into the
Current State Assessment. The BPR Practitioner then presents this information
to the Project Manager, Project Sponsor, and Stakeholders as determined by
the Project Manager. The Current State Assessment then becomes an important
input to the Project Approval Lifecycle (PAL) and design and reengineering
activities in subsequent process phases.
Inputs
The following is an
input to the activity:
• Identified Performance
Baseline
2.2.4 Tools
The tool that the BPR Practitioner will use within Business Analysis and Future
Definition during the Initiating Process Phase includes the following:
• Current State Assessment Template
2.2.5 Outputs
Business Analysis and Future Definition produces the following outputs during
the Initiating Process Phase:
• Identified Customer Needs
• Identified Business Process Issues
• Identified Benchmarks
• Identified Leading Practices
• Prioritized Opportunities
• Completed Current State Assessment
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 27
Initiating
Business Process Design
2.3 Business Process Design
Understand
Current Processes
Identify
Business Impact
Define
Future Processes
Elaborate
Future Processes
Business
Process Design
Concept Initiating Planning Executing Closing
Ensure the Future State is Established
Figure 2-5
The focus of Business Process Design during the Initiating Process Phase is to
understand the current state of the organization’s business processes that are
in scope of the project, as shown in Figure 2-5. The BPR Practitioner does this
by modeling the current state to a level of detail needed to identify business
process issues and opportunities.
The BPR Practitioner will document the current business processes through
interviews and facilitated work group sessions. The results will be documented
and are used during the Business Analysis and Future Definition Process Phase
to identify process problems and improvement opportunities by illustrating
connection points, numbers of handos, and overall complexity. A summary of
the inputs, roles, skills, activities, tools, and outputs is presented in Figure 2-6.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 28
Initiating
Business Process Design
Business Process Design
Inputs
• Business Process
Scope Model
• Completed BPR Schedule
•
Organizational
Proc
ess Assets
Roles
• BPR Practitioner
• Stakeholders
Activities
• Document Current State
Business Processes
Skills
• Analysis
• Documentation
• Facilitation
• Modeling
• Validation
Tools
• Business Process
Modeling Tool
Outputs
• Completed Current State
Process Model
Figure 2-6
2.3.1 Inputs
In order to complete the Initiating Process Phase Business Process Design
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Process Scope Model: The Business Process Scope Model provides a
basis for the BPR Practitioner to work from when documenting the current state
business processes.
Completed BPR Schedule: In order to identify Level 1 and Level 2 process details
(described later in this knowledge area), the BPR Practitioner will rely on the
input of Stakeholders and SMEs. The BPR Schedule describes the allocation of
these resources. The schedule is an output of the BPR Lifecycle Management
Knowledge Area in this process phase.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 29
Initiating
Business Process Design
Organizational Process Assets: An organization might have existing
documentation, including organization charts, enterprise architecture
documents, existing process models, desk guides, manuals, and prior project
work that will be useful for the BPR Practitioner.
2.3.2 Roles
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
The following table lists the roles and their associated responsibilities of those
involved in Business Process Design activities during the Initiating Process
Phase.
Role Responsibilities
BPR Practitioner • Facilitates the work group sessions with
Stakeholders
• Documents and models the current state
business processes
Stakeholders
(including SMEs)
• Has domain knowledge regarding specific
needs, processes, or functional areas
• Participates in the identification of current state
business processes
2.3.3 Activities
The tasks completed under the Business Process Design Knowledge Area center
on completing the Current State Process Model. Although these tasks are
grouped and sequenced in the sections that follow, the BPR Practitioner needs
to apply his/her knowledge and experience to ensure the appropriate sequence
for each project.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 30
Initiating
Business Process Design
Document Current State Business Processes
A Business Process Model is a graphical swim-lane diagram representing
a sequence of activities with the associated responsible roles. It contains
information that enables the analysis and identification of current business
process issues (an activity that occurs within the Business Analysis and Future
Definition knowledge area). An example of a simple model is presented in Figure
2-7, showing the process beginning and end, activities and decision points.
Inputs
The following are
inputs to the activity:
• Business Process
Scope Model
• Completed BPR Schedule
Level 1 – Post a Job Nocaon
Human
Resources
Business
Department
B1
Write Job Posng
A1
Report Job Opening
A2
Review Job Posng
B2
Revise Job Posng
B3
Post Job Posng
A3
Approved?
No
Yes
Figure 2-7
The BPR Practitioner will use their knowledge, judgment and experience to
maintain the analysis at a high enough level to capture the “who,” “what,”
“when,” and “where” work is performed, and avoid getting into “how” work is
being performed. It is critical to understand the activities that need to occur to
achieve the outcome, but not how it is done today. This enables a redesign of
the business processes to occur during the Planning Process Phase.
Business process modeling is normally done at various levels of detail enabling
complex business pr
ocesses to be divided into smaller, less complex, and more
manageable sub processes, activities, and tasks. This is known as levels of
decomposition. The CA-BPR employs the use of 5 levels of decomposition, as
presented in Figure 2-8.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 31
Initiating
Business Process Design
Level 0
End-to-End
Business Process
Level 1
Business Process
Level 2
Sub-Process
Level 3
Activity
Level 4
Task
Procure-to-Pay
1
Purchase
1.1
Create
Purchase Requisition
1.1.1
Identify
Commodity Code
2
Receive
3
Process Invoices
4
Process Payments
1.2
Approve
Requisition
1.3
Create
Purchase Order
1.4
Forward
PO to Vendor
1.1.2
Complete
Requisition Form
1.1.3
Submit Requisition
for Approval
1.1.2.1
Indicate Quantity
1.1.2.2
Verify Price
1.1.2.3
Indicate
Preferred Vendor
Figure 2-8
A Level 0 End-to-End Business Process describes an organization’s business
proc
ess at the highest level. This level, which is made up of a single phrase, can be
seen as an umbrella business process under which all other business processes
(Level 1), sub-processes (Level 2), activities (Level 3), and tasks (Level 4) are
encapsulated. In Figure 2-8, Procure-to-Pay is an End-to-End Business Process.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 32
Initiating
Business Process Design
The next highest level of process decomposition is Level 1 Business Process,
which is a series of related actions performed by one or more stakeholders in
order to complete a business transaction or accomplish an organizational goal.
While multiple business processes working together make up an end-to-end
business process, multiple sub-processes working together make up a business
process. In Figure 2-8, Purchasing, Receiving, Invoice Processing, and Payment
Processing are all examples of business processes.
The next level of process decomposition is Level 2 Sub-Process, which is a series
of steps necessary to the completion of a business process, but insuicient on
its own to achieve an organizational goal. For example, “create a purchase
requisition” is a sub-process of purchasing that is a necessary step to procuring
goods for a department, but by itself will not accomplish the goal of procuring
those goods. While multiple sub-processes working together make up a
business process, multiple activities working together make up a sub-processes.
Examples of sub-processes in Figure 2-8 include: Approve Requisition, Create
Purchase Order, and Forward Purchase Order to Vendor.
A Level 3 Activity is a series of tasks required to execute a sub-process. Activities
are further decomposed into tasks. For example, the sub-process of completing
a purchase requisition may require the activities of a “budget check” to verify
funds availability and “obtain supervisor approval” if the dollar amount exceeds
a certain threshold. Other examples of activities in Figure 2-8 include: Identify
Commodity Code, Complete Requisition Form, and Obtain Approval.
The last level of decomposition is a Level 4 Task which is a single action step
performed by a single Stakeholder and is the smallest part of the business
processes. Multiple tasks performed together make up a single activity. To
complete the requisition form, the employee indicates the quantity desired
and verifies the price. He or she then selects the preferred vendor and provides
shipping information. Examples of tasks in Figure 2-8 include: Indicate Quantity,
Verify Price, and Select Preferred Vendor.
To document the current state business processes, the BPR Practitioner will
normally employ Level 1 or Level 2. Further guidance on business process
modeling is presented in the Business Process Model Tool, including process
modeling techniques and templates. This activity consists of the following tasks:
• Prepare for Business Process Modeling
• Facilitate Sessions and Model Processes
Tools
A template is available:
Business Process
Modeling Tool
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 33
Initiating
Business Process Design
Prepare for Business Process Modeling
Business Process Modeling elicitation requires the BPR Practitioner to facilitate
elicitation sessions with Stakeholders who can describe the business processes. To
increase the likelihood of success, the BPR Practitioner should prepare for elicitation
by carefully considering the following areas when scheduling model sessions:
• Participants – the BPR Practitioner refers to the Phase BPR Schedule
when scheduling participants and sessions. Stakeholders identified as
participants in modeling activities need to be able to accurately describe
the business processes.
• Elicitation Methods and Group Size and Composition – for most projects,
business processes are elicited via interviews, facilitated group work-
sessions, or a combination thereof. The goal of the elicitation is to document
the processes accurately while controlling for cost. In many cases, one or
two SMEs are knowledgeable enough to describe entire business processes.
In these cases interviews are employed. When a business process is larger
and requires a group of Stakeholders, group work-sessions are typically
used. In such cases the BPR Practitioner should consider group size and
composition as important factors of success. Smaller groups may help
improve dialogue and discussions. Meetings with larger groups should
allow for smaller breakout groups to encourage more participation.
Composition of groups should include Stakeholders across the entire end-
to-end processes to address handos and other issues.
• Timing and Schedule – it is generally best to keep interviews or sessions to
no more than two to three hours per session to limit participant fatigue. Keep
in mind that facilitating several such meetings in a single day is diicult. It
is wise to allow time between interviews or sessions to accommodate other
work requirements, and document and prepare for the next session.
• Preparation and Materials – In preparing for facilitated sessions, the
BPR Practitioner should review pertinent organizational process assets to
become familiar with the business processes that are in scope of the project.
Documentation, such as training manuals or desktop procedures, can provide
good information and can be leveraged prior to the facilitated sessions. When
possible, it is helpful to create a basic dra model to serve as a scaold for more
detailed processes. Stakeholders will be much more willing to discuss business
processes with a facilitator who has taken the time to prepare and can use the
business terminology specific to their domain.
Inputs
The following is an
input to the activity:
• Organizational
Process Assets
Skills
Use the following skill to
complete the activity:
• Analysis
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 34
Initiating
Business Process Design
Facilitate Sessions and Model Processes
As the facilitator of the modeling sessions, the BPR Practitioner is responsible
for guiding the participants into producing the Current State Process Model
that provides enough detail to help identify process issues. This typically means
describing and documenting them no further than Level 2 sub-processes.
The session begins with an introduction of the purpose of the session, the
anticipated outcomes, and the roles of the participants. Establishing this
upfront is important to establishing the expectations of the participants. It is
helpful to keep these items visible, such as on a white board or flip chart, so the
BPR Practitioner can refer to them in case discussions go o-track.
The BPR Practitioner then performs a guided walkthrough of the Business
Process Scope Model to orient the participants. The BPR Practitioner then
leads participants through the initial dra model and prompts participants to
elaborate upon it. If a model was not prepared in advance, the BPR Practitioner
prompts the participants into identifying the individual steps in the business
process until the process is fully described.
Skills
Use the following skill to
complete the activity:
• Modeling
Tools
A template is available:
Business Process
Modeling Tool
Skills
Use the following skills to
complete the activity:
• Facilitation
• Documentation
• Validation
The BPR Practitioner, while facilitating the work session, should document the
results in a swim-lane diagram. Guidance regarding the documentation of the
models along with templates are provided in the Business Process Modeling
Tool. Modeling sessions can be challenging, especially with large groups. Below
are useful tips the BPR Practitioner can use for facilitating sessions:
• Use the first five minutes of the session to establish ground rules. Let the
participants know that the purpose is to gather specific information from
multiple viewpoints. The Practitioner will stop and refocus the discussion if
it gets o track. Also, make sure they understand that the discussion will be
documented, and that it may be necessary to backtrack to fill in gaps.
• When using process mapping to document a process flow, take the time to
explain the various symbols and standards used to ensure participants can
follow along.
• The BPR Practitioner must be careful to allow all the participants a chance
to provide input. It is the facilitator’s role to ensure that the information
gathered does not simply reflect the views of the most dominant personality
in the group.
• If tangential items come up during the session that are important but not
directly relevant to your topic, use a white board or flip chart to record them
as “parking lot” items that can be discussed at another time.
• If you are using process mapping to document a business process or
sub-process, verify the diagram with Stakeholders prior to moving on to the
next process.
Aer the model and documentation is complete, its accuracy should be verified
by the participants. The resulting Current State Process Model is added to the
Current State Assessment and becomes an important input into the Business
Analysis and Future Definition knowledge area.
2.3.4 Tools
The tool that the BPR Practitioner will use within Business Process Design
during the Initiating Process Phase includes the following:
• Business Process Modeling Tool
2.3.5 Outputs
Business Process Design produces the following output during the Initiating
Process Phase:
• Completed Current State Process Model
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 35
Initiating
Business Process Design
Outputs
The following is an
output to the activity:
• Completed Current State
Process Model
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 36
Initiating
Performance Measurement
2.4 Performance Measurement
Identify
Performance Baseline
Define
Performance Reports
Generate
Performance Reports
Performance
Measurement
Concept Initiating Planning Executing Closing
Ensure Improvements are Measurable
Determine
Future Measures
and Performance
Figure 2-9
The goal of Performance Measurement is to ensure that improvements resulting
from the project are measurable, as shown in Figure 2-9. The BPR Practitioner
should identify the processes being measured and the level of performance of
the current state as a baseline to which the future state can be compared. It is
fairly common that metrics for each business process as defined by the project
are not readily available, in which case a collection eort is performed to obtain
them. Baseline metrics will need to be measured throughout the project to
demonstrate improvement and should be aligned to the business processes.
A summary of the inputs, roles, skills, activities, tools, and outputs is presented
in Figure 2-10.
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 37
Initiating
Performance Measurement
Performance Measurement
Inputs
• Business Goals and
Objectives
• Business Process
Sc
ope Model
• Completed Current State
Pr
ocess Model
• Completed BPR Schedule
• Identified Cust
omer Needs
Roles
• BPR Practitioner
• Project Sponsor
• Stakeholders
Activities
• Determine the
Performance Baseline
Skills
• Analysis
• Interviewing
• Validation
Tools
• Current State Assessment
Template
• Perf
ormance Metric
Assessment Template
Outputs
• Identified Performance
Baseline
• Complet
ed Performance
Metric Assessment
Figure 2-10
2.4.1 Inputs
In order to complete the Initiating Process Phase Performance Measurement
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Goals and Objectives: The BPR Practitioner aligns current and future
performance measures to the Business Goals and Objectives.
Business Process Scope Model: The Process Scope Model provides a basis for
the BPR Practitioner to work from when determining which of the processes need
performance baselines.
Completed Current State Process Model: The Current State Process Model
is developed within the Business Process Design Knowledge Area in this
process phase and provides details regarding the processes impacted by the
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 38
Initiating
Performance Measurement
project. This detail will be helpful in aiding the BPR Practitioner in determining
performance measurements.
Completed BPR Schedule: In order to identify current levels of performance,
the BPR Practitioner will rely on the input of Stakeholders and SMEs. The BPR
Schedule describes the allocation of these resources. The schedule is an output of
the BPR Lifecycle Management Knowledge Area in this process phase.
Identified Customer Needs: When determining performance targets the needs
of customers are important to consider. Documentation of customer needs is
an output of the Business Analysis and Future Definition knowledge area in this
process phase.
2.4.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Performance Measurement activities during the Initiating Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Works with the Stakeholders (as needed) to
identify current performance measures
• Analyzes the current performance measures to
determine adequacy
• Analyzes the current performance levels to
determine accuracy
• Documents current performance baseline
Project Sponsor • Assists in identifying the current performance
measures
• Formally approves the performance baseline
Stakeholders
(including SMEs)
• Has domain knowledge regarding specific
needs, processes, and/or functional areas
• Participates in the identification of current
performance measures
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 39
Initiating
Performance Measurement
2.4.3 Activities
The tasks required to determine the performance baseline are presented
in a logical sequence below. The BPR Practitioner should leverage his/her
experience and judgment to adjust tasks and the sequence as needed.
Skills
Use the following skills to
complete the activity:
• Analysis
• Interviewing
• Validation
Determine Performance Baseline
Organizations oen track metrics to determine their level of performance.
Examples of performance metrics are number of applications processed within
a week, number of forms in a backlog per day, number of customer service calls
dropped before reaching a representative, and average time to process a form
or other product from beginning to end.
Inputs
The following is an
input to the activity:
• Business Goals and
Objectives, Business
Process Scope Model
• Completed Current State
Process Model
• Completed BPR Schedule
• Identified
Customer Needs
During the Initiating Process Phase, the BPR Practitioner determines the
performance baseline, or current level of performance, for business processes
in the scope of the project. The resulting performance baseline provides a basis
for measuring future improvements. This activity consists of the following tasks:
• Determine What Metrics are Being Used
• Assess Existing Metrics
• Create New Performance Metrics
• Collect and Document the Current Performance Baseline
Determine What Metrics are Being Used
The first step in determining the performance baseline is identifying what, if
any, metrics are currently in use. The BPR Practitioner does this by speaking to
SMEs that have insight into the processes. If it is determined that metrics are in
use, they should be evaluated to determine adequacy. If there are no metrics,
the BPR Practitioner should work with the Project Sponsor and SMEs to create
them as needed.
Assess Existing Metrics
If there are existing metrics, the BPR Practitioner will evaluate their adequacy
by performing a Performance Metric Assessment. This involves assessing each
metric against a series of criteria. These criteria are:
Tools
A template is available:
Performance Metric
Assessment
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 40
Initiating
Performance Measurement
• Accuracy – metrics should reflect the realities of the process
• Clarity – metrics should be easy to understand and if calculated, the
calculation should be documented
• Low cost – metrics should not require inordinate eort or cost to collect
• Numeric – metrics should be quantifiable so that they can be compared
over time
• Discrete – metrics should be singular and not compound
• Relevancy – metrics should reflect important objectives and should be
traceable back to the organization’s strategic goals
• Adequacy – metrics should describe all of the required objectives for a
comprehensive picture
• Time – metrics need to exist for a significant amount of time to show they
are reliable
The BPR Practitioner will work with the Project Sponsor and SMEs as necessary
to complete the assessment. If the outcome of the assessment shows that the
existing metrics are inadequate, the BPR Practitioner will need to lead an eort
for the SMEs to create new metrics.
Outputs
The following is an
output to the activity:
• Completed Performance
Metric Assessment
Identify New Performance Metrics
To create new performance metrics, the BPR Practitioner should conduct
brainstorming sessions with SMEs to identify potentially viable metrics. The
goal of these sessions is to create metrics that satisfy the criteria within the
Performance Metric Assessment. To prompt brainstorming activities, the BPR
Practitioner can use the following categories and questions:
• Time – How much time is spent generating products or services? What is
the complete cycle time from end-to-end? What is the cycle time for each
business process and sub-process?
• Quality – How many defects are associated with the product or service?
How many items are returned due to being defective, have errors, or
missing information?
• Cost – How much cost is associated with conducting the end-to-end
business process? Are there components of the business process that are
highly manual?
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 41
Initiating
Performance Measurement
• Inputs/Outputs – Are there backlogs? What is the quality of the end results?
The BPR Practitioner will rely upon the domain knowledge of SMEs to help
determine if the metrics are available or can be measured with reasonable
eort. For example, if cycle time is identified as a candidate, the BPR Practitioner
should ask the relevant SMEs how the cycle times could be currently measured.
This may be as simple as creating a new system report or by manually timing
cycles because the system functionality does not exist. In situations similar to
the latter, the BPR Practitioner needs to weigh the cost and eort required to
gather the current level of performance against the value of the metric. Once
viable metrics are determined, the BPR Practitioner needs to collect the metrics,
validate their accuracy, and document them in the Current State Assessment.
Collect and Document the Current Performance Baseline
Using the metrics identified in the prior task, the BPR Practitioner collects the
current performance baseline values. This oen involves submitting requests
for system reports to various Stakeholders that have access to the data. When
the data is collected, it is documented in the Current State Assessment.
Once the performance baseline values have been collected and documented,
the BPR Practitioner finalizes the performance baseline of each business
process in the Current State Assessment. It is recommended that the baseline
be established for an entire year, either calendar or fiscal year. This way, any
fluctuations over time can be accounted for. The finalized performance baseline
is then used in reengineering activities during the Planning Process Phase.
2.4.4 Tools
The tools that the BPR Practitioner will use within Performance Measurement
during the Initiating Process Phase include the following:
• Current State Assessment Template
• Performance Metric Assessment Template
Tools
A template is available:
Current State
Assessment
2.4.5 Outputs
Performance Measurement produces the following outputs during the Initiating
Process Phase:
• Identified Performance Baseline
• Completed Performance Metric Assessment
Outputs
The following is an
output to the activity:
• Identified Performance
Baseline
California Department of Technology
Business Process Reengineering Framework
Initiating | Page 42
Initiating
Process Phase Checklist
va
l Lifecycl
e
Project Appro
Project Appro
3.1 Complete the Checklist
Once all of the BPR activities within the Initiating Process Phase are done, the
process phase checklist should be completed. The checklist provides a list of
“why, how, what, who, where, and when” questions to verify that all items in the
process phase are complete.
The process phase checklist helps to identify and document repeatable steps,
from project to project, to ensure that the correct activities are completed at the
right time, every time.
Tools
A template is available:
BPR Initiating Process
Phase Checklist
Process phase checklists assist the BPR Practitioner in quickly and confidently
identifying areas of c
Project Appro
oncern within this process phase. In this case, completion
of the checklist provides a clear milestone that the Initiating Process Phase is
complete, including:
• Completed BPR Schedule
• Identified Customer Needs
• Identified Business Process Issues
• Identified Benchmarks
• Identified Leading Practices
• Prioritized Opportunities
• Completed Current State Assessment
• Completed Current State Business Process Model
• Identified Performance Baseline
• Completed Performance Metric Assessment
• Completed BPR Initiating Process Phase Checklist
Outputs
Complete the BPR
Initiating Process Phase
Checklist to validate
that all process phase
activities are complete.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 1
Planning
The Planning Process Phase focuses on
developing the future state, identifying
performance targets, and documenting the
future business processes.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 2
In this chapter...
Planning
1
Approach
Page 3
1.1 Introduction
1.2 Recommended
Practices
2
Knowledge
Areas
Page 7
2.1 BPR Lifecycle
Management
2.2 Business
Analysis
and Future
Definition
2.3 Business
Process Design
2.4 Performance
Measurement
3
Process Phase
Checklist
Page 38
3.1 Complete the
Checklist
California Department of Technology
Business Process Reengineering Framework
Planning | Page 3
Planning
Approach
Business Process Design Performance MetricsBusiness Analysis and
Future Definition
BPR
Lifecycle Management
Figure 1-1
The Planning Process Phase is the third process phase of the Project Management
Lifecycle (PMLC). In this process phase, the project team will analyze solution
alternatives, secure the necessary funding, document requirements, and
determine an implementation approach. The BPR Practitioner works closely with
the Project Manager and project team to assist in the selection of the technology
solution. As shown in Figure 1-1, activities from all four knowledge areas occur
within this process phase and focus on:
• Planning the BPR work
• Designing the future state
• Supporting project activities such as the assessment of
solution alternatives
• Identifying perf
ormance targets
1.1 Introduction
During the Planning Process Phase, the BPR Practitioner takes the first steps in
laying out the future state of the business processes. This is done by designing
the future state business processes at a high level, supporting a solution gap
analysis, and determining the performance targets the business process
improvements will be measured against. The BPR Practitioner will engage
the project team and subject matter experts (SMEs) to ensure these items are
California Department of Technology
Business Process Reengineering Framework
Planning | Page 4
Planning
represented thoroughly and accurately in preparation for the Executing Process
Phase. These activities are contained with the four active knowledge areas of
this process phase.
BPR Lifecycle Management
The emphasis of the project shis from building a business case towards
supporting the business process design eort. The BPR Practitioner works
closely with the Project Manager throughout the Planning Process Phase to
integrate BPR activities into the project schedule and coordinate with other
project team members.
Business Analysis and Future Definition
The BPR Practitioner may be asked to assist in project team activities including
market research to identify solution alternatives, analysis of solution alternatives
to identify gaps, and requirements development.
Business Process Design
The BPR Practitioner leads the development of the future state business process by
facilitating design sessions with the BPR Design Team. This results in the creation
of the Future State Process Model with associated assumptions and constraints
that will meet the Business Goals and Objectives and the needs of customers.
Performance Measurement
In addition to the BPR Design Team’s eorts to establish the future state business
process, they will work to establish performance targets for each. These targets
help to provide direction for the amount of redesign that is necessary.
Once all BPR-related Planning Process Phase activities have been completed,
the BPR Practitioner will complete the BPR Planning Process Phase Checklist.
Figure 1-2 lists all of inputs, activities, and outputs for each knowledge area
during the Planning Process Phase.
Sequence of Activities
Although the knowledge areas are presented in a specific order for consistency
throughout the CA-BPR, the order in which the activities occur is independent
of each other. Activities may occur simultaneously and iteratively rather than
sequentially. The BPR Practitioner should apply experience and knowledge
of past projects, along with individual judgment, to determine the most
appropriate use sequencing activities for each unique project.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 5
Planning
Business Analysis
and
Future Definition
BPR Lifecycle
Management
Business
Process Design
Performance
Measurement
Inputs Activities Outputs
• Project Support Activities
• None
• Completed Future State Process
Model
• Solution Alternatives
• Design Future State Business Processes• Business Goals and Objectives
• Completed BPR Schedule
• Completed Current State Process
Model
• Identified Benchmarks
• Identified Customer Needs
• Identified Performance Baseline
• Prioritized Opportunities
• Completed Future State Process Model
• Identify and Document
Performance Targets
• Business Goals and Objectives
• Completed Current State Process
Model
• Completed Future State Process
Model
• Identified Benchmarks
• Identified Customer Needs
• Identified Performance Baseline
• Prioritized Opportunities
• Completed Performance
Target Inventory
• Determine and Plan for BPR Activities• Completed BPR Schedule
• Stakeholder Register
• Completed BPR Schedule
Concept Initiating Planning Executing ClosingClosingExecutingInitiatingConcept
Planning Process Phase Goal: Establish the Future State
Figure 1-2
California Department of Technology
Business Process Reengineering Framework
Planning | Page 6
Planning
1.2 Recommended Practices
The following recommended practices will help the BPR Practitioner develop
the Future State Process Model and support the assessment of solution
alternatives. These recommended practices apply to all BPR knowledge areas
and help identify a preferred solution.
Recommended
Practices
Review Recommended
Practices at the start of
the process phase.
Establish the “What” Before the “How”
As the BPR Practitioner works on developing the Future State Process Model,
the focus of design should be on “what” needs to happen, as opposed to “how.”
Focusing on the “how” may limit the solution alternatives. This increases the
risk of creating a solution that may not address the business needs or issues, or
allow the organization to fully capitalize on potential opportunities.
Take the Time to Document the Environment
It can be very tempting for the BPR Practitioner to skip over or shortchange the
documentation of assumptions, constraints, and impacts because the solution may
appear obvious. But taking the time to document will provide substantial benefits.
This helps improve planning, provides early identification of potential issues to
address, and fosters the ability to compare solutions in an objective manner.
Make Sure the Gaps are Known and Understood
It is rare that an out-of-the-box technology solution will fit perfectly with the
future state. Knowing this is important for Stakeholders to understand where
and what the gaps are, and how those gaps will need to be addressed to achieve
the future state. Without a thorough gap analysis, an organization risks wasting
time, eort, and budget on an unsuitable solution.
Coordinate Resource Needs with the Project Manager
Keep in mind that when considering project resources for development or
support of the future state, it is likely that those same resources are needed for
technology selection, transition planning, or other tasks. To minimize resource
contention and keep BPR tasks in alignment with other project eorts, the BPR
Practitioner should work with the Project Manager to make sure that resource
needs are communicated and coordinated with other project workstreams.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 7
Planning
Knowledge Areas
BPR Lifecycle Management
2.1 BPR Lifecycle Management
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Concept Initiating Planning Executing Closing
Ensure the Performance of the BPR Eort
Figure 2-1
The goal of BPR Lifecycle Management in the Planning Process Phase is to plan
the BPR activities and secure the BPR resources that are needed, as shown in
Figure 2-1. Activities across all knowledge areas gain momentum and need
to be coordinated and managed to ensure the project is ready for Execution
Process Phase activities. Significant emphasis needs to be placed on eective
communications in this phase, as many resources will be shared between BPR
and other project workstreams.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-2.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 8
Planning
BPR Lifecycle Management
Inputs
• Completed BPR Schedule
•
Stakeholder Regist
er
Roles
• BPR Practitioner
•
Project Sponsor
• Project Manager
Activities
• Determine and Plan for
BPR Activities
Skills
• Pr
oject Management
• Estimation
• Analysis
Tools
•
BPR Schedule Template
Outputs
• Completed BPR Schedule
Figure 2-2
2.1.1 Inputs
In order to complete the Planning Process Phase BPR Lifecycle Management
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Completed BPR Schedule: The Completed BPR Schedule from the Initiating
Process Phase will be leveraged and elaborated upon for Planning Process
Phase tasks.
Stakeholder Register: A product of the Project Management workstream, the
register lists Stakeholders and other project resources involved or aected by
the project. The BPR Practitioner and Project Manager will use the register to
identify resources needed for BPR tasks during the Planning Process Phase.
BPR Lifecycle Management
California Department of Technology
Business Process Reengineering Framework
Planning | Page 9
Planning
BPR Lifecycle Management
2.1.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in BPR Lifecycle Management activities during the Planning Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Leads the eort to determine BPR needs for the
Planning Process Phase
• Supports the Project Manager with developing
BPR staing and resource estimates
• Supports the Project Manager in scheduling
and resourcing BPR activities
Project Sponsor • Assists with securing BPR resources
• Determines if external resources are needed to
support BPR activities
Project Manager • Leads the development of the project’s
approach, work plan, schedule, and budget
• Monitors and controls project performance
• Manages project staing and resourcing
• Aligns and integrates BPR activities with other
project activities
2.1.3 Activities
The tasks completed under the BPR Lifecycle Management Knowledge Area
center on establishing the resources and scheduling needs for this process
phase. Although these activities are presented in a logical sequence, the BPR
Practitioner should apply his/her knowledge and experience to determine the
necessary activities and the order of activities for each project.
Determine and Plan for BPR Activities
Similar to what was completed in the Initiating Process Phase, BPR activities
within the Planning Process Phase must be identified, resourced, and scheduled.
As these items are addressed, they are added to the BPR Schedule that was
established during the Initiating Process Phase. To update the BPR Schedule,
the BPR Practitioner should complete the following:
• Review the entirety of this chapter to identify the various activities and
outputs that must be developed within each knowledge area in the
Planning Process Phase.
• Based on the project and organizational characteristics, identify the tasks
necessary to complete the identified activities. Consider any constraints
that will dictate the timing, frequency, and order the activities need to
be completed.
• Estimate the duration and eort to complete each task. Consider the scope
and complexity of the project to come up with appropriate numbers.
• Work with the Project Manager to identify available resources to complete
the tasks. The availability of resources to support the eort may require
re-work of the schedule.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 10
Planning
BPR Lifecycle Management
Inputs
The following is an
input to the activity:
• Completed BPR Schedule
(from the Initiating
Process Phase)
• Stakeholder Register
Tools
A template is available:
BPR Schedule
Skills
Use the following skills to
complete the activity:
• Analysis
• Estimation
• Project Management
To the extent possible, the same pool of resources identified during the Initiating
Process Phase should be used for Planning Process Phase activities. However,
new project team members and Stakeholders may become involved during this
process phase and should be considered for inclusion. This pool of resources
will be used for the following key activities:
• Participation in the Solution Gap Analysis
• Design of Future State Processes
• Identification of Performance Targets
Of particular importance is the identification of the BPR Design Team. The
purpose of the BPR Design Team is to design future state processes and identify
performance targets. Major design activities occur multiple times over the
PMLC—at a high level during this process phase and at a more detailed level
during the Executing Process Phase when the technology solution has been
acquired. While these activities do not require dedicated, full-time resources,
it is important to form a team that will remain intact to maintain continuity of
knowledge and momentum.
The BPR Practitioner will need to work with the Project Manager to identify BPR
Design Team members that have technical and functional knowledge and skills
to perform these activities. This team should have the following characteristics:
• A team of 6 to 12 people have been shown to be the most eective.
• The team should include sta who are directly involved in executing the
process, sta who provide input to the process, and sta who use the
output of the process.
• The team should contain members with decision-making authority.
• The team should contain members who have a broad perspective on
the intent of the process and member who have the knowledge and
experience executing the process.
• The team should contain members with BPR or other process
improvement experience.
• For larger eorts involving processes that span multiple departments or
agencies, the BPR Practitioner should include one or two sta who are
not involved with the process in any capacity. This can aid in providing
objectivity and provides a unique source of valuable input.
The BPR Practitioner should work with the Project Manager and leverage the
project organization chart and the Stakeholder Register to identify and allocate
these resources in the BPR Schedule. Once the schedule has been developed,
the BPR Practitioner will work with the Project Manager to integrate the tasks
into the greater project schedule to monitor and control.
For More Info...
For more information see
the Schedule Management
Section within the
Planning Process Phase of
the CA-PMF.
2.1.4 Tools
The tool that the BPR Practitioner will use within BPR Lifecycle Management
during the Planning Process Phase includes the following:
• BPR Schedule Template
2.1.5 Outputs
BPR Lifecycle Management produces the following output during the Planning
Process Phase:
• Completed BPR Schedule
California Department of Technology
Business Process Reengineering Framework
Planning | Page 11
Planning
BPR Lifecycle Management
Outputs
The following is an
output to the activity:
• Completed BPR Schedule
i
California Department of Technology
Business Process Reengineering Framework
Planning | Page 12
Planning
Business Analysis and Future Definition
2.2 Business Analysis and
Future Definition
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Concept Initiating Planning Executing Closing
Ensure the Future State is Sound
Figure 2-3
The focus of Business Analysis and Future Definition during the Planning Process
Phase is to help the project team define the solution by assisting in market
research to identify potential solution alternatives, solution gap analyses
to determine the fit of solution alternatives, and functional requirements
development. While these are project activities that the BPR Practitioner may
support, they are key inputs to the decision making process on whether and
how to move forward with both the BPR eort and the larger project as a whole.
Consequently, this knowledge area is critical to providing support for defining
the technology solution, as show in Figure 2-3.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-4.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 13
Planning
Business Analysis and Future Definition
Inputs
• Completed Future State
Process Model
• Solution Alternatives
Roles
• BPR Practitioner
• Project Manager
•
Project T
eam
• Subject Matter Experts
Activities
• Project Support Activities
Skills
• Judgment
•
Facilit
ation
• Analysis
Tools
• None
Outputs
• None
Figure 2-4
2.2.1 Inputs
In order to complete the Planning Process Phase Business Analysis and Future
Definition activities, the BPR Practitioner will need a thorough understanding of
the following inputs:
Completed Future State Process Model: This model depicts the desired future
state business process and is the basis for the gap analysis. The Future State
Process Model is an output of the Business Process Design Knowledge Area in
this process phase.
Solution Alternatives: Proposed alternatives (outside of small, low complexity
solutions) should have a business case that includes a description, development
approach, cost information, and other elements. Solution alternatives are
identified by the project team through market research.
Business Analysis and Future Definition
California Department of Technology
Business Process Reengineering Framework
Planning | Page 14
Planning
Business Analysis and Future Definition
2.2.2 Roles
The following table lists the roles and their associated responsibilities of
those involved in Business Analysis and Future Definition activities during the
Planning Process Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • May assist in market research to identify
solution alternatives
• May assist as a participant during Solution Gap
Analysis sessions
• May help facilitate parts of the Solution Gap
Analysis sessions
• May assist in requirements development activities
Project Manager • Participates in the gap analysis work sessions
Project Team • Performs market research to identify
solution alternatives
• Facilitates the Solution Gap Analysis sessions
• Documents the Solution Gap Analysis sessions
• Develops functional and non-functional
requirements
Subject Matter
Experts
• Participates in gap analysis work sessions
2.2.3 Activities
The tasks required to support project activities are presented in a logical
sequence below. The BPR Practitioner should leverage his/her experience and
judgment to assist in these tasks as needed.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 15
Planning
Business Analysis and Future Definition
Project Support Activities
During the Planning Process Phase, the project team may require the support
of the BPR Practitioner to perform certain activities. Typically, these involve
providing business process domain expertise since the BPR Practitioner is
instrumental in designing the future state. The BPR Practitioner should be aware
of these support activities and coordinate closely with the Project Manager to
ensure they are accounted for in the project schedule. This activity consists of
the following tasks:
• Support Market Research
• Support Solution Gap Analysis
• Support Requirements Development
Inputs
The following is an
input to the activity:
• Completed Future State
Process Model
(Output of the Business
Process Design Knowl-
edge Area in this process
phase)
• Solution Alternatives
Skills
Use the following skills to
complete the activity:
• Judgment
• Facilitation
• Analysis
Support Market Research
During the Planning Process Phase, the project team takes the Future State
Process Model and performs market research to collect information and analyze
the capabilities of solutions in the existing market. The BPR Practitioner may
be asked to help support the project team’s market research by serving as a
consultant and subject matter expert regarding future state processes.
Once the Future State Process Model (including impacts, assumptions, and
constraints) is complete, the project team will begin assessing the model in
order to perform market research and develop alternative solutions. For BPR
projects, this almost always means the acquisition or development of new or
improved technology. As the project team is working, there may be questions
regarding the intent and impact of various processes in the Future State
Process Model. Furthermore, the project team may solicit the BPR Practitioner’s
opinions regarding the applicability of various solutions. The BPR Practitioner’s
support of the project team concludes when the project team completes its
market research and identifies solution alternatives.
Support Solution Gap Analysis
A key project team activity during the Planning Process Phase is performing a
gap analysis between each identified solution alternative (outputs of market
research activities) and the Future State Process Model. The BPR Practitioner
will assist the project team as a subject matter expert (SME) during gap
analysis sessions. The goal of the BPR Practitioner is to help the project team
California Department of Technology
Business Process Reengineering Framework
Planning | Page 16
Planning
Business Analysis and Future Definition
have a basis for objective comparison of each solution alternative by helping
surface the business process gaps and associated impacts, assumptions, and
constraints. Having these items identified allow for careful decision making on
how the project should move forward.
The solution gap analysis is a structured process performed in facilitated
sessions with SMEs and led by an analyst from the project team. To assist in this
eort, the BPR Practitioner needs to review both the future state (as documented
in the Future State Process Model) and each solution alternative. Becoming
familiar with these items prior to the analysis will make the BPR Practitioner
a more eective participant. In addition to providing domain knowledge and
expertise, the BPR Practitioner may be asked to help guide other participants
through a walkthrough of the Future State Process Model during the sessions.
Support Requirements Development
A requirement is a documented representation of a condition or function that must
be met or possessed by a solution or solution component to satisfy a contract,
standard, specification, or business rule. The main objective or goal in defining
requirements is to communicate Stakeholder objectives, needs, and outcomes.
During the Planning Process Phase, the BPR Practitioner may be asked to provide
consultation and input to the project team’s definition of business and solution
requirements. Initially, the strategic business goals, business problems or
opportunities may form the basis for the business requirements. Thus, questions
may be asked regarding the Business Problem Statement, the Business Goals and
Objectives, Prioritized Opportunities, and Identified Customer Needs that the
BPR Practitioner produced in the previous process phases.
2.2.4 Tools
There are no BPR tools for the BPR Practitioner within the Business Analysis and
Future Definition Knowledge Area during the Planning Process Phase.
2.2.5 Outputs
There are no BPR outputs for the Business Analysis and Future Definition Knowledge
Area during the Planning Process Phase.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 17
Planning
Business Process Design
2.3 Business Process Design
Understand
Current Processes
Elaborate
Future Processes
Identify
Business Impact
Define
Future Processes
Business
Process Design
Concept Initiating Planning Executing Closing
Ensure the Future State is Established
Figure 2-5
The focus of Business Process Design during the Planning Process Phase, is to
develop and document the Future State Process Model for business processes
that are in the scope of the project. The desired future state includes designing
future Level 1 and may include Level 2 business processes. This Future State
Process Model will then be used to guide the identification and evaluation of
solution alternatives. The knowledge area’s goal for the Planning Process Phase
is shown in Figure 2-5.
A summary of the inputs, roles, skills, activities, tools, and outputs of this
knowledge area is presented in Figure 2-6.
Tools
A template is available:
Business Process
Modeling Tool
California Department of Technology
Business Process Reengineering Framework
Planning | Page 18
Planning
Business Process Design
Business Process Design
Inputs
• Business Goals and
Objectives
•
Completed BPR Schedule
•
Complet
ed Current State
Process Model
•
Identified Benchmarks
•
Identified Cust
omer Needs
•
Identified Perf
ormance
Baseline
•
Prioritized Opport
unities
Roles
•
BPR Practitioner
• BPR Design Team
Activities
• Design Fut
ure State
Business Processes
Skills
• Facilit
ation
• Modeling
Tools
• Business Process
Modeling Tool
Outputs
• Complet
ed Future State
Process Model
Figure 2-6
2.3.1 Inputs
In order to complete the Planning Process Phase Business Process Design activities,
the BPR Practitioner will need a thorough understanding of the following inputs:
Completed BPR Schedule: The BPR Schedule identifies the resources needed to
design the Future State Process Model. The Completed BPR Schedule is an output
of the BPR Lifecycle Management Knowledge Area in this process phase.
Concept Process Phase Work Products: Outputs from the Concept Process
Phase that will assist the BPR Practitioner in this knowledge area include the
Business Goals and Objectives.
Initiating Process Phase Work Products: Outputs from the Initiating Process
Phase that will assist the BPR Practitioner in this knowledge area include the
Completed Current State Process Model, Identified Benchmarks, Identified
Customer Needs, Identified Performance Baseline, and Prioritized Opportunities.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 19
Planning
Business Process Design
2.3.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Business Process Design activities during the Planning Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Facilitates work group sessions with the
BPR Design Team
• Documents and models the Future State
Business Processes Model and associated
assumptions and constraints
BPR Design Team • Participates in work group sessions to
produce the Future State Process Model and
associated assumptions and constraints
2.3.3 Activities
The tasks completed under the Business Process Design Knowledge Area center
on creating the Future State Process Model. Although these tasks are grouped and
sequenced in the sections that follow, the BPR Practitioner needs to apply his/her
knowledge and experience to ensure the appropriate sequence for each project.
Design Future State Business Processes
An important BPR activity during the Planning Process Phase is creating a high-
level Future State Process Model along with documenting related assumptions
and constraints. This is done by documenting the desired future state to achieve
the following goals:
• Solves the business problem
• Addresses the Business Goals and Objectives
• Addresses the Prioritized Opportunities
• Improves upon the Performance Baseline
California Department of Technology
Business Process Reengineering Framework
Planning | Page 20
Planning
Business Process Design
• Leverages technology solutions as enablers
• Supports the identification of solution alternatives
The level of detail required in the Future State Process Model is dependent on
the complexity of the end-to-end business processes under investigation. As a
general rule, the future state should at least be modeled to the Level 1 business
process. For complex scenarios, the BPR Practitioner should include the Level
2 sub-processes. The BPR Practitioner should consult with the project team
and Project Manager as necessary to determine the appropriate level of detail
needed to achieve the goals outlined above.
The Future State Process Model is developed and documented in facilitated
sessions consisting of carefully chosen participants who form the BPR Design Team.
The quality and eicacy of the resulting Future State Process Model developed
during the Planning Process Phase will depend heavily on the knowledge, skills,
and experience of the BPR Practitioner to apply BPR techniques and facilitate
design sessions. Additionally, eective design sessions depend on:
• Eective preparation. Design sessions are most eective when there is
a common understanding of the current business processes, business
problems and issues, improvement opportunities, and legislative or union
contract constraints.
• Keep the business goals and objectives at the forefront. Clear objectives
are needed to drive the design sessions. The BPR Practitioner needs to
ensure a common understanding of the business goals and objectives,
including customer needs.
• Participants’ expertise to analyze and suggest improvements. Design
sessions will require the input from participants to identify improvements.
It is valuable to have participants with experience in business process
reengineering. Also, individuals with an understanding of various technologies
can also be helpful in understanding how the solutions may be applied.
• Employ cross-functional teams for outside-the-box thinking. The best
improvements tend to take place when multiple viewpoints are solicited. It
may be challenging for certain participants to see past the “but that’s how
we’ve always done it” view.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 21
Planning
Business Process Design
This activity consists of the tasks below and are described in the sub-sections
that follow:
• Prepare for Design Sessions
• Facilitate Design Sessions
• Document and Model Future State Business Processes
Inputs
The following is an
input to the activity:
• Completed BPR Schedule
Prepare for Design Sessions
The BPR Practitioner will first refer to the BPR Schedule to identify the BPR
Design Team resources that will participate in the facilitated sessions to
produce the Future State Process Model, assumptions and constraints. The
BPR Practitioner needs to verify that participants include SMEs, Stakeholders,
and/or project team members that have domain knowledge regarding specific
needs, processes, or functional areas. Additionally, the team must be cross-
functional, and the size of the team should be based upon the breadth and
depth of experience of those selected and the number of participants needed
to cover all processes and functional areas.
Skills
Use the following skills to
complete the activity:
• Facilitation
Tools
A template is available:
Business Process
Modeling Tool
Inputs
The following is an
input to the activity:
• Business Goals and
Objectives
• Identified Performance
Baseline
• Identified Benchmarks
• Prioritized Opportunities
• Current State Business
Process Model
• Identified Customer
Needs
The BPR Practitioner should serve as the facilitator during the design sessions,
guiding the participants in the creation of the Future State Process Model. The
BPR Practitioner will also need to document the designs using business process
models and forms for capturing assumptions and constraints. Templates for
these models and forms are included in the Business Process Modeling Tool.
To ensure that the participants have a common understanding of the eort and
in preparation for the design sessions, the BPR Practitioner should share the
following information ahead of the first scheduled meeting for review:
• Business Goals and Objectives. The BPR Practitioner should refer to
these goals and objectives as a way to verify the Future State Process
Model resolves the underlying problems and issues.
• Identified Performance Baseline and Identified Benchmarks. The
Future State Process Model should result in process improvement. The
BPR Practitioner will therefore refer to these performance indicators and
levels regularly.
• Prioritized Opportunities. The BPR Practitioner should refer to these
opportunities to ensure newly designed processes are aligned.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 22
Planning
Business Process Design
• Current State Process Model. When developing the Future State Process
Model, it is oen easier and more productive to begin with the Current
State Process Model rather than try to develop a new model from scratch.
• Identified Customer Needs. The key to the process designs is to ensure
that they meet the needs of customers.
To help facilitate the discussion, the BPR Practitioner should develop a Level
1 Future State Process Model based on the inputs identified above to have
something for the BPR Design Team to react to and use as a starting point. The
BPR Practitioner should employ redesign techniques that are discussed below.
It is important to plan and structure the sessions in advance to secure the
necessary participation. The number and length of sessions required depends
on the number and complexity of the business processes. A business process that
contains numerous sub-processes will most likely require more reengineering
considerations than a simpler process. The BPR Practitioner will need to take
these into account and leverage past experience and good judgment when
identifying the number of sessions.
Facilitate Design Sessions
As the facilitator of the design sessions, the BPR Practitioner is responsible for
guiding the participants to produce a Future State Process Model that addresses
the goals identified above, and identifying the associated assumptions and
constraints with the newly designed processes.
The session begins with an introduction of the purpose of the session, the
anticipated outcomes, and the roles of the BPR Design Team. Discussing this
upfront is important to establishing the expectations for the team. It is helpful
to keep these items visible, such as on a white board or flip chart, so the BPR
Practitioner can refer to them in case discussions go o-track.
Aer introductions, the BPR Practitioner performs a guided walkthrough to
orient the team to the Current State Process Model and the preliminary design
to introduce the key reengineering opportunities. The BPR Practitioner uses
a number of BPR techniques to solicit feedback from the participants. Eight
techniques are presented on the following pages.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 23
Planning
Business Process Design
Technique #1: Task integration and compression
The task integration and compression technique takes sequential processes
that oen include handos to other resources, and integrates these processes
to be performed by one person or team. Look at the process model for a
sequential series of two, three or more processes that could be combined into
a single process. For example, if a process model shows one party initiating a
transaction, another party reviewing it, and a third party approving it, see if
those could be combined into a single party performing a review/approval.
This technique can be used with many models and especially applicable for
those that have:
• Relatively simple sequences of business processes and sub-processes;
• Slow throughput identified as an issue;
• Large numbers of handos identified as an issue; and/or
• Large numbers of errors identified as an issue.
Below are examples of questions the BPR Practitioner can use to employ
this technique.
• Can we combine these related processes?
• Why do they need to be done by separate groups?
• Can we eliminate this process? What value does it add here?
The key benefits of task integration and compression include:
• Reductions of handos which reduces errors and delays.
• Reductions of process administration overhead associated with fewer
quality checks and reconciliations.
• Improved control due to fewer actors in the process.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 24
Planning
Business Process Design
Technique #2: Natural precedence
The natural precedence technique sequences processes and sub-processes into
an order that is a natural and eicient flow. For example, if the current process
has mail coming into a warehouse and then being transported somewhere for
sorting, it may be more eicient to include all mail sorting and processing at the
point of entry to cut down on transportation time.
This technique can be used with many models and especially applicable for
those that have:
• Many business processes and/or sub-processes;
• Many handos and decisions areas; and/or
• Points in the model where extensive rework is common.
Below are examples of questions the BPR Practitioner can use to employ
this technique.
• Would it function better if the processes were rearranged?
• Why does this process occur here rather than there?
• Can we move this process closer to related processes?
The key benefits of natural precedence include:
• Reductions of cycle time due to removal of intermediary sub-processes.
• Reductions of rework needed due to the elimination of unnecessary
transitions.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 25
Planning
Business Process Design
Technique #3: Hybrid centralization and decentralization
In some cases, previous process design work may have followed a strict rule
to either centralize or decentralize, when in fact, a combination works best.
For example, an organization may determine that centralized receipt of vendor
invoices coupled with decentralized departmental approvals is the most
eicient way to begin processing a payment cycle.
This technique can be used with many models and especially applicable for
those that have:
• Multiple identical processes;
• Multiple analogous processes; and/or
• Ineicient centralized processes.
Below are examples of questions the BPR Practitioner can use to employ
this technique.
• Would it be better if this process were handled by a single business group
rather than individually?
• Would it be better if this process were handled by individual business groups?
• What aspects of this centralized process may be better done by the
individual?
The key benefits of hybrid centralization and decentralization include:
• Reductions of cycle time due to fewer handos (decentralization).
• Increases in cross-trained employees (decentralization).
• Increased economies of scale due to increased volume and specialization
(centralization).
California Department of Technology
Business Process Reengineering Framework
Planning | Page 26
Planning
Business Process Design
Technique #4: Minimal input/output sources
The minimal input/output sources technique simplifies the number of inputs
or the number of outputs for a process. For example, if a process requires
many forms, it may simplify data collection if the inputs could be streamlined,
consolidated, or even eliminated. The BPR Practitioner should have the
participants review cases of multiple input or output forms to see if there are
eiciencies to be gained through redesigning and consolidating those forms.
This technique can be used with many models and especially applicable for
those that have:
• Multiple inputs/outputs and/or sources;
• Extensive reconciliation steps; and/or
• Instances of duplication of processes/sub-processes.
Below are some examples of questions the BPR Practitioner can use to employ
this technique.
• Can we modify inputs/outputs to improve this process?
• Do we truly need all of these items as inputs? Why?
• Do we need all of these inputs at this point in the process?
• Does this end-user truly need these items in the output?
• How can we eliminate the number of dependencies here?
The key benefits of minimal input/output sources include:
• Reductions of cycle time due to fewer inputs/outputs required.
• Increases in product/service consistency by better timely delivery of
essential items.
• Reductions of reconciliations and quality checks.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 27
Planning
Business Process Design
Technique #5: Shiing work boundaries
The shiing work boundaries technique shis the work from the organization
to either the customer, supplier, or third party. For example, if an organization
manually manages vendor registration and certification, it can shi much of
the vendor data management to the users themselves through a vendor web
portal. Another simple example is having an automated system for resetting
passwords that customers can use themselves.
This technique can be used with many models and especially applicable for
those that have:
• Highly specialized partners;
• Backlogs due to insuiciently trained resources or lack of data; and/or
• High overhead or transaction costs.
Below are some examples of questions the BPR Practitioner can use to employ
this technique.
• Why does the business group do this process? Is it really a core function?
• Is there anyone else that would do this process better?
• What processes can we ask input-providers to do?
• What processes can we ask output-users to do?
• What can we ask input-providers/output-users to do dierently to improve
this process?
The key benefits of shiing work boundaries include:
• Reductions of handos to specialized intermediaries.
• Decreases in cycle time due to fewer processes/sub-processes.
• Reductions of overhead costs due to fewer specialized resources.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 28
Planning
Business Process Design
Technique #6: Decreased alternatives
The decreased alternatives technique focuses on eliminating low value
alternatives that oen complicate and increase decision-making time. For
example, an automobile manufacturer which has a vehicle with many available
options and features may choose to eliminate the number of options which can
allow for improved economies of scale. In an oice environment, an agency
may reduce the number of methods an employee can use to enter their time
from several to one (for example, manual punch cards, fingerscans, manual
timesheets), simplifying and streamlining the first steps of the payroll process.
This technique can be used with many models and especially applicable for
those that have:
• High information collection and analysis costs;
• Many similar and separate process inputs; and/or
• Many alternate paths.
Below are some examples of questions the BPR Practitioner can use to employ
this technique.
• How much value does this option provide? Is it core to the business
process?
• Is this alternative worth having this separate process for it?
• Why does this alternative process exist? How oen does this happen? What
would happen if it did not exist?
The key benefits of decreased alternatives include:
• Reductions of information collection costs due to fewer options serviced.
• Faster decision-making due to a focus on core functions.
• Reductions of overall model complexity.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 29
Planning
Business Process Design
Technique # 7: Increased alternatives
The increased alternatives technique focuses on providing more options,
allowing users to determine the most expeditious alternative for each situation.
For example, instead of requiring a user to always mail a document, it may be
beneficial to allow them to scan and email it, fax it, or electronically attach it to
a system transaction.
This technique can be used with many models and especially applicable for
those that have:
• Interfaces with a variety of input-providers; and/or
• A high volume of data collection.
Below are some examples of questions the BPR Practitioner can use to employ
this technique.
• Does separating these into dierent processes improve eiciency?
• Does providing additional means of input improve the process?
• What kind of options can be provided to reduce this backlog?
The key benefits of increased alternatives include:
• Reductions of cycle times for various services/products.
• Increases in customer service and satisfaction due to reduced cycle times.
• Increases in customer satisfaction due to additional input modes.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 30
Planning
Business Process Design
Technique #8: Timing of decision-making
The timing of decision-making technique focuses on moving decision-making
tasks in the process to improve eiciencies and reduce errors. Decision-making
tasks can either be moved to occur earlier in the process or moved to occur later
in the process. Decision-making tasks that are moved earlier reduce the eort
spent committed to potentially unfruitful items. Moving decision-making tasks
later in the process allows for more data to be aggregated to make a correct
decision, thus reducing the number of errors and amount of rework.
This technique can be used with many models and especially applicable for
those that:
• Have many decision points;
• Have identified high costs associated with slow decision-making;
• Instances of case-by-case decision-making; and/or
• Decisions that may be delayed to due lack of information.
Below are some examples of questions the BPR Practitioner can use to employ
this technique.
• What can be done earlier to reduce reconciliation and quality checks?
• How can we filter out these issues earlier in the process?
• What impact does waiting for more information have?
• Can this be done in aggregate later in the process?
• Does this decision need to be made at this point in the process?
• What benefits might there be if this decision were made at a later point?
The key benefits of early decision-making include:
• Reductions of overhead and process management costs due to fewer
decision points.
• Increases in resource utilization.
• Avoidance of extraneous decision-making costs.
• Reductions of rework due to erroneous decision based on insuicient data.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 31
Planning
Business Process Design
It is not unusual to see a BPR team struggling to find improvement ideas
while looking at a Current State Process Model. The BPR Practitioner can
use the questions associated with each technique above to spur discussion
and brainstorm improvement ideas. While facilitating the session, the BPR
Practitioner should document the results. The responsibilities of facilitating
and documenting may be split amongst multiple BPR Practitioners, if available.
The BPR Practitioner must also remember to prompt the participants to identify
assumptions and constraints associated with the design.
Assumptions are beliefs assumed to be true, but not yet proven. Examples of
assumptions include:
• The technological ability to run parallel processes.
• The ability to modify job responsibilities without impacting civil service
union classifications.
• The ability to modify a mandate or regulation prior to implementation.
• The availability of resources to maintain the new solution.
Constraints are things that might restrict or limit capabilities. Generally, there
are two categories of constraints:
• Business Constraints – constraints related to limitations on available
solutions or processes that cannot be changed. Examples include having a
fixed budget, inability to redesign inputs, limitation on type of responsibilities
that can be shared between employee types, limitations based on privacy
laws, inability to outsource job functionality, and processes that must occur
prior to others.
• Technological Constraints – constraints related to the technological
capabilities of a solution. Examples include compatibility with existing
technology platforms, use of specific development language, use of
existing hardware, required methods of access, availability and uptime
requirements, and cybersecurity concerns.
Once this information is collected, the BPR Practitioner completes the Future
State Process Model. Guidance regarding the documentation of the models,
assumptions, and constraints along with templates are provided in the Business
Process Modeling Tool. The completed documentation should be shared and
validated with the participants to ensure the information has been captured
and represented accurately before shared with a larger audience, including
review and approval.
Skills
Use the following skills to
complete the activity:
• Modeling
Tools
A template is available:
Business Process
Modeling Tool
California Department of Technology
Business Process Reengineering Framework
Planning | Page 32
Planning
Business Process Design
Once finalized, the resulting Future State Process Model serves as the basis for
evaluating technology solutions and eectively illustrates the future vision of
the project. The Future State Process Model then serves as an input to other
project activities, such as:
• Market research of solution alternatives
• Requirements development activities
• Gap analysis of the identified solution alternatives
• Request for Proposal or other solicitation development activities
(if needed)
2.3.4 Tools
The tool that the BPR Practitioner will use within Business Process Design
during the Planning Process Phase includes the following:
• Business Process Modeling Tool
Tools
A template is available:
Completed Future State
Process Model
2.3.5 Outputs
Business Process Design produces the following output during the Planning
Process Phase:
• Completed Future State Process Model
California Department of Technology
Business Process Reengineering Framework
Planning | Page 33
Planning
Performance Measurement
2.4 Performance Measurement
Identify
Performance Baseline
Define
Performance Reports
Generate
Performance Reports
Performance
Measurement
Concept Initiating Planning Executing Closing
Ensure Improvements are Measurable
Determine
Future Measures
and Performance
Figure 2-7
The goal of Performance Measurement is to document the business process
improvements made and provide quantifiable objectives for the BPR eort, as
shown in Figure 2-7. During the Planning Process Phase, the BPR Practitioner
facilitates the identification of performance targets for the future state business
process that are aligned to the objectives of the project. Identifying meaningful
performance targets provides a quantifiable method to describe improvements
for a given business process.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
Performance Measurement Knowledge Area is presented in Figure 2-8.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 34
Planning
Performance Measurement
Performance Measurement
Inputs
• Business Goals and
Objectives
•
Completed C
urrent State
Process Model
• Completed Future State
Process Model
• Identified Benchmarks
•
Identified Customer Needs
•
Identified Performanc
e
Baseline
•
Prioritized Opportunities
Roles
• BPR Practitioner
•
Project Sponsor
• BPR Design T
eam
•
Stakeholder
s
Activities
• Identify and Document
Performance Targets
Skills
•
Facilitation
• Analysis
Tools
• Performanc
e Target
Inventory Template
• Performance Metric
Assessment Template
Outputs
• Complet
ed Performance
Target Inventory
Figure 2-8
2.4.1 Inputs
In order to complete the Planning Process Phase Performance Measurement
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Goals and Objectives: An output of the Concept Process Phase, they
are referred to during the facilitated sessions in this knowledge area to ensure
suggested performance targets are aligned to the project’s goals and objectives.
Completed Future State Process Model: This model is reflective of the
improvements the BPR Design Team has made to the current state. As such, they
provide a gauge for how reasonable suggested targets may be. The Completed
Future State Process Model is an output of the Business Process Design Knowledge
Area in this process phase.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 35
Planning
Performance Measurement
Initiating Process Phase Work Products: Outputs from the Initiating Process
Phase that will assist the BPR Practitioner in this knowledge area include the
Identified Performance Baseline, Completed Current State Process Model,
Identified Benchmarks, Identified Customer Needs, and Prioritized Opportunities.
2.4.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Performance Measurement activities during the Planning Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Facilitates work sessions to identify performance
targets for future state business processes
• Documents future state performance targets
• Facilitates review of performance targets with
Stakeholders and the Project Sponsor
Project Sponsor • Provides input on achievability of performance
targets
BPR Design Team • Participates work sessions to determine future
state performance targets
Stakeholders • Provides input on achievability of performance
targets
2.4.3 Activities
The tasks required to determine the performance targets are presented in a
logical sequence below. The BPR Practitioner should leverage his/her experience
and judgment to adjust tasks and sequence as needed.
California Department of Technology
Business Process Reengineering Framework
Planning | Page 36
Planning
Performance Measurement
Determine Performance Targets
Performance targets are measurements that become indicators of how much
improvement is expected from the Future State Process Model. Each process
that undergoes reengineering should have at least one performance target
as a means of measurement. To establish these targets, the BPR Practitioner
will facilitate sessions with the BPR Design Team to identify target values for
each performance baseline metric. The results are then documented in the
Performance Target Inventory. This activity consists of the following tasks:
• Identify and Document Performance Targets
Inputs
The following is an
input to the activity:
• Prioritized Opportunities
Skills
Use the following skills to
complete the activity:
• Facilitation, Analysis
Tools
A template is available:
Performance Target
Inventory
Identify and Document Performance Targets
During the same design sessions that produce the Future State Process Model, the
BPR Practitioner directs the BPR Design Team to identify new performance target
values for the future state. Participants should aim to create target values that:
• Are based on facts and careful analysis of the baseline and current
environment;
• Challenge the organization to achieve performance improvements; and
• Are achievable within a reasonable timeframe.
Participants use a number of resources to identify target values. These include:
• Identified Performance Baseline. This baseline provides participants
with previously identified metrics and a starting point for each metric’s
target value.
• Identified Benchmarks. Benchmarks provide performance levels of peer
organizations. These values provide a sanity-check for participants to
gauge reasonableness of suggested target values.
• Future State Process Model and Current State Process Model.
Participants compare the future state against the current state and
discuss and analyze how process improvements will impact performance
improvement. This helps participants choose performance targets
supported by process improvements.
• Identified Customer Needs and Business Goals and Objectives.
Participants refer to these to ensure target values align to the stated goals
of the project and help achieve customer needs.
Inputs
The following is an
input to the activity:
• Identified Performance
Baseline
• Identified Benchmarks
• Completed Future State
Process Model
• Completed Current State
Process Model
• Identified Customer
Needs
• Business Goals and
Objectives
California Department of Technology
Business Process Reengineering Framework
Planning | Page 37
Planning
Performance Measurement
Using these resources, the BPR Practitioner facilitates the BPR Design Team
in establishing new target values and target dates for each metric. The BPR
Practitioner asks participants to review and consider the baseline, benchmarks,
and improvements to the future state before soliciting best-guess target values.
The BPR Practitioner then facilitates a discussion on the reasonableness of
the suggested target values by again comparing them to the benchmarks and
improvements in future state process model. Once a consensus is reached,
target values are documented in the Performance Target Inventory.
It should be noted that during the identification of target values, it may become
apparent that certain baseline performance metrics are no longer a part of
the future state. This may happen to a very small number of the metrics and
is usually a result of the elimination of sub-processes that are related to the
generation of the metric. In these cases, the BPR Practitioner may need to direct
the BPR Design Team to create new replacement metrics, if needed, and use the
criteria in the Performance Metric Assessment as a guide to do so.
Aer the Performance Target Inventory is completed, the BPR Practitioner
elicits input from Stakeholders, including the Project Sponsor. It is important
to get input from executives and business process owners as they oen provide
an additional perspective on the appropriateness of target values. These
Stakeholders tend to keep a big-picture of the future vision of the organization
in mind, and may increase targets to challenge the organization further or
decrease targets to facilitate achievability. Aer getting input from these
Stakeholders, the BPR Practitioner finalizes the Performance Target Inventory,
which becomes an important input in the detailed future state design activities
in the Executing Process Phase.
2.4.4 Tools
The tools that the BPR Practitioner will use within Performance Measurement
during the Planning Process Phase includes the following:
• Performance Metric Assessment Template
• Performance Target Inventory Template
Tools
A template is available:
Performance Metric
Assessment
2.4.5 Outputs
Performance Measurement produces the following output during the Planning
Process Phase:
• Completed Performance Target Inventory
Outputs
The following is an
output to the activity:
• Completed Performance
Target Inventory
California Department of Technology
Business Process Reengineering Framework
Planning | Page 38
Planning
Process Phase Checklist
va
l Lifecycl
e
Project Appro
3.1 Complete the Checklist
Once all of the BPR activities within the Planning Process Phase are done, the
process phase checklist should be completed. The checklist provides a list of
“why, how, what, who, where, and when” questions to verify that all items in the
process phase are complete.
Tools
A template is available:
BPR Planning Process
Phase Checklist
The process phase checklist helps to identify and document repeatable steps,
from project to project, to ensure that the correct activities are completed at the
right time, every time.
Process phase checklists assist the BPR Practitioner in quickly and confidently
identifying areas of concern within this process phase. In this case, completion
of the checklist provides a clear milestone that the Planning Process Phase is
complete, including:
• Completed BPR Schedule
• Completed Future State Process Model
• Completed Performance Target Inventory
Project Appro
• Completed BPR Planning Process Phase Checklist
Outputs
Complete the BPR
Planning Process Phase
Checklist to validate that
all process phase activities
are complete.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 1
Executing
The Executing Process Phase focuses on
designing the details (the activities and tasks)
of the future state business processes. This
includes identifying performance metric
reporting solutions and implementing new
business processes.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 2
In this chapter...
Executing
1
Approach
Page 3
1.1 Introduction
1.2 Recommended
Practices
2
Knowledge
Areas
Page 8
2.1 BPR Lifecycle
Management
2.2 Business
Analysis
and Future
Definition
2.3 Business
Process Design
2.4 Performance
Measurement
3
Process Phase
Checklist
Page 36
3.1 Complete the
Checklist
California Department of Technology
Business Process Reengineering Framework
Executing | Page 3
Executing
Approach
Business Process Design Performance MetricsBusiness Analysis and
Future Definition
BPR
Lifecycle Management
Figure 1-1
The Executing Process Phase is the fourth process phase of the Project Management
Lifecycle (PMLC) and, as indicated in Figure 1-1, activities from all four knowledge
areas occur. During this process phase, the BPR Practitioner works closely with the
project team to align and integrate business process designs with the technology
solution. This includes designing the new processes at a detailed level, defining
performance metrics reporting, and supporting other project activities such as
functional gap analyses, training, and implementation.
1.1 Introduction
BPR activities during the Executing Process Phase build on the business process
analysis and outputs completed in the Planning Process Phase. The sections
below describe these activities in context with each active knowledge area.
BPR Lifecycle Management
Because SMEs and Stakeholders are a vital part of detailed future state process
design, it is important that the BPR Practitioner work with the Project Manager to
build a common understanding of tasks, schedule, and resources. Any contention
for SMEs and Stakeholder time should be resolved quickly so as to not negatively
impact the schedule for BPR work or the overall technology project.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 4
Executing
Business Analysis and Future Definition
The BPR Practitioner plays a support role to a number of important project team
activities resulting in the implementation of the future state. These activities
include rolling out the future vision to any newly informed Stakeholders,
performing a functional gap analysis, training, and implementation support. In
order to support these activities, the BPR Practitioner will need to work closely
with the project team throughout the process phase to coordinate these activities
and tasks.
Business Process Design
There is a significant amount of activity in this knowledge area for the Executing
Process Phase. The BPR Practitioner must plan and execute design sessions
with Stakeholders that emulate previous sessions, but document designs at a
lower level of detail. These sessions will focus on the activity and task level,
and to the degree possible, leverages the technical solution functionality or
components. The result should be a series of process models that outline the
future state at a level of detail that can be implemented and measured.
Performance Measurement
In the Performance Measurement Knowledge Area, the BPR Practitioner focuses
on defining the data collection and reporting mechanisms available with the
acquired solution. These activities are performed in conjunction with the project
team and must be considered carefully, as the measures should be relatively easy
to gather and easy to report.
Once all BPR-related Executing Process Phase activities have been completed, the
BPR Practitioner will complete the BPR Executing Process Phase Checklist. Figure
1-2 lists all of inputs, activities, and outputs for each knowledge area during the
Executing Process Phase.
Sequence of Activities
Although the knowledge areas are presented in a specific order for consistency
throughout the CA-BPR, the order in which the activities occur is independent
of each other. Activities may occur simultaneously and iteratively rather than
sequentially. Where an output from one knowledge area is an input to another, it is
not required that they have to be in final form; however, they should be reasonably
draed to contain a majority of the information the input/output is expected to
contain. The experience and knowledge of past projects and individual judgment
should be used to determine the most appropriate sequencing of activities for
each unique project.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 5
Executing
Business Analysis
and
Future Definition
BPR Lifecycle
Management
Business
Process Design
Performance
Measurement
Inputs Activities Outputs
• Project Support Activities
• None
• Completed Future State Process
Model
• Functional Requirements
• Design Detailed Future State
Business Processes
• Business Goals and Objectives
• Completed BPR Schedule
• Completed Current State Process
Model
• Completed Future State Process
Model (high-level)
• Completed Performance
Target Inventory
• Completed Future State Process Model
(detailed)
• Determine Data Sources and
Reporting Solutions
• Completed Future State Process
Model
• Completed Performance
Target Inventory
• Updated Performance
Target Inventory
• Determine and Plan for BPR Activities• Completed BPR Schedule
• Stakeholder Register
• Completed BPR Schedule
Concept Initiating Planning Executing ClosingClosingPlanningInitiatingConcept
Executing Process Phase Goal: Implement the Future State
Figure 1-2
California Department of Technology
Business Process Reengineering Framework
Executing | Page 6
Executing
1.2 Recommended Practices
The following recommended practices will help the BPR Practitioner develop
and implement the Future State Process Model. These recommended practices
apply to all BPR knowledge areas and help to define a detailed solution and
support the implementation.
Recommended
Practices
Review recommended
practices at the start of
the process phase.
Integrate the BPR Activities with Technology and
Organizational Change Management (OCM) Eorts
From the end user perspective, the deployment of processes and new
technology, training, and support structures all need to work together
seamlessly for a successful rollout. Therefore, setting up regular meeting
times to integrate and sync BPR activities with the technology implementation
schedules and approaches is vital. Similarly, integrating BPR activities with
communication and training eorts will help foster a coordinated and more
seamless experience for Stakeholders and end users.
Timebox the Development of Detailed Processes
In the Executing Process Phase, the BPR Practitioner will be facilitating design
sessions with Stakeholders, working at a detailed task and activity level.
Without a clear due date, the design work can easily become overthought and
over-engineered. Limiting design time will help keep your design focused on
the most prevalent needs, and will maximize the value of the time spent in the
design sessions.
One method of implementing this is to consider alignment with technical
development. Design sessions and the resulting documentation should
be completed prior to the beginning of development activities. Ideally,
documentation from detailed design sessions should be completed far enough
in advance of development to allow the technology team time to integrate
those designs into their own work. Therefore, the BPR Practitioner should work
with the project team to clearly understand implementation timeframes, and
then timebox the detailed design sessions accordingly.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 7
Executing
Limit the Design of Exceptions
It is not necessary (and rarely possible) to design a detailed process that
accommodates every exception condition. This is especially true when there
are multiple activities or tasks with multiple paths through each – the sheer
number of possible combinations can quickly become overwhelming.
Therefore, the BPR Practitioner should focus the design eort on just those
conditions and exceptions that occur most oen, ignoring the options that are
rare, or perhaps are possible but in fact have never occurred. This will ensure
that BPR resources are focused on their highest and best use, and that design
eorts are targeted to areas most likely to yield value.
Take a User–Centered Design Approach to Reengineering
The best improvements tend to take place when multiple viewpoints are
solicited, especially that of the user. For example, it may be tempting to only
have payroll clerks design time entry approval processes, but there is value in
getting users involved that input or evaluate the time reporting data. Ensuring
the needs of the users are met will ultimately increase the adoption and
utilization of the business process and technology to achieve the project goals.
Customize Processes, Not Technology
When implementing commercial o-the-shelf (COTS) solutions, it may be
tempting to customize systems to match existing processes. This can lead
to overly complex systems with custom upgrade that require high levels of
maintenance that are expensive to maintain. To realize the inherent benefits of
COTS solutions, processes should be modified to the technology.
Start with Simple, Discrete Processes
Successful BPR design sessions oen target low-hanging fruit first and build
momentum from those early successes. Start with simple, discrete processes
and sub-processes to introduce the idea of process improvement and build
momentum with quick wins. Starting with simpler processes also allows the BPR
Design Team to better internalize the steps involved in process improvement,
producing better results when more complex processes are analyzed.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 8
Executing
Knowledge Areas
BPR Lifecycle Management
2.1 BPR Lifecycle Management
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Concept Initiating Planning Executing Closing
Ensure the Performance of the BPR Eort
Figure 2-1
The goal of BPR Lifecycle Management in the Executing Process Phase, as
shown in Figure 2-1, is to manage the BPR work. The BPR Practitioner should
work closely with the Project Manager to develop and implement monitoring
and control mechanisms to keep the BPR eort on track and in sync with the
other project eorts.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-2.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 9
Executing
BPR Lifecycle Management
BPR Lifecycle Management
Inputs
• Completed BPR Schedule
• Stakeholder Register
Roles
• BPR Practitioner
• Project Sponsor
• Project Manager
Activities
• Det
ermine and Plan for
BPR Activities
Skills
• Project Manag
ement
• Analysis
• Estimation
Tools
•
BPR Schedule Template
Outputs
•
Completed BPR Schedule
Figure 2-2
2.1.1 Inputs
In order to complete the Executing Process Phase BPR Lifecycle Management
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Completed BPR Schedule: The Completed BPR Schedule from the Planning
Process Phase will be leveraged and elaborated upon for Executing Process
Phase tasks.
Stakeholder Register: A product of the Project Management workstream, the
register lists Stakeholders and other project resources involved or aected by
the project. The BPR Practitioner and Project Manager will use the register to
identify resources needed for BPR tasks during the Executing Process Phase.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 10
Executing
BPR Lifecycle Management
2.1.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in BPR Lifecycle Management activities during the Executing Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Leads the eort to determine BPR needs for the
Executing Process Phase
• Supports the Project Manager with developing
BPR staing and resource estimates
• Supports the Project Manager in scheduling
and resourcing BPR activities
Project Sponsor • Assists with securing BPR resources
• Determines if external resources are needed to
support BPR activities
Project Manager • Leads the progressive elaboration and
implementation of the project’s work plan,
schedule, and budget
• Monitors and controls project performance
• Manages project staing and resourcing
• Aligns and integrates BPR activities with other
project activities
2.1.3 Activities
The tasks completed under the BPR Lifecycle Management Knowledge Area
center on establishing the resources and scheduling needs for this process
phase. Although these activities are presented in a logical sequence, the BPR
Practitioner should apply his/her knowledge and experience to determine the
necessary activities and the order of activities for each project.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 11
Executing
BPR Lifecycle Management
Determine and Plan for BPR Activities
Similar to what was completed in the Planning Process Phase, BPR activities
within the Executing Process Phase must be identified, resourced, and
scheduled. As these items are addressed, they are added to the BPR Schedule
that was used in the Planning Process Phase. To update the BPR Schedule, the
BPR Practitioner should complete the following:
• Review the entirety of this chapter to identify the various activities and
outputs that must be developed within each knowledge area in the
Executing Process Phase.
• Based on the project and organizational characteristics, identify the tasks
necessary to complete the identified activities. Consider any constraints
that will dictate the timing, frequency and order the activities need to
be completed.
• Estimate the duration and eort to complete each task. Consider the scope
and complexity of the project to come up with appropriate numbers.
• Work with the Project Manager to identify available resources to complete
the tasks. The availability of resources to support the eort may require re-
work of the schedule.
Tools
A template is available:
BPR Schedule
Skills
Use the following skills to
complete the activity:
• Analysis
• Estimation
• Project Management
Inputs
The following are
inputs to the activity:
• Stakeholder Register
• Completed BPR Schedule
During the Executing Process Phase, the same pool of resources identified
during the Planning Process Phase should be used for BPR activities. However,
it is likely that new Stakeholders, such as a system integrator, have been added
to the project with the acquisition of the technical solution. Resources with
technical solution domain expertise are important to BPR activities during this
process phase and should be added to the resource pool. These resources will
be used for the following key activities:
• Design Detailed Future State Business Processes (Business Process Design
Knowledge Area)
• Determine Data Sources and Reporting Solutions (Performance
Measurement Knowledge Area)
California Department of Technology
Business Process Reengineering Framework
Executing | Page 12
Executing
BPR Lifecycle Management
Similar to the Planning Process Phase, the BPR Design Team plays a major role
in the Executing Process Phase. With the acquisition of the technical solution,
the team will elaborate upon the high-level Future State Process Model to flesh
out detailed process activities and tasks. In addition to the team characteristics
identified in the Planning Process Phase Chapter, the BPR Design Team requires
solution SMEs to participate in design sessions in order to adequately account
for the acquired solution’s capabilities.
The BPR Practitioner should work with the Project Manager and leverage the
project organization chart and the Stakeholder Register to identify and allocate
these resources in the BPR Schedule. Once the schedule has been developed,
the BPR Practitioner will work with the Project Manager to integrate the tasks
into the greater project schedule to monitor and control.
For More Info...
i
For more information see
the Schedule Management
Section within the
Planning Process Phase of
the CA-PMF.
2.1.4 Tools
The tool that the BPR Practitioner will use within BPR Lifecycle Management
during the Executing Process Phase includes the following:
• BPR Schedule Template
2.1.5 Outputs
BPR Lifecycle Management produces the following output during the Executing
Process Phase:
• Completed BPR Schedule
Outputs
The following is an
output to the activity:
• Completed BPR Schedule
California Department of Technology
Business Process Reengineering Framework
Executing | Page 13
Executing
Business Analysis and Future Definition
2.2 Business Analysis and
Future Definition
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Concept Initiating Planning Executing Closing
Ensure the Future State is Sound
Figure 2-3
During the Executing Process Phase, the BPR Practitioner will participate in a
number of important project team activities to support the design, development
and implementation (DD&I) of the future state, as shown in figure 2-3. These
activities include rolling out the future vision to any newly informed Stakeholders,
performing a functional gap analysis, training, and implementation support. In
order to support these activities, the BPR Practitioner will need to work closely
with the project team throughout the process phase.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-4.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 14
Executing
Business Analysis and Future Definition
Business Analysis and Future Definition
Inputs
• Completed Future State
Process Model
• Functional Requirements
Roles
• BPR Practitioner
• Project Manager
• OCM Practitioner
• Project Team
Activities
• Project Support Activities
Skills
• Judgment
• Facilitation
• Analysis
Tools
• None
Outputs
• None
Figure 2-4
2.2.1 Inputs
In order to complete the Executing Process Phase Business Analysis and Future
Definition activities, the BPR Practitioner will need a thorough understanding of
the following inputs:
Completed Future State Process Model: This model is used to inform the
rollout of the future vision, training, and implementation activities. The
Completed Future State Process Model is an output of the Business Process
Design Knowledge Area in this process phase.
Functional Requirements: Characteristics of the deliverable, described in
ordinary, non-technical language that is understandable to the customer.
Functional Requirements are produced by the project team during the Planning
Process Phase.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 15
Executing
Business Analysis and Future Definition
2.2.2 Roles
The following table lists the roles and their associated responsibilities of
those involved in Business Analysis and Future Definition activities during the
Executing Process Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR
Practitioner
• Works with the Project Manager, project team,
OCM Practitioner, or others as needed to support
project activities
• May assist with rolling out the future vision activities
• May assist with functional gap analysis activities
• May assist with training activities
• May assist with implementation activities
• Provides subject matter expertise regarding future
state processes
Project
Manager
• Works with the BPR Practitioner as needed to
coordinate project support needs
• Requests implementation support from the BPR
Practitioner as needed
OCM
Practitioner
• Provides input to project team activities regarding
communication method, communication frequency,
and training activities.
Project Team • Rolls out the future vision to Stakeholders
• Performs the functional gap analysis
• Performs training activities
• Assists with implementation planning
California Department of Technology
Business Process Reengineering Framework
Executing | Page 16
Executing
Business Analysis and Future Definition
2.2.3 Activities
The tasks required to support project activities are presented in a logical
sequence below. The BPR Practitioner should leverage his/her experience and
judgment to assist in these tasks as needed.
Skills
Use the following skills to
complete the activity:
• Judgment
• Facilitation
• Analysis
Project Support Activities
During the Executing Process Phase, the project team may require the BPR
Practitioner to support certain DD&I activities. Typically, these involve providing
business process domain expertise since the BPR Practitioner is instrumental
in designing the future state. The BPR Practitioner should be aware of these
support activities and coordinate closely with the project team. This activity
consists of the following tasks:
• Support the Roll Out of the Future Vision
• Support Functional Gap Analysis
• Support Training Activities
• Support Implementation
Support the Rollout of the Future Vision
With BPR projects, communication regarding the details of how end users and
other Stakeholders may be impacted is released strategically over time. This
communication is an exercise needed to build awareness and promote the new
environment. During the Executing Process Phase, the project team leads this
activity which oen occurs in stages as details about the new processes and
systems are developed. As such, the BPR Practitioner may be asked to provide
content and domain knowledge at various times. This may include:
• Domain Knowledge – End users and Stakeholders typically have a myriad
of questions about the new technology and its impact on their day-to-day
work, especially if they have not been engaged in project activities. The
BPR Practitioner can support the response by providing details and content
around what the process changes are going to be and how they will impact
Stakeholders.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 17
Executing
Business Analysis and Future Definition
• Content Preparation – Depending on the size and scope of the project, and
the degree of change involved in deploying the solution, there may be a
need for specialized content as part of the communication strategy. As an
example, the BPR Practitioner may need to walk through process models
for a specialized Stakeholder audience, prepare informational materials
given to Stakeholders, or assist with a Stakeholder assessment.
• Content Review – The OCM Practitioner may seek the assistance of the BPR
Practitioner in reviewing communication materials such as slide decks or
handouts. In these cases, the BPR Practitioner is again providing support
through the detailed knowledge acquired during development of the Future
State Process Model.
Support Functional Gap Analysis
Another activity the BPR Practitioner may support is the functional gap
analysis. This analysis, which is led by the project team, identifies any gaps
between the project’s functional requirements and the acquired solution. The
BPR Practitioner may be asked to participate in the analysis as a subject matter
expert, providing domain knowledge regarding the future state processes.
Additionally, when gaps are identified, participants may identify solutions that
include process workarounds. Here, the BPR Practitioner helps identify process
solutions to functional gaps and ensures that the appropriate information (i.e.
business process and/or sub-process names) is documented such that they
can be subsequently addressed. If gap documentation is found to be missing
the business process and/or sub-process names, the BPR Practitioner should
inform the project team what is required for completion. Gap resolutions that
have impact to the future state then become inputs to the design of the detailed
Future State Process Model, an activity under the Business Process Design
Knowledge Area in this process phase.
Inputs
The following is an
input to the activity:
• Functional Requirements
Support Training Activities
Once the detailed Future State Process Model (produced in the Business Process
Design Knowledge Area in this process phase) is complete, it becomes an input
to training and workforce transition activities. Although these activities are led
by the project team and the OCM Practitioner, the BPR Practitioner may be asked
to support training and develop reference material on how users will execute
the processes in the future state. As such, the BPR Practitioner should expect
to assist the OCM Practitioner in developing training content and facilitating
training sessions (as needed).
Inputs
The following is an
input to the activity:
• Completed Future State
Process Model
California Department of Technology
Business Process Reengineering Framework
Executing | Page 18
Executing
Business Analysis and Future Definition
Support Implementation
Another activity that the BPR Practitioner may support is planning the
implementation of the solution. In addition to coordinating on training needs,
the BPR Practitioner may need to provide subject matter expertise regarding
transition requirements and the integration between technical and non-
technical processes.
If suicient planning is performed, then the actual implementation or
deployment of the new processes should be straightforward. The BPR
Practitioner may be asked to help coordinate the deployment of new processes
with deployment of the technology solution. When those two elements are in
sync, users are able to see how the new processes work, and how the technology
acts to support those processes. The BPR Practitioner should work with the
project team to support the integration of process changes with the technology
deployment.
2.2.4 Tools
There are no BPR tools for the BPR Practitioners to use within the Business
Analysis and Future Definition Knowledge Area during the Executing Process
Phase.
2.2.5 Outputs
There are no BPR outputs for the Business Analysis and Future Definition Knowledge
Area during the Executing Process Phase.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 19
Executing
Business Process Design
2.3 Business Process Design
Understand
Current Processes
Identify
Business Impact
Define
Future Processes
Elaborate
Future Processes
Business
Process Design
Concept Initiating Planning Executing Closing
Ensure the Future State is Established
Figure 2-5
The focus of Business Process Design during the Executing Process Phase is to
elaborate and document the detailed Future State Process Model for business
processes that are in the scope of the project, as demonstrated in Figure 2-5.
A summary of the inputs, roles, skills, activities, tools, and outputs of this
knowledge area is presented in Figure 2-6.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 20
Executing
Business Process Design
Business Process Design
Inputs
• Business Goals and
Objectives
•
Completed BPR Schedule
• Comple
ted Curr
ent State
Process Model
• Completed Future State
Process Model (high-level)
• Completed Performance
T
arget Inventory
Roles
•
BPR Practitioner
• BPR Design Team
Activities
• Design Detailed Future St
ate
Business Processes
Skills
•
Facilitation
•
Modeling
•
Planning
•
Judgment
Tools
• Business Process
Modeling Tool
Outputs
•
Complet
ed Future State
Process Model (detailed)
Figure 2-6
2.3.1 Inputs
In order to complete the Executing Process Phase Business Process Design
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Business Goals and Objectives: A statement of the desired outcomes of the
project, this input document is used to help to inform implementation planning.
Completed BPR Schedule: The BPR Schedule identifies the resources needed
to design the Future State Process Model. The Completed BPR Schedule is an
output of the BPR Lifecycle Management Knowledge Area in this process phase.
Completed Current State Process Model: This model, which is produced
during the Planning Process Phase, may be referred to during future state
design sessions to address assumptions, constraints, or requirements.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 21
Executing
Business Process Design
Planning Process Phase Work Products: Outputs from the Planning Process
Phase include the Completed Future State Process Model and the Completed
Performance Target Inventory.
2.3.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Business Process Design activities during the Executing Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Facilitates work group sessions with the BPR
Design Team
• Documents and models the Future State
Process Model
BPR Design Team • Has domain knowledge regarding specific
needs, processes, or functional areas
• Participates in work group sessions to produce
the Future State Process Model and associated
assumptions and constraints
2.3.3 Activities
The tasks completed under the Business Process Design Knowledge Area center
on creating a detailed Future State Process Model. Although these tasks are
grouped and sequenced in the sections that follow, the BPR Practitioner needs
to apply his/her knowledge and experience to ensure the appropriate sequence
for each project.
Design Detailed Future State Process Models
A key BPR activity during the Executing Process Phase is to develop and
document the detailed future state business processes. The desired future
state consists of Level 3 and Level 4 business processes and should include
the activities and tasks, respectively. Business process levels are introduced in
Tools
A template is available:
Business Process
Modeling Tool
California Department of Technology
Business Process Reengineering Framework
Executing | Page 22
Executing
Business Process Design
the Concept Process Phase, and are further described in the Business Process
Modeling Tool.
This future state model will capture the specific activities, tasks, and decision
points needed to realize the improvements identified in the high-level Future
State Process Model developed in the Planning Process Phase. Similar to the
work conducted during the Planning Process Phase, this is typically done
through facilitated sessions, where the group starts with the understanding of
the Future State Process Model, and further details them by describing specific
activities, tasks and decision points, indicating what roles should perform them.
In a similar fashion to the high-level Future State Process Model, the results are
documented graphically in a process model that provides a visual view of the
desired future state business processes.
Documenting the future state in a graphical format allows the BPR Practitioner
to eectively communicate the future state to the end users who will be most
directly impacted by the new process. A well-documented Future State Process
Model provides the basis for planning the implementation and training of end
users and Stakeholders, and provides a platform for performance measurement
and continuous process improvement activities that will be completed in the
Closing Process Phase.
This activity should have a clear timeframe for completion, so that detailed design
is complete and documented prior to the beginning of technical development.
Without an end date, there is risk that detailed design will continue well into
development, which can be the cause of costly design changes late in the project.
Consequently, it is important for the BPR Practitioner to keep in mind that it is
generally not practical to decompose every sub-process. Sub-processes that are
composed of a single activity, or that function as entry or exit points (e.g. receipt of a
document or generation of a report), typically do not need to be further elaborated.
However, if there are several processes to be designed, the BPR Practitioner should
consider working on simpler, more discrete processes first. This will allow the team
to internalize the steps involved, and will produce “quick wins” that can help build
momentum and confidence for more complex processes.
This activity consists of the following tasks:
• Prepare for Design Sessions
• Facilitate and Document Design Sessions
• Validate Detailed Future State Process Models
California Department of Technology
Business Process Reengineering Framework
Executing | Page 23
Executing
Business Process Design
Prepare for Design Sessions
As with the design sessions conducted in the Planning Process Phase, the BPR
Practitioner will serve as the facilitator during Executing Process Phase design
sessions, guiding the participants in the creation of the detailed Future State
Process Model. Again, the BPR Practitioner will need to document the designs
using business process models and forms to capture key design assumptions or
constraints.
Skills
Use the following skills to
complete the activity:
• Facilitation
It is the BPR Practitioner’s role to identify the appropriate SME’s to participate
as the BPR Design Team. The same participants should be leveraged from
the Planning Process Phase, with the addition of SMEs that are familiar with
the technology solution. To ensure that the participants have a common
understanding of the business process design eort, they should review and be
familiar with the following inputs:
• Business Goals and Objectives. The BPR Practitioner should refer to these
goals and objectives to continually verify that the Future State Process
Model achieves these goals and objectives.
• Current State Business Process Models. When developing the Future State
Process Model, it is sometimes beneficial to refer back to the Current State
Process Model, either to address requirements, constraints or assumptions.
• Future State Process Model (high-level). A key input, the high level Future
State Process Model provides the foundational design of the business
processes and context for the detailed design work.
Inputs
The following are
inputs to the activity:
• Business Goals and
Objectives
• Completed Current
State Process Model
• Completed Future
State Process Model
(high-level)
With these inputs, the BPR Practitioner works to first determine which processes
or sub-processes within the high-level Future State Process Model should be
further broken down to create the detailed Future State Process Model. In
other words, the goal is to create detailed models of process activities and
tasks identified in the high-level Future State Process Model that need further
decomposition and elaboration.
It is important to plan and structure the sessions in advance to secure the
necessary participation. The number and length of sessions required depends
on the number and complexity of the process steps being further defined. A
business process that has many activities and tasks has more reengineering
considerations than a simpler process. The BPR Practitioner will need to take
these into account and leverage past experience and good judgment when
identifying the number of sessions.
Skills
Use the following skills to
complete the activity:
• Judgment
• Planning
California Department of Technology
Business Process Reengineering Framework
Executing | Page 24
Executing
Business Process Design
Facilitate and Document Design Sessions
As the facilitator of the design sessions, the BPR Practitioner is responsible for
guiding the participants into producing a detailed Future State Process Model
that includes the activities, tasks, and decisions needed to accomplish the goals
of the future state. Additionally the BPR Practitioner is responsible for facilitating
the identification of key assumptions and constraints associated with the newly
designed activities and tasks.
It is also important to remember that new or redesigned activities and tasks
should reflect improvements in eiciency and productivity while leveraging
the new technology, rather than simply doing things the same way as before.
To assist with this, the BPR Practitioner can use his or her role as facilitator to
focus on specific techniques and questions. These are described in detail in
the “Facilitate Design Sessions” task of the Planning Process Phase, Business
Process Design Knowledge Area.
Similar to the sessions conducted during the Planning Process Phase, the
Executing Process Phase sessions begin with an introduction of the purpose of
the session, the anticipated outcomes, and the roles of the BPR Design Team.
Establishing this upfront is important to establishing the expectations for the
team. It is helpful to keep these items visible, such as on a white board, so the
BPR Practitioner can refer to them in case discussions go o-track.
Aer introductions, the BPR Practitioner performs a guided-walkthrough of the
high-level Future State Process Model to orient the team. The BPR Practitioner
then begins by prompting the team to consider which process steps are
composed of multiple activities, involve significant movement of information,
or are otherwise complex or make heavy use of technology.
Moving from the high-level processes to more detailed activities and tasks is
essentially a move to a lower level of detail. To model this, the BPR Practitioner
should work with the BPR Design Team to determine the actions, decisions,
and information flow needed to perform the process step and accomplish the
business objectives of the improvement. To illustrate this, consider an example:
Inputs
The following are
inputs to the activity:
• Completed Performance
Target Inventory
• Business Goals
and Objectives
California Department of Technology
Business Process Reengineering Framework
Executing | Page 25
Executing
Business Process Design
Improvement: Centralize invoice processing in Accounts Payable
Process step: Process Vendor Invoice
Detailed Tasks/Activities:
1. Receive invoice in Accounts Payable (Accounts Payable)
2. Enter invoice into financial system (Accounts Payable)
3. Match invoice to purchase order (Accounts Payable)
4. Enter account code for the item or service (Accounts Payable)
5. Is this a capital projects invoice or an operating invoice?
a. If capital, forward to Engineering for approval (Accounts Payable)
i. Receive invoice (Engineering)
ii. Verify that invoice is correct and charged to appropriate project
(Engineering)
iii. Sign and date the invoice to indicate approval
(Engineering)
iv. Return approved invoice to Accounts Payable
(Engineering)
b. If operating, forward to originating department for approval
(Accounts Payable)
i. Receive invoice (Originating Department)
ii. Verify that invoice is correct and charged to appropriate account
(Originating Department)
iii. Sign and date the invoice to indicate approval
(Originating Department)
iv. Return approved invoice to Accounts Payable
(Originating Department)
6. Receive approval and forward to Treasury for payment
(Accounts Payable)
California Department of Technology
Business Process Reengineering Framework
Executing | Page 26
Executing
Business Process Design
Process Vendor Invoice
Originang
Department
Accounts PayableEngineering
Enter invoice to
nancial system
Receive invoice in
Accounts Payable
Capital or
Operang?
Operang
Capital
Match invoice to
purchase order
Enter account code
for the item or
service
Receive invoice
Verify that invoice is
correct and charged
to appropriate
account
Sign and date the
invoice to indicate
approval
Receive approval
and forward to
Treasury for
payment
Receive invoice
Verify that invoice is
correct and charged
to appropriate
project
Sign and date the
invoice to indicate
approval
Figure 2-7
Skills
Use the following skill to
complete the activity:
• Modeling
In this example, Figure 2-7, the process of “Process Vendor Invoice” has been
elaborated further to define the specific tasks needed to accomplish the
business objective of centralized payment processing. This detailed description
of activities and tasks should be repeated for each process that has been
identified as needing decomposition.
While facilitating the design session, the BPR Practitioner can document the
discussion and results in a swimlane diagram to provide a visual representation to
the team. Figure 2-7 depicts a swimlane diagram of the “Process Vendor Invoice.”
The BPR Practitioner should seek assistance for facilitating and documenting the
detailed design sessions, if necessary. Guidance regarding the documentation
of the models along with templates are provided in the Business Process
Modeling Tool.
Upon completion of the detailed Future State Process Model, the BPR
Practitioner and BPR Design Team should also identify any assumptions and
constraints associated with the detailed design.
Tools
A template is available:
Business Process
Modeling Tool
California Department of Technology
Business Process Reengineering Framework
Executing | Page 27
Executing
Business Process Design
Assumptions are beliefs assumed to be true, but not yet proven. Examples of
assumptions include:
• The technological ability to run parallel processes.
• The ability to modify job responsibilities without impacting civil service
union classifications.
• The ability to modify a mandate or regulation prior to implementation.
• The availability of resources to maintain the new solution.
Constraints are things that might restrict or limit capabilities. Generally, there
are two categories of constraints:
• Business Constraints – constraints related to limitations on available
solutions or processes that cannot be changed. Examples include having a
fixed budget, inability to redesign inputs, limitation on type of responsibilities
that can be shared between employee types, limitations based on privacy
laws, inability to outsource job functionality, and processes that must occur
prior to others.
• Technological Constraints – constraints related to the technological
capabilities of a solution. Examples include compatibility with existing
technology platforms, use of specific development language, use of
existing hardware, required methods of access, availability and uptime
requirements, and cybersecurity concerns.
Design assumptions and constraints are documented in a narrative that
accompanies the detailed Future State Process Model. Once the detailed design
is completed, it will be leveraged by the project team to configure and build the
technology solution.
Validate Detailed Future State Process Models
Once the technology solution is suiciently developed, the BPR Practitioner
validates the detailed future state processes with Stakeholders (including the
Project Sponsor and Project Manager). While the primary purpose of this activity
is to verify that the design will produce the desired outcomes, this validation
step also helps to inform the Stakeholders and is helpful for communicating
organizational change.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 28
Executing
Business Process Design
To validate the alignment of the business processes to the technology solution,
the project team will conduct testing activities such as Functional Testing
and User Acceptance Testing. This will test whether the technology has been
configured or developed to support the detailed Future State Process Model.
In addition, the BPR Practitioner should lead a formal walkthrough of the new
process with Stakeholders to validate the end-to-end process, sometimes
known as a Desk Review. This involves a facilitated discussion of each pathway
through the process to identify any missing steps, artifacts (such as a form or a
report), or actors within the process, and comparing the results to the desired
outcomes. Oen, simply talking through the process from beginning to end can
highlight anything that might have been missed during process design.
Should any issues arise during validation of the detailed processes, the BPR
Practitioner may need to bring the BPR Design Team together to resolve those
problems. The most common issues that arise include:
• Slight mismatches between end user documentation and the new process.
• Minor technology modifications or enhancements that were not
properly communicated to the BPR team, and therefore were not
properly documented.
• Aggregated steps that need to be broken out into more detail (i.e. user feedback
from training or deployment suggests the need for additional steps).
Once validated, end users are trained on the business processes before being
deployed as part of the technology solution.
2.3.4 Tools
The tool that the BPR Practitioner will use within Business Process Design
during the Executing Process Phase includes the following:
• Business Process Modeling Tool
2.3.5 Outputs
Business Process Design produces the following output during the Executing
Process Phase:
• Future State Process Model
Outputs
The following is an
output to the activity:
• Completed Future State
Process Model (detailed)
California Department of Technology
Business Process Reengineering Framework
Executing | Page 29
Executing
Performance Measurement
2.4 Performance Measurement
Identify
Performance Baseline
Define
Performance Reports
Generate
Performance Reports
Performance
Measurement
Concept Initiating Planning Executing Closing
Ensure Improvements are Measurable
Determine
Future Measures
and Performance
Figure 2-8
The goal of Performance Measurement is to implement the mechanisms to
allow for measuring performance, as indicated in Figure 2-8. In order to do
this, the BPR Practitioner identifies data sources and reporting needs related
to the established performance targets, and supports the project team in the
documentation of the reporting solutions.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
Performance Measurement Knowledge Area is presented in Figure 2-9.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 30
Executing
Performance Measurement
Performance Measurement
Inputs
• Completed Future State
Process Model
•
Completed Performance
T
arget Inventory
Roles
•
BPR Practitioner
• Project Sponsor
•
BPR Design Team
• Stakeholder
s
Activities
•
Determine Data Sources and
Reporting Solutions
Skills
• F
acilitation
• Analysis
Tools
• Performance Targ
et
Inventory Template
• Performance Metric
Assessment Template
Outputs
•
Updated Performance
Target Inventory
Figure 2-9
2.4.1 Inputs
In order to complete the Executing Process Phase Performance Measurement
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Completed Future State Process Model (detailed): The graphical depiction of
the improved processes should be referenced to verify alignment of performance
targets, and to assist with analysis of any indicators that are outside of targeted
performance. The detailed Future State Process Model is an output of the Business
Process Design Knowledge Area in this process phase.
Completed Performance Target Inventory: A listing of metrics that were
identified in the Planning Process Phase, these data points should be key
indicators of process performance, and should also be readily available, timely,
and accurate.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 31
Executing
Performance Measurement
2.4.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Performance Measurement activities during the Executing Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Works with the BPR Design Team to identify data
sources for reporting performance against targets
• Works with the project team and Stakeholders to
identify reporting requirements and solutions
• Documents data sources and reporting solutions
Project Team • Participates in work sessions to determine
reporting requirements and solutions
• Configures, tests, and implements
reporting solutions
BPR Design Team • Participates in work sessions to determine
data sources
Stakeholders
(including SMEs)
• Participates in work sessions to determine
data sources and reporting requirements
2.4.3 Activities
The tasks required to determine data sources and reporting solutions are
presented in a logical sequence below. The BPR Practitioner should leverage
his/her experience and judgment to adjust tasks and sequence as needed.
Skills
Use the following skills to
complete the activity:
• Facilitation
• Analysis
Determine Data Sources and Reporting Solutions
During the Executing Process Phase, the BPR Practitioner works with the BPR
Design Team to identify and assess data sources for measuring the performance
targets (metrics) that were documented in the Performance Target Inventory
during the Planning Process Phase. Then, working with the project team and
Inputs
The following are
inputs to the activity:
• Completed Future State
Process Model (detailed)
• Completed Performance
Target Inventory
California Department of Technology
Business Process Reengineering Framework
Executing | Page 32
Executing
Performance Measurement
Stakeholders, the BPR Practitioner can recommend specific reporting methods.
The Performance Target Inventory is then updated with the data source and
reporting method for each metric. This activity consists of the following tasks:
• Determine Data Sources
• Prepare for Reporting Definition
• Select Reporting Method
Determine Data Sources
Each target or metric that was identified as a key performance indicator for
a given process should have at least one source of data for that performance
information. The BPR Practitioner should consider the following in looking for
specific data sources:
• Business information systems and soware (including error, exception,
and activity data)
• Customer satisfaction surveys, both manual and electronic
• Web site or portal information such as number of unique visitors, average
length of time spent on each page of the site, etc.
• Data warehouse or other business intelligence systems
• Manual reports
To identify these data sources, the BPR Practitioner will work with the BPR
Design Team, which includes SMEs with knowledge of the technical solution.
For eiciency, this can occur during the detailed future state design sessions
described within the Business Process Design Knowledge Area.
The BPR Design Team may find that no data source is available for a given metric
in some cases. In these situations, the project team should be consulted to
determine if it is feasible to create the data source (for example, it may simply be a
matter of enabling a function within an existing soware package). If not, then the
team should reassess the metric to determine another measure that can be used.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 33
Executing
Performance Measurement
In other cases, the data source may be unreliable, or may require excessive amounts
of labor to generate. Again, the BPR Design Team should be consulted to see if it
is feasible to solidify the generation of that metric. If not, then the team should
reassess the metric to determine another measure that can be used.
Once all the required data sources have been identified, they should be captured
in the Performance Target Inventory.
Tools
A template is available:
Performance Target
Inventory
Prepare for Reporting Definition
At this point in the Performance Measurement Knowledge Area, a performance
metric has been determined, and an appropriate data source has been identified.
Now, the BPR Design Team assesses the characteristics of both the metric itself
as well as the data source. Specifically, the following should be understood:
• The frequency of data reporting – Is the data reported continuously, daily,
monthly, or some other time period? For example, financial data is oen
reported monthly, but some operational data may be reported daily or bi-
weekly.
• Data format – Is the data a number, a graph, a narrative description, or in
some other format?
• Nature of the data source – Is the data available in an electronic format from
an accessible system, on a hard copy report, on an individual spreadsheet,
or some other source?
• Data manipulation – Is the metric a key performance indicator by itself,
or does it need to be combined with other data to be valuable? Are other
manipulations needed to make the data meaningful?
With these variables assessed, the BPR Practitioner can work with Stakeholders
and the project team to identify best available reporting methods.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 34
Executing
Performance Measurement
Select Reporting Method
Once the characteristics of each metric are identified, the BPR Practitioner
should work with the project team to review available reporting platforms and
determine the best method to report the data. The BPR Practitioner should
consider the following reporting methods based on the eort required to
develop it and availability:
• Online Dashboards. Many executives like to view performance in a graph or
other visual medium, oen using red-yellow-green “stoplight” indicators to
quickly highlight current performance. This format is excellent for data that
is updated frequently (typically daily or even continuously), and is numerical
in nature and easily compared to targets. Dashboard data is also generally
output from one or more soware systems rather than manually entered.
• Periodic Reports or Online Queries. For data that is updated monthly or
less oen, or requires manipulation prior to displaying it to a Stakeholder, a
report or inquiry screen is oen the most appropriate choice. This enables the
Stakeholder to run the report or query as needed, and allows for combining
data elements, performing mathematical operations, dealing with exception
conditions, or other situations where programming is needed. In cases where
source data can vary in format or is not easily compared to targets, reports may
be the most appropriate mechanism to deliver performance results.
• Database or Data Warehouse. In some cases, Stakeholders may want raw
data that they can manipulate and format themselves, rather than having
it in a final format. Making data available in a standard database or data
warehouse format can oen work well for these types of Stakeholders,
assuming that data analysis tools are available to them as well.
Understanding the characteristics of performance metrics is important, but
the BPR Practitioner should also take care to work with Stakeholders to ensure
their reporting needs and preferences are addressed. Using Stakeholders’
preferred delivery mechanisms can help increase utilization of the metric and
performance target, and thereby help move the organization closer to a state
of continuous improvement. Though dierent reporting requirements may
necessitate data be presented in a prescribed format, the BPR Practitioner
should aim to report metrics as simply and consistently as possible to all
Stakeholders to ensure they are receiving the same message or end at the same
conclusion when viewed.
California Department of Technology
Business Process Reengineering Framework
Executing | Page 35
Executing
Performance Measurement
Once the BPR Practitioner addresses both available reporting platforms and the
preferences of Stakeholders, the BPR Practitioner documents these selected
reporting solutions in the Performance Target Inventory. These reports are later
generated during the Closing Process Phase.
2.4.4 Tools
The tools that the BPR Practitioner will use within Performance Measurement
during the Executing Process Phase includes the following:
• Performance Target Inventory Template
2.4.5 Outputs
Performance Measurement produces the following output during the Executing
Process Phase:
• Update Performance Target Inventory
Outputs
The following is an
output to the activity:
• Updated Performance
Target Inventory
California Department of Technology
Business Process Reengineering Framework
Executing | Page 36
Executing
Process Phase Checklist
va
l Lifecycl
e
Project Appro
Project Appro
Project Appro
3.1 Complete the Checklist
Once all of the BPR activities within the Executing Process Phase are done, the
process phase checklist should be completed. The checklist provides a list of
“why, how, what, who, where, and when” questions to verify that all items in the
process phase are complete.
Tools
A template is available:
BPR Executing Process
Phase Checklist
The process phase checklist helps to identify and document repeatable steps,
from project to project, to ensure that the correct activities are completed at
the right time, every time.
Process phase checklists assist BPR Practitioners in quickly and confidently
identifying areas of concern within this process phase. In this case, completion
of the checklist provides a clear milestone that the Executing Process Phase is
complete, including:
• Completed BPR Schedule
• Completed Future State Process Model (detailed)
• Updated Performance Target Inventory
• Completed BPR Executing Process Phase Checklist
Outputs
Complete the BPR
Executing Process Phase
Checklist to validate that
all process phase activities
are complete.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 1
Closing
Business Process Reengineering (BPR) activities
within the Closing Process Phase focus on
transitioning the project from deployment
to support. It also establishes the ongoing,
incremental improvement of business processes
through analysis of performance measures.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 2
In this chapter...
Closing
1
Approach
Page 3
1.1 Introduction
1.2 Recommended
Practices
2
Knowledge
Areas
Page 7
2.1 BPR Lifecycle
Management
2.2 Business
Analysis
and Future
Definition
2.3 Performance
Measurement
3
Process Phase
Checklist
Page 20
3.1 Complete the
Checklist
California Department of Technology
Business Process Reengineering Framework
Closing | Page 3
Closing
Approach
Business Process Design Performance MetricsBusiness Analysis and
Future Definition
BPR
Lifecycle Management
Figure 1-1
As shown in Figure 1-1, three knowledge areas are active in the Closing Process
Phase of the Project Management Lifecycle (PMLC). The Project Team will focus on
closing the BPR Project and developing an improvement plan that the organization
can use for continuous improvement.
1.1 Introduction
During the Closing Process Phase, the BPR Practitioner works with the Project
Manager to formally closeout the BPR eort by archiving artifacts and conducting
lessons learned. The BPR Practitioner will also create a post-implementation
continuous improvement plan that will be transferred to and maintained by
the organization. A key input to this improvement plan, the BPR Performance
Report, is initially created by the BPR Practitioner and will be updated over time
by the organization aer the project is closed.
BPR Lifecycle Management
The BPR Practitioner works closely with the Project Manager during the Closing
Process Phase to ensure that final BPR documentation is properly stored and
lessons learned are conducted for BPR-related activities. Additionally, the BPR
Practitioner may be asked to assist with a Post-Implementation Evaluation
Report (PIER) in the case that one is needed.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 4
Closing
Business Analysis and Future Definition
During the Business Analysis and Future Definition Knowledge Area, the BPR
Practitioner establishes a continuous improvement plan that the organization
will operate and maintain aer project closure.
Performance Measurement
The BPR Practitioner will collect initial performance data and create a report
to demonstrate progress toward performance targets. The report, which
will be maintained by the organization, becomes the basis of future process
improvements.
Once all BPR-related Closing Process Phase activities have been completed, the
BPR Practitioner will complete the BPR Closing Process Phase Checklist. Figure
1-2 lists all of inputs, activities, and outputs for each knowledge area during the
Closing Process Phase.
Sequence of Activities
Although the knowledge areas are presented in a specific order for consistency
throughout the CA-BPR, the order in which the activities occur is independent
of each other. Activities may occur simultaneously and iteratively rather than
sequentially. Where an output from one knowledge area is an input to another, it is
not required that they have to be in final form; however, they should be reasonably
draed to contain a majority of the information the input/output is expected to
contain. The experience and knowledge of past projects and individual judgment
should be used to determine the most appropriate sequencing of activities for
each unique project.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 5
Closing
Business Analysis
and
Future Definition
BPR Lifecycle
Management
Performance
Measurement
Inputs Activities Outputs
• Create the BPR Improvement Plan
• Completed BPR Improvement Plan
• Organizational Process Assets
• Create and Populate the
BPR Performance Report
• Current Performance Metric Values
• Completed Performance
Target Inventory
• Initial BPR Performance Report
• Close Out the BPR Project• Documentation from Previous
Process Phases
• Archived BPR Artifacts
• Completed Lessons Learned
ConceptConc Initiating Planning Executing ClosingExecutingPlanningInitiating
Closing Process Phase Goal: Transition to Support and Process Improvement
ept
Figure 1-2
California Department of Technology
Business Process Reengineering Framework
Closing | Page 6
Closing
1.2 Recommended Practices
The following recommended practices will help the BPR Practitioner properly
close the project, transition from deployment to support, and begin a cycle
of incremental improvement. The recommended practices apply to all BPR
knowledge areas.
Recommended
Practices
Review recommended
practices at the start of
the process phase.
Leverage BPR Resources Aer Go-Live
By the time new processes are deployed, BPR resources will have worked
through a detailed analysis of legacy processes, collaborated on improvement
alternatives, and designed and implemented new business processes in
tandem with a project team. Having gone through those activities, resources
that participated in BPR activities are in a unique position with subject matter
expertise and insights for continuous improvement and process refinement.
Consider Trends over Snapshots
Oen the desired productivity and eiciency gains will materialize over time
aer implementation of a new business process. End users and Stakeholders will
need time to internalize the new process steps and to develop mastery with new
technology. The BPR Practitioner should evaluate how performance metrics are
changing over time, looking at trends versus evaluating a performance snapshot
shortly aer deployment. This trend analysis will give the BPR Practitioner a
better view of the impact of the redesigned processes.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 7
Closing
Knowledge Areas
BPR Lifecycle Management
2.1 BPR Lifecycle Management
Schedule
Initiating Activities
Determine
the Approach
Schedule
Planning Activities
Schedule
Executing Activities
Close
BPR Eort
BPR Lifecycle
Management
Concept Initiating Planning Executing Closing
Ensure the Performance of the BPR Eort
Figure 2-1
The goal of BPR Lifecycle Management in the Closing Process Phase is to close
out the project in an orderly and timely fashion, as shown in Figure 2-1. The BPR
Practitioner will work closely with the Project Manager to archive BPR artifacts,
conduct lessons learned, and support the Post-Implementation Evaluation
Report (PIER) as needed.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-2.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 8
Closing
BPR Lifecycle Management
BPR Lifecycle Management
Inputs
• Documentation from
Previous Process Phases
Roles
• BPR Practitioner
• Project Sponsor
•
Project Manager
Activities
•
Close Out the BPR Project
Skills
•
Project Management
• Facilitation
Tools
•
Lessons Learned Template
Outputs
• Archived BPR Artifacts
•
Complet
ed Lessons Learned
Figure 2-2
2.1.1 Inputs
In order to complete the Closing Process Phase BPR Lifecycle Management
activities, the BPR Practitioner will need a thorough understanding of the
following input:
Documentation from Previous Process Phases: Documentation from previous
process phases should be archived or stored during the closeout process. The
BPR Practitioner should work with the Project Manager during this time as items
including, but not limited to, the Future State Process Model, the Performance
Target Inventory, and other important documents should be archived.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 9
Closing
BPR Lifecycle Management
2.1.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in BPR Lifecycle Management activities during the Closing Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Works with the Project Manager to close out the
BPR project
• Archives BPR project artifacts
• Conducts lessons learned sessions and
documents results
• Assists with the Post-Implementation Evaluation
Report (PIER) as needed
Project Sponsor • Provides final sign-o on the project
Project Manager • Leads the overall closeout process
• Coordinates closeout activities across all teams
2.1.3 Activities
The tasks completed under the BPR Lifecycle Management Knowledge Area
center on project closeout. Although these tasks are presented in a logical
sequence, the BPR Practitioner should apply his/her knowledge and experience
to determine the necessary activities and the order of activities for each project.
Skills
Use the following skills to
complete the activity:
• Project Management
• Facilitation
Close Out the BPR Project
In order to close out the BPR eort, the BPR Practitioner should work with the
project team to identify these tasks and perform them as required. This activity
consist of the following tasks:
• Archive BPR Artifacts
• Conduct Lessons Learned
Inputs
The following is an
input to the activity:
• Documentation from
Previous Process Phases
California Department of Technology
Business Process Reengineering Framework
Closing | Page 10
Closing
BPR Lifecycle Management
• Support Completion of the Post-Implementation Evaluation Report
Archive BPR Artifacts
Artifacts from this BPR project are a crucial source of information for improving
future BPR eorts. All records, both electronic and hard copy, should be stored
according to applicable project document management rules and guidelines.
Guidance for ongoing BPR activities (e.g., BPR Improvement Plan, Performance
Target Inventory) are turned over to personnel responsible for maintenance
and operation of the product, service, or other project results aer deployment.
The project archive should contain a document that includes a description of
all files being stored, the storage location, and a point of contact for further
information. Typically, at a minimum, archived BPR artifacts include:
• Current State Assessment
• Business Process Scope Model
• Current State Process Model
• Future State Process Model
• Performance Target Inventory
• BPR Improvement Plan
• Lessons Learned
Outputs
The following is an
output to the activity:
• Archived BPR Artifacts
Conduct Lessons Learned
During the Closing Process Phase, the BPR Practitioner should conduct lessons
learned session(s) with project team members who participated in BPR activities.
The objective of conducting lessons learned is to identify both the positive and
negative lessons learned from the BPR eort, as well as recommended corrective
actions for the negatively based observations that should be considered for
future projects.
To conduct lessons learned, the BPR Practitioner should facilitate brainstorming
sessions to identify and analyze each major negative and positive event that
impacted the BPR workstream. As items are identified and discussed, the BPR
Tools
A template is available:
Lessons Learned
California Department of Technology
Business Process Reengineering Framework
Closing | Page 11
Closing
BPR Lifecycle Management
Practitioner documents them in the lessons learned template included in the
CA-PMF. The template helps the project team document each lesson learned,
identify the PMLC stage in which the event occurred, the initiator of the lesson
learned and his or her role, and the recommendation to avoid the problem or take
advantage of the opportunity. The BPR Practitioner also documents a description
of the lesson learned and any recommendation for future BPR projects.
The completed lessons learned documentation represents knowledge and
experience gained during the project and should be archived and made
available for future consideration. For more information on conducting lessons
learned, see the Closing Chapter of the CA-PMF.
Outputs
The following is an
output to the activity:
• Completed
Lessons Learned
Support Completion of the Post-Implementation
Evaluation Report
The California Department of Technology (CDT) requires projects to complete
and submit a Post Implementation Evaluation Report (PIER) following project
completion. The BPR Practitioner may be asked to support or complete
portions of the PIER that pertain to the BPR eort. For more information on
the PIER, see Section 50 of the Statewide Information Management Manual
(SIMM) which contains “Instructions for Completing the Post Implementation
Evaluation Report (PIER).” These instructions describe when a PIER is required,
its contents, and procedures for submission and approval.
Web Link
For more information
on the PIER see the
Statewide Information
Management Manual
(SIMM) - Section 50.
i
2.1.4 Tools
The tool that the BPR Practitioner will use within BPR Lifecycle Management
during the Closing Process Phase includes the following:
• Lessons Learned Template
2.1.5 Outputs
BPR Lifecycle Management produces the following outputs during the Closing
Process Phase:
• Archived BPR Artifacts
• Completed Lessons Learned
California Department of Technology
Business Process Reengineering Framework
Closing | Page 12
Closing
Business Analysis and Future Definition
2.2 Business Analysis and
Future Definition
Build
Case for Change
Define
Business Rationale
Support
Solution Definition
Support
Continuous
Improvement
Support Design,
Development, and
Implementation (DD&I)
Business Analysis and
Future Definition
Concept Initiating Planning Executing Closing
Ensure the Future State is Sound
Figure 2-3
As show in Figure 2-3, the focus of Business Analysis and Future Definition during
the Closing Process Phase is to develop a post-implementation continuous
improvement plan that the organization will use for future process optimization.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
knowledge area is presented in Figure 2-4.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 13
Closing
Business Analysis and Future Definition
Business Analysis and Future Definition
Inputs
• Organizational
Process Assets
Roles
• BPR Practitioner
• Project Sponsor
Activities
•
Create the BPR
Improvement Plan
Skills
•
Planning
Tools
•
BPR Improvement
Plan Template
Outputs
• Complet
ed BPR
Improvement Plan
Figure 2-4
2.2.1 Inputs
In order to complete the Closing Process Phase Business Analysis and Future
Definition activities, the BPR Practitioner will need a thorough understanding
of the following input:
Organizational Process Assets: Existing policies, procedures, and plans
regarding performance improvement and continuous improvement (if available)
will help the BPR Practitioner create the BPR Improvement Plan tailored to fit
the organization’s needs.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 14
Closing
Business Analysis and Future Definition
2.2.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Business Analysis and Future Definition activities during the Closing
Process Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Creates the Process Improvement Plan
Project Sponsor • Helps identify post-implementation roles
and responsibilities
2.2.3 Activities
The task required to create the BPR Improvement Plan is presented below. The
BPR Practitioner should leverage his/her experience and judgment to modify
this task as needed.
Skills
Use the following skill to
complete the activity:
• Planning
Create the BPR Improvement Plan
Organizations that implement a BPR project should define a method of continuous
improvement they will follow aer the project closes to continually improve upon
and gain eiciencies in the ongoing operations of a business process. A major
BPR activity during the Closing Process Phase is the development of a plan that
identifies how future process improvements will be handled, including roles
and responsibilities, process improvement triggers, and process improvement
documentation. Aer the BPR Practitioner creates the plan and the project is closed,
the responsibility of operating and maintaining it is transferred to the ongoing
maintenance organization.
A well-established improvement plan will help organizations ensure future
improvement opportunities are considered and implemented in a timely and
organized fashion. The CA-BPR provides a BPR Improvement Plan template
containing detailed instructions and examples. The BPR Practitioner will complete
the plan, including the following key sections:
• Roles and Responsibilities – Roles and responsibilities should be defined
Inputs
The following is an
input to the activity:
• Organizational
Process Assets
Tools
A template is available:
BPR Improvement Plan
California Department of Technology
Business Process Reengineering Framework
Closing | Page 15
Closing
Business Analysis and Future Definition
to establish who is responsible for resourcing, monitoring, and executing
the BPR Improvement Plan and subsequent improvement opportunities.
The Project Sponsor and Project Manager can be consulted to determine
appropriate resources for this.
• Process Improvement Triggers –Future process improvements can be
triggered by ad-hoc events such as an employee identifying a process
problem or opportunity and complaints from customers. They can also
be triggered by the continuous evaluation of performance indicators by
comparing current performance values against performance targets, an
activity described under the Performance Measurement Knowledge Area in
this process phase. Fields such as business process, process improvement
trigger, and trigger description should to be created for capturing required
data.
• Documenting the Process Improvement – Required data for subsequent
process issues or opportunities needs to be defined, including root-causes,
owner assignment, and improvement plans.
When creating the plan, the BPR Practitioner should evaluate existing organizational
process assets to determine whether the organization already uses a continuous
improvement plan or method. In such cases, the BPR Practitioner should determine
if the plan or method addresses all of the elements listed in BPR Improvement Plan;
if not, the plan or method should be amended to include missing elements. Once
the BPR Improvement Plan is created, the BPR Practitioner should transfer it to the
appropriate resources of the organization that will provide ongoing support.
2.2.4 Tools
The tool that the BPR Practitioner will use within Business Analysis and Future
Definition during the Closing Process Phase includes the following:
• BPR Improvement Plan Template
2.2.5 Outputs
Business Analysis and Future Definition produces the following output during the
Closing Process Phase:
• Completed BPR Improvement Plan
Outputs
The following is an
output to the activity:
• Completed BPR
Improvement Plan
California Department of Technology
Business Process Reengineering Framework
Closing | Page 16
Closing
Performance Measurement
2.3 Performance Measurement
Identify
Performance Baseline
Define
Performance Reports
Generate
Performance Reports
Performance
Measurement
Concept Initiating Planning Executing Closing
Ensure Improvements are Measurable
Determine
Future Measures
and Performance
Figure 2-5
The goal of Performance Measurement, as shown in Figure 2-5, is to establish a
performance report that the organization can use for demonstrating progress
toward goals and as the basis for future improvements. The BPR Practitioner
performs this activity by creating a BPR Performance Report and populating it
with an initial set of performance values.
A summary of the inputs, roles, skills, activities, tools, and outputs of the
Performance Measurement Knowledge Area is presented in Figure 2-6.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 17
Closing
Performance Measurement
Performance Measurement
Inputs
• Current Performance
Metric Values
• Completed Performance
Target Inventory
Roles
• BPR Practitioner
• Project Team
Activities
• Create and Populate the
BPR Performance Report
Skills
• Analysis
• Communication
Tools
• BPR Performance
Report Template
Outputs
• Initial BPR
Performance Report
Figure 2-6
2.3.1 Inputs
In order to complete the Closing Process Phase Performance Measurement
activities, the BPR Practitioner will need a thorough understanding of the
following inputs:
Performance Target Inventory: A listing of performance targets and reporting
solutions for each business process. This was created during the Planning
Process Phase and updated during the Executing Process Phase.
Current Performance Metric Values: These values are generated via
the reporting solutions described in the Performance Target Inventory. The
BPR Practitioner documents the initial post-implementation values in the
BPR Performance Report.
California Department of Technology
Business Process Reengineering Framework
Closing | Page 18
Closing
Performance Measurement
2.3.2 Roles
The following table lists the roles and their associated responsibilities of those
involved in Performance Measurement activities during the Closing Process
Phase.
Roles
For a complete list of
all CA-BPR roles, see the
BPR Role Definitions
in the Glossary.
Role Responsibilities
BPR Practitioner • Creates the BPR Performance Report
• Collects current performance metric values
Project Team • Provides current performance metric values
2.3.3 Activities
The task required to create the BPR Performance Report is presented below.
The BPR Practitioner should leverage his/her experience and judgment to make
any adjustments as needed.
Inputs
The following is an
input to the activity:
• Current Performance
Metric Values
Skills
Use the following skills to
complete the activity:
• Analysis
• Communication
Create and Populate the BPR Performance Report
A key BPR activity during the Closing Process Phase is the creation of a
performance report and associated data collection. This report is used to
record and demonstrate the performance of the newly implemented processes.
Additionally, it will be used by the organization to surface future improvement
needs by identifying under-performing processes.
The report consists of a comparison of target values with current values for
each performance metric listed in the Performance Target Inventory. The BPR
Practitioner should create a report with the following elements:
• The business process to which the metric relates
• The performance metric description
• The baseline metric value
• The target metric value
• The current metric value
Inputs
The following is an
input to the activity:
• Completed Performance
Target Inventory
California Department of Technology
Business Process Reengineering Framework
Closing | Page 19
Closing
Performance Measurement
Additionally, the report should be designed to allow for continuous capture of
performance values over time. The BPR Performance Report may be developed
using the provided template.
The BPR Practitioner works with the project team to collect and document
current performance metric values. The sources and reporting mechanisms are
described in the Performance Target Inventory.
It should be noted that data collected immediately aer go-live may not show
meaningful improvements. This is because time is needed for new processes to
gain traction, users to perform new responsibilities eiciently, and customers
to become accustomed to new processes. Thus, the BPR Practitioner should
avoid taking action based on data gathered immediately aer implementation.
Once the initial BPR Performance Report is generated, the BPR Practitioner
transfers it to the members of the organization who will maintain and continue
to update it aer the project closes. The report becomes an important input
to the organization’s continuous improvement process described in the BPR
Improvement Plan created in the Business Analysis and Future Definition
Knowledge Area.
Tools
A template is available:
BPR Performance Report
2.3.4 Tools
The tool that the BPR Practitioner will use within Performance Measurement
during the Closing Process Phase includes the following:
• BPR Performance Report Template
2.3.5 Outputs
Performance Measurement produces the following output during the Closing
Process Phase:
• Initial BPR Performance Report
Outputs
The following is an
output to the activity:
• Initial BPR
Performance Report
California Department of Technology
Business Process Reengineering Framework
Closing | Page 20
Closing
Process Phase Checklist
va
l Lifecycl
Project Appro
Project Appro
Project Appro
3.1 Complete the Checklist
Once all of the BPR activities within the Closing Process Phase are complete,
the process phase checklist should be completed. The checklist provides a list
of “why, how, what, who, where, and when” questions to verify that all items in
the process phase are complete.
Tools
A template is available:
BPR Closing Process
Phase Checklist
The process phase checklist helps to identify and document r
e
epeatable steps,
from project to project, to ensure that the correct activities are completed at
the right time, every time.
Process phase checklists assist BPR Practitioners in quickly and confidently
identifying areas of concern within this process phase. In this case, completion
of the checklist provides a clear milestone that the Closing Process Phase is
complete, including:
• Archived BPR Artifacts
• Completed Lessons Learned
• Completed BPR Improvement Plan
• Initial BPR Performance Report
• Completing BPR Closing Process Phase Checklist
Outputs
Complete the BPR
Closing Process Phase
Checklist to validate
that all process phase
activities are complete.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 1
Additional
Resources
This chapter provides materials that are helpful
for further understanding of business process
reengineering (BPR) and the coordination and
planning of BPR with project management and
organizational change management (OCM). Also
included are a glossary of BPR role definitions
and terms.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 2
In this chapter...
Additional
Resources
1
Approach
Page 3
1.1 Introduction
1.2 CA-BPR Quick
Reference
2
Framework
Resources
Page 11
2.1 Introduction
2.2 CA-BPR
Activities in
Relation to
the CA-PMF and
the CA-OCM
2.3 BPR Resources
3
Glossary
Page 14
3.1 BPR Role
Definitions
3.2 BPR Terms
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 3
Additional
Resources
Approach
The objective of this chapter is to provide BPR Practitioners with supplementary
resources that are useful for understanding, coordinating, and planning a BPR
eort. Additionally, the chapter provides material helpful to understanding the
relationship between the California Project Management Framework (CA-PMF),
California Business Process Reengineering Framework (CA-BPR), and California
Organizational Change Management Framework (CA-OCM) over the Project
Management Lifecycle (PMLC).
1.1 Introduction
The CA-BPR is a practical guide to help the BPR Practitioner and project team
successfully manage a BPR eort. This chapter introduces useful resources that
help give the BPR Practitioner additional information about elements of the CA-BPR
and how it ties to other related State of California frameworks, such as the CA-PMF.
This chapter also includes references to BPR related resources that the BPR
Practitioner or those involved in a BPR eort can use to further their knowledge.
The BPR Practitioner can refer to or use these resources at any point throughout
the project; however, these may be particularly useful during project planning
to help provide context for the activities. The multiple illustrations presented
provide context around and promote coordination with project management
and BPR.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 4
Additional
Resources
1.2 CA-BPR Quick Reference
This section features graphics related to each of the knowledge areas goals and
the key elements from each process phase. While the knowledge area goals and
key elements are presented in CA-BPR chapters for each process phase, they are
presented here in a consolidated view across all process phases. This includes
the following key elements:
• Recommended practices
• Skills
• Roles
• Activities
• Tools
• Outputs
1.2.2 Key Elements by Process Phase
Each chapter of the CA-BPR contains graphics that summarize the following
elements broken out by process phase:
• Recommended practices to consider;
• A list of skills utilized by the BPR Practitioner;
• Key roles that are active during the process phase;
• Activities that the BPR Practitioner should undertake;
• Tools that are available to assist the BPR Practitioner to perform
the activities; and
• The outputs of those activities.
This section features graphics that represent each element across all
process phases.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 5
Additional
Resources
Recommended Practices by Process Phase
The CA-BPR includes narratives describing the recommended practices that are
advised for each process phase. These are based on lessons learned and best
practices. Figure 1-1 shows each process phase’s key recommended practices.
Recommended Practices
Initiating
Concept
Planning
Executing
Closing
• Don’t Over-Document the Current State
• Keep Lessons Learned in Mind Throughout the Project
• Have a Compelling Business Case for Change
• Focus on the Perspective of the Customer
• Have a Clear Baseline to Measure Performance Against
• Make Sure the Gaps are Known and Understood
• Coordinate Resource Needs with the Project Manager
• Establish the “What” Before the “How”
• Take the Time to Document the Environment
• Customize Processes, Not Technology
• Start with Simple, Discrete Processes
• Integrate the BPR Activities with Technology and
Organizational Change Management (OCM) Eorts
• Timebox the Development of Detailed Processes
• Limit the Design of Exceptions
• Consider Trends Over Snapshots• Leverage BPR Resources Aer Go-Live
• Engage Business Process Owners Early• Business Need should Drive the BPR Project
Figure 1-1
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 6
Additional
Resources
Skills by Process Phase
The CA-BPR identifies the skills needed by the BPR Practitioner to perform the
activities in each process phase. Figure 1-2 provides a complete list of all skills
by process phase.
Skills
Initiating
Concept
Planning
Executing
Closing
• Interviewing
• Root Cause Analysis
• Surveying
• Modeling
• Validation
• Project Management
•
•
Analysis
Estimation
• Documentation
• Facilitation
• Judgment
• Facilitation
• Modeling
• Project Management
• Estimation
• Analysis
• Analysis
• Modeling
• Planning
• Project Management
• Judgment
• Facilitation
• Analysis
• Communication
• Project Management
• Planning
• Interviewing
• Modeling
• Judgment
• Analysis
• Facilitation
Figure 1-2
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 7
Additional
Resources
Roles by Process Phase
The CA-BPR lists the roles and associated responsibilities for those who are involved
in the BPR eort. Figure 1-3 shows each key role within each process phase.
Roles
Initiating
Concept
Planning
Executing
Closing
• Project Manager
• Stakeholders
• BPR Practitioner
• Project Sponsor
• BPR Design Team
• Subject Matter Experts
• Stakeholders
• BPR Practitioner
• Project Sponsor
• Project Manager
• Project Team
• Project Team
• BPR Design Team
• Stakeholders
• BPR Practitioner
• Project Sponsor
• Project Manager
• OCM Practitioner
• Project Manager
• Project Team
• BPR Practitioner
• Project Sponsor
• Business Owner(s)
• Stakeholders
• BPR Practitioner
• Project Sponsor
Figure 1-3
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 8
Additional
Resources
Activities by Process Phase
An important component of the CA-BPR are the activities that the BPR
Practitioner performs. The other key elements, such as roles, tools, and outputs,
revolve around and are specific to these activities. While each chapter provides
a knowledge area perspective of these activities, Figure 1-4, shows an overall
view of all activities by process phase.
Activities
Concept
Planning
Executing
Closing
• Identify, Validate, and Prioritize Opportunities
• Document the Current State Assessment
• Document Current State Business Processes
• Determine the Performance Baseline
• Determine and Plan for BPR Activities
• Identify Customer Needs
• Identify Business Process Issues
• Identify Leading Practices and Benchmarks
• Design Future State Business Processes
• Identify and Document Performance Targets
• Determine and Plan for BPR Activities
• Project Support Activities
• Design Detailed Future State Business Processes
• Determine Data Sources and Reporting Solutions
• Determine and Plan for BPR Activities
• Project Support Activities
• Create and Populate the BPR Performance Report• Close Out the BPR Project
• Create the BPR Improvement Plan
• Define Vision and Align with Mission• Determine if BPR is the Right Approach
• Identify Current End-to-End Business Processes
Initiating
Figure 1-4
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 9
Additional
Resources
Tools by Process Phase
The CA-BPR includes tools provided to help the BPR Practitioner perform the
activities and document outputs. Figure 1-5 provides an overall list of each tool
that is used within each process phase.
Tools
Initiating
Concept
Planning
Executing
Closing
• Performance Metric Assessment Template
• BPR Initiating Process Phase Checklist Template
• BPR Schedule Template
• Current State Assessment Template
• Business Process Modeling Tool
• Performance Target Inventory Template
• BPR Planning Process Phase Checklist Template
• BPR Schedule Template
• Business Process Modeling Tool
• Performance Metric Assessment Template
• Performance Metric Assessment Template
• BPR Executing Process Phase Checklist Template
• BPR Schedule Template
• Business Process Modeling Tool
• Performance Target Inventory Template
• BPR Performance Report Template
• BPR Closing Process Phase Checklist Template
• Lessons Learned Template
• BPR Improvement Plan Template
• Business Process Modeling Tool
• BPR Concept Process Phase Checklist Template
• BPR Approach Assessment Template
• Project Charter Template
Figure 1-5
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 10
Additional
Resources
Outputs by Process Phase
Once a tool has been completed or updated to help perform a specific activity,
the tool will become an output. These outputs may also potentially become
inputs and used in another process phase or knowledge area. CA-BPR lists each
of the outputs by knowledge area and process phase. Figure 1-6 provides an
overall view of outputs by process phase.
Outputs
Initiating
Concept
Planning
Executing
Closing
• Completed Current State Assessment
• Completed Current State Process Model
• Identified Performance Baseline
• Completed Performance Metric Assessment
• Completed BPR Initiating Process Phase Checklist
• Completed BPR Schedule
• Identified Customer Needs
• Identified Business Process Issues
• Identified Benchmarks
• Identified Leading Practices
• Prioritized Opportunities
• Completed Performance Target Inventory
• Completed BPR Planning Process Phase Checklist
• Completed BPR Schedule
• Completed Future State Process Model (high-level)
• Updated Performance Target Inventory
• Completed BPR Executing Process Phase Checklist
• Completed BPR Schedule
• Completed Future State Process Model (detailed)
• Initial BPR Performance Report
• Completed BPR Closing Process Phase Checklist
• Archived BPR Artifacts
• Completed Lessons Learned
• Completed BPR Improvement Plan
• Business Process Scope Model
• Completed BPR Concept Process Phase Checklist
• BPR Approach Assessment
• Business Problem Statement
• Business Goals and Objectives
Figure 1-6
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 11
Additional
Resources
Framework Resources
2.1 Introduction
This section provides the BPR Practitioner with a side-by-side view of project
management processes from the CA-PMF and OCM activities from the CA-OCM
that typically occur during the same process phase. Additional BPR resources,
including those from the Information Technology Leadership Academy 21
(ITLA21), Business Process Modeling Readiness Guide, are provided for the
reader to further explore BPR concepts.
2.2 CA-BPR Activities in
Relation to the CA-PMF
and the CA-OCM
As detailed in the CA-BPR process phase chapters, BPR is not performed
in isolation, but rather depends heavily on strong coordination with other
project workstreams. Two important workstreams are project management, as
described in the CA-PMF, and OCM, as described in the CA-OCM.
Figure 2-1 provides an at-a-glance view of each high-level activity (or process, as
is the case with the CA-PMF) by process phase for each of these workstream and
relates the activities of the CA-BPR with activities of the CA-OCM and processes
of the CA-PMF.
Additional Resources | Page 12
Additional
Resources
California Department of Technology
Business Process Reengineering Framework
CA-PMF Processes CA-OCM Activities CA-BPR Activities
Concept
•
Identify the Project Sponsor(s) and Stakeholders
•
Conduct a Readiness Assessment
•
Project Approval Process
•
Concept Process Phase Review
•
Define the Magnitude of the Change
•
Identify Project Sponsor
• Concept Process Phase Re
view
•
Determine if BPR is the Right Approach
•
Define Vision and Align with Mission
•
Identify Current End-to-End Business Processes
•
Concept Process Phase Review
Initiating
• Establish Project Staing
• Create a Project Library
• Review Current Documentation
•
Conduct Stakeholder Analysis
•
Perform Charter Analysis
•
Monitoring and Controlling
• Pr
oject Approval Process
• Initiating Process Phase Review
• Develop the OCM Schedule
• Develop the Sponsorship Action Register
• Identify and Assess Leaders as
Change Supporters
•
Initiating Process Phase Re
view
• Determine and Plan for BPR Activities
•
Identify Customer Needs
•
Identify Business Process Issues
• Identify L
eading Practices and Benchmarks
• Identify, Validate, and Prioritize Opportunities
•
Document the Current Stat
e Assessment
• Document Current State Business Processes
•
Determine the Perf
ormance Baseline
•
Initiating Process Phase Re
view
Planning
• Prepare f
or Planning Process Phase Activities
• Develop Planning Process Phase Artifacts
• Approve and Baseline Planning Process
Phase Artifacts
• Optimize Planning Process Phase Artifacts
• Project Approval Process
•
Conduct Procurements
•
Planning Process Phase Re
view
•
Determine and Plan for OCM Activities
•
Assess Organizational Change Readiness
•
Update the OCM Plan
•
Conduct OCM Activities
•
Develop the Communication
Management Plan
•
Deliver Planning Process Phase
Communications
•
Support and Assist the Project Sponsor
•
Support Executive Leader
ship
• Conduct Team Guidelines Session
• Identify the Training Method and Approach
•
Planning Process Phase Re
view
•
Determine and Plan for BPR Activities
•
Project Support Activities
•
Design Future St
ate Business Processes
• Identify and Document Performance T
argets
• Planning Process Phase Review
Executing
• Assemble the R
esources
•
Pr
epare for the Executing of Process
Phase Activities
•
Dir
ect and Manage Project Work
•
Monit
oring and Controlling Project Work
• Develop Project Status Reports
• Executing Process Phase Review
• Determine and Plan for OCM Activities
•
Assess Or
ganizational Change Readiness
•
Updat
e the OCM Plan
•
Ex
ecute and Monitor the Eectiveness of
OCM Activities
•
Assess St
akeholder Communication Needs
•
Update the Communic
ation Management Plan
•
Deliver Project Communications
• Support Manag
ers and Supervisors
• Conduct Team Guidelines and Team
Eectiveness Surveys and Follow Up Sessions
• Update the Stakeholder Management Plan
•
Identify and Eng
age Stakeholder Group
Representatives
• Identify and Engage Super Users
•
Pr
ovide Guidance for Identifying and
Mitigating Resistance
•
Plan f
or Training
•
Develop T
raining
•
Conduct T
raining
•
Ex
ecuting Process Phase Review
•
De
termine and Plan for BPR Activities
•
Pr
oject Support Activities
• Design Detailed Future State
Business Processes
•
De
termine Data Sources and
Reporting Solutions
•
Ex
ecuting Process Phase Review
Closing
• Pr
epare for Project Closure
• Closeout Project Artifacts
•
Conduct L
essons Learned
•
Celebr
ate Success
•
Administr
ative Closeout
• Closing Process Phase Review
• Close Out the OCM Project
•
Communicat
e Details on Operational Support
•
Ev
aluate Training
• Coordinate Development and Delivery
of Ongoing Training Closing Process
Phase Review
•
Close Out the BPR Pr
oject
• Cr
eate the BPR Improvement Plan
•
Cr
eate and Populate the BPR
Performance Report
•
Closing Pr
ocess Phase Review
Figure 2-1
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 13
Additional
Resources
2.3 BPR Resources
Well-executed BPR is recognized as critical for successfully transforming the
way an organization does business. A number of BPR resources exist containing
perspectives on how to perform BPR and related practices. Many of these
resources have common threads and provide value for a BPR Practitioner. This
section lists BPR resources to accompany the CA-BPR framework.
2.3.1 Resources
Information Technology Leadership Academy 21 (ITLA21) Business Process
Modeling Readiness Guide – ITLA’s Business Process Modeling Readiness
Guide are resources for California’s departments to help their workforce prepare
for business process reengineering. Business Process Modeling (BPM) is a
methodology to identify and document a visual illustration of an organization’s
current business processes. For more information on the Business Process
Modeling Readiness Guide, visit: https://cdt.ca.gov/workforce-development/
information-technology-leadership-academy-archives/.
Michael Hammer – Michael Hammer’s article, “Reengineering Work: Don’t
Automate, Obliterate”, (Harvard Business Review, July-August 1990) introduced
Business Process Reengineering as a process improvement approach that
focused on fundamentally rethinking business processes to remove forms of
work that do not add value. For more information on Michael Hammer and BPR,
visit: www.hammerandco.com.
International Institute of Business Analysis (IIBA®) – The IIBA® is a professional
association serving the field of business analysis. The IIBA® provides publications,
including the Business Analysis Book of Knowledge (BABOK®) that describe
numerous practices and techniques that are helpful to BPR Practitioners. For
more information on the IIBA®, visit: www.iiba.org.
Association of Business Process Management Professionals (ABPMP) – The
Association of Business Process Management Professionals International is a
non-profit, vendor independent professional organization dedicated to the
advancement of business process management concepts and its practices. For
more information on the ABPMP, visit: www.abpmp.org.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 14
Additional
Resources
Glossary
This glossary oers brief, general descriptions of major BPR roles and terms,
many of which are used or referenced in the CA-BPR. This glossary is not
intended as a comprehensive or definitive compilation of terminology used in
the profession of BPR.
The descriptions are drawn from information within the CA-BPR itself, as well
as from highly regarded sources such as the California Project Management
Framework (CA-PMF), the IT Leadership Academy (ITLA), the Project
Management Institute (PMI), the Association of Project Management (APM), and
the BPM Readiness Guide.
Understanding BPR roles and terms is vital for BPR success. While these lists do
not cover all roles and terms, they include common and important ones that
the BPR Practitioner should know and understand.
3.1 BPR Role Definitions
There are many dierent roles, people, groups, and organizations involved in
various elements of a BPR eort. The following is a list of the dierent types of
roles that may be involved and their respective definitions or responsibilities.
BPR Practitioner – The BPR Practitioner is responsible for performing BPR
activities during a BPR eort. The BPR Practitioner may lead and manage a team
of BPR resources including members of the BPR Design Team, Stakeholders, and
other BPR Practitioners. The BPR Practitioner executes activities during all phases
of the PMLC, ensuring activities and resulting work products are in line with project
goals and objectives. The BPR Practitioner coordinates closely with the Project
Manager on schedule, resources, work plan, and monitoring and controlling
activities throughout the project. The BPR Practitioner also works closely with the
OCM Practitioner to provide process-related training and communication support
to ensure buy-in and adoption of new processes.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 15
Additional
Resources
BPR Design Team – The BPR Design Team is a group that performs the design
of future processes during the Planning, Executing, and Closing Process Phases
of the PMLC. Members of this team may consist of Stakeholders, members of
the Functional Project Team, members of the Technical Project Team, other BPR
Practitioners, other SMEs, and End Users. The BPR Design Team is responsible for
developing an organization’s future processes, an activity that is typically done in
facilitated work sessions led by the BPR Practitioner.
Customer – The end consumer or user of a business systems service. Oen the
consumer of the information provided by a business system.
End User – The End User is the person or organization that will use the project’s
end product. End Users can be state or local employees, or members of the public.
There may be several categories of End Users, such as the public via a website,
customer service call center employees, and financial sta. Each category may
have specific project-related needs and expectations.
External Stakeholder – A person, outside of the organization, who has influence
over a project, or who may be aected by a project. For State of CA organizations,
External Stakeholders may include customers that use products or services
(including citizens or members of other departments or agencies) or outside
organizations that are otherwise aected by a project.
Key Stakeholder – A person who participates in the decision to approve or
disapprove requirements on the behalf of other Stakeholders. A Stakeholder
who has significant influence over a project, or who may be significantly aected
by a project.
OCM Practitioner – The Organizational Change Management (OCM) Practitioner
leads the planning and executing of project activities related to preparing the
sponsoring entity and other Stakeholders for changes brought about by the new
product or system. This may include training on the new system, training and
implementation activities involving new business processes, Stakeholder outreach,
and other activities required to successfully implement the project’s solution.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 16
Additional
Resources
Project Manager – The Project Manager is responsible and accountable for
successfully executing a project. He or she receives authority from the sponsoring
organization to execute the project. This authority is documented in the signed
Project Charter. The Project Manager is responsible for organizing and leading the
project team that delivers the project goals and accomplishes all of the project
deliverables. The Project Manager leads the project team through the Concept,
Initiating, Planning, Executing, and Closing Process Phases, all while instituting
monitoring and controlling activities to ensure timely project progress. The Project
Manager guides project teams to successful completion of each project phase’s
milestones and deliverables, thereby meeting the goals of the organization. The
Project Manager must eectively balance and influence the competing project
constraints of scope, quality, schedule, budget, resources, and risks. The Manager
provides the communication link between the Project Sponsor and project team.
He or she also establishes eective communication between the project team
and business representatives participating in the project.
Project Sponsor – This is a critical project role with the authority to decide whether
or not a project should be undertaken, as well as the authority to provide funding,
resources, support for the project and to cancel the project if necessary. The
Project Sponsor ensures the needs of the business area are clearly communicated
in a timely manner. With review and approval of project documents and careful
progress reviews, the Project Sponsor ensures the design of the system meets
all business goals. The Project Sponsor is also responsible for ensuring that
adequate financial and business process resources are made available in a
timely manner to address business needs. The Project Sponsor is expected to
actively lead project teams to address risks and resolve project issues throughout
the project lifecycle. He or she may act as senior spokesperson for the project,
communicating strategic vision for the project both internally to the project
team and externally to other Stakeholders. The Project Sponsor communicates
project status to the organization’s executives as well as Stakeholders outside the
sponsoring organization.
Project Team – A project team is a team whose members usually belong to
dierent groups, functions and are assigned to activities for the same project. A
team can be divided into sub-teams according to need. Usually project teams are
only used for a defined period of time.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 17
Additional
Resources
Stakeholder – A Stakeholder is an individual or organization that can influence
a project, or can be aected by a project, in some way. “Stakeholder” is a very
broad term that includes not only the actual project team members but also any
individuals aected by changes brought about by the product.
Stakeholders typically include all of the separate units within the sponsoring
organization(s) that have a role to play in conducting or supporting the project,
such as the budget shop, the IT division, and the Human Resources unit.
Stakeholders also include interface partners and potential users of the project’s
product, whether they are part of the sponsoring organization or outside of it
(including other branches of state government and federal and local government).
Stakeholders include control agencies that review project details, and those who
have a role in reviewing and approving aspects of the business processes that
may be modified during the course of the project (such as the State Controller
approving payment processes). The Legislature is a stakeholder that may be asked
to approve project funding. Public sector project Stakeholders include taxpayers,
who have a stake in the eective use of public funds and an ongoing interest in the
state’s ability to manage projects and tax dollars eectively. Project teams may
benefit by categorizing Stakeholders in various ways, such as internal or external,
a member of the project team, a person within the sponsoring organization,
or members of the public. Project teams typically find it helpful to identify key
Stakeholders who have significant influence over the project or are significantly
aected by it.
Subject Matter Expert (SMEs) – Subject Matter Experts (SMEs) provide the project
team with knowledge of the details of the business operation, financial controls,
current database history and structure, and other aspects of the business processes
related to the project. These experts oen are not assigned full time, but they are
brought in as needed during requirements definition, design sessions, validation
of design, or at various stages of testing. In more iterative project development,
SMEs may be closely engaged in the development process.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 18
Additional
Resources
3.2 BPR Terms
The following is a high-level list of BPR terms that are widely used among
BPR Practitioners.
Alternative – Dierent solutions and approaches that must be evaluated and
potentially selected to attain the objectives of a project.
Alternatives Analysis – A process of breaking down a complex situation to generate
dierent solutions and approaches in order to evaluate the impact of trade-os.
Assumption – A factor in the planning process that is considered to be true,
real, or certain, without proof or demonstration. [Source: PMI.]
Backlog – A build-up of incomplete or unperformed tasks within a business
processes.
Benchmark – Standard point of reference used to define progress, improvement,
or change.
BPR Lifecycle Management – One of the four BPR knowledge areas, BPR
Lifecycle Management involves planning and management activities necessary
to complete the BPR eort. These activities govern the performance of all other
knowledge area activities and provide management for the BPR eort.
Business Analysis and Future Definition – One of the four BPR knowledge areas,
Business Analysis and Future Definition involves the analysis of the structure,
mandates, policies, and operations of an organization, and development of
the future vision. The principle benefit of business analysis is to understand an
organization’s current environment, thereby creating a foundation based on
documented and validated facts.
Business Driver – Business drivers are external and internal forces that create
a need for business action or “drive” the organization’s business, as well as the
strategies that an organization defines in response to these forces.
Business Goals – The underlying basis for which a project is undertaken.
Business Problem – A perceived gap between the existing state and a desired state.
Business Process – A set of defined ad-hoc or sequenced collaborative activities
performed in a repeatable fashion by an organization. Processes are triggered
by events and may have multiple possible outcomes. A successful outcome of a
process will deliver value to one or more stakeholders.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 19
Additional
Resources
Business Process Design – One of the four BPR knowledge areas, Business
Process Design establishes the design or redesign of current processes to improve
eiciency, eectiveness, quality, and/or service. Activities in this knowledge area
are core to BPR and involve using specific elicitation and modeling techniques
to identify, design and, ultimately, implement new business processes.
Business Process Management Notation (BPMN) – A standardized graphical
notation for drawing business processes in a workflow, facilitating improved
communication and portability of process models. [Source: ITLA]
Business Process Model – A graphical representation for how a set of activities
should operate in a flow and sequence in order to regularly achieve desired
outcomes. A process model depicts the events that trigger action and the
sequences of steps and the business rules used in and between those steps to
support decision-making and execution flow. [Source: ITLA]
Business Process Modeling – The set of activities involved in creating
representations of an existing or proposed business process. Business process
modeling applies a critical set of skills and techniques that enable a person to
understand, communicate, measure, and manage the primary components of
business processes. [Source: ITLA]
Business Process Narrative – A narrative that can accompany the business
process model and helps people to understand the model. The narrative
includes information such as inputs, outputs, triggers, assumptions, and
other information that is required to understand the model. The narrative
complements the model to provide a comprehensive representation of the
business process that can be understood and communicated.
Business Process Reengineering – The purpose of Business Process
Reengineering (BPR) is to help prepare the users for the new or modified
automated system that is being developed. The focus is on understanding
and documenting current processes and business needs, and identifying
where automation may help. Thereaer, the focus shis to assisting users to
modify or use new processes that incorporate the use of the automated system
functionality. Training and measuring process eectiveness are important
parts of the BPR eort. The goals of BPR are to streamline existing processes, to
ensure the correct processes are being automated, and to ensure automation
is addressing the process need. This does not mean the elimination of all
manual processes. Some new processes may be a combination of manual and
automated activities. In many cases, an organizational change or redesign may
be part of the eort, or it may be a simultaneous eort.
Business Requirements – A higher level business rationale that, when
addressed, will permit the organization to increase revenue, avoid costs,
improve service, or meet regulatory requirements.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 20
Additional
Resources
California Business Process Reengineering Framework (CA-BPR) – The
California Business Process Reengineering Framework (CA-BPR) is intended
as a practical guide to help BPR Practitioners successfully redesign business
processes that are part of large, transformative projects. The CA-BPR focuses on
core BPR activities including Business Process Modeling (BPM), documenting
the current state, designing the future state, and coordinating with other project
workstreams across the PMLC. The purpose of the CA-BPR is to provide BPR
Practitioners key steps and recommended practices to promote the successful
implementation of new business processes.
California Project Management Framework (CA-PMF) – The California
Project Management Framework (CA-PMF) is intended as a practical guide to
help project teams manage projects of all sizes so that they achieve expected
outcomes. The Framework focuses on Information Technology (IT) projects in
particular, but is designed for use by project teams across multiple industries.
The objective of the CA-PMF is to provide project teams with useful and practical
advice about what they need to do to make their projects successful.
California Organizational Change Management Framework (CA-OCM) –
The California Organizational Change Management Framework (CA-OCM) is
intended as a practical guide to help OCM Practitioners successfully navigate
and influence changes brought about by the new product or system. This may
include training on the new system, training and implementation activities
involving new business processes, Stakeholder outreach, and other activities
required to successfully implement the project’s solution.
Closing Process Phase – The Closing Process Phase consists of BPR activities
aimed at formally ending the project. Additionally, this process phase aims at
optimizing the future business processes and refining performance measures.
Commercial O-the-Shelf (COTS) – Commercial o-the-shelf soware is
commercially available application sold to the general public by a vendor
through public catalogue listings, not intended to be fully customized or
enhanced. COTS may be integrated into custom-built soware systems. Some
COTS products are designed to be modifiable (MOTS).
Concept – Thoughtful work, discussion, and brainstorming done before formally
initiating a project.
Concept Process Phase – The Concept Process Phase consists of activities aimed
at identifying the business problem(s), business need(s), and establishing a
vision for the project. The Concept Process Phase establishes a firm foundation
for the purpose and direction of the project.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 21
Additional
Resources
Constraint – (1) A limiting factor that aects the executing of a project, program,
portfolio or process. (2) Restriction that aects the scope of the project,
usually involving availability; assignment; or use of project cost, schedule, or
resources. (3) Any factor that aects when or how an activity can be scheduled.
(4) Any factor that limits the project team’s options and can lead to pressure and
resulting frustrations among team members. [Source: PMI.]
Continuous Improvement – An approach to operational process improvement
that is focused on ongoing improvements to products, processes, and/or
services. Oen associated with methodologies such as Six Sigma, Lean, and Total
Quality Management, continuous improvement activities drive performance
improvement in part by continuous measurement of performance indicators
and through instilling a culture on quality.
Current State – Also known as “as-is.” A model of the current structure (such as
process, data, applications, technology). The baseline used for measuring the
success of future changes or improvements.
Cycle Time – The total time that elapses between a customer’s request for an
item, service, or product and the customer’s receipt of it.
Data Warehouse – Houses transaction data for the purposes of querying and
reporting. Main data outputs are informal and formal reports.
DD&I – An acronym standing for design, development, and implementation.
Decomposition – Subdivision of the major project deliverables into smaller,
more manageable (granular) components until the deliverables are defined in
suicient detail to support future project activities (such as planning, executing,
monitoring & controlling, and closing).
Desk Review – A facilitated discussion of each pathway through a process to first
identify any missing steps, artifacts (such as a form or a report), or actors within
the process, and second, to compare the likely results to the desired outcomes.
Documentation – The collection of reports, information, records, references,
and other project data for distribution and archival purposes.
Domain – The functional area under consideration.
Eiciency – Performance measure related to inputs and outputs. Eiciency
involves operating or performing without waste. An eicient process uses the
least amount of resources (inputs) to achieve the greatest results (outputs).
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 22
Additional
Resources
Elicitation – An activity within requirements development that identifies
sources for requirements and then uses elicitation techniques (e.g., interviews,
prototypes, facilitated workshops, documentation studies) to gather
requirements from those sources.
Enterprise Architecture – A coherent collection of standards, policies, and
principles that guide the selection, acquisition, implementation, integration,
and management of IT hardware and soware resources. [Source: SIMM.]
Executing Process Phase – During the Executing Process Phase, the BPR
practitioner elicits and elaborates the detailed future business processes. This
phase also contains the implementation of the future business processes and
the monitoring of performance metrics.
Focus Group – A group of people (5-15) who are brought to together to discuss
and share ideas and opinions relating to a process that they are familiar with or
are aected by.
Framework – The combination of the templates and structured processes that
support the documentation of the architecture in a systematic and disciplined
manner.
Functional Requirements – Characteristics of the deliverable, described in
ordinary, non-technical language that is understandable to the customer.
Future State – Also known as “to-be.” A model of the future structure (such as
process, data, applications, technology).
Gap Analysis – An analysis comparing actual performance with potential or
desired performance. May define steps to achieve desired performance. May
be applied to information technology system performance, project activity
outputs, risk analysis, and other project areas.
Hando – Point or points during a process where information passes from one
entity to another.
Impact Analysis – Qualitative or quantitative assessment of the magnitude of
loss or gain that would be realized should a specific risk or opportunity event or
series of interdependent events occur.
Initiating Process Phase – During the Initiating Process Phase, practitioners
build on the project objectives established during the Concept Process
Phase and document high-level current business processes, Stakeholder
needs, current performance metrics, leading practices, and opportunities for
improvement. These elements are assessed and prioritized and become inputs
into the Planning Process Phase.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 23
Additional
Resources
Inputs – Information and/or documents that feed into a process. Examples
of inputs include receiving an email, getting a system-generated report, or a
telephone call from a customer.
Kaizen – Introduced in 1986 by Masaaki Imai in his book Kaizen: The Key
to Japan’s Competitive Success, Kaizen is a process improvement practice
that focuses on continuous improvement. Its core principle is that small
changes should be made by all employees with the aim of improving overall
organizational performance.
Knowledge Area – Organized groupings of related BPR activities that share
a common objective and purpose. Activities from multiple knowledge areas
occur within a single process phase. BPR’s four knowledge areas include BPR
Lifecycle Management, Business Analysis and Future Design, Business Process
Design, and Performance Management.
Leading Practice – Leading practices are eective strategies, operations, or
processes that are employed by peer organizations with a record and reputation
of high performance in the industry.
Lean – A philosophy and approach focused on providing higher quality, reduced
cycle time, and lower costs. Lean targets the elimination of non-value-add work
through a focus on continuous improvement.
Legacy System – An organization’s existing information and technology systems
that have been heavily invested in and relied upon by the organization. Oen
antiquated and/or insuicient.
Level 0 End-to-End Business Process – An End-to-End Business Process describes
an organization’s business process at the highest level. This level, which is made
up of a single phrase, can be seen as an umbrella business process under which
all other business processes (Level 1), sub-processes (Level 2), activities (Level 3),
and tasks (Level 4) are encapsulated.
Level 1 Business Process – The next highest level of process decomposition is
the business process, which is a series of related actions performed by one or
more stakeholders in order to complete a business transaction or accomplish an
organizational goal. While multiple business processes working together make
up an end-to-end business process, multiple sub-processes working together
make up a business process.
Level 2 Sub-Process – The next level of process decomposition is the sub-
process, which is a series of steps necessary to the completion of a business
process, but insuicient on its own to achieve an organizational goal. While
multiple sub-processes working together make up a business process, multiple
activities working together make up a sub-processes.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 24
Additional
Resources
Level 3 Activity – The next level of process decomposition is the activity, which
is a series of tasks required to execute a sub-process. Activities are further
decomposed into tasks.
Level 4 Task – A task is a single action step performed by a single stakeholder
and is the smallest part of the business processes. Multiple tasks performed
together make up a single activity.
Market Research – Market research determines whether the business goals and
objectives can be met by products or services available in the market-place;
whether commercial practices regarding customizing, or modifying products
or tailoring services are available to meet the Business Goals and Objectives.
Market research is also used to determine the number of potential solutions to
the business problem, which can help shape a future procurement.
Mechanism – Technology or other utility used by a business system to help
automate a business process, activity, or task.
Metric – A quantifiable measure used to track and assess the status of a specific
process, such as a business process, oen with the goal of process optimization.
Mission – A description prepared and endorsed by members of the organization
that typically answers these questions: What do we do? For whom do we do it?
How do we go about it? Used as a guide for making decisions in projects.
Model – The graphical representation or simulation of a process, relationship,
or information, along with a narrative that supports the diagram(s).
Modeling – Modeling is the identification and documenting of a set of processes
(usually of the same nature) that are classified together into a model. Process
modeling is a description of a process in a visual representation that accurately
depicts the process flow. [Source: ITLA.]
Monitoring and Controlling – Continuous tracking, assessment, and
coordination to adjust project performance for maintaining alignment with
project objectives.
Non-Functional Requirements – The quality attributes, design and
implementation constraints, and external interfaces that the product must have.
Organizational Change Management (OCM) – A structured approach to
shiing or transitioning an organization from the current state to a desired future
state. OCM is the application of a set of tools, processes, skills, and principles
for managing the people side of change to achieve the desired organizational
change. It is a process aimed at empowering employees to accept and embrace
changes in their business environment. OCM is frequently required during a
project and/or upon implementation of the project’s product or other end result.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 25
Additional
Resources
Organizational Process Assets – Plans, processes, policies, procedures, and
knowledge bases that are specific to and used by the performing organization.
[Source: PMI.]
Output – The tangible or intangible product typically delivered by a project.
[Source: APM.]
Performance Baseline – (1) Baseline is a specification or product that has been
formally reviewed and agreed upon, that thereaer serves as the basis for further
development, and that can be changed only through formal change control
process. (2) Baseline is a document or set of such documents formally designated
and fixed at a specific time during the lifecycle of a configuration item.
Performance Indicator – A type of value or characteristic against which to measure
progress or results. Used to track, measure, and monitor management strategies.
Performance Measure or Metric – Similar to a metric (see Metric), a
performance measure or metric is a tool describing how to measure and track
success in achieving an organization’s goals. Performance measure targets
provide the quantifiable answer to the question, “How will we know when we’ve
been successful in achieving our goal?” Analyzing the gaps between current
performance levels and performance targets helps organizations identify
priority areas needing improvement and develop strategies to close the gap.
Performance Target – Level of performance as established by a measureable
goal against which actual eort can be evaluated. Indicates a performance level
that an organization intends to meet or surpass during a specific timeframe.
Planning Process Phase – The Planning Process Phase consists of a number of
key BPR activities that contribute to the identification and ultimate acquisition
of a solution. These activities include developing the business case, designing
the high-level future business processes, and assisting in the identification of
the eventual solution approach. Many of the outputs of this phase are used in
formal procurement documentation.
Process – Related business activities performed to produce an end product or
provide a business service. A process has a specific beginning and end point
marked by the delivery or a product or other output.
Process Flow – A method of visually documenting the stages involved in per-
forming a certain business procedure. [Source: ITLA.]
Process Improvement – A systematic approach or series of actions in which an
organization identifies and optimizes its underlying processes to achieve more
eicient results or meet new objectives.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 26
Additional
Resources
Process Mapping – Evaluative tool used to represent and model a particular
process or business operation for the purposes of improving organizational/
operational eiciency.
Process Modeling – A graphical representation for how a set of activities should
operate in a flow and sequence in order to regularly achieve desired outcomes. A
process model depicts the events that trigger action and the sequences of steps
and the business rules used in and between those steps to support decision-
making and execution flow. [Source: ITLA.]
Process Phase – A collection of logically related project activities that
culminates in the completion of one or more deliverables. (The California
Project Management Framework (CA-PMF) describes five process phases:
Concept, Initiating, Planning, Executing, and Closing.) [Source: PMI.]
Process Time – Amount of time it takes for a service or product to have some-
thing done to it (excluding wait time). Measured by calculating how much time
it takes for work to be performed along a certain path, for all possible paths.
Project Approval Lifecycle (PAL) – California has adopted the PAL to improve
the quality, value and likelihood of success for technology projects undertaken by
the State of California. The PAL is intended to ensure projects are undertaken with
clear business objectives, accurate costs and realistic schedules. The PAL includes
various stages separated by gates that are specifically tailored for IT projects.
• PAL Stage 1 – Business Analysis: Provides a basis for project management,
program management, executive management, and state-level control
agencies to understand and agree on business problems or opportunities,
and the objectives to address them.
• PAL Stage 2 – Alternatives Analysis: Provides a basis for how the proposal’s
business objectives will be achieved, the evaluation of multiple alternative
solutions, determines which alternative will yield the highest probability of
meeting the business objectives, and to develop an acquisition strategy/
plan for procuring services.
• PAL Stage 3 – Solution Development: Provides confirmation of the solution
requirements needed to achieve the business objectives and development of
the Request for Proposal (RFP) for the acquisition of services if needed.
• PAL Stage 4 – Project Readiness Approval: A Solution Project Readiness and
Approval Analysis that solicits bids from vendors as to how they propose to
meet the business requirements of the chosen alternative approach, and
where the final form of the project is approved to go forward.
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 27
Additional
Resources
Project Charter – A document issued by senior management that gives
the project manager authority to apply organizational resources to project
activities, and formally recognizes the existence of a project. The Project
Charter’s purpose is to demonstrate organizational support for the project and
the Project Manager, as well as to document the business needs of the new
product, service or other project result.
Project Management – The application of knowledge, skills, tools, and
techniques to project activities to meet the project requirements. [Source: PMI.]
Project Management Lifecycle (PMLC) – A series of process phases to provide
better management and control over a project. During each phase processes,
activities, and tools are used to fulfill project goals or objectives. The PMLC is
designed to accommodate projects that vary in size and complexity.
Project Management Plan (PMP) – The document that describes how executing,
monitoring and controlling of the project will be conducted. [Source: PMI.]
Project Objectives – (1) Identified, expected results and benefits involved in
successfully completing the project. (2) Quantifiable criteria that must be met
for the project to be considered successful. (3) Project scope expressed in terms
of output, required resources, and schedule.
Prototyping – Enables the simulation and evaluation of potential reengineering
eorts within an organization or a systems development area. Provides feedback
on the progress of a reengineering project. If done continuously, allows changes
to be made before finalizing a process design.
Root-Cause Analysis – Root-Cause Analysis is a process of identifying underlying
causes of a problem through the use of specific analytical methods. Example
methods include, 5-Whys Analysis, Barrier Analysis, Change Analysis, Casual
Factor Tree Analysis, Failure Mode and Eects Analysis, Fish-Bone Diagram,
Pareto Analysis, and Fault Tree Analysis.
Requirement – A requirement is defined as “a condition or capability that must
be met or possessed by a system or system component to satisfy a contract,
standard, specification, or other formally imposed documents” (IEEE 610-
12- 1990 [R2002]). Therefore, requirements identify, in objective terms, the
criteria used to measure project success. Requirements should be captured and
approved as early as possible in the project.
Scope – The totality of the outputs, outcomes, and benefits and the work
required to produce them. [Source: APM.]
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 28
Additional
Resources
Six Sigma – A data-driven set of techniques, tools, and methodologies for
process improvement. Used to eliminate process defects, increase customer
satisfaction, reduce costs, improve cycle time, and achieve other metrics as
stipulated by the organization. Goal is to increase profitability by achieving a
high level of quality at reduced costs and time.
System Development Lifecycle (SDLC) – This is a model used in project
management that describes the stages (or phases) involved in an information
system development. The purpose is to meet user requirements in support
of business strategic goals and objectives. Also see SDLC Phase descriptions.
[Source: PMI.]
Solution – Determining what should be done to best support your current
and future business strategy and needs. The deliverables clearly describe the
solutions goals and scope, the capabilities to be implemented, and the risks
associated with the program of work that must be carried out.
Stakeholder Register – Documents the quantitative and qualitative analyses
of people whose interests should be considered. Typically contains at least this
minimum information for each identified Stakeholder: name, title, organization,
position, and location; contact information (such as phone, email, and address);
Stakeholder classification, based on the level of project influence and the level
of project impact the on the Stakeholder’s business or life; and the need for and
type of early engagement with the Stakeholder.
Sub-process – A set of related activities and tasks within a process.
Swimlane – A visual mechanism used in a process flow diagram that depict
what or who is working on a particular subset of a process and for organizing
and categorizing activities, based on cross functional flowcharting, and in BPMN
consist of two types:
• Pool – Represents major participants in a process, typically separating
dierent organizations. A pool contains one or more lanes (like a real
swimming pool). A pool can be open (i.e., showing internal detail) when it is
depicted as a large rectangle showing one or more lanes, or collapsed (i.e.,
hiding internal detail) when it is depicted as an empty rectangle stretching
the width or height of the diagram.
• Lane – Used to organize and categorize activities within a pool according
to function or role, and depicted as a rectangle stretching the width or
height of the pool. A lane contains the Flow Objects, Connecting Objects
and Artifacts. [Source: ITLA.]
California Department of Technology
Business Process Reengineering Framework
Additional Resources | Page 29
Additional
Resources
Task – The smallest unit of work, limited in duration and scope, performed by a
project or organization.
Technical Requirements – Description of the features of the deliverable in
detailed technical terms, providing project team members with crucial guidance
on what needs to be done on the project.
Timeliness – The completion of work correctly on time, as measured by
customer requirements.
Total Quality Management – Techniques for instilling and creating a process of
continuous improvement across an entire organization. TQM relies on four core
concepts: continuous improvement, customer focus, total participation, and
social networking. Begun as a statistical reliability measurement approach, it
is also designed to promote adherence to an organization’s policies on quality.
User Acceptance Test – Structured testing performed by users of the system
being built or modified to determine if it meets their requirements previously
identified in the project.
Walk-through – (1) A peer review and examination of the requirements, design,
or implementation of a project by qualified experts to ensure that the project
objectives will be met. (2) A process used by soware developers in which a
group of knowledgeable peers mentally step through the design and logic flow
of a program with test cases to identify errors and inconsistencies. (3) Rehearsal
of an operational procedure by stimulating the executing of all its steps, but
oen excluding those that are high risk or prohibitively expensive.
Work Products – An item or deliverable (such as a plan, document, or so-
ware) produced by the project.
