Data Migration From Various Legacy Systems to SAP R-3 by Geoffrey Warriss

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 Migration 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 functionalitys? 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, Kronos, etc, from which AETC are extracting data.

Area/ Content Info Comp Date Completed 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.

Area/ Content Info Comp Date Completed 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 Migration within the SAP R/3 system.

Area/ Content Info Comp Date Completed 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/ Migration 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 Name1 Draft Interim Report

2 Full time on Project3 Project Planning4 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 Name1 Draft Interim Report

2 Full time on Project3 Project Planning4 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 August

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 & Distribution: 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 SAPs 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 clients 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 SAPs 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 Blueprint - 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 Live & Support - 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 1980s 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 companys 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/3s 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.

IBMs AS/400 is the worlds 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 IBMs CL (Command Language). The 400 can also run a variety of Java and Windows NT software components.

AETCs 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 Kronos.

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 organisations 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/400s.


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 companys 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 IBMs 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/400s 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 AETCs 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/400s.

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 companys 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 SAPs 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 AETCs 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. Codds twelve rules as set out by Date (2000). The AS/400s 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 Migration 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 functionalitys 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

Characteristic 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

Accelerating Data Migration: LSM WorkbenchOne or several

files

R/3 Sta

ndard

Convert data

Batch Inputprocessing

Legacy dataon PC

Read data

Converteddata

Read dataLegacy data

on applicationserver

IDoc inboundprocessing

Direct Inputprocessing

How LSM Workbench works

Structurerelations

Field mapping

Conversionrules

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 Line: 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 functionalitys, 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 projects 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

Chapter 3