1

ASAP IMPLEMENTATION METHODOLOGY

How to use the Template

Blue text is always intended as instructions, guidelines, explanations, hints, and tips. It has to be removed when the document is finalized. To provide a consistent representation of this document to the customer, chapters should not be deleted or inserted. Required additions should be made as sub-chapters to existing chapters. Chapters that are not relevant should be marked as such (that is, add “not relevant” or “not applicable”).

Be sure to delete these instructions when you have finished!

DATA MIGRATION RECONCILIATION PLANMASTER CUSTOMER DATA

PROJECT IDENTIFICATION

Delete Project Identification table if not applicable for the document!

Project Name CPI Project Number

<Project Name>

Customer Name Customer Number

<Customer Name>

SAP Project Manager Customer Project Manager

<SAP Project Manager> <Customer Project Manager>

Author Document Location (repository/path/name)

<Author> <Document location>

Version Status Date (YYYY-MM-DD) Document Classification

0.1 Final <Date> Confidential

REVISION HISTORY

Delete Revision History section below if not applicable for the document!

2

Version Date Description

0.1 February 4, 2010 <Text here>

0.2

REVIEW AND APPROVAL

Delete Review and Approval section below if not applicable for the document!

NameCustomer Project Manager

Date (YYYY-MM-DD)

NameSAP Project Manager

Date (YYYY-MM-DD)

NameKey Stakeholder

Date (YYYY-MM-DD)

NameKey Stakeholder

Date (YYYY-MM-DD)

3

TABLE OF CONTENT

Overview.......................................................................................................................................................... 4Data Conversion Process.............................................................................................................................. 4Data Reconciliation Process......................................................................................................................... 7Specifications............................................................................................................................................... 105 Year Touch Definition................................................................................................................................ 11Cleansing & Matchback Processes.............................................................................................................12Resources Required..................................................................................................................................... 13Points to Consider........................................................................................................................................ 14

4

OVERVIEW

The following reconciliation plan has been created to incorporate specific audit points during our conversion process to ensure accuracy of the customer conversion process from a quantitative perspective and to provide stages at which we can troubleshoot potential issues along the way. It is imperative that we are able to reconcile the number of customers with the < SYS > system data initially and throughout the conversion process. This plan has been developed to clearly define the conversion and reconciliation processes specifically for < LOC >. Please note that the purpose of this reconciliation process is to validate the individual customer loads and will not involve cross object reconciliation or BI reporting.

In order to provide a clear picture of the customer conversion process, copies of the functional, net change, and technical specifications have been referenced as well. The cleansing and matchback process for legacy data has also been included since it is important to understand the logic behind the process to account for possible variance. Analyzing the definitions and processes will help us understand and explain potential variance between legacy and converted data and the respective reporting elements.

A resource overview has been included which shows the various elements involved with conversion. While this reconciliation plan focuses on a quantitative audit of the customer loads, it is important to understand the related tasks of data validation testing (DVT) which provides qualitative testing as well as the error analysis and break/fix tasks since conversion issues will need to be addressed and considered during the conversion process.In order to ensure accuracy and accountability, a team from the business has been engaged to assist the Project Atlas team, including < RESOURCE > (Operational Excellence Team/Business Process Owner), < RESOURCE > (Business Process Owner), and < RESOURCE > (ISSD BI Team). These individuals will provide initial sign-off on the reconciliation process and will be engaged during the reconciliation process from an audit and approval perspective.

DATA CONVERSION PROCESS

A new conversion architecture has been designed in order to streamline and optimize the conversion and net change processes by eliminating the need for flat files. The following process flow illustrates the new architecture:

5

The new architecture provides the following improvements to the conversion process:

A high level overview of the conversion development process and responsible parties is shown below:

6

A high level overview of the conversion cutover process flow is shown below:

7

DATA RECONCILIATION PROCESS

Following is a comprehensive process flow showing the complete end-to-end process for data reconciliation. The reconciliation steps are those tasks shown in red and are described below.

1. A list of the active business partners (i.e., customers, contacts, and prospects) and relationships will be extracted from the legacy system.

2. All of the active business partners and relationships are also extracted from DQMB.3. The legacy data and DQMB data are merged checking for duplicates.4. The data is extracted into SQL tables with a count kept of the total number of business

partners/relationships. 5. The SQL count total is reconciled with the legacy count totals. The data from steps 1, 2, 3, and 4 are

checked and the output is accounted for in step 6. The process of reconciling against legacy counts will be accomplished using refreshed versions of the “Address Cleansing Summary Findings” report (sample attached below) which is created and maintained by David Coppin as well as a report of customer counts provided by Jason Rubovitz and the ISSD BI team.

8

6. If the totals match, the reconciliation is complete and the process continues. Please note that a threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into the plan once determined.

7. The data is copied to the Z tables.8. The count of objects in the Z tables is reconciled with the count from the SQL tables. The data from

steps 4 and 7 are checked and the output is accounted for in step 9. 9. If the totals match, the reconciliation is complete and the process continues. Please note that a

threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into this plan once determined.

10. The data is loaded into SAP and the count metric is also stored. The program used is ZOMPTS _BP_CUSTOMER_PP. This program populates an SAP table with all business partners and relationships listed and then generates a log file. The log lists all of the business partners and relationships grouped into those with errors and those without errors. The items with errors have descriptions of each unique error displayed. The total number of business partners and relationships with and without errors are listed.

11. The error analysis and error correction processes are performed. 12. The log file’s total count is reconciled with the count from the source file. The data from steps 10

and 11 are checked and the output is accounted for in step 13. 13. If the totals match, reconciliation is complete and the process continues. Please note that a

threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into this plan once determined.

14. All data is now loaded into CRM.15. ECC data is replicated according to the following table with TCode SE11:

Business Partner Object Table in CRM Table in ECC

Customers, Contacts, Prospects BUT000 KNA1

Relationships BUT050 KNVK

16. The count of objects in ECC is reconciled with the count from CRM. The data from steps 14 and 15 are checked with the output accounted for in step 17.

17. If the totals match, reconciliation is complete and the process continues. Please note that a threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into this plan once determined.

18. A customer back copy of the data from CRM is executed, populating Z tables, with the following specifications:

ZTOMPTS_CHANPART Channel partner data from BP extraction program

ZTOMPTS_CONT_ADR Contact address extracted from BP extraction program

ZTOMPTS_CONTACT Contact data coming from BP extraction program

ZTOMPTS_CUST_ADD Customer addresses fetched from BP extraction program

ZTOMPTS_CUST_GEN Customer general data

ZTOMPTS_PROSPECT Prospect data fetched from BP extraction program

ZTOMPTS_SOLDTO Sold to party information

19. The count of objects in the Z tables is reconciled with the count from the SAP tables. The data from steps 9 and 18 are checked with the output accounted for in step 20.

20. If the totals match, reconciliation is complete and the process continues. Please note that a threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into this plan once determined.

21. The back copy data is copied from the Z tables to SQL tables.22. The count of objects in the Z tables is reconciled with the count from the SQL tables. The data from

steps 18 and 21 are checked with the output accounted for in step 23.

9

23. If the totals match, reconciliation is complete and the process continues. Please note that a threshold for variance will be determined with the business process ownership team during cutover testing and will be incorporated into this plan once determined.

24. The reconciliation process is complete. This process is similar for all business partners (customers, contacts, and prospects) and relationships.

10

SPECIFICATIONS

The following specifications were created to define and support the customer conversion process:

Functional Specification (Atlas) – The most current version of the OM-C-001 Customer Conversion Functional Specification can be found on the RICEFW section of SharePoint: http://portal.best.adinternal.com/sites/erp-na/Databases/default.aspx

Net Change Function Specification - The most current version of the Net Change Functional Specification can be found on the RICEFW section of SharePoint: http://portal.best.adinternal.com/sites/erp-na/Databases/default.aspx

Technical Specification (Legacy) – The most current version of the OM-C-001 Customer Conversion Technical Specification can be found on the RICEFW section of SharePoint: http://portal.best.adinternal.com/sites/erp-na/Databases/default.aspx

Data Conversion Run Procedure – The most current version of the Customer Data Conversion Run Procedure is attached below:

11

5 YEAR TOUCH DEFINITION

The business requirement for customer conversion was defined in the OM-C-001 functional specification as follows:

The definition includes all companies and people that exist in our CRM systems that have been qualified under the < CUST > 5 Year touch paradigm. Many systems contain an indicator for this characteristic. The Business Reporting Group has the technical definition of a 5 year touch customer. The business definition of a < CUST > 5 Year Touch is any customer who has had any activity with < CUST > software in the past years. Activity is further defined as a sales order, service agreement or support case.

For the purpose of reconciliation, 5 year touch must be further defined since the 5 year touch guidelines differ slightly by business unit and must be clear to ensure we are reconciling with similar parameters or can explain the variance. The legacy developer’s definition of 5 year touch for < LOC > is as follows (verbatim):

1. Order History2. Customer Products (IBase)3. Service Contracts4. Incidents (Service Tickets)5. Leads & Opportunities*

*Please note that while the extract logic of the developer includes customers with leads and opportunities, only those organizations with a “Sold To” role will be converted as customers and otherwise the organizations will be converted as prospects.

12

CLEANSING & MATCHBACK PROCESSES

For the purpose of reconciliation, the data cleansing and matchback processes must be further defined since the guidelines differ slightly by business unit and must be clear to ensure we are reconciling with similar parameters or can explain the variance.

The legacy team’s data quality and matchback processes are outlined in the attached document:

13

RESOURCES REQUIRED

The following organizational structure has been established to support the conversion and reconciliation processes for customers:

In addition to the Atlas employees shown above, < CUST > (Operational Excellence/Business Process Owner), < CUST > (Business Process Owner), and < CUST > (ISSD BI team) will be engaged to represent the business and to sign off on the reconciliation process. Resources will also be engaged to monitor the load process and to troubleshoot issues related to the customer master data object.

14

POINTS TO CONSIDER

■ The following areas should be considered during the reconciliation process:

■ The authoritative source for customer conversion will be reports defined by Project Atlas (ref. CR 922) and created by the ISSD BI team with approval by < CUST > and < CUST >. BRG’s Fusion database will not be part of this reconciliation process.

■ The < LOC > list of “do not merge” accounts will need to be considered. The decision was made not to merge customers with duplicate DUNs numbers.

■ In house, test, and dummy accounts will be excluded from conversion but may not be excluded in the legacy report. Therefore, this must be considered during reconciliation to account for possible variance.

■ The data reconciliation plan accounts for validation at the customer level but does not take into consideration cross object reconciliation or dependencies that will be part of future reporting. For example, we are auditing the total number of customers per legacy system but are not including BI reports that will identify customers with specific iBase (e.g., MAS 90 customers) that have links between objects. Therefore, cross object reconciliation is not covered within the scope of this customer reconciliation.

■ We will need to consider variance to account for prospect to customer conversion in subsequent rollouts. For example, a company may be a prospect in rollout 1 but a customer in rollout 2. While the quantities are likely to be small, it should be considered when defining possible reasons for variance.

■ We must compare customers with open items on AR against the customer upload to ensure that the AR open items within the Finance cutover can be uploaded.  If any customers exist on the AR open items list that do not exist on the customer upload list, they will fail the AR open items upload.  This is another step in reconciliation since any customer who has an open item in AR should be set up as a customer in SAP.  Timeline for this comparison to be agreed to later, but suggest one to two weeks prior to cutover.

■ In addition to the point above, we must consider other objects that are dependent upon customer conversion for reconciliation.

■ SSAN customers for < LOC > will need to be merged with Irvine data during the Irvine rollout in order to merge or exclude duplicate Service Contracts and iBase, as needed.

■ An error correction and reload process will be defined in order to correct errors during the conversion process. This will need to be factored into the process.