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

Published on February 2017 | Categories: Documents | Downloads: 18 | Comments: 0 | Views: 325
of 69
Download PDF   Embed   Report

Comments

Content

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

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.

i

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.

ii

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

iii

List of Figures & Tables Fig No. 1 2 3 4 5 6 7 8 9 10 Description (Reference) Principal Modules within SAP (Scapens et al, 1998) The Family of SAP R/3 Modules (Hernandez, 1997) ASAP Roadmap - Fast Track Implementation (Accelerated SAP, 1999) The Phases of Data Migration (Hudicka, 1999) Flow Chart of Transferring Business Objects (SAP Labs, Inc, 1999) Table of Characteristics ISO 9126:1991 (ISO/IEC 9126:1991, 2000). The LSM Workbench Process (R/3 Simplification Group, 2000) Steps in LSM Migration Process (R/3 Simplification Group, 2000) ABAP Workbench Screen – Version 4.5B (SAP AG, 1999) ABAP Functions in detail (SAP AG, 1999) Page 4 5 7 19 21 29 30 31 32 32

iv

Contents Title Page

Page

Summary …………………………………………………….. i Acknowledgements ………………………………………….. ii List of Abbreviations ………………………………………... iii

List of Figures & Tables …………………………………….. iv Contents Page ………………………………………………... v Project Development ………………………………………... 1.0 Introduction …………………………………………………. 2.0 A Review of SAP R/3 ………………………………………... 2.1 vii 1 3 – 11

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

2.2 2.3

2.4

2.5 2.6

3.0 Legacy Systems at AETC Ltd ……………………………… 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 3.3

Legacy Problems ……………………………………….. Architecture of the Legacy Systems ……………………. 3.3.1 Open Standards ...………………………………... 3.3.2 Integration ……………………………………….. 3.3.3 The AS/400 and SAP R/3 ………………………..

15 15 15 16 16

3.4

Transfer Programs ……………………………………… 17 3.4.1 Transfer Program Interfaces ……………………... 17 3.4.2 Data Structures …………………………………... 18 Summary ……………………………………………….. 18 19 – 27

3.5

4.0 Data Transfer ………………………………………………... 4.1

Methodologies ………………………………………….. 19 4.1.1 Dulcien Inc ..……………………………………... 19 4.1.2 ASAP Methodology ……………………………... 20 SAP Data Transfer ……………………………………... Analysing Data …………………………………………. 4.3.1 Types of SAP Data ………………………………. 4.3.2 Issues with Data Transfer ………………………... 4.3.3 Problems with Data ……………………………… 4.3.4 Data Cleansing & Purging ………………………. 4.3.5 Data Source Structures …………………………... 20 21 21 22 22 23 24

4.2 4.3

4.4

Electronic Vs Manual …………………………………... 25 4.4.1 Transfer Methods ………………………………... 26 Legacy System Migration Workbench …………………. 26 Summary ……………………………………………….. 27 28 – 36

4.5 4.6

5.0 Data Migration within SAP R/3 ……………………………. 5.1 5.2

Evaluation Characteristics .……………………………... 28 Legacy System Migration Workbench (LSM) ..……….. 5.2.1 How the LSM Works ……………………………. 5.2.2 Import Interfaces ...………………………………. 5.2.1.1 Batch Input (BI) …………………………. 5.2.1.2 Direct Input (DI) ………….……………… 5.2.1.3 Intermediate Documents (IDOC) ………... 5.2.1.4 BAPI …………………………………….. 29 30 31 31 32 32 32

5.3 5.4 5.5

ABAP Workbench ……………………….……………... 32 Computer Aided Test Tool (CATT) ……..……………... 33 Tool Similarities ………………………………………... 34

v

5.6 5.7

Evaluation Results ……………………………………… 34 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

vii

Project Development.

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).
Info Comp Date Completed

Area/ Content What is SAP? What is its position in Market Place for ERP? What does it offer? Integration with modules etc What are its functionality’s? Portability, etc. Architecture of SAP? Methodologies etc? Solutions, Best Practice? Changes to company practises? Importance of using standard SAP? Identification of possible risks and opportunities for improvement? •

07/07/00 07/07/00 14/07/00 14/07/00 14/07/00 14/07/00 14/07/00 14/07/00

To study the current Legacy Systems*, i.e. AS400 system, Kronos, etc, from which AETC are extracting data.
Info Comp Date Completed

Area/ Content What legacy systems are being migrated from? Architecture of legacy systems? Is there a link with the SAP R/3 system? What transfer programmes are available? How do these Programme dumps for data, interface with other systems? Is the data transfer consistent in the legacy system? Transfer error in data. Quality of DBMS? What are its pros/ cons. •

19/07/00 20/07/00 21/07/00 21/07/00 21/07/00 21/07/00

To examine the issues of Data Transfer from manual to automatic.
Info Comp Date Completed

Area/ Content What factors have to be taken into account when migrating data? Data cleansing/ purging: what, when, how and why? Why is it costly when implementing a new system? 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. •

04/08/00 08/08/00 08/08/00

10/08/00

To evaluate the current process of Data Migration within the SAP R/3 system.
Info Study each and test with various Comp Date Completed

Area/ Content What migration techniques are available?
sets of data.

17/08/00 24/08/00 24/08/00 24/08/00

What are the differences between each? Is there a limit to the data they can take? Are there possibilities for improvements?

• 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. v

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.
07 Feb '00 S W 20 Mar '00 01 May '00 S T M F T 12 Jun '00 S W 24 Jul '00 S T

ID 1 2 3 4 5 6 7 8 9

Task Nam e Draft Interim Report Full tim e on Project Project Planning Study SAP R/3 System, inc background reading Evaluating Legacy Systems for data migration Examine issues of Data Transfer Evaluate current process of Data Migration Conclude on Data Migration from Legacy Systems Write up Project

Re-Plan.
ID 1 2 3 4 5 6 7 8 9 Task Nam e Draft Interim Report Full time on Project Project Planning Study SAP R/3 System, inc background reading Evaluating Legacy Systems for data migration Examine issues of Data Transfer Evaluate current process of Data Migration Conclude on Data Migration from Legacy Systems Write up Project inc Re-writes May June July August 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20

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.

vii

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. v

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,

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.

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).

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, crossfunctional 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),
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.

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

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 evii

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

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 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 Pre - Strategy Strategy Pre - Analysis Analysis Pre - Design Design Pre - Test Test Implementatio n Revise Maintenance

Explanation Determine the scope of the migration – data to be migrated and from what systems. Determine whether or not the scope is achievable by examining the actual data. Determine procedures and who will perform tasks. 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. This is essentially the start of data mapping, where the data model will be complete, i.e. developed from legacy reports and user feedback. Data Migration is an iterative process. Looks at Logical errors and physical errors – identifies flaws in files, when mapping data. Identify Logical errors and execute mapping to resolve it. Pilot run of the test data, after Testing is finalised. This is a subset of the last two and Maintenance. Clean up is undertaken here & revision of data model. 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; • • • • • • • • •

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.

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).

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 singlelevel 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 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

Characteristic

Description.

i) Sub – Charact eristic
Functionality (1) Suitability (a) Accuracy (b) Interoperability Security (d) (c) 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. Attributes of software that bears on the frequency of failure by faults. To recover data and re-establish its level of performance. 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. Attributes of software that provides response & processing time & throughput rates in performing its function. Resource Behaviour (b) Attributes of software that bear on the amount of resources used in performing function.

Reliability (2)
Usability (3)

Maturity (a) Recoverability (b) Understanding (a) Learnability (b) Operability (c)

Efficiency (4)

Time Behaviour (a)

Maintainabilit Analysability (a) y (5)
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. 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.

Portability (6)

Adaptability (a) Conformance (c) Replaceability (d)

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

Accelerating Data Migration: LSM Workbench How LSM Workbench works
One or several files
Legacy data on PC

Read data Structure relations

Read data
L egacy data on application server

Field mapping

Convert data

R/3 Standard

Conversion rules Converted data

Batch Input processing Direct Input processing IDoc inbound processing

SAP AG July 1999

21

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.

vii

Command Line: Enter transaction code

Customised migration process for a Batch Input Interface. Fig 8, Steps in LSM Migration Process (R/3 Simplification Group, 2000)

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

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).

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 reusabulity 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
Repository Browser Dictionary

Function

Ability to display and edit hierarchical lists of development objects. 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 reengineering 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 & ECommerce 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.tudresden.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: Programme of Study: Supervisor: Title of project: Geoffrey WARRISS. Information Systems. Prof. Martin Dyer. Data Migration from various Legacy Systems to SAP R/3.

External Organisation*:
*(if applicable)

AETC Ltd.

AGREED MARKING SCHEME Understand the Problem Produce Solution * a 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: Signature of supervisor: Agreed objectives and deliverables (continued):

Date: Date:

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 Weight Number of Legacy Inputs Weight Quality of legacy data Weight
Amount of legacy data editing < 500 501-2,500 2,500-10,000

Weight Number of data element translations Weight Complexity of legacy data Weight Number of SAP input data Weight Complexity of SAP input Weight Does an SAP transfer program exist? Weight Can data be entered as needed? Weight

See note 1 1 3 Good 2 Little 2 Few 2 Simple 1 1 or 2 0 Simple 1 Yes 5 Yes 0

0 2 or 3 2 Fair 1 Average 1 Average 1 Average 0 3 to 5 1 Average 0 No 0 No 1

1 4,5, or 6 1 Poor 0 Extensive 0 Many 0 Complex 0 6 to 10 2 Complex 0

>10,000 2 >6 0

Extra-complex 1 >10 3 Extra-complex 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
Financial Accounting

Business Object
Accounting Documents Assets G/L Account Master Customer Master Vendor Master

Program/ Transaction
RFBIBL00 RAALTD01 (Batch Input) RAALTD01 (Direct Input) RFBISA00 RFBIDE00 RFBIKR00 RFBVAT_0 RFBVCA_0 RFBVD__2 RFBVGB_0 RFBVIT_0 RFBVES_0 RFBCH_0 RPUSTD00 RPULKT00 RHALTD00 RCCTBI01 RCCLBI01 RCCLBI02 RCCLRI03 RMDATIND RM06IBI0 RM06BBI0 RM06EEI0 RM06EEI1 Purchase Order RM06EEI1 Order Development RSTXLITF Long Texts RM07RRES RM07MMBL RFBIKR00 CG31 CG32 CG33 RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP

FI- Bank Data

Transfer of Bank Data (Austria) Transfer of Bank Data (Canada) Transfer of Bank Data (Germany) Transfer of Bank Data (Great Britain) Transfer of Bank Data (Italy) Transfer of Bank Data (Spain) Transfer of Bank Data (Switzerland) Master Data (Organisational Units) Payroll Account Personnel Planning Data Create Characteristics Create Classes Create Classification Change Classification Material Master Purchase Information Records Purchase Requisitions Open Purchase Order

Human Resources

Materials Management

Reservations Stocks (Inventory Management) Vendor Master Materials Management Phrases (EH&S) Sources Substances Plant Maintenance Measuring Point Measurement Documents Notifications - General Functional Location Object Link Equipment Maintenance Plan vii

Scheduling Maintenance Plan Order Confirmation Equipment Task List General Maintenance Task List Functional Location Task List Production Master Create Bill of Material Change Bill of Material Create variant Bill of Material Create Bill of Material with Long Texts Routings/ Task Lists Documentation Info Record Demand Management

RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RIIBIP00/IBIP RCSBI010 RCSBI020 RCSBI030 RCSBI040 RCPTRA01 RCVBI010 RMMM60BI (Batch Input) RM60IN00 (Direct Input) RKCFILE0 RV14BTCI RFBIDE00 FVINVB00 RVAFSS00 RLPLAT00 RLBEST00

Production Planning

SAP- EIS Sales & Distribution

Several Records for SAP-EIS Condition Records (Pricing) Customer Master Open Sales Orders Invoicing External Transactions

Warehouse Management

Storage Bins Stocks on Storage Bins

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

vii

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close