Post on 28-Aug-2018
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 2
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 3
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 4
The History of ERPs illustrated
From order management systems tobusiness analytics & more
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 5
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 6
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 7
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).
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 8
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 9
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 10
ERP Market
Overall Revenue of ERP VendorsRetrieved from Wikipedia (2012-04-17)
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 12
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 13
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 14
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 15
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 16
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 17
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,...
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 18
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!!
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 19
Use case for the Mtg SchedulerInitiator Participant
Schedule Meeting
Validate User
Generate Schedule
<<uses>>
EditConstraints
<<uses>>
ProvideConstraints
Withdraw
<<extends>>
<<uses>><<uses>>
<<uses>>
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 20
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 21
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 22
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 23
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 24
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 26
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 27
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 28
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 29
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!!
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 30
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 31
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 32
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 33
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 34
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 40
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 41
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 42
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 43
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?
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 44
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 45
OpenBravo: Under the Hood
● Model-View-Control based● Model-driven development
● (Business) models drive the code
● Standard technology● Java/JavaScript, SQL, XML,
XHTML
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 47
OpenBravo editions
0
365€ per year(3 concurrent users)Max 5
500€ per concurrent user
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 48
● Model-driven architecture● Great customization skills
Compiere
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 49
● 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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 50
● 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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 51
● [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