ATHABASCA UNIVERSITY

BEST PRACTICES - IMPLEMENTING ENTERPRISE RESOURCE

PLANNING APPLICATIONS

BY

VIKAS KUKREJA

An essay submitted in partial fulfillment

of the requirements for the degree of

MASTER OF SCIENCE in INFORMATION SYSTEMS

Athabasca, Alberta

June, 2008

© Vikas Kukreja, 2008

I

DEDICATION

I would like to dedicate this thesis to the divine who got me to a point where I have a

happy life with my mother Amarjit, wife Rinki and son Satyam. I was encouraged and

motivated through every hard step in my life and during this masters program. I would

like to thank my family because without them I wouldn`t have come this far.

I

ABSTRACT

Enterprise resource planning application is in high demand not only by large enterprises

but also by small and medium organizations because of the fact that ERP application

connects all the departments and stores into one database, which leads to only one truth in

the organization and avoids confusion and latency. ERP application helps faster and better

production and on time delivery and payment in the organizations. To gain such results it

is important that the application is installed properly, not doing so the organization loses

lots of time, money and may not be able to address the business requirements.

ERP application began to evolve in 1970 and had gone through many stages to provide a

solution to businesses in the market; consultants provide total cost of ownership,

formalizing techniques to decide which ERP is better for the company. Understanding the

ERP standards and architecture they do follow the best practice template to deploy the

application.

Picking the best practices to implement ERP helps all size businesses regardless of size to

achieve what their organization is missing for implementation. This essay will focus later

on SAP application specifically to reflect its architecture, landscape, and standard

configuration. Also, further on this essay will focus on the best practice implementing

standardization- do’s and don’ts, understanding methodologies, assumptions,

implementing security-network, physical, data, role management and finally

implementation SAP in a data centre

II

ACKNOWLEDGEMENT

I would like to acknowledge Dr. Qing Tan, my essay supervisor, for his time and patience

for reviewing this essay and providing me with valuable suggestions and

recommendations to prepare it in its complete form.

III

TABLE OF CONTENTS

Chapter I - INTRODUCTION............................................................................................. 1 

Statement of Purpose ....................................................................................................... 3 

Scope of this research ...................................................................................................... 3 

Significance ..................................................................................................................... 3 

Assumptions..................................................................................................................... 4 

Limitations ....................................................................................................................... 4 

CHAPTER II – INTRODUCTION TO ERP APPLICATIONS ......................................... 6 

Enterprise Resource Planning .......................................................................................... 6 

ERP Evolution ................................................................................................................. 9 

Disadvantages of ERP ................................................................................................ 11 

ERP applications in today’s market ............................................................................... 13 

Small Business ERP Leaders ..................................................................................... 14 

Middle Market ERP Leaders ...................................................................................... 15 

Fortune 2000/ Enterprise ERP Leaders ...................................................................... 16 

Best Practice Formalising ERP ...................................................................................... 16 

Stage 1: ....................................................................................................................... 17 

Stage2: ........................................................................................................................ 18 

Stage 3: ....................................................................................................................... 18 

Stage 4: ....................................................................................................................... 18 

IV

Stage 5: ....................................................................................................................... 19 

What is the Total Cost of Ownership (TCO) ................................................................. 19 

Importance of TCO .................................................................................................... 19 

Measuring TCO .......................................................................................................... 20 

Best Practice Applying TCO ...................................................................................... 21 

Hidden costs of ERP?................................................................................................. 26 

Lowering TCO through People and Processes........................................................... 29 

Why do ERP projects fail so often? ............................................................................... 29 

Example of Sobeys Corporation ................................................................................ 29 

Failure of ERP Software Implementation .................................................................. 32 

Failure of Accommodating Evolution of Business Processes.................................... 33 

Failure of User Acceptance ........................................................................................ 33 

Best Practice to avoid failure ..................................................................................... 34 

Chapter III – ERP METHODS AND STANDARDS ....................................................... 38 

ERP Implementation methods ....................................................................................... 38 

ERP Standards ............................................................................................................... 39 

ERP Architecture Layers ............................................................................................ 39 

Presentation Layer ...................................................................................................... 39 

Application Layer .......................................................................................................... 40 

Application Layer Standards ...................................................................................... 40 

V

Database Layer .............................................................................................................. 41 

Database Layer Standards .......................................................................................... 41 

Interoperability Standards .............................................................................................. 42 

Interoperability Web Standards .................................................................................. 42 

The Interoperability Issues in Software Integration ................................................... 43 

Service Oriented Architecture ....................................................................................... 44 

Reference Model for Service Oriented Architecture ................................................. 45 

SOA in ERP ............................................................................................................... 46 

Best Practice implementing SOA............................................................................... 47 

Common mistakes while implementing SOA ............................................................ 48 

Development Approaches .......................................................................................... 50 

Interface granularity ................................................................................................... 51 

SOA’s solutions & Future with ERP ......................................................................... 54 

Chapter IV – SAP AND ITS BEST PRACTICES ............................................................ 56 

Introduction SAP ............................................................................................................... 56 

Best Practice Implementing SAP ................................................................................... 57 

General Sizing Best Practices and Approaches ......................................................... 57 

Developing the SAP Data Center .................................................................................. 62 

Introducing the SAP Data Center ............................................................................... 62 

Best Practice in Standardizing ERP environment ...................................................... 64 

VI

VII

Best Practices, SAP Security...................................................................................... 66 

Chapter V – CONCLUSIONS AND RECOMMENDATIONS ....................................... 74 

Conclusions .................................................................................................................... 74 

Recommendations .......................................................................................................... 76 

BIBLIOGRAPHY ............................................................................................................. 80 

Appendix A – HARDWARE AND SOFTWARE CHECKLIST ..................................... 83 

Appendix B – SAP ARCHITECTURE ............................................................................. 86 

Types of Standard Configurations ............................................................................. 86 

The SAP Kernel Architecture .................................................................................... 90 

The Database Server .................................................................................................. 91 

SAP System Landscape.............................................................................................. 91 

Appendix C – SAP LANDSCAPE AND RULES OF THUMB ....................................... 99 

Infrastructure/Network/Domain Best Practices ............................................................. 99 

General Server Considerations .................................................................................... 100 

Tape Backup/Restore/Basic DR Strategy Best Practices ......................................... 101 

CHAPTER I

INTRODUCTION

In today’s world, businesses can no longer survive if they are run and maintained in a

conventional/traditional way. Businesses have become so complex and detailed oriented

that if it is not managed with appropriate measures and tools they will collapse in their

initial years. Small businesses and/or home offices may survive without adopting such

complex ways but once they grow to medium, large or enterprise size they must adapt to

change. Based on the nature of the business, change involves new methodologies, process

management, project management, human resources management, customer relation

management, logistics, supply chain management, etc. The complexity of businesses are

like dealing in different currency and currency rates, different time zones,

synchronizations between stocks for their delivery, accounts, payments, credit, finance,

sales and marketing. Corporate uses information systems as a tool to maintain their

business and its vision.

Business managers and experts have noticed that when any business grows bigger, the

organization becomes slow; including increases in lag time and inefficiency. To

overcome these problems, organizations are adopting Enterprise Resources Planning

(ERP) as part of their information system’s infrastructure which assists in proper

workflow environment. These ERP applications help the enterprise to maintain their

global offices, different currency, employees status and growth path, customer accounts

(local and global) in a centralized database that can be accessed from all over the

organization- real time which helps to maintain one type of truth in the entire

1

organization. The organization doesn’t have to work on the tentative numbers but instead

accurate and up–to-date real time figures so organizations can accurately decide which

steps to take in the future. Everyone understands the importance of ERP application but

due to the cost factor, up until a few years ago only big enterprises could afford to

implement such infrastructure in their organizations but now there are many different

vendors with their various cost effective products that are offering a similar but less

intensified product targeting small and large businesses, hence now most of the

businesses can afford such an application.

Implementing ERP application is not an easy job, it requires lots of analysis, planning,

managing, designing, implementing and then maintenance. If needs are not assessed

properly, a company may land-up picking and implementing a wrong product which will

not deliver the kind of solution the organization needs it, and by the time the organization

realizes that it could have lost a lot of money, time and business. Due to such heavy

investment, organizations invest more to fix the problems of ERP applications. It has seen

that many companies lose their business because their focus moves from their business to

solve Information System problems in the organizations. Due to the high rate of failure of

these ERP applications ERP application vendors provide best practices implementing

their ERP products, simultaneously organizations have adapted new ways of

implementing such applications in their organizations, instead of implementing all the

modules they adopt one module at a time and monitor its success.

2

STATEMENT OF PURPOSE

The main goal of this essay is to evaluate previous and existing implementation, ERP

application techniques that include, total cost of ownership, various ERP applications

vendors, emerging technologies which incorporate older technologies with new,

comparisons of vendors with their strengths and weaknesses. This essay has evaluated

hardware, software, environmental and security requirements for ERP in any

organization.

SCOPE OF THIS RESEARCH

The scope of this research is to highlight the best practices about implementing ERP in

any organization; this is because most of the ERP implementation fails due to the fact that

they either go over budget, over time and/or lose the focus of the business.

This research will focus on the topics of ERP implementation which is very common for

mistakes and help reader to identify them in their organization. This paper also identifies

the best action that must be taken before and during implementation of such applications.

SIGNIFICANCE

Significance of the best practices implementing ERP in any business is very high; it has

said ‘prevention is better than cure’ hence to save time and money corporations invest in

analysis, planning and understanding the need of their business using the case studies,

history of these products, application used by similar businesses and which steps failed

and which succeeded so they don’t repeat similar steps which help in moving faster

towards implementation with less hurdles. These types of best practice also provide the

3

templates created and used during the implementation of other implementations, which

improvise the process of planning, deployment and maintenance.

There is no need to reinvent the wheel if the documentations produced during the

successful implementation is saved and improvised, that’s the reason enterprises seek for

such documentation, and people, application and vendors whom have the most experience

with it.

ASSUMPTIONS

The reader of this essay is assumed to know the basics of ERP application or some

knowledge of application deployment from either project management view or technical

point of view.

LIMITATIONS

Since the topic of this essay is so broad, it is difficult to discuss all of them in details.

Hence this essay is focused on the common best practices which go across the platform.

Usually every vendor has their own best practices implementing their related ERP

application(s); later in this essay the reader will find my focus on one of the renowned

and well accepted ERP called SAP and its limited best practices implementing ERP

applications.

This essay is divided into multiple chapters- Chapter II to Chapter V, with various topics

for discussion. In Chapter II, I discussed ERP applications, their needs and revolutions,

disadvantages, ERP for today’s market, different vendors providing ERP application to

address different sizes of organizations. I also mentioned best practice formalizing ERP

with their stages and total cost of ownership (TCO) for companies.

4

In Chapter III, I discussed methods and standards of enterprise resources planning

application, common ERP architecture layers, like presentation, and application and

database layers with their standards. Later in this chapter, I discussed about the ERP

interoperability with another application. I also talked to Service Oriented Architecture

(SOA), it is the most important in the ERP application for interoperability, hence I talked

about its benefits, reference model and reference architecture, and its solution for the

future with ERP applications.

In Chapter IV, I focused on one of the ERP called SAP so we can drill down and explain

the best practices. I have talked about SAP and architecture, kernel, collaboration with

databases, SAP landscape and their new release. Later in this chapter I talked about the

best practices in sizing the project and developing a data center and the standardization of

things required to implement SAP. Later I finish this chapter off with SAP security

explaining secure network architecture, its communications, securing mobile business

applications, and SAP’s role and responsibilities.

In Chapter V, I concluded the essay by providing my conclusion and recommendations

based on the provided chapters.

This essay, as a whole provides the generalist view rather than specialties in the area of

best practice implementing ERP applications. It provides an overall high level coverage

of the area including related research, standards and specifications.

5

CHAPTER II

INTRODUCTION TO ERP APPLICATIONS

ENTERPRISE RESOURCE PLANNING

The motive of Enterprise Resource Planning software, or ERP, is to integrate all the

departments of an organization- human resources, finance, accounting, sales and

marketing and so on and their functions together in one integrated database for the best

workflow between one and other departments avoiding repetition or missing data. These

software infrastructures hold the entire company together, on one hand, and support the

external business process the company engages in, on the other. The advantages of such

task are enormous for enterprises; ERP connects and integrates all departments and their

processes in such a way that latency and dependency among the departments (for example

if the order processing report is not been given to logistics department, the shipping will

be delayed, hence billing then payment) are reduced significantly and that means efficient

production, delivery and payment.

Figure 1: ERP Systems Concepts (Mohammad A. Rashid)

6

Due to the magnitude, cost and well known problems of the ERP applications,

organizations do not roll every module in the company over night, rather they go by

modules or may not need all the application at once, or you may want to deploy only one

or two applications at a time- HR, PP, CRM etc. Later in the stage you can setup more

modules and when more than one module is implemented, these applications fit together

like Lego and work automatically with each other to make perfect workflow

environment..

This eventually becomes a single software program that serves the needs of people in

finance as well as it does the people in human resources and in the warehouse. Before that

each of those departments had its own application(s), optimized for the particular ways

that the department does its work called legacy application which does not communicates

with other department’s applications or their database. But ERP combines them all

together into a single, integrated software program, so that the various departments can

more easily share information and communicate with each other.

With integrated ERP suite, there is a “single version of truth” that only needs to be

entered once to be propagated to all parts of the business that needs it. All business

processes, all employees who touch the application, and all the executives who make

decisions for the company see the same version of reality, in real time, all the time.

That integrated approach can have a tremendous payback if companies install the

software correctly.

7

Take a customer order, for example. Typically, when a customer places an order to sales

department, that order begins a mostly paper-based journey from sales department to

production, logistics and finally billing of the company, often being keyed and rekeyed

into different departments’ computer systems along the way.

Figure2: Customer Order Process Cycle (Source: Introduction to ERP; Sandra Sieber; IESE – Universided de Navarra)

Paper documents are often batched and sent to individual departments for processing.

This can cause delays and lost orders between departments, all data entry into different

computer systems invites various types of errors. Meanwhile, nobody in the company

truly knows what the status of the order is at any given point because there is no way for

the finance department, for example, to access the warehouse’s computer system to see

whether the item has been shipped. "You’ll have to call the warehouse" is the familiar

refrain heard by frustrated customers.

ERP if installed in such organizations acts like a big tree that removes the old standalone

computer systems from sales, production, logistics, billing, finance, HR, warehouse

departments with a single unified software program, which further branches out as

software modules for every department. Finance, manufacturing and the warehouse all

8

still get their own software, except now the software is linked together so that someone in

finance can look into the warehouse software to see if an order has been shipped. Most

ERP software is flexible enough that you can install some modules without buying the

whole package. Many companies, for example, will just install an ERP finance or HR

module and leave the rest of the functions for another day. Furthermore these modules

can be customized based on the different requirements not typically available or not

required in the company’s business process.

ERP EVOLUTION

This giant application didn’t become so big over night; it’s been in a series of evolution

processes since 1960 when a couple of ex IBM employees started with the MRP (Material

Requirement Planning) in Germany with the concept of reducing inventory and process

time. Later they evolve into MRP II (Manufacturing Resource Planning) to integrate

process with accounting and human resources for further reduction. Steep evolution took

place when the company came out of ERP in 1990s and further ERP II in the 2000s where

they focused on clients, real time transactions, electronic commerce , asset management,

optimizing the whole business network i.e. supply chain management (SCM), customer

relation management (CRM).

Enterprises started realizing the advantages of ERP applications and their integrated

nature which helps generate great returns (if properly installed) and closely manage all

departments of the corporation.

The major difference between ERP and ERP II are as follows:

9

As compared to early ERP, ERP II is e-commerce enable; it deals with all the sectors and

segments instead of just manufacturing and distribution. It deals with all types of

industries and their specific industry processes, it is externally connected instead of just

internally available, the architecture is web-based and componentized, and data can be

externally published and subscribed as compared to just internally.

Figure-3: Difference between ERP and ERP-II (Introduction to ERP; Sandra Sieber; IESE – Universided de Navarra)

However, having an ERP application means nothing unless it is seamlessly integrated

with other information systems. There are few challenges mentioned below that

organization faces while performing ERP integration.

Integration of ERP Modules: Organizations tend to install modules from the same ERP

vendors in the initial ERP implementation but it is not necessary that the company will

buy all modules from the same company. In later years- long after the installation and

integration of new ERP modules could be either the integration of modules from different

vendors, or the different versions of the modules from the same vendor.

10

Integration of E-Business Applications: E-business software systems generally fall into

four categories: Enterprise Resource Planning (ERP), Customer Relationship

Management (CRM), Supply Chain Management (SCM) and Knowledge Management

(KM). To get the most out of ERP systems, ERP should be tightly integrated with other e-

business software - Supply Chain systems, CRM, knowledge management, B2B exchange

and ecommerce storefront on the Internet.

Integration with Legacy Systems: Over the years, legacy systems have accumulated vast

amount of data vital to the survival, operations, and expansion of corporations and non-

profit organizations. Integration of ERP systems with legacy systems is more complex

than the integration of ERP modules and Integration of e-business Applications. It

routinely requires the installation of third-party interface software for the communication

between ERP software systems and legacy systems. Second generation ERP systems use

relational database management systems (RDBMS) to store enterprise data. Data

conversion from legacy systems to RDBMS is often a time-consuming and tedious

process. While most interface software provides API for ERP to access legacy systems,

some vendors offer integration module that automates or accelerates the transformation of

legacy application logic and data into reusable components with XML, SOAP, J2EE and

.NET interfaces.

Disadvantages of ERP

Like everything else ERP also has some disadvantages that must be considered before

choosing and implementing the application. Usually an organization chooses such

applications when they see more benefits than disadvantages. If understood properly the

11

disadvantages mentioned below can easily change higher management decisions to

accept, delay or not indulge in this project at all.

Costs: The costs involved in setting up an ERP system are far more than implementing

other office applications. Hence it is very important for companies to determine whether

their ways of doing business will fit within a standard ERP package. Software cost is not

the only expense for the company. They have to consider costs involved in training, data

conversion, integration and testing, post-ERP performance issues that may lead to

reduction in revenues, maintenance costs etc.

Time: Depends on the size of the enterprise/company, ERP implementation can take

considerable time. Since time is a valuable resource for the organization, it is important to

make accurate estimates of the time required.

There is also a chance that the implementation process may slow down the routine

operating works within organizations.

Acceptance: Employees are usually slightly reluctant to accept change and it can be a

difficult process. In many situations employees have invested a great deal of time and

effort in assembling a work-flow that actually works in practice, that’s the reason they

don’t really want to change the way they perform their daily tasks and love to stick with

the same old ways to carry out their work. Hence it is important for organizations to

involve the users in the project activities from the beginning. This will create a sense of

ownership in their minds and make them accept the ERP System more willingly. (Shields,

2001)

Training: Many times companies underestimate the amount of time employees will

require getting familiar with new systems. They tend to budget less time and costs for

12

training, that leads them to unfamiliarity with the product, create human errors, less

utilization of available functions, which in turn create frustration, confusion and a less

productive environment.

ERP APPLICATIONS IN TODAY’S MARKET

As mentioned above, we have ERP which comes with many modules that can be installed

at any point of time and after installing they join with previously installed modules as a

Lego joins with other Lego. Enterprise software system may include the following

modules:

Account receivable Accounts payable General ledger Sales & marketing Customer relation management (CRM)

Material resource planning

Bill of materials Inventory control Purchasing Logistics Work order management

Shop floor control

Budgeting Sales analysis Report writing Order entry Order entry e-commerce

Table1: Common ERP modules

However, in today’s market there are so many ERP applications available that choosing

which one to go for can be a great challenge. We have taken top leading ERP software of

the market -listed below to describe their technical compatibility, customers in the world

and strength level in various sectors; moreover we have described the ERP leader based

on the organization size.

13

Epicor at Glance Infor at Glance Microsoft at

Glance Oracle at Glance SAP at Glance

• Long history of reputable products

• Over 20,000 customers, 140 countries, 30 languages

• In major growth mode

• Reasonable VAR channel

• Several strong industry solutions

• Good after sales support

• MS/SQL/SOA technology

• Low to moderately priced

• 3rd largest global ERP maker

• Over 70,000 customers

• Several different ERP systems

• Vertically focused ERP solutions

• Lean manufacturing capabilities

• Complex and discrete manufacturing

• Process manufacturing

• Strong distribution and SCM

• Low to moderately priced

• Over 83,000 ERP customers

• Strong SMB/mid-market solution

• Very strong partner channel

• Only sold through VAR channel

• Multiple ERP products

• ERP road map questionable

• Solutions often vary by global region

• MS/.Net/SQL technology

• Low to moderately priced

• Over 37,000 application customers

• Claim #1 CRM market share leader

• #2 ERP market share leader

• 30 year proven credibility

• New SOA architecture

• Deep software functionality

• Highly flexible

• Technology is the Oracle stack

• Priced at the high end

• More than 35,000 customers, 120 countries

• Claim #1 CRM market share leader

• Built the client/server ERP market

• Definite #1 ERP market share leader

• Very impressive distribution/SCM

• Several industry solutions

• Netweaver, SQL and a chasm of technologies

• Priced at the high end

Small Business ERP Leaders

Microsoft ERP has become very popular for SMB (small and midsize business)

organizations. Since 2000, Microsoft has acquired Great Plains (who previously acquired

Real World and Solomon) and Navision (who previously acquired Axapta). While

Microsoft failed on the infamous Project Green integration which was to merge these

solutions into an ERP powerhouse, the company does an impressive job at continuing to

14

advance these solutions independently. The Axapta and Navision products offer strong

distribution and manufacturing capabilities and are far more popular in Europe than in

North America. Great Plains remains a channel favourite and offers the strongest

financials among the MS product suites. Solomon also has a loyal VAR channel, strong

Financials and a competitively strong project accounting and job cost suite. Great Plains

and Solomon have deeper channel resources and far more market share in the United

States than Navision and Axapta. Unfortunately, Solomon's maintenance and evolvement

is largely outsourced (back to some of the original founders and software authors) so it is

unsure how much longer this product will survive.

Middle Market ERP Leaders

Epicor offers strong ERP software functionality along with several impressive Industry

solutions for Professional Services Automation (PSA), financial services, hospitality

management, retail, distribution, manufacturing, pharma and not for profit. In a late 2007

analyst release report, Epicor was recognized by Aberdeen as achieving the lowest TCO

(Total Cost of Ownership) and total per user cost of software, services and maintenance

for mid-size companies. In fact, the Epicor ERP solution came in at less than 50% of

competing ERP products. The company's channel strategies are usually questionable

which may necessitate more review for international buyers. Infor is a company that

surprisingly few ERP software buyers are aware of. Largely based on an aggressive

acquisition and roll-up strategy, Infor is the third largest ERP manufacturer - behind only

SAP and Oracle. Infor is a vertically oriented software publisher with several different

ERP software systems and particularly strong distribution, supply chain management

15

(SCM), lean manufacturing, complex manufacturing and process manufacturing

solutions.

Fortune 2000/ Enterprise ERP Leaders

SAP is the largest and most recognized Fortune 1000, Global 5000 and enterprise market

share leader. The company has achieved its success due to its rich functionality and

completeness of workflow integration in accounting and distribution software suites along

with tightly integrated financials, manufacturing, human resource, payroll and customer

relationship management software systems.

Oracle is the world's second largest business applications maker - and is clearly out to

take the lead role from SAP. Bolstered by its acquisitions of PeopleSoft (with JD

Edwards) and Siebel Systems, Oracle has collected an impressive customer list and

portfolio of intellectual property. Now the real work to keep those customers and

integrate those products (project Fusion) is underway with results expected very soon.

Oracle is also expected to acquire other ERP application from the market and has plan to

integrate with rest of their own application in future to empower their application

structure and seamless workflow integration for customers.

BEST PRACTICE FORMALISING ERP

It is reasonable to believe that it is just a matter of time before a company will make a

decision to acquire a new software package that promises efficiency and cost savings. The

need will arise simply because in the current information technology environment certain

unnecessary costs are no longer sustainable. The result using an outmoded system- the

16

quality of information available to the company- do not present a return compatible with

the investment made.

Many factors are leading companies to seriously consider the possibility of replacing their

information systems with software packages. Most reach this conclusion after confirming

that they must reduce cost to maintain competitive. Another factor influencing companies

is that most of their competitors are already on this path.

Having made the decision, ensured the commitment of all and generally understanding

the challenges to be faced and the time frames involved, it is time for the company to go

out and find the ideal package.

As a first measure, it is necessary to decide whether the company wants to work alone,

counting on the talent and dedication of its personnel or it will contract with consultants

to help the evaluation term in the selection process. Whichever method company decided

to choose they have to go through the series of stages (listed below) which helps them

formalize the ERP for that company.

Stage 1: Study strategy and business processes and decide to acquire an ERP

This stage is divided in two very different stages. In the first stage, the project team

studies the business (mission, strategy, etc.), its departments and business processes. This

is something that is considered fundamental if the team is going to evaluate how well

each ERP adapts to the organization for example, what are the features a company would

looking for (CRM, BI, Material management etc), does the organization work process

require any advance features like SOA, lean manufacturing support, on demand delivery

etc. In the second stage, a committee has to decide if the company has to acquire an ERP.

17

This decision consists on a deep study of each alternative (internal or external custom

development, integrating best-of-a-breed vertical packages, maintaining existing systems,

etc), in order to adopt one (or a mixture of some) of them.

Stage2: Search for application vendors and first filter

Based on the knowledge about the company obtained in stage 1 and on some minimum

requirements about candidate ERPs (maximum cost affordable, platform, etc.), the project

team conducts a market research initiative looking for ERPs suitable for the organization.

The project team has to obtain enough minimum information on each ERP, applying the

minimum requirements; the number of candidates/vendors can be reduced to a small

number (between 1 and 3 at the most).

Stage 3: Evaluate the vendor’s solution and second filter

Here the project team needs much more information about the ERPs obtained in Stage2.

This information should be obtained in one or more interviews with the providers, getting

as many fact sheets, catalogs, articles, etc., as possible. Applying a long list of more

detailed selection criteria —which has to be refined and adapted to the organization—,

the project team should select 2 or 3 ERP candidate solutions. This phase and the

following are the ones in which the use of a formal notation may be more helpful.

Stage 4: Analysis and demonstration of applications and visits to the providers

At this point the ERP providers have to demonstrate their products to the project team, the

company top management, the mid-level management and a selected group of future final

users. The purpose here is to obtain a much deeper knowledge on each solution,

specifically on its functionality and adaptability to the organization. The project team

gathers all the opinions; reviews and refines the application of the list of criteria to each

18

candidate ERP; and prepares a selection proposal, which has to be approved first by IT

management and, finally, by top management.

Stage 5: Final decision, negotiation and planning

The project team negotiates the contract with the selected ERP provider, including the

estimation of the cost and the overall implementation plan, two very important aspects

that should be estimated by the ERP provider, and a contingency plan.

WHAT IS THE TOTAL COST OF OWNERSHIP (TCO)

The Total Cost of Ownership (TCO) method is a technique which can be used to make

sure that all associated costs over a given time period are considered when you are

acquiring an asset. TCO methodology was developed much before Research Company

Gartner made it popular in 1987s to determine the cost of owning and deploying personal

computers and since then their technique has been the leading advocate for its use in IT.

TCO is sometimes referred to as total cost of operation. When incorporated in any

financial benefit analysis (e.g., ROI, IRR, EVA, ROIT, and RJE) TCO provides a cost

basis for determining the economic value of that investment.

The TCO concept is widely used in the automobile industry. The TCO denotes the cost of

owning a vehicle from the purchase, through its maintenance, and finally its sale as a used

car but this paper will focus TCO related to ERP applications only.

Importance of TCO

One of the surveys done by Aberdeen group on ERP in manufacturing industries, they

found functionality and Total Cost of Ownership were clearly the top two selection

criteria in ERP software decisions (Aberdeen Group 2006). While vendors have always

19

emphasized lower TCO in selling to small and medium size businesses, Aberdeen found

larger companies (those with revenues over $1 billion) were even more sensitive to this

criterion.

TCO begins with an estimate of all direct and indirect costs that might be associated with

the life-cycle stages of an ERP project, including its implementation, operation, and

eventual replacement. This always involves making some assumptions about the future,

and then simulating various scenarios to arrive at alternative cost estimates. The goal of

TCO is to support wise decisions about all costs in the beginning of an ERP project, and

then to anticipate and manage those costs during its life cycle.

Perhaps the prime motive for controlling TCO in ERP projects is to minimize the number

and degree of changes that are permitted to the baseline software. Customization and

upgrades are costly, and the decision to hold the line should be made at the beginning of

implementation and revisited only under the most extreme circumstances. Similarly, the

institution should be prepared at the outset to modify its business practices to conform to

the demands of the new applications; delay in doing so can only increase the TCO over

time.

Measuring TCO

If there is one cardinal precept underlying the relationship between ERP projects and

TCO, it is this: you cannot manage what you do not measure. Gartner’s software

modeling tool known as TCO Manager is the industry standard framework and

methodology for cost management. It uses standards from generally accepted accounting

principles; identifies the ERP costs that should be measured, compared, and monitored;

compares expenditures, staffing levels, and service levels to other organizations similar in

20

technology, size, and mission; measures performance and user satisfaction in addition to

costs; and highlights strengths and weaknesses in an institution’s TCO. It also simulates

TCO targets reflecting asset changes and adoption of best practices for an unlimited set of

“what if” scenarios. Most of the simulations run for three to five years and are based on

benchmarking data by industry that are continually updated.

Gartner suggests that measuring, managing, and controlling costs are three separate

disciplines. Each has a different objective, using TCO as a fundamental element.

Measurement is a stake in the ground to determine where an enterprise is today.

Management is communication and the attainment of a commitment to action. Control is

the execution of these actions and the monitoring of key cost elements to maintain

alignment with the goals of the enterprise. But it all starts with an institutional

commitment to and a culture of empirical evidence.

Best Practice Applying TCO

Life-Cycle Costs: There are five major ERP life-cycle components of TCO analysis:

acquisition, implementation, operations, maintenance, and replacement (Figure 5). The

most important cost drivers within each of those categories are: the nature of the

organization (for example, a large, public, multi-campus system versus a small, private

institution); the quantity and types of technologies (for example, mainframe versus client-

server system); and management practices (centralized versus decentralized IT operation).

The life cycle of the technologies themselves is another critical component. For example,

desktop hardware may last two to five years, applications software 10 to 15 years, and

wiring 20 to 25 years, compared to 30-plus years for the physical plant and an annual

cycle for personnel and support costs.

21

Figure 5: Life cycle cost of any ERP system (Richard West, stephen diagle, 2004)

Too often, acquisition costs drive decisions concerning ERP deployment; this forces

attention to up-front, direct, and budgeted costs. Focusing on the total cost picture, on the

other hand, leads us to consider the indirect, unbudgeted, and contingency costs of

implementation and operations that can haunt an ERP project downstream. As Figure 1

suggests, most of the life-cycle costs of an ERP system are centered in operations and

maintenance. Controlling software modifications and centralizing operations can have

significant effects on overall costs.

TCO is a means for understanding and controlling the risks associated with implementing

an ERP system. As Figure 2 suggests, change has to be assimilated into the organization

in steps. Proper change management maximizes the political, fiscal, and organizational

benefits over the life cycle of the ERP system while minimizing risks. In the early stages

of an ERP project, political and process factors are very important. Achieving early wins

22

and optimizing user buy-in can pave the way for controlling both political and fiscal costs

down the road and increase the chances of delivering product on time and on budget.

Figure 6: Applying TCO to an ERP Implementation (Richard West, Stephen diagle, 2004)

Direct and Indirect Costs: The identification and measurement of direct and indirect costs

is a critical requirement of TCO analysis. Direct or budgeted costs include all

expenditures related to clients, servers, peripherals, and networks, including capital, fees,

and labour in each area. Indirect or non-budgeted costs include downtime and services to

end users. These costs often are hidden and difficult to identify or measure. While direct

costs usually relate to tangible assets, indirect costs are found in time and productivity

losses due to downtime in technology or among staff. They tend to be process and people

oriented and contribute heavily to overall TCO. Few things are as difficult to fund and to

conduct as end-user training and support, yet that is where most indirect costs reside and

where most direct costs get shifted. Understanding indirect costs is one of the big lessons

of TCO analysis.

23

Once the direct and indirect costs are known, the basic strategy is to conduct what-if

simulations of various implementation scenarios to see which yields the best TCO. All of

these calculations obviously rely on making good assumptions as a basis for evaluating

the TCO comparisons.

Managing ERP Cost

Assuming that the major life-cycle costs can be identified and measured, the issue is then

one of instituting cost-containment tactics and management strategies to lower overall

TCO in an ERP project. Gartner has identified two broad categories of cost management

enablers: technology and process. The technology factors include platform

standardization, automated asset management, hardware inventory, client remote control,

and automated software distribution.

The process-related factors include end-user training, IT professional staff training, a

stable IT organization, capacity planning and management, benchmarking of current

operations, centralized procurement, and vendor standardization. The relative efficacy of

any cost-reduction strategy usually depends heavily on the technology itself. However,

the cumulative effect of implementing a combination of these technology and process

factors can be expected to lower TCO in both direct and indirect costs.

The long-term goals of an ERP project deserve the most sustained attention; short-term,

tactical cost reductions should not impede achievement of long-term goals and priorities.

Budgetary downturns can be a direct threat to expensive ERP projects, which is where

strategic cost management comes in to play.

Standard cost-containment strategies usually include the following:

24

• Control institution expenditures in the form of caps, across-the-board cuts,

deferred purchases, and reductions in discretionary spending.

• Manage reductions in targeted areas based on program reviews.

• Achieve productivity improvements through process redesign.

• Outsource operational and capital costs through strategic sourcing.

• Renegotiate contracts to receive better rates or extended payments.

• Streamline strategic goals and expectations for the institution through a

comprehensive mission review.

These practices make sense, but are essentially defensive in nature. A more proactive

approach might include the following:

• Manage risk—TCO is as much about risk management as cost containment. It

is a good idea to conduct a formal readiness assessment on a campus prior to

beginning an ERP implementation.

• Set a management strategy and philosophy and stick to it.

• Reengineer work processes as a means for controlling costs, especially if it

enhances service levels.

• Develop a detailed understanding of the relationships between ERP life cycles

and TCO (again, the lesson of Figure 5).

The life-cycle of technologies themselves is a critical component; life cycle for computer

system will be 3 to 5 years, software will be 5 to 10 years and wiring will be 20 to 25

years, moreover the annual maintenance support also effect the calculation of life-cycle.

25

Hidden costs of ERP?

Although different companies will find different land mines in the budgeting process,

those who have implemented ERP packages agree that certain costs are more commonly

overlooked or underestimated than others. Armed with insights from across the business,

ERP pros vote the following areas as most likely to result in budget overrun.

Training: Training is the near-unanimous choice of experienced ERP implementers as the

most underestimated budget item. Training expenses are high because workers almost

invariably have to learn a new set of processes, not just a new software interface. Worse,

outside training companies may not be able to help you. They are focused on telling

people how to use software, not on educating people about the particular ways you do

business. Prepare to develop a curriculum in-house that identifies and explains the

different business processes that will be affected by the ERP system.

Remember that with ERP, finance people will be using the same software as warehouse

people and they will both be entering information that affects the other. To do this

accurately, they have to have a much broader understanding of how others in the

company do their jobs than they did before ERP came along.

Integration and testing: Testing the links between ERP packages and other corporate

software links that have to be built on a case-by-case basis is another often-

underestimated cost. A typical manufacturing company may have add-on applications

from the major—e-commerce and supply chain—to the minor—sales tax computation

and bar coding. All require integration links to ERP. If you can buy add-ons from the

ERP vendor that is pre-integrated, you’re better off. If you need to build the links

yourself, expect things to get ugly. Moreover, veterans recommend that instead of

26

plugging and moving dummy data with in the application, run a real purchase order

through the system and preferably with the participation of the employees who will

eventually do those jobs.

Customization: Add-ons are only the beginning of the integration costs of ERP. Much

more costly, and something to be avoided if at all possible, is actual customization of the

core ERP software itself. This happens when the ERP software can’t handle one of your

business processes and you decide to alter the software to make it do what you want. The

customizations can affect every module of the ERP system because they are all so tightly

linked together. Upgrading the ERP package—no walk in the park under the best of

circumstances—becomes a nightmare because you’ll have to do the customization all

over again in the new version and vendor will not be there to support you either. You will

have to hire extra staffers to do the customization work, and keep them on for good to

maintain it.

Data conversion: It costs money to move corporate information, such as customer and

supplier records, product design data and the like, from old systems to new ERP homes.

Companies often deny their data is dirty until they actually have to move it to the new

client/server setups that popular ERP packages require. Consequently, those companies

are more likely to underestimate the cost of the move, clean data modification etc.

Data analysis: Companies who relies on extensive data analysis must calculate the cost of

data warehouse in the ERP budget. Users are in a pickle here: Refreshing all the ERP data

every day in a big corporate data warehouse is difficult, and ERP systems do a poor job of

indicating which information has changed from day to day, making selective warehouse

27

updates tough. One expensive solution is custom programming. The upshot is that the

wise will check all their data analysis needs before signing off on the budget.

Replace your best people: It is a fact that the success of ERP depends on staffing the best

people from the business and IS divisions. The software is too complex and the business

changes too dramatic to trust the project to just anyone. The bad news is a company must

be prepared to replace many of those people when the project is over. Though the ERP

market is not as hot as it once was, consultancies and other companies that have lost their

best people will be hounding yours with higher salaries and bonus offers than you can

afford.

Implementation teams can never stop—most companies intend to treat their ERP

implementation as they would any other software project. Once the software is installed,

they figure the team will be scuttled and everyone will go back to his or her day job. But

after ERP, you can’t go home again. The implementers are too valuable. Because they

have worked intimately with ERP, they know more about the sales process than the

salespeople and more about the manufacturing process than the manufacturing people.

Companies can’t afford to send their project people back into the business because there’s

so much to do after the ERP software is installed. Just writing reports to pull information

out of the new ERP system will keep the project team busy for a year at least.

Waiting for ROI: One of the most misleading legacies of traditional software project

management is that the company expects to gain value from the application as soon as it

is installed, while the project team expects a break and maybe a pat on the back. Neither

expectation applies to ERP. Most of the systems don’t reveal their value until after

companies have had them running for some time and can concentrate on making

28

improvements in the business processes that are affected by the system, however analyst

has noticed that after ERP implementation companies goes into depression. The most

common reason for depression is employee’s performance. For them everything looks

and works differently from the way it did before. When people can’t do their jobs in the

familiar way and haven’t yet mastered the new way, they panic, and the business goes

into spasms.

Lowering TCO through People and Processes

Although the procurement and deployment of technology plays an obvious role in total

cost of ownership analysis, you must remember that people and processes play equally

key roles. No one area is greater than the other two.

It is not uncommon, unfortunately, to be inclined to carefully estimate people and

technology costs, only to downplay the process costs of a particular solution. Why?

Because it's easy to pull together the one-time implementation costs associated with

technology, but usually a bit more difficult to quantify people expenses, and seemingly

impossible to quantify process costs/savings.

WHY DO ERP PROJECTS FAIL SO OFTEN?

Successful implementation of ERP systems could save tens of millions of dollars and

increase employee satisfactions, customer satisfactions and sustain competitive

advantages in every- changing marketplace. Corporate executives are often perplexed by

the stories that how reputable corporations (Hershey Foods, Sobeys etc.) have failed

miserably and lost ten of millions of dollars in their ERP endures.

Example of Sobeys Corporation

29

In a photograph, Bradley Jardine, former CIO of Sobeys Inc. is seen standing outside the

company's Stellarton, Nova Scotia offices — headquarters of the second largest grocery

chain in Canada.

The caption under this image says Jardine is proud to oversee the North American food

industry's largest SAP implementation on IBM's DB2 database. Projections for the SAP

R3 ERP application promises 100 per cent return on investment in three years, with other

benefits such as improved employee productivity.

One year later, when new CEO arrived at Sobeys and a week before December — the

beginning of the busiest shopping season of the year, the DB2 database crashes, affecting

stores in Atlantic Canada and 15 in Ontario. The supply chain is interrupted for five days.

Couple the untimely crash with what the company calls "growing pains" experienced with

the implementation of its enterprise software and suddenly the previously much-touted

SAP project is deemed unfit for Sobeys' consumption.

In a quarterly call to financial analysts on January 24, McEwan said the company was

ditching SAP. Apparently the software couldn't handle ordering and data processing

needs for the stores where SAP had been implemented for ERP. His reason was

"Insufficient core functionality in the SAP software component of our enterprise-wide

systems to effectively deal with the extremely high number of transactions in our retail

operating environment."

The cost of that decision translated into a sizeable hit on Sobeys' books — $49.2 million

associated with labour and other expenses attributed to the implementation and

subsequent disruption.

30

In the days following the Nov. 25 database crash, an IBM Canada Ltd., spokesperson

agreed there had been a problem with the DB2, but insisted it was addressed at the time of

the problem and that Sobeys remains a good customer

While SAP acknowledged there had been bugs in the Sobeys implementation, their

reaction to the news hinted that changes at the senior level, including McEwan's recent

arrival and news of a new CIO might have influenced the decision.

Sobeys' decision to stop using SAP the way it did has left many in the industry scratching

their heads. One analyst referred to the company's statements to the media — including

the headline on its own press release —"Sobeys Moves Ahead without SAP" (even

though they were keeping the software for HR and financials) as the equivalent to a

"public stoning of SAP.

SAP was given a second chance though, and Sobeys successfully completed a regional

SAP for Retail implementation in 2004. Sobeys was back at Sapphire this year as part of a

panel on directions and challenges for food retailers, and rather than delve into past

problems, Sobeys senior vice-president and CIO Clinton Keay said he'd rather "focus on

the positives" in the company's SAP history.

The grocer has used SAP since 1996 for financials, later adding payroll, human resources

and, of course, retail management.

Keay said Sobeys' move to SAP was initially driven by Y2K compliance concerns; they

had a lot of complex legacy systems that wouldn't talk to each other, and many of the

people that knew how to run the legacy systems had left the company.

"The key focus was around integration, and a single source of the truth," said Keay,

describing the situation pre-SAP.

31

The failures of ERP projects are preventable if we can identify the common causes of the

failures regardless the companies and industries that implement them.

An ERP system is the combination of ERP software, the business processes that the ERP

transforms, the users of the ERP system, and the computer systems that run the ERP

applications. The failures of ERP project is often the result of the failures in one or more

of those four components. The failures in computer systems (hardware and operating

systems) are much easier to identify and to fix, so we'll examine the failures in software

implementation, business process and user acceptance.

Failure of ERP Software Implementation

Module-based ERP software is the core of ERP systems. Most ERP projects involve

significant amount of customizations. Packaged ERP software modules have build-in

functionality that work in a standard and simplified enterprise environment. However,

every organization is unique in data requirements and business processes. It is the

customizations that transform packaged ERP software into ERP software that meets

organizations' individual business processes and operations. Long and expensive

customization efforts often result the pass of release deadline and budget overrun.

Customizations may make the software more fragile and harder to maintain when it

finally goes to production. Major changes may be required in the later stage of the

implementation as a result of incomplete requirements and power struggles within

organizations.

32

The integration of ERP systems with the IT infrastructures also challenges ERP project

teams. The use of appropriate implementation methodologies can often make or break a

ERP project.

Failure of Accommodating Evolution of Business Processes

According to Anthony, R. A, business processes fall into three levels - strategic planning,

management control and operational control. Organizations continuously realign their

business processes of all levels in response to the ever-changing market environment.

Many ERP systems aren't flexible enough to accommodate evolution of business

processes. Many ERP system need a major overhaul in every a couple of years.

Failure of User Acceptance

The users of ERP systems are employees of the organizations at all levels. ERP projects

usually modify the company's business processes which create extra workload for

employees who use them initially. They may not think that the workflow embedded in the

software is better than the ones they currently use. Ongoing end-user involvement and

training may ease the difficult in organization's adaptation of new systems and new

business processes.

At its simplest level, ERP is a set of best practices for performing different duties in any

company, including finance, manufacturing and the warehouse. To get the most from the

software, you have to get people inside your company to adopt the work methods outlined

in the software. If the people in the different departments that will use ERP don’t agree

that the work methods embedded in the software are better than the ones they currently

use, they will resist using the software or will want IT to change the software to match the

ways they currently do things. This is where ERP projects break down.

33

Customizations make the software more unstable and harder to maintain when it finally

does come to life. The horror stories you hear in the press about ERP can usually be

traced to the changes the company made in the core ERP software to fit its own work

methods. Because ERP covers so much of what a business does, a failure in the software

can bring a company to a halt, literally.

Best Practice to avoid failure There are few considerable point mentioned below that can help avoid ERP failure. First

we would like to emphasize on how the phenomenon of scope creep is perceived, and

how the definition of success, as distinct from the absence of failure, is almost entirely

missing from everyone’s list of risk factors

Scope creep, meaning the expansion of project goals after initiation, is certainly real

enough. The pressure for scope creep is always present in ERP implementations. It is only

resisted where project management is actively charged with resisting it and is supported

by top management in very assertive and public ways.. Scope creep is unfailingly

identified by implementers as the near-universal cause of schedule slips and budget

overruns. Just as frequently, implementer’s allegations of scope creep are vehemently

denied by the user community.

In reality, there are two kinds of scope. There is the formal, documented scope of the

project, and then there are all the undocumented and often competing bundles of

expectations the various players bring to the project. Together, these bundles of

expectations make up the scope that always seems to creep.

To implementers, scope means the implementation team working understanding of their

34

task, and nothing else. It is not necessarily the same as any written spec or contractual

obligation, but to them it is the only thing that counts. Before the fact, the consequences

of any change to the implementation team working understanding of their task are utterly

unforeseeable, ranging from inconsequential to catastrophic; but even inconsequential

changes has an impact on the project schedule because they must be evaluated and proven

to be inconsequential. All too often changes are somewhat more than inconsequential.

Impacts throughout the system have to be discovered, assessed and dealt with. Often

changes come in waves, one change requiring many more. Work previously thought

complete has to be redone and retested, and more work added to the schedule as the full

impact of each change sinks in.

To avoid this kind of scope creep, implementers and users must be on the same page, not

just metaphorically but literally: that is, there must be an actual page “a shared,

documented statement of project expectations that everyone works from. That there

usually isn’t such a thing is demonstrated by the ubiquity of implementer’s claims of

scope creep in the face of users equally sincere denials of any change to their projects

objectives.

Next, we turn to gaps between the usual definitions of failure and success. One of the risk

factors-causes of failure Aloini, Dulmin and Mininno identified, only one directly

addresses success that is ineffective strategic thinking and planning. Their definition of

this risk factor is important enough to quote in full: The organization must decide why an

ERP system should be implemented and what critical business goals the system will

35

address. Hence, identifying business goals, determining the strategic business issues and

strategic requirement identification are essential elements of the ERP planning process.

Alignment of IT strategy with the organization’s business strategy must be enabled by

senior executive support. If an organization tries to install a system without establishing a

clear vision, every effort can turn into a disaster. Although this is the only mention of this

particular risk, remember that failing to address can lead to symptoms of failure.

We would take that quite a bit further. It is one thing for senior executives to establish a

clear vision. It is quite another thing to ensure that everyone else can share it. Senior

executives do not implement ERP systems. Strategic business issues and strategic

requirement need to be spelled out in unambiguous terms that everyone on the project

shares long before the first technical implementation decision is made. This is the role of

requirements analysis.

The importance of requirements analysis is often addressed, and with good reason: almost

every kind of failure can ultimately be traced back to inadequate requirements definition.

That is a strong statement, but it proves to be easy to back up. Consider that only 15 to

25% percent of ERP implementations are deemed to fail outright (corresponding to

Aloini, Dulmin and Mininno’s macro-class of process failure). Yet a large proportion of

the rest are not really deemed to succeed. We must ask ourselves how that can happen.

How, that is, can an ERP implementation proceed to go-live and only then be perceived to

have failed? When we consider that no implementation will ever be allowed to go live if

requirements are clearly not met, we must conclude that in such cases the requirements

36

the implementation team was working to were different from the real (but possibly

unstated) requirements by which the system is eventually judged.

37

CHAPTER III

ERP METHODS AND STANDARDS

ERP IMPLEMENTATION METHODS

As discussed in chapter 1, these ERP programs are used by a variety of organizations-

Govt, private, semi-Govt, in the areas of manufacturing, medical, consulting, information

technology, e-commerce etc. ERP is also no longer just an enterprise package, due to

competition and requirements, vendors have introduced ERP applications for small and

medium size corporations. The basic point of introducing ERP system in the organization

was to eliminate the legacy programs that provide more confusion than anything else.

Take for instance the basic concept of accounting; many companies must divide their

financial problems into a series of accounts, with one person or one small group of people

dealing with those problems. These areas are divided into money spent on supplies,

accounting items, paying employees or payroll, and a variety of other areas. Most

companies uses series of programs, one for each of those areas. By using ERP

implementation, they can eliminate the multiple programs and condense them down into

one program.

ERP can be used for a host of areas beyond accounting things. Many supply companies

have found success by using ERP implementation. Supply companies typically work by

supplying products and items to other companies, either through wholesale also known as

“at cost”, or at a small mark-up to guarantee a profit. Though the process sounds simple,

it actually involves a variety of steps. To help keep these steps organized, many supply

companies have used ERP implementation.

38

ERP STANDARDS

ERP Architecture Layers

There are typically three layers of architecture for ERP software packages which can be

defined by vendor-neutral or vendor-specific standards. The Web Services Presentation

Layer and the process of creating interoperability between ERP software and other third

party applications typically use vendor neutral standards. The Application layer and

Database Layers are often developed or configured with vendor specific standards, if

standards are available. Often system integrators develop standards based upon the

breadth of their experience with the application and this information can be provided to

clients. System integrator standards should not be used if vendor neutral standards have

been developed by proven organizations developing industry-wide standards, particularly

in the interoperability, web services and service oriented architecture arenas.

Presentation Layer

Web Services Presentation Layer Standards The web services presentation layer is

the most visible layer of an ERP software product. It provides the end-user

interface and renders the physical layout of the application.

Extensible Markup Language (XML) Extensible Markup Language (XML) is a

simple, very flexible text format derived from Standard Generalized Markup

Language (SGML). XML is used as a common data format at all levels of web

services architectures. It uses Document Type Definitions (DTDs) to describe tags

which define the data to be exchanged. It is useful for hierarchical structuring of

data.

39

Web Services Business Process Execution Language (WSBPEL) WS-BPEL, also

known as Business Process Execution Language for Web Services (BPEL4WS),

provides a language for the formal specification of business processes and

business interaction protocols. By doing so, it extends the Web Services

interaction model and enables it to support business transactions. WS-BPEL

defines an interoperable integration model that should facilitate the expansion of

automated process integration in both the intra-corporate and the business-to-

business spaces.

APPLICATION LAYER

Application Layer Standards

The major ERP vendors employ proprietary fourth generation interpretive languages as

the core development tools within their ERP applications. Other industry-standards such

as XML and Java (J2EE) are also used to provide web services connectivity and

interoperability.

Vendors Oracle Oracle,

Peoplesoft SAP

Development

Language PL SQL PeopleCode ABAP

Table5: ERP Proprietary Development Tools

40

Java 2 Platform, Enterprise Edition (J2EE) Java 2 Platform, Enterprise Edition is a

programming platform for developing and running distributed multi-tier

architecture applications using Java, based largely on modular components

running on an application server. J2EE is also considered informally to be a

language or standard because providers must agree to certain conformance

requirements in order to declare their products as J2EE compliant; albeit with no

ISO or ECMA standard. The naming convention for this platform has changed to

Java Platform, Enterprise Edition.

DATABASE LAYER

Database Layer Standards

Java Database Connectivity (JDBC) JDBC gives access to a tabular data source

using the Java programming language. It provides connectivity to a wide range of

SQL databases and other data sources, such as spreadsheets or flat files.

Open Database Connectivity (ODBC) ODBC is Microsoft's strategic interface for

accessing data in a heterogeneous environment of relational and non- relational

database management systems. Based on the Call Level Interface specification of

the SQL Access Group, ODBC provides an open, vendor- neutral way of

accessing data stored in a variety of proprietary personal computer, minicomputer,

and mainframe databases.

Active Data Objects (ADO) This is a Microsoft database interface that is the

Microsoft standard for data access. ADO is a set of Component Object Model

41

(COM) objects that provides an interface to OLE DB. The three primary objects

are Connection, Command and Recordset.

Active Data Objects .Net (ADO.Net) This is a data-access component of

Microsoft’s .NET framework. It has an extensive set of classes to facilitate data

access from a large variety of sources.

Object Linking and Embedding/ Database (OLE/DB). This is a low-level

Application Program Interface (API) from Microsoft for accessing both relational

and non-relational data. OLE/DB allows connectivity to ODBC-based SQL

sources. OLE DB interfaces can provide much of the same functionality that is

provided by database management systems. OLE DB evolved from the Open

Database Connectivity (ODBC) application programming interface.

OLE DB for OLAP. This is an extension to OLE DB that enables users to access

multidimensional databases in addition to relational databases.

INTEROPERABILITY STANDARDS

Interoperability Web Standards

These interoperability web standards will serve as the basis for connecting ERP systems

to external systems with a focus on using commercial best practices and vendor-neutral

standards. The ultimate goal of using ERP systems as components of an overall service-

oriented architecture relies on the foundation of a standards-based approach to

interoperability. The three most prevalent protocols used for web services interoperability

are SOAP, UDDI and WSDL. Because these standards continue to evolve, ERP and

42

COTS products should be evaluated for compatibility and ease of integration with

existing software by a technical team as a part of the software selection process.

Simple Object Access Protocol (SOAP) SOAP provides HTTP/SML based remote

procedure call capability for XML Web Services. It is used for exchanging

structured and typed information between peers in a decentralized, distributed

environment. SOAP is a one-way communication and it is comparable to the

current use of Remote Procedure Call (RPC). SOAP can be used in combination

with other protocols. Its full development in Web services has to be integrated

with UDDI and WSDL.

Universal Description, Discovery and Integration (UDDI) UDDI is used for

publishing and discovery of web services. UDDI provides a searchable registry of

XML Web Services and their associated URLs and WSDL pages. The goal is to

enhance interoperability and speed adoption for web services.

Web Services Description Language (WSDL) WSDL is a XML based interface

description language to describe XML Web Services and how to use them. WSDL

describes the syntax and location of web services. WSDL definitions are

“semantic-free”; the operations of web services are defined in terms of sequences

of messages to be exchanged and with whom.

The Interoperability Issues in Software Integration

The business enterprises are now facing a major issue of the software interoperability

because of the use of software from multiples vendors, implemented in various

technologies. Business enterprises use the applications built around different technologies

43

and platforms, and integration across the applications within the enterprise or of

businesses partners is never an easy or simple task. The lack of interoperability of

software product is causing serious problems for the integration of software from multiple

vendors for the end-to-end enterprise business solution.

Every day, businesses face an ongoing challenge of making a wide variety of software

from many different vendors work together. It's crucial to success in streamlining

business processes, getting closer to customers and partners, or making mergers and

acquisitions successful. Whether you are connecting with partners' systems, accessing

data from a mainframe, connecting applications written in different programming

languages or trying to log on across multiple systems; bringing heterogeneous

technologies together while reducing costs is today a challenge that touches every part of

the organization.

However, it is crucial need for the enterprises to have the seamless integration across the

software applications for better end-to-end business solutions.

SERVICE ORIENTED ARCHITECTURE

Service Oriented Architecture is an architectural (Sun Microsystems, 2004) paradigm and

discipline that may be used to build infrastructures enabling those with needs (consumers)

and those with capabilities (providers) to interact via services across disparate domains of

technology and ownership. Services act as the core facilitator of electronic data

interchanges yet require additional mechanisms in order to function. Several new trends

in the computer industry rely upon SOA as the enabling foundation. These include the

automation of Business Process Management (BPM), composite applications

44

(applications that aggregate multiple services to function), and the multitude of new

architecture and design patterns generally referred to as Web 2.0

Reference Model for Service Oriented Architecture

A Reference Model is an abstract framework for understanding significant entities and

relationships between them. It may be used for the further development of more concrete

artefacts such as architectures and blueprints. Reference models themselves do not

contain a sufficient level of detail sufficient to enable the direct implementation of a

system. In the case of a reference model for SOA, the Organization for the Advancement

of Structured Information Systems (OASIS) has a standard Reference Model for SOA,

which is not directly tied to any standards, technologies, or other concrete implementation

details.

In order for SOA to meet these challenges, services must have accompanying service

descriptions to convey the meaning and real world effects of invoking the service. These

descriptions must additionally convey both semantics and syntax for both humans and

applications to use.

Each service has an interaction model, which are externally visible aspects of invoking a

service.

45

Execution

Context

Visibilit Service

Description Service

Real World

effect Interaction

Contract

& Policy

Figure7: The Core OAIS reference model for SOA

SOA in ERP

Joshua Greenbaum, principal of Enterprise Applications Consulting in Berkeley,

California, said one implication is clear, though: SOAs will give more power of choice to

ERP customers.

Organizations already have "a lot of functionality in their software; they need to unlock it,

recombine it and build new functionality in a service architecture," Greenbaum said. "In a

well-developed Web services world, you will be able to pick and choose the services you

like from any vendor, as long as your architecture lets you do that. From the customer

standpoint, this is freedom of choice."

Recognizing this, ERP giants like Oracle Corp., in Redwood Shores, California, and SAP

AG, in Walldorf, Germany, are racing to be the infrastructure platform of choice,

Greenbaum said. SAP's NetWeaver integration and application platform is the technical

underpinning to the company's Enterprise Services Architecture (ESA) strategy. And

Oracle's Fusion middleware is the technical foundation for its next generation of

applications, dubbed "Project Fusion."

46

"The theory is, you can do anything you want in a Web services world, as long as the

interfaces work well together, but there will be a lot of institutional inertia toward

working with products and companies you know," Greenbaum said. "Once you get the

infrastructure in place, if you're using NetWeaver [for example], you'd be inclined to take

a fresh look at SAP first before you pluck something out of a competitor's offering."

Best Practice implementing SOA

Despite the lack of clear guidelines defining SOA, enough companies have embraced it

that best practices and lessons learned are emerging. The big-bang, all-at-once approach

to SOA implementation has been largely ineffective, according to experts (Matthew

Josefowicz, John Burke).

It has seen that the most encouraging returns on SOA efforts are those that took an

incremental approach -- they started in areas that made good business sense and were able

to communicate those business values to other parts of the enterprise.

Although SOA is a "think big" concept that can be leveraged across different parts of the

enterprise, it's important to start small during implementation, confirms John Burke, vice

president of insurance solutions for SAP (Walldorf, Germany). "SOA, in and of itself, is

an enabling technology; it's an architecture that improves processes, both internal and

external," he says. "There are so many systems inside of carriers and so many

permutations that it can quickly get overly complex. So pick a business process that's

meaningful to your business -- a line of business, a market segment. Pick something that

is tangible and carve that out."

47

Common mistakes while implementing SOA

There are number of common mistakes companies would do while implementing SOA in

the environment of the organizations

Taking a shotgun approach When attempting to move to an SOA, companies often take a

shotgun approach and don’t take into consideration which services are actually being

used, often times web-enabling is more than necessary. Service enabling everything is

costly and may not be necessary.

Failing to involve business analysts Business analysts are critical to the success of an

SOA project. Instead of involving them from the start, companies tend to focus heavily on

implementation, such as generating web services, rather than focusing on what needs to

be enabled to meet business needs.

Spending more time on SOA products than SOA Planning Companies tend to focus more

attention on SOA products--such as tooling, integration engines and SOA software

offerings--than on discovery, planning and project preparation for SOA initiatives.

Tackling the largest projects first The most practical approach to an SOA is to start with

the smaller, lower risk projects that are less visible. While most companies tend to begin

by tackling the larger projects first, this is high risk and often leads to failure.

Forgetting that SOA is a business Problem SOA is a business problem disguised as a

technology problem. When the technical focus supersedes the focus of the business, the

entire SOA project can veer off course. It is important to understand the goals of SOA,

and that the business problem should be the primary, not secondary focus.

48

Treating identity as an afterthought Companies have a tendency to commence a project,

and then wait until the project is mid-stream before considering identity implications. An

infrastructure should be put in place to handle logins by proper credentials. Identity needs

to be given high priority during the SOA planning process, instead of being treated as an

afterthought.

Buying new products when existing investments suffice Companies seeking to realize the

benefits of SOA often believe they must buy new hardware, software and SOA-specific

products to do the job; however, that is usually not the case. Many SOA initiatives can

begin with a company’s existing hardware and software with minimal additional

investment.

Misunderstanding company key players Often times the person leading the SOA project

does not know who the necessary players are or who ‘owns’ the data within the company.

Beginning a project without a full understanding of which departments affect which

services, and vice versa, can doom an SOA project from the start by creating roadblocks

to project acceptance.

Expecting the SOA project to spread quickly

Many companies expect the quick spread of SOA projects from one business unit to

another and become frustrated when it does not happen. However, moving forward

incrementally and carefully ensures the most reuse across all organizations, which leads

to a more efficient SOA infrastructure.

Service-Oriented Architecture (SOA) emphasizes loose coupling between different

systems within an enterprise. Service interface structure is of primary importance in SOA

49

because poorly designed service interfaces can have a negative effect on all applications

that need to use them. Well-designed service interfaces can accelerate project schedules

and make your SOA solution more responsive to business needs.

Development Approaches

Programming models and development tools based on XML and Web services define

three approaches to building Web services:

Bottom up: Leading integrated development environments (IDEs) provide tools for

creating Web service implementations from existing code (for example, Java™ or

COBOL). With this approach, the developer usually selects an existing JavaBeans or an

EJB component and invokes a wizard that generates a WSDL file that can be used to

invoke the bean or EJB as a Web service.

Top down: Following this approach, the developer first defines the Web service interface

using WSDL and XML Schema (XSD) constructs, then generates skeletal implementation

code for the service. Next the developer completes the skeleton service implementation.

Most leading IDEs, such as Rational Application Developer V6 and WebSphere

Integration Developer V6, provide tooling support for this approach.

Meet in the middle: This approach involves a combination of the previous two. The

developer first defines the service interface using WSDL and XSD, and generates a

skeletal implementation for the service. If necessary, the developer may also use a

bottom-up technique to expose existing code using a convenient application programming

interface (API). Then the developer writes code that converts between the newly designed

interface and the old interface.

50

Many skilled Java developers like to use bottom-up techniques to accelerate Web services

development in SOA projects. They develop implementations for new services in Java

first, and then use the powerful code generation wizards to create WSDL interfaces for

these services. Although this approach can speed the implementation of individual

services, it frequently means problems for the SOA project as a whole.

Problems occur because bottom-up generation frequently results in type definitions that

cannot be reused and multiple types defined to represent semantically equivalent

information.

Use the top down and meet in the middle development approach, rather than bottom-up

techniques. Design your service interface using XSD and WSDL, then generate skeletal

Java code.

The bottom up development approach is appropriate when there is an existing body of

legacy code (for example JavaBeans, EJB, COBOL, and so on). With this approach, you

should carefully review interfaces of existing classes before generating the WSDL

interface. If the Java interface contains any of the following, it can be considered weakly

typed:

• java.lang.Object used as either parameter or return type for a method

• Collection classes (for example, java.util.Vector) used as either parameter or

return type for a method (JAX-RPC constraint)

Interface granularity

51

A service interface should generally contain more than one operation. Operations defined

as part of a single service interface should be semantically related. A large number of

services, each containing a single operation or small number of operations, indicates

inappropriate service granularity. Conversely, a very small number of services (or a single

service) containing a large number of operations likewise indicates inappropriate service

granularity.

A service interface (WSDL port type) should generally contain more than one operation.

Operations defined as part of a single service interface should be semantically related by

data on which they operate.

Each COBOL transaction can be exposed as a single Web service operation. We could

define service called MyS390Service, for example, with a single interface that defines

operations for all COBOL transactions running on that mainframe. This produces an

interface with dozens of operations that client applications can use to invoke any

transaction on that system, regardless of whether the transaction is related to customer

management or product pricing.

When designing a new service, do not mix synchronous and asynchronous invocation

semantics in a single interface (WSDL port type). If it is advantageous to support both

semantics, define separate interfaces for synchronous and asynchronous invocations.

A WSDL port type can contain one or more operations. Operations can be one-way or

request-response. A one-way operation can define a request message but no response

message. It is not possible to define faults messages for a one-way operation.

52

As soon as a client application invokes a one-way operation using, for example, a JAX-

RPC-compliant Java proxy, it returns control immediately to the calling client application

thread. There is no way for the client application to know whether or not the message was

successfully delivered or even dispatched.

Static/Stateful compared with Dynamic/stateless interfaces

Design your service interfaces for stateless interactions. The request message passed in to

the operation should contain all information necessary to complete that operation,

regardless of the sequence in which other interface operations are invoked.

Exchanges between services can be stateful or stateless in nature. A stateful, or

conversational, exchange between services occurs when the service provider retains

knowledge of data that has been exchanged between the service consumer and the service

provider during preceding operation invocations.

For example, a service interface could define operations called setCustomerNumber() and

getCustomerInfo(). In a stateful exchange the service requestor calls the setCustomerNumber()

operation first, passing in the customer number. The service provider retains the customer

number in memory. Next the service requestor calls the getCustomerInfo() operation. The

service provider then returns a customer information response that corresponds to the

customer number set in the previous invocation.

And lastly, define and use custom headers to carry system-relevant information that is

specific to your business or project. Avoid putting system-relevant information into the

body of your message.

53

SOA’s solutions & Future with ERP

Will service-oriented architectures (SOAs) lessen dependencies on expensive enterprise

resource planning (ERP) systems? According to Joshua Greenbaum, the principal of

Enterprise Applications Consulting in Berkeley, California, He said one implication is

clear, though: SOAs will give more power of choice to ERP customers.

Organizations already have "a lot of functionality in their software; they need to unlock it,

recombine it and build new functionality in a service architecture," Greenbaum said. "In a

well-developed Web services world, you will be able to pick and choose the services you

like from any vendor, as long as your architecture lets you do that. From the customer

standpoint, this is freedom of choice."

"The theory is, you can do anything you want in a Web services world, as long as the

interfaces work well together, but there will be a lot of institutional inertia toward

working with products and companies you know," Greenbaum said. "Once you get the

infrastructure in place, if you're using NetWeaver [for example], you'd be inclined to take

a fresh look at SAP first before you pluck something out of a competitor's offering."

NetWeaver brings together many of SAP's components and tools, such as the Web

application server, enterprise portal, business intelligence, composite application

framework and NetWeaver Developer Studio. SAP has already rolled out several new

applications based on NetWeaver and its ESA, including mySAP Customer Relationship

Management and SAP xApps packaged composite applications.

According to Ian Kimbell, vice president of mySAP ERP marketing, NetWeaver provides

the prerequisites for service architecture. "You need a repository for services; you need a

54

platform to build services on; you have to have an analytic capability and a portal," he

said.

Similarly, Oracle's Fusion middleware provides "a set of applications and technologies

that help customers pull together disparate environments," said Fred Studer, vice

president of ERP marketing at Oracle. Among the elements included are the BPEL

Process Manager, the JDeveloper 10g and an application server.

Both companies claim their infrastructures enable ERP customers to begin an incremental

move to an SOA today, and that their next generation of products based on these

infrastructures will offer easier and less costly upgrades and migrations -- and ultimately

more choice.

55

CHAPTER IV

INTRODUCTION SAP

SAP is an acronym for "System Application & Products" which creates a common

centralized database for all the applications running in an organization. The application

has been assembled in such a versatile way that it handles all functional departments

within an organization.

R/2, which ran on mainframe architecture, was the first SAP version. SAP's products are

generally focused on Enterprise Resource Planning (ERP). SAP's applications are built

around R/3 system which provides the functionality to manage product operations, cost

accounting, assets, materials and personnel. The R/3 system of SAP runs on majority of

platforms including windows 2000 and it uses the client/sever model.

Since 2002, SAP has used the term SAP NetWeaver to refer to an overarching

technological concept comprising of the different SAP technology platforms. This effort

is in a sense merging the technologies to one platform: a new platform that is the

integration of people, information, and processes in one solution.

According to SAP, SAP NetWeaver is a comprehensive integration and application

platform that works with existing IT infrastructures to enable and manage change. SAP

NetWeaver enables the ability to flexibly and rapidly design, build, implement, and

execute new business strategies and processes as illustrated in Figure 8 below. SAP

NetWeaver can also drive innovation throughout the organization by combining existing

systems while maintaining a sustainable cost structure.

56

Figure 8: SAP NetWeaver

SAP NetWeaver is the technical foundation of mySAP Business Suite solutions, SAP

Composite Applications, partner solutions, and customer custom-built applications. It also

enables Enterprise Services Architecture, SAP's blueprint for service-oriented business

solutions.

BEST PRACTICE IMPLEMENTING SAP

General Sizing Best Practices and Approaches

Even in the best of cases, where much is known about a future solution's peak transaction

workload or typical end user's work habits, ERP solution sizing still remains an iterative

process, as much art as science. Understanding SAP's architecture can pay big dividends,

therefore, when it comes to the sizing process. Of course, to gain more than a cursory

understanding of the internal architecture employed by mySAP components requires

considerable training, coupled with a number of years of experience. However, a basic

understanding of the core concepts behind the operation of an SAP system will help

57

smooth out some of the bumps during the sizing process. This knowledge should help you

in maintaining an apples-to-apples sizing comparison between different hardware and

other SAP technology partners.

If we think of the database as the first layer in the three-tiered client/server architecture,

the application component, called the Application Server, is the second layer. It is very

common to see anywhere from 2 or 3 to perhaps 10 or 12 application servers in a single

system. In this way, the system's processing power is easily increased as a system's

utilization or requirement to host a greater number of users increases and therefore more

horsepower is necessary. As mentioned before, the runtime element of mySAP

components is referred to as the kernel, which spawns a number of SAP work processes,

each serving different functions-work processes are created specifically to support online

users, background or batch processes, printing, database updates, and so on.

Another unique element of the application layer is the Central Instance (CI), which

actually runs with one of the Application Servers dedicated to servicing end-user

transactions. Although for the most robust configurations, SAP allows us to actually

relocate the CI to its own physical server. This is so that the very processor-intensive

application servers can be granted the resources of an entire server, instead of being

forced to share CPU and memory with the CI. In other words, a separate CI server helps

ensure the system can respond instantly to the next request without waiting for resources

(primarily CPU) to be freed from some non-CI related usage.

58

Understanding Different Sizing Methodologies

In addition to a full-fledged top-to-bottom solution stack approach to SAP sizing, a

number of other sizing methodologies and approaches are often undertaken by different

SAP technology partners. The key to any valid sizing approach is to understand the

workload being performed, so that a hardware configuration with the proper number and

speed of CPUs, RAM, and disk drives can be assembled. Some sizing approaches are

faster than others, though, at the expense of sizing precision. For example, many

hardware vendors provide ‘Budgetary Sizings’ based solely on the expected number of

active users to be supported by a particular mySAP solution. In this way, a ballpark dollar

figure can be gleaned early in an SAP project without requiring all the time and trouble of

answering a comprehensive sizing questionnaire.

SAP AG provides its own rendition of a budgetary sizing by means of its Quick Sizer, an

online tool most often leveraged for its ability to perform rapid user-based mySAP

sizings. Available at http://service.sap.com/quicksizing, the Quick Sizer can also model

mySAP solutions even more accurately through an analysis of transactions and resulting

outputs, in the form of customer-provided quantity and structure-related data. For

example, business requirements that can be described in terms of the number of expected

financial documents, receipts, postings, average line items in a typical order, and so on to

be processed or created annually will more accurately help an SAP sizing expert craft a

hardware solution than an online user-based sizing approach.

This brings us to Transaction-Based Sizing. As the name implies, this approach seeks to

characterize and understand the nature of end-to-end functional transactions being

executed as part of a particular mySAP component. In addition to the quantities and

59

structures already mentioned, peak processing hours and peak throughput loads are also

factored in, just as they should be in user-based sizing exercises. Great care needs to be

taken to avoid underestimating the number of transactions to be performed by a particular

system; though-it's easy to short change the sizing exercise.

Sizing Tools, Practices, and Assumptions

SAP's Quick Sizer, along with all hardware vendors' SAP sizing tools, must make

assumptions regarding what you seek in a solution. One of the most important

assumptions that you need to verify with your hardware vendor involves how your

specific SAP workload is distributed among the servers in your solution. Each vendor and

their SAP sizing tools make assumptions like these:

The load borne by a system architected for three tiers is often split 33/67 or 25/75,

between the database server and the Central Instance combined with all application

servers, respectively. Verify these numbers are consistent if you are working with

multiple hardware vendors.

• Batch and user/online loads may be distributed to dedicated servers, or shared.

Verify how the tool addresses this, if at all.

• When clustering, each node in a cluster can be configured to perform work while

running in "normal" non-failover mode. Verify what both the normal .and failover

workloads look like for each cluster node.

Attention needs to be given to the methodology employed to determine how large your

SAP database will be in two or three years, and what the growth chart will look like over

60

time. Different database sizing approaches have evolved over the years; verify that your

prospective vendors are using the same method, or in some other way guide them toward

agreeing on a number that makes sense to everyone.

Servers are sized such that the average CPU utilization over time is 65% or so. In other

words, the system might spike to 100%, or sit nearly idle occasionally, but generally will

hover around the 65% mark.

Of this 65% utilization, fully half is dedicated to user-based dialog processing, and the

other half to a combination of batch processing, printing, interface processing, and

reporting.

The remaining 33% worth of "capacity" remains available to provide capacity to initiate

new work with minimal delay which, in turn, results in predictably good response times.

This extra capacity also helps to address unforeseen or unplanned future workloads.

Be careful that each of these assumptions is clearly documented in the sizing documents

you receive from each hardware vendor. By sizing for the full 100% capacity of a server,

their solutions therefore appeared to require less RAM and CPU processing power. This

helped them undercut other hardware vendor's proposals when in fact their less-than-

customer-focused tactics only left their clients with premature performance problems that

eventually had to be addressed before Go-Live.

Best Practices Regarding System Landscape Design

It is recommended that you plainly direct each potential hardware vendor to size for

identical system landscapes. In other words, do not leave this up to their discretion and be

clear as to which SAP system landscape components you want to see included in your

61

sizing. With regard to the system landscape, you also must be clear about whether a

multi-tier is required, and what exactly that entails. And you need to cover landscape

deployment options, like using instance stacking to install multiple systems on one

physical server. Stacking is quite common in the Unix world of SAP (and to a much

lesser extent, Windows), where development, test, and training instances might all reside

on one very capable server rather than separate servers.

One should help push each vendor toward a consistent standard for sizing the various

systems within the system landscape. For example, specify where minimal server, disk

subsystem, and other hardware components should be employed. Your Test system

should be able to support a specific number of users, or a specific percentage of the load

to be eventually borne by production.

DEVELOPING THE SAP DATA CENTER

Introducing the SAP Data Center

The goal to developing Data Center is to create a stable and highly available facility for

hosting your SAP implementation. One should take this process from building out the

power, network infrastructure through installing servers, configuring disk subsystems,

and installing server operating systems. This application and its resident data will

ultimately prove critical to your company's well-being. Should this application and data

become unavailable, even for a short period of time can cause thousands of users may sit

idly by, waiting for the system to come "back." Trucks may stack up in the loading docks,

waiting for bills of lading and shipping orders. Customers may call in or "click in"

looking for status updates on their orders, only to be told to "try again sometime later, the

62

system is down." Manual processes may need to be invoked to keep new orders coming

in. And to make it worse, eventually these manual orders will need to be keyed into the

system when it again becomes available. Reports will be unavailable, impacting decision

making from the boardroom down to the assembly line, and everywhere in between.

At the lowest layer of the stack we find power requirements. An incorrectly architected

power infrastructure will bring down an otherwise highly available clustered SAP

solution in a heartbeat-all of the high-availability offerings at other layers in the solution

are "powerless" without a well-architected Uninterruptible Power Supply (UPS) solution

or power distribution system.

Similarly, cooling requirements must be addressed at one of the lowest layers of the stack.

The servers not only pull a tremendous amount of power, they also generate a

considerable quantity of BTUs (British Thermal Units, or units of heat). An inadequate

cooling and air handling system can wreak havoc with availability statistics.

Servers, disk subsystems, network infrastructure, and other SAP-related infrastructure

needs to all be neatly racked and cabled. Lack of attention to detail, poor planning, and

more can quickly become contributing downtime factors.

SAP's tiered architecture requires forethought in regard to network planning, neglecting

the impact that a three-tiered architecture can have on public and private network

segments can impact not only availability, but also overall performance. In addition, we

cannot forget about network firewall security and other network infrastructure

considerations that will impact availability when it comes to Internet-facing SAP Web

servers, e-commerce/procurement systems, and so on.

63

Your disk subsystem, whether direct-attached SCSI, fibre channel arbitrated loop,

switched fabric, or network attached, tends to be the single most important performance

factor in my experience, outside of really bad coding. But it is also one of the most easily

misunderstood solution components when it comes to high availability.

Operating system installation, configuration practices, and more can easily impact

availability.

As we know now that design and implementation of a company's specific SAP Solution

Stack through a well-planned data center deployment affects availability at all levels of

the stack. Single points of failure (SPOFs) abound everywhere. A lone power source,

single power distribution unit, non-redundant power supplies, single network segment to a

server, single server hosting a database, and more all represent opportunities for

downtime.

Looking from OSI model perspective, we will find that many of the key layers of the SAP

Solution Stack map nicely to a layer in the OSI model. Therefore, every aspect of

planning for a highly available SAP Data Center also tends to "snap into" one of those

seven OSI layers, from the physical layer-power, through the data, network, and transport

layers, up to the session, presentation, and application layers-where your end users are

provided with the SAPGUI interface.

Best Practice in Standardizing ERP environment

Before we dive into identifying and addressing single points of failure common to ERP

Data Center designs and implementation, it first makes sense to discuss the role of

standards and standardization in your data center. Standards impact everything.

64

Fortunately, taking a close look at standards early in the Data Center planning process

forces you to think ahead, and ultimately avoid many pitfalls potentially lurking in the

future. Consider the following:

1. Server naming conventions must be descriptive enough to promote manageability,

but short enough to be technically supported by the particular SAP component

version.

2. IP naming conventions should help identify what type of server network

connection is being made. For example, standards that help to identify public,

private, clustered, and internal/other network connections are quite prevalent in

the world of SAP infrastructure.

3. Disk naming (and drive letter, for Windows 2000/NT) conventions should be

published and leveraged for consistency.

4. Even something as simple as color-coding network cables and power cables can

improve system availability. Similar to IP naming conventions, a good color-

coding scheme helps avoid unplanned downtime of vital networks.

5. Standard "high-availability server configurations" are normal in most ERP shops.

This usually equates to servers configured with redundant power supplies, fans,

power distribution units, processors, RAID-protected disk drives, RAID or ECC-

protected RAM, network cards, and so on, in a server cluster configuration with

dual-host bus adapters in each server.

6. As with standard highly available server configurations, most ERP shops also

promote an equivalent "high-availability disk subsystem." This usually involves a

standard frame or disk chassis, standard drive size (in example, 36GB 15,000

65

RPM 1" drives), standard redundant disk drive controllers, and redundant disk

interconnects back to the server infrastructure.

7. A standard operating system built for high-availability deployments is typically

developed. Nowadays, standard methodologies for deploying customary server

images are often employed, leveraging OS-build approaches ranging from

traditional disk imaging to custom scripting, deployment of imaging servers,

hardware vendor-specific approaches, and so on.

8. Finally, standardized processes regarding managing all of the aforementioned

resources help to minimize downtime across the board.

Best Practices, SAP Security

In today’s world without security, businesses simply cannot prosper. Data security at the

transaction level is a prerequisite in the computer economy. Also, legal requirements in

most countries call for comprehensive security mechanisms. Integrity, authenticity,

confidentiality, and availability of valuable business data need to be guaranteed at all

times.

Protecting Server Communications

To protect valuable company data against eavesdropping, business scenarios require data

encryption – not just for communications between specific entities, such as business

systems or end user PCs, but also for every single transaction or access. Every business is

on the internet hence standard SSL protocol provides security enhancements for the

application-layer hypertext Transfer Protocol (HTTP) and uses public and symmetric key

technology to encrypt communications between application servers and components of

exchange infrastructures.

66

The SAP® Cryptographic Library, SAP’s default GSS-API product, secures

communications between the servers of mySAP.com components. The library is based on

standard public-key infrastructure technology. Companies using other security

technologies, such as Kerberos or proprietary public-key infrastructures, can easily

integrate the necessary SAP-certified partner products.

Securing Network Architectures

Solid network architecture is crucial for ensuring the security, reliability, and availability

of IT solutions. However, as companies create Web services and open up systems for

outside access in collaborative business scenarios, they face increasingly complex

network structures and new security challenges.

Ideally, network architecture provides sufficient security and does not require any special

components, such as firewalls or reverse proxy servers. However, because SAP does not

have its own operating system and supports databases and components developed by

other companies, additional tools and measures are required to make the entire system

secure and audit proof. This especially applies to system management issues, such as

availability, networks, communications, and monitoring. Access to internal systems and

resources from outside can be regulated using firewalls that block certain communication

channels. At the same time, though, external staff members can be granted access through

authentication measures, such as single-use password generators or smart cards.

Additional security measures, such as installing scanners in the firewall and monitoring

inbound and outbound communications, prevent viruses, Trojan horses, and worms from

getting in or sensitive information from getting out through a covert channel.

67

All of these measures offer inadequate protection for internal communication. A well-

thought-out network topology with layered network zones is significantly more effective

here. Highly sensitive systems and components (Web servers, mail servers, or content

management servers, for example) should be located in a separate area that is sealed off

from attacks from inside and outside. Sensitive application servers should only be

accessible via a demilitarized zone (DMZ) that is protected by a number of firewalls

serving different purposes.

The sensitivity of the data processed in SAP Web Application Server will have to be

considered when determining the setup of a system landscape. One way of establishing a

secure landscape is to bring multiple instances of SAP Web Application Server into play

in the demilitarized zone and the service back end.

This proxy instance enables continuous protection using SSL. But if additional security

measures like content screening are required, SSL can also be terminated here. In

addition, the connection between SAP Web Application Server in the back end and the

proxy instance in the demilitarized zone through the second firewall can be established as

unidirectional to minimize the risk of outside intrusion. In addition to the standard

architecture of mySAP Technology, a reverse proxy server is often installed to enhance

network security. Reverse proxies are especially useful if applications that are not

compliant with SAP's single sign-on mechanisms or that cannot perform authorization

checks – for example, very simple Java applications – are combined with SAP

applications in one portal. In this case, the reverse proxy can take over the authentication

in front of the portal and perform a role-based authorization check on the target URLs of

the simple services. Most reverse proxy products also offer functions for synchronization

68

with the central user store. In addition, reverse proxies provide such features as cookie

caching and content screening.

Figure9: Encrypted Communications (SAP AG, 2002)

All data (including passwords) is usually transmitted through the Internet in plain text. To

maintain confidentiality, all modern browsers support the encryption of HTTP data by

using the Secure Socket Layer protocol (SSL), also known as HTTPS. To use SSL

encryption, the web server must obtain a certificate issued by a Certification Authority

(CA). This is the precondition for the secure connection to be established.

Data is sent as clear text by default between the WGate and the AGate. Built in is a

connection type that encrypts the data with a triple DES algorithm using a static key.

However, this key is not configurable. Therefore, this encryption provides protection only

against accidental reading of the data but not against serious attacks. For better protection,

you can use SAP's Secure Network Communication (SNC) to protect the link between the

WGate and AGate.

69

Securing Mobile Business Applications

Different applications have different security requirements. Simply looking up a phone

number in a corporate directory does not require a complex security solution, but if users

need to access mission-critical data, authentication and confidentiality become crucial.

The type of mobile device used also influences the security solution. A mobile phone with

a browser based on the Wireless Application Protocol (WAP).

Different wireless networks also have varying security properties. No single security

solution exists for such a heterogeneous technology landscape yet.

Managing Roles and Responsibilities

mySAP Technology uses an LDAP-based directory supplied by certified partners as a

single point of administration for user management. With its new, simplified role concept,

SAP separates roles (a set of actions that are semantically close) and responsibilities (a set

of organizational data that allows users to access or modify specific data).

Users’ positions in the organizational structure of the company largely define their

responsibilities. Roles consist of the applications and information users need for their

daily tasks. Separating role and responsibility administration simplifies the process of

creating authorizations, especially because the tasks of assigning responsibilities (top

down) and assigning roles (bottom up) usually lie with two separate administrators. In

most cases, assigning roles is a departmental responsibility, whereas assigning

responsibilities is a centralized task. SAP Enterprise Portal, SAP’s portal solution, uses

roles to generate a personalized user interface, simplifying application and information

access. Applications and Web services use roles to determine which transactions a user is

70

allowed to access, and they use responsibility information to control which data a user is

authorized to display or modify.

Figure10: User Management with a Central User Store

Managing Authorizations

Information about user roles is increasingly administered with the help of a central

directory service, but authorizations are still assigned in the business applications

themselves, such as human resources, logistics, or financial applications. A detailed

authorization concept, which forms an integral part of all SAP solutions, enables

companies to build finely grained authorization structures. Authorization objects are

assigned to user roles and activated when a user logs on to an application. These

authorization objects regulate access to transactions, tables, and documents in the system.

The evolution of the traditional SAP R/3 authorization concept now extends to Web-

based applications, for example, in the context of SAP Web Application Server. SAP’s

Web applications enable the explicit activation and deactivation of Web services, as well

71

as a detailed assignment of permissions. These characteristics provide the basis for a fine-

grained access control concept for Web applications. As more and more applications are

being transformed into Web services, managing authorizations within the individual

applications becomes increasingly cumbersome and adds to the workload of

administrators. In a pure Web-service environment, authorizations will therefore be

maintained centrally by dedicated administration systems. The core protocol technology

used will be the Security Assertion Markup Language (SAML), an XML security

standard for exchanging authentication and authorization information.

Avoid Server Backdoors

Configure the operating system of all servers of a mySAP.com infrastructure to be as

closed and restrictive as possible. Disable any services that are not needed on all SAP

servers, such as sendmail, remote login, password administration, the Network File

System (NFS), and the Network Information System (NIS).

Besides building secure gateways between the open Internet and the corporate intranet

using the described approaches, the data transmitted over the web must be protected from

corruption and eavesdropping. The protection of network connections includes three

levels of security:

• Authentication-identifies the communication partner.

• Integrity-recognizes changes made to data while it was transmitted, and

• Confidentiality-encrypts data to prevent read without authorization.

Encryption is mandatory for connections across open networks like the Internet.

However, it may also be necessary to use encryption in internal networks for

72

authenticating users and protection. Below is the description of making secure

communication connections. Cryptographic methods can be used at different layers in the

network protocol stack:

-At the data-link layer, network packets can be encrypted directly by the network card.

However, this method requires special hardware and is rarely used.

-At the network layer, several standards for securing data are available. The most

common is IPsec, which will in future be part of IPv6.

-At the transport layer, Secure Sockets Layer (SSL) is the most common among several

standards.

-Application layer-most applications define their own security protocols.

73

CHAPTER V

CONCLUSIONS AND RECOMMENDATIONS

CONCLUSIONS

ERP is no longer the application for manufacturing companies, now ERP is required in

almost every company and their departments. In the future, every company will have

some sort of ERP application installed in their organization. They are also no longer the

application of large corporations; ERP application vendors have recognized the demand

and need for such applications for small and medium business, hence they have

introduced ERP application that suits them.

Due to the fact that ERP application is not a one desktop or one server application, it

connects every department in various location into one system, hence requires pre-

planning, in-depth analysis of the business processes, formalizing techniques to acquire

applications before we install it. That is because the application is complex, time

consuming and cost more than the conventional applications and if not managed properly

its failure rate is higher than other application deployment we used in the past. If installed

properly there are lots of benefits like: Reducing operating cost (ERP software attempts to

integrate business processes across departments onto a single enterprise-wide information

system. The major benefits of ERP are improved coordination across functional

departments and increased efficiencies of doing business), Facilitate Day-to-Day

Management (The implementations of ERP systems nurture the establishment of

backbone data warehouses. ERP systems offer better accessibility to data so that

management can have up-to-the-minute access to information for decision making and

74

managerial control. ERP software helps track actual costs of activities and perform

activity based costing), Support Strategic Planning (strategic planning is "a deliberate set

of steps that assess needs and resources; define a target audience and a set of goals and

objectives; plan and design coordinated strategies with evidence of success; logically

connect these strategies to needs, assets, and desired outcomes; and measure and evaluate

the process and outcomes).

To avoid common mistakes implementing ERP, one must go through best practices

documents. Project managers, managing budgets must involve the stakeholder for the

total cost of ownership and if required return of investment. Interoperability gives

seamless communication between legacy and ERP application; knowledge of ERP

architecture and standards give better idea for implementation and hiring the right

personal to do the right job. SOA allows enterprises to evolve their IT infrastructure in a

flexible way. Web services provide an ideal technology for implementing an SOA. Well-

designed service interfaces can facilitate an SOA implementation, while poorly designed

ones can greatly complicate it.

SAP is one of the major stake holders in ERP application business and implementing such

application is important to know its kernel, landscaping, and its minimum requirements,

and later following the best practices we can setup SAP in data center and seal it with a

tight network, application, and database security.

75

RECOMMENDATIONS

Selection of ERP must be by their functionality and local business requirements not by

just brand name, it has been noticed that 40% to 60% of ERP functions are not even used

by their employees, that means the company has given more money to rent/buy those

services which is not been used. Moving in steps and monitoring each module’s success is

the way to move ahead with ERP application, not by replacing the old system with a new

ERP application that can cause devastating effects. Changing application does not mean

that the employees will also change with it, it takes a long time to train them and get used

to all the functionality, and they may have to change the way they work because ERP tend

to change business processes as well. That may lead to slower performance, and delay in

shipping and billing. If the application is not handled properly, it may overwhelm project

managers, consultants and employees and that will lead to more time and money which

stake holders may not get and agree to it and fail the project.

The failures of ERP projects are preventable if we can identify the common causes of the

failures regardless the companies and industries that implement them.

Successful implementation of ERP systems could save tens of millions of dollars and

increase employee satisfactions, customer satisfactions and sustain competitive

advantages in every- changing marketplace.

An ERP system is the combination of ERP software, the business processes that the ERP

transforms, the users of the ERP system, and the computer systems that run the ERP

applications. The failures of ERP project is often the result of the failures in one or more

of those four components. The failures in computer systems (hardware and operating

76

systems) are much easier to identify and to fix, so we'll examine the failures in software

implementation, business process and user acceptance.

To get the most from the software, you have to get people inside your company to adopt

the work methods outlined in the software. If the people in the different departments that

will use ERP don’t agree that the work methods embedded in the software are better than

the ones they currently use, they will resist using the software or will want IT to change

the software to match the ways they currently do things. This is where ERP projects break

down.

To avoid these kinds of problems, implementers and users must be on the same page, not

ust metaphorically but literally: that is, there must be an actual page “a shared,

documented statement of project expectations that everyone works from. There usually

isn’t such a thing demonstrated by the ubiquity of the implementer’s claims of scope

creep in the face of user’s equally sincere denials of any change to their projects

objectives.

It is also recommended to setup interoperability between the old and new ERP

applications and slowly migrate it to a new system if the old one is not offering much to

do or does not change it at all that the new application can very well merge the old

application with the help of interoperability features.

The organization’s data is highly important and losing such critical information can

change the future prospect or may loose current or future business. It is important that

security should be implemented. Conventionally it is recommended disabling all the ports

and functions which you think is not needed or no longer required, that can be the

backdoor entry for corporation data leak in a reverse manner but now it should be

77

addressed in reverse manner. That is, instead of closing security holes not- needed (port,

application, protocols, activate digital certificates), one should be opening the path

required for access and the rest will stay closed.

From one of the ERP-SAP’s perspective, you need to ensure that no detail is overlooked

when planning for your SAP Data Center facility or facilities. Each layer in the SAP

Solution Stack presents single-point-of-failure challenges; each layer must therefore be

thoughtfully considered with an eye toward eliminating these SPOFs, or at least noting

and mitigating risk to the point where such risk becomes financially acceptable.

SAP's architecture can pay big dividends, especially when it comes to the sizing process.

To gain more than a cursory understanding of the internal architecture employed by

mySAP components requires considerable training, coupled with a number of years of

experience. However, a basic understanding of the core concepts behind the operation of

an SAP system will help smooth out some of the bumps during the sizing process.

In addition to a full-fledged top-to-bottom solution stack approach to SAP sizing, a

number of other sizing methodologies and approaches are often undertaken by different

SAP technology partners. The key to any valid sizing approach is to understand the

workload being performed, so that a hardware configuration with the proper number and

speed of CPUs, RAM, and disk drives can be assembled.

SAP AG provides its own rendition of a budgetary sizing by means of its Quick Sizer, an

online tool most often leveraged for its ability to perform rapid user-based mySAP sizings

Do not leave this decision on hardware vendor’s discretion and be clear as to which SAP

system landscape components you want to see included in your sizing. With regard to the

78

system landscape, you also must be clear about whether a multi-tier is required, and what

exactly that entails.

In regards to developing SAP’s data center, the goal is to create a stable and highly

available facility for hosting your SAP implementation. Firstly, power sources should not

be just power from the city, then UPS and then generator; instead there should be two city

power sources that must come from two different sources- grid and generator/s must have

enough oil to run the infrastructure for three weeks or more not just a few hours.

Similarly, extra precaution must be taken in security- physical (there should be two

separate doors before entering the data center, one guarded by security personal and the

other guarded by the combination of biometric and pin code-which changes every 10

minutes), network (most of the companies are applying DMZ in their infrastructure for

securing the core business and providing access to their employees/partners, however

they can greatly reduce the threat by adding Intrusion Detection System-IDS), data (by

adopting encryption methods) and application (SAP and databases provides roles and

profile, which should not be underestimated for applying security in the organization, if

implemented with proper guidelines the environment can be highly secure).

79

BIBLIOGRAPHY

(2007). A Pragmatic Approach to Implementing a Service Oriented Architecture with

SUN JAVA Composite Application Platform Suite. Sun Microsystems Inc.

Christopher Koch, CIO. (2003, March 07). An Introduction to ERP. Retrieved 04 01,

2008, from http://www.cio.com/article/print/40323

Cindy Jutras. (2006). The Total Cost of ERP Ownership. Aberdeen Group.

Conz, N. (May 2007). SOA Adopters Discuss Best Practice. Insurance & Technology.

Duane Nickul; Laurel Reitman; James Ward; Jack Wilber. (2007). Service Oriented

Architecture (SOA) and Specialized Messaging PAtterns. San Jose: Adobe.

Duane, Nickull; Laurel Reitman; James Ward; Jack Wilber. (2007). A Pragmatic

Approach to Implementing a Service Oriented Architecture with SUN JAVA Composite

Application Platform Suite. Sun Microsystems Inc.

EMC Corporation. (2006). Best Practices for Implementing SAP on Dell/EMC, Part

Number 300-003-347, REV A01. EMC Corporation.

erp_standards.htm. (2008, Feb 02). Retrieved May 07, 2008, from http://www.army.mil.

ERPsoftware360.com - Enterprise Resource Planning software market. (n.d.). Retrieved

April 02, 2008, from top 5 client/server ERP Software Application:

http://www.erpsoftware360.com/erp-software.htm

F.Robert Jacob, D. C. (2000). Why ERP- Aprimer on SAP implementation. McGraw-Hill

Higher Education.

80

Frye, C. (16 May 2005). SOA promises more freedom for ERP customers.

SearchWebServices.com.

Inc, T. (2001). Calculating your total cost of ownership (TCO). A TriActive White Paper ,

7.

Jiraporn Lertkarnchanaporn, A. G. (2002). Enterprise Resource Planning. Florida:

University of Central Florida.

Jutras, Cindy. (2006). The Total Cost of ERP Ownership. Insight and advice for

enterprise executives , 8.

Mabert, Soni and Venkatraman. (2000). Enterprise Resource Planning Survey of US

Manufacturing Firms. Production and Inventory Management Journal .

Michael Missbach, U. M. (2001). SAP Hardware Solutions. New Jerssy: Prentice Hall,

Inc.

Mikhail Genkin. (2007, March 20). Best practices for service interface design in SOA,

Part 1. Exploring the development, interfaces, and operation semantics of services .

Mohammad A. Rashid, L. H. The Evolution of ERP System: A historical perspective.

Idea Group Publishing.

Narang, S. (2007). Web Services Specifications and SOA Interoperability. Enterprise

Open Source Magazine.

Paul Callahan. (2008). top 10 mistakes when implementing SOA projects. ZDnet News:

news.zdnet.com.

81

Pollyanne S. Frantz, Arthur R. Southerland, and James t. Johnson. (2002, November 4).

ERP Software. Implementation Best Practices , p. 41.

Richard West, stephen diagle. (2004, 01 6). EDUCAUSE Center For Applied Research.

Total Cost of Ownership: A stratagis tool for ERP planning an dimplementation , p. 14.

Samad, M. (2007). Web services - A Solution of Interoperaability and Portability

Problems of Enterprise Software Integration. Alberta: Athabasca University.

SAP AG. (2002). Security: Secure Business In Open Environment version 1.2. Walldorf,

Germany : SAP AG.

Sieber, P. S. (May 2003). Introduction to ERP. IESE Business School.

successfulerpimplementation.html. (2008). Retrieved May 07, 2008, from http://www.erp-

implementation-advisor.com.

Victor, P. (2005). ERP implementation for production planning at EA Cakes Ltd. Victor

Portougal: Hershey, PA : Idea Group Pub., c2005.

xavier Burgues illa, Xavier Franch, Joan Antoni Pastor. (2000). Formalising ERP

Selection Criteria. Proceeding of the tenth International workshop on software

specification and design (IEEE) .

Sergio, Lozinsky. (1998). Enterprise-Wide Software Solutions. Integration Strategies and

Practices.

Frye, Colleen. SOA Promises More Freedom ERP Customers (16 May 2005). From:

http://www.SearchWevSercies.com.

82

APPENDIX A

Checklist for H/W and OS best practice (Inc, 2001)

Perform EVERY 2 HRS each SAP server to be monitored

(color in boxes to indicate completed):

Server Name: Date/Times: Control Panel/Services Applet (if available, verify the following are ‘started’ on each

SAP server, as appropriate):

DB Server Service (DB servers only): ������ SAPService<SID>: ������

IIS/ITS Services (ITS servers only): ������ SAP OS Collector: ������

SAP MMC Snap-In (as applicable):

Database ‘up’ – green icon: ������ SAP ‘up’ – green icon: ������

SAPGUI (Need User ID for each SAP instance – then use /nSM51 to SPECIFICALLY

select each APP, CI, or DB server to monitor):

/nSM50: Ensure all DIA, UPD, & BGD Work Processes have ‘running’ or ‘waiting’

Status �����

Verify that one or more DIA WPs show very little CPU time used: ������

(press ‘CPU’ button, lower times indicate available bandwidth - look for 25% of all DIA work processes

to have been used substantially less than the others)

/nSICK (looking for ‘no errors reported’): ������

/nOS01: ___# of Presentation Server (Clients): ������ ___# of Application Servers: ������

/nST06: CPU User Utilization: ������ CPU System Utilization: ������

CPU Idle:������

83

(note that User +System utilization should not typically exceed 65%) Load Average: # of processes waiting for CPU <= 3):������ Pages in/second <5):������

Physical Memory Available:������ Physical Memory Free (>20%+ available): ������

Check that the Disk Queue Length does not exceed 5 by performing the following: Click the ‘Detail Analysis MThen under the ‘Previous Hours’ section, click the ‘Disk’ button. Review the ‘Queue Length’ column: ������ Next, under the ‘Previous Hours’ section, click the ‘Pagefile’ button.

Ensure Pagefile Utilization < 10%:

/nST03: Click ‘This Application Server’ button, then the ’Last minute load’ button, then enter ‘120’ minutes

Avg Response Time(<10,000 ms Bkg, 2,000ms Dia/Upd)Bgd: �����Dialog: ������ Upd:�����

Avg Wait Time (<5% response time, waiting on WP) Bgd: ������ Dialog: ������ Upd:���

Avg Load Time (<5% response time) Bgd: ������Dialog: ������ Upd:���

Avg Roll Time (<10% response time) Bgd: ������Dialog: ������ Upd:���

Avg DB Request Time (<50% response time) Bgd: ������Dialog: ������ Upd:���

Avg CPU Time (<30% response time, 60% Bkg OK) Bgd: ������Dialog: ������ Upd:���

Check Alerts, Logs, and other Monitors:

/nAL16 (or via ST06): OS Alerts: ������ Worst queue length: ������ Errors/collisions: �����

Review additional monitors/logs: EntMgt & OS Event Viewer SysLog/Application Log: ������

Regular Scheduled Miscellaneous Tasks:

/nST07: Number of users - Logged in: ___________ Active: __________ In a Work Process: __________

/nSM12: Look for any ‘old’ locks (clear ‘user name’, “no lock entries found” desired, otherwise list here): __

/nSM37: Ensure that no jobs (batch housekeeping jobs) have been cancelled/abended: ������

(clear ‘user name’ and ‘job name’, then insert * in each of these, and in ‘Job status’ tab, select only

‘Cancelled’)

/nSP01: Ensure that no print jobs have been waiting to print for longer than an hour (* in ‘Created by’): ���

/nST04: Data Cache %Quality Hit Ratio (>.96): ������

84

Procedure Cache % Quality Hit Ratio (>.96): ������

Regular Scheduled Miscellaneous Tasks:

/nST07: Number of users - Logged in: ___________ Active: __________ In a Work Process: __________

/nSM12: Look for any ‘old’ locks (clear ‘user name’, “no lock entries found” desired, otherwise list here): __

/nSM37: Ensure that no jobs (batch housekeeping jobs) have been cancelled/abended: ������

(clear ‘user name’ and ‘job name’, then insert * in each of these, and in ‘Job status’ tab, select only

‘Cancelled’)

/nSP01: Ensure that no print jobs have been waiting to print for longer than an hour (* in ‘Created by’): ���

/nST04: Data Cache %Quality Hit Ratio (>.96): ������ Procedure Cache % Quality Hit Ratio (>.96):�

/nST02: In the SWAPS column, ensure nothing is displayed in ‘red’, or note: _____________________________________

/nDB02: Size (total) of database: ______ ____ ____ ____ ____ ____ Used: ______ ____ ____ _

NOTES:

85

APPENDIX B

SAP Architecture

SAP launched mySAP.com in around year 2002, it is a newer version of traditional SAP

which comes with suite of applications like CRM,SRM,SCM (APO), BI etc and it is build

on top of R/3 system as a core component. R/3 system and newer mySAP.com is different

products and have different licensing schemes; newer version is all web based

(NETWEAVER), which is powered by WebAS. There are many options when deploying

SAP solutions, which could require additional storage. For implementing optional

components, the Competence Centers can assist in architecting the full solution’s storage

requirements through the formal sizing process.

SAP NetWeaver-based solutions have a flexible two-tier, three-tier or multi-tier

architecture:

Central instance

Database instance

Dialog instances, if required

Internet Middleware

Front-end GUI

Types of Standard Configurations

Central system is that in which the central instance and the database instance are on the

same host. Standalone database system is that in which the central instance and the

86

database instance are on different hosts. In a two-tier configuration, this server can also

accommodate the central instance (the SAP instance that includes the message server and

enqueue server processes). If the central instance is installed on a separate application

server, the configuration is three-tiered, and the database server is called a standalone

database server. Dialog instances are SAP instances that include only dialog, batch, spool,

or update processes; these run on hosts called application servers.

Each of these instance hosts (servers) require internal storage to meet the needs for the

operating system and associated swap area. The majority of the storage requirements are

typically from whichever server or servers host the database functionality. Other servers

can require external storage if serving as part of a cluster or using boot-from-SAN

technology.

Figure9 below shows a traditional two-tier (SAP ECC) configuration in which the SAP

central instance resides on the database server (also called central system). This

configuration is often used for sandbox, development, and small productive

environments. A three-tier configuration should be considered to support a highly

available solution.

87

Figure: Two-tier SAP R/3 system configuration

Another figure10 below shows a three-tier distribution of the instances for a large SAP

System (one that spans several computers and has a standalone database server).

88

Figure: Three-tier SAP R/3 system configuration

The configuration of the system is planned in advance of the installation using SAP

knowledgeable resources. The configuration is designed using both SAP’s QuickSizer

sizing tools on the basis of sizing information that reflects the system workload. Details

such as the set of applications to be deployed, how intensively these are used, and the

number and type of users, IT practices around backup/restore, disaster recovery strategies,

and system availability requirements are necessary to architect a solution that meets each

customer’s unique needs.

The SAP R/3 system is structured in a three-tier client/server architecture from a software

perspective, with each tier having a distinct function (see Figure11 below). In this

architecture, the presentation tier provides the interface to the user, the application tier

processes the business logic, and the database tier stores the business data. The SAP

system architecture supports heterogeneous environments and provides a high degree of

89

system scalability and flexibility. With the introduction of the Internet middleware, SAP

systems are now considered to be structured in a multi-tier architecture.

Figure: Multiple Tier types in SAP

The presentation tier, typically installed on a PC, provides the SAP Graphical User

Interface (SAPGUI). The interface is also available through a web browser. In this case,

an additional middleware tier transforms the SAPGUI DlAG protocol into HTTP. The

access is via TCP/IP and consumes very little network bandwidth. Essential for WAN

links, SAP has the lowest network bandwidth demand of all ERP solutions.

The SAP Kernel Architecture

There are two important terms to differentiate for SAP systems: kernels and releases. The

SAP release is the collection of business programs, usually written in ABAP (SAP's own

business programming language), that are stored in the relational database. These ABAP

90

programs are the business and functional logic of the relevant SAP system. They are

independent of the underlying operating system and server platform.

The SAP kernel, on the other hand, is a collection of executables and tools that enable the

SAP system to process the business logic. The sum of SAP kernel processes started or

stopped as a whole is called an SAP instance. Each SAP system can deploy multiple

instances, typically one instance per server box. There are several situations, however,

where it makes sense to run multiple instances per single server box.

The Database Server

Although SAP software is generally independent of anyone particular relational database

management system (RDBMS), there are some important software architecture concepts

that apply to each database.

Just like SAP software, each RDBMS has a kernel, or a set of executables that enable the

database application to run. These kernel files are compiled specifically for each server

OS platform. The actual data stored in the database is logically stored as rows within

relational tables. Physically, however, the data is stored in data files on disks, configured

with a file system or as raw disks

SAP System Landscape

Every SAP implementation project goes through deployment phases of some sort. There

are several types of systems used to implement a project. These should at least be

dedicated software deployment layers, if not on physically separate servers:

91

• Training, Evaluation, and Sandbox Systems-used for user training, gaining experience

in mySAP.com and playground for feasibility studies for customer-specific

requirements; usually small systems with small databases.

• Development System (DEV)- for customization of the mySAP.com systems and

development of new components and functionality; usually small systems with small

databases. It can be on different OS and HW platform, however, similar OS ease the

management.

• Test and Quality Assurance System (Test/QA)-enables extended testing of upgrades/

transports prior to implementation in the production system. These tests can cover OS

upgrades, SAP upgrades and patches, new system drivers, interface setups, and so on.

These are smaller than the production system but in a ratio that allows forecasting the

performance impact. The data used is a copy of the production system to run tests

with real, large quantities of data.

• Production System (PROD)-system with live data for production use.

Figure: Typical R/3 landscape

92

SAP Server Pre-Installation Checklist

(HW and OS only)

Verify Basic Data Center Infrastructure Installation

___1. Ensure that all server/disk subsystem racks are physically installed.

___2. Ensure that all servers/disk shelves are physically installed.

___3. Verify that all PCI and other controller cards occupy a “standard” PCI or other

slot in each server (for example, all public NICs should reside in slot x, and all

HBAs for external SAN connections should reside in y and z).

___4. Ensure that all SAN disks are physically installed.

___5. Ensure that all SAN cabinets are cabled to SAN Switches, and all SAN Switches

are cabled to redundant HBAs in each Database or other SAN-attached server.

___6. Ensure SAN disks are to be carved into volumes consistent with your SAP

Competency Center’s recommendations.

___7. Ensure that all servers are cabled via 10BaseT CAT5 to redundant network

switches (as dictated by the solution sizing or HW requirements).

___8. Verify that the public and private (and cluster interconnect, if applicable) network

connections are clearly labeled and ready.

___9. Verify that all HOSTNAMES and IP addresses (including management appliance

or similar IP addresses) have been determined and documented in advance of

actually installing OS’s.

93

General Power and HA Power Requirements

___10. All racks should be configured with redundant PDU’s.

___11. All servers, disk subsystems, and network equipment should be installed with

redundant power supplies.

___12. Each power supply should be connected to different PDU’s.

___13. Each PDU should be connected to a separate UPS (preferred) or power source.

___14. Ensure that all power is laid out as required, L6-30P for servers and L6-20P for

SAN/Disk subsystems (verify specifics with your hardware partner).

Update HW configuration (as required)

___15. Perform all firmware (FW) upgrades prior to configuring any drives at a hardware

level – upgrade all array controller(s), drives, and system boards to

versions/release levels approved by the hardware vendor and your SAP

Competency Center.

___16. Assume 4+ drives are installed in each server – typically, 1 drive is mirrored to

another, for two mirror-sets total. Check with your SAP Competency Center or

solution sizing for specifics.

___17. Carve the local disks. Start the Array Configuration Utility or equivalent to verify

configuration of local server drives

___18. Create 2 arrays, 1st drive mirrored to 2nd, 3rd drive mirrored to 4th.

___19. Ensure that a hot spare is set up, if room is available for another drive.

94

___20. Unless specific testing has been performed that indicates another configuration is

better, go with all array controller default values. For example, ensure that

read/write cache is set to 50/50.

___21. Create 1 logical drive per array (do not create more than one logical drive per

array unless directed to do so per the sizing).

Update OS (assumes W2KAS/SPx currently installed)

___22. Verify that the base W2KAS OS load has been performed, and that the currently

supported service packs/patches have been applied)

___23. Choose a SAP system name consistent with your naming standards. The NAME

must NOT exceed 13 characters in most cases (SAP limitations), though this

varies. Since other applications are still limited to 8 characters, the best way to go

is to choose a name that does not exceed 8 characters but still manages to reflect

the role of the server.

___24. Create the admin/installation user (i.e. r3padm, verify the name with the SAP

Basis team) - MUST BE lowercase - and give this user domain admin (or admin)

rights – note that ALL SAP installations, updates, and administration activities

need to be performed with this user ID.

___25. Ensure that all LOCAL drives are formatted for NTFS (explorer, select root, file,

properties, general tab), 64kb recommended for log and data files, 4kb or 8kb

recommended for all others.

___26. For INTERNAL drives only (to be used for OS and pagefile), depending on the

physical drive size, you may wish to create 2, 3, or more drives on each physical

95

array. For example, with 18 GB drives, 3 drives of about 6GB is common. Be

consistent across all servers.

___27. Label all disk drive volumes, i.e. - C: OS, D: UTIL, E: PAGE1, F: PAGE2, G:

PAGE3, H: PAGE4, Z: CDROM, or equivalent (as per standards)

___28. Set the TEMP environment variable (control panel, system) – used by R3setup.bat

or other installation processes, which will be executed later by the SAP Basis

team.

___29. Create the C:\TEMP directory if it doesn't exist already.

___30. Perform Pagefile sizing - 4x physical RAM, 10 GB max OK unless directed

otherwise (may wish to round up just to be consistent).

___31. Configure pagefiles via Control Panel, System) – suggest 4095 MB on drives C:,

E:, F: - refer to the standard Pagefile sizing developed for customer’s EA

environment.

___32. Modify the default ‘Server’ service property – change it to ‘Maximize Throughput

for Network Applications’ (this changes how memory/cache is allocated, and is

set via network & connection places, properties, pick connection, properties, file

and print sharing, properties)

___33. Grant ‘everyone’ permissions to root/all subdirectories of all logical drives

___34. Ensure your hardware specific driver-overlays are up to date, and approved by the

hardware vendor’s SAP Competency Center. For example, it’s common to load

special network, array, and management drivers that replace the default W2K

drivers.

96

___35. Load the SNMP service (W2K) if not loaded already– note that service packs and

other updates/patches may need to be reapplied.

___36. Load any solution stack management agents not already loaded, as directed by the

SAP Basis team.

___37. Check the W2K Event Viewer for issues

___38. Check the Management Console for issues

___39. Select a 3-character SID (system ID), consistent with Customer’s EA naming

standards.

___40. Set up an alias for SAPTRANSHOST in the HOSTS file – edit

C:\WINNT\SYSTEM32\DRIVERS\ETC, and add an entry for SAPTRANSHOST

to point to the particular system’s central instance.

___41. Verify that Internet Explorer is at version 5.x.

___42. OPTIONAL – after the ENTIRE SAP INSTALLATION, go back to Control

Panel, System, Performance, and change 'foreground' to 'background' - this

ensures that a locally logged-on user does not rob the logged-in SAP R/3 clients of

their otherwise entitled memory/processor cycles. You may also wish to load any

array configuration or management utilities locally on the server, too, to facilitate

future change control/troubleshooting.

97

Prepare for the DB and R/3 installation

___43. Read through the pertinent INSTALLATION guide (InstGuide - print it, make it

easy on yourself!) and the standard SAP product guide (may be found on CD with

the installation kit)

___44. Request that the SAP Basis team obtain any pertinent SAP Notes - see the

InstGuide for a list of pertinent notes, and read these – they may impact the basic

setup of the server/infrastructure.

98

APPENDIX C

SAP System Landscape Best Practices and Rules of Thumb

INFRASTRUCTURE/NETWORK/DOMAIN BEST PRACTICES

• A separate domain for all W2K-based SAP resources is recommended by both

SAP and its technology partners (primarily for security purposes, as this

minimizes the number of people that have administrator access and can thus

disable or change the SAP Services or purposely/inadvertently delete

SAP/database disk partitions). This also serves to keep extraneous

network/domain-related traffic off of the Enterprise SAP domain.

• It is also recommended that separate subnets be deployed for the production SAP

system and all other SAP systems.

• Further, in 3-tier configurations, the traffic between the Database Server and

Application Server(s) should reside on a separate high-speed (i.e. 100 Mbit/sec or

GigE) subnet, hence the need for at least TWO NICs in each Application Server –

one NIC supports this back-end network, and the other NIC supports the public

network used by the SAPGUI/WebGUI clients.

• For standardization purposes, these NICs should be IDENTICAL.

99

GENERAL SERVER CONSIDERATIONS

• Only servers and Disk Subsystems (including disk controller/disk storage combinations)

specifically certified to support SAP may be proposed (though once a controller has been

certified in a particular vendor’s platform, it’s certified for all platforms).

• More recently, SAP has left the Disk Subsystem certification up to the hardware

vendor.

• All volumes (OS/Pagefile, DB & SAP executables, and Log Files), except

possibly the database volume(s), should ALWAYS be configured for Hardware

Level RAID 1. Database volumes may be configured for any number of RAID

levels, depending upon performance, availability, redundancy, and other

requirements.

• All database volumes should be configured with a “Hot Spare” so as to minimize

the potential for losing yet another drive, and therefore losing data.

• Pagefiles and Swap partitions are typically configured per SAP’s recommendation

of 4 times physical RAM (this actually varies, depending upon the specific Basis

release and component being deployed). However, greater than a 10 GB

Pagefile/Swap is virtually pointless, as the SAP formula does not apply well

beyond a certain memory footprint.

• Hardware vendors should never propose systems that exceed 65% expected CPU

utilization. In fact, many hardware partners size for 33% CPU load, keeping

another 33% to address peaks or batch loads, and the remaining 34% for

emergencies/high seasonal peaks.

100

Tape Backup/Restore/Basic DR Strategy Best Practices

• The Tape Solution specified for the Landscape should be standardized around a

single density (or backward-compatible to other densities in the Landscape), i.e.

only 35/70 GB DLT drives will be configured. Of course, this does not preclude

use of different hardware tape subsystems - perhaps a DLT Tape Array might be

deployed for Production, and a shared Tape Library might be utilized by all other

systems, for example.

• For the best level of protection, two tape drives should be used for Production - a

separate tape drive should be used to backup database LOGS, and another one

used for database volume backups. This maximizes the potential for successful

backups/restores, as it protects against tape drive problems that lead to corrupt

media.

• Regardless of physical devices, different tape cartridges must be used to backup

the logs and the database, again to ensure that the database can be restored – this

protects against tape media failure.

• Network-based BACKUP/RESTORE servers are typically only recommended if a

dedicated Gigabit network link is implemented. Thus, we would now need 3

discrete NICs in a 3-tier solution. The reason for the 3rd NIC is simple - potential

bottlenecks associated with network-based 100Mbit or slower networks,

especially shared networks. It’s preferred to go with SAN-based technology if

your budget allows this, as described next.

• The SAN Switched Fabric/Fibre-Channel based Tape Library keep backup/restore

traffic off of other networks. In the case of a SAN, a dedicated piece of gear is

101

102

required to connect the SAN to the tape library. As for FCAL systems, a dedicated

7 or 12-port Fibre Hub is necessary. Note that many legacy 7-port Fibre Hubs are

not “manageable,” though. On the other hand, not all 12-port FCAL hubs

supported Microsoft clusters. So do your homework in this regard – you may lean

one way or the other, for standardization, capability, or other purposes.