best practices implementing erp applications
Post on 21-Nov-2021
20 Views
Preview:
TRANSCRIPT
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.
top related