Data migration Strategy - SAP SIMPLE Docs



| |

| |

| |

| |

| |

| |

| |

| |

| | | | |

| | | | |

Table of Contents

1 Document Information 4

2 Introduction 5

3 Definitions of Different Types of Data 6

3.1 Master Data 6

3.2 Configuration Data 6

3.3 Transaction Data 6

4 Data Migration Activities 7

4.1 Define the SAP Data Requirements (Functional) 7

4.2 Define the SAP Data Requirements (Technical) 7

4.3 Identify the Legacy Data (Functional) 7

4.4 Identify the Legacy Data (Technical) 7

4.5 Define Data Standards 7

4.6 Legacy Data Cleansing 7

4.7 Determine the Data Transfer Method 7

4.8 Data Mapping and Transformation 8

4.9 Identify Missing Data 8

4.10 Resolve Missing Data 8

4.11 Extract Legacy Data 8

4.12 Design Automatic Loads 8

4.13 Develop Automatic Loads 8

4.14 Manual Data Entry 9

4.15 Data Loading Instructions 9

4.16 Trial Data Upload - Running 9

4.17 Trial Data Upload - Checking 9

4.18 Execution Plan for Final Uploads 9

4.19 Dual Data Maintenance 9

4.20 Data Cutover 9

4.21 Reconcile the Migrated Data 9

4.22 Data Sign-off 9

5 Data Migration Guiding Principles 10

5.1 Data Migration Approach 10

5.1.1 Master Data - (e.g. Customers, Assets) 10

5.1.2 ‘Open’ Transactional data (e.g. Service Tickets) 10

5.1.2.1 Historical Master and Transactional data 10

5.2 Data Migration Testing Cycles 11

5.3 Data Cleansing 11

6 Data Migration Methods 13

6.1 Legacy System Migration Workbench (LSMW). 13

6.2 LSMW process flow 13

6.3 Bespoke Program Development 14

6.4 Manual Migration 14

7 Data Object Structure (DOS) 15

8 Data Object Register 16

9 Roles and Responsibilities 17

10 Key Issues & Risks 18

10.1 Current Data Migration Issues 18

10.2 General Data Migration Risks 18

Document Information

|Area |Data |

|Title |Customer First – Data Migration Strategy |

|Business Process Owner | |

|Short description | |

|SolMan Dev ID | |

|Reviewed by | |

|Approved by | |

|Document Status |Ready for review |

|Comments | |

|Version |Date |Summary of Changes |Author |

|1.0 |14.01.2008 |Document ready for review |Mushtaq khan / Graeme Cox |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

Introduction

The scope of this document is to define the data migration strategy in the context of Customer First from a CRM perspective. By its very nature CRM is not a wholesale replacement of legacy systems with SAP but rather the coordination and management of customer interaction within the existing application landscape. Therefore a large scale data migration in the traditional sense is not required, only a select few data entities will need to be migrated into CRM.

Data migration is typically a ‘one-off’ activity prior to go-live. Any ongoing data loads required on a frequent or ad-hoc basis are considered to be interfaces, and are not part of the data migration scope. This document outlines how the CF project intend to manage the data migration from the various council legacy systems the SAP CRM system

The creation of the Single Customer Record is not included in this document; refer to the Single Customer Record MDM design paper for information on this subject.

Definitions of Different Types of Data

In the context of this document legacy applications are defined as those that will be replaced by the Customer First Transformation programme, back-office applications are defined as applications that will not be replaced but may be integrated into the Customer First applications.

1 Master Data

Identified as fixed data, it describes the information about people, places and objects that are involved in running the business processes. These data types tend to be created once maintained over a long time frame and are used by a number of business activities. Examples include; customers, assets, land & property.

2 Configuration Data

This is data that is set up on SAP during the build and configuration process as it is configured. This type of data is not part of the migration process, as it will be transported to the production system through the transport procedure along with all other configuration.

3 Transaction Data

Transaction data describes business activities conducted by the council in carrying out its duties. In the context of Customer First these transactions will be related to the customer interaction process and related to;

• Customer providing new information – such as new address details.

• Customer seeking information – such as location of nearest swimming pool.

• Customer making an application – such as an application for a parking permit.

• Customer making a booking – such as an appointment with a council officer.

• Customer raising a service request – such as a bulky waste collection.

• Customer making a payment – such as a traffic offence fine.

Transactional Data falls into two categories;

• Open Transaction Data - is transactional data that has not completed its business cycle, for example a service ticket that remains open with additional activities required prior to being closed.

• Closed Transactional Data – is transactional data that has completed its business cycle and is subsequently used for information purposes only, for example a service ticket will all related activities completed and a ticket status of closed.

Data Migration Activities

The complexity of data migration demands a process that ensures the accurate and complete transfer of data into the new system from legacy systems. The activities involved in the data migration process are detailed below.

1 Define the SAP Data Requirements (Functional)

In SAP a Data Object is a business data unit such as customers; the functional SAP data requirements define the SAP transactions, the screen headings and the screen field descriptions used to enter the data.

2 Define the SAP Data Requirements (Technical)

These define in detail the SAP Data structures, tables and fields. Including the field name, field attributes (e.g. data type and length) and field properties (mandatory, optional, conditional or suppressed). This process requires a detailed knowledge of the associated SAP business processes and careful analysis of the configured SAP system.

3 Identify the Legacy Data (Functional)

This activity identifies where the legacy data currently resides, in which applications/databases, and how it is currently entered and maintained. In addition this activity defines the legacy screen headings and the screen field descriptions used to enter the data.

4 Identify the Legacy Data (Technical)

This activity identifies in detail the legacy data tables and fields, the field attributes and properties including the data type and length. This process requires a detailed knowledge of the associated legacy applications.

5 Define Data Standards

The data standards define the required appearance, consistency and content of the data. For example, the name and address formats, uppercase & lowercase requirements, providing a consistent look for the data that will be visible both internally and externally to the business.

6 Legacy Data Cleansing

Legacy data required for migration into SAP must be completely cleansed prior to the final data load in SAP with the aim to ensure the consistency and accuracy of the data.

As a general approach the data will be cleansed on the legacy database before extraction, however there may be circumstances where this is not the best method and the data will be cleansed after it has been extracted.

Cleansing is an iterative process that can start as soon as the data has been identified as being required for migration into SAP. The data cleansing cycle includes the following steps:

• The elimination obsolete records.

• The removal of duplicate records.

• Correcting inaccurate records.

• Correcting incomplete records.

7 Determine the Data Transfer Method

For each business object the following choices are available for data transfer:

• To use the standard SAP data transfer programs.

• To manually enter data with online transactions.

• To develop bespoke batch input programs.

Data volumes, data complexity and availability of standard SAP data load programs are all to be considered before deciding between automated or manual load.

8 Data Mapping and Transformation

This is a manual process where the data fields in the legacy data source are assigned corresponding fields in the SAP system. Field text in the legacy system rarely agrees with the corresponding terminology in the SAP system, therefore a variety of mapping methods are required. At the end of this step every SAP field that requires data must have been:

• Assigned a corresponding field from the legacy system.

• Assigned a transformation – i.e. converted from the original state to the required state using variety of methods including lookup tables, combining fields or logical rules for data transformation.

• Assigned a constant value.

9 Identify Missing Data

Missing data is identified during the data mapping process, where a table or field in the SAP systems does not have an identifiable source from the legacy applications.

10 Resolve Missing Data

SAP modules will require data that does not exist in the legacy systems, the approaches to resolve this issue are:

• Populate the missing data within the data load programs, either by calculation or mapping tables.

• Using third party software, such as Microsoft Excel, for data staging and manipulating the data manually to fit the required format.

• Developing guidelines for use during manual migrations, which show how to determine missing values while entering the data.

11 Extract Legacy Data

Legacy data is extracted from the legacy systems using software specifically developed for the task using the legacy toolset available, the extracted data is loaded into staging tables and transferred to the data staging area. Extracted legacy data will be held on the data migration staging area for further analysis, manipulation and cleansing using the appropriate tool, for example MS Excel, MS Access. Integrity checks are required to ensure the correct data has been extracted, for example, all records are included in the extract, duplicates have not been created etc.

12 Design Automatic Loads

Where an automatic load process has been chosen as the best method to load the data into SAP, the data load programs are designed and a technical specification written. The technical specification will define an appropriate SAP load technique, all data mapping (legacy field to SAP field) and data transformation logic.

13 Develop Automatic Loads

Automatic data loads into SAP will be developed using the technical specification defined.

14 Manual Data Entry

Where manual data entry has been chosen as the best method to load the data into SAP, data will be manually entered into SAP using the appropriate transaction.

15 Data Loading Instructions

Instructions for the data load to be written and agreed for all data objects in scope. This includes the order in which data is to be migrated and any dependencies

16 Trial Data Upload - Running

The process of running trial data loads into the SAP system will help ensure data accuracy, the correct load sequence, determine load duration and correct any loading errors. The trial data loads will continue until the load process completes successfully.

17 Trial Data Upload - Checking

After the trial data load run has completed, the data loaded will be checked for accuracy to ensure it meets defined requirements.

18 Execution Plan for Final Uploads

This plan gives an indication of the feasibility of the final conversion into the production system in the available time frame, and specifies the data sequencing as well as the appropriate time to freeze the legacy system(s), for extracting information for the final uploads.

19 Dual Data Maintenance

Where master data is migrated before actual go-live any data changes on the legacy system must also be reflected on the new SAP system. Dual maintenance is best avoided if there is a large volume of master data changes as the additional workload may be excessive.

20 Data Cutover

This is the final Data Migration into the SAP production System. The cutover period is the time between the shutting down of the old system (and ceasing of all logistic related business activities) and commencement of use of the SAP. During cutover the all processing on the legacy system is frozen and the data extracted.

21 Reconcile the Migrated Data

This process checks that the data migrated into SAP meets the specified data requirements. This includes, but is not limited to manual data checks, record counts, checking balances, running reconciliation reports, approval of acceptable differences (rounding errors) etc.

22 Data Sign-off

After the migrated data has been reconciled and checked the data loads will be signed-off, the sign-off will act as approval for the go-live of the SAP application.

Data Migration Guiding Principles

1 Data Migration Approach

1 Master Data - (e.g. Customers, Assets)

The approach is that master data will be migrated into SAP providing these conditions hold:

• The application where the data resides is being replaced by SAP.

• The master records are required to support SAP functionality post-go-live.

• There is a key operational, reporting or legal/statutory requirement.

• The master data is current (e.g. records marked for deletion need not be migrated) OR is required to support another migration.

• The legacy data is of a sufficient quality such so as not to adversely affect the daily running of the SAP system OR will be cleansed by the business/enhanced sufficiently within the data migration process to meet this requirement.

Note: Where the master data resides in an application that is not being replaced by SAP, but is required by SAP to support specific functionality, the data will NOT be migrated but accessed from SAP using a dynamic query look-up. A dynamic query look-up is a real-time query accessing the data in the source application as and when it is required. The advantages of this approach are;

- Avoids the duplication of data throughout the system landscape.

- Avoids data within SAP becoming out-of-date.

- Avoids the development and running of frequent interfaces to update the data within SAP.

- Reduces the quantity of data within the SAP systems.

2 ‘Open’ Transactional data (e.g. Service Tickets)

The approach is that ‘open’ transactional data will NOT be migrated to SAP unless ALL these conditions are met:

• There is a key operational, reporting or legal/statutory requirement

• The legacy system is to be decommissioned as a result of the CF project in timescales that would prevent a ‘run down’ of open items

• The parallel ‘run down’ of open items within the legacy system is impractical due to operational, timing or resource constraints

• The SAP build and structures permit a correct and consistent interpretation of legacy system items alongside SAP-generated items

• The business is able to commit resources to own data reconciliation and sign-off at a detailed level in a timely manner across multiple project phases

1 Historical Master and Transactional data

The approach is that historical data will not be migrated unless ALL these conditions are met:

• There is a key operational, reporting or legal/statutory requirement that cannot be met by using the remaining system

• The legacy system is to be decommissioned as a direct result of the CF project within the CF project timeline

• An archiving solution could not meet requirements

• The SAP build and structures permit a correct and consistent interpretation of legacy system items alongside SAP-generated items

• The business is able to commit resources to own data reconciliation and sign-off at a detailed level in a timely manner across multiple project phases

2 Data Migration Testing Cycles

In order to test and verify the migration process it is proposed that there will be three testing cycles before the final live load:

• Trial Load 1: Unit testing of the extract and load routines.

• Trial Load 2: The first test of the complete end-to-end data migration process for each data entity. The main purpose of this load is to ensure the extract routines work correctly, the staging area transformation is correct, and the load routines can load the data successfully into SAP. The various data entities will not necessarily be loaded in the same sequence as will be done during the live cutover

• Trial Cutover: a complete rehearsal of the live data migration process. The execution will be done using the cutover plan in order to validate that the plan is reasonable and possible to complete in the agreed timescale. A final set of cleansing actions will come out of trial cutover (for any records which failed during the migration because of data quality issues). There will be at least one trial cutover.. For complex, high-risk, migrations several trial runs may be performed, until the result is entirely satisfactory and 100% correct.

• Live Cutover: the execution of all tasks required to prepare SAP for the go-live of a particular release. A large majority of these tasks will be related to data migration.

3 Data Cleansing

Before data can be successfully migrated it data needs to be clean, data cleansing is therefore an important element of any data migration activity:

• Data needs to be in a consistent, standardised and correctly formatted to allow successful migration into SAP (e.g. SAP holds addresses as structured addresses, whereas some legacy systems might hold this data in a freeform format)

• Data needs to be complete, to ensure that upon migration, all fields which are mandatory in SAP are populated. Any fields flagged as mandatory, which are left blank, will cause the migration to fail.

• Data needs to be de-duplicated and be of sufficient quality to allow efficient and correct support of the defined business processes. Duplicate records can either be marked for deletion at source (preferred option), or should be excluded in the extract/conversion process.

• Legacy data fields could have been misused (holding information different from what this field was initially intended to be used for). Data cleansing should pick this up, and a decision needs to be made whether this data should be excluded (i.e. not migrated), or transferred into a more appropriate field.

It is the responsibility of the data owner (i.e. the business) to ensure the data provided to the Customer First Project for migration into SAP (whether this is from a legacy source or a template populated specifically for the CF project) is accurate.

Data cleansing should, wherever possible, be done at source, i.e. in the legacy systems, for the following reasons:

• Unless a data change freeze is put in place, extracted datasets become out of date as soon as they have been extracted, due to updates taking place in the source system. When re-extracting the data at a later date to get the most recent updates, data cleansing actions will get overwritten. Therefore cleansing will have to be repeated each time a new dataset is extracted. In most cases, this is impractical and requires a large effort.

• Data cleansing is typically a business activity. Therefore, cleansing in the actual legacy system has the advantage that business people already have access to the legacy system, and are also familiar with the application. Something that is not the case when data is stored in staging areas. In certain cases it may be possible to develop a programme to do a certain degree of automated cleansing although this adds additional risk of data errors.

• If data cleansing is done at source, each time a new (i.e. more recent) extract is taken, the results of the latest cleansing actions will automatically come across in the extract without additional effort.

Data Migration Methods

There are four primary methods of transferring data from a legacy system into SAP. The most appropriate method will depend on the volume and complexity of data to be migrated for each data object.

1 Legacy System Migration Workbench (LSMW).

This is a facility provided by SAP that enables migrated data to be first cleansed in spreadsheets (or access depending on the data volumes), and subsequently loaded into SAP via predetermined field mapping. The facility also caters for ‘data transformation’ where field values can be created from simple predefined logic. It is the preferred tool for all data migration into SAP. The main benefits are:

• A highly flexible tool provided and supported by SAP.

• Independence from SAP releases, platforms and the kind of data to be migrated.

• Independence from SAP releases, platforms and the kind of data to be migrated.

• A step by step guide through the data migration process.

• Generates ABAP code once data transfer has been configured.

• It allows additional ABAP coding for complex data loads.

• It allows reusability of data mapping and conversion rules.

2 LSMW process flow

The LSMW process flow is made up of the following steps:

• Read data (legacy data in spreadsheet tables and/or sequential files) from a file on a local PC or file server.

• Convert data (from the source into the target format).

• Import data (to the database used by the SAP application).

[pic]

3 Bespoke Program Development

This is suitable where the data to be migrated is complex and in a significantly different format from that required by SAP and there is no standard SAP data load program available. This method will only be used as a last resort as it tends to create a large development overhead and is usually only justified if the volume of such data is very large.

4 Manual Migration

If the volume of data to be migrated is relatively low or is of poor quality, the overhead of developing migration programs might not be justified. Manually keying the data using the SAP transactions can enable the SAP logic to validate the data at the time of entry. The main disadvantages are the possibilities of input errors (mis-keying) and for multiple SAP rollouts the data must be manually input each time.

Data Object Structure (DOS)

For each data object identified as requiring data migration a data object structure (DOS) will be created. The DOS is the central repository for the detailed information on the SAP data field definitions, properties and attributes of a data object The DOS is a vital input to the task of writing functional specifications for the migration of legacy data into SAP., it is used to:

• Map legacy systems data to the SAP template data.

• Design and develop legacy data extracts.

• Design and construct data load templates.

• Design and construct data conversion programs.

• Define manual data input instructions for manual data entry.

• Derive priorities and business rules for data cleansing.

• Determine any data transforming requirements.

• Design and construct interface programs.

There is one DOS for each Data Object or group of Data Objects in scope. The main purpose of this document is to achieve:

• A consistent look and feel for all DOS records

• Clarification of the DOS columns

• Standard values for columns across all DOS records

• Clear rules for different scenarios

• Better interpretation of an SAP data object.

Each DOS sheet is an Excel file that conforms to the following generic layout. See Appendix 1 for the sample template

|DOS Sheet Field |Mandatory/Optional |Comments/Values |

|Screen Name |Mandatory |This is the name at the top of the SAP screen when entering fields. Enter once at the |

| | |beginning of the section, not on each line. For example Business Partner. |

|Field Description |Mandatory |Field Description, for example Customer Name |

|Table/Structure |Mandatory |SAP Table Name. |

|Field Name |Mandatory |SAP Field Name |

|Length |Mandatory |Length of field |

|Format |Mandatory |Example CHAR, DATS, CURR |

|Field Status |Mandatory |Field Status; R=Required, A=Automatic, C=Conditional, |

| | |O=Optional, NR=Not Required |

|Comments |Mandatory |Insert comments to assist with data mapping and transforming. For example: Describe |

| | |allowable values with the conditions for deciding which value must be used |

|Source System |Mandatory |The name of the legacy system |

|Legacy Table/Field |Mandatory |The name of the legacy table and field. |

|Conversion Rule |Mandatory |The Conversion Rule, describe the transformation values, any fixed values or logical |

| | |rules |

Data Object Register

The ‘Data Object Register’ will contain a definitive list of all data objects considered for migration into SAP, for each data entity responsibility will be assigned for each activity in the data migration process. The data object register will contain all data objects considered for data migration and form the basis for reaching a final decision on whether the data migration will take place for the data object in question.

The Data Object Register layout and content is detailed in the able below;

|DOR Column |Column Description |

|Directorate |The name of the BCC directorate |

|Source Application |Source application name e.g 3’C’s |

|Rollout Sequence |The rollout sequence of the data object |

|Data Object |The data object name e.g LLPG |

|Description |A meaningful description of the data object |

|Data Type |The type of data, master/transactional |

|Business Data Owner(s) (BCC) |The name of the business data owner within BCC |

|Service Birmingham Contact |The name of the SB contact |

|Workstream Business Representative (BCC) |The name of the BCC business representative on the Customer First Programme |

|Functional Consultant (CF) |The name of SAP functional consultant responsible |

|Workstream Data Analyst (CF) |The name of the data analyst responsible for the data migration |

|Data Volume |The volume of data i.e. number of records |

|Data Complexity |How complex – high, low, medium. |

|Data Quality |Quality of the data – high, low, medium |

|Data Migration Recommended (Yes/No) |The recommended data migration approach |

|Recommendation Rationale |The reasons for the data migration recommendation, e.g. highly complex, very high |

| |development cost, dynamic data lookup. |

|Agreed Data Migration Yes/No |Following consultation, the agreed decision on data migration. |

|Agreement Rationale |The reasons for the agreed migration decision. |

Roles and Responsibilities

The successful migration of data into SAP requires a significant and diverse input from many different sources. A complete understanding of legacy systems and SAP data structures is necessary as well as a functional and business understanding of the processes the data is supporting. For that reason the each data entity has people assigned to oversee each of the following roles. The responsibilities of each data entity “team” can be shared in whatever way suits them best but the likely division is shown below.

• Business Data Owner(s) (BCC)

o Overall responsibility for ensuring “fit for use” for business.

o Business sign off for: Strategy document, Trial cutover migration, Live migration.

o Ensuring necessary data cleansing/build takes place.

• Workstream Business Representative (BCC)

o Facilitating flow of information between project team and business owners.

o Ensuring project team is considering ALL parts of the business

o Highlighting business critical data gaps

• Functional Consultant (Customer First)

o Ensuring “fit for use” in SAP environment.

o Create strategy for field mappings and data build where appropriate.

o Functional support for technical analysts.

• Legacy System Owner (Service Birmingham)

o Build of extract routines from legacy systems.

o Timely extraction of files for build/test phases, Trial Cutover and Live Cutover.

o Highlight any data gaps from legacy systems.

• Workstream Data Analyst (Customer First)

o Design/Build of import routines to SAP

o Ensuring field mappings are complete.

o Timely load of files for build/test phases, Trial Cutover and Live Cutover.

Key Issues & Risks

1 Current Data Migration Issues

• Data Access - access to the data held within the BCC Specialist Service Delivery applications is required to enable; data profiling, the identification of data sources and to write functional and technical specifications.

• BCC Resource Availability;

o Required to assist in data profiling, the identification of data sources and to create functional and technical specifications.

o Required to develop and run data extracts from the councils specialist service delivery systems.

o Required to validate/reconcile/sign-off data loads.

o Required for data cleansing.

• The LLPG (Local Land and Property Gazetteer) and GIS are being created outside of Customer First, they are required by the customer first solution and therefore must be managed as a dependency.

• Data cleansing is the responsibility of BCC, they will also require support in this process by Service Birmingham. Customer First will help identify the data anomalies during the data migration process however Customer First will not cleanse the data in the councils applications. Depending on the data quality, data cleansing can require considerable effort, and involve a large amount of resources.

• The scope of the data migration requirements has not yet been finalised, as data objects are identified they will be added on to the data object register.

2 General Data Migration Risks

• Business resources are unable to confidently reconcile large and/or complex data sets. Since the data migration will need to be reconciled a minimum of 3 times (system test, trial cutover and live cutover) the effort required within the business to comprehensively test the migrated data set is significant. In addition, technical data loading constraints during cutover may mean a limited time window is available for reconciliation tasks (e.g. overnight or during weekends)

• Business resources are unable to comprehensively cleanse the legacy data in line with the CF project timescales. Since the migration to SAP may be dependent on a number of cleansing activities to be carried out in the legacy systems, the effort required within the business to achieve this will increase proportionately with the volume of data migrated. Failure to complete this exercise in the required timescale may result in data being unable to be migrated into SAP in time for the planned cutover

• The volume of data errors in the live system may be increased if reconciliation is not completed to the required standard. The larger/more complex a migration becomes, the more likely it is that anomalies will occur. Some of these may initially go undetected. In the best case such data issues can lead to a business and project overhead in rectifying the errors after the event. In the worst case this can lead to a business operating on inaccurate data.

• The more data migrated into SAP makes the cutover more complex and lengthy resulting in an increased risk of not being able to complete the migration task on time. Any further resource or technical constraints can add to this risk.

• Due to the volume of the task, data migration can divert project and business resources away from key activities such as initial system build, functional testing and user acceptance testing.

Appendix 1 – Data Object Structure Template

Screen |Field |Purpose/Description |Field

Name |Table/

Structure |Length |Format |Field Status

|Comments |Source

System |Source

Table

Field Name |Conversion

Rule | |Address Data |  |  |  |  |  |  |  |  |  |  |  | |  |Title |Title key - e.g. Mr, Mrs, etc. |title |addr1_data |4 |char |M |  |  |  |  | |  |Name 1 |Address component: Name of an address. |name1 |addr1_data |40 |char |M |  |  |  |  | |  |Name 2 |Address component: Name of an address. |name2 |addr1_data |40 |char |M |  |  |  |  | |  |Name 3 |Address component: Name of an address. |name3 |addr1_data |40 |char |M |  |  |  |  | |  |Name 4 |Address component: Name of an address. |name4 |addr1_data |40 |char |M |  |  |  |  | |  |Search term 1 |Short description for a search help. |sort1 |addr1_data |20 |char |O |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |  |  |  |  |  |  |  |  |  |  |  |  | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download