Enterprise System Lecture03

Enterprise System - CS556
Mr. Farhan Sabir Ujager email id: farhan@biit.edu.pk, WhatsApp# 0300-5733768
(Week 3) Lecture 5-6
Learning objectives:
 Examine in detail the enterprise systems modules and architecture.
 Understand the effects of a well-designed architecture on ERP implementation.
 Know the various types of ERP architectures and the related benefits and drawbacks of
several architectures.
 Introduction to SAP
Resources: Beside these lecture handouts, this lesson will draw from the following
Text Book: Enterprise Systems for Management by J. Thompson and Luvai

F. Motiwalla (2nd Edition)
Reference book: Concepts in Enterprise Resource Planning by Bret Wagner

and Ellen Monk (4th Edition)
ERP Architecture
The architecture of the ERP implementation influences the cost, maintenance, and the use of the
system. A flexible architecture is best because it allows for scalability as the needs of the
organization change and grow. A system’s architecture is a blueprint of the actual ERP system
and transforms the high-level ERP implementation strategy into an information flow with
interrelationships in the organization. The ERP architecture helps the implementation team build
the ERP system for an organization. The role of system architecture is similar to the architecture
of a home, which takes the vision of the homeowners with the system components similar to the
wiring, plumbing, and furnishings of a home.
The process of designing ERP system architecture is slightly different from other IT
architectures. Whereas other IT architectures are driven by organizational strategy and business
processes, if purchased, ERP architecture is often driven by the ERP vendor. This is often
referred to as package-driven architecture. The reason for this reversal is that most ERP vendors
claim to have the best practices of their industry’s business processes captured in their system
1
logic. This argument has proven very powerful in convincing organizations to spend millions of
dollars for the ERP package. In order to leverage this investment and maximize the return on
investment, an ERP implementation is driven by the requirements contained in the package.
FIGURE 1-3 Example of Architecture of ERP at Large University
The architecture must therefore be conceived after the selection of ERP software, whereas the
architecture is conceived well before buying or developing software in other IT implementations.
An ERP package can have a very different implementation outcome from one organization to
another. In the architecture of a large university, an ERP system can be very complex and must
be designed and tested thoroughly before implementing it in the organization (Figure 1-3). The
architecture sets the stage for modifications or customizations to support an organization’s
policies and procedures, data conversion, system maintenance, upgrades, backups, security,
2
access, and controls. Many organizations often make the mistake of ignoring the system
architecture stage and jumping directly into ERP implementation because they have planned a
―vanilla‖ or ―as-is‖ implementation. This can be disastrous because the organization will not be
prepared for long-term maintenance and upkeep of the system. The two types of architectures for
an ERP system are logical (see Figure 1-4) and physicalor tiered (see Figure 1-5). The logical
architecture, shown in Figure 1-4, focuses on supporting the requirements of the end users,
whereas the physical architecture focuses on the efficiency (cost, response time, etc.) of the
system. The logical architecture provides the database schemas of entities and relationships at the
lowest tier, followed by the core business processes and business logic handled by the system at
the second tier. The third tier provides details on the applications that support the various
business functions built in to the ERP system. The end users do not ever see the first and second
tiers because they interact primarily with the client–user interface application tier that provides
them access to the functional applications.
Figure 1-4 Logical Architecture of an ERP System
3
FIGURE 1-5 Tiered Architecture Example of ERP System
ERP Life Cycle
Understanding an ERP system life cycle and its effects on today’s organizations is fundamental
to fulfilling the long-term investment in an ERP system. As shown in Figure 1-6, ERP
implementation is not a onetime implementation. It requires a continuous cycle of product
release and support.
The key to a successful implementation, therefore, is to use a proven methodology, to take it one
step at a time, and to begin with an understanding of the ERP life cycle. When a system
implementation does not have a well-defined methodology, deadlines will likely be missed,
budgets will be overspent, and functionality will not meet the client’s needs and requirements.
4
FIGURE 1-6 ERP Life Cycle
ERP system implementations are very risky, and using a well-defined project plan with a proven
methodology will assist in managing those risks.
There must be a strong well-communicated need to make the change from the existing
information systems/applications to an ERP system before starting any ERP development or
implementation. There should also be clear and well-defined business objectives written and
communicated to the organization. The project methodology needs to be documented, reviewed,
and fully understood by everyone involved in the project once objectives are outlined.
ERP Implementation Strategies

Implementing an ERP system is problematic without first considering current business processes
and changes to those processes based on the functionality of the new system. If business
processes are not analyzed and compared with what the new system can do, it is very likely the
implementation will require significant system modifications after implementation. In
developing the business case for an ERP implementation one must make a decision on the
number of modifications to be made to address business requirements. An implementation with
considerable modifications to the ERP software package, sometimes referred to as ―chocolate‖
implementation, can increase the chances of success with the users because the package has been
customized based on user requirements; however, modifications increase the investment in the
system and introduce higher implementation risk.
In a purchased system like ERP, modifying the system means that every modification will have
to be addressed each time the system is upgraded. It is like paying for the modification over and
over again. Most purchased ERP systems today are minimally modified (or as-is) to protect the
5
investment in the system. This is sometimes called a ―vanilla‖ implementation. Every ERP
vendor upgrades their system on a regular basis, adding functionality, fixing problems, and
generally keeping the product current with the ever-changing technology innovations to remain
competitive. Product life cycles are shown in Figure 1-7.
FIGURE 1-7 ERP Implementation Methodology
ERP VENDORS
The ERP software market has experienced tremendous growth in the last decade, even after
analysts had predicted its early demise in 1990s. The Global Industry Analysts, Inc., analyzed
ERP software market worldwide (North America, Europe, Latin America, Asia, and rest of
world) by revenue and application type. They predict that world market for ERP software will
reach $67.8 billion by the year 2015, dominated by North America and Europe, from the $36
billion in 2008. Tight budget amid the global economic crisis forces the enterprises to remain
more accountable toward spending on business process and applications. The focus has now
shifted toward reducing the operating costs, implementation time, and the cost of maintenance of
the ERP system. In turn, the vendors too are concentrating on the smaller projects that result in
quick returns, rather than on longer ones with higher implementation periods and delayed
payments. In turn, the enterprises are now opting for single application systems over multiple
systems, in order to save on costs and bring in more functional efficiencies.
6
Tier I includes large vendors like SAP, Oracle, and Microsoft, who provide support for large
companies; Tier II includes vendors supporting the midsize companies; and Tier III vendors
support small companies. Recently, the midsize and small company markets have shown
tremendous growth. Small companies, which usually have less than 30 users and less demanding
needs, prefer using Tier III software. Midsize companies (with less than 100 users) that have
outgrown Tier III packages often become Tier II clients. They usually have just a few localized
sites and prefer short-term investments. Tier I software is targeted for a large enterprise
company.
Here is the market share vendor between Tier II and top three Tier I vendors.
7
Introduction to SAP
SAP is the world leader in enterprise applications in terms of software and software-related
service revenue. Based on market capitalization, it is the world’s third largest independent
software manufacturer supporting all sizes of industries helping them to operate profitability,
grow sustainably and stay ahead of the competition in the market.
SAP is the largest enterprise applications provider and one of the largest software companies
worldwide. Although SAP and its enterprise competitors are all distinctly different from one
another, they are markedly similar as well. Most provide enterprise-class business software,
business intelligence and data warehousing solutions, software for small and medium-sized
businesses, platforms for web and application development, integration software to tie computer
systems together; various cloud computing offerings, and so on.
Brief history of SAP
SAP was founded nearly 40 years ago in Mannheim, Germany, by a group of former IBM
engineers with a singular vision: to develop software package that caters a company’s diverse
business functions together. The idea was to help companies replace 10 or 15 different business
applications such as financial systems (running accounts payables and receivables), warehousing
applications, production planning solutions, plant maintenance systems, and so on—with a single
integrated system. Even better, these former IBMers wanted to create a system that embodied all
8
the best practices that various types of businesses and industries had to offer. In the process, it
was envisioned that this new software package would minimize a great deal of complexity and
provide businesses with more real-time computing capabilities. This vision became real when
Systems, Applications, and Products in Data Processing (SAP), opened its doors in 1972. Those
of us working in the SAP ecosystem have long referred to the company and its products inter-
changeably using a single word best spelled out as S-A-P (ess aye pea), not sap.

Enterprise System Lecture03

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enterprise System Lecture03

Uploaded by

Copyright:

Available Formats

Enterprise System - CS556

Mr. Farhan Sabir Ujager email id: farhan@biit.edu.pk, WhatsApp# 0300-5733768

(Week 3) Lecture 5-6

Text Book: Enterprise Systems for Management by J. Thompson and Luvai

Reference book: Concepts in Enterprise Resource Planning by Bret Wagner

FIGURE 1-3 Example of Architecture of ERP at Large University

Figure 1-4 Logical Architecture of an ERP System

FIGURE 1-5 Tiered Architecture Example of ERP System

ERP Life Cycle

FIGURE 1-6 ERP Life Cycle

ERP Implementation Strategies

FIGURE 1-7 ERP Implementation Methodology

Brief history of SAP

You might also like