<Project Name>

Business Process Model

Business Process Model Template Instructions

(Please remove this section before completion of template)

The Business Process Model should document any current processes that may or should be affected by the project. Once the current processes are documented, the future processes should be identified. Once both these sets of processes have been documented, a gap matrix will need to be completed to bridge the transition.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Business Process Model (SDLC)	O	O	O	This deliverable is optional for all project sizes, unless requested by the Sponsor, Steering Committee or IT management.	The Business Process Model will have two approvals. The first approval will be the plan itself, and the other will be the implementation of the plan. Both should be approved by the Sponsor and the Steering Committee, at a minimum.

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	3

3.	Business Process Review	4

3.1.	Management Processes	4

3.2.	Operational Processes	4

3.3.	Supporting Processes	7

4.	Gap Matrix	8

5.	Implementation Plan	11

6.	Approvals	12

6.1	Plan Approval	12

6.2	Completion Approval/Acceptance	12

Introduction

Purpose

A Business Process Model is created to help with the requirements analysis and design of the proposed system. The three main purposes of a Business Process Model are to:

Capture current business processes providing insight into how work is executed, who is involved, and how activities flow from beginning to end.

Redesign and Improve business processes to reduce inefficiencies, drive down costs, and respond faster to customer requests. A process has to be documented before it can be redesigned.

Automate existing process.

The relationships of a business process in the context of the rest of the enterprise systems (e.g., data architecture, organizational structure, strategies, etc.) create greater capabilities when analyzing and planning enterprise changes.

Assumptions

This document assumes.....

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Business Process Review

Management Processes

Document the processes that will govern the system and/or application operations. This may include corporate governance or strategic management, etc.

Operational Processes

Document and flow out all operational processes that will be affected in any way by the system and/or application. An example of how this can be documented is below:

Business Office – Payment Posting Unit

A site visit was conducted at the Business Office Payment Posting Unit for the purpose of documenting the operational flow of the unit. The operational flow included cashier, lockbox, manual payment posting, remit payment posting, cap payments, reconciliation, refunds and returned checks.

This office currently uses the IDX application, Banner and AMS image system.

Staffing	1 Manager 5 Payment Poster 2 Refund Clerks 1 Data Control Clerk
Data Control Clerk	Charges and Co-payments are posted on site, batched and balanced. Cashier receives the encounter forms, batch proof, batch transmittal form and money. The money is recounted and matched to batch transmittal and batch proof. Money is ....etc.
Cashier Lock Box	The lockbox divides the daily deposits by payers. The cashier receives a list of the day’s deposits. These deposits are logged on the Daily Deposit Spreadsheet. All deposit totals are sent to Newark in the Banner system.
Manual Payment Posting	These reps get the different color coded folders with IDX batches of EOB’s and check copies. Through Posting Option ‘O’, the payments are posted. The approved amount is not overridden during posting. Any rejections are posted using the appropriate code for the payer being posted. Upon completion of posting.....etc.
Remit Payment Posting	Folder is received from lock box with copies of the checks and EOBs for each days deposits. All the check numbers included in the batch are listed on the outside front of the folder. The rep then checks the Check Summary.....etc.
Reconciliation	The manager receives a monthly report that has all the batches posted for the previous month by deposit date. The batches are then matched to the daily bank deposits....etc.

Supporting Processes

Document the processes that will support the core processes, i.e. finance, service center, etc.

Gap Matrix

The goal of gap analysis is to identify the gap between actual processes with potential processes to improve performance. The two questions answered should be “Where are we?” and “Where do we want to be?”

An example of how to document this shown below:

TOPIC: Payment Posting Unit
Goals: Payment Posting Reconciliation
Process	Issue Description	Current State Analysis	GAP Analysis	Future State Analysis
1. Manual Payment Posting	How are payments posted manually into the IDX System?	Batches, divided by insurance types, are posted using Post Receipts action code (O). Rejections are posted at the transaction level to the correct invoice. Batch is logged when completed and sent to scanning.	Continue with current process.	EMR: Continue with current process. Reinstall: Increase the number of remits accepted.
2. Remit Payment Posting	How are payments posted electronically into the IDX System?	Checks are received in the lockbox and the electronic file for that check is requested from IS&T. IS&T runs the load and post. The edits and errors are corrected by the billing representative. Batches are logged when completed.	Check request, load and post moved to payment poster with IS&T still performing the FTP of reports.	Continue with current process.
3. Reconciliation	How are bank deposits for SOM reconciled?	Reports are generated for all batches posted. Batches are matched to each deposit and reviewed for correctness. All corrections are tracked on a manual ledger.	Continue with current process.	Continue with current reconciliation process, except for tracking errors in an electronic file (i.e., Excel).

Implementation Plan

Document the plan, with detailed steps, on how these needs will be met to get to the potential improved processes.

Approvals

Plan Approval

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Completion Approval/Acceptance

The individuals below agree that the plan outlined in this Support Documentation has been executed to completion.

APPROVED BY:
Function Role	Name and Title	Signature	Date

EXAMPLE

Authorization Codes

Business Process Model

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	2

3.	Business Process Review	2

3.1.	Management Processes	2

3.2.	Operational Processes	2

3.3.	Supporting Processes	2

4.	Gap Matrix	2

5.	Implementation Plan	2

5.2.	Adjusted Project Schedule	2

6.	Approvals	2

6.3	Plan Approval	2

6.4	Completion Approval/Acceptance	2

Introduction

Purpose

A Business Process Model is created to help with the requirements analysis and design of the proposed system. The three main purposes of a Business Process Model are to:

Capture current business processes providing insight into how work is executed, who is involved, and how activities flow from beginning to end.

Redesign and Improve business processes to reduce inefficiencies, drive down costs, and respond faster to customer requests. A process has to be documented before it can be redesigned.

Automate existing process.

The relationships of a business process in the context of the rest of the enterprise systems (e.g., data architecture, organizational structure, strategies, etc.) create greater capabilities when analyzing and planning enterprise changes.

Assumptions

All work will be completed by current Service Center and IS&T Billing department staff

Version Control

Version	Date	Person	Change
1.0	9/4/09	A. Levinson	Initial Document Creation
2.0	9/9/09	A. Levinson	Document Updated
2.1	9/23/09	A. Levinson	Document Updated
2.2	9/29/09	T. West-Crews	Document Updated
3.0	10/1/09	A. Levinson	Document Updated
3.1	10/5/09	A. Levinson	Document Updated
3.2	10/6/09	A. Levinson	Document Updated
4.0	10/7/09	A. Levinson	Document Updated

Business Process Review

Management Processes

Authorization Codes Management is distributed across two functional areas: IS&T Billing and IS&T Service Center. The Service Center has processes in place for the distribution and maintenance (add, remove, delete) of UMDNJ authorization codes. IS&T Billing maintains processes that govern the database that links authorization codes to clients and their respective Banner index numbers. The financial transaction component of authorization code management is part of the overall workflow but is a separate process. However, IS&T Billing maintains ownership of the authorization code management processes and forms.

Operational Processes

IS&T – Authorization Code Management

A review of the IS&T Authorization Code Management processes was conducted for the purposes of documenting the operational workflow of the system. The processes span across two functional departments: IS&T Service Center and IS&T Billing. The responsibilities of each unit are indicated in the workflows below.

Authorization Code Processing

Authorization Code Form

Supporting Processes

Authorization Code IDT Processing

Gap Matrix

The goal of gap analysis is to identify the gap between actual processes with potential processes to improve performance. The two questions answered should be “Where are we?” and “Where do we want to be?”

TOPIC: Authorization Codes
Goals: Reduce Fraud Consolidation of Databases Ensure database accuracy
Process	Issue Description	Current State Analysis	GAP Analysis	Future State Analysis
1. Authorization Code Issuance	All auth codes are issued with international calling enabled which should not be the case. This creates the possibility of increased costs and fraudulent use of authorization codes.	Auth code issuance follows the workflow listed above.	N/A – Future state will correct the problem.	Add a simple section to the authorization code form for the client to indicate if international calling is required. Depending on this input, the records in the data base will be updated accordingly and the code will be added to the appropriate call groups.
2. Removal of authorization codes without owner or Banner index	A subset of auth codes are currently active but have no owner or Banner index associated with them. These codes are being used with monthly charges being incurred.	UMD IS&T is currently incurring the costs of these auth codes.	N/A – Future state will correct the problem.	Deactivate these auth codes and reissue new auth codes to clients who self identify as previously using a deactivated code.
3. Consolidation of authorization code databases	Currently two (2) databases are used to manage university auth codes. They are owned by the IS&T Service Center and Billing respectively and are indicated on the workflow. Consolidation of these databases would increase accuracy of auth code inventory and provide greater efficiencies.	Currently two (2) databases are used to manage university auth codes. They are owned by the IS&T Service Center and Billing respectively and are indicated on the workflow.	N/A – Future state will correct the problem.	Consolidate all information into one database to ensure and transfer all auth code management processes to IS&T Billing (auth code troubleshooting would still be addressed by the Service Center).

Implementation Plan

Authorization Code Issuance – to effect this process change, the following tasks will need to be performed.

Task Title	Due Date	Owner
Update Auth Code Application Form – HLA 3	10.30.09	IS&T Billing
Auth code application form will be updated to include a check box for international calling as well as a disclaimer that states the person who is applying for this auth code will be responsible for its usage. The form will also be restricted to one (1) customer code per form.
Setup International Call Group – HLA 1	10.30.09	IS&T Billing
Setup international calling group in auth code database which is initially empty.
Communication to the University – HLA 3	N/A	IS&T Billing
Communication to the University of impending shut-off of international calling. 11.2.09 – Initial communication to University which includes updated auth code form, detailing the reason for the impending shut-off and including instructions on how to minimize disruption of service (re: re-apply for international calling). 11.16.09 – Follow-up communication to University. 12.1.09 – 2nd Follow up communication to University. 12.4.10 – Final communication to University.
Shut off of International Calling – HLA 3	12.7.09	IS&T Billing
International calling shut-off for all auth codes who currently are not in the ‘international calling’ group.

Removal of Auth Codes Without an Owner – to effect this process change, the following tasks will need to be performed.

Task Title	Due Date	Owner
Disable Un-owned and Inactive Auth Codes – HLA 1	11.2.09	IS&T Billing
Disable all University authorization codes that currently do not have an owner associated with them or have been inactive for one (1) year. Individuals who are inadvertently impacted (re: those that have legitimate reasons to have an auth code) will have to reapply and receive a new code. These individuals will apply using the new auth code form, so they will not be impacted by the pending shutoff of international calling.

Consolidation of Authorization Code Databases – to effect this process change, the following tasks will need to be performed.

Task Title	Due Date	Owner
Update Auth Code Process Workflow – HLA 3	N/A	IS&T Billing
The auth code process workflow will be updated to reflect IST Billing will assume the code issuance, delete, and compromised responsibilities. Also, IST Billing will be the source for notification to customers regarding their new auth code. The IST Service Center will handle the initiation of the HEAT ticket, and resolution to problems/questions customers have for existing auth codes (IST Service Center will require access to the Billing auth code database). Please see the updated workflows below (page 13 &14) for further detail: Authorization Code Management Process and Authorization Code Troubleshooting.
Grant IST Service Center Access to Billing Auth Code Database – HLA 1	10.23.09	IS&T Billing
Create specific logins to the Billing auth code database for IST Service Center staff
Develop Database & Updated Workflow Training – HLA 3	10.26.09	IS&T Billing, IS&T Service Center
Service Center & Billing to develop training on the updated auth code management process workflow. IST Billing to develop training for use of the Billing auth code database.
Conduct Training – HLA 3	10.30.09	IS&T Billing, IS&T Service Center
Service Center to conduct previously developed training on the updated auth code management process. IST Billing to conduct training for Service Center on use of Billing auth code database.
Database Cutover – HLA 3	11.2.09	IS&T Billing, IS&T Service Center
New auth code management process will be in place as of 11.1.09. IST Billing database will become the main system of record; Service Center database will retire.

Operational Recommendations - Develop process for reconciliation of termination report with IST Billing database. This should prevent the distribution of codes that belong to former employees.

5.1 Updated Workflow Processes

Adjusted Project Schedule

Approvals

Plan Approval

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date
Sponsor	John Quirinale	Approval received	10.6.09 SC Meeting
SC Member	Shelley Cousins	Approval received	10.6.09 SC Meeting
SC Member	Tina West-Crews	Approval received	10.6.09 SC Meeting
Project Manager	Adam Levinson	Approval received	10.6.09 SC Meeting

Completion Approval/Acceptance

The individuals below agree that the plan outlined in this Support Documentation has been executed to completion.

APPROVED BY:
Function Role	Name and Title	Signature	Date
Sponsor	John Quirinale	Implicit approval	1/08/10
SC Member	Shelley Cousins	Implicit approval	1/08/10
SC Member	Tina West-Crews	Approved via email	1/6/10
Project Manager	Adam Levinson	Implicit approval	1/6/10