22. Enterprise Resource Planning Systemsdisi.unitn.it/~dalpiaz/ois/lib/exe/fetch.php?media=22-erps.pdf · Enterprise Resource Planning Systems (known as ERPs) ... use historical data

© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 1

22. Enterprise Resource Planning Systems


ERP Systems

● Enterprise Resource Planning Systems (known as ERPs) constitute an important trend in business applications, focusing on logistics and business processes. Earlier trends included Management Information Systems, Decision Support Systems and more.

● What? ERPs are generic, integrated software solutions that address enterprise needs taking a business process view of an organization to meet organizational goals, tightly integrating all functions of an enterprise [erpfans.com]

● Why? ERPs are being used to tackle problems such as material shortages, productivity enhancements, customer service, cash management, inventory problems and quality control.


The History of ERPs

● 60s – Reorder point systems: use historical data to forecast future inventory needs

● 70s – Materials requirements planning (MRP): demand-based approach for planning manufacturing products and ordering inventory

● 80s – Manufacturing resource planning (MRP II): added capacity planning; could schedule and monitor the execution of production plans

● 90s – Manufacturing execution systems (MES): can adapt production schedules to meet customer needs

● Since late 90s – ERPs support integration of back-office applications in support of business processes, such as in supply chain management


The History of ERPs illustrated

From order management systems tobusiness analytics & more


ERPs as Generic SW solutions

● Traditionally, software was developed as an one-of solution to someone's problem

● This means that customer A has a problem -- e.g., needs a computerized accounting system -- and software company S builds a solution for A; customer B also needs an accounting system, so S builds an accounting system for B, etc

● A generic software solution is a parameterized solution that can be customized to special needs of each customer, e.g., customer A vs customer B

● SE principle (reuse): Build once, use many times


ERPs as Integrated SW solutions

● Traditionally, organizational information systems have been developed in an "islands of automation" fashion

● This means that a company would build an accounting system to support its accounting services, a human resources system, etc. These systems were "islands" in the sense that they did not talk to each other

● The great push for integration came in the 90s, partly due to the adoption of business processes by companies, partly due to new technologies (CORBA, the internet, the web, …) and partly due to increased international competition

● This push was addressed by vendors of ERP systems who offered proprietary integrated architectures (e.g., SAP's R/3) to their customers


The Breakthrough for ERPs

● Generic solutions were unacceptable until the 90s ( → Not-invented-here syndrome)

● Every company felt that it was unique in the way it did business, e.g., (for a telephone company), the telephone services it offered customers, but also the accounting services used internally.

● In the 90s companies started changing their operations to make them business process-based

● ERP vendors used this as a basis to offer generic solutions based on "best practices" business processes.

● Companies were willing to adopt best practices solutions for areas that were not part of their core business (e.g., accounting for a telephone company).


ERP Practice

● ~1998: A single ERP system (SAP's R/3) was in use in more than 60% of multinational companies around the world

● By 1997, 50% of SAP's income came from SMEs● ERPs were the first to use in practice client-server architectures● ERPs changed the nature of IT jobs: instead of building and maintaining software,

focus shifted on customizing and integrating software● In 1998, ERP vendors sold ERP systems worth $17.2B (estimated $47B 2011); the

largest players have been SAP, Oracle, PeopleSoft and Baan.● ERP system costs have been high: The average cost of an ERP system sold in 1999

was $15M (about $53K per user) – 2005 figures: still $15M, about $20K per user


ERP Market

● 60% of Fortune 1000 companies use ERPs● In the early 90s, market growth was 40-50% per year, during 1999-

2001 slowed down to 30% per year. 18% in 2005-2006

Retrieved from Wikipedia (2011-04-13)

2 SSA Global Tech is now part of Infor Global Solutions


ERP Market

Overall Revenue of ERP VendorsRetrieved from Wikipedia (2012-04-17)


How many apps per enterprise?


Core ERP Subsystems

● Human resources● Master Scheduling● Materials Requirements Planning● Capacity Requirements Planning● Bill of Materials● Purchasing● Shop Floor Scheduling (e.g. JIT)● Accounts Payable (Creditors)● Logistics

Generally, back-office functions


ERPs and CS Research

● Cooperative Information Systems focus on global information systems which integrate legacy “point solutions”; topics of interest include interoperation, workflows, data integration, integration architectures…

● Databases, where there is active interest in data integration, extended transaction models, (most recently) application-driven data management…

● Software Engineering, where there has been work on software families [Parnas76] and product lines [sei.cmu.edu], covering topics such as domain engineering and application engineering


Product Families

● A product family (or product line) consists of similar software systems that share common characteristics, but also differ in certain respects (variant requirements)

● Commonalities and variations arise from many sources:● Functional requirements – payroll, customer order processing, reservation

systems● Non-functional requirements, design decisions● Runtime component structure, distribution● Computing platforms -- GUI, databases, OS, …● Political, social or personal factors (note: yes, these should be part of the

equation too!!)

[Jarzabek99]


How to Build/Use ERPs?

Domain Analysis

Domain Experts

Domain Model Generic Architecture

Existing Applications in Domain

EvolutionEvolution

Requirements for

ApplicationCustomizationCustomization

CustomizedApplicationAnalysisAnalysis

Domain EngineeringS

takeholders

ApplicationEngineering


Example: Meeting Scheduler

● We want to build a software family for meeting scheduling systems (MSS) for universities, offices, hotels, hospitals,...

● Common requirements for MSS: gathering constraints, scheduling, making reservations, facility management (optional), user management, payment (optional)

● Where do we start? Let’s build a domain model● Next slide


Domain Model: Meeting Scheduler

● Relevant objects include: ● mtg initiator, participants, requested mtg, scheduled mtg, time

constraints, place constraints,…;

● Relevant processes include: ● Meeting scheduling: initiator requests a mtg, names participants, system

collects constraints, proposes a schedule (time and place), gets confirmation from initiator, or goes back to looking for alternatives;

● Managing facilities: keeps track of who has booked what room, equipment required, payment involved,...


Entities in the Domain Model

1

0..*

0..1

hasPart

Person

nameemail

Meeting

timeplace

participates

RequestedMtg

ScheduledMtgTimetable

initiates

2..*

0..*

1

hasPart

ConstraintMtgRequirement

TimeReq

SpaceReq

LocationReq

EquipmentReq

0..*

0..*

0..*

0..*

hasPart

hasPart

Conceptual Modelling!!


Use case for the Mtg SchedulerInitiator Participant

Schedule Meeting

Validate User

Generate Schedule

<<uses>>

EditConstraints

<<uses>>

ProvideConstraints

Withdraw

<<extends>>

<<uses>><<uses>>

<<uses>>


Sequence Diagram

1. login2. validate

3. prompt

4. give details

5. inform participants

6. remind participants

7. prompt scheduler

8. present schedule

9. schedule OK’ed 10. inform

participants

:Person:MtgRequest :MtgManager :Scheduler

:Person


Generic Architecture

MSS Client MSS Server

Database System

Scheduling Logic

Facility Mgt Logic

User Mgt Logic

Initialization Logic

DB InterfaceLogic

Conflict ResLogic

PaymentLogic

PanelInitialization

Main MenuPanel

SchedulingPanels

FacilityMgt Panels

ConfigurationPanels

User MgtPanels

User Interface Business Logic Database


Feature Models

● Feature models describe allowable configurations of features.● In addition to the above, there is also XOR decomposition

Manage schedules

Meetings People

Schedules Facilities User mgt Payments

Sched panel Sched logic

OR decomp

AND decompoptional


Customizing generic SW

● Unsupported customization (extension): extend or modify generic software to support unanticipated features

● Supported customization: select among available options (through switches, tables or some other mechanism) to customize the generic package to a particular application

● For both types, ERP technology could do better:● Most companies buying generic packages do 10-20% unsupported customization

[Forrester98, Glass99]; customization of business logic leads the way● Customizing a generic package to a particular application is a costly, time-

consuming and error-prone process● “...The ERP vendors have taken a model T approach -- you can have any

colour you want, as long as it’s black…” [Forrester99]


SAP R/3

● With the advent of distributed client-server computing SAP AG brought out a client-server version of the software called SAP R/3 that was manageable on multiple platforms and operating systems which opened up SAP to a whole new customer base

● SAP R/3 was officially launched on July 6, 1992 and came to dominate the large business applications market for a decade

● SAP introduced the object-oriented concept of "business objects"; e.g., a customer in the system is actually an instantiation of a customer business object, and interacts with other objects in the system in pre-defined but customizable ways

● Traditionally, software vendors sold applications tailored to the needs, and business processes, of each individual customer. SAP provided standardized processes, which were termed best-practice solutions


R/3, according to SAP


R/3 Functional Modules

● R/3 is arranged into distinct functional modules, covering the typical functions in place in an organization

● The most widely used modules are Financials and Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales & Distribution (SD), and Production Planning (PP)

● Each module handles specific business tasks on its own, but is linked to the others where applicable. For instance, an invoice from the Billing transaction of Sales & Distribution will pass through to accounting, where it will appear in accounts receivable and cost of goods sold

● Using SAP often requires the payment of hefty license fees, as the customers have effectively outsourced various business software development tasks to SAP


Technology

● SAP R/3 is a 3-tiered client/server based application● SAP R/3 functionality uses its own proprietary language called ABAP

(Advanced Business Application Programming). ABAP is a fourth generation language (4GL), geared toward the creation of simple, yet powerful programs

● R/3 also offers a complete development environment where developers can either modify existing SAP code to modify existing functionality or develop their own functions, whether reports or complete transactional systems

● ABAP's main interaction with the database system is via open SQL statements. These statements allow a developer to query, update, or delete information from the database

● Advanced R/3 features include GUI development and advanced integration with other systems


Customizing/Implementing R/3● SAP R/3 is never used the same way twice; e.g., Atlas Copco can

have a different implementation of SAP R/3 than Procter & Gamble. ● Two primary issues influence the complexity of the implementation:

● Customization configuration - there are tens of thousands of database tables that may be used to control how the application behaves. Each company will have its own accounting "Chart of Accounts" which reflects how its transactions flow together to represent its activity. That will be specific to a given company. In general, the behavior (and appearance) of virtually every screen and transaction is controlled by configuration tables. This gives the implementor great power to make the application behave differently for different environments.

● Extensions, Bolt-Ons - In any company, there will be a need to develop interface programs to communicate with other information systems. This entails developing ABAP/4 code, and considerable "systems integration" effort to either determine what data is to be drawn out of R/3 or to interface into R/3 to load data into the system.


Personnel Requirements

● Due to the complexity of implementation, these companies recruit highly skilled SAP consultants to do the job. The implementation must consider the company's needs and resources. Some companies implement only a few modules of SAP while others may want numerous modules

This is how this course was born!!


R/3 Layers and Application Modules

● R/3 has several layers. ● The Basic System (BC) includes the ABAP programming language, and

is the heart of operations and should not be visible to higher level or managerial users. Other customizing and implementation tools exist also.

● The heart of the system (from a manager's viewpoint) are the application modules. These modules may not all be implemented in a typical company but they are all related.


Application Modules

● FI Financial Accounting – automated management and external reporting of general ledger, accounts receivable, accounts payable and other sub-ledger accounts with a user defined chart of accounts. As entries are made relating to sales production and payments journal entries are automatically posted: "books" reflect the real situation

● CO Controlling – represents the company's flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur

● AM Asset Management – manages and supervises individual aspects of fixed assets including purchase and sale of assets, depreciation and investment management

● PS Project System – designed to support planning, control and monitoring of long-term, complex projects with defined goals

● WF Workflow – links the integrated SAP application modules with cross-application technologies, tools and services


More R/3 Modules

● HR Human Resources – Supports planning and control of personnel activities● PM Plant Maintenance – Manages building and equipment maintenance● MM Materials Management – Supports the procurement and inventory functions

occurring in day-to-day business operations such as purchasing, inventory management, reorder point processing, etc.

● QM Quality Management – Supports quality planning, inspection, and control for manufacturing and procurement

● PP Production Planning – Plan and control manufacturing activities● SD Sales and Distribution – Optimize all the tasks and activities carried out in

sales, delivery and billing● WM Warehouse Management – Control of stock to a physical level down to a

warehouse bin


Financial Accounting Module

● Consists of 8 sub-modules:● FI-GL -- General Ledger Accounting● FI-LC -- Consolidation● FI-AP -- Accounts Payable● FI-AR -- Accounts Receivable● FI-BL -- Bank Accounting● FI-AA -- Asset Accounting● FI-SL -- Special Purpose Ledger● FI-FM -- Funds Management


Industry-specific Solutions

● Industry Solutions combine the SAP application modules and additional industry-specific functionality. Special techniques have been developed for industries such as banking, oil and gas, pharmaceuticals

● As of Feb 2006, following Industry Specific Solutions are supported by SAP: Automotive, Aerospace & Defense, Apparel and Footwear, Bank, Beverage, Catch Weight Mgmnt, Defense & Security, Hospital, Higher Education, Hospitality Mgmnt ,High Tech, Media, Mining, Mill Products, Oil, Public Sector, Retail, Recycling Admin, Service Provider, Telecommunications, Utilities

● Note: These are not necessarily ERPs any more, may involve front-office functions


Look-and-Feel: Creating aSales order






Beyond R/3: SAP NetWeaver

● SAP NetWeaver is an application builder platform for integrating business processes across systems and databases

● It is the technological foundation for all SAP products since the SAP Business Suite. NetWeaver is a service-oriented application and integration platform (i.e. NetWeaver is the interface and runtime environment between applications)

● NetWeaver interoperates with and can be extended using Microsoft .NET, Sun Java EE, and IBM WebSphere. SAP is fostering relationships with system integrators and technology providers, many of the latter becoming "Powered by SAP Netweaver"

● SAP Netweaver is part of SAP's plan to transition to a new architecture. From a technical point of view, one can say that SAP NetWeaver is an evolution of mySAP technology, also known as simply SAP


SAP Exchange Infrastructure

● SAP Exchange Infrastructure (SAP XI) is SAP's enterprise application integration (EAI) software, a component of the NetWeaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties.

● SAP XI is compatible with software products of other companies

● SAP calls XI an integration broker because it mediates between entities with varying requirements in terms of connectivity, format, and protocols. According to SAP, XI reduces the TCO by providing a common repository for interfaces

● The central component of SAP XI is the SAP Integration Server, which facilitates interaction between diverse operating systems and applications across internal and external networked computer systems


mySAP Business Suite

● mySAP Business Suite is a family of adaptive business applications, providing best-of-breed functionality built for integration, industry-specific functionality, scalability, and collaboration over the Internet.

meant for → SME

● mySAP Business Suite applications are based on the NetWeaver platform, an integration and application platform. This reduces total cost of ownership across the entire IT landscape and supports the evolution of mySAP Business Suite to a services-based architecture

● mySAP components:● Customer Relationship Management, ERP Product Lifecycle Management,

Supply Chain Management, Supplier Relationship Management


Towards Open Source

● ERPs are very expensive● Acquisition cost● Maintenance cost

● Open source systems are becoming an alternative● No acquisition cost● Freedom to customize/modify● Often web-based● Maintenance?


OpenBravo

● Hosted by SourceForge● Focus on Agility

● To manage change and exploit opportunities● “Tactical” time horizon: week, month, quarter● 100% web-based● Cost-effectiveness● Pay-as-you-go subscription● No hidden fees● Around 15k users● Around 1000 customers


OpenBravo: Under the Hood

● Model-View-Control based● Model-driven development

● (Business) models drive the code

● Standard technology● Java/JavaScript, SQL, XML,

XHTML


OpenBravo editions


OpenBravo editions

0

365€ per year(3 concurrent users)Max 5

500€ per concurrent user


● Model-driven architecture● Great customization skills

Compiere


● Flexible workflow support● General Workflow – Provides guidance and step-by-step instructions

for achieving a task● Document Process Workflow – Started when processing any

document. You can use these workflows to manage approvals● Document Value Workflow – The workflow is automatically started

when any entity fulfils a user defined condition● Security

● Role-based● Data security (professional & enterprise editions)● Auditing

Compiere


● Compiere can be deployed on the cloud● Amazon Elastic Compute Cloud (EC2)

● Advantages● Security and scalability● More flexible than Software-as-a-Service

– Customers have their own installation● Low cost

Compiere on the cloud


● [erpfans.com] www.erpfans.com.● [Forrester98] Forrester Report, Conquering Customization, March 1998.● [Forrester99] Forrester Report, ERP eCommerce Realities, April 1999.● [Glass99] Glass, R., Vessey, J., “Enterprise Resource Planning Systems: Can they Handle

the Enhancement Changes Most Enterprises Require”, Proceedings EMPRS’99, Venice, November 1999.

● [Jarzabek99] Jarzabek, S.,”Synergy between Component-Based Software Engineering and Generative Approaches to System Families”, Software Engineering seminar, University of Toronto, October 1999.

● [Macala96] Macala R., Stuckey, L. Jr. and Gross, D. “Managing Domain-Specific, Product-Line Development,” IEEE Software, May 1996, 57-67.

● [Parnas76] Parnas, L., “On the Design and Development of Program Families”, IEEE Transactions on Software Engineering 2(1), January 1976.

● [Rolland99] Rolland, C., “A Goal-Driven Approach to Modeling COTS Acquisition Impacts”, Proceedings EMPRS’99, Venice, November 1999.

● [sei.cmu.edu] www.sei.cmu.edu/domain-engineering

References

Documents

22. Enterprise Resource Planning Systemsdisi.unitn.it/~dalpiaz/ois/lib/exe/fetch.php?media=22-erps.pdf · Enterprise Resource Planning Systems (known as ERPs) ... use historical data