[Project Name]
Data and Conversion Strategy
Prepared By:
Prepared For:
Date Created:
Last Updated:
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
Document Overview
Author’s Name
Department Name
Month Day, Year
August 13, 2008
RASCI Alignment
DATA AND CONVERSION STRATEGY
PROJECT NAME
Revision Log
Revision
Date
1.0
MM/DD/YY
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Initials
Description of Revision
Initial Draft
Page 2 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
Table of Contents
1) INTRODUCTION ................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
2) BACKGROUND...................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
2.1) PURPOSE........................................................................................................ ERROR! NO BOOKMARK NAME GIVEN.
2.2) SCOPE AND APPLICATION .............................................................................. ERROR! NO BOOKMARK NAME GIVEN.
3) DATA ADMINISTRATION STRATEGY ........................................... ERROR! NO BOOKMARK NAME GIVEN.
3.1) DATA APPROACH .......................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
3.1.1) Critical Success Factors ................................................................................ Error! No bookmark name given.
3.1.2) Scope ............................................................................................................. Error! No bookmark name given.
3.2) DEFINITIONS .................................................................................................. ERROR! NO BOOKMARK NAME GIVEN.
3.2.1) Data ............................................................................................................... Error! No bookmark name given.
3.2.2) Data Ownership ............................................................................................ Error! No bookmark name given.
3.2.3) Data Administration ...................................................................................... Error! No bookmark name given.
3.2.4) Data Value Changes vs Data Structure Changes .......................................... Error! No bookmark name given.
3.2.5) Data Repository ............................................................................................. Error! No bookmark name given.
3.3) DATA ADMINISTRATION RULES .................................................................... ERROR! NO BOOKMARK NAME GIVEN.
3.3.1) Introduction ................................................................................................... Error! No bookmark name given.
3.3.2) Data ............................................................................................................... Error! No bookmark name given.
3.3.3) Data Organization ......................................................................................... Error! No bookmark name given.
3.3.4) Processes ....................................................................................................... Error! No bookmark name given.
3.3.5) Systems .......................................................................................................... Error! No bookmark name given.
3.4) SUPPORTING PRINCIPLES OF DATA ADMINISTRATION ................................... ERROR! NO BOOKMARK NAME GIVEN.
3.4.1) Data ............................................................................................................... Error! No bookmark name given.
3.4.2) Organization.................................................................................................. Error! No bookmark name given.
3.4.3) Processes ....................................................................................................... Error! No bookmark name given.
3.4.3.1 Management of Data Change ..................................................................... Error! No bookmark name given.
3.4.3.2 Data Structure Changes............................................................................... Error! No bookmark name given.
3.4.3.3 Features of the Change Control Procedure ................................................. Error! No bookmark name given.
3.4.3.4 Data Value Changes .................................................................................... Error! No bookmark name given.
3.4.3.5 Data Monitoring ......................................................................................... Error! No bookmark name given.
3.4.4) Systems .......................................................................................................... Error! No bookmark name given.
3.4.4.1 Automation.................................................................................................. Error! No bookmark name given.
3.4.4.2 Service Levels ............................................................................................. Error! No bookmark name given.
3.4.4.3 Security ....................................................................................................... Error! No bookmark name given.
3.4.4.4 Transparency .............................................................................................. Error! No bookmark name given.
4) CONVERSION REQUIREMENTS ...................................................... ERROR! NO BOOKMARK NAME GIVEN.
5) ASSUMPTIONS AND CONSTRAINTS ............................................... ERROR! NO BOOKMARK NAME GIVEN.
6) CONVERSION APPROACH ................................................................ ERROR! NO BOOKMARK NAME GIVEN.
6.1) DATA MAPPING ............................................................................................. ERROR! NO BOOKMARK NAME GIVEN.
6.2) DOWNLOAD PROGRAMS ................................................................................ ERROR! NO BOOKMARK NAME GIVEN.
6.3) ASCII FLAT FILE .......................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
6.4) UPLOAD PROGRAM........................................................................................ ERROR! NO BOOKMARK NAME GIVEN.
6.5) INTERFACE TABLE ......................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
6.6) TRANSLATION PROGRAMS............................................................................. ERROR! NO BOOKMARK NAME GIVEN.
6.7) APPLICATION PRODUCTION TABLE ............................................................... ERROR! NO BOOKMARK NAME GIVEN.
6.8) TESTING ........................................................................................................ ERROR! NO BOOKMARK NAME GIVEN.
6.9) CONVERSION EXECUTION PLAN .................................................................... ERROR! NO BOOKMARK NAME GIVEN.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 3 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
7) IMPLEMENTATION APPROACH ..................................................... ERROR! NO BOOKMARK NAME GIVEN.
7.1) PLANNING APPROACH ................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
7.2) DELIVERABLES .............................................................................................. ERROR! NO BOOKMARK NAME GIVEN.
8) CONVERSION TEAM ORGANIZATION .......................................... ERROR! NO BOOKMARK NAME GIVEN.
8.1) ....................................................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
8.2) ROLES AND RESPONSIBILITIES ...................................................................... ERROR! NO BOOKMARK NAME GIVEN.
9) CONVERSION RESOURCE REQUIREMENTS ............................... ERROR! NO BOOKMARK NAME GIVEN.
9.1) SOFTWARE .................................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
9.2) HARDWARE ENVIRONMENT .......................................................................... ERROR! NO BOOKMARK NAME GIVEN.
9.3) NETWORK FILE TRANSPORT .......................................................................... ERROR! NO BOOKMARK NAME GIVEN.
9.4) STAFFING ...................................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
9.5) OTHER ........................................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
10) PROJECT STANDARDS ..................................................................... ERROR! NO BOOKMARK NAME GIVEN.
10.1) TOOL STANDARDS ....................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
10.1.1) Application Tools ........................................................................................ Error! No bookmark name given.
10.1.2) Conversion Tools ......................................................................................... Error! No bookmark name given.
10.1.3) Source Control ............................................................................................ Error! No bookmark name given.
10.1.4) Version Control ........................................................................................... Error! No bookmark name given.
10.1.5) System Management Tools .......................................................................... Error! No bookmark name given.
10.2) DELIVERABLE NAMING STANDARDS ........................................................... ERROR! NO BOOKMARK NAME GIVEN.
11) DATA CLEANUP PROCESS .............................................................. ERROR! NO BOOKMARK NAME GIVEN.
11.1) DATA CLEAN UP ......................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
11.2) KEY DATA TRANSLATIONS ......................................................................... ERROR! NO BOOKMARK NAME GIVEN.
12) USER ACCEPTANCE CRITERIA ..................................................... ERROR! NO BOOKMARK NAME GIVEN.
12.1) DELIVERY ................................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
12.2) DATA ACCEPTANCE .................................................................................... ERROR! NO BOOKMARK NAME GIVEN.
13) VERSION CONTROL PROCEDURES ............................................. ERROR! NO BOOKMARK NAME GIVEN.
14) PROJECT METRICA .......................................................................... ERROR! NO BOOKMARK NAME GIVEN.
15) PROJECT MILESTONES ................................................................... ERROR! NO BOOKMARK NAME GIVEN.
16) CONVERSION RISKS ......................................................................... ERROR! NO BOOKMARK NAME GIVEN.
17) DOCUMENT SIGN OFF ..................................................................... ERROR! NO BOOKMARK NAME GIVEN.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 4 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
1) Introduction
This document is used to determine the strategy for meeting the defined conversion
requirements. The Data Conversion Strategy is intended to provide a roadmap for
performing the conversion of data from the legacy system to the new system. The tasks and
resources needed to fulfill this strategy are also discussed in this deliverable. The strategy in
the deliverable template is based upon the proven conversion methods practiced by the
Oracle Advanced Conversion Technologies (ACT) Group.
The Data Conversion Strategy is used as follows:








The conversion team uses this document to communicate to the client the strategy
for successfully converting their legacy data to the new Oracle system(s).
The conversion team uses this document as a roadmap for performing the
conversion. All members of the team, both consultants and client team members,
should understand and follow the same strategy.
The project manager uses this document to understand how the conversion team
plans to perform the conversion, and how the conversion effort may impact the
overall project.
Therefore, the readers of the Data Conversion Strategy include the following:
the client project leader who should sign-off the conversion requirements and
strategy
each member of the conversion team
the project leader who needs to review and determine what other groups should be
given the document
Use the following criteria to review this deliverable:
Is the strategy understood by those on the distribution list for this deliverable?
Are all assumptions, constraints, and risks which could impact the conversion
process stated and understood?
2) Background
2.1) Purpose
The purpose of this document is to provide University of Chicago with a strategy for
planning the conversion project to ensure the highest quality conversion. This deliverable
document summarizes the key areas to focus on in organizing, planning, and executing the
conversion project tasks and deliverables.
2.2) Scope and Application
The application of this Data Conversion Strategy provides direction for all phases of data
conversion.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 5 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
[ Include the scope of data conversion activities such as departments, systems, etc]
3) Data Administration Strategy
3.1) Data Approach
3.1.1) Critical Success Factors
Critical for the successful implementation of all the above requires all individual
business units to share:




Common data
Common data structures
Business ownership of Data
Comprehensive Data transformation and administration processes
These factors will form the cornerstone of the University’s ability to support their
business processes and enable business decisions to be made with confidence. The
Data administration processes adopted by the University of Chicago will be aligned
with the principles for operational excellence and other examples of internal and
external commercial best practices.
3.1.2) Scope

Define Data and Data administration

Distinguish Data structure changes from Data value changes. The emphasis of this
document is on Data value changes. Data structure changes will follow the
change control process.

Provide overall rules and supporting principles for data, organization, process and
systems for the administration of Data.
3.2) Definitions
3.2.1) Data
Data is defined as being business object reference data that is stored within a system
and is used in business processes that operate using the system. Data is critical to the
operation of the business as it is fundamental to many business transactions and
reporting. Examples of Data include materials, vendors, customers, cost centers, etc.
3.2.2) Data Ownership
Data ownership refers to who, in terms of the organization, is responsible for the field
contents of a Data record. Ownership is decentralized as the field values are by their
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 6 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
very nature specific to business processes. The most appropriate business process to
have ownership may be obvious (e.g. Chart of Accounts), but it is not so obvious who
should have ownership of other data. (SEE APPENDIX E)
Data ownership will be assigned to named individuals, and will apply at the relevant
organizational level for each object/element (e.g. global, BUSINESS UNIT, sales
organization).
3.2.3) Data Administration
Data administration is defined as the establishment, operation and communication of
the principles, processes, technical infrastructure and tools, roles and responsibilities
for Data management within the business.
Data administration applies in the following data change context:








Creation of new data
Extension of existing data to other organizational units
Changes
Archiving/deactivation
Deletion
Reactivation
Rationalization
Propagation of data to related systems
Data Administration process scope includes:









Establishment of Data ownership
Maintenance access requirements
Data authorization
Change process timeliness and required accuracy level
Processes for all change requirements
Process completion and continuous improvement auditing
Communication and notification of changes
Process performance measurement
Error handling
3.2.4) Data Value Changes vs Data Structure Changes
Data Value Changes are changes to existing data values, or the creation of new data
values within the existing data structures for the data object. The change procedures
for data objects can vary from being formal for “static” data (e.g. Organization
Structure elements controlled at a global level) to being operational business rules for
dynamic Data such as materials. Examples of Data Value Changes include:

Adding new values for a data object e.g. add a new material or vendor
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 7 of 26
DATA AND CONVERSION STRATEGY


PROJECT NAME
Updating existing values
Marking an existing value as inactive e.g. customer inactive because trading has
ceased.
Data Structure Changes are changes and extensions to the structure of existing data
objects, or the creation of new data objects to allow the capturing of additional
information, which cannot be captured with existing data structures. Examples of
Data Structure Changes include:


Creation of new data objects e.g. introduction of a new material type which would
be handled by the DT
The Data Team will not own changes to the organizational structure e.g. changes
to plants, sales organizations perhaps as a result of an acquisition. That would fall
under the responsibility of the Functional teams.
The process differs for these two types of change
3.2.5) Data Repository
The role of the Data Repository is to define, structure, standardize and store
commonly used data held at a global level thereby ensuring all systems and processes
have access to relevant, consistent and up-to-date common information.
3.3) Data Administration Rules
3.3.1) Introduction
The rules that must be applied in the management of Data are set out in the following
sections in the four categories:




Data
Organization
Processes
Systems
3.3.2) Data
The rules for the administration of the Data aspects of Data are:



There must be one global clear definition for each Data object.
Where one Data object has multiple attributes, there must be a clear definition for
each attribute.
A minimum set of Data objects must be maintained to satisfy all Business Unit
needs of analysis and reporting.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 8 of 26
DATA AND CONVERSION STRATEGY










PROJECT NAME
A minimum set of attributes for a Data object must be maintained to satisfy all
business unit needs of analysis and reporting.
Data will be defined at global and business unit levels, and must be maintained at
the appropriate level.
Data terminology must be consistent across business unit levels.
Data must not be maintained in an ad-hoc fashion by departments to satisfy only
their local needs. (Requests to create or change Data structure and data values
must be channeled through the appropriate Data change control procedure).
If local copies of Data are to be created, this must be done in a controlled way and
the copy must be determined to be Data falling under the administration process,
or a copy which does not require update.
Data must be coded consistently to support global and business unit levels
analysis and reporting.
Conformance to data architecture (i.e. the data structures that support business
processes) must be enforced for all projects involving Data.
Data codes must never be re-used. If they cease to be active, then they must be
marked as inactive and not deleted from the Data Repository
Data must be complete, accurate and up-to-date.
Data must be available to the business, but secured against unauthorized change
access.
3.3.3) Data Organization
The rules for the management of the Organizational aspects of Data are:

There must be clearly defined and agreed roles and responsibilities for Data
Administration.

There must be clearly identified Business Ownership for each Data object,
particularly where data responsibilities are partitioned. Owners must be assigned
to each Data object, and the people concerned must be informed of their roles and
responsibilities and adequately trained to perform them effectively.

Where multiple attributes exist, each one must have a single Business Owner.
However, the data object to which these attributes belong may be shared across
business units. In this case, changes to the data object must be approved by the
impacted business units in writing.

All Data management activities for s’ operations must be authorized by the
appropriate authority and coordinated by the Data Administration group where
required.
3.3.4) Processes
The rules for the management of the Process aspects of Data are:
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 9 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME

There must be only one data structure change control process.

Each Data object must have its own data value change control process.

Execution of the data structure change control process and the data value change
control processes must trigger related changes to data as appropriate.

Implementation of Data change administration must take account of all
constraints and sequence dependencies.

Data changes must be appropriately authorized, and the relevant parties
throughout the business made aware of changes.

The Data maintenance process must not compromise speed-to-market or other
business performance requirements.
3.3.5) Systems
The rules for the Data systems are:

There must be one master source for all Data, held in a Data repository.

There must be one vision of the future data repository, driven by business
requirements, and supported by technical capability.

Where the Data needs to be held in several systems, the master/slave relationship
must be clearly defined.

Data objects and their attributes must be made accessible for authorized people to
view, run queries or perform downloads.
3.4) Supporting Principles of Data Administration
At a lower level than the rules previously described, there are certain principles that will
support the administration of Data. These are outlined in the following sections.
3.4.1) Data
Each data object requires a data definition that must describe the data object in
sufficient detail to distinguish it from other similar objects. The definition should be
suitable to support:



The creation of new code values so that consistent codes are created.
Data exchange such that data can be extracted and received with minimal need for
explanations, conversions or revisions.
The running of reports such that readers can understand the basis of the data
displayed.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 10 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
The data definition should be accompanied by information on coding including:



Length (number of characters in the field)
Structure (numbers will have no meaning embedded, however there may be some
structure applied to naming conventions for example)
Conventions (e.g. naming), including number ranges
Each set of related data elements should have a data relationship diagram. This
should be orientated towards business understanding, rather than an Information
Technology view.
3.4.2) Organization
All people having responsibilities and fulfilling roles in Data Administration should
have the appropriate skills and knowledge. These should be kept up to date and put
to use to ensure continuity of capability.
Data Administration is responsible for ensuring the change processes are consistent,
controlled, communicated, executed as efficiently as possible and completed.
The Business Owner should be the relevant person with adequate business knowledge
who can fulfill all roles and responsibilities of a Business Owner. For a particular data
object, the number of people fulfilling all the roles and responsibilities should be kept
to a minimum. Ideally, this would be one person with one back up per object at the
appropriate organizational level.
Where a data object has multiple attributes, the “default” Business Owner for these
attributes should be the Business Owner of the data object itself.
The Business Owner is responsible for the design, definition of assigned Data objects
and for ensuring compliance in usage.
3.4.3) Processes
3.4.3.1 Management of Data Change
Requests for Data changes will be controlled and separated into the different
processes for Data Value Change and Data Structure Change as follows.
There will be one entry point to this change management process.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 11 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
All master data changes
Enter master data
change request
Data value
changes
Data value
change
request
Request entered into Master Data Value
Maintenance Process
Process managed within Master Data Value Maintenance
Data structure
changes
Data structure
change
request
Request entered into Data Structure
Change Process
Process managed within Change Control
3.4.3.2 Data Structure Changes
There will be a single process for Data structure management process,
regardless of whether the change arises from a requirement from a business
unit already live in production or requirements from additional business unit
roll-outs.
Data structure changes will vary in terms of scope from a straightforward task,
to a complex project, and could involve a significant number of resources.
For each type of change there will be an agreed formal change process
incorporating relevant analysis, decision points and project planning where
required.
3.4.3.3 Features of the Change Control Procedure
The data structure change control procedure will, where appropriate,
comprise:






Administration of change requests.
Analyzing the implications of change requests (including feasibility and
cost/benefit analysis where required) and reaching agreement.
Setting up, amending, retiring (or marking as inactive) data structures
and/or values.
Communicating to people impacted by the change
Disseminating changes to systems affected.
Managing the transition of the change.
3.4.3.4 Data Value Changes
Data value changes will typically be a normal course of business and require a
high level of service in line with business requirements. For each data object
there will be an agreed maintenance process, with assignment of business data
ownership. The maintenance procedure will vary according to data object
type, and the process will vary from the simplest case of an authorized
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 12 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
business data owner updating a single data field, to a fully coordinated process
for the introduction of a new product for example.
Where appropriate, there will be an audit trail of changes made to data values.
Performance levels will be set for response times on processes, such as setting
up new instances of codes, as required by the business.
3.4.3.5 Data Monitoring
All Data Administration process will have an element of continuous
improvement Data Monitoring included. Aspects that will be included are:



Data consistency
Quality of data
Identifying items for marking as inactive.
3.4.4) Systems
3.4.4.1 Automation
The Data administration process should make the best use of technology,
automating processes where feasible.
3.4.4.2 Service Levels
There will be service levels for system availability.
3.4.4.3 Security
There will be appropriate levels of security for data, and access to Data will be
controlled and authorized by the Basis Team.
3.4.4.4 Transparency
The system used should provide a transparent data model open to other
systems.
4) Conversion Requirements
Insert Text here
5) Assumptions and Constraints
The following assumptions and constraints apply:


conversion project start date:
target production date:
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 13 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
6) Conversion Approach
This section provides a graphical description of the conversion approach which will be used to
convert the <System to be Converted> to the new application. An explanation of this strategy
follows.
Insert diagram here.
6.1) Data Mapping
The data mapping process provides detailed lists of the <System to be Converted> data sets
and data elements that will need to be moved into the Oracle tables during the data
conversion. During this process, some decisions will need to be made with regard to
obtaining required information needed by the target application which may not be present in
the old system. Default settings, user input, and new data entries are many issues that must
be addressed during this phase.
The output of this section is data mapping spreadsheets that show what is needed for the
Oracle target application processing to meet business operational requirements and where
these data elements will come from.
6.2) Download Programs
These programs are used to extract the identified conversion data elements from the current
existing <System to be Converted>. What tool is used to accomplish this task is usually
dependent on the abilities of the current system to develop an ASCII flat file. It is important
to remember how the flat file will be structured (the order of the records as they are pulled) ,
type of delineation used, number of records, etc. This must match how the interim tables are
set up. The output from this is the ASCII flat files identified in the next section.
6.3) ASCII Flat File
Most database or file systems output data in text form. A comma or space delimited, variable
or fixed format data file from the existing system should be generated. If you cannot find a
way to produce clean text data, try generating a report to disk, using a text editor to format
your data.
6.4) Upload Program
Once data has been put into an ASCII flat file and physically moved onto the same computer
that has the Oracle RDBMS, the next step is to load the data into a relational database
environment.
Programs must be written and run to move data, validate data, and perhaps insert standard
values into default fields. Usually a single loader program is written for each data table
being loaded.
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 14 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
6.5) Interface Table
The detailed technical description of any interface table that the data is placed into from the
ASCII flat file is described. A temporary table which mimics the production table that the
data will eventually be loaded into should be built. This allows you to manipulate the data as
needed before loading the legacy data into the production tables.
Before loading the Oracle application production tables, the legacy data should first be
loaded into temporary or interface tables. The interface tables provide a location for you to
manipulate and translate the data as needed before validating the data and loading the
application production tables. These temporary interface tables need to be built before you
run the loader script to populate these tables.
6.6) Translation Programs
These scripts are developed to translate data from the existing system format into useful data
for the Oracle target application. An example of this might be taking the date format that
exists in the legacy system and converting it into an Oracle format. There may be several or
no translation programs, depending on both the type of data coming across and the format of
that data.
6.7) Application Production Table
This is the final production data table where the converted data resides. These tables are
identified early on when doing the initial data mapping. These tables drive some of the
translation programs that must ultimately ensure that 100% of the required information that
the target applications require is present in the final data structures.
6.8) Testing
This test plan has been integrated into the entire conversion process so that, even during the
pre-conversion steps, some type of validation reports are generated from the,<System to be
Converted> systems, to be compared later with the converted data.
The approach to data validation
6.9) Conversion Execution Plan
The conversion execution plan is the execution document meant to be followed when
performing the actual conversion. This document is specifically tailored for the <Company
Short Name> conversion.
The following steps within the approach described above will be managed using the
automated conversion tool described below:
7) Implementation Approach
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 15 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
7.1) Planning Approach
A waterfall development method is being used on this project. The method covers the
following phases of the project life cycle:






Discovery
Plan and Analyze
Design
Build
Test and Final Prep
Deliver and Stabilize
7.2) Deliverables
This section lists the tasks and deliverables which will be produced during this conversion
project:
Task
Document Data Conversion Requirements
Define Data Conversion Strategy
Define Data Conversion Workplan
Design Data Conversion Modules
Code Conversion Modules
Perform Conversion Module Test
Convert and Verify Data
Deliverable
Data Conversion Strategy
Data Conversion Strategy
Data Conversion Workplan
Data Conversion Module Design
Conversion Modules
Conversion Module Test Results
Converted and Verified Data
8) Conversion Team Organization
8.1)
The organization structure for this conversion project is as follows:


8.2) Roles and Responsibilities
The conversion project roles will be staffed by the indicated person:
Oracle Team Member
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Client Team Member
Page 16 of 26
Role
Conversion Project
Manager
Analyst
DATA AND CONVERSION STRATEGY
Oracle Team Member
Client Team Member
PROJECT NAME
Role
Module Designer
Programmer
Tester
Technical Expert
9) Conversion Resource Requirements
The following software and hardware requirements are considered a part of this conversion
effort:
9.1) Software
The application software considered as part of this project includes:
Legacy Environment:


Oracle Environment:


9.2) Hardware Environment
The hardware and operating software to be used includes:
Legacy Environment:


Oracle Environment:


9.3) Network File Transport
9.4) Staffing
The staff involved with this project must have the background, experience, and training in the
following areas:



File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 17 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
Below is a list of skills which the current conversion project team does not fulfill:

9.5) Other
10) Project Standards
10.1) Tool Standards
A list of tool standards specific to the conversion project follows.
10.1.1) Application Tools
10.1.2) Conversion Tools
10.1.3) Source Control
10.1.4) Version Control
10.1.5) System Management Tools
10.2) Deliverable Naming Standards
The following table provides instructions on how to name files, programs, and other project
deliverables.
Program Type
Upload Module
Download Module
Interface Table
Creation Module
Translation Module
Interface/
Conversion Module
Word Documents
Other Project
Deliverables
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Format
Page 18 of 26
Extension
Example
DATA AND CONVERSION STRATEGY
PROJECT NAME
11) Data Cleanup Process
11.1) Data Clean Up
Specific areas (entities) which are candidates for data clean-up include the following:


11.2) Key Data Translations
Strategic data which requires translation includes the following entities:


12) User Acceptance Criteria
12.1) Delivery
All conversions will be deemed to be delivered following successful business system testing.
Conversion data acceptance criteria should include the following:



transact ability
ability to reconcile financial information
definition and acceptance of account level variances
12.2) Data Acceptance
13) Version Control Procedures
All versions of instance information and conversion modules will be managed under version/source
control. The version source control strategy being used by the overall project will be followed.
14) Project Metrica
The following metrics are considered in determining the complexity factors in the CDM estimating
model:




existing record volumes by entity:
volumes of data to be converted by entity:
throughput of the conversion interfaces:
number of users:
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 19 of 26
DATA AND CONVERSION STRATEGY

PROJECT NAME
number of concurrent users:
15) Project Milestones
The Development Team and <Company Long Name> will review and approve each project
milestone by using the standard acceptance criteria for each task deliverable produced.
In addition to the previously defined conversion project deliverables, the following additional project
milestone, which are subject to client acceptance have also been identified:
Phase
Current Conversion Milestone
Date
Actual Conversion Milestone
Date
16) Conversion Risks
The following risks have been identified as having an impact on the overall success of the
conversion project:


File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 20 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
Appendix A – Business Data Owners
The following individuals have been designated as the Business Data Owner within their
BUSINESS UNIT for the Data element indicated. Additional Business Data Owners will be
identified as part of the cut-over process for each BUSINESS UNIT.
Business Unit
Vendor
Customer
Material
Business Unit 1
Name
Name
Name
Business Unit 2
Name
Name
Name
Business Unit 3
Name
Name
Name
Business Unit 4
Name
Name
Name
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 21 of 26
DATA AND CONVERSION STRATEGY
Appendix B – Data Team Organization
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 22 of 26
PROJECT NAME
DATA AND CONVERSION STRATEGY
PROJECT NAME
Appendix C – Data Request Process Roles and Responsibilities
Each business unit will assign a designated business data owner and backup for each of the primary
master files. (Material, Vendor, Customer) This list of business owners is authorized by
management at the business unit and sent to the Central Data Team (DT).
The responsibilities for this position will include:
 Verifying the request form is completed with the all necessary data. Depending on the
request, it may be necessary to obtain additional information from various departments
within the business unit. If the business unit also requires additional forms, the business
owner is responsible for gathering them (Certificate of Insurance, W9…)
 Sending the completed form** to the Data team. If additional forms are required for the
business unit, they too should be scanned and included in the email to the DT. (Certificate of
insurance, W9…) This will ensure that all required documents are stored together in a
central location.
 Working with the Data team to resolve any issues.
 Notifying the various departments in the business unit that request is complete. The business
owner will receive notification from the Infra service desk when the request has been
completed by the DT. In the event additional views or files need to be created by the
business unit, it is the responsibility of the business owner to let the respective areas know
that basic centralized configuration is complete.
The Data Team (DT) will process the request with the following steps:
 DT will verify the data on the form for completeness and accuracy. The database will be
queried to validate that the request is not an item that already exists. Any issues will be
discussed with the business owner who requested the data until proper resolution is agreed
upon. Any discussions will be documented in the Infra ticket.
 DT will enter data into the database.
 DT will update the ticket with new master file information and an email will be sent to the
business owner when the Service Desk ticket is closed
**The appropriate forms are stored in the <to be filled in>. To access <to be filled in>…
Service Level Agreements
Requests will be prioritized as follows:
Priority
Critical
High
Medium
Low
Response Time
Immediate
30 minutes
2 hours
N/A
Resolution
4 hours
24 hours
48 hours
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Notification
From Service Desk
“
“
Page 23 of 26
DATA AND CONVERSION STRATEGY
PROJECT NAME
In the event there is to be a mass input required by the DT, like a new product line, the DT will need
to be notified by the business owner via email at least 2 weeks in advance in order to allocate time to
analyse how the update will be done. This request should include any critical dates. A schedule will
then be developed with the business owner for the update.
Hours of Operation
The DT will available from 6 a.m. PST until 4:00 p.m. PST
8 a.m. CST until 6:00 p.m. CST
9 a.m. EST until 7:00 p.m. EST
Emergency Requests
For requests that require immediate turnaround, a phone call made to any SAP Data Team member
where the process will be escalated to critical priority. The Business Owner will work with the DT to
get the Data record into the system as quickly as possible. The business owner will also follow up
with the appropriate paperwork to the DT. The request form would be noted as “emergency”.
There may also be a case where an exception to normal processing occurs. In this event, the
Manager of the Data Team is authorized to make such a change. This change will be communicated
back to the business owner via email.
APPENDIX D - Data Conversions
Data can be migrated to the Data Repository either manually or automated. The conversion method
for each data element will be determined based on the volume of data to be converted and the
availability of the data in an electronic format. For data elements that will be migrated through an
automated conversion process, the file mappings can be found on the <to be filled in>.
APPENDIX E – Centralized and Distributed Maintenance of Master Files
Centrally Maintained by DT
Maintained by the BUSINESS UNIT
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 24 of 26
Maintained by
<Fill in>
DATA AND CONVERSION STRATEGY
PROJECT NAME
17) Document Sign Off
Phase: Discovery
The (Deliverable Name) document has been reviewed and found to be consistent with the specifications
and/or documented project requirements. The signature below documents acceptance of this document
and/or work product by the signing authority
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 25 of 26
Contractor________________
DATA AND CONVERSION STRATEGY
PROJECT NAME
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
File Name: 106757862
Last Saved: 3/7/2016 5:06:00 AM
Page 26 of 26