DATA AND CONVERSION STRATEGY PROJECT NAME
[Project Name]
Data and Conversion Strategy
Document OverviewPrepared By: / Author’s Name
Prepared For: / Department Name
Date Created: / Month Day, Year
Last Updated: / August 13, 2008
RASCI Alignment
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
Revision Log
Revision / Date / Initials / Description of Revision1.0 / MM/DD/YY / Initial Draft
Table of Contents
1) Introduction 5
2) Background 5
2.1) Purpose 5
2.2) Scope and Application 5
3) Data Administration Strategy 6
3.1) Data Approach 6
3.1.1) Critical Success Factors 6
3.1.2) Scope 6
3.2) Definitions 6
3.2.1) Data 6
3.2.2) Data Ownership 6
3.2.3) Data Administration 7
3.2.4) Data Value Changes vs Data Structure Changes 7
3.2.5) Data Repository 8
3.3) Data Administration Rules 8
3.3.1) Introduction 8
3.3.2) Data 8
3.3.3) Data Organization 9
3.3.4) Processes 9
3.3.5) Systems 10
3.4) Supporting Principles of Data Administration 10
3.4.1) Data 10
3.4.2) Organization 11
3.4.3) Processes 11
3.4.3.1 Management of Data Change 11
3.4.3.2 Data Structure Changes 12
3.4.3.3 Features of the Change Control Procedure 12
3.4.3.4 Data Value Changes 12
3.4.3.5 Data Monitoring 13
3.4.4) Systems 13
3.4.4.1 Automation 13
3.4.4.2 Service Levels 13
3.4.4.3 Security 13
3.4.4.4 Transparency 13
4) Conversion Requirements 13
5) Assumptions and Constraints 13
6) Conversion Approach 14
6.1) Data Mapping 14
6.2) Download Programs 14
6.3) ASCII Flat File 14
6.4) Upload Program 14
6.5) Interface Table 15
6.6) Translation Programs 15
6.7) Application Production Table 15
6.8) Testing 15
6.9) Conversion Execution Plan 15
7) Implementation Approach 15
7.1) Planning Approach 16
7.2) Deliverables 16
8) Conversion Team Organization 16
8.1) 16
8.2) Roles and Responsibilities 16
9) Conversion Resource Requirements 17
9.1) Software 17
9.2) Hardware Environment 17
9.3) Network File Transport 17
9.4) Staffing 17
9.5) Other 18
10) Project Standards 18
10.1) Tool Standards 18
10.1.1) Application Tools 18
10.1.2) Conversion Tools 18
10.1.3) Source Control 18
10.1.4) Version Control 18
10.1.5) System Management Tools 18
10.2) Deliverable Naming Standards 18
11) Data Cleanup Process 19
11.1) Data Clean Up 19
11.2) Key Data Translations 19
12) User Acceptance Criteria 19
12.1) Delivery 19
12.2) Data Acceptance 19
13) Version Control Procedures 19
14) Project Metrica 19
15) Project Milestones 20
16) Conversion Risks 20
17) Document Sign Off 25
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.
[ 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 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
· 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.
· 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:
· 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.
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.