business process re-engineering (bpr) description page 1 of 2

California Home Wednesday, November 19, 2003

HHSDC Home BP Home Page The MSC CMM POST Enterprise The Project Office Life Cycle Processes Search BP HHSDC Links Resources Library QAWG SID Policy Contact Us

search

My CA nmlkji

Purpose: The purpose of Business Process Re-engineering (BPR) is to help prepare the users for the new or modified automated system that is being developed. The focus is on understanding current processes and assisting users to modify or use new processes that incorporate the use of the automated system functionality. Training and measuring process effectiveness are important parts of the BPR/BPI effort. The goals of BPR are

To simplify the existing processes

To streamline the existing processes

To ensure that the correct processes are being automated by the new system (i.e., some processes don't really need to be automated)

To ensure that the automation is addressing the process needs (i.e., don't automate just for the sake of automating)

This does not necessarily meant the elimination of all manual processes. Some new processes may be a combination of manual and automated activities. In some cases, an organizational change or re-design may be part of the effort or it may be a simultaneous effort. Definitions:

Business Process Re-engineering (BPR) - Analysis and re-design of business workflows and processes to improve performance. The true sense of BPR usually involves a radical or far-reaching approach (such as a "clean slate" approach). This type of BPR may also include an organizational re-design.

Business Process Improvement (BPI) - A less-radical and sometimes incremental approach. Changes are made to existing processes and new processes are developed only as needed (instead of re-working all processes). Organizational changes are less likely to occur.

Usually, SID performs BPI, although it is often referred to as BPR, using the term in a more generic sense. This web site uses the term BPR for both BPR and BPI.

Process Relationships and Dependencies: To the SID Lifecycle Framework (the big picture)

To the Primary Processes

To the Supporting Processes

Process Details: General Approach to the Process

Process Steps For New Systems Acquisitions

Business Process Re-engineering (BPR)

of 2Business Process Re-engineering (BPR) Description

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr.htm

Process Steps For Maintenance and Operations

Risks and Considerations

Work Products and Deliverables

Tools: None at this time

References: BPR Responsibility Assignment Matrix (MS Word)

Samples: None at this time

of 2Business Process Re-engineering (BPR) Description

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr.htm



search

My CA nmlkji

General Approaches to BPR: There are the three approaches generally used by SID to implement BPR.

New Systems Development - Project Office Responsibility For new systems development, the project office (or its consultants) should perform at least the Goals/Objectives and Current Systems Analysis steps. This allows the project and Sponsor to obtain a better understanding of the users' needs and to incorporate the appropriate items into the RFP (as staffing and funding permit). This also ensures that the project is more effective in subsequent deliverable reviews and testing, because they have a greater understanding of the users' needs and business (this does not mean the users should not participate in testing and reviews however). This is the preferred approach when funding permits. The project office then may choose to perform the BPR, or may have the Prime Contractor perform the BPR along with the new systems development.

New Systems Development - Prime Contractor Responsibility Sometimes the Prime Contractor is responsible for performing all of the BPR efforts, including assisting to develop the goals and scope, and performing the current systems analysis. This method is generally used if the project cannot obtain sufficient staffing or funding to perform the analysis during the Planning/Procurement phases.

M&O - Project Office Responsibility In an M&O environment, the project (or their consultants) is usually responsible for performing any BPR efforts. This generally consists of smaller efforts and BPR may not be needed for every release/change. This is truly more of a BPI effort. This effort also requires active sponsorship from the program area, particularly when coordinating policy changes.

Process Details: Process Steps For New Systems Acquisitions

Process Steps For Maintenance and Operations

Common Risks and Considerations: Schedule Considerations - If the Prime Contractor will be performing all the BPR steps (including the goals/objectives and current systems analysis), it may impact the schedule for the requirements and design, depending on how stable the requirements in the RFP were. The Current Systems Analysis may uncover items that should have been included in the scope, but were overlooked at the time. Sometimes there is simply no funding and/or staffing available to perform the analysis prior to contract award, so the risk of possible scope creep must be accepted.

Schedule Coordination - There is always a strong possibility of colliding schedules and staff availability. Don't forget that sometimes multiple projects are performing work simultaneously at a county/user site. Where possible, coordinate your work with other projects to minimize user inconvenience.

Priorities - Remember that the county/user agenda and priorities are usually different from the State/project's. To the user, the project is just one item amongst the rest of their duties. Try to adjust or at least be aware of the impacts to the counties/users and minimize the impact where possible.

BPR Process Steps BPR Main

Page 1 of 2BPR Process

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20process.htm

Organizational Culture - The business processes and new system cannot solve organizational or cultural problems. Consider how to best address these issues and what impact the processes will have (i.e., will they exacerbate an existing problem, or help to alleviate it?). Often such problems will significantly delay or negatively impact the project's efforts.

Organizational Changes - Organizational changes are very difficult to institute and often require knowledge of many state and union regulations. Be aware and sensitive to these issues and the users concerns. Primary issues in this area are reporting and managerial structure, and types of work performed (are the skills within a given job class?).

User Staffing - If the project entails large scale changes, some users may choose to leave instead of learning to use the new systems/processes, particularly if they are close to retirement. This will affect morale and may impact process roles and responsibilities. There is little that can be done to address this risk.

Empowerment of Participants. Sometimes stakeholder representatives that are assigned to participate in the BPR effort are not experienced, respected or empowered enough to truly be able to represent their organization. In many cases, representatives believe they are only meant to be observers instead of active participants. Be sure to set expectations at the start of the project, and confirm with participants their expected level of participation and decision-making.

Setting Expectations - Acknowledge that the system will not always (and in many cases should not) eliminate all manual processes and sometimes, it creates additional work or shifts in workload (due to approvals and confirmations). Don't try to pass the system off as a silver bullet. Be careful not to promise any functionality or solutions without consulting the development team and scope/requirements documents.

Project Commitment - If a BPR/BPI effort is started, be sure to follow through with it or have a REALLY good reason for stopping it. Otherwise, the staff and users will feel that no one is interested in them, or that their project/Sponsor isn't really committed to helping them. Once this support and buy-in is lost, it is extremely hard to recapture it.

Unpopular Findings - Likewise, if the analysis finds something "bad", it must be elevated and addressed (even if it is unpopular to do so), or the project will lose credibility.

Issue Coordination - Timely answers to legal and policy questions are important. Often there are federal, state and county regulations or policies that must be coordinated and understood to effectively redesign the processes or systems. Be sure to raise and coordinate these issues as soon as possible, particularly if they could impact the automated system.

Implementation Coordination - Be sure to work closely with the (automation) Implementation Team (if they are not the same as the BPR team). Attend some of their meetings and county workshops to ensure a consistent message is being communicated and to ensure all concerns are heard and addressed. Participate in the site assessment at each county to ensure the physical location is conducive to the processes being developed.

Page 2 of 2BPR Process

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20process.htm



search

My CA nmlkji

Basic Process Steps: If the project is using a phased implementation approach, steps 2-6 may repeat, and incorporation of lessons learned by the previous iterations becomes an important part of step 8.

1. Develop the Goals, Objectives and Approach for the BPR effort. 2. Identify the Current System Processes ("As-Is Analysis"). 3. Identify the New Opportunities ("visioning"). 4. Develop the Future System Approach ("To-Be Analysis"). 5. Develop a Process Gap Analysis to identify areas that must change. 6. Develop a Policy Impact Analysis to identify policy areas that impact or are impacted by the

system/processes. 7. Develop the Detailed Process Implementation Plan. 8. Implement the Plan and Processes.

Work Products and Deliverables: BPR Approach Plan/BPR Charter/BPR Project Plan

Communications Strategy/Plan

Issue Resolution Process

Travel Plans/Budget

Current Process Analysis

Future System Approach

Process Gap Analysis

Policy Impact Analysis

Detailed Process Implementation Plan

BPR Lessons Learned

BPR for New Systems BPR Main

Page 1 of 1BPR for New Systems Acquisitions

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20for%20new%20sys.htm



search

My CA nmlkji

The purpose of this step is to allow the project, Sponsor and stakeholders to agree on the scope and approach to the BPR effort. Depending on the approach, this step is performed either during the Initiation/Planning phase, or as one of the first steps in the Systems Development phase.

1. Determine the goals and objectives for the BPR/BPI effort. The objectives should be measurable or verifiable.

2. Determine the scope of the effort.

What organizational units are considered in/out of scope? What process areas or systems are considered in/out of scope? Can automation elements be added to the scope? Can current automation/hardware/software be replaced or upgraded, if appropriate?

3. Determine the organizational boundaries.

Is an organizational re-design or adjustment allowed? Can staff be re-assigned to new areas?

4. Establish the BPR team and participants.

Determine the stakeholders, Sponsor and approval authority, if it is different from the overall project Provide roles and responsibilities, skills needed, authorities (such as for decision making) and time expectations to the stakeholders

5. Develop the BPR Approach Plan/Charter/Project Plan.

Describe how the current and future analyses will be conducted Who will participate in the BPR effort? What is the methodology for each BPR activity? How much time and what level of participation will each activity require? What are the types of anticipated results; how will the results be presented; and at what level of detail will they be presented?

Obtain agreement and signoff on the plan/charter from the Sponsor and stakeholders

6. Document the Communications Strategy/Plan.

This should be an expansion of the project Communications Plan and should be referenced by that plan Describe the types of communications, methods, frequency, content and level of detail, and who is responsible for the communications

7. Document or confirm the Issue Resolution Process.

BPR Goals and Approach BPR Main

Page 1 of 2BPR Goals and Approach

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20goals.htm

This may be part of the Communications Strategy/Plan or a stand-alone document. The process may be part of the regular project issue process, or may be considered a separate process though similar steps should be followed. All issues and their resolution should be documented Ensure there are policy and legal representatives available to discuss and resolve issues Ensure that an escalation process is documented, including timeframes which require escalation All participating stakeholders should agree to use this process and agree to participate in the resolution of issues, as needed This process should be implemented as soon as the Approach Plan/Charter is approved, and should continue until the system is retired.

8. Document or confirm the Travel Plans and Budget for the BPR effort.

Determine who is paying for the travel to county/user locations, or if the costs will be shared

For example, what if county staff are in town for a CWDA meeting and a BPR workgroup? Who pays for what?

Document the specific procedures and agreements, including travel claims, scheduling and approvals required

Timelines: This set of steps should not take more than a few months; 3-5 months is average and more than 9 months is approaching excessive.

Page 2 of 2BPR Goals and Approach

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20goals.htm



search

My CA nmlkji

The purpose of this step is to determine how the users currently accomplish their work, and areas where they hope to correct problems or improve inefficiencies. Depending on the approach, this step is performed either during the Planning/Procurement phase, or as part of the requirements validation/development steps in the Systems Development phase.

1. Research and document the current processes at various representative user locations. Collect any existing documentation. Identify the success criteria and metrics that can be used to measure improvement.

Process documentation should include such things as Process workflows Process steps Mandatory items (e.g., must deposit all received checks at the end of the day by 3pm) Frequency of the process (e.g., once a day, once a month, several times a day, etc.) Measures, metrics, or statistics collected (e.g., number of batches, number of transactions, time to process a request, etc.) Deadlines for processing (e.g., batch windows, EFT transmission deadlines, etc.) Dependencies and start/stop criteria Error and Anomaly handling

Ensure that all affected stakeholders are represented, especially in the workgroups (i.e., don't omit a consortia/region from the workgroup; be sure you have appropriate representation) Establish work groups, as needed (recommend not more than 15-20 people per group). Ensure the workgroups have a charter and plan for their activities. Ensure appropriate Sponsor representation and a process to request decisions or clarification (if not through the issue process). Be sure that the representatives have a clear understanding of the time demands of the work group and that they will be able to devote sufficient time to it. Ensure the members are representatives of the working-level staff and that they are empowered to provide the necessary information, opinions and decisions.

Reports workgroup Forms workgroup Interface workgroup Data Conversion workgroup

Used to address cross-county issues and problems Who pays for manual entry of legacy data (if needed) Who performs the cross-county data resolution?

Data Accuracy and Standards workgroup Establish standards for data entry and conversion to ensure a certain level of data quality in the new system Typical items include standards abbreviations for

Titles (Doctor vs. Dr.; when to use titles) Street names (Street, St, Str; Ninth St vs. 9th Street) City names (LA, L.A., Los Angeles; Lake vs. Lk; Beach vs. Bch)

BPR Current Systems Analysis BPR Main

Page 1 of 2BPR Current Systems Analysis Process Step

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20curr%20sys%20analysis.htm

County and State names (CA, Ca, Calif) How are memo or note fields used? Have they been used as workarounds? Are certain types of information always placed in certain text fields?

Organizational Changes workgroup This workgroup may be warranted to address issues and user concerns, as well as regulations and union issues. A representative from the appropriate Human Resources organization and/or a Union representative may be appropriate

2. Document the interim results for other locations/users who are affected or interested, but not directly participating in the analysis. This will hopefully help to obtain early feedback and comments before the final analysis document is published.

3. Determine data ownership, data access, county-to-county access, and security issues and policies.

These issues may be handled through workgroups (refer to above) if there are a large number of issues or they may be handled through the Issue Resolution Process

3. Determine the key measures and targets for evaluating improvement. These should also include or be factored into the overall goals and success metrics for the effort (refer to item #1 on this page).

Amount of time required to process a request Amount of time required to initiate a case Number of forms processed Number of days for case review User satisfaction (how will you measure this?) Ease of use (how will you measure this?)

4. Document the information gathered in a Current Systems Analysis document. Obtain approval and confirmation of the analysis.

Ensure all sites review the documentation, as well as CWDA, the Sponsor, and other key stakeholders

Timelines: This set of steps will take several months depending on the number of organizations involved, and the complexity of the system; 6-9 months is average, but up to a year is not uncommon for larger systems/organizations.

Page 2 of 2BPR Current Systems Analysis Process Step

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20curr%20sys%20analysis.htm



search

My CA nmlkji

This purpose of this step is to determine how to modify the existing processes to use the new system and ways to address existing problems and inefficiencies. This step is usually performed as part of the design step in the Systems Development phase.

1. Identify the new opportunities/conduct "visioning" sessions.

If appropriate (e.g., if more than 6 months have elapsed since the current systems analysis steps), re-validate existing processes, goals and scope. This may be performed during the requirements validation/definition step of the System Development phase. Identify process/system areas that will and will not change, and document the rationale for such decisions. Determine where automation will dictate or alter existing processes, and where there are opportunities to fix known problems or inefficiencies. Determine alternative business approaches, if appropriate. Document any assumptions or constraints on the processes. In some cases, the new opportunities and assumptions must be approved before proceeding to the next step. In other cases, this step follows to the next step without any approvals. This is dependent on the type of approval structure, and size and complexity of the effort.

2. Develop the Future Systems Approach ("To-Be Analysis").

Develop the ideal process flows. These will be general/high-level process flows. The actual step-by-step processes cannot be developed until the system is built (need the screen names, key field names, etc.). However, there should be sufficient information to ensure that no step in the current processes have been unintentionally omitted. Explicitly state which current process steps are being deleted or replaced by the automated system

Develop alternatives and pros/cons for the alternatives, if appropriate. If appropriate, explain the new organizational structure and change to reporting/approval structure. Identify monitoring points for the key measures to determine process effectiveness.

Identify how often measures will be taken, who is responsible for taking the measures, and how they will be evaluated

Obtain approval (or selection) for the approach.

3. Perform a Process Gap Analysis to identify the impacts to current business policies and practices.

This may be included as part of the Future Systems Approach, or may be a separate document produced after the approach has been approved. Identify the gaps between the current processes and future processes

BPR Future Systems Approach BPR Main

Page 1 of 2BPR Future Systems Approach Process Step

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20future%20sys%20analysis.htm

Determine where decisions must be made Determine how each type of user group will be affected Determine the activities that must be performed to prepare for the new processes and system, including

Training Plan for the new processes Training Plan for the new technologies or COTS products Training schedule Facility or location adjustments Organizational changes

Describe the risks to the process implementation and identify risk owners, monitoring, mitigation and contingency responsibilities and actions

4. Develop a Policy Impact Analysis to identify any impacts to existing policies or areas where policy decisions or changes are needed.

Describe how the current policies will be implemented/automated by the new system Describe the impacts to current policies and why they are needed Determine where decisions must be made Determine if policies need to be/should be changed and make recommendations. Remember the policy organization must decide what changes are made.

Timelines: This set of steps usually requires a few months; 2-6 months is average.

Page 2 of 2BPR Future Systems Approach Process Step

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20future%20sys%20analysis.htm



search

My CA nmlkji

The purpose of this step is to prepare to implement the new and modified processes. This step should coincide with the Testing phases of the System Development phase and the Implementation phase.

1. Develop the Detailed Process Implementation Plan.

If the same team is performing the BPR and system implementation this information may be included in a single Implementation Plan. Develop the approach to implementing the new processes. Develop the schedule, including reviews and checkpoints. Dates will need to be notional due to the need to align with the automation effort. Identify key resources and skills needed to implement the processes. Refine the training approach and schedule. Develop the user skills assessment. Develop the criteria and approach to the process reviews and checkpoints. Develop mitigation and contingency strategies for process implementation risks and critical processes. Ensure all the items identified in the Process Gap Analysis have been addressed. Brief the users and Sponsor on how the implementation will be conducted.

2. Implement the Plan and processes.

Perform preparation for the process and system implementation. Train the users on the new processes. Monitor the processes for a specific period of time to ensure the process is working and addresses the business need. Perform process measurements, as identified by the plan. Review processes and obtain staff feedback Analyze process feedback and measures, and make adjustments as necessary.

Update process documentation and re-train staff Re-assess risks, mitigations and contingencies

Monitor and measure again, as often as needed After the implementation is completed, re-assess the processes to determine how effective the effort was. This analysis could be done as part of the Post Implementation Evaluation Report (PIER) or separately by the Sponsor or user organization. This can be a sort of cost-benefit analysis of the new system to determine if things are working smoothly and if they system/processes have actually improved business processing. This is also an opportunity to collect lessons learned on the BPR and implementation effort.

Timelines: The length of time needed for these steps will vary depending on the type of implementation approach and number of locations involved. Generally step 1 should take 1-2 months for the planning and prep; step 2 may be performed at several sites and may require 1-6 months at each site.

BPR Process Implementation BPR Main

Page 1 of 2BPR Process Implementation

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20proc%20impl.htm



search

My CA nmlkji

Basic Process Steps: The following steps are not necessarily sequenced steps, but a general approach and considerations that should be followed for each release/system change. Some of the later steps occur as needed or as requested. Depending on the size, scope and complexity of the change, it may be appropriate to initiate a more formal BPI analysis as described in the Process for New Systems.

1. Develop an M&O Charter/Plan (review annually once established), and include or update the Communications Plan and Issue Resolution Process. Review any contracts to determine whether any changes are necessary due to the new phase (different emphasis/scope, different reporting metrics needed, types of liquidated damages, etc.) and if the terms and conditions of the contract are still valid (e.g., payment by deliverable vs. time and materials vs. payment by system release).

These plans and processes are not specific to BPR, but should include a description and responsibilities for BPR in the overall approach to M&O. Be sure the charter/plans describe how the M&O/project staff will assist with business process changes/improvements or re-design.

What is the scope of BPR in the context of M&O? What are the project's responsibilities vs. the contractor vs. the users vs. the Sponsor? What is the escalation process for issues?

2. Determine how the changes in the planned release will affect the user, documentation and system.

Determine the impact to the user interface (e.g., screens, reports, etc.) and business processes. Determine the impact to the documentation, including design materials, user manuals, process descriptions and training materials. Determine if there are legal or policy impacts that should be forwarded to a workgroup or the Issue Resolution Process for resolution.

3. Inform the users about the upcoming changes, impacts and the tentative schedules. This may be through a newsletter, e-mail, or website bulletins.

4. If appropriate, invite the user to review and "play with" the system and new changes.

Generally scheduled after system testing, or about 45-60 days prior to issuing the release to production. May not be needed for small changes. Sometimes referred to as County Test Workshops. Some projects conduct these sessions as the final part of System Testing. Others consider it part of User Acceptance Testing.

5. Provide Release Notes to the users which describe the detailed changes, process impacts, and what to expect in the new release.

BPR for M&O Systems BPR Main

Page 1 of 3BPR for M&O

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20for%20MnO.htm

Generally distributed 30 days prior to the release. If there are business process impacts or policy impacts, they should be explicitly described. On-line help, computer-based training and other updated system documentation is generally distributed at this time.

6. Perform User Training as appropriate.

Usually the project facilitates training, with the contractor responsible for updating the appropriate documentation and training materials. Various types of training delivery methods and forums include

Regional Individualized (by user group or location) Computer/Web-based Training (on CD or via website) Train-the-Trainer (project provides materials, but user trainers deliver the information) Training through University/College (e.g., School of Social Work)

Trainers should collect and report their impressions of the system, the comments and/or problems received during trainers (particularly on usability), and suggestions for future enhancements to the system and to the training approach.

7. Upon request, perform or facilitate process assessments ("tune-ups") for the users to help them better utilize the system.

This may entail reviewing their existing processes and methods of doing business, or performing additional or specialized training. Often these assessments are geared towards streamlining the use of the application. Where possible, suggestions are made based on quantitative data from process or system usage reports.

8. If possible, collect and distribute Business Process Models to help users document and refine their process documentation.

By providing samples and/or templates, it helps the users to develop or tailor their own processes, and encourages documentation of the processes. Allows different user groups to share ideas and tips.

9. If possible, encourage the various workgroups and user forums to continue into M&O. This provides communication forums for resolving problems and addressing specific issues. Sponsor participation and support is critical to ensure that decisions are made and acted upon. The Sponsor and users must take ownership of the workgroups for them to be effective.

Work Products and Deliverables: M&O Charter/Plan

Communication Plan updates

Issue Resolution Process

System Documentation Updates

Newsletters/Website Bulletins

System Release Notes

Training Plan and Materials

Page 2 of 3BPR for M&O

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20for%20MnO.htm



search

My CA nmlkji

Work Products and Deliverables: The following are the typical work products and deliverables when performing BPR. For M&O projects, not all of these items may need to be stand-alone formal documents. However, all the information and topics should be considered and the appropriate information should be documented.

BPR Approach Plan/Charter - Describes the approach, methodology, roles and responsibilities and goals of the BPR effort.

Communications Strategy/Plan - Describes the approach to communication for the BPR effort. May be part of the project Communications Plan, or a stand-alone document which is referenced by the project Communications Plan. The format should be generally the same as the project Communications Plan.

Issue Resolution Process - Should follow the same types of steps as the project Issue Resolution, if it is not the same process.

Travel Plans/Travel Budget - Should describe the procedures, forms, approvals and claiming instructions. May be part of the BPR Approach Plan/Charter or a set of separate procedures.

Current Process Analysis (As-Is Analysis) - Describes the current state of business for the various user types.

Future System Approach (To-Be Analysis) - Describes the proposed approach for new and modified processes.

Process Gap Analysis - Describes the differences between what exists currently and what the proposed process/system will be.

Policy Impact Analysis - Describes any changes in policy or policy decisions and issues.

Detailed Process Implementation Plan - Describes the approach to implementing the new processes and how to monitor them for effectiveness.

Business Process Model/Process Descriptions - Presents the detailed descriptions of the process. May be textual or graphical/flowcharts.

Process Training - Training materials specifically geared towards the new processes and how the processes mesh with the new/modified automated system.

Newsletters or Website Bulletins - Provides information to the users on upcoming changes to the system and processes, and the anticipated impacts.

Release Notes (to coincide with system releases) - Describes the implemented changes to the system and processes. See samples below.

Samples:

BPR Work Products and Deliverables BPR Main

Page 1 of 2BPR Work Products and Deliverables

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20docs.htm

Sample Cover Letter for Release Notes (MS Word)

CWS/CMS Release Note Procedures (MS Word)

CWS/CMS Release Notes - High Impact Summary (MS Word)

Business Process Model/Process Description (MS Word)

BPR Charter/Plan/Approach Plan Outline (MS Word)

Current Systems Analysis (As-Is) Outline (MS Word)

Detailed Process Implementation Plan Outline (MS Word)

Future Systems Approach (To-Be) Outline (MS Word)

Policy Impact Analysis Outline (MS Word)

Process Gap Analysis Outline (MS Word)

Travel Budget/Plan Outline (MS Word)

Page 2 of 2BPR Work Products and Deliverables

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20docs.htm

BPR Responsibility Assignment Matrix (RAM) Goals Current

System Analysis

New Opportunities

Future System

Analysis

Gap Analysis

Policy Impact

Analysis

Detailed Impl Plan

Implementation

Prime Contractor1

P or S P or S P or S P or S P or S P or S P or S P or S

Project Office – BPR Team1 2

P or S P or S P or S P or S P or S P or S P or S P or S

Project Office – Implementation Team2

R I R R R I S S

Project Office – QA Team

R R R R R R R R

Project Office – Project Mgr3

A A A A A A A S, R

Sponsor3 S,A S,A A S,A S,A S, A A S, R Users S S,A S S S S I S IV&V R R R R R R R R Stakeholders4 S I S S S S S S P – Primary responsibility S – Support or participate in the effort R – Review results and provide comments A – Approve results or make decisions on approach I – For information only

1 The approach determines who has primary vs. support responsibility. If the Prime is the primary, then the project’s BPR team will support them. 2 Sometimes the BPR Team is the same as the Implementation Team; sometimes they are different. This matrix shows expectations based on separate teams. 3 The approvals are dependent on project structure. In some cases, the Project Manager is authorized to approve the documents; in other cases, the Sponsor and/or Stakeholders must approve BPR/BPI documents. 4 Stakeholders, in this matrix, refers to those stakeholders which are not discussed already in the matrix, such as control agencies, unions, and advocacy groups. Not all these parties will be participants in the BPR/BPI process, but where appropriate, this is generally the type of involvement to expect. (See also footnote 3.)



search

My CA nmlkji

Relationship to the SID Lifecycle Framework: BPR follows the SID Lifecycle Framework and is applicable to both the New Systems Acquisition, M&O and Re-Procurement lifecycles. Some form of BPR is generally needed for all projects, though it may not be a "formal" effort. Refer also to Approaches to BPR. Relationship to the Primary Processes:

Initiation - During the Initiation phase, the project and Sponsor should begin thinking about how the system changes will affect the current organization and business processes. The scope statement (for the system) will also constrain any BPR efforts. Ideally, a short BPR session should have been conducted prior to or as part of Initiation to identify the true need for a system (i.e., is a system truly needed, or just refinement of existing processes?). This is usually best accomplished by a Current Process Analysis (or development of a Concept of Operations (ConOPS). This analysis will help to uncover the true user needs, problems, opportunities and give the stakeholders an idea of the size, complexity and appropriate scope for the project ("fix the problems, not the symptoms"). This information should then be used to develop a more informed project concept and to build the business case for an Feasibility Study Report (FSR).

Planning - During the Planning phase, the project and Sponsor must decide how much BPR/BPI is needed. The goals and scope should be established during this phase to provide a framework for how much money and effort is required, and what the emphasis and boundaries are. The goals and scope will be confirmed and/or adjusted during the Procurement phase, as needed, to respond to Sponsor, user and project concerns and needs. If organizational change is being included, then special coordination must be started in the planning phase. If significant changes are being made to the organization, then the unions, State Personnel Board (SPB) and Department of Personal Administration (DPA) may need to approve the proposed organizational changes, reclassifications, and reporting structure. Be sure to establish contacts and identify the governing regulations and laws prior to beginning any future analysis (To-Be analysis).

Procurement - The Current Systems Analysis or a Concept of Operations (ConOPS) may be performed by the project, and referenced in the RFP to provide bidders with a background on the problem; or the project may elect to include the Current Systems Analysis as part of the tasks the vendor must perform once on contract. The processes at this stage may be high-level, but should incorporate the mandatory steps and key considerations. See also Approaches to BPR.

System Development - If the project team has not performed the Current Systems Analysis, then that analysis would be conducted during the requirements and general/high-level design phases, and documented in the General Systems Design (GSD). If the project team has performed the analysis already, then the processes are re-validated (due to the amount of time that has elapsed due to the procurement) and may be further elaborated at a lower level of detail during the validation of requirements and/or Joint Application Design sessions (JADs). The Future System Approach would be developed and summarized in (or along with) the Detailed System Design (DSD or SDD). The Detailed Implementation Plan would be created during the DSD and Code/Unit Test phases, and must be approved prior to Implementation.

Implementation - The BPR Implementation is usually conducted in parallel with the automation/system implementation. The BPR team must work closely with the automation/system implementation team (if it is not the same team) to ensure the appropriate training and monitoring is conducted. If appropriate, the organizational changes are enacted at this time. This may include a physical

BPR Relationships and Dependencies BPR Main

Page 1 of 2BPR Relationships and Dependencies

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20rel%20and%20dep.htm

move, new reporting structures, and/or establishment of new meetings and status reports.

M&O - For M&O projects, the amount and type of BPR/BPI will vary depending on the number, type and complexity of the changes being implemented. A BPR effort may not be needed for all changes; training may be the primary output, in many cases. The process is the same as in a new systems development, with the possible exception of the Current Systems Analysis. If there is adequate documentation of the current system already, it may be sufficient to perform a brief confirmation of the processes and system area instead of an exhaustive analysis. During M&O, it is also prudent to periodically re-measure and evaluate the processes to ensure that they are effective and keeping pace with changes in the business. This responsibility should fall to the user organization, but often the project will need to assist or facilitate.

Closeout - During Closeout, the primary activity is the archiving of appropriate documentation.

Relationship to the Supporting Processes: Project Management - Project management oversees the BPR effort, regardless of the approach.

Contract Management - If a consultant/contractor is performing the BPR effort, then the Contract Manager would oversee the administrative aspects and work with the project team to ensure the deliverables meet the State's requirements.

Configuration Management - The primary focus is on configuration and version control of documents and presentations.

Requirements Management - Requirements for the processes may be maintained with the automated system requirements or may be in kept in a separate area. If a single vendor is performing both the BPR and automated system development, it is recommended all requirements be kept in a single repository to aid tracking and testing.

Issue Management - Any issues that are raised should be tracked in the same manner as the rest of the project. A separate category may be used to identify those issues that are specific to BPR. Questions and what-ifs should be tracked separately; refer to the definition of an issue for clarification.

Risk Management - A risk assessment should be performed and the results discussed with stakeholders. Some risks will be outside the control of the project. See also Common BPR Risks and Considerations.

Quality Assurance - Key quality factors for BPR include identifying and involving the appropriate set of stakeholders, obtaining feedback from all users, obtaining buy-in from all users, ensuring all processes are considered and represented, and ensuring the proposed processes are compatible with the system under development.

Process Improvement - BPR works hand-in-hand with process improvement. The hope is that the users will embrace the new processes and system, and then take ownership of both and continue efforts to refine the processes to use the system. Once the processes are implemented, the project's role begins to diminish. Ultimate responsibility for the processes becomes the domain of the users (though the project may assist or facilitate process improvement efforts during the M&O phase).

Independent Verification and Validation (IV&V) - An IV&V vendor may oversee and monitor the results and effectiveness of BPR. Primarily the focus will be on monitoring the quality, communications, and risks associated with the BPR effort and ensuring a consistent structured approach is being followed.

Page 2 of 2BPR Relationships and Dependencies

5/24/2004http://www.bestpractices.cahwnet.gov/Misc%20Processes/BPR/bpr%20rel%20and%20dep.htm

business process re-engineering (bpr) description page 1 of 2

Documents