This project is scoped on creating a centralized customer master Database. Data from Legacy system (Dealer Information Database) is going to be merged into SAP. SAP will be the Core Master Maintenance system.

A brief overview of the Legacy system- Dealer Information Database (DID):

DID is an Auto industry Dealer Information Database system that stored customers/Dealers information. It consists of customers who are primarily classified as dealers and non-dealers. They are

a) Ship-to locations

b) Warranty repair stations

c) Fleet companies

d) Auto Industry sub organizations

e) Plants

f) Government

g) Financial organizations

h) Distribution Centers (RDC,CDC)

It is a Mainframe DB2 database that stores dealers’ customer master data.

Following are the status used to determine DID customers:

a) History - completely done customers

b) Pending - they are creating the site

c) Active - Currently active

d) Terminate - out of business, not an active dealer, but still financially active

Here is a brief on what SAP is:

SAP stands for Systems, Applications and Products in Data Processing.

SAP is an enterprise resource planning (ERP) software product capable of integrating multiple business applications, with each application representing a specific business area.

These applications update and process transactions in real time, thus allowing seemingly, effortless integration and communication between areas of a business.

ABAP (Advanced Business Application Programming) is the programming language used in SAP.

A figure below that depicts SAP’s integration across different processes, function silos.

Here is a context diagram of SAP landscape that will be used for this project.

1.1 System Perspective

Given the volume of the DID data and the need for a stable, repeatable process of creating, changing and deleting customer master records, manual creation or change to the customer master data is not an option. The interface will bring in all the changes to the customer master on a daily basis to keep the systems in sync.

Manually modifying the customers would be tedious and error prone and may result in data inconsistency between the two systems. However, controlled manual intervention would be required to an extent (for SAP specific fields) once the interface is up and running.

1.1.1 High-level architecture diagram

The objective here is to have a global customer master repository in SAP for the purpose of billing and accounts receivables. DID, being the Gold System for dealer information, is one of the main source systems for customer master.

The purpose of the on-going interface is to maintain data consistency between DID and SAP customer masters.

Here is a comprehensive architectural overview of the system. It is intended to capture and convey the significant architectural decisions that have been made on the system.

1.1.2 Major system features

Benefits of implementing SAP Solutions:

Increase revenue: Access real-time data fast with SAP

Reduce costs: Gone are the days of costly and recurring customization

Adaptable: React quickly whenever your business needs to change and adjust to new market conditions

Complete solution: Run your entire business effectively with just the one solution

Personalized: Improve your employees’ productivity with a role-based user experience, built-in learning, analytics and collaboration

Improve customer relationships: Integral CRM arms your team with relevant information

Maintain IT solution as you grow: SAP will not hold your business back from growth

Clear, instantaneous insights: Create up-to-the minute dashboards

Business Critical alerts: Powerful alerts system

Improve efficiency: One centralized data repository

Support Multi-currency transactions: Multi-currency transaction and report capabilities

Multi-lingual capabilities: Available in 27 languages and 40 countries

Integrate with Microsoft Office: Word, Excel and Outlook

1.2 Operating Environment

Dealer Information Database is a Mainframe DB2 database that stores dealers’ customer master data.

UNIX is going to be the operating system on which SAP is installed and functions.

2 Use Cases

Create/Change Customer in SAP by Trigger from Legacy Systems

Use Case Identification and History
Use Case ID:		CMI_INT_001
Use Case Name:		Create/Change Customer Master Record In The Legacy Gold Source Systems		Version No:	1.0
Purpose:		The purpose is to create/change a customer master record in the SAP system whenever a request for creation/change of a customer is sent from a legacy system Below are the features specific to SAP – · DID – source system for dealerships. Approximately, 90% of the customers will come from DID. · The number assignment will be internal to local SAP instance. The account groups and the actual number ranges will not be affected by this decision.
Last Update by:		Mona Kaushal		On (date):	06/15/2010
User/Actor:		Interface
Business Owner Name:		Key business users		Contact Details:
Trigger:		Request for creation/change of customer from upstream system
References:		N/A
Frequency of Use:		Frequent – daily
Preconditions:		Customer created/changed in the legacy system
Post Conditions:		Customer masters are created/changed in SAP
Non-functional Requirements		None
Steps:		- Create request in legacy system to create/change customers in SAP - Trigger Customer Master Interface - Create/change customer master record in the SAP System: SAP ECC , DID
Step	User Actions		System Actions
1	Create request in legacy system to create/change customers in SAP		N/A – Legacy
2	Trigger Customer Master Interface		· Legacy system feeds data file to the GIF (Global Integration Factory) · The GIF passes on the data file to SAP through an IDoc.
3			· New customers are created in SAP from the data received from the interface by internal number assignment. · Existing customer master records are changed as requested.

2.1 Use Case Diagram

Use Case 2.1.1 CMI_INT_001-1: Create Customer Master Record in SAP

Use Case 2.1.2 CMI_INT_001-2: Change Customer Master Record in SAP

2.2 Use Cases

Use Case Identification and History
Use Case ID:		2.2.1: CMI_INT_001-1
Use Case Name:		Create Customer Master in SAP		Version No:	1.0
Purpose:		Creation of SAP customer master records directly in SAP - Going forward, SAP will be the Gold Source for DID customers. DID will send data file as mentioned in the mapping document. SAP will read the data, validate and then create the customer master in SAP system.
Last Update by:		Mona Kaushal		On (date):	06/15/2010
User/Actor:		Interface
Business Owner Name:		Key Business user		Contact Details:
Trigger:		Request for creation of DID into SAP
References:		N/A
Frequency of Use:		Frequent – daily
Preconditions:		Request for new customer is approved.
Post Conditions:		Customer masters are created in SAP
Non-functional Requirements		None
Assumptions, Issues:		· The request is approved · The customer does not already exist.
Steps:		- Create customer master record in the SAP system System: SAP Transaction – XD01
Step	User Actions		System Actions
1	Create customer master record in the SAP		· New customers are created in SAP

Use Case Identification and History
Use Case ID:		2.2.2. CMI_INT_001_2
Use Case Name:		Change Existing Customer Master in SAP		Version No:	1.0
Purpose:		Change an existing SAP customer master record in SAP - The customer masters for which SAP is the gold source can be changed in SAP. Going forward, SAP will be the Gold Source for DID customers. DID will send data file as mentioned in the mapping document. SAP will read the data, validate and then change the customer master in SAP system.
Last Update by:		Mona Kaushal		On (date):	06/15/2010
User/Actor:
Business Owner Name:		Key business user		Contact Details:
Trigger:		Request to change a customers in SAP
References:		N/A
Frequency of Use:		Frequent – daily
Preconditions:		Customer exists in SAP
Post Conditions:		SAP customer masters are changed as requested.
Non-functional Requirements		None
Assumptions:		· The request is approved · The customer already exists.
Steps:		- Change customer master record in the SAP System: SAP Transaction – XD02
Step	User Actions		System Actions
1	Change customer master record in the SAP		· Existing customer is changed

3 Functional Requirements

All the functional requirements are covered in the respective Deliverable objects list. The requirements will be gathered through the WORKSHOPS conducted with the business. Refer to the Workshop document for details.

3.1 Behavioral Requirements

3.1.1 Failed Transaction Handling/Error Handling for Interfaces

System/communication Errors:

The interface is run in scheduled background jobs. If a job does not run due to file accessing errors or technical reasons, or terminates while running the job, the support team monitors the jobs and takes follow up actions as per the established procedures.

If the interface was aborted in middle due to different technical reason, error is analyzed and if required the job is rescheduled.

Data Errors:

While processing the Legacy source file in SAP, data records are validated at field level for consistency with mapping rules and data related checks. The data records that pass through these checks will be loaded to SAP, but those that fail in the validation checks will not be loaded to SAP. The data records that fail in the validation will be stored in a custom table in SAP for later error correction and reprocessing in a job run called ‘Suspense run’.

Before processing the Legacy source file in a Regular job run, the interface is executed in a Suspense job run to load the corrected data records found in the previous Regular job.

There are two stages where errors can occur; before loading to SAP during validation and in the processing of the record in SAP.

There is no editing or correction done at the source file level in SAP. But, if there is a need to correct the failed data records at the Legacy source and resend them in a file to SAP, then these failed records in SAP will be archived first before reprocessing the file containing the erred data records, which will be a Regular job run.

3.2 Data Requirements

Here is the list of the Source system data elements: - DID

Error! Not a valid link.

Here is the list of the Destination system data elements: - SAP

Error! Not a valid link.

Details of the how the data will be translated to be covered in the Mapping document of the Functional Specification document.

3.3 Interface Requirements

Following are the Requirements that need to be gathered for the Interfaces

Frequency (realtime, xMinutes, xDaily, xWeekly, xMonthly)

How many files are we going to receive and when?
Answer: Every hour

Automated or Manual

Manual if someone has to kickoff the process, review the file beforehand, or manually upload/download a file like a spreadsheet
Answer: both manual and automated

Responsible Business Owner

Who from the business owns the process and interface?
Answer: Owned by the business Customer master team.

Responsible person for Legacy system:

Who owns from the deployment team and can answer mapping and technical questions?
Answer: Mona Kaushal

Data Transaction Volumes

How many records are coming per transmission?
Answer: Approximately 10 customer

3.3.1 Reporting Requirements

Report Name	Description/Use	Frequency
S_ALR_87012179 - Customer List	The customer list is used for displaying and for printing customer master data which is needed in the area of financial accounting. The list can be used for information and documentation. You can narrow down the number of customers to be printed using selection criteria. This includes, for example, the account number of the customer, the company code, a search term, or an interval for the selection criteria. Only customers for whom company-code-dependent master data exists, are displayed for the following entries.	Adhoc
S_ALR_87012180 Address List	The address list report displays customer address from the General view of the customer master record.	Adhoc
S_ALR_87012182 Display Changes to Customers	· You can use this report to display changes to the customer master record. Select options exist concerning the customer, the change date, the name of the person changing and the field group. Additionally, you can choose whether you want to see the changes for the general data, the company code data or the sales area data. Within each data range, you can set limits according to the organizational form	Adhoc
S_ALR_87012183 Display/Confirm Critical Customer Changes	· A program is used for displaying and changing the customer's confirmation status. · The confirmation status provides information as to whether sensitive fields have been changed in the customer master record.	Adhoc

4 N on-Functional Requirements

4.1 Language for IT systems

English will be the only language of communication for documentation, meeting, presentation, deliverable documents and workshops.

ABAP will be the programming language that will be used for SAP.

4.2 Documentation Requirements

Following are the list of documents that will be needed to be delivered at various stages of the project. Link below to go into the details.

http://code.google.com/p/customer-master-integration/

S.No	Description

1	Project Planning document
2	Project methodology document
3	Project milestones document
4	System Requirement document
5	Work-shop documents
6	Functional specification document
7	Mapping document
8	Technical specification document
9	Test Cases/scripts
10	Training manual
11	Minutes of Meeting

4.2.1 Safety Requirements

The documents will be loaded in a safe and secure location for uniqueness, consistency, avoiding data duplicity.

Access to the system will be restricted to the privileged group.

Backup of needed data will be maintained.

4.2.2 Training Requirements

Training documents will be detailed in the Training manual.

The training document will provide details on how to use the system in details with snapshots and step by step instructions.

4.3 Legal Requirements

This project will be governed by HGU rules and regulations and in accordance with the US legal rules/regulatory code.

4.3.1 Software Licensing Requirements

None

4.4 Hardware Requirements

Laptops, Desktop, HP UNIX Network, and other infrastructure needs to be installed before moving into the “Realization” mode of the project.

4.5 Software Requirements

The project system will be run on UNIX platform

The user community will use Windows, MS Office, SAP and other required tools to work on the project.

4.6 Disaster Recovery Requirements

Backup of the data, system will be maintained as scheduled.

4.7 Security Management Requirements

4.7.1 User Security Requirements

User privacy, security, access will be controlled by the System administrator and per the security norms.

4.7.2 Data Security Requirements

Data security will be maintained as per standard security norms baselined below:

Define Access Requirements

The data can be classified by its sensitivity (e.g., restricted, confidential) or by user role. Users can be classified by organizational unit, by user role, or by individual. Identify restrictions by data and user classification.

Define time frames when secure data cannot be published to non-secure staff.

Define Audit Requirements

Define audit requirements. Consider gathering information on connections, disconnections, data accesses, and data changes.

Define Network Requirements

Identify network requirements, such as data encryption/decryption and routing restrictions.

Define Data Requirements

Identify any legal restrictions that apply to data kept on customers, employees, etc. To meet legal restrictions it may be necessary to store summarized data so that individual entities (e.g., employees, companies) cannot be identified.

Identify data privacy laws that must be adhered to (e.g., most countries require that companies that hold data on customers must make this data available to the customer on demand).

Define data movement security requirements. The following should be considered:

· Can data be transferred to a diskette?

· Can data be stored on a PC?

· Who might have access to data transferred to a diskette or a PC?

· Do back-ups have to be encrypted?

· Where should back-ups be kept?

· Who might have access to the back-ups?

Define High-Security Requirements

If high levels of security are required, define the requirements, such as "trusted" versions of database management systems, "trusted" versions of operating systems, and secure facilities.

5 Assumptions, Constraints and Dependencies

The assumptions and dependencies considered are:

DID will continue to be the Gold Source System for dealers and will provide the customer master for conversion.
Dealers will not be created directly in SAP.
All changes to customer master records (DID data) will be initiated from DID system. However, changes to SAP specific data would be possible directly in SAP.
The Legacy system owners (DID) will ‘cleanse’ and ‘download’ the legacy data as appropriate, and provide the customer data under the required structure.
SAP will serve as a tool to facilitate the on-going interface processes and objects like mapping source & destination system fields, file format, file structure etc.
Only active customers will be extracted from the legacy systems.
The SAP team is responsible for:

Receiving valid Customer Master Data in SAP.
Processing source flat files.
Converting, mapping source fields as necessary.
Extending additional SAP values as necessary.

The Legacy System team is responsible for:

Extracting, converting, translating Legacy data into SAP required format as per the required guidelines

6 Conclusion

The Proposed solution meets the objective of interfacing legacy application Dealer information Database with SAP solution. This solution shall facilitate the Centralized Customer Master database system.

Implementation options for this solution have been detailed in the respective documents in the “Project deliverable document list ver 1.0.XLS” file.

Appendix A – System Requirements Information Gathering Template

Click the following link to get details of the documents pertaining to this project: