Project Charter
Author FSRP Project Team
Title Project Charter
File Name FSRP_Project_Charter_v1.9.doc
Deliverable Key DCD 1.1 Project Charter
Last Edited 4/29/2004 9:55 AM
Number of Pages 87
Version Revision Date Revision Comments Author
1.0 1/19/2004 First Draft Joshua Perry
1.1 2/17/2004 Incorporated Project Standards & Scope Danny Trudgett
1.2 2/19/2004 Incorporated Implementation Standards Michelle Bankowski
1.3 2/24/2004 Incorporated Project Strategies Michelle Bankowski
1.4 3/1/2004 Incorporated edits from various Reviewers Michelle Bankowski
1.5 3/3/2004 Removed Implementation Standards Michelle Bankowski
1.6 3/4/2004 General updates. Added a new “Issue Type” Danny Trudgett
in Issue Management Plan
1.7 3/9/2004 Incorporated edits from Mike Calhoun and Jim Danny Trudgett
Lewis
1.8 3/30/2004 Incorporated updates from ESC Danny Trudgett
1.9 4/29/2004 Incorporated Change Management Strategy Michelle Bankowski
4/29/2004 1 of 87
Table of Contents
1 EXECUTIVE SUMMARY .................................................................................................................................4
1.1 INTRODUCTION ...............................................................................................................................................4
1.2 PROJECT OVERVIEW .......................................................................................................................................4
1.3 PROJECT OBJECTIVES .....................................................................................................................................4
1.4 PROJECT BENEFITS .........................................................................................................................................4
1.5 CRITICAL SUCCESS FACTORS .........................................................................................................................5
2 IMPLEMENTATION STRATEGY AND APPROACH .................................................................................6
2.1 IMPLEMENTATION STRATEGY .........................................................................................................................6
2.2 IMPLEMENTATION APPROACH ........................................................................................................................6
2.3 TIMELINE ........................................................................................................................................................8
2.4 IMPLEMENTATION METHODOLOGY ................................................................................................................8
3 PROJECT ORGANIZATION............................................................................................................................9
3.1 TEAM STRUCTURE ..........................................................................................................................................9
3.2 FSRP MANAGEMENT CHAIN ..........................................................................................................................9
3.3 FSRP STAFFING REQUIREMENTS..................................................................................................................10
3.4 PHYSICAL LOCATION ....................................................................................................................................10
3.5 PROJECT FINANCIAL MANAGEMENT ............................................................................................................11
3.6 ROLES AND RESPONSIBILITIES ......................................................................................................................11
4 PROJECT SCOPE ............................................................................................................................................21
4.1 ORGANIZATIONAL SCOPE .............................................................................................................................21
4.2 PROCESS SCOPE ............................................................................................................................................24
4.3 TECHNICAL SCOPE........................................................................................................................................31
5 PROJECT STRATEGIES ................................................................................................................................37
5.1 OVERVIEW....................................................................................................................................................37
5.2 UC CONFIGURATION CYCLE STRATEGY .......................................................................................................37
5.3 TESTING STRATEGY......................................................................................................................................40
5.4 DATA CONVERSION STRATEGY ....................................................................................................................44
5.5 INTERFACE STRATEGY..................................................................................................................................46
5.6 REPORTS AND FORMS STRATEGY .................................................................................................................52
5.7 ABAP ENHANCEMENT STRATEGY ...............................................................................................................53
5.8 EXTENDED FUNCTIONALITY/BOLT-ON STRATEGY .......................................................................................54
5.9 POST IMPLEMENTATION SERVICE AND SUPPORT STRATEGY ........................................................................55
5.10 SYSTEM ENABLER STRATEGY ......................................................................................................................57
5.11 CAPACITY PLANNING STRATEGY .................................................................................................................58
5.12 DISASTER RECOVERY STRATEGY .................................................................................................................58
5.13 ARCHIVING STRATEGY .................................................................................................................................59
5.14 CONTROLS AND SECURITY STRATEGY..........................................................................................................59
5.15 TECHNICAL INFRASTRUCTURE STRATEGY ....................................................................................................60
5.16 ORGANIZATIONAL CHANGE MANAGEMENT STRATEGY ...............................................................................61
5.17 END USER TRAINING STRATEGY ..................................................................................................................75
6 PROJECT STANDARDS AND PROCEDURES ...........................................................................................76
6.1 COMMUNICATIONS MANAGEMENT PROCEDURE...........................................................................................76
6.2 RISK MANAGEMENT PLAN ...........................................................................................................................76
6.3 PROJECT STATUS REPORTING PROCEDURE ...................................................................................................78
6.4 PROJECT MEETING PROCEDURE ...................................................................................................................79
6.5 PROJECT DOCUMENTATION STANDARDS ......................................................................................................81
6.6 STANDARD TOOLS AND RESOURCES.............................................................................................................81
4/29/2004 2 of 87
6.7 ISSUE MANAGEMENT PLAN ..........................................................................................................................82
6.8 SCOPE MANAGEMENT PLAN .........................................................................................................................84
6.9 PROJECT PLANNING AND MONITORING PROCEDURE ....................................................................................86
6.10 QUALITY ASSURANCE STANDARDS ..............................................................................................................86
Table of Figures
FIGURE 1 – FINANCIAL SYSTEMS REPLACEMENT PROJECT TIMELINE ............................................................................8
FIGURE 2 – ASCENDANT™SAP PROJECT LIFECYCLE .....................................................................................................8
FIGURE 3 – FINANCIAL SYSTEMS REPLACEMENT PROJECT ORGANIZATION STRUCTURE ...............................................9
FIGURE 4 – ITERATIVE CONFIGURATION PROCESS .......................................................................................................37
FIGURE 5 – FLOW OF DATA OBJECTS DURING DATA MIGRATION ................................................................................45
FIGURE 6 – SAP INTERFACE PROCESS ..........................................................................................................................50
FIGURE 7 – INTERFACE MODEL FOR EAI......................................................................................................................51
FIGURE 8 – FSRP INITIATIVE POTENTIAL AREAS OF IMPACT .......................................................................................61
FIGURE 9 – FSRP CHANGE MANAGEMENT STRATEGY ELEMENTS ...............................................................................63
FIGURE 10 – RISK MANAGEMENT LIFECYCLE ..............................................................................................................64
FIGURE 11 – ALIGNMENT OF STAKEHOLDER AND COMMUNICATIONS ACTIVITIES .......................................................69
FIGURE 12 – STAKEHOLDER COMMITMENT CURVE ......................................................................................................72
FIGURE 13 – RISK CLASSIFICATION TABLE ..................................................................................................................77
FIGURE 14 – PROJECT SCOPE DEFINITION ....................................................................................................................85
4/29/2004 3 of 87
1 Executive Summary
1.1 Introduction
The Project Charter sets out the overall approach for delivering a quality SAP system for the University of
Cincinnati’s Financial System Replacement Project (FSRP). It outlines the project organization, roles and
responsibilities, scope, methods, tools and processes to be used, and is designed to:
• Facilitate the successful completion of the FSRP
• Instill confidence in the quality of the work performed as part of the project
• Define the roles and responsibilities of project stakeholders
• Provide a mechanism to execute the project and track and report project progress
• Define the framework within which project progress and issues are communicated both within the
project team and to the wider UC community.
The Project Charter is a living document that is maintained and controlled by Project Management. The
document is updated as required during the project, with the most current version available in the
Ascendant ERP toolset.
1.2 Project Overview
The University of Cincinnati Financial System Replacement Project will replace the College and University
Financial System (CUFS), with a mySAP Business Solution that applies current technology and best
business practices to improve the University’s financial management operations.
The FSRP solution will provide UC a set of consistent financial policies, procedures, and processes that
improve the University’s ability to capture and access the financial information needed to better manage
its operations and financial position.
FSRP is a collaborative effort between the University, IBM Business Consulting Services and SAP.
1.3 Project Objectives
FSRP has four main objectives:
• Relate to UC’s needs as a 21st century public university
• Efficient financial operations and accurate information
• Flexibility and information access improvements
• Ability to use financial information to manage central resource strategies.
1.4 Project Benefits
The primary benefits expected to accrue from FSRP are:
• Supports a flexible, evolving and responsive business environment
• Eliminates non-value adding activities such as data entry duplication
• Adopts best practices where possible
• Improves ability to service customers
• Improves quality, quantity and timely processing of UC’s financial data enabling better information
for mission-critical decisions
• Reduces reliance on ancillary systems
• Provides an integrated solution to the shortfalls of the existing CUFS system
• Streamlines business processes and reduces inefficiencies
4/29/2004 4 of 87
• Supports information sharing and access
• Simple and easy-to-use interfaces.
1.5 Critical Success Factors
Success for the Financial System Replacement Project (FSRP) SAP implementation is defined as follows:
General
• The FSRP SAP implementation must come in on time, on budget and with the functional scope
that will be defined and agreed to during the Blueprint Phase of the project.
• Adequate knowledge transfer must take place from the external (IBM and SAP) consultants to UC
personnel, through all phases of the implementation so that UC will be fully capable of supporting
the SAP system at the conclusion of the initial phase of the implementation effort.
• The organizational impact of the new system must be minimized by dedicated Change
Management activities that support a smooth transition to the new SAP environment.
• All personnel must be adequately trained prior to using or working with the new system.
Functional
• Business processes and practices contained in the mySAP Business Solution will be adopted to
improve UC practices and procedures.
• UC must be able to go live with General Ledger, Accounts Receivable, Accounts Payable,
Purchasing and Grants Management on 1 July, 2005.
• Budget, including Position Budgeting, must go live on 1 March 2005.
• Shadow systems should be eliminated wherever possible.
Technical
• Standard SAP configuration practices and capabilities will be adopted. The SAP program code
will not be customized or modified.
• Existing interfaces with the CUFS system must be allowed for in the implementation of the new
SAP system.
• The new system will provide the ability to interface to and provide data for other UC web
applications.
4/29/2004 5 of 87
2 Implementation Strategy and Approach
2.1 Implementation Strategy
A successful implementation strategy will create the baseline that bounds the project and acts as a
gateway for scope, schedule, and resource change requests. This provides management with necessary
guidelines to support the project related to resources, quality, configuration, releases, issues, scope,
change requests, risk, finances, contingency, and performance reporting.
The Project Team will develop a common design of business process functionality that meets the needs
for all University Departments, maximizing the use of configurable SAP functionality. During the Blueprint
Phase, the joint functional design teams (UC/IBM/SAP) will collect and document business requirements
across the University. The processes are evaluated and categorized based on level of fit to the software.
These requirements are configured, integrated and tested before deployment, involving University subject
matter experts. Business process scenarios will be successfully tested and approved by User Acceptance
Testers. System testing, including interfaces and conversions, training and cutover activities will then
occur prior to deployment of the solution.
The University is interested in a solution that provides a single integrated source of financial information.
This single system concept will reduce reconciliation, enable management reporting, reduce processing
time, and provide insight to data on a university wide basis. While the acquisition of new, functionally rich,
and technologically advanced software is an important step for the University, as important is how well
the University understands, accepts, adapts, and is able to leverage the software for future business
process improvements.
The following criteria must be met in order to effectively execute the UC project strategies (see Section 5
“Project Strategies”):
• Sufficient time and resources are dedicated to complete the identified tasks to meet the project
timelines
• Involvement of the executive and business process owners, including interface owners, data
object owners and data conversion owners.
• Quick and timely decision making, sign off and priority setting to assure project proceeds on
schedule
• Issues are addressed and resolved in a timely manner
• Risks are identified early and are effectively managed.
2.2 Implementation Approach
The implementation approach for the University is designed to deliver the core integrated solution in four
technical and functional waves:
• Core Financial Management: The core system, based on SAP R/3 Enterprise 4.7 and the
Enterprise Add-on for Public Sector (EA-PS) 2.0 including General Ledger, Funds Management,
Accounts Payable, Accounts Receivable, Purchasing, Asset Accounting/Capital Finance, Grants
Management, Endowment Management and Project Accounting
• Budget Planning: The SAP Strategic Enterprise Management (SEM) solution for budget
planning and simulation functions
• Financial Reporting: The SAP Business Information Warehouse solution for consolidated
financial reporting and access to limited historical data
• Enterprise Portal: The SAP Enterprise Portal to provide unified access to the mySAP
components via a web-based user interface.
4/29/2004 6 of 87
2.2.1 Implementation Schedule Goals
The proposed implementation schedule is designed to:
• Transition to the new SAP system in a way that minimizes disruption to UC’s financial
management operations by aligning the Go-Live of the Core Financial Management system with
the end of the Fiscal Year and by aligning the Go-Live of the Budget Planning system with the
start of the FY05 budgeting cycle,
• Minimize overall implementation cost by adopting a common Project Preparation phase that
supports all subsequent implementation waves, and
• Utilize the SAP Enterprise Portal as a unified access point for the underlying SAP R/3, Strategic
Enterprise Management and Business Warehouse systems, providing the University with a role-
based Web interface.
2.2.2 Proposed Timing
The recommended implementation timeline will deliver an operational SAP system in 18 months,
coinciding with the beginning of fiscal year 2006.
The figure below illustrates the relative timeframes for the deployment of each wave. The schedule
includes six weeks of supporting activities after the go-live date with a strategically chosen team of
consultants assisting UC in the smooth transition to a production environment.
During the Core Financial Management Blueprint phase, the Project Team will evaluate the implication
and feasibility of implementing purchasing-related contract functionality prior to the Go-Live of the Core
Financial Management system.
The issues relating to year-end with a new system can be challenging and, as such, require additional
attention due to new processes and procedures based on the new system. For this reason, the
implementation approach includes additional production support concurrent with the initial Go-Live and
the first year-end roll-over.
4/29/2004 7 of 87
2.3 Timeline
2003 2004 2005
Wave
S O N D J F M A M J J A S O N D J F M A M J J A S O N D
Project Prep.
Core Financial Blueprint
Final
Management Realization
Prep.
(R/3 Enterprise) Go Live
Core Financial Sustain
Blueprint
Blueprint Realiz-
Budget ation Final
Prep.
Planning Project
Strategies Go Live
(SEM-BPS) & Sustain
Standards
Blueprint Realiz-
Financial ation Final
Reporting Prep.
Go Live
(BW) Sustain
Go Live
Portal Blueprint / Realization Sustain
Figure 1 – Financial Systems Replacement Project Timeline
2.4 Implementation Methodology
The Financial System Replacement Project (FSRP) will implement SAP using IBM’s Ascendant™SAP
methodology. The Ascendant™SAP methodology is a web-enabled project support system with Project
Management Information System (PMIS) functionality and a central repository (the Ascendant ERP
Toolset) that aids in managing the project and maintaining documentation and deliverables. The
methodology is based on SAP’s Accelerated SAP (ASAP) methodology and commercial best practices, to
provide a comprehensive framework for implementing SAP solutions.
Ascendant™SAP includes templates and accelerators for deliverables, work products and project
management. Based on the SAP R/3 Reference Model, the methodology delivers a standardized,
repeatable and proven approach to the FSRP SAP implementation. The Ascendant™SAP methodology
provides a roadmap for the SAP implementation with phases, activities, milestones and deliverables
addressing five key focus areas for a complete lifecycle implementation. Figure 2 shows the
Ascendant™SAP Project Lifecycle Phases and key focus areas.
Ascendant TM SAP Project Lifecycle
Program Management
Business
Evaluation Project Business Realization Final Go Live Sustain Organization
Preparation Blueprint Preparation and
Support Application
Architecture
Figure 2 – Ascendant™SAP Project Lifecycle
4/29/2004 8 of 87
3 Project Organization
3.1 Team Structure
The Project Team Structure is based on a collaborative team effort, drawing resources and skills from
UC, IBM and SAP. The structure is designed to support knowledge transfer to UC staff so that UC can
establish a core competency in the operation and maintenance of the SAP system.
Figure 3 – Financial Systems Replacement Project Organization Structure
A Project Team Structure Chart including Project Team Member names is maintained in the Ascendant
ERP Toolset.
3.2 FSRP Management Chain
All resources dedicated to the FSRP SAP implementation (i.e. UC, IBM, SAP) will ultimately report to the
FSRP Project Managers for the period that they are assigned to the project.
UC personnel who are required to divide their time between the FSRP project and their existing job
function will work under a matrix reporting relationship based on time allocation that is agreed to between
the FSRP Project Managers and the relevant Functional Area Management. UC personnel performing
4/29/2004 9 of 87
FSRP-related work, but who are not actually assigned to the project, will report to their existing
management as usual.
3.3 FSRP Staffing Requirements
It is anticipated that the number of dedicated UC personnel will range from a minimum of 8-10 people in
the early stages of the project, up to a maximum of 40-50 people.
3.3.1 Augmenting UC Personnel
In order for the FSRP SAP implementation to be successful, a combination of UC and contract personnel
will be required. Contract personnel may fill a variety of roles based on the specific needs of the project
and the area they are serving. These roles may include:
• Backfilling UC staff so that they can be dedicated resources on the FSRP SAP Implementation
project
• Working directly on the FSRP SAP implementation project, bringing specific knowledge and
experience
• Supplementing personnel in either the project or functional areas during periods of heavy
demand.
3.3.2 Retaining UC Staff on the FSRP
UC believes that the people on the FSRP SAP implementation are important to the institution. UC Project
Team Members are identified on the basis of their knowledge of current processes, their ability to
envision new and better ways to conduct business in the future, their ability to act as “Change Agents” for
the SAP implementation, their ability to work with others and their overall work ethic. Understanding this,
UC is committed to enhancing the current and future performance of UC Project Team Members including
identifying career opportunities which meet personal and organizational goals.
UC Management is aware of the magnitude of the effort that will be required to accomplish the successful
implementation of the new SAP system. In recognition of this, a flexible framework of compensation
options has been developed to compensate significant contributors for their involvement in the project.
Options include:
• Flex Time – a flex time option will be available in certain cases that will allow people to work a
flexible schedule, both in terms of the hours worked during the day and the days of the week that
will be worked
• Comp. Time – In some cases compensatory time off may be a more appropriate arrangement,
particularly in the case of people who are significantly involved in the project for a relatively short
period of time
• One-Time Bonus – A one-time lump sum cash award may be offered to reward individuals or
teams for their contributions
• Incremental Pay Increase – If someone is going to be involved in the project for an extended
period of time and will continue to be responsible for duties in their functional area, a temporary
pay adjustment of up to 10% of their base salary may be offered.
3.4 Physical Location
Project Management Best Practice shows that project teams are most effective and efficient when the
members are as closely located as possible. The bulk of the FSRP Implementation Project Team will be
located on the fifth floor of University Hall, in an area that has been specifically configured for the project.
Members of the FSRP Implementation System Development and Infrastructure Teams will be located on
the fourth floor of University Hall, in an area that will be re-configured in April 2004 to accommodate the
project’s requirements. It is possible that a larger space may be required during the peak of the
implementation effort and alternatives will be considered should this become necessary.
4/29/2004 10 of 87
3.5 Project Financial Management
The FSRP SAP implementation will be paid for through the Core System Budget Fund. The IMTC-
approved budget has been set based on several obligations including:
• Implementation Partner services
• New positions required for successful implementation
• Back-filling of positions to replace Core Project Team Members
• Business and technical training
• Software upgrades required (other than the Core System software – SAP)
• New hardware required.
The UC Business Process Project Manager is responsible for monitoring all project expenditures and
reporting the status of the budget to the Executive Steering Committee on a monthly basis. Actual or
potential budget problems should be communicated to the Executive Steering Committee Co-Chairs
immediately for resolution. It is the direct responsibility of the Executive Steering Committee Co-Chairs to
keep the budget within the boundaries established and approved at project startup.
3.5.1 Financial Accounting Principle for the FSRP
It is imperative for the integrity of the FSRP to have proper accounting procedures in place to track and
monitor budget and expenditures associated with the project. The process for this is detailed in the
“Financial Accounting Principle” document which is available in the Ascendant ERP Toolset.
3.5.2 Financial Expenditure Approval
The process and associated form for requesting backfill funds is detailed in the “Financial Expenditure
Approval” document which is available in the Ascendant ERP Toolset.
3.6 Roles and Responsibilities
3.6.1 Introduction
The roles and responsibilities documented below are intended to provide guidance for individuals
participating in the FSRP project. They represent a framework from which team members can understand
their own primary areas of responsibility, as well as those of their colleagues, and thereby better
understand how they can focus their own energies to deliver the overall solution.
It is important to note that while this document is intended to assist in defining borders between roles in
order to promote understanding and avoid duplication of effort, it is not intended to be a definitive “all
encompassing” list which is read as the maximum contribution a person can make to the success of the
project. It is both an expectation and a requirement that individuals will contribute to the project in ways
not formally enumerated in this document.
The implementation of an integrated solution such as SAP is an integrated effort. It is the responsibility of
all team members to ensure that cross-domain activities such as Project Management, Change
Management and End User Training are incorporated to every extent possible in the work they do and the
deliverables they produce. Everyone is responsible in some way for the successful implementation of the
FSRP system. To achieve success, individual roles and responsibilities may have to be adapted. It is
expected that this adaptation will be organic to the project team and will be performed as and when
required with minimal formal constraints. If necessary, this document can be updated to reflect the
realities of the project as the project progresses.
The organization chart for the project (shown in Section 3.1) describes a single team for each of ‘Change
Management and Training’, ‘Business Process’, ‘System Development’ and ‘System Infrastructure’. For
the larger teams (e.g. ‘Business Process’) there will be sub-teams (e.g. ‘Purchasing’ or ‘Budget’) that will
have team members that will assume ‘Team Lead’ level roles and responsibilities for their sub-team.
4/29/2004 11 of 87
Likewise, the ‘Change Management’ and ‘Training’ roles are separately described in this document
however, there is a single ‘Change Management and Training’ team shown on the organization chart.
Each of the ‘Change Management and Training’, ‘Business Process’, ‘System Development’ and ‘System
Infrastructure’ teams will have ‘Team Leads’ from both UC and IBM. The roles and responsibilities
described in this document will be shared between the IBM and UC Team Leads according to the ‘Lead’
and ‘Assist’ status of the work package/deliverable as described in the Statement of Work, and according
to the individuals’ capabilities and workload. The IBM and UC Co-Leads are jointly responsible for the
overall performance of their team and it is expected that they will work closely together to coordinate and
direct their efforts.
3.6.2 Project Management
3.6.2.1 Project Sponsor
The Project Sponsor defines the FSRP’s vision and goals. The Project Sponsor:
• Is the ultimate owner of the project and has decision-making power in the fulfillment of the
primary responsibilities, as outlined for the Steering Committee Members
• Maintains the final authority to set priorities, approve scope, and settle University-wide issues
• Promotes the FSRP project throughout the organization
• Has final budget authority.
The UC FSRP project has two sponsors: the CIO and CFO. The Project Sponsors meet regularly with the
Executive Steering Committee Co-Chairs and Project Managers.
3.6.2.2 Executive Steering Committee Co-Chairs
The Executive Steering Committee (ESC) Co-chairs represent the Project Sponsors in defining and
executing the FSRP project. The responsibilities of the ESC Co-Chairs include:
• Chair the Executive Steering Committee
• Represent the Executive Steering Committee at the Sponsors Meetings
• Support timely decision making by resolving escalated issues and routing decisions to the
Sponsors or Executive Steering Committee.
3.6.2.3 Executive Steering Committee
The Executive Steering Committee (ESC) sets project priorities, approves scope, and resolves University-
wide issues in accordance with the vision and goals set by the Project Sponsors. The Executive Steering
Committee aids in promoting the SAP implementation project throughout the organization. The primary
responsibilities of the Executive Steering Committee members include:
• Monitor project budget, scope and schedule
• Commit required resources to the project
• Maintain congruence between FSRP and other associated initiatives
• Monitor the Risk Management Plan and Mitigate Risks
• Assess organizational impacts and act as change leaders
• Empower the core project team to make decisions
• Resolve escalated issues
• Generate timely decisions, supporting Project Management to accomplish the project goals
• Sign-off of phase milestones
• Recommend whether or not the system should go live.
The IBM and UC Project Managers attend Executive Steering Committee meetings.
4/29/2004 12 of 87
3.6.2.4 IBM Project Executive
The IBM Project Executive (PE) has overall IBM executive responsibility for IBM’s performance on the
project. The PE oversees the quality delivery of services to the project, and works with University
Executive Management to provide oversight for the project. The Project Executive is responsible for
overall contract management, staffing, financial plans, customer satisfaction and issue resolution. The
IBM Project Executive is authorized to act on behalf of the IBM Corporation in reaching agreements with
UC.
The IBM PE shares overall executive management with the UC Project Sponsors, with parallel
responsibilities including:
• Ultimate owner of IBM’s performance including resource performance and quality of deliverables
• Serves as counsel to the UC Project Sponsors to minimize risk and facilitate the acceptance of
change
• Promotes the FSRP project throughout the IBM organization.
The IBM Project Executive is a member of the Executive Steering Committee, and participates in steering
committee meetings.
3.6.2.5 UC Project Manager
The UC Project Manager (PM) owns the project deliverables and is responsible for day-to-day project
management. The PM is the primary liaison with the Steering Committee. The FSRP project will have two
UC Project Managers – a Technical PM and a Business Process PM. For responsibilities that encompass
both the technical and process domains (e.g. process decisions that impact technical scope or vice
versa), the UC Business Process PM will be the lead UC Project Manager.
The UC Project Manager responsibilities will be shared between the UC PM and the IBM PM, and will
include:
• Definition of the implementation strategy
• Preparation and maintenance of the project plan, project budget, work plan, and project charter
• Supervision of project activities and production of all deliverables
• Acquisition, assignment and ongoing management of project resources
• Communication of project status to the Executive Steering Committee, Project Sponsors, and the
Project Team
• Resolve/escalate project issues.
The PM must proactively anticipate project deviations and be responsible for taking immediate corrective
action. It is also the PM’s responsibility to obtain an understanding of the overall SAP business process
integration in the University’s environment – the PM must be able to participate in blueprinting UC’s
business processes.
The PM participates in the Executive Steering Committee and Sponsors Meetings. The PM participates
as an active member of the Change Management Team.
3.6.2.6 IBM Project Manager
The IBM Project Manager assists the UC Project Manager in the definition and execution of project
deliverables and the day-to-day management of the entire project. The IBM Project Manager is the main
liaison between the Team Leads and the Executive Steering Committee. The responsibilities of the IBM
Project Manager include:
• Providing methodology guidance for implementation approach
• Assisting project management and project team in understanding the implementation approach
• Aiding in the definition of project deliverables and critical target dates to be reflected in the project
plan
4/29/2004 13 of 87
• Assisting in the definition of project scope and objectives
• Aiding in the resolution of issues when necessary
• Assisting project managers, consultants, and individual teams when necessary in the execution of
activities and the production of deliverables.
The IBM Project Manager must proactively anticipate project deviations with the UC Project Manager,
communicate such deviations when appropriate to Executive Steering Committee members and Project
Sponsors and facilitate taking immediate corrective action.
The IBM Project Manager is responsible for the ongoing management of IBM resources assigned to the
project and for the tracking of the IBM consulting budget.
The IBM Project Manager participates in the Executive Steering Committee and Sponsors Meetings.
3.6.2.7 Project Administrator
The Project Administrator assists in providing project support through ownership and management of
project documentation, project applications and the facilitation of project team communications and
processes. This role involves managing some project related metrics, such as the percentage of tasks
completed, the quality, cost and time involved in project planning.
The Project Administrator is responsible for providing administrative support to the project at the direction
of the Project Manager(s).
3.6.3 Business Process
3.6.3.1 Business Process Team Lead
The Business Process Team Lead (PTL) is responsible for the process areas and the project
deliverables, along with day-to-day management of the business areas. The PTL ensures that combined
output from individual process areas is integrated to provide an effective overall solution. The PTL works
with the Project Manager to develop and manage scope, assign and schedule resources, and to monitor
deliverable progress. The PTL is responsible for identifying the impacts and requirements for the
business processes to support the organization’s “To-Be” vision within the SAP System, and for verifying
that the business objectives are being met by the Project Team.
The PTL manages the effort to analyze and document the decomposition of the University’s business
processes, and directs and works with the business process team members, owners, and users to:
• Develop the business design
• Configure the system and validate the design
• Test and document the implementation
• Obtain buy-in from both the business process owners and users
• Ensure that the business objectives are being met by the process team.
The PTL also manages the execution of testing (per the Statement of Work), including:
• Working with the project team to identify mission critical business process scenarios
• Identifying transactions and data to be tested; managing expected results versus actual results,
and reasons for differences
• Coordinate test case review with business units /users
• Assigning follow up tasks to re-configure and retest
• Tracking of error resolution.
The PTL conducts workshops and presentations to validate business processes and solutions with the
user community, in conjunction with the business process team members.
4/29/2004 14 of 87
In addition, the PTL works closely with the technical team in the design and development of reports,
forms, interfaces, and conversions. The PTL may also execute both the detailed design and the
configuration of the SAP System.
The PTL should also ensure the transfer of skills between consultants and UC team members.
3.6.3.2 Business Process Team Member
The Business Process Team Member (PTM) is responsible for the execution of the detailed design and
configuration of UC’s business processes within the SAP System. This includes working with the PTL in
the analysis and decomposition of the business processes, documenting the business process
requirements, and designing and configuring the SAP System to support the organization’s “To-Be”
process vision. The PTM should also aid in the design of reports, forms, interfaces, and conversions. The
PTM is also involved in system unit and integration testing. This includes performing the test, making
changes in configuration based on results, and error resolution.
The PTM should conduct workshops and presentations to validate business processes and SAP solutions
with the user community. The PTM is responsible for working with the user documentation developers
and trainers in the identification of business processes, and SAP technical system tasks to be
documented. The PTM will be the primary source of Super Users who will provide support in the first few
months after implementation, as well as implementing future releases of the software.
Responsibilities of the Business Process Team Members include:
• Obtain a detailed knowledge of SAP for their specific process area, and a sound understanding of
how it interacts with other areas
• Gain a clear understanding of project scope and objectives
• Specify the requirements for business processes to support the organization’s "To-Be" vision with
the SAP system
• Develop, document and test the functional design
• Define scripts of business process flow as a basis for SAP configuration
• Create the detailed design and configuration of the SAP system in support of their functional area
• Design simple forms and reports
• Identify mission critical scenarios and data objects to be tested
• Create scripts for and executes unit testing and integration testing
• Identify, resolve or escalate issues
• Conduct or participate in workshops and presentations to validate business design with the user
community in conjunction with the business process team members
• Assist the end user documentation team in the identification of business processes and system
tasks to be documented
• Assist in developing and providing training to the end users and development resources
• Provide post-implementation production support.
3.6.3.3 Business Process Owner
The Business Process Owner (BP Owner) owns the business process from a strategic point of view and
is responsible for its automation in the new FSRP system. The BP Owner works directly with the Business
Process Team Lead (PTL) and team members to communicate the success factors associated with the
BP Owner’s business process areas. The BP Owner is responsible for approval of the SAP solution for
their assigned business area(s). The BP Owner is usually a member of UC’s senior management, for
example – Controller, Vice President, Purchasing Director, etc. The BP Owner can also be an Executive
Steering Committee member.
BP Owner primary responsibilities are to:
4/29/2004 15 of 87
• Ensure the business objectives are met by the SAP System
• Work with the PTL to validate the “To Be” view of the business processes
• Participate in Change Management activities
• Commit, and ensure the participation of, Subject Matter Experts from their business areas
• Identify, resolve and/or escalate project issues
• Develop and execute the transition plan for team members moving to/from their non-project jobs
• Approve and sign off the validity of converted data
• Approve the plan for, and successfully execute, User Acceptance Testing.
3.6.3.4 Application Consultant
The Application Consultant (AC) provides SAP software expertise. The AC effectively transfers SAP
design and configuration knowledge to both Business Process Team Leads and other team members.
The AC also acts as an advisor and aids the project team in all tasks, as necessary.
Responsibilities of the Application Consultant include:
• Plan and execute the development, documentation and testing of the functional design
• Plan and execute the design and development of reports, forms, interfaces and conversions
• Plan and executes the creation of the detailed design and configuration of SAP in support of their
functional area
• Assist in the identification of mission critical scenarios and data objects to be tested
• Assist in the creation of scripts for, and execution of unit and integration testing
• Identify, resolve and/or escalate issues
• Conduct or participate in workshops and presentations to validate business design with the user
community in conjunction with the business process team members
• Provide implementation experiences from other SAP installations to aid in the design process
• Assist the project team in all tasks as required.
3.6.4 Subject Matter Expert (SME)
Subject Matter Experts are involved in the project on a temporary basis to provide process-specific
requirements and knowledge when necessary. The primary role of the SME is to assist the core project
team to ensure the final implementation efficiently and accurately supports UC’s business processes. To
this end, the SME works closely with the Business Process Team.
Responsibilities of SME’s include:
• Locate and provide all necessary documentation requested by Functional and Integration Test
teams for the successful completion of the implementation
• Participate in workshops and presentations to validate the business design and business rules
being implemented
• Define sources of data and business rules for data conversion and interfaces
• Assist in defining and reviewing test scenarios and aid in writing test scripts to exercise the new
system and data
• Participate actively in user acceptance test
• Participate in change management activities as required
• Participate in the definition of end user training requirements and materials for their particular
area of functional expertise.
4/29/2004 16 of 87
3.6.5 System Infrastructure
3.6.5.1 Infrastructure Team Lead
The primary responsibility of the Infrastructure Team Lead (ITL) is to manage the completion of all
technical project deliverables. The ITL must be able to work with the Project Manager to complete the
technical requirements planning, and to plan and manage the technical scope and resources schedule.
Other responsibilities include communicating and providing day-to-day technical direction of the project,
including detecting project deviations, and being responsible for taking immediate corrective action;
developing and managing the Cutover Plan, and acting as the communication link to the Business
Process Team and other IT organizations within the University.
3.6.5.2 Infrastructure Architect
The Technical Architect is responsible for the overall technical architecture of the SAP System. The
Technical Architect receives direction from, and reports to, the Technical Team Lead.
3.6.5.3 Infrastructure Team Member
The primary responsibility of the Infrastructure Team Member (ITM) is to provide guidance and advice for
all technical aspects of the SAP implementation project. The ITM must work with the Project Manager and
the Technical Team Lead to complete the technical requirements planning, and then to carry out the
technical SAP System tasks.
Other responsibilities may include:
• Providing technical day-to-day direction for the project, including detecting project deviations, and
taking immediate corrective action
• Perform system and database administration activities
• Developing and managing the Cutover Plan, prior to go live and production start up
• Identify, resolve and/or escalate issues
• Acting as the communication link with the Business Process Teams and other IT organizations.
The Technical Team Member can be a consultant for one or more areas, such as SAP System
Administration, Database Administration, Network Administration and Operating System Administration.
3.6.5.4 System Administrator
The SAP System Administrator is responsible for:
• Providing day-to-day SAP BASIS support
• Configuring, monitoring, tuning, and troubleshooting the SAP technical environment on an
ongoing basis
• Performing checks, tasks, and backups within the technical environment
• Scheduling and executing the SAP Transport Management System (TMS) and Computing Center
Management System (CCMS)
• Managing and executing SAP installations, upgrades and system patches.
• Operating system installation, upgrades, patches, backups, performance and tuning
• Security for the operating system environment.
3.6.5.5 Network Administrator
The Network Administrator is responsible for:
• Network planning, installation, upgrades and patches
• Network security, and the ongoing management of the OSS connection
4/29/2004 17 of 87
• Network connections to front-end systems, printers, routers and both application and database
servers.
3.6.5.6 Authorizations Consultant
The Authorizations Consultant is responsible for managing the SAP security and authorization
environment. Responsibilities include:
• Design and document standards and procedures for SAP user/account administration
• Profile creation and maintenance
• Authority management for the associated SAP environment for interfaces.
The Authorizations Consultant works closely with the Business Process Team and under the joint
direction of the Business Process Team Lead and the Technical Team Lead to ensure authorizations are
integrated with business processes and system roles.
3.6.5.7 Database Administrator
The Database Administrator’s primary areas of responsibility are:
• Database configuration and tuning
• Backup and recovery management
• Database growth management
• Database security
• Support other technical initiatives – e.g. BASIS activities – as required.
3.6.6 System Development
3.6.6.1 System Development Team Lead
The System Development Team Lead works with the Project Manager(s) to estimate, plan, and manage
the system development aspects of the project. The System Development Team Lead is responsible for:
• Identifying the critical system development milestones and ensuring that they are included in the
overall project plan
• Identifying requirements with the Business Process Team for development effort (e.g.
conversions, interfaces, reports, etc.) and participating in the development of the data conversion
strategy
• Managing the process of data conversion, interfaces, reports and SAP user exits development as
well as the development of cross-application components etc.
• Ensuring that adequate documentation is produced for system and application development tasks
• Working closely with the project manager to define standards for project and documentation,
including TMS, ABAP/4, etc.
• Provide technical development assistance and guidance to the System Developers
• Participate in Go-Live (cut over) plan development, testing and execution.
Depending on the size and complexity of the implementation, this person can also perform the Systems
Developer role.
3.6.6.2 System Developer
The System Developer is responsible for the data mapping, design, development, and testing of
conversion programs, interface programs, ABAP enhancement programs, SAPScript, ABAP custom
reports and forms, system integration and data warehouse support. The System Developer works with
the System Development Team Lead in the management and documentation of the development
projects, including definition of development standards and policies. The System Developer may also
assist the System Development Team Lead in the development of a Production Support Plan for the
custom development.
4/29/2004 18 of 87
3.6.7 Change Management
3.6.7.1 Change Management Team Lead
The Change Management Team Lead assists Project Management in assessing, planning and executing
change management activities. The Change Management Team Lead is responsible for managing the
Change Management Team, executing Change Management activities and producing Change
Management deliverables.
3.6.7.2 Change Management Team Member
The role of the Change Management Team Member is to determine where and how the implementation
of the FSRP System will affect the organization and identify and execute strategies and plans that will
minimize organizational impact and improve the acceptance and adoption of the new system.
Change Management team members are responsible for developing and executing change management
activities and producing change management deliverables. In this role they will:
• Plan and assess the organizational impact of the ERP system,
• Establish appropriate organization metrics to track change effectiveness and adoption
• Assess organization change readiness
• Assist in the definition of organizational roles and responsibilities
• Perform stakeholder analysis
• Define and execute a communications plan that includes all internal and external project-related
communication.
3.6.8 End User Training
3.6.8.1 End User Training Team Lead
The End User Training Team Lead assists Project Management in planning and developing the end user
training strategy. The End User Training Team Lead responsibilities include:
• Create the Project Team Training Plan
• Create the End User Training Strategy
• Create Training Standards, Templates and Prototypes
• Manage and participate in the execution of training strategies and plans.
3.6.8.2 End User Training Team Member
The End User Training Team Member is responsible for developing and executing training activities and
producing training deliverables at the direction of the End User Education Team Lead. Responsibilities
include:
• Undertake an end user assessment
• Develop training standards prototypes and templates
• Develop training materials
• Conduct training classes and workshops
• Provide Train-the-Trainer education to other UC staff as required
• Work with Project Team Members to ensure training activities are aligned with business
processes and rules contained in the SAP solution
• Co-ordinate with the Change Management team to ensure training and change management
activities are aligned.
4/29/2004 19 of 87
3.6.9 Quality Assurance
3.6.9.1 IBM Quality Assurance
The IBM Quality Assurance (IBM QA) is responsible for project quality assurance through the execution of
the Quality Review Program (QRP), and by encouraging the proper use of processes and methodologies
to maximize quality throughout the project lifecycle. The IBM QA will review the project on a regular basis,
in accordance with the project status and profile.
IBM QA reviews will focus on the following areas: scope management, issue management, project
management, client management, third party management, project approach, methodology and
technology, economics, estimates and scheduling, staffing and closure.
3.6.9.2 UC External Auditor
The UC External Auditor is responsible for assessing and evaluating the FSRP project’s compliance with
application, data or technical standards, controls and procedures. The UC External Auditor communicates
findings and recommendations to the UC Audit Committee and copies Executive Steering Committee and
Project Management.
3.6.9.3 UC Internal Auditor
The UC Internal Auditor is responsible for assessing and evaluating the FSRP project’s compliance with
application, data or technical standards, controls and procedures. The UC Internal Auditor communicates
findings and recommendations to the Steering Committee and Project Management. Responsibilities
include:
• Ensuring the presence of adequate internal controls (technical and process)
• Ensuring the presence of adequate security and authorizations
• Ensuring the presence of audit trails
• Reviewing business process procedures
• Reviewing the reconciliation results of data conversion.
4/29/2004 20 of 87
4 Project Scope
4.1 Organizational Scope
The purpose of defining the organizational scope is to confirm the organization and geographic areas that
will be included in the FSRP implementation.
4.1.1 Overview
The University is located on three campuses in southwest Ohio. These include the main academic
campus which includes the West Campus, East Campus (Medical Center), a branch campus located in
Blue Ash (Raymond Walters College), and a branch campus located in Clermont County (Clermont
College).
The primary business of the University of Cincinnati is higher education and their customers are students.
The University is comprised of 17 colleges and divisions offering more than 450 degree programs from
the associate to the doctoral level. The University’s enrollment is approximately 34,000 students.
The University employs approximately 2,535 full-time faculty members, 2,160 part time faculty members,
4,179 full and part time staff, and 6,366 student workers and graduate assistants for a total of 15,240
people. The University has an annual payroll of approximately $356.7 million.
4.1.2 Organizational Scope
4.1.2.1 Campus Locations
The University of Cincinnati is comprised of the following campuses:
Campus Nature of Activity Location
University of Cincinnati – Main West Campus – Main academic campus Cincinnati, OH
Campus East Campus – Medical Center
Clermont College Branch campus offering Associate Degree and Certificate programs Batavia, OH
Raymond Walters College Branch campus offering Associate Degree and Certificate programs Blue Ash, OH
Business units that are accounted for in CUFS such as the Hoxworth Blood Center and Genome Institute
are included within the scope for the Medical Center.
4.1.2.2 UC Foundation
The University of Cincinnati Foundation is the private sector (non-government) fund-raising entity for the
University of Cincinnati and its campuses, colleges, departments and units.
The University Foundation is included in the scope of the project for purposes of supporting the annual
financial reporting requirements.
4.1.2.3 Business Areas
For management reporting the University is divided into the following segments:
Business Area Description
010 President
030 Senior VP/Provost
040 Senior VP/Provost Health Services
4/29/2004 21 of 87
Business Area Description
050 VP Administrative Services
060 VP Finance/Treasurer
070 VP Public Affairs
080 VP University Dean/Graduate Studies/Research
090 VP Development/Alumni Affairs
100 University Hospital Agency Units (HAGC/UH)
110 Raymond Walters College
115 Clermont College
120 AVP for Human Resources
130 UCit
140 Public Relations
150 University Plant Funds
150 VP Student Affairs and Services
190 University Unassigned
4.1.2.4 Departmental Units
The University currently has numerous organization codes. Organization codes are used to represent
individual colleges or functional units in CUFS as well as grants and contracts and are present on all
revenue and expense transactions.
Current Organizations Organization Names
01XX – 02XX Student Groups
03XX College of Arts and Sciences
04XX College of Business Administration
05XX College of Education
06XX College of Engineering
08XX College of Design, Art, Architecture, and Planning
09XX College Conservatory of Music
11XX College of Law
12XX –13XX College of Medicine
14XX College of Nursing
15XX College of Pharmacy
16XX College of Allied Health Science
17XX Graduate
18XX University College
19XX School of Social Work
21XX College of Evening and Continuing Education
22XX Summer Session
23XX Collateral Departments
24XX Clermont College
25XX Raymond Walters College
26XX Clermont College Summer Session
27XX Raymond Walters College Summer Session
28XX Ohio College of Applied Science (OCAS)
4/29/2004 22 of 87
Current Organizations Organization Names
29XX Research Labs
31XX Public Service
32XX Academic Support
33XX Academic Administration
34XX – 35XX Student Services
36XX – 37XX Institutional Support
38XX – 39XX Operation and Maintenance of Plant
4XXX Hospital
50XX – 54XX Residence Halls
55XX University Health Services
56XX University Conferencing
58XX Campus Services
61XX – 65XX Food Services
66XX – 69XX Tangeman University Center
70XX – 75XX Bookstore
76XX – 79XX Athletics
81XX – 84XX Shoemaker Center
85XX – 87XX Parking
A000 - F999 Grants and Contracts (Non-Letter of Credit)
G000 - W999 Grants and Contracts (Letter of Credit)
4.1.2.5 Function
The University utilizes a 4-digit function code to identify the nature of the activity by organization. The first
1-2 digits represent the nature of activity while the last 2-3 digits can represent the organization. Function
codes are only used on expense transactions.
Current Functions Function Names
0XXX Instruction
1XXX Research
2XXX Public Service
3XXX Academic Support
4XXX Student Services
5XXX Institutional Support
6XXX Operation and Maintenance
7XXX Scholarship and Fellowship
80XX Residence Halls
81XX Residence Dining Halls
8200 University Center
83XX Bookstore
84XX Athletics
85XX Parking
9XXX Hospital
4/29/2004 23 of 87
4.2 Process Scope
4.2.1 Objectives
The FSRP system will utilize a variety of productivity-enhancing features, be accessible via the web on a
workstation and will allow each user to customize their work environment by saving default settings based
on the user’s role. The system has the capability to provide electronic workflow functionality to allow for
movement of financial documents between departments and electronic approval. Workflow functionality
will be evaluated for adoption after the core financial system is in production.
A major objective of a new system is to reduce reliance on ancillary systems, the re-keying of data,
maintaining sidecar systems and the dumping of data into separate spreadsheets or database software
for ad hoc reporting and managerial reports.
Data must be available so as to allow for web-based queries and ad hoc reporting at the departmental
level and incorporating distributed print capabilities. This will provide more timely electronic distribution of
reports and ease in developing customized ad hoc reports. In addition, reduced printing time and costs
along with the numerous steps required both at the central and departmental level for the manual
distribution of reports will occur. Eradicating inefficient, less effective and costly work arounds will also be
realized.
4.2.2 Financial Structure - Legal Entities and Statutory Reporting
The University of Cincinnati has been designated by the Ohio Board of Regents as one of only two
comprehensive graduate public universities in the State and is a component unit of the State of Ohio. The
University of Cincinnati includes a not-for-profit corporation – the University of Cincinnati Foundation. The
University of Cincinnati Foundation was established in 1975 and assures donors that their gifts are used
in accordance with their intentions. The University has adopted GASB Statement 35, as amended by
GASB Statements 37 and 38. Balance sheets are prepared annually at the legal entity and fund level.
Statements of revenue, expense and changes in net assets are prepared annually by operating and non-
operating revenue and expense. In addition, a quarterly report of revenues and expenses is prepared for
the Ohio Board of Regents, and an annual CAFR is prepared for the State of Ohio.
4.2.3 Current Environment
The CUFS system is a mainframe-based Finance System that was originally purchased in 1985 from
American Management Systems. The Purchasing Department and the Office of the Controller manage
the system, and over 770 Departmental Users update or use the system. CUFS interfaces with HRMS,
UniverSIS, term contact management system, investment pool system, and various service department
systems. CUFS main functions are budgeting, payroll accounting, procurement accounting with
encumbrance control, disbursements and financial accounting and reporting. The system processes
approximately 5 million ledger transactions annually.
4.2.3.1 General Ledger
General ledger accounting is decentralized by legal entity. University of Cincinnati transactions are
processed in the CUFS system. This ensures that all financial activity is recorded in the CUFS general
ledger, balanced and posted to valid accounts. University of Cincinnati Foundation transactions are
processed in a separate system and periodically combined with the University for financial reporting
purposes outside of the CUFS system. All entities are on a July 1 – June 30 fiscal year accounting cycle.
The CUFS system provides internal monthly financial management reports and data for external reports,
including the consolidated annual audited financial statements and State of Ohio and Federal financial
reports. CUFS also provides tables and converted history tables and ledgers for ad hoc reporting and
data downloads.
4/29/2004 24 of 87
4.2.3.2 Accounts Receivable
The University has a centralized Accounts Receivable Department. Departments send Customer Invoice
Request forms to the Controller’s department who is responsible for creating invoices in CUFS and
maintaining the customer master records. The Accounts Receivable Department prints and mails
approximately 250-300 customer invoices twice each month. Customers send their remittances to a
central lockbox. Remittances are manually applied against open items on customer accounts. There are
approximately 1500 active customers in CUFS.
4.2.3.3 Accounts Payable
The University has a centralized Accounts Payable Department and uses a three way match (purchase
order, receiver and invoice) for purchase order items to determine invoices to be paid. The Accounts
Payable Department processes 3,600 – 4,800 vendor invoices, and 1,400 – 1,600 travel expense
reimbursements and independent contractor payments each month. Vendors are paid by check on pre-
numbered check stock that is mailed from the Controller’s Office. Check runs are processed daily.
However, approximately 300 manual checks are generated each month which the University intends to
discontinue. The University utilizes positive pay and the bank provides a daily file of paid checks. Manual
intervention is required in order to make wire transfer, ACH and foreign currency payments. The
University has a purchasing card program administered through MBNA. The purchasing card program
has approximately 1100 active users who process about 11,000 transactions per month. The University
has approximately 49,000 active vendors (regular, library disbursement, one-time, and independent
contractors).
4.2.3.4 Fixed Assets
Asset accounting at the University is decentralized. Detailed fixed assets records are maintained in
databases outside of CUFS by several different departments. The Construction Management Department
manages land, land improvements, buildings, infrastructure (roads/tunnels), and construction in process
assets valued at $1.5 billion using an Access database. The Art Director manages fine art assets valued
at $5 million using a Paradox database. The University Library manages library book assets valued at
$118 million using a Euclid database. The Space Management Department manages moveable capital,
moveable non-capital, US Tag/Non-UC Title, and building equipment assets valued at approximately
$216 million using an Access database. The University uses a limited number of asset classes.
Depreciation is manually calculated and posted in CUFS by journal entry. The University periodically
disposes of assets by demolition, scrapping, transfer to surplus property or sales.
4.2.3.5 Cost Accounting
The University uses various elements of their account coding structure to capture expenses for cost
accounting and management reporting purposes. The ORGN code is used to identify the college and
department incurring the expense. The first 1-2 digits of the FUNCTION code are used to identify the
nature of the activity being performed. The last 2-3 digits of the FUNCTION code can also identify the
department performing the activity. Cost transfers are processed in CUFS using unique general ledger
accounts. Currently, the University does not capture revenues by organization or nature of activity.
4.2.3.6 Project Accounting and Capital Finance
The University has a centralized Construction Management and Capital Finance function. This
department is responsible for all project management and accounting activities. Project planning is done
using Primavera which the University plans to continue using. Each project is represented by a plant fund
in CUFS. Each month project revenue and expenses are downloaded from CUFS to an Access database.
All project and capital finance reporting is done through Access. The University has approximately 200
active projects.
4.2.3.7 Grants
Grants management at the University is decentralized. Departments prepare grant proposals and submit
applications through the Office of Sponsored Programs (OSP). The University is currently evaluating the
implementation of the COEUS system to manage grant pre-award activities. Grant Administrators in the
4/29/2004 25 of 87
Sponsored Program Accounting (SPA) Office are responsible for all grant accounting and reporting
activities. They establish grant account numbers, prepare grant billings, execute letter of credit draw
downs, manually post grant accounts receivable/cost transfers/adjusting entries in CUFS, prepare internal
and external reports, and handle final account reconciliation and close out. Overhead is automatically
applied to grants based on rates specified in the grant award and loaded in CUFS. Budgetary spending
control is exercised by fund and expense object based on the terms and conditions of the grant. The
University has approximately 1200 grants.
4.2.3.8 Endowment Accounting
The University maintains endowment funds in multiple investment pools with unit based accounting for
distribution functions.
4.2.3.9 Purchasing
The University has a centralized purchasing function that is used for all University funded purchases. The
Purchasing Department handles over $300 million in purchases annually including construction bid
awards. Each year they bid out Term Contracts and process Rental, Service, Maintenance and Lease
Agreements.
4.2.4 SAP Scope
The following business processes are in scope for the UC project:
• General Ledger/Special Ledger
• Funds Management
• Accounts Payable
• Accounts Receivable/Revenue Management/Cash Management
• Asset Accounting/Capital Finance
• Controlling/Cost Accounting
• Grants Management
• Project Systems (including Capital Finance)
• Purchasing
• Budget Preparation (SEM/BPS)
• Endowment Accounting
• Business Information Warehouse
• Enterprise Portal.
4.2.4.1 General Ledger/Special Ledger
• Record all financial transactions into the ledger (revenues, expenses, assets & liabilities,
encumbrances and budget).
• Assure that transactions are balanced and that they are posted to valid accounts.
• Chart of Accounts
• Automatic and simultaneous posting of sub-ledger items in the appropriate general ledger
accounts (reconciliation accounts)
• Journal voucher processing
o Direct Entry
o Spreadsheet Upload
• Record Purchase Card Accounting Entries from 3rd Party
• Closing Operations
• Provide standard financial reports
4/29/2004 26 of 87
o Account Line Item Analysis
• GASB 34/35 Reporting
4.2.4.2 Funds Management
• Funds Master Records
• Commitment Items
• Record Original Budget (feed from SEM)
• Budget Reserves
• Budget Adjustments/Transfers
• Budget Supplements
• Encumbrance Recording and Tracking
• Budget Control System (BCS) – Prototype only
• Year end Close Operations
4.2.4.3 Accounts Payable / Capital Finance
• Centralized Vendor Master Management
• Invoices (P.O. related and Direct Invoice Entry)
• Invoice Adjustments (Credit/Debit Memos)
• Use three way match (purchase order, receiver and invoice) to determine what invoice lines
should be paid.
• Vendor Down Payments/Cash Advances
• Vendor Payments (Manual, Check, Wire Transfer, ACH) including daily payment runs
• Payment Proposals
• Positive Pay
• Warrant Clearing
• Vendor Account Analysis, Aging and Clearing
• 1099 Processing
4.2.4.4 Accounts Receivable/Revenue Management
• Centralized Customer Master Management
• Centralized/Limited Decentralized Billing
o Government Contracts, Service Invoices, Rent Invoices
o Internal Billings (Direct expenditure transfers, Recovery expense)
o Recurring Invoicing
• Billing Form (one format / different text based on department)
• A/R Adjustments (Credit Memos / Debit Memos)
• Customer Payments
o Cash Application (manual application of lockbox activity)
o Short payments
o Overpayments
• Miscellaneous Cash Receipts (Cash, Check, Credit Card)
o Direct Entry
o Spreadsheet Upload
• Customer Account Analysis
• Customer Account Aging
4/29/2004 27 of 87
• Collections
• Write-off Uncollectible Receivables
4.2.4.5 Cash Management
• Bank Account Management
o Bank Master Data
o Bank Deposit Slips
o Check Management (Reversals, Voids, Reissues)
o Cash Journal
• Cash Management
o Check deposits
o Cash and Liquidity Forecasting
4.2.4.6 Asset Accounting
• Centralized Asset Master Record Management
o Asset Classes
o Asset Masters
o Assets Under Construction
o Sub-Assets
o Leased Assets
• Asset Acquisitions
o External Acquisition with Vendor
o Acquisition from Internal Activity (Donated Assets, Transfers In)
o Capitalization of Assets Under Construction
• Asset Retirements and Transfers
o Retirement with Revenue (Sale)
o Retirement without Revenue (Scrapping, Donations)
o Intra-company Asset Transfers
o Gain/Loss on Retirement
• Physical Inventory of Assets
• Depreciation
o Depreciation Areas (Modified Accrual and Full Accrual)
o Depreciation Method (Straight Line over Useful Life)
o Mid-Year Convention
o Planned/Unplanned Depreciation
• Asset Reporting
o Asset Explorer
o Asset Activity Reports (Additions, Transfers, Retirements)
• Capability for GASB and OMB Circular A21 compliance
4.2.4.7 Controlling/Cost Center Accounting
• Cost Centers
• Cost Center Groups
• Cost Center Hierarchies
• Cost Elements (Revenue and Expense)
• Allocations
4/29/2004 28 of 87
4.2.4.8 Grants Management
• Grant Master Data Management
o Sponsor Masters
o Grant Masters
o Sponsored Programs
o Sponsored Class
• Life Cycle Status Management
• Grant Sponsored Budget
• Grant Availability Control
• Grant Accounting
o Track multi-year grant projects with encumbrances, expenditures, cost allocations, revenues,
journal vouchers, and balance sheet and budget transactions
• Cost Sharing Rules
• Application of Indirect Costs
• Record labor costs
• Grant Billing
• Receivables Tracking
• Records Management
• Grant Closeout
• Grant Accrual (Year end)
• Reporting (BW)
4.2.4.9 Project Systems
• Project Master Data Management
o Project Definition Masters
o Work Breakdown Structure Elements
• Life Cycle Status Management
• Project Planning
• Project Budgeting
• Project Availability Control
• Project Accounting (Encumbrances, Expenditures, Revenues, Journal Vouchers)
• Application of Overhead Costs
• Record labor costs
• Project Closeout
• Project Accrual (Year end)
• Reporting (BW)
4.2.4.10 Purchasing
• Purchase Requisitions
• Purchase Orders
• Contracts
• Request for Quotations (RFQ)/Quotations
• Goods Receipts
• Invoice Verification
• Material Master Maintenance (Commodity file)
4/29/2004 29 of 87
4.2.4.11 Budget Preparation (SEM/BPS)
• Organizations Hierarchies
• Versions
• Characteristics
• Key Figures
• Budget Planning
• Position Budgeting
• Planning Methods (Manual, Copy, Top Down/Bottom Up Distribution, Revaluations)
o Planning Areas
o Parameter Sets
o Planning Levels
o Planning Packages
o Planning Layouts (6) - Revenue, Expense, Position for High Level Plan, Detail Plan and
Operational Plan
• Calculation Rules (25 maximum)
o 5 High (5 days each configuration effort)
o 10 Medium (3 days each configuration effort)
o 10 Low Complexity (1/2 day each configuration)
• Budget Retraction to Funds Management
• Reporting – 25 BW Reports
4.2.4.12 Endowment Accounting
• Business Partner Management and Reporting
• Investment Management and Reporting
o Money Market
o Derivatives
o Securities
o Loans
• Investment Accounting
• Funds Management and Reporting
• Market Risk Analyzer
o Mark-to-Market Valuations
• Electronic Bank Statement Processing
4.2.4.13 Business Information Warehouse
An integral part of the solution is the reporting and analysis capability of the SAP Business Information
Warehouse (BW) system. BW will enable easy access to data for users of varying skill levels and provide
the capability for ad hoc query, drill-down, trending, and comparative analysis such as actual to budget
and prior year to current year.
BW is delivered with pre-configured objects – InfoCubes, Queries, Reports, Roles, R/3 Extractor
Programs, Web Templates, etc – collectively known as “Business Content”. Pre-configured business
content as provided by SAP will be leveraged to the extent possible.
New business content will be necessary in the areas of grants management, project accounting, special
ledger and historical data. The solution includes two InfoCubes for each of the following six areas (twelve
configured InfoCubes in total):
• General Ledger
4/29/2004 30 of 87
• Accounts Receivable
• Accounts Payable
• Funds Management
• Purchasing
• Asset Accounting.
In addition to the InfoCubes above, one new InfoCube in each of the following four (4) areas will be
configured:
• Strategic Enterprise Management (Budget)
• Grants Management
• Project Systems
• Special Purpose Ledger.
In addition to the sixteen (16) InfoCubes, UC will evaluate the integration of HummingBird’s BiWEB
product with the SAP BW data warehouse.
4.2.4.14 Enterprise Portal
SAP Enterprise Portal deployment will include the standard out-of-the-box SAP portal functionality.
The approach is to create a web-based, role-based front-end for the underlying SAP systems, leveraging
key portal functionality such as single sign-on and role-based functionality.
The initial benefits of the deployment of the SAP Enterprise Portal for UC are to manage end user
access, integrate other University financial Web applications and to lay the foundation for future
development and customization. During the core financial management system implementation, the SAP
Enterprise Portal will be deployed to support only UC employees and project team members with web
and SAP access, which will provide a prototype for its effectiveness as a communications tool.
4.3 Technical Scope
4.3.1 Extended SAP Functionality and Bolt-Ons Scope
Bolt-Ons refer to external software systems that are integrated with the SAP system. During the scoping
study exercise the following Bolt-Ons were identified and are included in the implementation:
Bolt-Ons
SAP
Bolt-On Description Frequency In Out Complexity
Hyland - OnBase (six different query Daily and Interactive X Very High
requests) (Real-time)
Get IT Web Application Daily and Interactive X High
(Real-time)
UC Data Warehouse & SAP BW Daily and Interactive X X Very High
Integration (Real-time)
In addition to the Bolt-Ons identified above, the FSRP team will:
• Investigate the inclusion and use of Dunn and Bradstreet software for vendor classification
• Evaluate an SAP-certified Auto Fax Partner to support the SAP R/3 Core purchasing solution.
4.3.2 Technical Infrastructure Scope
Technical infrastructure scope covers building and supporting the SAP landscapes for R/3 Enterprise,
SEM/BW and Enterprise Portal from Project Preparation through the Go-Live and Support phases,
including the DB2 database.
4/29/2004 31 of 87
Experience has shown that IBM will lead the building of the Sandbox, Development, Quality
Assurance/Test and Training while UC learns the process, and then UC will take the lead for the building
of the Production landscapes. This provides for optimal knowledge transfer.
IBM will develop a Technical Knowledge Transfer Plan for UC’s Basis and DB2 Administrators along with
assisting UC to determine the strategy for Enterprise Application Integration (EAI). IBM will lead the
development of the User Role and Authorization Design which will be supported by UC’s Central Security
Team and UC SAP Competency Center.
The system landscapes will include:
• Sandbox
• Development
• Quality Assurance/Test
• Training
• Production environments.
The technical infrastructure will include: Output Management, SAP Job Scheduling, Regression Testing,
Stress Testing and Archiving tools. MS Operations Management will be reviewed as part of the Technical
Infrastructure.
4.3.3 Interface Scope
The FSRP team will interface the SAP system with UC systems, where:
• Legacy system refers to UC’s existing databases and applications.
• Interfaces refer to those interactions between information systems that allow data to be passed
from one system to the other in order to keep the disparate information systems synchronized.
The following interfaces have been identified as part of the implementation:
Interfaces
SAP
Interface Description Frequency In Out Complexity
PNC (external to UC) Daily X X
- Positive Pay Low
- Warrant Clearing Low
HR/Flex/Payroll Bi-weekly and Monthly X X Very High
HR Positions to SEM Quarterly X High
Campus Postage Monthly X Medium
Transportation Services Monthly X Medium
Chemistry Monthly X Medium
Student Billing & Receivables Monthly X Medium
Bookstore Monthly X Medium
Duplication Services Monthly X Medium
Telecommunication Services Monthly X Medium
Radiation Safety Monthly X Medium
Office Deport (external to UC) Monthly X Medium
Lab Animal Medicine Monthly X Medium
Medical Center Monthly X Medium
A-21 Effort Reporting Monthly X Medium
Labor History Interface Monthly X Medium
4/29/2004 32 of 87
Pro Value Services (UC Credit Monthly X Medium
Cards)
Position Budgeting Quarterly X Medium
TABS Daily X X Medium
Any Interfaces in addition to those identified above will be identified and evaluated during the Blueprint
Phase.
4.3.4 Data Conversion Scope
FSRP will convert and load legacy data into the SAP system, where:
• Legacy system refers to UC’s existing databases and applications.
• Conversions refer to the loading of data from existing legacy systems into the new SAP
environment, one time only.
The following Conversions have been identified as part of the implementation:
Conversions
Conversion Data Conversion Automated Description
Object Type Method Conversion
Type
Vendor – Master Automated Stage, Load Data will need to be cleansed prior to loading. Data
Federal ID Data enrichment that can be derived with rules will occur
within the load program. Other additional information
will be manually loaded. One time vendors will not be
converted.
Vendor balances will not be converted; Vouchers will
either be paid prior to cutover or remain in CUFS until
the payment cycle is complete. For payment activity
completed in CUFS, summary accounting entries will
need to be made in SAP.
Vendor – Master Automated Stage, Load Refer to Vendor - Federal ID
Independent Data
Contractor
Vendor – Master Automated Stage, Load Refer to Vendor - Federal ID
Library Data
1099 Transacti Automated Load A file of balances by Vendor for calendar year 2005
onal (Jan-June) will need to be provided to support this
conversion from CUFS.
Material Master Master Automated Stage, Load If required, data will be cleansed prior to load. The
Data source of the conversion will be the line items of UC’s
current contracts.
Data enrichment that can be derived with rules will occur
within the load program. Other additional information will
be manually loaded.
Only Basic and Purchasing views will be loaded. No
sales, accounting or inventory related views will be
loaded. Inventory balances will not be loaded.
Purchase Transacti Manual n/a The University will be encouraged to close out any
Orders onal s
open PO' prior to go-live. We will convert the
s
balance of open PO' (no detail)
Open Requisitions will not be converted.
Receipts Transacti Manual n/a Will create goods receipts for open PO’s for which
onal the quantity received is greater than the quantity
invoiced.
4/29/2004 33 of 87
Conversion Data Conversion Automated Description
Object Type Method Conversion
Type
Contracts Transacti Manual n/a Only current, valid contracts will be loaded. Each SAP
on R/3 Core contract will contain line items for only one
vendor. Current contracts can contain multiple
vendors. This will translate into an increase of total
number of contracts while the number of line items
should remain the same.
Bids / RFQ’s Transacti Manual n/a The University will be encouraged to close out any
onal open Bids prior to go-live. We will only convert open
bids.
Customers Master Upload Load If required, data will need to be cleansed prior to
Data loading.
Open Transacti Automated Stage, Load Open Receivables to be converted will need to be
Receivables onal reconciled to the Ledger A/R balance.
Fund Master Upload Stage, Load The Account Code Structure will be defined prior to
Data loading.
Fund groupings and hierarchies may need to be
manually created.
Area Master Upload Stage, Load The Account Code Structure will be defined prior to
Data loading.
Area and Organizations can be combined; hierarchy’s
will be manually created
Organizations Master Upload Stage, Load Refer to Area
Data
Function Master Upload Stage, Load The Account Code Structure will be defined prior to
Data loading.
Objects Master Upload Stage, Load The Account Code Structure will be defined prior to
Data loading.
Sub Objects Master Upload Stage, Load The Account Code Structure will be defined prior to
Data loading.
Revenue Master Upload Stage, Load The Account Code Structure will be defined prior to
Source Data loading.
Ledger Transacti Automated Load Ledger detail including journal vouchers will not be
Balances onal converted. Balance sheet balances may need to be
manually loaded. Fiscal year 2004 will need to be
closed in CUFS prior to converting balances.
Fund Balances Transacti Automated Load Fiscal year 2005 will need to be closed in CUFS prior
onal to converting fund balances
Perm Budget Transacti Automated Load One year of the PERM version details is required to
onal start the Budget process for FY 2006.
Fixed Assets Master Automated Stage, Load Asset book value and cumulative depreciation must
Data/ be available to support the conversion. Total book
Transacti value of Fixed Assets must be reconciled to the
onal Ledger Balance prior to loading.
Project Master Automated Stage, Load The project structures will be defined prior to loading.
Definition Data WBS hierarchies will need to be manually created.
Project Transacti Automated Extract, Load Life to Date Balances for Open Projects at go-live.
Balances onal Detailed project expenditures and revenue will not be
converted.
Grant Master Automated Stage, Load The grant coding structure will be defined prior to
Definition Data loading.
4/29/2004 34 of 87
Conversion Data Conversion Automated Description
Object Type Method Conversion
Type
Grant Balances Transacti Automated Stage, Load Life to Date Balances for Open Grants at go-live.
onal
Grant Detailed Transacti Automated Stage, Load Detailed grant expenditures will only be converted for
Expenditures onal those grants requiring the information for federal
reporting.
Bank Accounts Master Manual n/a
Data
Bank Balance Summary Automated Load Detailed Cash Receipts, Deposits and Outstanding
Balances Warrants will not be converted.
Investment Master/ Manual n/a
Instruments / Data
Balances Summary
Balances
Investment Master Manual n/a
Portfolios / Data
Balances Summary
Balances
Debt Master Manual n/a
Instruments Data
Summary
Balances
Endowments / Master Manual n/a
Balances Data
Summary
Totals
Any Conversions in addition to those identified above will be identified and evaluated during the Blueprint
Phase.
4.3.5 Data Warehousing and Forms Scope
Custom Reports refers to reports developed using the ABAP development environment to meet UC
specific requirements. The project anticipates the majority of UC’s reporting requirements will be met
using standard SAP reports. It is estimated that a total of ten (10) custom reports of medium to high
complexity will be developed. The actual reporting requirements will be identified during the Business
Blueprint phase.
The FSRP project team will design, build and test each custom report. The project team will define the
requirements for the reports and verify the results during unit, integration and user acceptance testing.
Custom reports do not include the implementation of any third party reporting tools (e.g. SQL, Forest and
Trees, other 4th GL reporting package).
The term Custom Forms refers to the Print Workbench forms that will be developed to meet the business
requirements of UC. The project estimates that a total of fifty five (55) forms (fifty Grants Management,
three Purchasing and two Accounts Payable) of low to medium complexity will be developed to meet
UC’s business requirements. The actual form requirements will be identified during the Blueprint Phase.
4.3.6 ABAP Enhancements Scope
Enhancements refer to additional system functionality developed using the ABAP or JAVA programming
languages. Enhancements include activation of special logic utilizing User Exits, new transaction screens,
and custom database tables and access logic. Enhancements do NOT include updates or changes to the
SAP source code.
4/29/2004 35 of 87
The FSRP project recognizes UC’s objective to implement an “off the shelf” solution, on-time and on-
budget, and adopt the best business practices contained in the SAP software with minimal
enhancements. Enhancements, due to their nature as a development activity, are an area that can have
significant impact on schedule and budget if they are not well defined and managed. However, due to the
inherent complexity of the FSRP implementation and the expectation that gaps exist between UC
requirements and ‘out of the box’ SAP functionality, the project anticipates that enhancements will be
required to deliver an optimal solution. The project therefore will adopt a three part approach to enhancing
the core SAP system:
• Include five (5) medium complexity enhancements to provide for anticipated gaps in system
functionality
• Include five (5) high complexity enhancements to provide for endowment functionality
• If additional enhancements are identified during the Blueprint Phase, they will be documented –
including the requirement and level of effort for implementing each enhancement.
This approach is designed to allow UC to assess the Cost-Benefit impact of each enhancement while
minimizing the opportunity for cost and schedule impact.
4.3.7 Control and Security Scope
Security profiles will be defined by the UC SAP Competency Center (Business/Functional Team
members), profiles will be managed by UC’s Central Security Group and the Competency Center will
have staff to authorize users specific profiles based on formal approvals. No profile changes can be made
by the Competency Center. FSRP Security Team Members will undertake SAP training during the project.
4/29/2004 36 of 87
5 Project Strategies
5.1 Overview
The project strategies documented below are designed to provide a framework for developing and
executing detailed implementation plans in a manner that is consistent with the project’s goals. Project
strategies include UC Configuration Cycle, Testing, Data Conversion, Interfaces, Reports and Forms,
ABAP Enhancement, Extended Functionality/Bolt-On, Post Implementation Service and Support, System
Enabler, Capacity Planning, Disaster Recovery, Archiving, Control and Security, Organizational Change
Management and End User Training.
Guiding principles for delivering Project Strategies over the course of the implementation of SAP that will
be applied to each strategy include the following:
• While focusing on the scope of the initial implementation, position the system technically to grow
and expand to meet the future needs of the University
• Identify during the Blueprint Phase the information required by the various strategies to support
the "to be" business processes
• Utilize standard SAP screen displays and pre-delivered reports and forms
• Consolidate and standardize report and screen formats across all UC departments (unless it is a
special legal requirement)
• Business Process Owners will document, create the business justification and present business
case justification for all custom requests and Bolt-Ons and obtain required approvals.
5.2 UC Configuration Cycle Strategy
5.2.1 Overview
Configuration cycles define how we will design, configure, test, validate and redesign business processes
on the SAP R/3 system. The configuration process is iterative and will often take several iterative
attempts at configuring the system before it will support the business requirements. Figure 4 shows a
graphical representation of the iterative configuration process.
Validate
Technical
Configuration
& Design
Validate
Business Process Business Process Configure Relevant
and Procedures and Procedures SAP R/3 Business
Defined Processes &
Refined
Procedures
Validate
Business
Process
Procedures
(BPP' s)
Iterative Feedback Loop
Figure 4 – Iterative Configuration Process
Each time the cycle is repeated, we are able to design and refine both the business processes, as well as
the technical SAP configuration.
4/29/2004 37 of 87
Since there will be several cycles within the prototyping process, each business process will be assigned
to a specific Configuration Cycle. Based on complexity, the process will be categorized as either ' baseline'
final'
configuration, ‘baseline (+n)” configuration or ' configuration. Baseline configuration includes those
business processes that are core to the business and fit well into SAP functionality. These processes will
require no modifications to SAP and will not require major changes to the business processes or the
organizational structure. Final configuration includes more complex processes that are specific to UC or
may not be an easy fit to standard SAP processing.
Although there will only be one baseline configuration cycle, the final configuration may consist of multiple
cycles, depending on the number and complexity of the processes to be modeled. It is important to note
that the same end-to-end process can be assigned to multiple cycles. The process might first be modeled
during baseline in its most simple mode, and then more complex variations added during the later cycles.
Since the process teams within project may have differing requirements with regard to the number of
cycles required, each team can define its own cycles and deadlines for those cycles. As a rule however,
each team must have all of their cycles complete prior to the Final Integration Test.
5.2.2 Detailed Approach
5.2.2.1 Business Process Definition
The first step in the solution design process is to map UC’s end-to-end business processes to the SAP
R/3 Reference Model. The SAP R/3 Reference Model is a breakdown of the SAP system from a module,
down to specific functions within a module. The result of this exercise will be end-to-end process maps,
mapped to key SAP transactions. This step will be conducted during the Blueprint Phase of the project.
5.2.2.2 Define Detail Scope
Once the end-to-end processes are defined, the Project Team will define a detailed Business Process
Master List (BPML) that results from the mapping of business processes to SAP transaction codes. The
BPML is a statement of project scope providing a complete listing of SAP transaction codes. A
transaction code represents a recurring business event or scenario that has a unique result for each
occurrence electronically recorded in the system. For example, the posting of a vendor invoice in the
accounts payable sub-ledger is represented by a particular transaction code. Similarly, the subsequent
payment transaction liquidating the payable is represented by another transaction code. The BPML
output is typically a spreadsheet file. All the transaction codes that are in scope for the project are listed in
the rows of the spreadsheet. These codes are categorized by functional area so that, for example, all
accounts payable transactions appear together.
As a refined statement of project scope, the BPML is the point of origin for the major project work streams
during the Realization phase as described below:
• For the Functional Teams, the BPML points from the Business Blueprint to the system tables in
which configuration settings are required. The Functional Teams use the BPML as a checklist for
making and documenting the system configuration settings
• The Change Management Team will use the BPML to build a matrix of transactions and future
organizational roles for use in organizational change management
• The Testing Team uses the BPML for complete functional coverage in building test cases for
integration testing and user acceptance testing
• The Training Team uses the BPML to build the end-user training curriculum and the training
schedule
• The Security Team uses the BPML and the roles developed by the business transformation team
to develop security profiles.
This step will be conducted at the beginning of the Realization Phase.
4/29/2004 38 of 87
5.2.2.3 Configure SAP
Once the BPML has been created configuration activities can begin. Each Business Process Team (i.e.
Purchasing, Accounts Payable, Budgeting etc.) will be responsible for configuring their corresponding
components in the end-to-end business process. For example, in the basic requisition to check scenario,
the Purchasing Team will be responsible for configuring the requisition, purchase order and receipt
functions, while the Accounts Payable Team will be responsible for configuring the invoice and payment
functions.
Configuration can be performed in either the Sandbox or Development clients. However, the Sandbox
environment will only be used for "testing" the configuration. The Sandbox is the client where anything
goes and changes can be made without any standards or major communications across the project.
Configuration in the Sandbox is not saved and is not transported to other clients (e.g. Test, Training or
Production).
Within the Development environment there will be two clients in which configuration will be conducted.
These clients include the Preliminary and Golden client. The Preliminary client will be used to configure
the system in iterative cycles. It is here that the data should resemble realistic data and communication
across project teams is critical to ensure that we ultimately have an integrated design. The Preliminary
configuration client is where configuration will be unit tested prior to entering configuration in the Golden
client.
The Golden client is the platform from which configuration will be migrated to the Quality Assurance
environment. The purpose of this client is to ensure that the configuration remains pure for migration to
Quality Assurance/Training and Production. Final configuration from the preliminary development client
will be manually re-entered into the Golden client by the UC Project Team Member responsible for the
business process area. This procedure will aid in facilitating knowledge transfer. Within the Golden client
there will be no data and no testing. Once data and transactions are introduced to a client, a great deal of
the configuration cannot safely be altered. As a result, the Golden client will be used strictly for
configuration.
For a detailed diagram of the SAP systems and clients, refer to the "Logical Landscape" section of the IT
Infrastructure Strategy document.
5.2.2.4 Validate Technical Configuration and Design
Once configuration for a transaction is completed in the Preliminary Development client, the work will
need to be unit tested. A unit test consists of one SAP transaction (i.e. Enter Purchase Order) and may
encompass a test of both configuration, as well as development work, depending on the transaction. The
unit test script and results are documented in the Business Process Procedure (BPP).
This transaction flow will be validated primarily by the Business Process Team responsible for the
configuration however, extended team members and/or subject matter experts may be called upon if
needed. This validation is informal and ongoing throughout each cycle of configuration.
5.2.2.5 Transaction Integration Validation
At the end of a cycle, key integration points for transactions will need to be validated. The audience for
this validation should be the Project Team Members impacted by integration points, select Subject Matter
Experts and/or Business Process Owners. The objectives of this validation are as follows:
• Validate that key integration points are accurate
• Validate that integration audit trails are accurate and satisfactory
• Validate the roles defined in the process and business control points
• Instill a sense of ownership and confidence with the Business Process Owners
• buy
Solicit ' in'from the project team and subject matter experts
• Validate associated system development requirements
4/29/2004 39 of 87
• Start to identify the impact on end user training.
The degree of formality and level of integration will depend on the importance of the process. This
validation will occur in the Development environment and is conducted by project team members.
5.2.2.6 Validate Relevant Documents
As we progress through the baseline and final configuration cycles, processes will be tweaked and
configuration will be refined. It is critical that the supporting documentation be updated to reflect changes
that are made. This documentation will serve as the platform for Integration Testing and Training
documents and therefore must be current. Key documents to be updated will include:
• Business Process Flows
• Business Process Procedure documents (BPP’s)
• Configuration documents.
5.3 Testing Strategy
The system is being developed in four waves – Budget Preparation (SEM-BPS), Core Financial
Management (R/3 Enterprise), Business Warehouse (BW), and SAP Portals. Testing will be required as a
part of each of these deployable releases prior to migrating into production.
Several types of testing activities will be employed to confirm that the configured business processes
meet design requirements and that the technical environment is prepared for production. These different
types of tests are performed to address the integrated nature of the system and to cover all aspects of
system configuration and development. These include: Unit Testing, Integration Testing, User
Acceptance Testing, Interface End-to-End Testing, System Testing, Security Testing and Regression
Testing.
The system areas relevant for testing are:
• Configured business processes
• Development objects, including user exits, conversions, interfaces, forms, reports, and other
enhancements
• Technical system components, including hardware, connectivity and system administrative
support processes (such as backup and recovery and transport tools).
For each level of testing, the following method will be used:
• Plan what will be tested
• Prepare for testing
• Execute the test
• Report the results.
During test planning, the types of testing required will be identified based on the focus areas that are
priorities for the University. The test planning will also identify at which level each type of testing will be
performed.
The testing is based on the business and technical requirements for the scope of the project based on the
Blueprint phase. Test Cases will be created to support the testing effort.
The University and IBM resources will be involved in all levels of testing. The Unit, Integration, Interface,
End-to-End and System Test levels are IBM led, while the User Acceptance, Security and Regression
Test levels will be led by the University.
4/29/2004 40 of 87
5.3.1 Test Scope
The Test Scope defines the rules of what is included under the test plan and what is not. Clearly
identifying the scope of testing limits the effort to a manageable volume and assures testing is
concentrated where it is required.
The scope for testing is outlined in the “Project Scope” section of this document which details the
functional scope for the project.
5.3.2 Testing Strategy
5.3.2.1 Test Types
Test Types fall into functional and structural types. Functional Test Types assure the functionality of the
application, while Structural Test Types assure the structural viability and operability of the system.
Examples of Functional Test Types to be employed include Function/Requirements Testing, Error-
Handling Testing, Future Year Testing, Interface/Inter-system Testing and Regression Testing.
Examples of Structural Test Types include System Administration, Backup and Recovery, Contingency
also called disaster recovery testing), Printing and Fax, Network and Infrastructure, Security, Performance
and Stress/Volume Testing.
5.3.2.2 Test Levels
There are several levels of testing that will be performed to accomplish comprehensive functional and
technical system verifications for the FSRP project. This section provides an overview of test levels.
Unit Testing is the first level of testing for configuration and development. It focuses on validating that the
system’s smallest components meet specific functional test conditions. The purpose of the unit testing
activity is to verify that the system’s components are functioning as expected and to confirm that no errors
exist. Unit testing is typically the first test completed during the configuration and development efforts.
Unit testing focuses on self-contained functions rather than end to end integration. Unit testing for both
configuration and development objects is performed in a development environment using a small subset
of representative data. String testing may also be performed before integration testing if this is deemed
necessary. String testing is a further extension of unit testing by testing the related input and output
transactions to the unit test being performed.
Integration Testing (business function testing) validates that the integration of the system’s components
that compose the business solution is complete and functioning correctly. It is process-oriented testing of
essential functional business processes and encompasses configuration, interfaces, critical reports, user
exits, enhancements, and other development. Data loads into BW will also be verified during this testing
activity utilizing key reports.
The primary dependencies are:
• Successful completion of unit testing system wide
• A completed integration test schedule
• Completed integration test scripts
Integration testing is performed in a quality assurance system. Representative real data will be used to
simulate actual conditions. Test results are documented on the test scripts, and these documents
compose the integration test results. All problems encountered during integration testing are documented
and tracked to resolution. The compilation of these problems and associated resolutions make up the
integration test software problem log.
User Acceptance Testing (UAT) confirms that the requirements identified and accepted during the
Blueprint phase have been realized. Business Process Owners will determine the criteria for acceptance
4/29/2004 41 of 87
prior to the start of the testing. When the system testing meets the acceptance criteria defined, the
process owners will sign the UAT results, indicating approval. This activity proves to the University of
Cincinnati that the system operates in accordance with the functional requirements and is a major
component of overall system acceptance.
Business process scenarios executed as part of integration testing will form the foundation of the User
Acceptance Testing scope; however, user input will be solicited to define the scope of the final testing.
User Acceptance Testing is performed by selected key end users as identified by the University of
Cincinnati. In preparation for User Acceptance Testing, users will be provided with training to enable them
to perform their task with baseline SAP system technical and functional knowledge. Training will include:
• SAP navigation
• Business process overviews
• Business Process Procedures (BPP’s)
User Acceptance Test results are documented on the test scripts, and these documents compose the
user acceptance test results. All problems encountered during testing are documented and tracked to
resolution. The compilation of these problems and the associated resolutions make up the User
Acceptance Test Software Problem Log.
A UC Team Lead serves as the Testing Team Lead. This person is responsible for managing daily testing
activities, assisting users as needed with their testing tasks, and managing problems and issues that
arise during testing.
This testing activity is dependent on the successful completion of integration testing.
Interface End-to-End Testing is conducted with parties internal and external to the University to verify
the technical readiness of communications channels and that full production files can be successfully
exchanged and processed.
This activity is dependent on successful completion of interface integration testing.
System Testing validates the production readiness of the technical aspects of the new system
environment. This includes validation of input/output devices (such as printers and fax machines), backup
and restore testing, and testing of system administrative support functions. This test is dependent on the
production system being available. Note: Due to the expected low transaction load on the production
system plus a hardware sizing approach that allows for a margin of additional built-in capacity (made
possible by a combination of the low expected load levels, relatively high performance of “baseline”
systems and the relatively low cost of incremental hardware [CPU’s, memory and storage] required),
stress testing of the production system will not be performed.
Security Testing validates that the security access created provides the proper authority for University
employees to perform their business functions. Security testing is conducted to verify that the correct
system access for production user profiles has been created. Transactional access as defined in each
role created for end users will be tested. Security testing is dependent on completion of integration testing
and completion of security test scenario scripts.
Regression Testing is testing performed to verify that changes, such as support pack testing, made to
the system or technical environment have not adversely affected already tested system functionality (non-
change testing). The need to perform this testing activity becomes more likely and larger in scope as
these types of changes are made in the later stages of the project. The scope of testing will depend on
the impact of the changes precipitating the regression test. Regression testing may be conducted to
perform:
• Support pack upgrades
• Development and configuration changes made after functional testing activities have been
completed
4/29/2004 42 of 87
The current project plan does not include support pack upgrades. The activities for regression testing
relative to changes made after functional testing has been completed will be determined based on the
size and scope of the change made.
5.3.3 Roles and Responsibilities
5.3.3.1 IBM Roles
Team Lead/Test Manager: The Test Manager is responsible for managing, planning, coordinating,
controlling and monitoring the testing effort for Integration Testing, Interface End-to-End Testing, System
and Security Testing.
Consultant/Tester: The Tester is responsible for writing test cases, writing test scripts, building test data,
executing test scripts and documenting test results. The Consultant is responsible for managing,
planning, coordinating, controlling and monitoring the unit test effort for the assigned domain.
5.3.3.2 University of Cincinnati Roles
Team Lead/Testing Coordinator: Responsible for assessing the quality and completeness of all testing
scripts developed for the project. The Team Lead is also responsible for managing, planning, coordinating
and monitoring the testing effort for User Acceptance and Regression Testing. The UC Team Lead is
responsible for the testing facilities.
Team Member/Tester: The Tester is responsible for writing test scripts, building test data, executing test
scripts and documenting test results. The UC Tester is responsible for planning the effort related to
Regression Testing.
5.3.4 Test Management and Reporting
An organized and detailed problem tracking and resolution process is a key to successful testing
management. Testing issues will be monitored and tracked utilizing the Issues Management process
supported by the Ascendant ERP Toolset.
5.3.4.1 Problem Logging
All problems found during testing will be logged in the Ascendant ERP Toolset. Problems are initially
prioritized based on the Tester’s assessment of the criticality of the problem. If this assessment is
deemed to be inappropriate by the Team Leads, they may reassign the priority. The primary data to be
captured includes:
Issue Number Auto-generated unique problem number
Issue Date Date problem logged
Issue Title Short problem description
Critical Date Resolution Date required
Team Identification of team assigned to the issue
Responsible Identification of individual
Raised By Name of person who logged the problem
Test Type Testing activity in which the problem occurred (for example, integration, user acceptance,
regression)
Scenario ID Number of the test scenario script where problem was identified
Transaction Code / Specific transaction code where problem occurred
Development Object
Priority Defines the priority of the problem; used to prioritize work on corrections (critical, high, medium,
low)
Status Status of the problem (open, in process, closed, canceled)
Description Detailed problem description
4/29/2004 43 of 87
5.3.4.2 Problem Assignment and Resolution
Once a problem is created in the Ascendant ERP Toolset, it will be assigned for resolution, typically by
the person performing the test. After the assignment is made, the person responsible will be automatically
notified of the issue. The assigned person researches and resolves the problem and updates the issue
with the resolution. The problem documentation is then sent back to the tester for retesting. In addition to
basic information about the assignment and resolution of the problem, other required information
includes:
Action Required Information on problem research if applicable during the course of analysis
Resolution Description Description of the problem resolution
Resolution Date Date the problem resolution was entered
Impact Description Description of impact to training (if process change)
Transport Number Transport number that includes the fix
5.3.4.3 Problem Retesting and Closure
Once the problem has been resolved, the script in which the error was found is retested. If the test is
successful, the problem tracking database is updated to close the problem. If the problem is not resolved,
it is forwarded back to the assigned person. The following data is updated:
Retested BY Person assigned to verify that the problem is fixed
Status Status of problem (open, in process, closed, cancelled)
Closed Date Date problem is closed
5.3.4.4 Problem Reporting
Standard reports can be created and ad hoc queries can be developed as needed.
5.3.4.5 Problem Management
During testing activities, daily meetings will be held to review open problems, discuss priorities, plan
retests for resolved problems, and discuss issues. These meetings are critical to facilitate
communications and keep testing on track.
5.3.4.6 Problem Escalation
If there are discrepancies within the team regarding problem resolution, the normal issue resolution
process will be followed.
5.4 Data Conversion Strategy
5.4.1 Overview
The purpose of this section is to provide a strategy on how to initialize the master and transactional data
in the R/3, BW and BW/SEM-BPS databases. Specific data conversion plans will be identified during the
Blueprint Phase.
The data conversion effort is being developed in two waves – Budget Preparation (SEM-BPS) and Core
Financial Management (R/3 and BW). The data initialization requires a great deal of planning across the
Business Process, System Development (SAP and Legacy), Technical Infrastructure and Project
Management teams in order to meet project timelines for the final Integration Testing.
The Data Conversion Strategy must address all required data objects to initialize the databases. Data
objects refer to the different data tables and fields that need to be loaded and include both to master data
and transaction data. Examples of master data are materials and vendors. Examples of transaction data
4/29/2004 44 of 87
are orders and purchase requisitions. Legacy System Migration Workbench (LSMW) will be used where
appropriate.
5.4.2 Strategy
The Data Conversion Strategy will address data from CUFS, PERM and other data sources identified by
the Business Process Teams. The strategy will utilize a staging area for data cleansing which is a critical
and time consuming activity. The following high level critical activities are the foundation for the Data
Conversion Strategy for each data object:
• Identify data objects to be initialized in SAP
• Identify legacy data sources in CUFS, PERM or other existing data sources
• Create Data Migration Register for all data objects that serves as a central point of information for
data conversion. See Data Migration Register section below for details
• Create and finalize any program specifications for each data conversion
• Map legacy data to SAP
• Identify data gaps
• Identify data migration method for every data object to ready data for cleansing for both existing
data objects and gaps. Data migration may be automated or manual depending on each data
object
• Identify data object owner and develop a reconciliation and balancing process to assure data
quality in SAP
• Organize and prioritize data transfer to SAP. Data transfers are dependent on the customizing of
the SAP system and the organizational structure changes. As these can influence the data
transfer it will be necessary to confirm that all customizing is completed prior to the final test run
• Analyze and cleanse legacy data. Data cleansing can be performed in on the legacy systems or
in intermediate databases and this will be identified in the data migration method for each data
object and document in the Data Migration Register
• Test the data migration method to convert the legacy data into intermediate databases. This test
will be a repetitive process until both legacy and SAP Data Conversion Teams are satisfied the
data object will load into SAP. Testing and re-testing is a critical and best practice to assure
quality and integrity of data loaded into production SAP
• Identify the time required to execute each data migration method. Timings are critical for
production “Cut-Over” planning
• Execute and transfer data objects via data migration method into production SAP
• Reconcile and balance data in production SAP.
5.4.3 Data Migration Process
The following figure and table represent the flow of data objects during the Data Migration Process to load
production SAP databases.
D
B
Direct input,
A Conversion C CATT, BDC
(Automated sessions or E
or Manual) manual entry
Figure 5 – Flow of Data Objects During Data Migration
4/29/2004 45 of 87
Field Data Flow Data Location/Storage/Method
A Legacy data CUFS, PERM or other data sources in a flat file format
B Conversion and mapping MS Excel, data conversion program, MS Access or manual
entry
C Staging- Interim data storage area for MS Access , MS Excel , Text files, flat files
cleansing
D SAP upload procedures Data Migration Method for each data object
E SAP master database SAP R/3 Master database
5.4.4 Data Migration Register
A Master Data Migration Register will be created during the Blueprint Phase and will serve as a central
point of information for data conversions. The Master Data Migration Register contains a list of all data
objects detailing the following information:
• Data upload reference that ties the request back to a specific Business Process procedure
• Priority of the data
• Data object’s name
• Owner responsible for the data
• Type of data, whether it is master data or transaction data
• Prerequisites for loading the particular data object
• Data volume
• Upload procedure and reference
• Clean-up, mapping and data conversion responsibilities and status’s (percentage completed)
• QA (Quality Assessment) status
• Cut-Over timings, dependencies and sequence for transferring the data to production SAP
• Any other additional comments for example, any changes that need to be made to the data after
data transfer and before “going-live”.
5.4.5 Data Conversion Strategy Success Factors
Critical success factors that must be considered to effectively execute the Data Conversion Strategy are
as follows:
• Correct mapping of legacy data elements to the SAP data elements
• Identify and manage any field attributes change before production start (display or mandatory
attributes change or field status group change)
• Identify and manage conversion values changes at a late stage (cost code to cost center)
• Manage the number of different data objects to be transferred
• Identify early in the process the amount of data to be transferred, timings
• Produce an audit trail and reconciliation reporting
• Focus on quality and consistency of the data provided and cleansed
• Testing and re-testing prior to production loading.
5.5 Interface Strategy
5.5.1 Overview
The purpose of this section is to provide a strategy on how to interface and manage all in-bound and out-
bound data transmission to and from the R/3 and BW systems. For each interface, the strategy defines in
4/29/2004 46 of 87
detail the interface owner, interface method, dependencies, reconciliation process, rollback procedures,
complexity and risks, security, schedule, and resource requirements. Interfaces included as part of this
strategy are documented in the “Interface Scope” section of this document.
Each interface will require a great deal of planning across the Business Process, System Development
(SAP and Legacy), Technical Infrastructure, and Project Management Teams in order to meet project
timelines for the final Integration Testing along with the on-going management of interfaces.
The Interface Strategy must address all required data objects for all in-bound and out-bound interfaces
and include both internal UC and external UC interfaces. Interface data objects refer to the different data
tables and fields that need to be extracted from SAP or entered into SAP, Legacy and external UC
systems. An example of an internal interface is HR/Flex/Payroll and an external interface would be PNC
Positive Pay and Warrant Clearing.
5.5.2 Strategy
The Interface Strategy will only address the interfaces identified by the Business Process Teams during
the Blueprint Phase. The FSRP project recognizes that over many years the CUFS system has been
interfaced-to extensively, and while the UC RFP identified 19 interfaces, many more are known to exist. It
is likely that undocumented interfaces also exist. Adequately identifying and transitioning all existing
CUFS interfaces (either through building new interfaces to the SAP system or proving an alternative
approach to business areas that require core financial system data in order to support their operations)
will require UCIT resources to provide assistance and input to the core FSRP Project Team.
The Interface strategy includes using Web services standard SAP interfacing technologies (e.g. AL, BDC,
LSMW, BAPI’s) where appropriate, and integrating with UC’s current Enterprise Application Integration
BizTalk solution utilizing XML communication. The strategy is to insulate internal and external systems
from changes in partner systems where possible, by building platform-independent interfaces via the Web
Services Description Language (WSDL) where applicable. Where resources and technology preclude
this, the strategy is to minimize any internal or external system changes by performing the work with
standard SAP to BizTalk connectors in BizTalk or with SAP programs where required.
The policy for each interface solution is:
• SAP’s communication and integration technologies will be applied with the first priority being to
meet the business requirements with a minimum of impact to the technical scope and imposing
minimum technical risk on the project.
• Standard technical solutions will be developed and deployed to expedite the development
process, thereby reducing the ongoing maintenance support requirements after implementation.
The following high level critical activities are the foundation for the Interface Strategy for each interface
and data object:
• Analyze all legacy interfaces documented in the “Interface Scope” section of this document to
determine if they could be replaced by SAP functionality as part of the Blueprint Phase
• Identify data sources and data objects to be interfaced with SAP
• Create Interface Profile documents for all data sources and objects that serves as a central point
of information for interfaces (see “Interface Profile” section below for details)
• Determine the interface: Web services, SAP technologies and/or BizTalk
• Create and finalize any program specifications for each SAP interface for BizTalk and SAP.
Reusable business processes should have reusable implantations via Web services and, if
necessary, Business Process Execution Language for Web Services (BPEL4WS or BPEL)
orchestrations. One program specification should be created for each extract, translation and
input program
• Map SAP data objects with legacy and external systems
• Identify data gaps
4/29/2004 47 of 87
• Identify data interface method for every data object for both existing data objects and gaps
• Identify data object owner (Business Process Owner) and develop a reconciliation and balancing
process to assure data quality in and out of SAP
• Organize and prioritize interfaces to SAP. Interfaces are dependent on the customizing of the
SAP system and the organizational structure changes. As these can influence the data to be
interfaced, it will be necessary to confirm that all customizing is completed prior to the final test
run
• Identify the data integration method for each data object and document in the Interface Profiles
document. (What does this fragment mean?)
• Identify interface dependencies and reconciliation processes
• Identify backup, restart and rollback procedures
• Extract data objects via data interface and feed BizTalk
• Test the interface method to translate the data objects with SAP and other UC systems. This test
may be a repetitive process until legacy, external and SAP data interface teams are satisfied the
data object flow with SAP and other UC systems. Test the restart and rollback procedures
• Testing and re-testing is critical and best practice to assure quality and integrity of data loaded
into production SAP
• Identify the time required to execute each interface. Timings are critical for managing and
scheduling the production systems
• Reconcile and balance interface data SAP, UC internal and external systems is performed by the
interface owner. The interface owner is also responsible for processing and correcting interface
errors
• Identify audit trail requirements
• Build production interface schedule
5.5.3 In-bound and Out-bound Interface Process
5.5.3.1 In-bound Interfaces
Loosely-coupled
If, on analysis of the set of interfaces defined in the Blueprint Phase, it is determined that there is
functionality or data in SAP that has applicability across application or platform boundaries, a loosely-
coupled solution using Web services should be employed. This platform-independent, single point of
access for a common interest of the defined interfaces allows for greater manageability and adaptability
and contributes to the goal of services-oriented architecture.
Data mapping is a secondary issue. In cases where the source system is legacy or that resource
availability does not allow for consumption of Web service, these services can be used in conjunction with
the techniques described in the next section (“Tightly-coupled”.) BizTalk has the ability to consume Web
services at any point of a transaction.
Tightly-coupled
An inbound interface process begins with the mapping and translation of existing data in the internal and
external systems as shown in Figure 6 below. This leads to the actual extraction of data from the current
system. This extract generated for input into SAP is typically in the form of a flat file.
Before the actual program can be constructed, a thorough data mapping has to take place. In addition, a
translation/manipulation of internal and external data fields is required for SAP to properly process the
file. SAP interfacing technologies, or BizTalk can be used to map appropriate tables/fields, to process all
extract files into SAP acceptable data and formats. The interfacing technology, BizTalk, should only pass
those records that were successfully translated.
4/29/2004 48 of 87
Data is extracted from various source systems, processed through SAP interfacing technology or BizTalk,
and the translated file is transmitted to the SAP system. BizTalk or the SAP interfacing technology pre-
processes the data into defined formats and assigns SAP specific values for data transfer to SAP. A
production schedule will be used to execute the various background processes in the interface
architecture and transfer the files.
The Project Team will evaluate the adoption of standard SAP tools and functionality e.g. the Legacy
system Migration Workbench and the SAP Data Transfer Workbench (DX Workbench), where practical to
transfer data to/from BizTalk or to/from SAP. SAP will process BizTalk files into the correct format and
recommended size for processing through SAP program or other generic program as well as creating
reconciliation and balancing reports of BizTalk files prior to the SAP load.
5.5.3.2 Out-bound Interfaces
The outbound interface approach is very similar to an inbound interface approach as defined in “In-bound
Interfaces” section above and Figure 6 below. In order to provide data from the SAP environment to
internal and external systems, some form of user written extraction programs may need to be developed.
These extract programs will be in the form of ABAP/4 programs, which will query the SAP data dictionary
to retrieve required information.
Standard SAP-to-BizTalk connectors in BizTalk will be utilized for interfaces unless a specific SAP
program is required.
4/29/2004 49 of 87
SAP In-Bound Interface Process SAP Out-Bound Interface Process
Overview Overview
Identify
Identify SAP
Reconcile Legacy Reconcile
Fields to
Data Fields to Data
Populate
Populate
Load Data Load Data
Map SAP to Map Legacy
into SAP into Legacy
Legacy Fields to SAP Fields
System System
Define Map File Define Map File
Translation Layout to Translation Layout to
Rules SAP Fields Rules Legacy Fields
Map Legacy Transfer Flat Map SAP Transfer Flat
Fields to File File to SAP Fields to File File to Legacy
Layout Server Layout Server
Extract Perform Data Extract SAP Perform Data
Legacy Data Translation Data Translation
Figure 6 – SAP Interface Process
5.5.4 Interface Model for EAI
Figure 7 below represents the Interface Model for EAI to leverage UC’s current EAI infrastructure with
SAP integration. The model will be further defined during the Blueprint Phase. XI is SAP’s entry into the
EAI domain. It can be configured with adapters that allow XI to support many different protocols and data
formats. XI is a relatively new product offering and consequently has not yet developed a reputation for
being a robust and stable environment. Due to the limited SAP customer use of XI as an enterprise
application solution, a proof-of-concept will be conducted using a 60 day trial of the SAP XI 2.0
technology. Proofs-of-concept will also be performed with the .NET Connector 1.0.2, Java Connector
2.1.2 and NetWeaver Developer Studio.
4/29/2004 50 of 87
SAP ALE BW/SEM-
SAP R/3
BPS
BizTalk
Internal External
Systems Systems
Figure 7 – Interface Model for EAI
5.5.5 Interface Profile
The Interface Profile will be created during the Blueprint Phase and will serve as a central point of
information for interfaces. The Interface Profile contains a list of all data objects detailing the following
information:
• Interface Description
• Data Object Owner (Business Process Owner)
• Interface Method
• Dependencies
• Reconciliation Process
• Restart and Rollback Procedures
• Complexity and Risks
• Security Requirements
• Schedule Requirements (frequency)
• Resource Requirements.
5.5.6 Interface Strategy Success Factors
Critical success factors that must be considered to effectively execute the Interface Strategy are as
follows:
• Correct mapping of data elements
• Use standard SAP and Microsoft connectors where a services-oriented approach is not possible
• Appropriate use of Web services, SAP interfacing technologies and BizTalk
• Identify and manage any field attributes change before production start (display or mandatory
attributes change or field status group change)
• Identify and manage interface values changes at a late stage (cost code to cost center)
• Manage the number of different data objects to be interfaced
• Identify early in the process the amount of data to be interfaced, timings, schedule requirements,
dependencies
• Establishment of solid on-going support processes and procedures
• Focus on quality and consistency of the data provided and translated
4/29/2004 51 of 87
• Testing and re-testing prior to production execution.
5.6 Reports and Forms Strategy
5.6.1 Overview
The purpose of this section is to provide a strategy on how to identify report and form requirements to
track business results and to provide forms to meet the business needs. This section describes the
business reports and forms development activities as they relate to the implementation of SAP at UC.
5.6.2 Strategy
The key to this strategy is to leverage existing SAP reports and forms to minimize building of customized
programs to meet the business requirements of UC. R/3 and BW will be the reporting repositories for UC.
Minimizing customization will decrease the risk and costs for development and on-going support of the
SAP solution. Establishing BW as the main reporting repository and utilization of delivered BW cubes will
also minimize risk and costs for UC reporting requirements. Key to this strategy is the identification of
information requirements at the same time new business processes are being defined during the
Blueprint Phase. The following high level critical activities are the foundation for this strategy:
• Utilize BW and delivered cubes as the main reporting repository
• Determine, for each information request, if R/3 or BW will be the reporting repository and the level
of detailed information required
• Identify gaps
• Document report and form customization needed to meet gap requirements. Determine how gaps
will be satisfied using SAP reports and forms tools (Report Writer, Query, SAPScript or ABAP)
• Present business justification for custom requests, and obtain required approvals
• Prioritize development requests
• Determine any design or configuration implications
• Develop design specifications for approved customized reports and forms. Approved forms will be
developed within SAP using SAP Script, in most cases copying and modifying standard forms
• Construct approved reports using SAP delivered reporting tools where appropriateHummingbird’s
BI Query product suite where appropriate, or ABAP
• Test, train, and implement all reports and forms within the framework of the Business Process
model.
5.6.3 Standards
Report and form standards will be defined during the Blueprint Phase and documented if customization is
required to meet an information requirement. A Reports Development List and Forms Development List
will be created if customization is required.
5.6.4 Security
Report security policies will be defined during the Blueprint Phase and documented to meet an
information requirement.
5.6.5 Reports and Forms Strategy Success Factors
Critical success factors that must be considered to effectively execute the Reports and Forms Strategy
are as follows:
• Determination of the report repository between R/3 and BW
• Sufficient time and resources are dedicated to complete the coding and testing of reports and
forms
4/29/2004 52 of 87
• Heavy need for customized reports and forms
• Identification of the correct reporting tool.
5.7 ABAP Enhancement Strategy
5.7.1 Overview
The purpose of this section is to provide a strategy on how to address enhancements that requires an
ABAP program be written to meet a specific business need. Enhancements are custom programs, written
in ABAP, SAPscript or Java languages that address reports, forms or added functionality via user exits
that are not provide by standard SAP. Enhancements do not include updates or changes to the SAP
source code. This section describes the ABAP development activities as they relate to the implementation
of SAP at UC.
5.7.2 Strategy
Key to this strategy is to leverage existing SAP functionality to minimize building of customized ABAP
enhancements to meet the business requirements of UC. Minimizing customization will decrease the risk
and costs for development and on-going support of the SAP solution. An ABAP enhancement may be
required to address specific conversion, interface, reports or SAP functionality gap. Key to this strategy is
the identification of ABAP requirements at the same time new business processes are being defined
during the Blueprint Phase. The ABAP enhancement strategy requires UC to do the following:
• Identify during Blueprint the ABAP enhancements required to support the "to be" business
processes
• Utilize standard SAP screen displays and pre-delivered functionality
• Identify and document gaps
• Analyze and determine if gap can be addressed with a manual business process, a bolt-on
solution or ABAP enhancement
• Document ABAP customization needed to meet gap requirements
• Assess potential impact of the enhancement
• Build the business case, business/organizational impact, cost benefit, integration considerations
and rationale to justify the ABAP enhancement
• Present business justification for ABAP enhancements, and obtain required approvals
• Prioritize ABAP enhancement requests
• Determine any design or configuration implications
• Develop detailed design specifications for approved customized ABAP enhancements
• Build approved reports using SAP delivered reporting tools, where possible, or ABAP
• Test ABAP enhancement
• Identify the time required to execute each ABAP enhancement and determine system impact.
5.7.3 Standards
ABAP enhancement standards will be defined during the Blueprint Phase and documented if
customization is required to meet a business requirement. A Master Development List will be created if
customization is required to track each enhancement.
5.7.4 Security
Report security policies will be defined during the Blueprint Phase and documented to meet the business
requirement.
4/29/2004 53 of 87
5.7.5 ABAP Enhancement Strategy Success Factors
Critical success factors that must be considered to effectively execute the ABAP Enhancement Strategy
are as follows:
• Business Process Owner will document, create the business justification and present business
case justification for all custom requests, and obtain required approvals
• Sufficient time and resources are dedicated to complete the identification of ABAP enhancements
• Strong business case for ABAP enhancement
• Involvement of the business owner
• Quick decision making, sign off and prioritization of ABAP enhancements
• Sufficient time and resources are dedicated to complete the coding and testing of ABAP
enhancements
• Solid ABAP standards and code reviews specifically for performance considerations.
5.8 Extended Functionality/Bolt-On Strategy
5.8.1 Overview
The purpose of this section is to provide a strategy on how to address the need for extended functionality
that is required to meet a specific business need. Extended functionality is typically referred to as a Bolt-
On. A Bolt-On is a software or hardware solution that is integrated with SAP by enhancing areas where
SAP does not provide functionality. Bolt-On solutions are typically provided by Third Party certified SAP
partners or are internal applications that require integration with SAP. An example would be a tax
package solution, a Fax server solution and the UC current Data Warehouse.
5.8.2 Strategy
The main focus of the strategy is to leverage existing SAP functionality to minimize Bolt-On requirements
to meet the business requirements of UC. Minimizing Bolt-Ons will decrease the risk and costs for
development and on-going support of the SAP solution. Bolt-Ons may be required to address specific
conversion, interface, and SAP functionality gaps. Key to this strategy is the identification of Bolt-On
requirements at the same time new business processes are being defined during the Blueprint Phase.
The following high level critical activities are the foundation for this strategy:
• Identify during the Blueprint Phase the Bolt-Ons required to support the "To Be" business
processes
• Utilize standard SAP screen displays and pre-delivered functionality
• Identify and document gaps
• Analyze and determine if gap can be addresses with a manual business process, a bolt-on
solution or ABAP enhancement
• Document Bolt-On needed to meet gap requirements
• Research the Bolt-On to determine the overall impact to the system
• Build the business case, business/organizational impact, cost benefit, integration considerations
and rationale to justify the Bolt-On
• Present business justification for Bolt-on, and obtain required approvals
• Prioritize Bolt-On requests
• Determine any design or configuration implications
• Consider business need for a high availability for the Bolt-On
• Develop procurement specifications for approved Bolt-On including both software and hardware
• Identify SAP certified partners who address the specific Bolt-On requirement
• Execute the UC procurement Process
4/29/2004 54 of 87
• Review alternative solutions
• Select and procure Bolt-On solution including both software and hardware
• Install, integrate and test the Bolt-On solution
• Identify the time required to execute each Bolt-On and determine system impact for production
environment.
5.8.3 Standards
rd
IBM recommends that all 3 -party Bolt-Ons are certified SAP solutions.
5.8.4 Security
Bolt-On security policies will be defined during the Blueprint phase and documented to meet the business
requirement.
5.8.5 Extended Functionality/Bolt-On Strategy Success Factors
Critical success factors that must be considered to effectively execute the Bolt-On Strategy are as follows:
• Duration of the Bolt-On procurement
• Time to integrate and test the Bolt-On
• Ability to find SAP-certified solutions.
5.9 Post Implementation Service and Support Strategy
5.9.1 Overview
The purpose of this section is to provide a strategy on how the post implementation services and support
will be delivered after Go-Live, along with the establishment of the UC SAP Competency Center for on-
going and sustaining support of the production environment. This strategy will be refined during
implementation and finalized prior to Go-Live.
5.9.2 Strategy
The key to this strategy is to identify the areas of support that are required during post implementation by
the implementation team along with the support areas UC will need to establish to provide on-going and
sustaining activities for the production system.
5.9.2.1 Implementation Team
The Implementation Team will provide for a period of six weeks, resources chosen to assist UC in the
smooth transition to the production environment in support of the UC SAP Competency Center. In
addition, the implementation team will provide six weeks of support for the critical end of year processing.
5.9.2.2 UC SAP Competency Center
UC will establish during the course of the project, a SAP Competency Center that will support the Go-Live
and provide on-going and sustaining support for the SAP solution. The UC Competency Center will need
to address several key areas as UC moves forward with the initial implementation, new SAP functionality
and new technology changes. Establishment of Help Desk support structures will also be addressed in
this strategy and the key areas of support include the following:
• User Interface (Desktop)
• Business Process (Process)
• Training
• Application Functional (Configuration)
• Application Development (ABAP)
4/29/2004 55 of 87
• Infrastructure (BASIS, DBA etc.)
• Operations (scheduling, OS, hardware etc.)
• Security
• Organizational Change Management.
User Interface - SAPGUI and SAPGUI for HTML support and deployment will need to be integrated with
current UC Desktop support, for those users who access the system via SAPGUI. Maintain the design
and operation of the Enterprise Portal interface.
Business Process – SAP processes will need to be supported along with new processes that will need
to be defined and assessed for impact and change management implications. Assist with planning and
support of major release upgrades and assist in defining security profiles.
Training – Courses will need to be kept up-to-date as configuration and processes change and new
functionality is deployed. Maintain end user training plans and materials.
Application Functional – Provide detailed application knowledge, perform software configuration tasks,
provide help desk support for the application and maintain all master data that is defined as centrally
maintained for UC, perform regression testing along with assessing the impact of proposed changes to
the base line system. Assist with planning and support of major release upgrades, perform analysis of
potential impacts of vendor-supplied patches and assist in defining security profiles.
Application Development - Support custom ABAP developed objects (screens, reports, forms etc),
interfaces with Exchange Infrastructure, BIZTALK along with assisting with planning and support of major
release upgrades, and Bolt-Ons (software integration).
Infrastructure – Provide architecture and planning, BASIS and DB2 support, apply patches and fixes to
kernel and SAP application, monitor availability and performance of SAP, build new clients, assist with
planning and support of major release upgrades.
Operations – Support hardware, Operating System, network, monitor availability and performance of OS
and hardware, job scheduling, manage backup and recovery, print management etc.
Security – Administer SAP security profiles including role-based “Single Sign-on” users who access the
system via the Portal. Security of the UC Competency Center will need to be addressed since this
support organization will cut across departments and functional areas.
Organizational Change Management – Coordination, prioritization of SAP change requests will need to
be integrated into the current UC change control processes. Tight integration is required to ensure that
infrastructure and legacy changes are known prior to deployment.
5.9.3 Post Implementation Service and Support Strategy Success Factors
Critical success factors that must be considered to effectively execute the Post Implementation Service
and Support Strategy are as follows:
• Identification of the Support organization at the end of the Blueprint Phase to facilitate
organizational changes and knowledge transfer
• Integration with existing UC support organizations
• Assigning key personnel from the Implementation Team to the UC SAP Competency Center
• Ensuring a smooth transition to the UC SAP Competency Center.
4/29/2004 56 of 87
5.10 System Enabler Strategy
5.10.1 Overview
The purpose of this section is to provide a strategy on how to address the need for technical utility
solutions to support the UC SAP landscapes. This strategy includes reviewing solutions for Document
Imaging, Output Management (including department charge back capability), SAP Job Scheduling,
Regression Testing, Stress Testing and Archiving. MS Operations Management will be reviewed as part
of the Technical Infrastructure. This strategy will be refined and potential solutions will be reviewed during
the Blueprint Phase as technical requirements are identified, after the overall architecture is finalized and
during the deployment of the landscapes.
5.10.2 Strategy
The main focus of the strategy is to leverage existing SAP technical capabilities to minimize the need for
additional System Enablers of UC. Minimizing System Enablers will decrease the risk and costs for
implementation and on-going support of the SAP solution. Key to this strategy is the identification of
System Enabler requirements at the same time new business processes and technical requirements are
being defined during the Blueprint Phase and landscape rollout. The following high level critical activities
are the foundation for this strategy:
• Identify during Blueprint the System Enablers required to support the "To Be" technical
infrastructure
• Identify and document gaps
• Analyze and determine if gap can be addresses with a manual business process or a System
Enabler solution is required
• Document System Enabler needed to meet gap requirements
• Research the System Enabler to determine the overall impact to the system
• Build the business case, business/organizational impact, cost benefit, integration considerations
and rationale to justify the System Enabler
• Present business justification for System Enabler, and obtain required approvals
• Prioritize System Enabler requests
• Determine any design or configuration implications
• Consider business need for high availability for the System Enabler
• Develop procurement specifications for approved System Enabler including both software and
hardware
• Identify SAP certified partners who address the specific System Enabler requirement
• Execute the UC procurement Process
• Review alternative solutions
• Select and procure System Enabler solution including both software and hardware
• Install, integrate and test the System Enabler solution
• Identify the time required to execute each System Enabler and determine system impact for
production environment.
5.10.3 Standards
IBM recommends that all System Enablers are certified third party SAP solutions.
5.10.4 Security
System Enabler security policies will be defined during the Blueprint Phase and landscape rollout and
documented to meet the technical requirement.
4/29/2004 57 of 87
5.10.5 System Enabler Strategy Success Factors
Critical success factors that must be considered to effectively execute the System Enabler Strategy are
as follows:
• Involvement of the technical owner and business owner
• Quick decision making, sign off and prioritization of System Enablers
• Sufficient time and resources are dedicated to complete the procurement process
• Duration of the System Enabler procurement
• Time to integrate and test the System Enabler.
5.11 Capacity Planning Strategy
Given the relatively small volume of data that UC production system is expected to generate, it is not
anticipated that capacity planning beyond simple data archiving will be a factor for the UC SAP production
system. The recommended strategy for capacity planning is to size the solution for several years of
production operations and prepare an Archiving Strategy, if required. During the implementation the
project team will evaluate the SAP EarlyWatch and IBM Insight services to determine if there is any
change to this strategy.
5.12 Disaster Recovery Strategy
5.12.1 Overview
The purpose of this section is to establish a placeholder strategy for a Disaster Recovery for the SAP
environments. UC first needs to finalize their SAP platform and operating system decision before an
effective Disaster Recovery Strategy and Plan can be developed.
5.12.2 Strategy
The main focus of the strategy is to incorporate the SAP infrastructure into the existing UC disaster
recovery plans where possible. Once the platform and operating system decision is finalized, UC can
then begin to finalize the Disaster Recover Strategy and begin building the Disaster Recovery Plans. The
following high level critical activities are the foundation for this strategy:
• Finalize the SAP platform and operating system decision,
• Determine how it fits into the UC current plans
• Decide what SAP environments need to be recovered in case of an emergency
• Involve the platform and network vendors and obtain pricing information as necessary
• Build and Finalize the Disaster Recovery Plan
• Implement and test the Disaster Recovery Plan
• Testing and re-testing is a critical and best practice to assure the disaster recovery works
• Schedule the testing of the Disaster Recovery Plan annually
• Update Disaster Recovery Plans immediately as the Infrastructure changes.
5.12.3 Disaster Recovery Strategy Success Factors
Critical success factors that must be considered to effectively execute Disaster Recovery Strategy are as
follows:
• Any Disaster Recovery Plans developed will support, and not conflict with, UC’s existing Disaster
Recovery arrangement with Ohio State University
• Sufficient time and resources are dedicated to complete the identification of the Disaster
Recovery Plan
• Strong business case for acquisition of Disaster Recovery hot site or service provider
4/29/2004 58 of 87
• Involvement of the business owners and technical owners
• Identification of network requirements
• Quick decision making and sign off once it is determined that a Disaster Recovery Plan is
warranted
• Sufficient time and resources are dedicated to complete the procurement process if required
• Time to integrate and test the Disaster Recovery Plan
• Continuous updating of the Disaster Recovery Plans where changes are made to the
infrastructure
• Continue to test the Disaster Recovery Plan annually.
5.13 Archiving Strategy
Given the decision to size the production system to maintain three years of history from Go-live prior to
archiving, it is recommended that the Archiving Strategy be developed after one full year of history has
been captured. This will allow UC to better understand the growth rate of the database, the use of BW
and performance of the production servers before implementing an Archiving Strategy.
5.14 Controls and Security Strategy
5.14.1 Overview
The purpose of this section is to provide a strategy on the various areas that require specific Controls and
Security as UC deploys SAP throughout the University that contribute to:
• Effectiveness and efficiency of the UC’s operations
• Reliability of financial and management reporting
• Compliance with applicable laws and regulations.
Controls and Security are techniques used to establish internal control of the resources and data for the
FSRP systems within UC.
In order to ensure the control objectives are achieved, specific control procedures (including security) will
be designed and implemented either within and/or in support of the SAP systems. Controls will fall into
one of the following Controls Categories:
• Inherent Controls - represent controls within the system that can be relied on out of the box. For
example, a Vendor Master Record cannot be deleted when the customer has related open items.
This is enforced by the system and does not require any further configuration,
• Configurable Controls - represent controls that can be configured within SAP. For example, the
system can be configured to check for duplicate invoices from vendors,
• SAP Authorization Concept (Security) - provides access level controls to transactions processed
within the system. For example, only authorized personnel can maintain a specific fund, and
• Other/Manual Supporting Controls - Other/Manual controls represent procedures implemented
outside the system.
5.14.2 Strategy
The overriding principle of the Controls and Security Strategy is to build-in informational integrity during
business process design in the Blueprint phase, rather than auditing-out weaknesses after the process
and systems are installed. The Controls and Security approach includes:
• Taking a “risk management” approach to implementing configurable, manual, and access controls
• Establish control objectives reflect internal and external control requirements
• Integrating controls and security design fully with Business Process design.
4/29/2004 59 of 87
The following high level critical activities are the foundation for the Controls and Security Strategy for the
various Controls Categories:
• Develop the Business Risk Profile and determine the control objectives that will be needed to
mitigate the identified risks. At a high level, indicate the strategy for implementing these controls.
Either manual, configurable or authorization concept controls can be used
• Prepare a “Controls and Security Plan” that references the risk model and the identified control
objectives, as well as, the control implementation approach
• Review and include current UC security and controls into the document to address at least the
following areas:
o Business processes – include business related controls for configuration and security
authorization design
o Technical infrastructure – include physical security, operating system, database, data
communications and network, access to specific landscapes
o Interfaces and conversions – include data encryption requirements, data cleansing process,
access to batch runs and EAI hubs
o Organizational – include end users, project team, testers, trainers and UC SAP Competency
Center staff and other support organizations
• The “Controls and Security Plan” references the specific details of the implementation
environment, target technical infrastructure, and the scope of the business processes being
implemented, while discussing why a particular control approach is being pursued
• Ensure that the plan is agreed to by both Project Management and Internal Audit. Make clear that
the plan may be updated as additional information is gathered
• s
Use SAP' R/3 Security Winhelp, R/3 System Security and Authorization Concept, and R/3
Security Manual to help define and document the Controls and Security Plan.
5.14.3 Controls and Security Strategy Success Factors
Critical success factors that must be considered to effectively execute the Controls and Security Strategy
are as follows:
• Sufficient time and resources are dedicated to complete the Controls and Security process
• Involvement of the business and technical owners including Internal Audit
• Starting the Blueprint Phase prior to having the Business Risk Profile completed.
5.15 Technical Infrastructure Strategy
SAP R/3 and BW systems run on a variety of databases, operating systems and hardware platforms.
Some platforms are relatively new and do not have a large production customer base, while other
platforms have been around for many years and are in production at thousands of companies. Different
sets of skills are needed by system administrators to maintain the software and hardware. Some skills are
already in-house at the University, while others may have to be acquired or built.
The underlying infrastructure, services and systems management necessary to support an end-to-end
implementation of the SAP R/3 application environment is currently being investigated by the System
Infrastructure Team. Once decided and approved, it will be documented in the “Technical Infrastructure
Strategy”.
As the business requirements and issues are refined during the project, the Technical Infrastructure
Strategy will be validated, updated and expanded to the deeper level of understanding and the impact on
technical requirements.
The Technical Infrastructure Strategy is a stand-alone document that is available in the Ascendant ERP
Toolset.
4/29/2004 60 of 87
5.16 Organizational Change Management Strategy
5.16.1 Executive Summary
Replacing the College and University Financial System (CUFS) with a mySAP Business Solution
represents a significant transition for many University of Cincinnati (UC) staff. Study after study shows
that the key roadblock to successful change is resistance on the part of the people who must do things
differently. Resistance usually comes about because people are afraid or unsure of how they will be
affected by the change. Changes to the business processes as a result of the implementation of SAP
may also result in changes to other elements of the organization including:
• Management Systems – the configuration of the organization as a complex system, including its
formal aspects of authority and communications
• Values, Beliefs and Norms – the predominant value system for the organization as a whole, the
norms and values guiding individuals and groups at all levels in the organization
• Information Technology – the operations and systems used to support jobs and arrange the
flow of work
• Jobs and Skills Organization – the nature of work as guided by the organization’s mission,
objectives and strategy.
Figure 8 shows the potential areas of impact for the Financial System Replacement Project (FSRP)
initiative:
Management Systems
Jobs and Skills Business Values, Beliefs
Organization Processes & Norms
Information
Technology
Figure 8 – FSRP Initiative Potential Areas of Impact
Changes in any or all of these areas should be identified and managed in order to achieve the anticipated
benefits of the SAP implementation. Helping the UC Community through the changes that the FSRP
initiative represents is the responsibility not only of the FSRP Project Team, but also of UC Executive
Leadership and Senior Management, especially within the Finance and Information Technology divisions.
The role of the FSRP Change Management and Training Team is to put in place processes and
structures to assist UC staff through the change and to support UC Management in their role as Change
Leaders.
The FSRP Change Management Strategy describes the key Change Management workstreams that will
be developed and resourced to support the implementation of SAP at UC.
4/29/2004 61 of 87
5.16.2 Overview of Change Management
Change Management can be defined as, “the systematic and planned implementation of activities
and actions targeted to specific audiences, which move an organization to accept and embrace
new behaviors, new tools, new processes and/or new orientations.”
Change Management in the context of the FSRP SAP implementation, consists of:
• Activities relating to the assessment of an organization’s capacity to effect the changes needed to
achieve the required performance
• Developing and executing change initiatives aimed at facilitating the implementation and
mitigating project risks
• Sustaining and institutionalizing the new business practices.
To this end, the major goals of Change Management for UC’s FSRP initiative are to:
• Ensure a smooth transition to the new SAP system
• Create and sustain acceptance and ownership of the project objectives by UC Executives and
staff
• Understand UC’s stakeholders, their level of support for the project and their issues
• Actively engage key stakeholders
• Identify and reduce the impact of barriers to change within UC
• Help ensure that the business benefits are realized
• Reduce risk.
The ability of UC to successfully implement FSRP is in large part dependent on the effective delivery of
an integrated set of Change Management activities targeted to specific audiences across all areas of the
organization that are affected by the implementation. These activities are aimed at preparing UC –
especially the system end users – for the changes that will occur as a result of the FSRP.
Many lessons have been learned from ERP implementations which indicate that the more effective the
change management activities, the less impact and resistance is felt by the organization. It is therefore
important that:
• Change Management becomes a part of all phases of the implementation lifecycle (from before
Blueprint to after Go-Live)
• All Change Management tasks are included and monitored as part of the integrated Project Plan.
5.16.3 Benefits and Importance of Change Management
The benefits of adopting and embracing a Change Management approach in support of the FSRP
initiative include:
• Buy-in to the change is actively developed, not left to chance
• Through a co-ordinated communication process, confusion and uncertainty among end users and
other key stakeholders is minimized
• Barriers to change are identified early, allowing them to be managed in a controlled way
• Dissatisfaction and/or resistance among key stakeholders is identified, managed and controlled
• Business disruption is, as much as possible, minimized
• Motivation is maintained, thereby sustaining the momentum of the FSRP initiative
• New or modified jobs are identified, as well as the skills required to successfully perform those
jobs
• End users become trained, skilled and practiced users at the point of go-live.
4/29/2004 62 of 87
5.16.4 Transition Planning
Transitioning to the new SAP system requires a well thought out plan that incorporates information from
all components of the Change Management effort, integrated with the overall timeline for the
implementation. The timing and impacts of other initiatives outside of the FSRP must also be taken into
consideration. Transition Planning summarizes the needed changes for the project and defines the
overall approach, documented in the Change Management Strategy, which UC will take to implement its
new capabilities, manage resistance, promote acceptance and mobilize the organization to meet
business goals and objectives. In addition to the elements identified in the Change Management Strategy,
Transition Planning encompasses two other major areas:
• Risk Management, and
• End User Training.
An approach to Risk Management has been defined in the Project Charter and summarized in the FSRP
Change Management Strategy. A separate Preliminary End User Training Strategy has been developed,
which will be refined over the life of the project. The End User Training Strategy should be read in
conjunction with the Change Management Strategy and complements the activities outlined in this
document.
5.16.5 Change Management Strategy
The Change Management Strategy contained in this document supports UC’s FSRP SAP implementation
objectives and applies and delivers a broad range of Change Management activities that address:
• Organization Readiness
• Stakeholder Analysis and Participation (including Change Leadership and Change Agent
Programs)
• Communication
• Risk Management.
The diagram in Figure 9 shows how the elements of the Change Management Strategy fit together.
Combined, these elements help to create awareness, understanding and acceptance of the FSRP.
Stakeholder Analysis Change Leadership Change Agent
and Participation Plan Program Program
Identifies Stakeholders and Engages key decision Engages individuals at
their needs and creates a makers and influencers all levels of the
plan to address and monitor in leading the change organization to act as
those needs effort role models for the
change effort
Change
Readiness Communication Strategy Communication Plan
Assessment
Defines overall framework for Details the specific
Assesses management communications communication activities
and employee development and delivery required to help inform and
understanding of the prepare the organization for
project and their TRANSITION AND RISK the transition to the new work
readiness for change MANAGEMENT ACTIVITIES environment
Figure 9 – FSRP Change Management Strategy Elements
4/29/2004 63 of 87
Although identified separately, the Change Management activities shown in Figure 9 are highly
interdependent. For example, communications activities are a key component of most stakeholder
participation plans; change leadership and change agent programs are also key components of
stakeholder participation; and they are all elements of the overall transition and risk management
activities for the project. Together these activities will help UC staff to understand, accept and implement
the changes resulting from the FSRP initiative.
5.16.6 Risk Management
5.16.6.1 Overview
A Risk is defined as, “any unplanned event that has the potential to negatively affect the cost,
schedule or functionality of the project or the way the University operates.”
A risk, were it to occur, would involve a change from what is expected, assumed or planned, to a different
(usually worse) outcome. A risk may be a one-time event, repeated events or an ongoing situation. Risk
Management is a structured process that involves predicting and addressing risks as early as possible in
order to minimize their negative effects on the project.
5.16.6.2 Benefits of Managing Risk
All projects experience some degree of uncertainty. The FSRP initiative is an inherently risky project
because it involves fundamental change to many parts of the University including business processes,
policies, procedures, jobs, roles and responsibilities.
It is necessary to anticipate and manage risks before they occur in order to increase the chance of
success for the FSRP initiative.
5.16.7 Risk Management Approach
5.16.7.1 Risk Identification and Assessment
Initial identification and assessment of risks will be performed early in the Blueprint Phase. Identification
and assessment of new risks and reassessment of known risks will be performed throughout the project
as shown in Figure 10:
Initial Risk Update Risk
Assessment Assessment
Program Management
Business
Evaluation Project Business Realization Final Go Live Sustain Organization
Preparation Blueprint Preparation and
Support Application
Architecture
• Manage Risks
• Add New Risks
Figure 10 – Risk Management Lifecycle
The approach for managing risks on the FSRP initiative is documented in Section 6.2 of the Project
Charter.
4/29/2004 64 of 87
5.16.8 Organization Readiness Assessment
5.16.8.1 Overview
Change is an inevitable result of any business initiative. Resistance to change can cause the project to be
delayed, or in the worst case, to fail. For change to be accepted, UC must identify where resistance exists
or may arise, understand the extent to which the members of the organization are ready, willing and able
to move forward, and influence the supporting and restraining forces to help staff integrate the changes
into their daily activities.
An Organization Readiness Assessment is an approach that allows the FSRP Project Team to evaluate
the UC Community’s commitment, readiness and ability to accept and sustain the changes resulting from
the FSRP SAP implementation. It assesses:
• The environment, both internal and external to UC
• Behaviors, culture and organizational relationships among the various internal constituencies as
well as the relationship between the University and its vendor partners
• Past project successes and failures at UC
• Current internal project competitors/complements
• Compelling need for change
• Perceived impact and benefits of the FSRP initiative
• Issues, concerns and attitudes of the organization toward the FSRP initiative
• UC’s commitment, readiness and ability to accept and sustain the changes that will be required to
achieve FSRP goals and objectives
• Past training concerns.
5.16.8.2 Benefits of Organizational Readiness Assessments
Conducting an Organization Readiness Assessment is one of the most important activities in the early
stages of a change initiative such as the FSRP. The assessment provides a key source of information to
Project and Senior Management for:
• Understanding the risk factors and enablers associated with change
• Serving as a window into the success or failure of the FSRP initiative
• Providing a foundation for transition planning in subsequent phases of the project.
Failure to perform change readiness activities often results in a poor foundation on which to base
Transition Management activities. Milestones may be missed because issues that have not been
considered surface, impeding the progress of the project.
5.16.8.3 Organization Readiness Assessment Approach
The approach for the FSRP Organization Readiness Assessment activities has been designed with three
goals in mind:
• Gather input from affected members of the UC community
• Educate the UC community about FSRP and Change Management
• Begin the process of building buy-in among stakeholders.
5.16.8.4 Change Readiness Interviews and Surveys
During the Blueprint Phase, interviews and surveys will be conducted with and administered to
representatives from all levels of the UC Community in all applicable stakeholder groups. Interview and
survey questions and schedules will be submitted to FSRP Project Management and Executive
Leadership for approval prior to being executed. The Change Readiness Survey will form the basis of the
quantitative data, being supplemented by interview input.
4/29/2004 65 of 87
The interviews and surveys will be strictly confidential. Questions will be designed to draw out information
relating to a number of factors that have been found to directly affect organizational change efforts. These
factors include:
A. Change History – Looks at how leaders, managers and staff view change, value change, make
room for change, and have responded to change in the past.
B. Communication, Involvement and Participation – Looks at how the organization is kept
informed and how much people are included in the process of designing and implementing
change. Typically questions about this factor ask how much information about the change staff
receive, whether they feel they have the resources to manage the change, how much they are
involved in change efforts and how much they are motivated and capable of carrying out the
change.
C. Compelling Need for Change – Looks at the extent to which the organization understands the
goals and objectives of the FSRP initiative, how it solves important problems or creates strategic
advantages and how it relates to the future of the organization.
D. Skills/Training – Looks at whether the organization possesses the required skills and training
needed to meet the new roles and responsibilities associated with the new SAP system.
E. Impact – Looks at the extent to which people who will be affected by the implementation of the
new SAP system are aware of the specifics of what will be happening, when and how they will be
personally affected.
F. Resources Committed – Looks at the extent to which people perceive that adequately skilled
and motivated people have been made available to plan and implement the FSRP initiative.
G. Sponsorship – Looks at the extent to which people believe that the FSRP initiative is supported
and driven by key leaders who articulate a vision and reasons for the project that are perceived
as compelling and achievable by the rest of the organization.
H. Value People – Looks at how the organization values, respects, supports and helps people to
deal with the stress of change.
Change Readiness Assessment activities conducted at this stage of the project will provide early
indications of potential barriers and overall change readiness. Issues and concerns identified at this point
can be addressed by actions in one or more of the project strategies.
5.16.8.5 Change Readiness Report
The results of the surveys conducted during the Blueprint Phase will be compiled, analyzed and
presented in a Change Readiness Report. The results will help the FSRP Project Sponsors, FSRP
Project Management and FSRP Project Team understand both current and anticipated organizational
issues and enablers to change, including the risk factors that need to be addressed in order to minimize
the depth and length of performance disruptions brought about by the implementation of the SAP system.
The findings will be used to develop key change management activities that will be reflected in the
Communication Plan (incorporating Change Leadership and Change Agent activities), and the End User
Training Strategy.
5.16.8.6 Periodic Surveys
Change Readiness Surveys will be administered periodically throughout the life of the project to check for
new issues and verify that progress is being made in reducing resistance and removing barriers. Where
appropriate, surveys may be administered to a particular area or group in order to obtain more specific
readiness information and/or track the effectiveness of communication and training activities. During the
later stages of the project, the FSRP Project Team will have already begun to identify some of the details
of the key changes that will result from the FSRP initiative, which will be communicated to the UC
Community. As a result, more detailed questions and issues may be raised that can be adequately
addressed through the assessment activities or through appropriate plans.
4/29/2004 66 of 87
5.16.8.7 Focus Groups
Organization Readiness Assessment activities can also be used to track the effectiveness of the change
process over the life of the FSRP initiative. Prior to “Go-live”, a focus group comprised of a representative
group of users will be held to assess user views on training and communications. Another focus group will
be held after cutover to assess user views on process changes and system functionality.
5.16.8.8 Participants
Interviews and surveys will be conducted with participants from all levels of the UC Community including
senior management, middle management and front-line staff. Front-line staff are especially important as
they possess detailed knowledge and in many cases, actually drive the change. Participants will be
identified by the Project Sponsors, Executive Steering Committee, Project Management Office and FSRP
Project Team.
5.16.9 Stakeholder Analysis and Participation
5.16.9.1 Overview
Stakeholders are defined as, “individuals or groups who will either be affected by the FSRP
initiative or have the ability to impact the FSRP initiative or change effort”.
A Stakeholder Analysis is a technique that identifies the individuals or groups affected by or capable of
influencing the FSRP. An assessment of stakeholders and their issues is necessary to identify the range
of interests that need to be taken into consideration in planning change and to develop the vision and
change process in a way that generates the greatest support.
In order to anticipate, understand and correct barriers that may arise to the FSRP, UC needs to identify,
in advance, the key players, the influence that they have on the project, their primary association with the
FSRP initiative, and the players who are potential supporters and blockers to this effort. From this base of
information, UC can continue to identify and track key people’s/groups responses to change and the
effect it has on the implementation.
Stakeholder Analysis is used to:
• Ensure a smooth transition to the new SAP system
• Create and sustain acceptance and full ownership of the FSRP objectives by UC executives and
staff
• Understand UC’s stakeholders, their level of support for the project and their issues
• Actively engage key stakeholders
• Reduce the impact of barriers to change within UC
• Help ensure that the business benefits are realized.
5.16.9.2 Benefits of Stakeholder Participation
Gaining buy-in and commitment to the FSRP objectives is absolutely critical for success. As such, a
thorough and targeted approach to stakeholder participation and communication is essential. The
expected benefits of stakeholder participation include:
• Helps FSRP Project Management assess the change readiness of the organization
• Assists FSRP Project Management in identifying opportunities to mitigate/avoid possible
blockages to the implementation of the FSRP
• Stakeholders clearly understand the FSRP vision
• The scope of the FSRP is known and realistic expectations have been set
• Increased participation and ownership for developing and implementing process improvements
and acceptance of change
• Two-way communication channels are established
• Proactive management of employee morale and performance levels during the transition period
4/29/2004 67 of 87
• Increased willingness to learn and adapt to new technology, and
• Smoother transition to the target environment.
5.16.9.3 Stakeholder Analysis and Participation Approach
5.16.9.4 Identify and Segment Stakeholders
During the Blueprint Phase, the Change Management and Training Team will work with Project
Management, Project Team Members and representatives from the business areas to identify key
stakeholder individuals or groups that will be affected by the FSRP initiative.
The identified stakeholders will then be segmented into groups or individuals.
Segmentation is used to:
• Identify key stakeholders or individuals within UC whose assistance and active involvement will
benefit the FSRP
• Match the content and targeting of communications to the needs and behaviors of key
stakeholder groups and individuals
• Define logical groupings within the organization to achieve the most effective introduction
approach
• Focus the Project Team’s attention on real, identifiable individuals and groups to encourage a
more personalized approach to the engagement.
It is possible to segment stakeholders using a variety of different criteria, such as:
• Work location
• Organization basis (job role, functional area)
• Behavioral basis (state of readiness, attitude to the initiative)
• Needs or benefits basis (benefits sought, feature needs, information needs)
• Change roles (Sponsor, Influencer, Change Agent, Change Target, Change Leader).
It is also possible to segment using three simple categories:
• Individuals e.g. President, Sponsors, Project Managers
• Groups e.g. Executive Steering Committee, Business Process Owners, Staff
• External e.g. Unions, Suppliers, Government Agencies.
The initial approach for segmenting stakeholders will be determined during the Blueprint Phase, taking
care to avoid over-segmentation which can complicate the process with relatively little enhanced value.
Segmentation is an iterative process that will be done periodically throughout the life of the FSRP
initiative to ensure that key individuals and groups are aligned.
5.16.9.5 Analyze Stakeholder Issues and Roles
Building on the high-level segmentation of stakeholders in the preceding step, it is necessary to dig
deeper into understanding the level of support the FSRP has from stakeholder groups and individuals. It
is also necessary to identify who has the greatest influence over the FSRP and who will be highly
involved. Working with Project Management and Project Team Members, the FSRP Change
Management and Training Team will classify stakeholders according to the following:
• Their current level of support for the FSRP initiative
• Their required level of support for the FSRP initiative
• Their level of influence within the organization
• The level of impact the FSRP initiative will have on them
The analysis will also identify the expected change role of the stakeholder individual or group as follows:
Customer - Recipient of the change benefits whose views must be considered but
4/29/2004 68 of 87
who does not authorize or participate in the change
Influencer - Supporter and influencer who sometimes initiates change but cannot
lead it
Change Agent - Individuals who play a role in leading the implementation efforts at
various levels of the UC Community, typically at the direction of the
Project Sponsors/Change Leaders
Change Target - UC staff who must change in order for the FSRP initiative benefits to
be realized
Change Leader - Leader who demands and authorizes change
Information regarding stakeholder issues may also be collected as part of Organization Change
Readiness interviews and surveys and Risk Assessment workshops.
The results of the stakeholder analysis are used to develop Stakeholder Plan(s) which will include the
identification of Stakeholder Management Actions to be implemented.
5.16.9.6 Develop Stakeholder Plan(s)
After collecting information relating to stakeholders, the FSRP Team will have a better idea of how much
effort and attention is needed by each stakeholder individual or group, and when engagement activities
need to take place. One or more Stakeholder Plans will be developed that will form the basis for ongoing
stakeholder engagement and communication delivery throughout all phases of the FSRP initiative.
Stakeholder plans are closely aligned with the Communication Plan, which identifies different audiences
and their communication needs (see Section 9 for more information regarding the FSRP Communication
Plan). Figure 11 shows the relationship between Stakeholder Analysis and Participation activities and
Communications:
Develop Communication Strategy
Develop Communication Strategy Develop Communication Plan
Identify Develop Implement
Analyze Segment Develop Plans for
Identify
Stakeholders Analyze Segment Communication Plan
Stakeholders Stakeholders Stakeholders
Profiles
Stakeholders Stakeholders Stakeholders
Identify Assess Segment Develop a plan Identify specific
individuals or stakeholders stakeholders to tailor components of
groups who across the based on communications communications:
are affected following similar to meet the Segment/audience
by the FSRP dimensions: characteristics changing Message
initiative or Power & influence and current information Medium/vehicle
who can affect within the positioning needs of Initiator/source
the outcome organization across these stakeholders Timing/frequency
of the Project Degree of co- dimensions Feedback approach
operation they (stakeholder
need to exhibit for mapping and
project to be prioritization)
successful
Current level of
support
Figure 11 – Alignment of Stakeholder and Communications Activities
The purpose of developing Stakeholder Plans is to increase the likelihood of success for the FSRP SAP
implementation by ensuring that the interests of affected key individuals or groups are considered, and
that they are actively involved in the change and encouraged to support the change. Stakeholder Plans
are developed using a three-step approach:
1. Review Implementation Plan to Identify Key Milestones. In order to understand how each
stakeholder individual or group will be affected at each phase of the FSRP initiative, it is necessary to
understand how the project is going to roll out. This acts as a guide to the information and
involvement activities required for each phase.
4/29/2004 69 of 87
2. Determine Stakeholder Needs and Issues at Each Phase. Each stakeholder individual or group
may experience different reactions to each phase of the FSRP initiative. For example, what may
seem very threatening to one group may not even register with another, or one group may need to be
very involved in a phase while another may just require an update.
3. Design Change Management Activities to Respond to Stakeholder Needs and Issues. Based on
the needs and issues identified by phase, we will develop activities and methods, closely aligned with
the Communications Plan, to manage stakeholder responses to change throughout the life of the
project.
5.16.9.7 Implement Stakeholder Management Actions
The primary component of implementing Stakeholder Management Actions is the Communication Plan
which sets out how information will be exchanged, with whom and how communication effectiveness will
be measured over the life of the project.
Implementing Stakeholder Management Actions also involves the development of change management
and communication materials targeting key stakeholders or groups. Examples of such materials include
meeting agendas, presentation slides, handouts, website content, newsletters, surveys, e-mail content.
A number of change management events will be identified in the Communication Plan. These events may
include (but are not limited to) All-hands Meetings, Town Hall Meetings, Focus Groups, Demonstrations
and Brown Bag Sessions.
5.16.9.8 Monitor and Revise
As this is an iterative process, it will be necessary to periodically monitor whether stakeholders are
grouped appropriately, are beginning to support the FSRP in the desired way, and whether the change
management activities and events are effective.
5.16.10 Change Leadership
A key component of Stakeholder Participation is Change Leadership. Change is most successful if it is
led from within the organization. Change Leadership focuses on three main areas:
• Stakeholder Analysis and Participation (addressed above)
• Sponsorship
• Change Agents.
Building and supporting a network of Change Leaders and Change Agents is essential to deploying and
sustaining the changes that will result from the FSRP initiative. The Stakeholder Participation and
Communication strategies described in this document are designed to facilitate this by incorporating the
following principles:
• Sponsors will provide guidance to the implementation team, communicate project goals and
objectives to the UC Community and empower the team to make rapid decisions based on
project goals
• Stakeholders will be evaluated and the type and level of support required for each internal and
external stakeholder group identified. Targeted transition management activities will be planned
and executed to enable stakeholders to internalize the changes that will impact their daily
activities
• Change Agents from across the University will be identified and organized to deploy the change
throughout the organization, support the Stakeholder groups, execute the transition management
activities and provide feedback to the FSRP Project Team, Project Management, Executive
Steering Committee and Project Sponsors.
5.16.10.1 Sponsorship
Sponsorship is a key element of Change Leadership. The Project Sponsors are largely responsible for
directing the organization toward a new business or organizational model, facilitated by the FSRP
4/29/2004 70 of 87
initiative. The Change Readiness, Stakeholder Participation and Communication approaches described in
the Change Management Strategy, and the End User Training Strategy incorporate activities designed to
help support the Project Sponsors in their role as “Champions” of the FSRP initiative, responsible for
encouraging and guiding the change effort.
5.16.10.2 Change Agents
Developing a network of Change Agents is key to increasing the speed and smoothness of the transition
to the new system. A Change Agent is defined as, “an individual who provides services or leadership
to implement the change, typically at the direction of the Sponsors.”
It is largely through Change Agents that the interests and issues of stakeholder groups are identified and
addressed. The Change Readiness, Stakeholder Participation and Communication approaches described
in the Change Management Strategy, incorporate activities that are designed to identify, prepare and
involve Change Agents in addressing stakeholder concerns and deploying the changes throughout the
organization.
5.16.11 Communications Program
5.16.11.1 Overview
Communications can be defined as, “an integrated approach to conveying clear, consistent and
timely information to all stakeholders who can affect the success of the FSRP initiative.”
Communications are a key success factor for the FSRP initiative – they get the organization connected
and updated before, during and after the project. The information may become the foundation for training
and other roll-out activities, helping to ensure that these activities take place given a solid understanding
of the FSRP initiative and its implications.
It is important for the UC Community to receive timely, meaningful information in order to feel part of the
FSRP initiative. The more people that know about and understand how and why changes are happening,
the more likely they are to feel committed to the change effort. Communications are strongly linked to
stakeholder participation, as shown in Figure 4 above.
In order for communication to be effective, it must satisfy the specific informational needs of the UC
Community throughout the life of the FSRP initiative. As an individual’s or groups understanding of and
readiness for the impending change varies over time, so must the communication objectives and
messages, “moving” stakeholders through the commitment curve shown in Figure 12:
4/29/2004 71 of 87
High
STAGES FOR BUILDING PERSONAL
C COMMITMENT TO CHANGE
Internalization
O Individuals make FSRP
their own and create
M innovative ways to use
and improve
M
IT
M Adoption
Individuals are willing to
E work with and
implement FSRP
N
T Positive Perception
Individuals understand FSRP
impacts and benefits to them
Understanding
Awareness Individuals understand
Contact Individuals are aware of FSRP impacts to UC and
Individuals have basic scope and their functional area
heard FSRP exists concepts of FSRP
Low
TIME
Status Quo Vision
Figure 12 – Stakeholder Commitment Curve
5.16.11.2 Benefits of a Communications Program
The rumor mill is often one of the strongest and potentially most destructive forces in an organization.
Lack of correct understanding about the FSRP initiative may produce resistance to the change effort. If
this resistance is strong enough within the UC Community, the FSRP initiative risks failure. Typically,
employees prefer to receive news of an impending change through their normal communication channels.
Ideally, messages should precede the change as far in advance as possible in order to provide the
community with enough time to understand what is happening and why. The FSRP Communication
Strategy and Plan will be designed to provide the right information, at the right time, to the right audience.
The expected benefits of a planned, targeted Communications Program include:
• Increased credibility of the change process by involving stakeholders in the planning and
implementation of the FSRP initiative
• Reduced impact of rumors and negative perceptions as accurate and consistent information is
assembled and distributed on a proactive basis
• Increased satisfaction through the management of stakeholder expectations
• Increased understanding of the goals and objectives of the FSRP initiative.
5.16.11.3 Communications Program Approach
5.16.11.4 Communication Strategy
The purpose of the Communication Strategy is to define the overall approach that will be used in
conducting the communication activities for the FSRP implementation. Its primary goal is to provide
timely, accurate, essential FSRP-related information to all stakeholders. A secondary goal is to aid the
FSRP Project Team and UC Leadership in managing Stakeholder expectations. The Communication
Strategy has four components:
• Communication Principles
• Audience Definition
4/29/2004 72 of 87
• Communication Roadmap
• Communication Media Definition.
It is prepared as the first step in the communication process, laying the groundwork for the
Communication Plan without considering specific message content (which is developed as part of the
Communication Campaign Definition process described later in this document).
5.16.11.5 Communication Principles
Communication principles help to ensure consistency and effectiveness in the communication process. At
the beginning of the communications planning process, communication principles will be set out so that
there are clear directives that the entire Communications Team have agreed upon and that Management
has approved.
5.16.11.6 Audience Definition
Different groups within the UC Community will need different types of information over the life of the
FSRP initiative. The Stakeholder individuals and groups identified as part of the Stakeholder Analysis will
be further classified into audiences in order to effectively target appropriate communication messages
during the FSRP Communication Campaigns. Audience Definition involves the development of a list of
who is affected and how, and how best to communicate with them. Following this, it will be possible to
understand the different requirements of each audience segment (including both internal and external
audiences.)
5.16.11.7 Communication Roadmap
A Communication Roadmap will be developed that defines the specific phases or campaigns to be
conducted during the FSRP initiative, and their relative timing. The campaigns map to the commitment
stages identified in the commitment model shown previously in Figure 5 and the phases of the
implementation lifecycle. For the FSRP initiative, it is anticipated that there will be five communication
campaigns as follows:
• Awareness – inform Stakeholders that the FSRP initiative exists and make them aware of the
basic scope of the project and general concepts about SAP projects
• Understanding – give Stakeholders an understanding of the impacts of the new SAP system on
UC and their functional area
• Positive Perception – give Stakeholders an understanding of specific impacts and benefits of
the new SAP system and how they will be affected
• Adoption – actively involve Stakeholders and gain their acceptance of the new SAP system
including a willingness to work with and implement the new system
• Internalization – create a sense of ownership of the new SAP system among Stakeholders and
encourage them to create innovative ways to use and improve the system.
5.16.11.8 Communication Media Definition
There are various methods for delivering and receiving messages to and from audiences, ranging from
“non-personal” such as memos and posters, to “personal” such as meetings. Media will be selected
based on the messages the FSRP is attempting to deliver and what audience they are being delivered to.
Multiple media may be used in some cases to deliver the same message, this duplication helping to
ensure that key messages are received. There are a range of media choices that may be adopted
throughout the FSRP implementation and it is important to identify the available media and start to target
appropriate media to messages and audiences (which will be combined and documented in the
Communication Plan). Examples of communication media and channels include newsletters, surveys,
bulletin boards, websites, e-mail, CD ROM, briefings, town hall meetings, focus groups, demonstrations
and Q&A sessions.
4/29/2004 73 of 87
5.16.11.9 Communication Campaign Definitions
Once the overall, in-depth Communication Strategy is complete, the next step will be to create the
Communication Campaign Definitions for each of the five campaigns that have been identified for the
FSRP initiative. There are three parts to defining each Communication Campaign:
• Campaign Objectives
• Audience Requirements
• Message Definition.
5.16.11.10 Campaign Objectives
The purpose of developing campaign objectives is to identify critical factors that must be achieved for the
FSRP Communication Program to be successful. Throughout the execution of the Communication
Campaigns, the Communication Team will actively solicit feedback, comments and suggestions to
determine whether or not the messages delivered were successful. At the end of each campaign, these
objectives will be used to determine if the overall campaign has been successful.
If the objectives for a particular campaign are not achieved, the Communication Plan will be modified (e.g.
adding communications to the following campaign) until the objectives are fulfilled.
5.16.11.11 Audience Requirements
The definition of audiences and audience requirements are specific to each Communication Campaign.
Identifying audience requirements is helpful in consolidating numerous groups of Stakeholders into single
audiences, ensuring that the messages for each campaign help achieve the communication requirements
for all audiences and identifying common communication requirements that may be appropriate for mass
communication media. Audience requirements will be identified with the following characteristics in mind:
• Members of an audience often need the same kinds of information
• Members of an audience may be affected in a similar way during a particular campaign
• Members of an audience may have similar responsibilities toward the project during a campaign.
5.16.11.12 Message Definition
Each Communication Campaign will be focused on delivering a relatively small number of key messages.
Different messages will be applicable to different audiences at different times based on their information
requirements. Different messages also lend themselves to different types of communication media and
for these reasons we will specifically consider the messages for each campaign along with their
audiences, media, frequency and timing. The specific content of the key messages will be set out in the
Communication Plan.
5.16.11.13 Measuring Communication Effectiveness
It is important to track the effectiveness and impact of communication activities in order to ensure that
communication is clear, consistent and effective throughout the life of the FSRP initiative. Feedback may
be solicited through a number of formal and informal mechanisms such as surveys, interviews, meetings,
focus groups. These mechanisms will be determined during the communication planning effort. The
feedback collected will be documented and reviewed at regular intervals to assess the effectiveness of
the communication plan, identify unanticipated points of resistance or concern and determine the need to
update or refine the plan.
5.16.11.14 Communication Plan
The output from the above activities will result in the development of the FSRP Communication Plan. It is
the document that will be used to direct the actual preparation and delivery of the communication
materials. It defines the specific communications to be prepared and delivered, the timing for each
communication, and who the communication messenger is.
4/29/2004 74 of 87
The elements of the Communication Plan will identify:
• WHO Spokesperson and influencers
• SAYS WHAT Key messages
• TO WHOM Target audiences
• HOW Channels or communication media
• WHEN Timing and frequency
• WITH WHAT EFFECT Measurable results
5.17 End User Training Strategy
The success of the FSRP SAP implementation is largely dependent on how well UC management and
staff are equipped to operate in the new SAP environment. The degree to which UC can quickly adapt to
the new environment depends on the quality of the training materials and courses provided to users of the
SAP system.
To ensure that all personnel are adequately trained prior to using or working with the new SAP system
(an identified “Critical Success Factor” for the FSRP implementation), a Preliminary End User Training
Strategy has been developed and is available in the Ascendant ERP Toolset. The Preliminary End User
Training Strategy outlines a recommended training and performance support approach for UC’s future
SAP users that addresses three main questions:
• What training and performance support strategy should UC use?
• How should UC execute this strategy?
• What tools should UC use to effectively execute this strategy?
The Preliminary End User Training Strategy will be completed by including a definition of the training
approach, audience, materials, timeline and defined roles and responsibilities. It will also define the
training modules to be developed and delivered (the course curriculum) and the method of delivery.
The End User Training Strategy is a stand-alone document that will be updated as required and made
available in the Ascendant ERP Toolset.
4/29/2004 75 of 87
6 Project Standards and Procedures
To ensure consistency in the project work across all business and technical functional teams, clearly
defined standards will be employed. This will assist in facilitating a high standard of work in all areas,
resulting in a high quality implementation. Defined project standards will also make the tasks of project
planning, monitoring and control easier to achieve by providing a consistent basis for assessment of work
products and activity progress.
6.1 Communications Management Procedure
Communications Management includes the processes required to ensure timely and appropriate
generation, collection, dissemination and storage of project Information. UC and IBM team members will
maintain an open communications environment throughout the project, both within the project team and
amongst the UC user community.
The objectives of the Communications Management Procedure are to ensure that:
• All important project documentation is logged
• Project documentation is organized and securely stored
• Documentation is cross-referenced
• Documentation is handled efficiently and in a timely manner.
The primary mechanism for project-related communication will be the Ascendant ERP Toolset. IBM will
utilize the Ascendant ERP toolset (which will be accessible by all project team members) as a repository
for all project-related documents and artifacts, including:
• Work Products
• RWD Info Pak Documents (e.g. Business Process Procedures)
• Project Deliverables
• Issues
• Status Reports
• Project Change Requests
• Meeting Dates & Minutes.
6.2 Risk Management Plan
During the course of any project, risks will arise that require containment in order to ensure the progress,
or even the successful outcome, of the project. All projects inherently contain some level of risk, and a
well documented Risk Management Plan is an important element of the management of a project. The
primary purpose of the Risk Management Plan is to provide a clear, structured and repeatable process for
documenting, communicating and containing project risks.
Risks are defined as “Any unplanned event that has the potential to negatively affect the cost, schedule or
functionality of the project or the way the University operates.”
Risk Management is the:
• Timely identification and evaluation of potential risks
• Agreement on appropriate actions for the containment of the risk and the progression of such
actions
• Continuous involvement of management so that they understand and accept the potential risks
and their containment.
The objectives of the Risk Management Plan are to:
• Identify those risks that may impact the project
4/29/2004 76 of 87
• Ensure each risk is analyzed for probability and impact
• Ensure that there is an agreed Risk Containment Plan for each risk (including, if appropriate, a
plan to do nothing)
• Identify an appropriate contingency plan (as part of the containment plan) for high risks
• Allocate ownership for the risk and its containment plan to a Risk Action Manager
• Establish and monitor a procedure for reviewing and evaluating risks on an on-going basis,
adding new risks, removing obsolete risks and updating current risks
• Report the status of current risks.
6.2.1 Procedure
6.2.1.1 Identify
An initial identification of risks and their impact and probability, will take place early in the project at a risk
workshop. New risks are identified as the project proceeds.
6.2.1.2 Validate
All identified risks are raised to, and validated by the Project Manager(s). Once validated, risks are
documented in the “Risk” section of the Ascendant ERP Toolset.
6.2.1.3 Plan
Risk Containment Plans are created where required.
6.2.1.4 Control
Regular review and update of all risks will be conducted, including re-analyzing the risks and reviewing
the status of each Risk Containment Plan.
6.2.1.5 Report
The Risk Containment Plan will be reported regularly to the Executive Steering Committee and Project
Sponsors.
6.2.2 Risk Classification
Risks will be classified according to a combination of their probability of occurrence and their impact
should they occur, as shown in the table below.
PROBABILITY
Low Medium High
High Significant Major Maximum
IMPACT Medium Minor Significant Major
Low Minor Minor Significant
Figure 13 – Risk Classification Table
Risks will be managed according to their classification as shown in the table below:
4/29/2004 77 of 87
Classification Consequences Action Required
Maximum Drastic - risk could result in project failure • Risk is identified and documented
Major Material impact on project scope, • A Risk Containment Plan is developed
schedule or budget • A Risk Action Manager is assigned
Major impact on the way UC does • Resources are allocated to execute the Risk
business Containment Plan
Significant Material impact on system functionality • Risk is identified and documented
(but not project schedule or budget) • A Risk Action Manager is assigned and a Risk
Minor impact on the way UC does Containment Plan may be developed
business
Minor Slight - the project has sufficient resources • Risk is identified and documented
to contain the risk
In addition to their classification (above), risks can be allocated to two main categories:
• Project Risks – those risks that impact the performance of the project – i.e. the project’s ability to
meet project milestones, schedule and budget.
• Business Risks – those risks that impact the way UC does business, for example changing staff
roles or responsibilities to support the way the system operates.
6.2.3 Risk Management Responsibilities
Responsible Party Responsibility
Any project team member • Recognizes the existence of a risk and documents it in the Ascendant ERP Toolset.
Note: Risks will have been validated with the Project Manager(s) prior to being
documented in the Ascendant ERP Toolset.
Project Manager(s) • Facilitates an initial Risk Management Workshop to establish the risk management plan.
• Ensures that risks are validated, documented in the Ascendant ERP Toolset and if
appropriate assigned to a Risk Action Manager
• Schedules regular reviews of the Risk Containment Plan with the Risk Action Managers.
• Reports the status of the project risks to Executive Steering Committee and Sponsors
Risk Action Manager • Creates/Updates the Risk Containment Plan in conjunction with the Project Manager(s)
• Executes the Risk Containment Plan
• Communicates risks and their Risk Containment Plan to Project Manager(s) and other
stakeholders as directed
6.2.4 Risk Escalation
It is the responsibility of the Executive Steering Committee Co-Chairs to validate each Risk and to
escalate the Risk Containment Plan as appropriate.
6.3 Project Status Reporting Procedure
Reporting project status is an integral part of planning and controlling the project. The objectives of the
Project Status Reporting Procedure are to:
• Inform all levels of management of the status of the project
• Compare actual figures with plans in order to take corrective actions
• Provide succinct information that is appropriate for its audience.
Status Reports will be created from reporting templates, available in the Ascendant ERP Toolset.
The following table summarizes the types of progress reports to be used during the course of the project:
Report From To Timing
Individual Status Team Members Team Leads As needed.
Team Status Team Leads UC/IBM Project Managers Weekly at the Team Leads Meeting
4/29/2004 78 of 87
Report From To Timing
Twice Monthly Status IBM Project UC Project Managers Twice each calendar month at the first PM
Manager Meeting of every month AND at the PM Meeting
immediately before the Executive Steering
Committee and Sponsors meetings.
7 Keys to Success IBM Project UC Project Managers/ This report is a component of the “Bi-weekly”
Manager Sponsors/ Executive status report and will be updated once a month –
Steering Committee on each Monday before the Executive Steering
Committee and Sponsors meetings
Reporting Roles and Responsibilities
Role Responsibility
Team Member • Identify work completed since last status report.
Team Leads • Compare weekly reports with project plans/schedules to identify variances and potential problems.
&
Project Managers • Review variances and problems with staff to identify root causes and possible remedial actions.
• Review tasks to be completed for achievement of next deliverables and milestones with those
responsible for doing the work and agree actual/likely completion dates.
• Assess likely impact of any variances upon current and future tasks and milestones including estimates
for effort, costs, completion dates and resource requirements.
• Identify appropriate remedial actions and discuss and agree to their feasibility and effectiveness with
those who are responsible.
• Store reports in the Ascendant ERP Toolset and send to Project Manager(s).
6.4 Project Meeting Procedure
The tables below summarize the meetings to be held during the course of the project. Meeting minutes
are kept for Project Sponsor, Executive Steering Committee, Project Managers and Team Leads
meetings and conference calls. All meeting minutes will reside in the Ascendant ERP Toolset and will be
maintained by the Project Administrator. Meeting minutes will be made available no later than three days
after the meeting.
6.4.1 Team Meeting
Objective: General project communication and co-ordination
When: As required - To be determined by Team Leads
Agenda: 1. Opening (Announcements)
2. Project Plan Status
3. Deliverable Review
4. Issue Log Review
5. Problems and Concerns
6. Action Items
7. Decisions Taken
8. Key Accomplishments
9. Planned Activities
10. Other Business
11. Close
Participants: Team Members
Minutes: Determined by Team Leads
6.4.2 Team Leads Meeting
Objective: Project communication and co-ordination between the project team leads and project management
When: Weekly - Monday at 3PM
Agenda: 1. Opening (Announcements and confirmation of previous minutes)
4/29/2004 79 of 87
2. Project Plan Status
3. Deliverable Review
4. Issue Log Review
5. Areas of Concern
6. Action Items / Decision Taken
7. Key Accomplishments
8. Planned Activities
9. Other Business
10. Close
Participants: Project Team Leads, Project Managers
Minutes: Project Administrator
6.4.3 Project Managers Meeting
Objective: Project communication and co-ordination between the UC and IBM project management team
When: Weekly – Monday at 4PM
Agenda: 1. Opening (Announcements and confirmation of previous minutes)
2. Project Status
a. Project Plan
b. Deliverable Status
c. Budget Status
d. Issue Status
e. Scope Changes
f. Risk Management Plan
g. Key Accomplishments
h. Planned Activities
3. Areas of Concern
4. Action Items / Decisions Taken
5. Other Business
6. Close
Participants: UC and IBM Project Managers, ESC Co-Chairs, Invitees
Minutes: Determined by Project Managers
6.4.4 Executive Steering Committee Meeting
Objective: Project communication and co-ordination with the Executive Steering Committee to facilitate project
oversight
When: Third Thursday of Each Month, 10:00 – 11:30am (with exceptions)
Agenda: 1. Opening (Announcements and confirmation of previous minutes)
2. Project Status
a. Project Plan
b. Deliverable Status
c. Budget Status
d. Issue Status
e. Scope Changes
f. Risk Management Plan
g. Key Accomplishments
h. Planned Activities
3. Update from Sponsors Meeting
4. Areas of Concern
5. Action Items / Decisions Taken
6. Other Business
7. Close
Participants: Executive Steering Committee, Project Managers, Invitees
Minutes: Project Administrator
6.4.5 Project Sponsors Meeting
Objective: Project communication and co-ordination with the Project Sponsors to facilitate sponsor participation
When: Third Wednesday of Each Month, 10:00 – 11:30am (with exceptions)
4/29/2004 80 of 87
Agenda: 1. Opening (Announcements and confirmation of previous minutes)
2. Project Status
a. Project Plan
b. Deliverable Status
c. Budget Status
d. Issue Status
e. Scope Changes
f. Risk Management Plan
g. Key Accomplishments
h. Planned Activities
3. Areas of Concern
4. Action Items / Decisions Taken
5. Other Business
6. Close
Participants: Project Sponsors, Executive Steering Committee Co-chairs, Project Managers, Invitees
Minutes: Project Managers
6.5 Project Documentation Standards
High quality documentation is vital to a successful project and is used to:
• Accurately describe the business process design to be implemented
• Ensure that the reasons for process and system design decisions are clearly understood
• Fully document the required policies and procedures
• Provide comprehensive system configuration descriptions, for the purposes of system support
and future systems development
• Facilitate the efficient and user-friendly operation of the new system, by means of simple
procedural documentation
• Enable the success of the system and the business process design in achieving the project
objectives and planned benefits to be audited and built upon
• Ensure consistent project documentation presentation to key business process owners and lead
users.
Documentation templates will be developed by project teams, approved by Project Management and
deployed to the Ascendant ERP Toolset for team members to use.
Wherever possible, templates provided by RWD Info Pak and the Ascendant ERP toolset (under the
classification of “Process Documents”) will be used, with modifications to fit the project’s requirements.
The following documents will be based on documentation templates and subject to documentation
control:
• Business Blueprint (Process Definition Documents)
• Fit-Gap Report
• Business Process Master List
• Test Scripts
• Business Process Procedures
• Detailed Functional Specifications.
Completed project documents will be stored in the Ascendant ERP Toolset. Some process documents
may be a combination of the Ascendant ERP Toolset document plus an attached MS Office document -
for example, Business Process Procedures.
6.6 Standard Tools and Resources
During the course of the FSRP SAP implementation, a standard set of tools will be used to ensure
compatibility of documentation between teams. The following set of tools will be utilized for this project:
• RWD Info Pak
• Microsoft Office (Word, Excel, PowerPoint, Visio) – Various Project Documents
4/29/2004 81 of 87
• Microsoft Project – Project Plan
• Ascendant ERP Toolset – Document control, issue management, status reporting, project
calendar, project contact details (email address, phone number, etc), reference material (how-to
guides, manuals, etc)
• SAP IMG – Documentation of configuration
6.7 Issue Management Plan
During the course of any project, issues will arise that require resolution in order to ensure the progress,
or even the successful outcome, of the project. Issues are a normal project occurrence and an active,
lengthy and well managed issue log is a sign of a healthy project. The objective of the Issue Management
Plan is to provide a clear, structured and repeatable process for documenting, communicating and
resolving project issues.
An issue may be defined as, “An identified “matter” that may impact project objectives, timeliness, scope
or success and requires a final decision or solution to resolve.” Additionally, the person raising the issue
is doing so because he or she is not sufficiently empowered or informed to be able to resolve the issue.
Issues generally require some level of escalation or collaboration for their resolution. Any project team
member can raise an issue, and it is the responsibility of all project team members to raise issues and
actively participate in their resolution.
Issue Management is a process to ensure that all issues are identified and resolved with minimum impact
to the project. Issue Management requires that issues are:
• Raised and Validated
• Documented (in the Ascendant ERP Toolset)
• Reviewed
• Assigned an Action Manager (person responsible) and resolution timeline. Where possible issues
will be assigned to Team Members for resolution.
• Worked and Reported
• Escalated (if necessary)
• Approved (if necessary)
• Resolved
• Closed (and marked as a Cutover Issue for the cutover plan if appropriate).
Any situation arising during the execution of the project that will impact the project objectives or schedule
must be processed using the Issue Management Plan.
Overall successful issue management is a primary responsibility of the UC and IBM Project Managers.
Those responsible for resolving issues will use reasonable efforts to resolve issues promptly and are
empowered to escalate issues to higher level to gain resolution.
6.7.1 Issue Management Responsibilities
Responsible Party Responsibility
Core Project Team Members • Raise issues to resolve problems and ensure the project proceeds according to
schedule, budget and with the necessary functionality.
• Document issues in the Ascendant ERP Toolset.
• Communicate issues, including their status, progress and resolution, to impacted
parties.
Team Leads / Project Manager(s) • Ensure that issues are adequately validated and documented, and assigned an
Action Manager (Person Responsible).
• Update project plans to reflect any changes introduced by the resolution of the
issue.
4/29/2004 82 of 87
• Perform QA on Issue documentation to ensure procedures have been followed.
Action Manager • Resolve issues as promptly as possible and escalate if necessary.
• Ensure that issues are managed and documented in a timely and accurate
manner.
Team Leads / Project Manager / • Accept escalated issues and contribute to their timely resolution.
Executive Steering Committee / Project • Evaluate alternative resolution approaches.
Sponsors • Approve resolution of an issue.
6.7.2 Issue Escalation
Issues will be escalated to the following levels:
Level Responsible Party
1. Team Team Member(s) / Team Lead(s)
2. Project Project Manager(s)
3. ESC Co-chairs Executive Steering Committee Co-chairs
4. Steering Committee Executive Steering Committee, IBM Project Executive, SAP Consulting
Manager
5. Sponsors Project Sponsors
*Note: The Executive Steering Committee Co-chairs are empowered to escalate issues to either the
Project Sponsors or Executive Steering Committee for resolution.
6.7.3 Issue Attributes
Issues logged in the Ascendant ERP Toolset will have the following attributes:
Field Description
Title A brief but unique description of the issue.
Team The functional or process team which has ownership or main responsibility for this issue (usually the team
that the Action Manager resides in).
Status Open ................................ Issue is open and is being managed
Pending ........................... The Action Manager (person responsible) has resolved the issue and the
resolution is pending approval
Closed.............................. Issue has been closed
Closed & Cutover............ Issue has been closed and marked as a cutover issue for future reference (to be
included in the cutover plan)
Editors Person(s) who can edit/update this issue (usually the Action Manager)
Raised By Person(s) who raised the issue (usually the Editor)
Action Manager The project team member assigned for research and resolution of this issue
Access Public or Private access level. If private then issue may be viewed by only those team members, or groups,
explicitly listed as responsible or as reviewers. If public then issue may be viewed by all with access to
project server.
Priority The priority with which this issue must be resolved. Used in conjunction with the issue’s criticality (below) to
determine which resources will be allocated to resolving issues.
High ................. must be resolved in the next 24-48 hours
Medium ............ must be resolved within the next week
Low .................. must be resolved within the next month
4/29/2004 83 of 87
T Tu,incrtqeI,mre
y IeiggieeuMpyEr
p hinpcsssioadct
e osw:nioRoSctoh
etcaDnue,mSrO
aylDaertc t or
ipueeccrp s
:eni , d
std( o ee e
ceea w S
Ih o R
ts s
oo mr.e.oapjUpap
un hctfrrerc. u“
r eeisedeopT e e
c psocpv)j b s
e tuitsehc
sa
St N”tmeamosmerS
DAaTfvuinuipe
ep Lee(mrsre)
sr bsntuetat
co rcsalqtra
rv eoareino
il srftteg c
p eiuey
i oftx e
uh u
rAevpsitre
epsirttea
noDwosiud
fp hr
i
CtrAdthsee
RtrTealdoic:ineBs
udveapssld
t rlnvubt
t aec h u
b le
ooasp
qAaehvtoeudclgts
upOfraodeihMeai
e oaeasrt,nna nn
s lnaotseig a mde
e w prel ne,
e rq e
yl
edvhooutvslTcanu
RalDwpis
elnahrre
qe tioed
ua ecvq
ed thau
si eale
ee y st
p
r
pD i.ItiSals.ite
r g.utmccioOnct
o h.eWpohoi(fat
v b shhsSnatg nh
y aaitzlecge
At H..sIeperrRiho
Cy M..tYcfrtc.a
r e.aas.,uee.n
i d.ytmcneoO
t i.UspghouR
c u whu)cuess
a . IdiSSlss
l msonooaug
i uevnerm
eMsidic
sAaegRp
Cbceanc
Lac oa
t .
I t,e r
..hsapdRe
CDqLeaeaenoairte
riuTo.cs(irtpsi
itro.utl.cgaa ls
tneehebvealsevu
cR htArassnat s
ae e.loernil
l w(hshitzm
a a.oevonia
e .suurnanc
attMbf o
thAea
es ag
eiihnttnprinkoi
xndd)erdspette
Aa htaebpy)
ct ehmnglop
o dituee
NteTixnoydslteh
tD Tetiomeboo
t as c
A a
x eehbn.
eo hrtseu
Nt Tinams
scde b
cniect
teot e
io
c e
C tt
Amitntesirddnltel
Rt Tuohnuon‘iplro
oe hees(naan’ca/
osaimelonimeiadr
ldnieataeonofb s
tedmaiecwudtae e
t paioi
n o so
a
u
CloTodopdycngiosv
ennh.raigahcri e Field
es sincn kso )
nd ebdtcdreh
cs ellihwepahr
s env e s d
r sl il
d ss
a
iv
er
i c ro
asnhcaueutte/ny
ia reesiwrrnes
ot ihrnsheoov
m pttvsln .
tetetirtevette
RAmTaforahoddUi
n e maeoiioj t
a ues
me ntothlou
t nmle h
In Aifnirti
ps yorhtvte
a aaaabai.
c dlttens Description
Ci Denis s
ot ehiag
m sosse
u i s
e cwurd
Ri Eehomo
Ro Aalnwii.
en taaial
en dnlovvi
sa rteee.
o raee.
o tehons
l itwl
l besso
t
oD ecturdu
s t iovtlfe
t e tuthut
e otaesh
s hseee
u nd o
t e t
No nlrtros
SeecaSfnscleozaaE
6coMimtendasceLevel
iaoiaeoawtt:rFl
chpospdneccftopr
.SnagcPailragtitR
pc.n,Mtclw
oaemynneaonahR c
8nsaloumseunaimfP
ptareoadue,ta. o
mgeoel v
i ge
mynojpenee diP
lnAjrb hi
etrdoegtrssnn
r
u The escalation level for issue.
hPesrs”hnto
ersfcaohb
mdon r
Tnsnptesiil S
·oS“ ca s
cc o
io
mp
ee 1. Team .................................... Team Members / Team Leads
2. Project ................................. Project Managers
3. Steering Committee ............ Executive Steering Committee, ESC Co-chairs, IBM or SAP
¤
4/29/2004 84 of 87
• Functionality Scope
• Organizational Scope
• Technical Enhancements Scope
• Technical Infrastructure & Security Scope
• Interface Scope
• Data Conversion Scope
• Reports and Forms Scope.
Scope Management requires the following approach:
• Define detailed scope (across all the 8 dimensions shown above)
• Agree to the detailed scope by obtaining sign-off from the project management team and key
stakeholders
• Communicate the scope to the entire project team
•
Manage all changes to scope via a rigorous scope control process that operates within the
project governance structure
The Project Scope is defined first at a high-level, and then in more detail as Blueprinting occurs, as
shown in the diagram below.
High Level Scope
Definition
Detailed Scope
Definition
Signoff
Manage Scope
People
Evaluation
Project Go Live and Process
Business Final
Realization Sustain
Preparation Blueprint Preparation Support
Knowledge
Technology
Figure 14 – Project Scope Definition
The reference document for the high-level scope definition for FSRP is the IBM Statement of Work
(SoW). Any variation from the SoW defined scope that has a material impact on project cost, schedule or
functionality will be documented in Project Change Requests (PCR’s) and processed using the Project
Change Control Procedure.
6.8.1 Project Change Control Procedure
Changes to the scope of the project will be made through the following Project Change Control Procedure
(PCCP):
• A Project Change Request (PCR) will be the vehicle for communicating change. The PCR must
describe the change, the rationale for the change and the effect the change will have on the
project
• The designated Project Manager of the requesting party will review the proposed change and
determine whether to submit the request to the other party. The submitting party will indicate
whether the change constitutes minor or major change as defined in this document.
• Both Project Managers will review the proposed change and approve it for further investigation or
reject it. IBM will specify any charges for such investigation. If the investigation is authorized, the
Project Managers will sign the PCR, which will constitute approval for the investigation charges.
4/29/2004 85 of 87
IBM will invoice UC for any such charges. The investigation will determine the effect that the
implementation of the PCR will have on price, schedule, UC staffing requirements and other
terms and conditions of this SOW.
• A written Change Authorization must be signed by both parties to authorize implementation of the
investigated changes.
6.9 Project Planning and Monitoring Procedure
The UC and IBM Project Managers are responsible for monitoring the overall performance of the project.
The project will implement an overall project plan and one or more detailed plans for implementation
threads (e.g. Technical, Business Process Workshops, etc). The overall project plan will be developed at
a detailed level prior to each project phase, not later than one month before the start of the phase. The
IBM Project Manager will maintain this detailed plan throughout the project and the plan will be updated
twice each month.
The IBM Project Manager will maintain, on a weekly basis, IBM time spent on the project and status
(percentage completed) of the deliverables.
Time away from the project (i.e. for vacations and/or holidays) for both UC and IBM staff will be recorded
in the Ascendant ERP Toolset calendar.
6.10 Quality Assurance Standards
Quality assurance is a necessary function in a project as complex as an SAP implementation. It is vital to
ensure that the project is “on track” for success. To provide this assurance requires regular assessments
from an experienced and objective viewpoint, independent of the day-to-day stresses of the project. The
objectives of periodic project reviews are to ensure that:
• Project goals are aligned with those of UC
• Project standards and procedures are being followed
• The project has sufficient resources
• Responsibilities are understood and well defined
• Business process changes are being effectively managed
• Time schedules and budgets are being adhered to.
IBM will conduct scheduled quality reviews at key project milestones, delivered by senior IBM consultants,
to ensure both the integrity of the system design and the achievement of the project objectives and
identified benefits. These reviews may be carried out by means of interviews with key personnel,
attendance at team meetings and work sessions, and by assessments of project plans and
documentation. In so doing, attention is given to ensuring that:
• Objectives and benefits of the project are defined, achievable and understood
• The Project does not deviate from its defined objectives
• The Project procedures and standards are established, communicated and understood
• The Project organization is defined and proper resources are allocated
• Project roles and responsibilities are clearly defined and understood
• Project team members are working effectively as a team
• Project issues are being raised and resolved
• Organizational and business process changes are managed effectively
• Business policy and procedures are clearly defined and changes are being managed effectively
• Project plans are realistic, consistent and sufficiently detailed
• Time schedules and budgets are adhered to
• Both systems and business process integration are delivered
4/29/2004 86 of 87
• System design and testing procedures are sufficiently rigorous
• Technical infrastructure and conversion plans are adequate
• Viable system operational procedures are established
• Viable end-user training plans have been established and are being adhered to
• A viable help desk structure has been established.
4/29/2004 87 of 87