data migration from various legacy systems to sap r/3 · pdf filedata migration from various...

Data Migration from various Legacy Systems to SAP R/3

By

Geoffrey Warriss

MSc in Information Systems

1999/2000

The candidate confirms that the work submitted is his/ her own and the appropriate credit has been given where reference has been made to the work of others

Summary.

i

Summary

The MSc project is being undertaken, within a live implementation of the leading ERP software

SAP R/3 at AETC Ltd. The project is defined as 'Data Migration from various Legacy systems to

SAP R/3'.

The aim of the project, is to identify the data migration techniques in SAP R/3 as well as the

accompanying legacy systems at AETC Ltd, and analyse these and the methods used in

implementation. The following list of objectives has been generally defined to facilitate the

achievement of the project;

1. To undertake a comprehensive study of the SAP R/3 system (a review).

2. To study the current Legacy Systems from which AETC Ltd are extracting data.

3. To examine the issues of Data Transfer from manual to automatic.

4. To evaluate the current process of Data Migration within the SAP R/3 system.

5. To draw conclusions on Data Transfer/ Migration from Legacy systems to SAP R/3.

The report is divided into Six Chapters with the addition of various Appendices to support the

material within the sections, as well as providing a comprehensive reference list.

Chapter 2 satisfies the first objective and provides an overview of the SAP R/3 system. It identifies

what SAP is, what it offers, the structure, functionalities, architecture and the methodologies used.

Chapter 3 identifies the legacy systems in use at AETC Ltd, and what if any characteristics they

provide for effective migration to the SAP R/3 system. This chapter fulfils the second objective.

Chapters 4 and 5 outline the process of data transfer and migration within SAP R/3. They identify

the issues involved, with migrating data from legacy systems and the methods adopted. Chapter 4

investigates the various transfer techniques that are available within SAP, looking primarily at the

Legacy System Migration Workbench tool and its associated interfaces. These complete the third

and fourth objectives.

The final Chapter draws together relevant conclusions from the previous chapters, and highlights

the overall issues that need to be identified when data migrating.

Acknowledgements.

ii

Acknowledgements

There are a multitude of people that I need to thank for their assistance and advice that they have

afforded me, throughout both this project and the course.

I must in the first instance express my gratitude to everyone on the AETC SAP Implementation

Team, who were extremely helpful and cooperative in providing support, advice and the necessary

information, that has allowed me to complete this report. In particular, I would like to thank Peter

Cawtheray for sharing with me his comprehensive knowledge and for his supervision. A special

thanks also go to Richard Breen, once again for his in depth knowledge and generosity in providing

help and answers to my constant questions and Andrew Norvell for his depth and talents of ABAP

and the use of his increasingly expensive time.

In addition I would like to express my gratitude to Patrick McIlroy for identifying a possible project

at AETC Ltd. Simon Keay (SAP UK), SAP LSM and the Simplification Group who have been

extremely helpful in providing information. Vasco Madeira a man who has incredible focus and

self-management. Chris Dove for his incessant wit and professionalism. Martin Watmough and

Andrew Payne for there helpful direction and broadening knowledge of PP, Neil Webster, Derrick

Mkandla, David Holmes, Roger Thornton, Mike Foster, Mick Prest, Iain McClure, and the rest of

the SAP Team. Being involved with them all has been a very rewarding privilege.

A sincere thanks must also go to Professor Dyer for his experienced guidance and knowledge to the

completion of this report.

I would also like to thank my newfound friends and colleagues from across the globe for being

supportive and such genuine people, Kiran, Evangelo, Salvo, Owen, Ferry, Bola, Raj.

These acknowledgements would not have come to fruition without the support, both financially and

morally throughout my education, from my parents, Brian and Joan Warriss and to my brothers

Simon and Robin, who have provided the much needed motivation, wisdom and knowledge.

Finally I have a debt of gratitude to thank the sport of Cricket, the season starts when you need it

the most. The game has allowed me to release all my stress and frustrations unfortunately not

enough on the opposing teams.

List of Abbreviations.

iii

List of Abbreviations Abbreviation Meaning ABAP Advanced Business Application Programming API Application Programming Interface ASCII American Standard Code for Information Interchange ASP Application Service Provider ATM Asynchronous Transfer Mode BAPI Business Application Programming Interface BI Batch Input BMF Blade Machining Facility BOM Bill of Material CATT Computer Aided Test Tool CL Command Language DI Direct Input ERP Enterprise Resource Planning HR Human Resources IBM International Business Machines IDOC Intermediate Document IPCS Integrated PC Server IPX Inter-network Packet Exchange LSMW Legacy System Migration Workbench MAPICS/ DB Manufacturing Accounting and Production Information Control System/ Database MRP Material Resource Planning NCR Non Conformance Reporting NGV Nozzle Guide Vane PCC Precision Castparts Corporation PCF Precision Casting Facility ROF Repair and Overhaul Facility RPG Report Program Generator SAP Systems, Applications and Products in Data Processing SAP GUI SAP Graphical User Interface SME Small & Medium Sized Enterprises. SNADS Systems Network Architecture Distribution Services SQL Structured Query Language SXDA Standard Data Transfer – Transaction code VAR Value Adding Reseller WFMC Workflow Management Coalition

List of Figures & Tables.

iv

List of Figures & Tables Fig No. Description (Reference) Page

1 Principal Modules within SAP (Scapens et al, 1998) 4

2 The Family of SAP R/3 Modules (Hernandez, 1997) 5

3 ASAP Roadmap - Fast Track Implementation (Accelerated SAP, 1999) 7

4 The Phases of Data Migration (Hudicka, 1999) 19

5 Flow Chart of Transferring Business Objects (SAP Labs, Inc, 1999) 21

6 Table of Characteristics ISO 9126:1991 (ISO/IEC 9126:1991, 2000). 29

7 The LSM Workbench Process (R/3 Simplification Group, 2000) 30

8 Steps in LSM Migration Process (R/3 Simplification Group, 2000) 31

9 ABAP Workbench Screen – Version 4.5B (SAP AG, 1999) 32

10 ABAP Functions in detail (SAP AG, 1999) 32

Project Development.

v

Contents Page

Title Page

Summary …………………………………………………….. i

Acknowledgements ………………………………………….. ii List of Abbreviations ………………………………………... iii List of Figures & Tables …………………………………….. iv Contents Page ………………………………………………... v Project Development ………………………………………... vii

1.0 Introduction …………………………………………………. 1

2.0 A Review of SAP R/3 ………………………………………... 3 – 11 2.1 SAP AG ………………………………………………… 3 2.1.1 Market Position …………………………………. 3 2.2 What is SAP R/3? ………………………………………. 4 2.3 What does SAP R/3 offer? ……………………………... 4 2.3.1 Modules ………………………………………….. 4 2.3.2 Integration ……………………………………….. 5 2.3.3 Configuration & Customisation …………………. 6 2.3.4 Advantages ………………………………………. 6 2.4 Opportunity for Improvement ………………………….. 7 2.4.1 Standard SAP ……………………………………. 7 2.4.2 Methodologies …………………………………… 7 2.4.3 Investment ……………………………………….. 8 2.4.4 mySAP.com ……………………………………… 8 2.4.5 Application Service Providers …………………… 8 2.4.6 SAP Business Partners …………………………... 8 2.4.7 Risks, Opportunities and Weaknesses …………… 9 2.5 Functionalities ………………………………………….. 10 2.6 Summary ……………………………………………….. 10

3.0 Legacy Systems at AETC Ltd ……………………………… 12 3.1 The AS/400 …………………………………………….. 12 3.1.1 Business Information ……………………………. 13 3.1.2 Kronos …………………………………………… 13 3.1.3 UniPay …………………………………………… 14 3.1.4 MAPICS …………………………………………. 14 3.1.5 Other System ……………………………………. 14


v

3.2 Legacy Problems ……………………………………….. 15 3.3 Architecture of the Legacy Systems ……………………. 15 3.3.1 Open Standards ...………………………………... 15 3.3.2 Integration ……………………………………….. 16 3.3.3 The AS/400 and SAP R/3 ……………………….. 16 3.4 Transfer Programs ……………………………………… 17 3.4.1 Transfer Program Interfaces ……………………... 17 3.4.2 Data Structures …………………………………... 18 3.5 Summary ……………………………………………….. 18

4.0 Data Transfer ………………………………………………... 19 – 27 4.1 Methodologies ………………………………………….. 19 4.1.1 Dulcien Inc ..……………………………………... 19 4.1.2 ASAP Methodology ……………………………... 20 4.2 SAP Data Transfer ……………………………………... 20 4.3 Analysing Data …………………………………………. 21 4.3.1 Types of SAP Data ………………………………. 21 4.3.2 Issues with Data Transfer ………………………... 22 4.3.3 Problems with Data ……………………………… 22 4.3.4 Data Cleansing & Purging ………………………. 23 4.3.5 Data Source Structures …………………………... 24 4.4 Electronic Vs Manual …………………………………... 25 4.4.1 Transfer Methods ………………………………... 26 4.5 Legacy System Migration Workbench …………………. 26 4.6 Summary ……………………………………………….. 27

5.0 Data M igration within SAP R/3 ……………………………. 28 – 36 5.1 Evaluation Characteristics .……………………………... 28 5.2 Legacy System Migration Workbench (LSM) ..……….. 29 5.2.1 How the LSM Works ……………………………. 30 5.2.2 Import Interfaces ...………………………………. 31 5.2.1.1 Batch Input (BI) …………………………. 31 5.2.1.2 Direct Input (DI) ………….……………… 32 5.2.1.3 Intermediate Documents (IDOC) ………... 32 5.2.1.4 BAPI …………………………………….. 32 5.3 ABAP Workbench ……………………….……………... 32 5.4 Computer Aided Test Tool (CATT) ……..……………... 33 5.5 Tool Similarities ………………………………………... 34

Contents Page.

vii

5.6 Evaluation Results ……………………………………… 34 5.7 Summary ……………………………………………….. 36

6.0 Conclusions ...………………………………………………… 37 - 38 References Appendices

A Project Experience.

B Objectives & Deliverables.

C Marking Scheme & Interim Report Header Sheet.

D ASAP Documentation.

E SAP Data Transfer Matrix.

F Business Object Transfer Programs.

G ISO 9126: 1991 Software Evaluation

H Legacy System Migration Workbench


v


Project Concept.

It was decided that to obtain an overall understanding of the implementation and the SAP R/3

system, a live project involving Data Migration would be appropriate, as it has consequences

throughout the whole business system. This was duly accepted, as the potential future employment

benefits from being involved with a live SAP implementation will be invaluable.

The project has entailed being initially trained to use the data migration tool, the Legacy System

Migration Workbench (LSM), researching the details of AETC's Legacy systems and the elements

involved in data transfer within the SAP R/3 system.

Module Appreciation.

I have been able to gain a wide breadth of knowledge much quicker from the project due to the

structure of the MSc modules I have taken and the content of them. The modules that have been

very relevant to the project were in the main Business Process Re-engineering, Business

Information Systems, Information Modelling, Information Systems Engineering and Distributed

Information Management.

Project Management.

The project objectives were highlighted and a project plan was developed, generally as follows,

Project Objectives.

Title: DATA MIGRATION FROM VARIOUS LEGACY SYSTEMS TO SAP R/3.

Initial aim?

To identify the data migration techniques in SAP R/3 as well as the accompanying legacy systems at AETC Ltd, and analyse these and the methods used in implementation.

The following tables represent the requirements for each objective. As can be seen I have defined a

column for the information requirements, the desired completion date and fully completed date.


v

OVERALL OBJECTIVES: • To undertake a comprehensive study of the SAP R/3 System (a review).

Area/ Content Info Comp Date Completed

What is SAP? 07/07/00 What is its position in Market Place for ERP? 07/07/00 What does it offer? Integration with modules etc 14/07/00 What are its functionality’s? Portability, etc. 14/07/00 Architecture of SAP? 14/07/00 Methodologies etc? Solutions, Best Practice? 14/07/00 Changes to company practises? Importance of using standard SAP? 14/07/00 Identification of possible risks and opportunities for improvement? 14/07/00 • To study the current Legacy Systems*, i.e. AS400 system, K ronos, etc, from which AETC

are extracting data.


What legacy systems are being migrated from? 19/07/00 Architecture of legacy systems? Is there a link with the SAP R/3 system?

20/07/00

What transfer programmes are available? 21/07/00 How do these Programme dumps for data, interface with other systems?

21/07/00

Is the data transfer consistent in the legacy system? Transfer error in data. 21/07/00 Quality of DBMS? What are its pros/ cons. 21/07/00 • To examine the issues of Data Transfer from manual to automatic.


What factors have to be taken into account when migrating data? 04/08/00 Data cleansing/ purging: what, when, how and why? 08/08/00 Why is it costly when implementing a new system? 08/08/00 Data Transfer for business objects: 1. Identify fields. 2. Analyse legacy data. 3. Map legacy data to R/3. 4. Prepare legacy database. 5. Transfer data.

10/08/00

• To evaluate the current process of Data M igration within the SAP R/3 system.


What migration techniques are available? Study each and test with various sets of data.

17/08/00

What are the differences between each? 24/08/00 Is there a limit to the data they can take? 24/08/00 Are there possibilities for improvements? 24/08/00 • To draw conclusions on Data Transfer/ M igration from Legacy Systems to SAP R/3. To complete by the 31/08/00 * - With reference to AETC Limited.

Contents Page.

vii

The tables were used to initiate targets and milestones, so that information could be confidently

obtained and the objectives could be satisfied successfully.

Initial Project Schedule.

The project schedule was defined at the start of same and has been adjusted to accommodate

variations as and when they arise.

Re-Plan.

The above project schedule was more conducive to working on what is, by its application, a flow

process, i.e. the initial objective provided an all round understanding of the possibilities and allowed

the ongoing objectives to be satisfied as appropriate.

ID Task Nam e1 Draft Inter im Repor t

2 Full tim e on Project

3 Project Planning

4 Study SAP R/3 System, inc background reading

5 Evaluating Legacy Systems for data migration

6 Examine issues of Data Transfer

7 Evaluate current process of Data Migration

8 Conclude on Data Migration from Legacy Systems

9 Write up Project

S W S T M F T S W S T07 Feb '00 20 Mar '00 01 May '00 12 Jun '00 24 Jul '00

ID Task Nam e1 Draft Inter im Repor t

2 Full tim e on Project

3 Project Planning

4 Study SAP R/3 System, inc background reading

5 Evaluating Legacy Systems for data migration

6 Examine issues of Data Transfer

7 Evaluate current process of Data Migration

8 Conclude on Data Migration from Legacy Systems

9 Write up Project inc Re-writes

07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20May June July Augus t

Chapter 1 – Introduction.

v

1.0 Introduction.

The project topic was not a defined internal MSc project, but was very relevant to the Information

Systems perspective. The possibility of undertaking a project with AETC Ltd (an ex employer of

the author) was highlighted through management contacts at the company.

AETC Ltd is an Investment Casting company that specialises in the manufacture of components for

the hot section of the Gas Turbine Engine. They supply such companies as Rolls Royce, Pratt &

Whitney, ABB and GEC, with components for both Aerospace and Industrial markets.

The project will focus on the Data Migration to the ERP system, SAP R/3, from a number of legacy

systems, as implemented into a live roll out at AETC Limited. The company at the time of writing

is implementing R/3 into its facilities, as a pilot for the roll out to its American parent company

Precision Castparts Corporation (PCC). SAP R/3 is to replace the existing legacy systems namely

the IBM AS/400, which has become a bespoke and inflexible system and therefore has become

increasingly expensive to maintain.

The aim of the project is to identify the data migration techniques in SAP R/3 as well as the

accompanying legacy systems at AETC Ltd, and analyse these and the methods used in

implementation. To initiate the process a number of objectives were defined to facilitate the

achievement of the project, they are listed as follows;

6. To undertake a comprehensive study of the SAP R/3 system (a review).

7. To study the current Legacy systems from which AETC Ltd are extracting data.

8. To examine the issues of Data Transfer from manual to automatic.

9. To evaluate the current process of Data Migration within the SAP R/3 system.

10. To draw conclusions on Data Transfer/ Migration from Legacy systems to SAP R/3.

The report is divided up into Six Chapters with the addition of various appendices that support the

material within each, as well as providing a comprehensive reference list.

Chapter 2 is designed to satisfy the first objective and provide an overview of the SAP R/3 system,

highlighting the background to SAP, as well as identifying the technical aspects associated with the

system.


v

Chapter 3 is aimed at satisfying the second objective by the identification of the legacy systems in

use at AETC Ltd and what if any characteristics they provide for effective migration to the SAP R/3

system.

Chapter 4 and 5 outline the process of data transfer and migration within SAP R/3. Identifying the

issues involved with migrating data from legacy systems and the methods adopted. Chapter 4

investigates the various transfer techniques that are used within SAP, looking primarily at the tool,

the Legacy System Migration Workbench and its associated interfaces.

The final Chapter draws together conclusions from the previous chapters, and highlights the overall

issues that need to be identified and addressed when data migrating, as well as the SAP R/3 tools

used for data transfer.


v

2.0 A Review of SAP R/3.

This chapter introduces SAP R/3 by describing the structure and functionalities of SAP and in

addition, the architecture and methodologies that SAP follow in implementation.

2.1 SAP AG.

SAP is an Integrated Business system that has evolved from an original concept, first developed by

five former IBM German systems engineers in 1972. Twenty eight years later, the company has

developed into the industry leader and fourth largest independent software company, providing

enterprise wide solutions, that integrate the processes within enterprises and among business

communities.

SAP™ stands for Systems, Applications and Products in Data Processing. SAP AG is a worldwide

company based in Walldorf, Germany. The company has pioneered the development of ERP

(Enterprise Resource Planning) software systems in the client/ server market, with 1999 revenues of

∈5.11bn and almost 23,000 employees (SAP AG Annual report,1999, www.sap.com)

SAP AG has developed three very distinctive and powerful software products in the ERP market,

these being R/2 (for Mainframe computing), R/3 (for Client/ Server computing) and mySAP.com.

All three are integrated systems with the latter two being e-business enabled via the Internet.

2.1.1 Market Position.

SAP AG was the largest listing in terms of market capitalisation on the New York stock exchange

at $70billion. The boom continued by 1999 it held 32% of the ERP market (Tapsell, 1999).

SAP holds a superior standing with the Fortune 500 companies, the following lists these (Tapsell,

1999);

6 of the top 10 use SAP.

7 of the most profitable use SAP.

9 of the top 10 with the highest market value use SAP.

7 of the top 10 Pharmaceutical, Computer and Petroleum companies use SAP.

6 of the top 10 Chemical companies use SAP.

8 of the top 10 Electronic and Food manufactures use SAP.

Chapter 3 – Legacy Systems.

vii

This demonstrates the extent of the SAP software and customer spread across industries worldwide,

it's not just the large multinationals that can afford to implement SAP. SAP is now targeting small

to medium sized companies in order to expand their markets and knowledge.

2.2 What is SAP R/3?

SAP R/3 is an integrated Enterprise Resource Planning system. It comprises a set of business

modules that are designed from industry 'Best Practice' techniques. The software is built to operate

in the client/ server market, which is where the business logic can be held either on the server or

partly on the client, depending on the circumstances (www.sap.com, 2000).

SAP uses relational tables and adopts transactional processing to present information to the user

(Blain et al, 1997). The required data is keyed in or inputted automatically from peripheral

equipment, i.e. a bar-code scanner, and is transacted in the background, within the database server

via the application server (if a 3-Tier architecture is utilised). It is then presented in the SAP user

interface for its required use.

2.3 What does SAP R/3 offer?

2.3.1 Modules.

SAP R/3 provides a complete set of integrated applications, referred to as modules. These are

developed around industry best practice by SAP and cover most business functions. They include

the following:

Finance and Accounting: This includes Financial Accounting, Controlling Assets management

and a Project System.

Human Resources: This involves the full set of capabilities required to manage, schedule, pay and

hire human resources.

Manufacturing & Logistics: This is the most complex function and comprises the largest set of

modules, including materials management, plant maintenance, quality management, production

planning & control and Project Management.

Sales & Distr ibution: This function provides customer relationship management, sales order

management, configuration management, distribution, shipping and transportation management.

Fig 1, Principal Modules within SAP (Scapens et al, 1998)


vii

The array of R/3 products are shown in the SAP matrix as follows,

Fig 2, The Family of SAP R/3 Modules (Hernandez, 1997)

2.3.2 Integration.

Bancroft et al (1998) argue that there is no other comparable product available in the market place,

that satisfies the company wide set of totally integrated solutions as well as R/3. The global take up

of the system and as a result SAP's market leadership, appears to satisfy this observation.

A fully integrated system, means that each module can access other business modules (depending

on the information structure of the database tables) and provide real-time information on any aspect

of the enterprise. As a result SAP has stated that companies should re-engineer their business

wherever needed, so as to reduce the possible consequences in other modules (as data is integrated

and used elsewhere in the system). Scapens et al (1998) reiterates this by recognising that most SAP

implementations are accompanied by business process re-engineering.

SAP R/3 is most effective when it is applied within a manufacturing environment, although it is

also applied within the service and sales sectors. A company that has a top down structure (i.e.

Hierarchical) is said to be better suited to SAP R/3 due to the structure of the software itself

(Scapens et al, 1998).

The figure represents how the R/3

system is structured, i.e. the R/3 system

is client/ server based with the

integrated modules residing on the of

R/3 database.


vii

2.3.3 Configuration & Customisation.

SAP R/3, although designed around industry best practice solutions, still has to be adapted to the

particular needs of the business. With most companies there needs to be a major development phase

involving not only configuration and re-engineering, but customisation of the generic package.

There is a risk that customisation can become problematical and due to the expertise required, very

expensive. By modifying the standard software package into a ‘bespoke’ system, a different set of

issues are created, e.g. future SAP releases will require modification and SAP’s expensive

involvement. Bancroft (1998) and Macmillan (1998/99) support this view, as there is a possibility

of ‘hot patches’ and updates to SAP not functioning on the customised system.

Although customisation is in theory not an advisable road to take, in reality, a company may have to

undertake some customisation, after they have configured each module to its full capabilities. There

are however SAP R/3 versions called Industry Solutions that come pre-configured and customised.

These have been targeted at the SME market (Manufacturing Computer Solutions, 2000).

2.3.4 Advantages.

Once SAP R/3 is installed there are many elements within the package that can be 'turned on' to

improve productivity and automate many processes, such as ‘Workflow’. This will be discussed in

the next chapter.

Giles Farrow who is Reporting Systems Manager at Guinness Ltd, explains that SAP manages to

produce many positive benefits, through the design of the system of transaction processing, which it

does brilliantly (Durban, 1999).

The major benefit of implementing SAP R/3 is the reduction in overall costs that are generated from

not having to maintain the separate legacy systems. (Scapens et al, 1998). The legacy system

concept and implications will be discussed in the next chapter.

One of the most quoted examples of legacy system numbers is that of Owens-Corning Fiberglass

corporation in Ohio (they were one of the original SAP customers in America). They identified that

prior to the implementation of SAP they estimated they had 200 legacy systems across 80 sites.

Once SAP was introduced the legacy systems were reduced to less than 10 and the year on year cost

benefits were considerable (Lienert, 1996).


vii

2.4 Opportunities for Improvement.

2.4.1 Standard SAP.

Because SAP does not customise a system to a client’s needs, it forces business processes to be

tightly integrated across applications and across departments, ensuring corporate wide consistency

of information (Lienert, 1996).

To gain the necessary benefits from R/3 and the support of SAP, keeping as close to the standard

package as possible is very important. SAP is continuously updating their modules in order to

become more flexible in operation and more user friendly. A result of this is mySAP.com, which

takes advantage of the Internet as a communication tool.

It is very apparent to the author, from both reading and active involvement in actual in site system

preparation, that the implementation of SAP R/3 requires superior skills in managing the process

and the ongoing business. The system being a standard package also requires high quality, cross-

functional communication and a supportive organisational structure.

2.4.2 Methodologies.

AETC are using SAP’s Accelerated SAP methodology which is a process-oriented (rather than a

task-oriented) approach to implementation. It details all the elements within an implementation and

is defined on a ‘ roadmap’, which are self-explanatory. The roadmap is split into five sections and is

shown below (more detail in Appendix D),

Fig 3, ASAP Roadmap - Fast Track Implementation (Accelerated SAP, 1998).

Phases of ASAP. 1. Project Preparation - Initial

planning and scoping of project objectives.

2. Business Bluepr int - Detailed documentation of results from project preparation & refine goals.

3. Realisation - Implement business process requirements from Blueprint. Implement system, Test and configure. Includes development of data migration steps.

4. Final Preparation - System testing, end user training and fine tuning.

5. Go L ive & Suppor t - Move from pre-live to a live operation, including end user support.


vii

2.4.3 Investment.

SAP invests a great deal into systems development. This has placed SAP in the position they are in

today and the position they will surely maintain in the future. The package itself comes with many

software development tools, including the ABAP/4 Development Workbench, the Legacy System

Migration Workbench (LSM) and other integrated tools. The LSM is an addition to R/3 that allows

the conversion and transfer of legacy data from the legacy systems, making the whole process of

migration far more efficient and controlled. The R/3 data dictionary stores every modification,

update or deletion of any data or programme, which is used in SAP.

2.4.4 MySAP.com.

SAP employs 5,400 software developers (www.sap.com, 2000). With the launch of mySAP.com,

they are developing the e-business solution for companies as well as improving certain modules and

incorporating extra functionality. The strategy is to embed and improve new concepts such as

Knowledge Management and Customer Relationship Management. Geraldine McBride who is SAP

New Zealand MD states that the aim is to give companies predictive knowledge to make future

decisions (Tapsell, 1999).

2.4.5 Application Service Providers.

Macmillan (1998/99) claims that most companies feel a fully adopted enterprise wide solution is far

cheaper than the development and maintenance of a bespoke (legacy) system. It seems that in the

new millennium companies are out-sourcing their complete IT infrastructure to ASP (Application

Service Providers), a new phenomenon that is being born with the Internet. As these virtual

businesses operate and maintain an organisations applications, it is said that this isolates the users

from technology changes (Ranger, 2000). Giga Information Group states that companies should not

use ASP's for ERP's, however BT has been providing a service for certain modules within SAP R/3

for two years. SAP has launched their very own ASP called SAP Hosting in February of this year

(www.sap.com). This, however, is an issue that would be an interesting area for future projects.

2.4.6 SAP Business Partners.

SAP's growth has come through a partnership between various companies within varying sectors of

business. SAP provide resources for a total implementation. However this route tends to be an


vii

expensive option. Initially once a SAP product is chosen, it is handled through a VAR (Value

Adding Reseller). The VAR is a SAP certified company that provides all the consultancy needs for

the installation of each module (defined by the package the company decides to purchase).

The other elements of the implementation partnerships include Platform and Hardware services, the

Integration of new technologies, database and operating systems. The final partnership provides the

addition of upgrades to the SAP software.

2.4.7 Risks, Opportunities and Weaknesses.

Risks Bancroft et al (1998) states four possible risks with SAP R/3, these are based around technology,

flexibility, complexity and corporate strategy.

SAP is a standalone system that is based on 1980’s client/server technology. Because of this there

has been an alleged slow take-up. Bancroft et al (1998) argue that this is not the case as there have

been no recent developments in this technology and therefore no other comparable integrated

system. This appears to be the case, as only Oracle seems to be a close competitor.

SAP R/3 solutions are designed around American best practices and can therefore be difficult to

implement worldwide, which is significant, when re-engineering your business is part of the

implementation, as this usually involves a huge change in culture.

In the authors view implementing SAP R/3 is very complex, involving very detailed work plans and

schedules to assure a smooth and well executed cross over. It requires fundamental changes in

technology, business processes, management structures and job functions. Bancroft et al (1998)

states that the sheer scale of an implementation can overwhelm a SAP implementation team. This is

the main reason why SAP provides a VAR to offer a solid grounding of understanding that is vital

if the installation is to be successful.

SAP in all probability will not fit easily into a company’s corporate strategy and culture. Due to its

flexible integration capabilities, the many changes and configurations are almost always undertaken

successfully, allowing it to merge efficiently into the companies operations.


vii

Opportunities There are many opportunities to be gained by implementing SAP, from the integration of business

processes and having a reduced number of legacy systems to maintain to the reduction in overall

operating costs. These advantages can easily outweigh the objections to implementation.

Weaknesses As mentioned SAP is designed for transaction processing. However Giles Farrow (Durban, 1999)

admits that its design principles for information management are completely reversed. Farrow

highlights the fact that extracting meaningful data from SAP R/3 for business decisions is very

difficult, and is due to R/3’s uniquely constructed tables. The only viable option is to obtain the

services of an ABAP programmer to customise (previously deemed to be a bad idea) the interfaces

and pull the information from the required tables.

2.5 Functionalities.

SAP R/3 gains all its functionality, i.e. the integrated modules and the adaptability in the

configuration of them, through its Open Architecture structure and Portability. According to the

SAP 50 Basis Training Guide, the outstanding feature of the components, is the combination of up

to the minute technology with comprehensive business functions. The high level of application

integration ensures that all functions can be accessed directly through the system and therefore by

the user (SAP AG, 1998). This is achieved by the integrated relational database.

The Open architecture that SAP adopts also makes it fully compatible with most software and

hardware. It also enables interfacing through various standard protocols and networks, this is where

SAP gets its tag of ‘Guaranteed Portability’ . These are combined in their own level, above which

the system components are independent of the hardware and software environment (SAP AG,

1998).

2.6 Summary.

SAP is a German company that develops the leading integrated Enterprise Resource Planning

software. SAP R/3 is an integrated modular business process reengineering ERP, which can be fully

configured and customised only if absolutely necessary, as customisation is an expensive option.

SAP has many business partners that can support a customer's implementation from start to finish

and throughout the life of the software. MySAP.com is the latest ERP software from SAP and is e-


vii

business enabled. SAP R/3 has an open architecture where it is platform independent and cross

functional in every aspect.


vii

3.0 Legacy Systems.

‘Legacy systems are the information resources currently available to the organisation. They include

existing mainframes, personal computers, serial terminals, networks, databases, operating systems,

application programs and all other forms of hardware and software that a company may own’ (SES

Software Holdings Limited, 1995). This also includes any paper systems, e.g. manually indexed

systems.

AETC Limited operates their business processes on the industry standard, IBM AS/400 server

system. They initially adopted same because of its tried and tested excellence in hardware and

software integration, i.e. it comes complete with operating system, database software and system

management tools, etc. There is therefore no need to source these essential components from

different vendors.

3.1 The AS/400.

IBM’s AS/400 is the world’s most popular multi-user business computer, with over 600,000 sold in

over 120 countries. It's installed in 98 percent of the Fortune 500 companies and is enabled in 49

languages (IBM Corporation, 2000). IBM sells on average 50,000 units every year and has become

the first choice for any level of enterprise (Midrange Computing Editors, 1997).

The AS/400 runs on the renowned OS/400 operating system that has more than 28,000 licensed

applications and 3,500 client server applications, developed to run on it (Midrange Computing

Editors, 1997). The software programs are written in the AS/400 language, RPG (Report Program

Generator) and can be accessed via IBM’s CL (Command Language). The 400 can also run a

variety of Java and Windows NT software components.

AETC’s AS/400 system has been customised over the last 14 years and has consequently become a

bespoke system. The market and competition in their field of business, is ever demanding and

changing, and so requires the business system to either change with it or be able to provide the

necessary information, that allows the company to make accurate decisions. As a result certain

elements of the software components have been developed to suit their particular business and

operational needs.


vii

Within AETC four AS/400 units are operated. They run particular elements of the business, e.g. the

Payroll system is called UNIPAY from Rebus. One is dedicated to the business functions of the

company, and another is configured to hold their Time and Attendance system from Kronos. They

also have an AS/400 at their Leicester site that runs an ERP system called MAPICS.

3.1.1 Business Information.

The main AS/400 server holds all the central AETC business information (for BMF, ROF, NGV

and PCF) from Manufacturing information, to Human Resources information to Payroll

information. For HR and Payroll, the information is taken from Kronos and Unipay respectively,

these are AS/400 compliant software programs.

Manufacturing information includes such things as Part numbers, Operation Routings, Materials

used, Work in Progress, Costs, Vendors, Customers and so on. Human Resources information is all

aspects involved with employees, from Name and Address to Next of Kin and Job Function.

3.1.2 K ronos.

AETC uses the Kronos TimeKeeper/ AS system for Time & Attendance, but will expand its use for

Job Booking (i.e. employee time is accounted for against various jobs that are carried out, which is

required for costing). The TimeKeeper is an integrated solution for proactively managing your

organisation’s most valuable and expensive resource, employees (Kronos Incorporated, 2000).

The system's base application provides a foundation upon which other integrated modules make up

the midrange market's most powerful, most flexible solution for frontline labour management. This

allows an organisation to make real-time decisions by managing labour resources proactively and

more efficiently (Kronos Incorporated, 2000).

The system is specifically written in RPG/ CL so it can operate on the OS/400 platform. The data is

recorded via Swipe Cards through Terminals, but requires manipulation in the payroll system to add

value. This added value takes place through transferring the data, as the data has to be ‘ formatted’

so the Unipay system can make use of it. A Flat-File (ASCII) is created through an RPG program

and transferred by an IBM function called SNADS (Systems Network Architecture Distribution

Services). This uses an API that communicates the exchange of data via the IPX protocol. This is

the standard communication function used to communicate between AS/400’s.


vii

3.1.3 Unipay.

Unipay is also written in RPG and receives data from Kronos via the SNADS function, it can then

interpret the data and calculate the relevant information for every employee.

3.1.4 MAPICS.

MAPICS/ DB (Manufacturing Accounting and Production Information Control System/ Database)

is an ERP software that is capable of operating on the AS/400 and is used at the company’ s

Leicester Site (NGV), where machining of pre-assembled Nozzle Guide Vanes, as well as

machining of raw castings, is carried out.

The MAPICS system is queried and accessed using CL via the standard AS/400 interface.

3.1.5 Other Systems.

There are other business systems that are separate from the AS/400, but are still critical to the

operation of the business. Operational procedures are such systems that are crucial to standard

organisational practice. The information relating to these systems includes documents such as

Standard Practice Instructions or Production Planning Sheets. They are stored not on the AS/400

but on Windows NT Servers and are vaulted by file name, therefore the filename is the only key

identifier. The software used for this is called Data Ease (this has now been phased out and has been

removed from the system) (Breen, 2000).

The company also uses Lotus Notes software for email etc, but will be utilising it further for its

capabilities in Workflow. The Workflow Management Coalition (1999) define this as the

automation of a business process, in whole or part, during which documents, information or tasks

are passed from one participant to another for action, according to a set of procedural rules. There is

a Workflow module within SAP that could be used to automate the approvals of purchase

requisitions.

Lotus notes however, will be interfaced to SAP, and will use workflow for a process called Non

Conformance Reporting (NCR).


vii

3.2 Legacy Problems.

There are a number of problems that have been highlighted with regard to the effectiveness of the

current Legacy systems. The main points are that they either do not hold the necessary data for

accurate business decisions (i.e. the data is obsolete and inaccurate) or that the information available

has to be manipulated to become value adding to the company. When one considers, e.g. the

traceability & quality audit trails required in the aviation industry, then obviously the existing

system has its inherent weaknesses.

The biggest problem facing the company with regard to their legacy systems is that they have

limited integration between each other (Breen, 2000), this seems to contradict the IBM philosophy.

Having a bespoke system that also runs external software like Unipay and Kronos for Payroll and

some HR functionality, means that some data is constantly repeated. If a new employee is added to

the AS/400 human resources system, it then has to be replicated into both the Kronos and UniPay

systems. This can lead to many problems including incorrect input of data, a possibility of missing

data or no data at all in a particular system.

3.3 Architecture of the Legacy Systems.

The AS/400 system holds the majority of the legacy data, and it is therefore necessary to compare

the architecture of the legacy to the SAP R/3 architecture and expose any similarities that may aid

in migration.

3.3.1 Open Standards.

The AS/400 uses a unique layered architecture that enhances its integration with other hardware and

software. This is defined within IBM’s ‘OPEN’ Blue print. Ricke (2000) describes the structure of

the blueprint as a guide that helps its users choose the technologies and products needed to create a

solution. In effect it provides a technology independent base for system design, where there are no

restrictions.

The openness of the system is enhanced through a number of features such as TIMI (Technology

Independent Machine Interface), this sits between the applications and the hardware. It allows for

hardware independence.


vii

3.3.2 Integration.

The AS/400 is the champion of client/ server technology and uses the DB2/400 relational database

as its database server for the OS/400 operating system. The AS/400 has all the functions required,

which are fully integrated into the system, such as system management as well as communication

and network protocols (TCP/IP, SNA and ATM, Token Rings, Ethernet respectively). It uses an

object-orientated architecture to store and retrieve information, where an object represents a table

(IBM Corporation, 2000).

The OS/400 runs on 64-Bit RISC processor technology and uses a single level storage system (i.e.

both memory and disk storage are treated as one virtual address space), these also add to the

AS/400’s high integration factor (IBM Corporation, 2000).

The AS/400 client/ server capability also allows for platform independence, which gives it the

possibility to operate within Windows, Unix, OS/2 and Macintosh, and connection through

numerous communications protocols (Powers, 1999).

3.3.3 The AS/400 and SAP R/3.

Dawson (1998) identifies a number of similarities and elements that make SAP R/3 and the AS/400

so compatible. Firstly there is the object-oriented nature of the SAP application and its

accompanying language which bonds well with the object oriented architecture of the 400 and the

RPG language.

The objects in the AS/400 are used to store data in Physical files or tables, this is also how SAP is

structured and based. Both are accessed using a form of SQL that has been modified to suit the

particular language, but still uses the standard syntax.

SAP has been developed to be platform independent (i.e. Open technology), i.e. it is designed to run

on Windows and Unix servers, as well as many relational databases (SAP R/3, 1999/2000). The

SAP GUI can operate across the board on Windows, Unix, Macintosh and OS/2 workstations. The

AS/400 is also platform independent due to its range of client communication software (Powers,

1999).


vii

The major similarity involves the functional aspect of each, the AS/400 is fully integrated and SAP

is a total environment application (i.e. Programming Language (ABAP/4), Editor, Change

Management, Database, Data Transfer, etc) as stated by Dawson (1998).

3.4 Transfer Programs.

The AS/400 has a number of programs that can be used in migrating data. It would be prudent to

investigate the transfer programs available. Firstly the AS/400 has a standard Query Report Writer,

which uses SQL type commands to access tables and can output to a screen, printer or to file.

Windows NT is the choice of platform that runs AETC’s Microsoft products and Lotus Notes

software, which is also designed for a server environment, through an IPCS (Integrated PC Server)

formerly FSIOPS as described by Hirsch (1995) and Ahn et al (1998). The AS/400 uses a particular

transfer program for the PC environment called Client Access.

Client Access integrates the AS/400 with the clients and provides a great deal of functionality in

connection to obtain business information, applications and resources across the enterprise (Hutt et

al, 1998).

3.4.1 Transfer Program Interfaces.

The Client Access interfaces through a standard windows GUI and uses the IPX (Internetwork

Packet Exchange) protocol. This connection works at the network level of the communication (the

network level being a Token Ring, Ethernet or ATM network). This however is not the only

connection that the AS/400 and clients can use to communicate by, as previously mentioned the

AS/400 uses SNADS (as well as TCP/IP - a SAP standard protocol) to communicate with other

AS/400’s.

3.4.2 Data Structure.

The standard data transfer operation requires a flat file, as it needs the ASCII format to allow the

target to recognise the data structure.


vii

Once the transfer file is in the flat file format, the consistency of transfer is 100%, there is very

rarely any discrepancies with data once transferred, it would only happen if the user had defined the

wrong path or had used incorrect SQL commands (Breen, 2000).

3.5 Summary.

Legacy systems include bespoke IBM AS/400 applications as well as off the shelf packages that

integrate with the AS/400.

AETC is migrating from four AS/400 systems, used for different parts of the business. The reason

for migration is that the information available has to be manipulated to add value to the function of

the business.

There are certain elements of both the SAP R/3 and AS/400 architectures (i.e. object oriented

structure), that facilitates the migration at the logical level. The openness and integration of the

architectures allows for communication and platform independence.

The data transfer programs used within the current legacy systems is Client Access and is very

effective at the job it is required to do.


vii

4.0 Data Transfer.

Data Migration is possibly the most significant stage of any new system implementation. In most

literature read, the view is that migrating data is the most costly and demanding on resources.

Hudicka (1999) has the view that people do not fully understand the complexities of data migration

when a number of heterogeneous sources are involved. The author having first hand experience can

understand the implications of the view put forward, as the perception of being able to move data

simply, is certainly not the case. There are many issues prior to migration that need to be fully

understood and effectively planned.

4.1 Methodologies.

As data migration requires major effort from a company’s resources, it is essential to have a sound

methodology prior to undertaking a migration project. SAP has a standard methodology, but there

are others to note such as Hudicka.

4.1.1 Dulcien Inc.

Hudicka (1999) has outlined a methodology that should be developed in line with the overall phases

of the project, i.e. it integrates with all stages of project development and includes the following,

Phases Explanation Pre - Strategy Determine the scope of the migration – data to be migrated and from what systems. Strategy Determine whether or not the scope is achievable by examining the actual data. Pre - Analysis Determine procedures and who will perform tasks. Analysis In parallel with the core Analysis of the project, as any change to the data element or

‘Object’ in SAP will change the data model. Pre - Design This is essentially the start of data mapping, where the data model will be complete, i.e.

developed from legacy reports and user feedback. Design Data Migration is an iterative process. Pre - Test Looks at Logical errors and physical errors – identifies flaws in files, when mapping data.

Test Identify Logical errors and execute mapping to resolve it. Implementation

Pilot run of the test data, after Testing is finalised.

Revise This is a subset of the last two and Maintenance. Clean up is undertaken here & revision of data model.

Maintenance Data Mapping is validated and implemented through 'scripts', which have been put through the test phase.

Fig 4, The Phases of Data Migration (Hudicka, 1999).


vii

Hudicka identifies the need for a strict methodology, as in most other systems development, data

migration is not deemed to be of such importance. He stresses that data migration should be

initiated at the first planning stage of a project development, so the consequences of the

complexities involved are identified early on.

AETC Limited have considerable experience of large project development and have been able to

obtain outside expertise from the VARs, who were able to guide them in ascertaining their

requirements for migration to SAP R/3.

4.1.2 ASAP Methodology.

As defined in the review chapter most SAP implementations follow the SAP standard ‘Accelerated

SAP’ implementation programme, this has enabled AETC to plan their implementation effectively

from start to finish. The five phases represent different stages in implementation, similar to

Hudickas but not in the same detail.

The emphasis on methodologies is apparent when comparing the two. Hudickas’ highlights the

requirement for data migration throughout all phases (but is driven at projects where data migration

is overshadowed). ASAP angles slightly differently (as data migration is an integrated part of R/3),

by identifying the milestones that need to be reached for the whole project, with pre-planning being

a major element, in understanding the obligation to R/3. Only in the Realisation (discussed in

Chapter 2) stage is data migration explored, but in great detail especially with regard to its

important role within the project.

4.2 SAP Data Transfer.

SAP uses 'business objects' to describe a business process and could be for example a Purchase

Order. The objects are called up by SAP’s BAPI (Business Application Programming Interface),

where any external applications can use the business object (SAP AG, 1997). BAPI is a method of

data transfer and will be explored further in the next chapter.


vii

SAP follows a standard process for migrating the Business Object, it uses the following flow

process;

Fig 5, Flow Chart of Transferring Business Objects (SAP Labs, Inc, 1999)

The above flow chart provides an overview of the whole process of data migration within SAP,

from knowing your legacy systems and data, to how the data is formatted for SAP conversion.

There are several methods that can be used in SAP to transfer data.

4.3 Analysing Data.

Hudicka (1999) defines data migration as the collective process of data extraction, transformation

and cleansing, by moving data sets from one or more sources to an additional source. In AETC’s

implementation, the migration is taking place from the legacy systems as defined in chapter two, to

the SAP R/3 database. As highlighted within this chapter there are a number of issues that need to

be considered fully and understood, before migration takes place.

4.3.1 Types of SAP data.

SAP uses several types of data that are identified in its data dictionary. The data types are identified

by their functional purpose, these being Master Data, Transactional data and Customising Data

(Blain, 1997).

Identify the Fields

Analyse Legacy Data

Map Legacy Data to R/3

Prepare the Legacy data

Transfer Data

• Understand the data to be transferred and required Business Object. • Determine the Target file structure. • Determine legacy file structure. • Determine relevant data in legacy system for R/3. • Mapping assigns specific legacy data to SAP fields. • It defines the conversion process of the data. • Cleanse and Purge data before conversion • Convert Legacy file to a Flat file (ASCII) format. • Transfer data into R/3 by one of the methods available.


vii

Master Data (Static) is that which should change infrequently, for instance a Material Master,

Vendor Master, Customer Master, etc. This is critical business information that is migrated across

as a set of SAP Business objects, i.e. SAP uses business objects (as its Object Oriented Language)

to encapsulate R/3 processes and data, and make them available to the R/3 system (SAP AG, 1998).

Transactional Data (Dynamic) is used during data processing and is assigned to certain master data,

e.g. transaction data relating to a new purchase order, would be assigned to the Vendor Master

(SAP AG, 1999).

Customising Data includes system setting data and can control the business process, e.g. Material

Group Codes.

4.3.2 Issues with Data Transfer.

Initially those involved in migrating data need to understand firstly what data is to be migrated from

the legacy system, this can vary as data can come from heterogeneous data sources that are not

necessarily part of the main database systems. Secondly there is a need to understand the structures

of the data sources involved. This will provide the persons involved with an understanding of what

data is relevant and how the legacy data is to be structured within the SAP system. It is at this point

that the persons involved in migration realise the criticality of the data and the consistency of their

database.

4.3.3 Problems with Data.

A companies database historically can become overrun with obsolete, inaccurate and duplicated

data. These are not just the common problems faced, there is a further classification of problem

data, which involves data that does not conform to system standards. This is normally associated

with the target system, i.e. the SAP R/3 database.

An example of this at AETC is the data held for a material identification number on the AS/400.

The necessary data is displayed within three fields as a Category, Number and Suffix (Breen, 2000).

This is not in an acceptable data format for SAP, as SAP displays this in just one field. Therefore

preparatory formatting is essential to get the required information into the correct migration format

for SAP, this kind of data is commonly known as ‘Dirty Data’ (Hudicka, 1999).


vii

There are other issues such as Invalid Characters and Character Combinations (Hudicka, 1999),

which may not be supported by the target system, but need to be altered. In SAP during an upload

of data, if a non-recognisable character is contained within the data, the ABAP generated program

will place the data within speech marks, this can then be edited out. An example of this is text

containing commas and single quotes (Breen, 2000).

There are certain conditions that need to be followed, as with any database, Null values are not ideal

and SAP uses a standard ‘no data’ value, typically ‘ /’ to represent this.

If these data violations (Hudicka, 1999) are not anticipated and dealt with there is a costly

consequence of having invalid data being migrated into the target system. This situation identifies

the major effort required in data migration, especially with Data Cleansing and Purging. This key

area will be discussed in the next section.

A problem that arose during the analysis stage at AETC identified that SAP required a ‘Material

Master’ file as a business object, but AETC did not have a valid material master in its entirety at the

PCF (Cawtheray, 2000). The result being the need to create one, which was a very lengthy and

expensive process that involved data cleansing of their AS/400 system, in order to create the

required file.

4.3.4 Data Cleansing & Purging.

Cleansing data can require a major effort and be very costly, data migration as a whole is said to

take up around 20% of the entire implementation budget (R/3 Simplification Group, 2000), data

cleansing can be a large percentage of this, depending on the complexities of the cleansing required.

Data cleansing is the process of removing dirty data from the legacy database, the result of which

creates a valid and consistent database (including any external paper systems etc). The majority of

data cleansing is focused on correcting the database so that the data is accurate, valid and current

(Blain, 1997).

There is another step that is known as ‘Data Purging’ and is identified as being the deletion process

for obsolete and unwanted data. AETC has needed to go through a major cleansing and purging

program, when creating their material master at the PCF.


vii

4.3.5 Data Source Structures.

The data source (AS/400) and target system (R/3) are of the relational database design and therefore

follow E. F. Codd’s twelve rules as set out by Date (2000). The AS/400’s DB2/400 uses single-

level storage, where each object (used to handle information) is addressed with a location in

storage. This allows for faster retrieval of information and greater management of data (IBM

Corporation, 2000).

SAP R/3 also uses the relational database architecture which is designed around thousands of tables

and a number of proprietary mechanisms (Durban, 1999) such as Pooled and Clustered tables,

which are defined within the ABAP Data Dictionary.

Table Pools

A pooled table has data stored in the appropriate table pool, i.e. data of several tables can be stored

together as a table pool in the database.

Clustered Table

A clustered table has data stored in the appropriate table cluster, i.e. several records from different

cluster tables can be stored together in one physical record in a cluster table.

Transparent Table There is a third category of table called a transparent table that is created in the database, similar to

a ‘view’ created within SQL.

This gives a sense that the data stored within SAP is highly structured and uses the standard foreign

key to emphasise relationships and dependencies between tables. These are commonly known

within R/3 as Check Tables (Norvell, 2000).

Although there is a logical structure, there is no defined common structure to the data with regard to

the integration between the AS/400 and SAP R/3 (Breen, 2000). The SAP database requires far

more data than the AS/400 currently holds and this must be in a particular format for SAP to be able

to make use of it. The lack of a defined link is highlighted with certain 'Master Data’ , for example

‘Routings’ and ‘Bills of Materials’ . SAP requires defined links between master data and the

underlying tables, to allow for the transactions to take place.

Within the tables, header and item levels are used to reference the data. The header level defines the

top level of a file and the mandatory fields to be used within SAP for controlling the transaction,


vii

e.g. Part Number and Plant. The detail of the header level is held within the item level. The Header

has a one to many relationship (1 � M) with the item level, an example of this could be a Bill Of

Material (BOM) for a given part number. The part has many materials that go into its manufacture

and therefore is seen as being multi-level.

4.4 Electronic vs Manual.

SAP uses an object to define master data (i.e. the business objects), but it also uses this information

to deduce the type of data transfer, i.e. Electronic or Manual. This is a decision made by the

migration team, and is primarily determined by the volume of data to be migrated. There is a

standard set of guidelines that is used to determine the transfer method, which can be viewed in

Appendix E.

Electronic data Transfer is via a standard program, which is developed for a specific Business

Object and ensures data consistency. It can also be performed by one of the other methods, which

are identified in section 4.4.1.

Manual data entry is carried out when there is little data to transfer. The data has no automatic

consistency checks, as it is transacted directly into the R/3 database. It therefore has to go though a

stringent process of accuracy and completeness checks, as the format has to be exact, i.e. the field

formats must conform to how they are set up in the SAP database. If configuration changes are

made to the table, then manual entered data has to be re-entered (R/3 Simplification Group, 1999).

Hudicka (1999) outlines the features required for a data transfer tool, as being able to report its

operation, to be able to generate code mapping (as defined in SAP Object transfer), to be able to

reduce script processing time and to be able to automatically detect any data integrity violations.

The Electronic transfer method available within SAP has all and more of these functions designed

into its operation. This will be evaluated in the next chapter.

4.4.1 Transfer Methods.

Once the type of transfer is determined, it is then possible to decide what method to use to transact

the objects into SAP, of which there are a number.


vii

If the manual method is used, the data is transacted in manually. It is important that all data is

transacted through using one of the defined methods, as the SAP software may not work correctly

(when data is transacted, Logs are created defining the meta data of the data transferred, including

location, size, etc.) (R/3 Simplification Group, 1999).

Within SAP R/3 the following transfer methods are available, the use of which depends on the

business object defined;

1. SAP Data Transfer Programs – Used for transferring standard SAP Business Objects.

2. SAP Workbench - Used to develop ABAP transfer programs.

3. LSM - The Legacy System Migration Workbench uses standard interfaces, such as

• Batch Input (BI), Direct Input (DI), BAPI's (Business Application Programming

Interfaces) or IDOC's (Intermediate Documents).

4. CATT - Computer Aided Test Tool which allows the recording of transactions.

All of the data held on the AETC legacy systems was manually formatted during the cleansing

process and presented in a flat file format. These flat files (that represented the business objects)

were then automatically transacted into the R/3 database, using primarily the Legacy System

Migration Workbench, Batch Input interface, which will be highlighted in the next section.

4.5 Legacy System Migration Workbench (LSM).

SAP R/3 incorporates a migration tool called the LSM. This allows companies to migrate data from

non-SAP systems (i.e. Legacy Systems) as well as SAP R/2 systems to SAP R/3. The LSM was

developed from the old R/2 – R/3 data transfer workbench, which is integrated into the capabilities

of the LSM (R/3 Simplification Group, 1999).

The LSM supports conversion of data from the legacy system in a convenient way, i.e. it has a

logical method that can be followed easily. The data can then be imported into the R/3 system via

one of the aforementioned interfaces. It also has the added benefit of providing a recording function

that allows you to generate a business object in an entry or change transaction. (R/3 Simplification

Group, 2000)


vii

4.6 Summary.

Hudickas methodology emphasises data migration activities throughout an implementation, whereas

SAP identifies data migration as the penultimate event in implementation.

There are many issues regarding the structure and format of data before migration can take place,

these involve consistency, structure, type and cleansing.

Data can be transferred electronically by numerous methods within SAP, i.e. the LSM or can be

transacted manually. SAP defines a data object, instead of fields and records that is migrated as a

whole into the R/3 database.


vii

5.0 Data M igration within SAP R/3.

As identified in the previous chapter, there are several methods available to transfer data into the

SAP R/3 database. This section will highlight each and use the ISO standard for evaluating

software. The author has taken the view, that the methods available are functionality’s of the overall

software product R/3 and therefore not stand-alone systems.

The standard method of migration, is to use the built in programs that are provided to transact the

various business objects into the R/3 database (see Appendix F). These are accessed by entering the

'Transaction Code' either within the LSM or with the SXDA (Data Transfer workbench) within

which there is a drop down list of objects.

These specific programs, have been developed from tried and tested solutions for migrating objects

from source to target, and therefore have assured results in data consistency. They have been

designed to accurately map the standard fields, by using established mapping conversion rules that

the SAP R/3 tables require for a relevant business object (Gradl et al, 1998).

If a standard program is not available then other methods can be used, all with varying degrees of

operation. As previously stated SAP has a standard tool, the LSM, that automates the whole process

of transacting data. There are alternative methods e.g. the ABAP Workbench (which is the core tool

within SAP) that can be used to develop a transaction program, such as the standard programs. The

Computer Aided Test Tool (CATT) is used primarily for creating manual and automatic test cases

e.g. test recorded transactions (SAP AG, 1999).

5.1 Evaluation Characteristics.

The criteria to be used is based on the ISO/ IEC 9126: 1991, Information Technology - Software

Product Evaluation (Quality characteristics & guidelines for their use) standard. There are a number

of sub-characteristics that are available within each main characteristic (see Appendix G).


vii

ISO 9126:1991

Character istic i) Sub –

Characteristic

Description.

Functionality (1)

Suitability (a)

Accuracy (b)

Interoperability (c)

Security (d)

Attribute of software that provides set of functions for specified tasks.

Attributes of software that bears on the provision of correct results, effects.

Attributes of software that allow it to interact with specified systems.

Attributes of software that allows ability to prevent unauthorised access.

Reliability (2) Maturity (a)

Recoverability (b)

Attributes of software that bears on the frequency of failure by faults.

To recover data and re-establish its level of performance.

Usability (3) Understanding (a)

Learnability (b)

Operability (c)

Attributes of software that allows users to recognise the application.

Attributes of software that allows the user to learn the application.

Attributes of the software to allow effective operation & control by user.

Efficiency (4) Time Behaviour (a)

Resource Behaviour (b)

Attributes of software that provides response & processing time &

throughput rates in performing its function.

Attributes of software that bear on the amount of resources used in

performing function.

Maintainability (5)

Analysability (a)

Changeability (b)

Stability (c)

Testability (d)

Attributes of software that bear on effort needed to diagnose deficiencies,

failures or identification of parts to be modified.

Attributes of software to allow modification, fault removal etc.

Attributes of software that allows the unexpected effect of modifications.

Attributes of software that on effort to validate the software.

Portability (6) Adaptability (a)

Conformance (c)

Replaceability (d)

Attributes of software that allows it to adapt to other environments.

Attributes of software that adheres to standards of portability.

Attributes of software that allows opportunity to use it in place of another

piece of software, in that environment.

Fig 6, Table of Characteristics ISO 9126:1991 (ISO/IEC 9126:1991, 2000).

The relevant characteristics in Fig 6 will be identified according to the manner in which the

characteristic fit the tools. The following sections will give a brief description of the tool and the

method it uses for transfer.

5.2 Legacy System Migration Workbench (LSM).

The LSM is a multi-functional tool and allows business objects to be created, deleted or changed

and then migrated (in the flat file format), via a 26-step migration process, which can be customised

depending on which 'interface' is chosen initially. The process takes the user through the whole


vii

migration concept by defining object attributes, structures, relationships, mapping conversion rules

and the actual required flat file.

5.2.1 How the LSM Works.

� SAP AG July 1999 21

Accelerat ing Data Migrat ion : LSM Workbench

One or severalf i les

R/3 S

tandard

Convert data

Batch Inputp rocessing

Legacy dataon PC

Read d ata

Converteddata

Read dataL egacy data

on app licat ionserver

IDoc inbou ndprocessing

Direct Inputp rocessing

How LSM Workbench works

Structurerelat ions

Field m apping

Co nvers ionru les

Fig 7, The LSM Workbench Process (R/3 Simplification Group, 2000)

The first stage of the migration process is to determine the Project name and the desired object that

is to be transferred. Once the ‘object’ is identified, the following sequential process is used to

transact the object into the LSM, using one of the available interfaces.

The LSM process involves inputting source files that have been converted into a flat file and read into the LSM. The data is converted. This process determines the structural relations between source and target and defines how the fields will be mapped & converted. This creates the load file, which can then be imported by one of the Interfaces.


vii

5.2.2 Import Interfaces.

Once the LSM generates the ABAP transaction program it is then required to be transacted, this is

achieved by one of the four interfaces. The interfaces update the database and provide the

consistency needed for an accurate database, which was highlighted by the author and Hudicka in

chapter 4.

5.2.2.1 Batch Input (BI).

This is the most common interface (for standard transfer programs) and is used to transfer large

amounts of data. BI simulates manual entry, ie. It follows the same screen transactions that one

would have to follow if doing same manually. When the BI is run it creates a BI session, which is a

data file that has details of conversion rules etc that have been previously defined. It also checks for

errors in the data before transacting it into the database (R/3 Simplification Group, 1999).

It is possible to see how the BI is processed, i.e. in the background (a Log is generated and provides

a history), foreground (ability to step through the transactions, similar to online entry) or display

errors only (errors are shown and can be amended online).

Customised migration process for a Batch Input Interface.

Once a step is complete a log is created, recording the history

Command L ine: Enter transaction code

Fig 8, Steps in LSM Migration Process (R/3 Simplification Group, 2000)


vii

5.2.2.2 Direct Input (DI).

The DI method is available for some core business objects, i.e. Master Data. It is used to check data

thoroughly, but does not have the capability of BI with processing options. Fortunately there are

two methods available,

1. If the DI program aborts mid way through processing, the user must be able to identify which

records were correctly transacted and delete them from the flat file.

2. If the user starts the program directly and it aborts prematurely, when restarted there is no need

to change the flat file, as the data was transacted successfully and when re-run does not

duplicate the records.

(R/3 Simplification Group, 1999)

5.2.2.3 Intermediate Documents (IDOC).

The IDOC was developed to exchange messages between systems. The IDOC technique converts

read data into 'packages' and stores same in its own format, until it is called up by the program and

processed (R/3 Simplification Group, 1999). This process is an option for bulk data transfer, but

was not used while the author was at AETC.

5.2.2.4 BAPI.

The BAPI as defined in section 4.2, defines the Business Object and provides the attribute of re-

usabulity due to its purpose, as with the re-usable conversion rules of the migration objects (R/3

Simplification Group, 1999).

5.3 ABAP Workbench.

The ABAP Workbench allows the creation of a flat file (as with the BAPI). It provides general

functions such as correction to a program, transport of a program, a data dictionary, etc. It is also a

test environment (this includes the CATT also), where the program can be compiled and run. It can

then be transported (the SAP term for transferring programs, configurations etc) into the system.


vii

Fig 9, ABAP Workbench Screen – Version 4.5B (SAP AG, 1999)

Tool Function Repository Browser Ability to display and edit hierarchical lists of development objects. Dictionary Ability to define and save data definitions Ability to store documentation, help

information, data relationships, and other information. The Dictionary can be used to generate database objects like tables and indexes. The Dictionary is a central storage area for system-wide data definitions. The definitions are stored centrally and are therefore available for use anywhere in any program throughout the system.

ABAP Editor Ability to create and edit program code. Function Builder The Function Builder is used to define and store function modules. The

Function Builder stores these modules centrally. A library is available to write new modules and look up information on existing modules.

Screen Painter Ability to design screens in an application's GUI. Menu Painter Ability to design menus that appear in the GUI Fig 10, ABAP Functions in detail (SAP AG, 1999) The above table represents the functions of the workbench in detail.

5.4 Computer Aided Test Tool (CATT).

The CATT is the fully integrated test tool of the ABAP Workbench. The CATT is used to create

manual and automatic test cases, i.e. an automatic transaction that has been recorded (part of its

function - can also be recorded using the LSM). SAP AG states that the tool is very flexible in

transferring data and acts very similar to a BI.

It CATT uses the following sequence, record transaction, generate test module (using the relevant

transaction screens involved), assign parameters to the module and export this to create a text file.

Once the file is tested, data transfer can take place.


vii

5.5 Tool Similarities.

There is a visible relationship between the various ‘ tools’ . Using the LSM as a point of reference for

the others, there are certain attributes of CATT that are integrated into the LSM functionality’s, e.g.

testing, consistency checks and the ability to perform recordings. The ABAP workbench obviously

underpins both of these tools because of the ABAP language and the integration of the CATT. It

uses the ABAP editor to create code for a transaction and can test same within the ABAP

Workbench (Norvell, 2000).

AETC have made good use of the LSM but have not needed to use the IDOC or BAPI functions,

due to the effectiveness of the BI, DI and Recording capabilities.

AETC have used a standard transfer program in the AS/400 (Client Access) to import the data into

a flat file, by exporting it into an Excel spreadsheet. As a result AETC were able to use the LSM to

migrate this data into R/3 by highlighting which fields were relevant to SAP by using the SAP

standard field names.

5.6 Evaluation Results.

The following evaluation is based on the ability to create a data transfer program and uses a rating

to define the effectiveness of each tool, regarding the appropriate characteristics (section 5.1). The

rating will use a measure of 1 to 5, where five represents the best correlation to the characteristic. It

is acknowledged that the CATT is a functionality of the ABAP workbench, consequently these two

tools will be 'integrated' and evaluated as one.

The evaluation shows that although the ISO standard characteristics are reasonably rigid an

integrated tool can contain certain design elements that meet the requirement characteristics.

The LSM as identified is the standard tool and is designed to create a transaction program and use

its interfaces to transact data into the R/3 database.

5.7 Summary.

SAP uses a number of methods to create a transaction program, the preferred method is to use the

standard business programs that can be initiated by using the SXDA transaction code. The standard


vii

programs already have the required defined structures of the file and designate certain values to

certain SAP fields for the particular business object.

SAP has developed a migration tool called the LSM that can create and transact a business object

into R/3 by using a Batch Input, Direct Input, IDOC or BAPI interface.

The ABAP Workbench is a multifaceted tool, which is used primarily for program development. It

can perform other operations such as defining a recording for a transaction.

The evaluation of each tool using ISO 9126:1991 has proven that the LSM satisfies a majority of

the characteristics to a reasonable efficiency, as does the ABAP workbench. The author reiterates

that migrating data is the LSM's core design function.


vii

6.0 Conclusions.

SAP has been the pioneering force in the revolution of improving business integration and

performance, by developing enterprise wide systems. Its market leadership with R/3 the ERP

system for the client/server market is proving to be unbeatable.

R/3's architecture plays a key role in its adoption as 'open standards' and 'platform independence'

will surely continue to dominate the software market. Its fully integrated modular structure,

transaction processing and effective reporting capabilities have convinced companies in ever

increasing numbers to deploy same in place of their legacy systems.

SAP however is not the ideal software package in its standard form. SAP requires very careful

appraisal in its planning stage, in order to limit the amount of customisation that may otherwise take

place. It is an opportunity for process change, due to its process rather than task oriented nature.

SAP is a very complex system and as such, the whole process of implementing R/3 is very

demanding on an organisation, in the respect that existing processes and procedures will after re-

engineering be changed in many cases completely. A smooth implementation is paramount,

following SAP's ASAP methodology will provide a framework to follow. As with any other new

complex system implementation there are hidden problems that can hamper progress and hence

success.

The author concludes that data migration is certainly an element that if planned successfully can aid

effective implementation. Data migration is the fundamental building block for the whole system, if

the process is to be successful there are a number of fundamental issues that need to be understood.

The users must understand what historical data will be of use and in what format it needs to be.

There will always be a necessity to cleanse the data before migration as a database can become

overrun with obsolete, inaccurate and duplicated data. The challenge is to identify these early on

and purge them from the system, as the R/3 system will only be as good as the data that is in being

transacted into the system.

Data migration to SAP from legacy systems is a very structured and logical process, the use of the

various SAP tools, i.e. the LSM, provides the needed consistency that most databases fail to

achieve. The validation measures within the tools create data integrity and the SAP business objects


vii

extend the consistency. The only flaw is the inherent inconsistencies with manual data entry, which

is only limited to user entry.

It is true to say that the amount and complexity of data that needs to be captured and processed

simply cannot be underestimated. Understanding the structure of the existing legacy systems, i.e.

the AS/400, assists greatly in actual data preparation and utilising a tool that can query the database

and download data into a file can save considerable time. It is also important to understand the

relationships within the SAP database structure and how the data will relate to this.

Data migration is stated to take up about 20% of the overall implementation budget, when one takes

into account that a SAP implementation can run into the millions, then data migration becomes a

large constituent of this and therefore requires overall effective planning and management.

Overall the completed project has satisfied the objectives that were initially set. The contents have

highlighted the key issues that were identified, within the scope of what is a live project at AETC

Ltd.

The project’s completion has without doubt been assisted by a clear, concise and achievable plan.

The end product should have hopefully attained and satisfied, the standards that the intended

audience require.


vii

References.

• Accelerated SAP (1998), Accelerated SAP Implementation Assistant- version 4.15.0, SAP AG

• Ahn, J., Hofstetter, J., Mazema, L., Perera, L. & Zimmer, F (1998), SAP R/3 Implementation for

AS/400, 3rd Edition, International Business Machines Corporation.

• Apex Systems Ltd (1999), Data Migration Introduction, Apex Systems.

• Bancroft, N.H., Seip, H., Sprengel, A (1997), Implementing SAP R/3, 2nd Edition, Manning.

• Blain, J & Consultancy, ASAP World (1997), Special Edition Using SAP R/3, 2nd Edition, Que

Corporation.

• Breen, R (2000), IT Projects, AETC Limited.

• Cawtheray, P (2000), IT Manager, AETC Limited.

• Coalition, Workflow Management (1999), Terminology & Glossary, The Workflow

Management Coalition Specification, Doc No. WFMC-TC-1011, Issue 3, p 8.

• Curran, T., Keller, G. & Ladd, A (1998), SAP R/3 Business Blueprint: Understanding the

Business Process reference model, Prentice Hall.

• Date, C.J (2000), The Database Relational Model: A retrospective review and analysis,

Addison-Wesley Publishing company.

• Dawson, M (1998), SAP and the AS/400, Coffee Break,

http://www.midrangecomputing.com/coffeebreak/bi.cfm?bi=980401.cfm

• Dulcian (2000), Data Migration, http://www.dulcian.com/data_migration.htm

• Durban, M (1999), Access denied how Guinness overcame the difficulties of extracting data to

populate a data warehouse with valuable business information, Managing Information, Vol. 6,

no.6, pp 38-40.

• Faden, M (2000), Data Cleansing helps E-Business run more efficiently: Data Mining & E-

Commerce have exposed problems with the management of information, Information Week

Online.

• Gradl, J & Dascakowsky, K (1998), Accelerated Data Migration, SAP AG,

http://www.sap.com/press/magnews/regular/dt_1098e/s20.htm

• Gradl, J (1999), Making Migration, www.sap.com/press/magnews/regular/ma_1199/5056.htm

• Hernandez, J.A (1997), The SAP R/3 Handbook, McGraw-Hill,

http://advisor.gartnerweb.com/n_inbox/hotcontent/hc_081898_2.html

• Hirsch, H (1995), AS400 Integrated File Server (FSIOP),

http://www.tug.on.ca/articles/sep95v11n1AS400IntegratedFileServer.html

• http://www.mysap.com

• http://www.sap.com


vii

• http://www.sapfans.com

• Hudicka, J.R (1999), So, you say your Data’s clean, Huh?!?, Dulcian, Inc, www.dulcian.com

• Hudicka, J.R (1999), The complete data migration methodology, Dulcian, Inc,

www.dulcian.com

• Hutt, N., Kin, M.C., Lee, D., Rizzo, J., Roehm, B., Ryymin, J., Smith, M.M., Steen, G.V.,

Vebele, H (1997), Inside AS/400 Client Access for Windows 95/NT V3 R1 Mod2, IBM

Corporation, International Technical Support Organisation – Rochester Centre.

• IBM Corporation (2000), AS/400 Guided Tour,

http://www.as400.ibm.com/overview/tourindex.htm.

• ISO/IEC 9126:1991 (2000), Information technology: Software product evaluation (Quality

characteristics and guidelines for their use), International Standards Organisation.

• Kronos Incorporated (2000), TimeKeeper AS Suite, http://www.kronos.com/products/tkas.htm.

• Lienert, A (1996), Getting in the Pink, Management Review, vol.85, no.5, pp 18-23.

• Macmillan, M (1998/99), Enterprise-wide Systems in Education: A Case Study of SAP R/3 at

the University of Leeds, MSc Project - School of Computer Studies.

• Manufacturing Computer Solutions (2000), News & Analysis: Manufacturers to be offered

pre-configured SAP, Manufacturing Computer Solutions, vol. 6, no. 5, p 8.

• Midrange Computing Editors (1997), Coffee Breaks with the Editors,

http://www.midrangecomputing.com/coffeebreak/bi.cfm?bi=970618.cfm.

• Norvell, A (2000), SAP ABAP Consultant, Avalon Systems Development Ltd.

• Powers, S (1999), AS/400 System Handbook,

http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R3PDF/EZ3AER01.PDF.

• R/3 Simplification Group (1999), Data Transfer Made Easy: Step by Step guide to SAP Data

Transfer, Release 4.0B – 4.5x, SAP Labs, Inc.

• R/3 Simplification Group (1999), Initial Data Transfer Made Easy: Step by Step guide to SAP

Initial Data Transfer, Release 4.0B, SAP Labs, Inc.

• R/3 Simplification Group (2000), Data Migration of Non- SAP Systems to R/3: Quick

introduction to working with the Legacy Systems Migration Workbench – Version 1.6.6, SAP

Labs, Inc.

• Ranger , S (2000), Hosting: beware the shake-out, Computing - 3rd August, p 9.

• Ricke, D (2000), Technical Notes- A 3 Dimensional framework for information technology

solutions, IBM Systems Journal, vol.39, no.2, pp 336-359.

• SAP AG (1997), BAPI Introduction and Overview- R/3 Release 4.0, SAP AG.

• SAP AG (1998), SAP 50 Basis Technology, SAP AG.


vii

• SAP AG (1999), SAP Online Help 4.5B- Glossary, SAP AG.

• SAP AG (1999/2000), SAP R/3, SAP Labs, Inc.

• Scapens, R., Jazayeri, M and Scapens, J (1998), SAP integrated information systems and the

implications to management accountants, Management Accounting, vol. 76, no.8, pp 46-48.

• SES Software Holdings Limited (1995), BOMA™-Legacy Systems, http://www.mpgfk.tu-

dresden.de/~weise/docs/boma/0-1.html.

• Sharpe, S (1999), SAP R/3 in 10 Minutes, SAMS Publishing.

• Tapsell, S (1999), The growth merchants, Management NZ, vol. 46, no.5, pp 20-24.

• Whatis.com (2000), Terminology, http://www.whatis.com/index.htm.


vii

Appendix A: Project Experience


vii

Project Experience.

Having the opportunity to undertake a project within a working environment has been a very

rewarding experience, especially one of this scale and relevance. I believe I have gained three

positives from the project,

1. I have been able to interact with highly qualified professionals.

2. I have gained valuable experience in a field, that I might not have done with an in house project.

3. I believe the environment and knowledge that I have been involved with has enabled me to

develop and further my inter-personal and management skills, which in today’s labour market is

very important.

SAP R/3 as a whole is a very complex system to implement, and without question needs dedicated

project management. SAP R/3’s underpinning methods are certainly cutting edge and trying to

understand fully what it can achieve has been an absorbing experience. Its flexibility in both

operation and integration is without doubt superior to any other product on the market.

It is absolutely essential to be involved within a live implementation because of the access to

documentation that would otherwise need to be purchased, which in the case of SAP is normally

very expensive. There is also the benefit of gaining knowledge from professionals involved with

implementation.

I have found it quite strange that software implementations have such highly specific guidelines for

project management, there are numerous publications, documentation’s etc that back this up. In the

case of an implementation that involves data migration, there is little or no information available

that both describes and encourages the pro-active management of a data migration project.

Having clearly defined objectives and a plan of how they are to be achieved has certainly been very

beneficial. Identifying the required scope, literature and knowledge to achieve them has provided an

excellent future in project management, as my career progresses.

Above all careful planning is absolutely essential and understanding how to satisfy the objectives is

of paramount importance, to a successful project.


vii

Due to the remit of this project, I have found it stressful at times with regard to following the MSc

Project handbook. I feel it is biased or too focused towards a software development project. If a

student wishes to understand an element of the course in more detail, then the MSc Project

Handbook should be able to guide the student along, not produce some statements that are

confusing.

My advice to any future project undertaken, is if an obstacle interrupts the train of thought, then

step back and focus on a small part of the project that can be achieved without any problems, i.e.

keeping an effective reference list or making sure the whole project is formatted correctly. This will

give the feeling of flow and will improve the overall productivity of the project.

Above all, try and obtain a project that is value adding and enjoy it, four months goes very quickly.


vii

Appendix B: Objectives & deliverables


vii

School of Computer Studies

MSC PROJECT OBJECTIVES AND DELIVERABLES This form must be completed by the student, with the agreement of the supervisor of each project, and submitted to the MSc project co-ordinator (Mrs A. Roberts) by 7th April 2000. A copy should be given to the supervisor and a copy retained by the student. Amendments to the agreed objectives and deliverables may be made by agreement between the student and the supervisor during the project. Any such revision should be noted on this form. At the end of the project, a copy of this form must be included in the Project Report as an Appendix.

Student: Geoffrey WARRISS.

Programme of Study: Information Systems.

Supervisor: Prof. Martin Dyer.

Title of project: Data Migration from various Legacy Systems to SAP R/3.

External Organisation*: AETC Ltd.

*(if applicable)

AGREED MARKING SCHEME

Understand the Problem

Produce a Solution *

Evaluation Write -Up Appendix A

TOTAL

%

20 40 20 15 5 100

* This category includes Professionalism (see handbook)

OVERALL OBJECTIVES (continue overleaf if necessary):

• To undertake a comprehensive understanding of the SAP R/3 System.

• To analyse the current Legacy Systems, i.e. AS400 system etc, from which AETC are extracting data.

• To examine the issues of Data Transfer from manual to automatic transfer.

• To evaluate the current process of Data Migration within the SAP R/3 system.

• To draw conclusions from Data Transfer/ Migration.


vii

DELIVERABLE(s):

1. A project report.

2. An Interim report.

3. A final presentation of the overall project.

Signature of student: Date:

Signature of supervisor: Date:

Agreed objectives and deliverables (continued):

Amendments to agreed objectives and deliverables:

Date Amendment


vii

Appendix C: Marking Scheme & Interim Report Header


vii

Appendix D: ASAP Documentation


vii

Appendix E: SAP Data Transfer Matrix


vii

Conversion Evaluation Matrix Score Number of Objects < 500 501-2,500 2,500-10,000 >10,000

Weight See note 1 0 1 2 Number of Legacy Inputs 1 2 or 3 4,5, or 6 >6

Weight 3 2 1 0 Quality of legacy data Good Fair Poor

Weight 2 1 0 Amount of legacy data editing Little Average Extensive

Weight 2 1 0 Number of data element translations

Few Average Many

Weight 2 1 0 Complexity of legacy data Simple Average Complex Extra-complex

Weight 1 0 0 1 Number of SAP input data 1 or 2 3 to 5 6 to 10 >10

Weight 0 1 2 3 Complexity of SAP input Simple Average Complex Extra-complex

Weight 1 0 0 1 Does an SAP transfer program exist?

Yes No

Weight 5 0 Can data be entered as needed?

Yes No

Weight 0 1 Total Score: Notes: 1. If the number of objects is less than 500, the legacy data is complex, the SAP input is complex,

and an SAP standard data transfer program exists, an automatic conversion is the best solution. Otherwise, a legacy data report and manual data input should be used.

2. A score of 5 or less indicates that a manual conversion is the most cost-effective solution. 3. A score between 5 and 10 indicates that either a manual conversion or an automated conversion

may be a cost-effective solution, but the evaluation factors should be carefully reviewed before deciding a recommended course of action.

4. A score of 10 or more indicates that an automated conversion is justified.


vii

Appendix F: Business Object Transfer Programs


vii

SAP Standard Business Object Data Transfer Programs. Module Business Object Program/ Transaction Financial Accounting Accounting Documents RFBIBL00 Assets RAALTD01 (Batch Input) RAALTD01 (Direct Input) G/L Account Master RFBISA00 Customer Master RFBIDE00 Vendor Master RFBIKR00 FI- Bank Data Transfer of Bank Data (Austria) RFBVAT_0 Transfer of Bank Data (Canada) RFBVCA_0 Transfer of Bank Data (Germany) RFBVD__2 Transfer of Bank Data (Great Britain) RFBVGB_0 Transfer of Bank Data (Italy) RFBVIT_0 Transfer of Bank Data (Spain) RFBVES_0 Transfer of Bank Data (Switzerland) RFBCH_0 Human Resources Master Data (Organisational Units) RPUSTD00 Payroll Account RPULKT00 Personnel Planning Data RHALTD00 Materials Management Create Characteristics RCCTBI01 Create Classes RCCLBI01 Create Classification RCCLBI02 Change Classification RCCLRI03 Material Master RMDATIND Purchase Information Records RM06IBI0 Purchase Requisitions RM06BBI0 Open Purchase Order RM06EEI0 RM06EEI1 Purchase Order RM06EEI1 Order

Development RSTXLITF Long Texts Reservations RM07RRES Stocks (Inventory Management) RM07MMBL Vendor Master RFBIKR00 Materials Management (EH& S)

Phrases CG31

Sources CG32 Substances CG33 Plant Maintenance Measuring Point RIIBIP00/IBIP Measurement Documents RIIBIP00/IBIP Notifications - General RIIBIP00/IBIP Functional Location RIIBIP00/IBIP Object Link RIIBIP00/IBIP Equipment RIIBIP00/IBIP Maintenance Plan RIIBIP00/IBIP


vii

Scheduling Maintenance Plan RIIBIP00/IBIP Order Confirmation RIIBIP00/IBIP Equipment Task List RIIBIP00/IBIP General Maintenance Task List RIIBIP00/IBIP Functional Location Task List RIIBIP00/IBIP Production Master Create Bill of Material RCSBI010 Change Bill of Material RCSBI020 Create variant Bill of Material RCSBI030 Create Bill of Material with Long Texts RCSBI040 Routings/ Task Lists RCPTRA01 Documentation Info Record RCVBI010 Production Planning Demand Management RMMM60BI (Batch Input) RM60IN00 (Direct Input) SAP- EIS Several Records for SAP-EIS RKCFILE0 Sales & Distr ibution Condition Records (Pricing) RV14BTCI Customer Master RFBIDE00 Open Sales Orders FVINVB00 Invoicing External Transactions RVAFSS00 Warehouse Management

Storage Bins RLPLAT00

Stocks on Storage Bins RLBEST00


vii

Appendix G: ISO 9126 : 1991 Software Evaluation


vii

Functionality

A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. (ISO 9126: 1991, 4.1)

Functionality

Suitability: Attribute of software that bears on the presence and appropriateness of a set of functions for specified tasks. (ISO 9126: 1991, A.2.1.1) Accuracy: Attributes of software that bear on the provision of right or agreed results or effects. (ISO 9126: 1991, A.2.1.2) Interoperability: Attributes of software that bear on its ability to interact with specified systems. (ISO 9126: 1991, A.2.1.3) NOTE -- Interoperability is used in place of compatibility in order to avoid possible ambiguity with replaceability. (ISO 9126: 1991, A.2.1.3) Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. (ISO 9126: 1991, A.2.1.4) Security: Attributes of software that bear on its ability to prevent unauthorised access, whether accidental or deliberate, to programs and data. (ISO 9126: 1991, A.2.1.5)

Reliability

A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. (ISO 9126: 1991, 4.2) NOTE -- Wear or ageing does not occur in software. Limitations in reliability are due to faults in requirements, design and implementation. Failures due to these faults depend on the way the software product is used and the program options selected rather than on elapsed time. (ISO 9126: 1991, 4.2)

Reliability

Maturity: Attributes of software that bear on the frequency of failure by faults in the software. (ISO 9126: 1991, A.2.2.1) Fault tolerance: Attributes of software that bear on its ability to maintain a specified level of performance in cases of software faults or of infringement of its specified interface. (ISO 9126: 1991, A.2.2.2) Recoverability: Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it. (ISO 9126: 1991, A.2.2.3)

Usability

A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. (ISO 9126: 1991, 4.3) NOTES

1. `Users' may be interpreted as most directly meaning the users of interactive software. Users may include operators, end users and indirect users who are under the influence or dependent on the use of the software. Usability must address all of the different user environments that the software may affect, which may include preparation for usage and evaluation of results.

2. Usability defined in this International Standard as a specific set of attributes of software product differs from the definition from an ergonomic point of view, where other characteristics such as efficiency and effectiveness are also seen as constituents of usability. (ISO 9126: 1991, 4.3)

Usability

Understandability: Attributes of software that bear on the users' effort for recognising the logical concept and its applicability. (ISO 9126: 1991, A.2.3.1) Learnability: Attributes of software that bear on the users' effort for learning its application (for example, operation control, input, output). (ISO 9126: 1991, A.2.3.2)


vii

Operability: Attributes of software that bear on the users' effort for operation and operation control. (ISO 9126: 1991, A.2.3.3)

Efficiency

A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. (ISO 9126: 1991, 4.4) NOTE -- Resources may include other software products, hardware facilities, materials, (e.g. print paper, floppy disks) and services of operating, maintaining or sustaining staff. (ISO 9126: 1991, 4.4)

Efficiency

Time behaviour: Attributes of software that bear on response and processing times and on throughput rates in performing its function. (ISO 9126: 1991, A.2.4.1) Resource behaviour: Attributes of software that bear on the amount of resources used and the duration of such use in performing its function. (ISO 9126: 1991, A.2.4.2)

Maintainability

A set of attributes that bear on the effort needed to make specified modifications. (ISO 9126: 1991, 4.5) NOTE -- Modifications may include corrections, improvements or adaptation of software to changes in environment, and in requirements and functional specifications. (ISO 9126: 1991, 4.5)

Maintainability

Analysability: Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified. (ISO 9126: 1991, A.2.5.1) Changeability: Attributes of software that bear on the effort needed for modification, fault removal or for environmental change. (ISO 9126: 1991, A.2.5.2) Stability: Attributes of software that bear on the risk of unexpected effect of modifications. (ISO 9126: 1991, A.2.5.3) Testability: Attributes of software that bear on the effort needed for validating the modified software. (ISO 9126: 1991, A.2.5.4)

Portability

A set of attributes that bear on the ability of software to be transferred from one environment to another. (ISO 9126: 1991, 4.6) NOTE -- The environment may include organisational, hardware or software environment. (ISO 9126: 1991, 4.6)

Portability

Adaptability: Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions or means than those provided for this purpose for the software considered. (ISO 9126: 1991, A.2.6.1) Installability: Attributes of software that bear on the effort needed to install the software in a specified environment. (ISO 9126: 1991, A.2.6.2) Conformance: Attributes of software that make the software adhere to standards or conventions relating to portability. (ISO 9126: 1991, A.2.6.3) Replaceability: Attributes of software that bear on the opportunity and effort of using it in the place of specified other software in the environment of that software. (ISO 9126: 1991, A.2.6.4) NOTES

3. Replaceability is used in place of compatibility in order to avoid possible ambiguity with interoperability.


vii

4. Replaceability with a specific software does not imply that this software is replaceable with the software under consideration.

5. Replaceability may include attributes of both installability and adaptability. The concept has been introduced as a subcharacteristic of its own because of its importance.

Evaluation process

Source ISO 9126: 1991, 5.3. The evaluation process consists of three stages and it may be applied in every appropriate phase of the life cycle for each component of the software product: Quality Requirement Definition: The purpose of the initial stage is to specify requirements in terms of quality characteristics and possible subcharacteristics. Requirements express the demand of the environment for the software product under consideration, and must be defined prior to the development. As a software product is decomposed into major components, the requirements derived from the overall product may differ for the different components. Evaluation Preparation: The purpose of the second stage is to prepare the basis for evaluation. This stage consists of three components:

Quality metrics selection

: The manner in which quality characteristics have been defined does not allow their direct measurement. The need exists to establish metrics that correlate to the characteristics of the software product. Every quantifiable feature of software and every quantifiable interaction of software with its environment that correlates with a characteristic can be established as a metric. [...] Metrics can differ depending on the environment and the phases of the development process in which they are used. Metrics used in the development process should be correlated to the user respective metrics, because the metrics from the user's view are crucial.

Rating levels definition

: Quantifiable features can be measured quantitatively using quality metrics. The result, the measured value, must be interpreted as a rated value, i.e. divided into ranges corresponding to the different degrees of satisfaction of the requirements. Since quality refers to given needs, no general levels for rating are possible. They must be defined for each specific evaluation.

Assessment criteria definition

: To assess the quality of the product, the results of the evaluation of the different characteristics must be summarised. The evaluator has to prepare a procedure for this, using, for instance, decision tables or weighted averages. The procedure usually will include other aspects such as time and cost that contribute to the assessment of quality of a software product in a particular environment.

Evaluation Procedure: The last step of the Evaluation Process Model is refined into three steps, namely measurement, rating and assessment.

Measurement:

For measurement, the selected metrics are applied to the software product. The result is values on the scales of the metrics.

Rating:

In the rating step, the rating level is determined for a measured value.

Assessment:

Assessment is the final step of the software evaluation process where a set of rated levels are summarised. The result is a statement of the quality of the software product. Then the summarised quality is compared with the other aspects such as time and cost. Finally managerial decision will be made based on the managerial criteria. The result is a managerial decision on the acceptance or rejection, or on the release or no-release of the software product.


vii

Appendix H: Legacy System Migration workbench