1. The Enterprise Systems Configuration Spring, 2012

2. Track Vision
ES Design
ES Operations
ES IT

3. Track Courses Sequence
EGN 5620 ES Configuration
EGN 5622 ES Integration
EGN 5623 ES Optimization
EGN 5621 ES Collaboration
5620
5622
5621
5623

4. ESE Framework Enterprise elements System facets Engineering activities
Decision
Resource
Information
System facets
Strategy
Competency
Capacity
Structure
Engineering activities
Specification
Analysis
Design
implementation
Performance measure
Cost
Time
Quality
Benefit (profit)

5. High-Level OP Planning
ECC 6.0
January 2008
Enterprise Operations
OP Execution
High-Level OP Planning
Procurement
Process
CO/PA
Detailed OP Planning
Forecasting
Sales and Operations
Planning
Demand
Management
MPS
MRP
Execution
Sales Information
System
Manufacturing
Execution
Warehouse
Management
Strategy Planning
Vision
Goals & Objectives
Strategy
Product Portfolio and Roadmap
Sales
Process
January 2008
© SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.
© SAP AG and The Rushmore Group, LLC 2008

6. Enterprise Systems Architectures: Theories & Concepts Spring, 2012

7. Three major enterprise (information reference) architectures
Generalized enterprise reference architecture (GERA)
Purdue enterprise reference architecture (PERA)
Enterprise architecture framework
By John Zackman

8. GERA - Three scoping/modeling dimensions
Life-cycle dimension
Provides for the controlled modeling process of enterprise entity according to its life cycle
Generic-ity dimension
Provides for the controlled particularization (instantiation) process from generic (or partial) to particular.
View dimension
Provides for the controlled visualization of specific views of the enterprise entity

9. GERA - Enterprise life-cycle phases (1)
Identification
(A set of activities that) identifies the contents of the enterprise in terms of the nature of its existence, its need and the need for changes.
Concept
(A set of activities for) developing the concepts of the underlying enterprise, including the definition of its mission, vision, values, strategies, objectives, operational concepts, policies, and business plans.
Requirements
(A set of activities for) developing descriptions of operational requirements of the enterprise, its relevant processes, and the collection of all their functional, behavioral, information and capacity needs for both production and mgt, whether by humans or machinery.

10. GERA - Enterprise life-cycle phases (2)
Design
(A set of activities that) support the specification of the enterprise with all of its components that satisfy the enterprise requirements. They include the design of all human tasks, all machine tasks, and operational processes (including identification of necessary information and resources for mfg. information, communication, control and other processing technology)
Sub-phases: preliminary (architectural) design and detailed design
Implementation
(A set of activities that) define all tasks that must be carried out to build or re-build (manifest) the enterprise. This comprises implementation in the broadest sense, covering
Commissioning, purchasing, re-configuring, or developing all software and hardware resources for services, mfg. and control.
Hiring and training personnel, and developing or changing the human organization.
Component testing and validation, system integration, validation, and testing, and releasing into operation

11. GERA - Enterprise life-cycle phases (3)
Operation
The activities of the enterprise that are needed during its operation for producing the customers products and service which is its special mission , along with all those tasks needed for monitoring, controlling, and evaluating the operation.
Thus the resources of the enterprise are managed and controlled so as to carry out the processes necessary for the entity to fulfill its mission
Deviations from goals and objectives or any feedback from the environment may lead to requests for change, which includes enterprise re-engineering, continuous improvements of its human and technology resources, its business process, and its organization.
Decommission
The activities needed for disbanding, re-missioning, re-training, redesign, recycling, preservation, transfer, disassembly, or disposal of all or part of the entity at the end of its useful life in operation.

12. GERA - Enterprise’s entity types (4)
Type A – strategic management entity
such as an (enterprise) engineering project
Very short life cycle
Type B – engineering implementation entity
Entity that creates other enterprise entities
Type C – enterprise entity
Entity that produces customers goods and services
Type D – product entity
All products and customers services of enterprise type C
Type E – methodology entity
Entity that establishes tasks to support other entities.

13. GERA - views Entity model contents views
Function (model of functions and behaviors of business processes)
Information (model)
Organization (of responsibilities and authorizations on entities)
Resource (model)
Entity purpose views
(Customer) service and product views (contents relevant to operation and its results
Management and control views (contents relevant to mgt.)
Entity implementation views
Human activities view (of information related to human tasks)
Automated activities view (of information related to machine tasks)
Entity physical manifestation views
Software view (information resources capable of performing a task set)
Hardware view (physical resources capable of performing a task set)

14. PERA Layers (life cycle phases)
Identification
of the CIM business entity
Concept layer
mission, vision, and values
Definition layer
functional requirement
Specification layers
architectural design
Detailed design layer
Manifestation layer
Implementation
Operations layer

15. Zackman’s Enterprise Framework
Row
Perspective
Constraint
Model 1
Planner
Financial/external
Scope (an executive summary of system scope, cost, and how it would perform) 2
Owner
Usage/policy
Enterprise (business) model (business entities, processes and how they interact) 3
Designer (analyst)
Structure/operation
System model (data elements and functions that represent business entities and processes) 4
Builder
Technology
Technology model (adapting information model to the details of programming languages, tools, I/O devices, and others) 5
Subcontractor
Implementation
Out of context models (detailed specifications given to programmers who code modules)

16. Zackman’s Enterprise Framework
Data (with entity and relation)
Function (with function and parameter)
Network (with node and link)
Scope (planner)
List of things important to the business (entity: class of business thing)
List of processes the business performs (function: class of business processes)
List of location in which the business operates (node: major business location)
Enterprise model (owner)
ENT/REL diagram (business entity, business constraint)
Process flow diagram (business process and resources)
Logistics network (business location, business linkage)
System model (designer)
Data model (data entity and data relationship)
Data flow diagram (application function and user view)
Distributed system architecture (I/S function, and line characteristics)
Technology model (builder)
Data design (segment/row; pointers/key)
Structure chart (computer function and screen/device format)
System architecture (hardware/system software, line specifications)
Components (subcontractor)
Data definition description (field and address)
Program (language statement and control block)
Network architecture (address, protocol)

17. Zackman’s Enterprise Framework
People (agent, work)
Time (time, cycle)
Motivation (ends, means)
Scope
List of organizations/agents important to the business (major org. unit)
List of events significant to the business (major business event)
List of business goal/strategy (major bus. goal and critical success factor)
Enterprise model
Organization chart (org. unit, work product)
Master schedule (business event and bus. cycle)
Business plan (business objective and bus. strategy)
System model
Human interface architecture (role, deliverable)
Processing structure (system event and processing cycle)
Knowledge architecture (criterion, option)
Technology model
Human/technology interface (user, job)
Control structure (execute, component cycle)
Knowledge design (condition and action)
Components
Security architecture (identity, transaction)
Timing definition (interrupt and machine cycle)
Knowledge definition (sub condition, step)

18. Enterprise Systems Modeling: Concepts and Tools Spring, 2012

19. Information systems modeling tools
IDEF
IDEF0 (activities)
IDEF1x (information)
IDEF2x (dynamics)
OMT
Functional model
Object model
Dynamic model

20. IDEF Concept (1) IDEF (ICAM Definition) ICAM Objective
Developed by the US Air Force Integrated Computer Aided Manufacturing (ICAM) Programs in 1981
ICAM Objective
To develop structured methods for applying computer technology to manufacturing and to better understand how best to improve manufacturing productivity

21. IDEF Concept (2) IDEF0 IDEF1 IDEF2
An activity model of a manufacturing system and environment
IDEF1
An informational model of the system and environment
IDEF2
A dynamic model to describe time-varying system behavior

22. IDEF Concept (3) IDEF Methodology Commercial IDEF software tools
Modeling process and tools, leading to creation of the three IDEF models
IDEF0 (activities)
IDEF1x (information)
IDEF2x (dynamics)
Commercial IDEF software tools
Design/IDEF by Meta Software Company
AI0WIN by Knowledge Based Systems Inc.

23. OMT Concepts (1) Object modeling technique (OMT)
“Object-oriented” means:
Software organized as a collection of discrete objects that incorporate both data structure and behavior, in contrast to conventional programming in which data structure and behavior are only loosely connected.
OMT Methodology (in stages):
system analysis,
system design,
Object (implementation) design, and
implementation.

24. OMT concepts (2) - common themes
Synergy (i.e., shifting focus from coding technique to packaging, based on consistent
identity,
classification,
polymorphism, and
inheritance
Abstraction,
Encapsulation,
Combining data and behavior,
Sharing (inheritance of data structure & behavior among subclasses)
Emphasis on object structure (not procedure structure),

25. OMT Concepts (3) - Synergy
Identity
Data is quantized into discrete, distinguishable entities called objects
Classification
Objects with the same data structure (attributes) and behavior (operations) are grouped into a class
An operation is an action or transformation that an object performs or is subject to.
polymorphism
The same operation may behave differently on different classes.
A specific implementation of an operation by a certain class is called a method. Each operation may have multiple methods implementing it.
inheritance
The sharing of attributes and operations among a hierarchy of object classes

26. OMT Models (4) 3 OMT models used to describe a system: Object model
describing the objects in the system and their relationships;
Dynamic model
describing the interactions among objects in the system; and
Functional model
describing the data transformation of the system.
Their relationship
The object model describes what changes (or transforms) before when (dynamic model) or how (functional model) it changes.

27. OMT Functional Model (5)
It describes the data value transformations within a system.
The functional model contains data flow diagrams.
A data flow diagram is a graph whose nodes are processes (activities) and whose arcs are data flows.

28. OMT Object Model (6)
It describes the static structure of the objects in a system and their relationships.
The object model contains object diagrams.
An object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.

29. OMT Dynamic Model (7)
It describes the aspects of a system that change over time and is used to specify and implement the control aspects of a system.
The dynamic model contains state diagrams.
A state diagram is a graph whose nodes are states and whose arcs are transitions between states caused by events.

30. Relationship between the two techniques & among the three models
IDEF0/functional model
The input to an activity is usually through a user interface for data entry
The output from an activity is usually a user interface for a report, though the output may be a write/update to a database. IDEF0’s
ICOM
Material is an input object.
Product/process data are output objects.
Rules/regulations and SOPs are constraints. Technical precedence is a constraint
Resources/tools and methods are a mechanism.
IDEF1/object model
The collection of the ICOM of an IDEF activity model constitutes an inclusive foundation for the object model.
IDEF2/dynamics model
Each object requires a state diagram to define/govern its life-cycle behavior.
A triggering event is associated with each transition from one state to another. One state may transform to multiple states, depending on the triggering event.

31. Relationship between the two methods and among the three models
IDEF0/functional model
The input to an activity is usually a user interface for data entry
The output to an activity is usually a user interface for a report, though the output may be a write/update to a database.
ICOM
Material is an input object.
Product/process data are output objects.
Rules/regulations and SOPs are constraints.
Resources/tools and methods are mechanisms.
IDEF1/object model
The collection of the ICOM of an IDEF activity model constitutes an inclusive foundation for the object model.
IDEF2/dynamics model
Each object requires a state diagram to define/govern its life-cycle behavior.
A triggering event is associated with each transition from one state to another. One state may transform to multiple states, depending on the triggering event.

45. Enterprise Systems Configuration SAP Implementation Spring, 2012

46. R/3 SAP Module View Integrated Solution Client / Server Open Systems
Financial
Accounting
Sales &
Distribution
Materials
Mgmt.
Controlling
Production
Planning
R/3
Fixed Assets
Mgmt.
Integrated Solution
Quality
Mgmt.
Project
System
Client / Server
Plant
Maintenance
Open Systems
Workflow
R: real time. 3: 3-tier client-server architecture (database, application, and presentation layers)
Human
Resources
Industry
Solutions

47. SAP Enterprise Structure Example
Financial
Business Area – Bicycles BI##
CC CA##
CC GB##
CC AU##
CC JP##
CC US##
CC DE##
CC: company code. CoA: chart of accounts (country-specific). CA: controlling area. Business Area: by products
CoA US##
CA##
CoA DE##
GB##
AU##
JP##
Chart of Accounts (global) GL##
CA North Am. NA##
CA Europe EU##
CA Asia AS##
Operating Concern (global) GL##
Client GBI

48. SAP Enterprise Structure Example
Procurement
Shipping Point
DL##
MI##
SD##
TO##
HD##
HH##
PE##
RM##
TG##
TG##
TG##
RM##
TG##
TG##
Storage Location
SF##
FG##
FG##
FG##
SF##
FG##
FG##
FG##
MI##
MI##
MI##
FG##
MI##
MI##
MI##
MI##
Central Purchasing Organization (global) GL##
Purchasing Org. US##
CA##
PO DE##
AU##
Purchasing Group North America
N##
PGr Europe
N##
Asia
AS##
CC: company code. CoA: chart of accounts (country-specific). CA: controlling area. Business Area: by products
Dallas
DL##
Miami
MI##
S. Diego
SD##
Toronto
TO##
Heidelb.
HD##
Hamburg
HH##
Perth
PE##
CC US##
CA##
CC DE##
AU##
Client GBI

49. SAP Enterprise Structure Example
Sales and Distribution
Distribution Channel Wholesale WH
Division Accessories AS
Division Bicycles BI
Distribution Channel Internet IN
SO West
UW##
SO West
CW##
SO North
DN##
SO North
GN##
SO North
AN##
CC: company code. SO: sales organization. Division: by product line
SO East
UE##
SO East
CE##
SO South
DS##
SO South
GS##
SO South
AS##
CC US##
CC CA##
CC DE##
CC GB##
CC AU##
Credit Control Area (global) GL##
Client GBI

50. Enterprise Structure Plant Client Chart of Accounts Company Code
Fiscal Year
Variant
Credit Control
Area
Purchasing
Organization
Group
Shipping
Point
Sales
Distribution
Channel
Division
Sales Area
Controlling Area
SL10
SL20

51. BPI – II Final Roadmap Procurement Process Production Process Sales
ECC 6.0
January 2008
BPI – II Final Roadmap
Purchase
Order
Purchase
Requisition
Procurement
Process
Schedule
and Release
Goods
Receipt
Convert Production
Proposal
Production
Process
Goods
Issue
Run MPS w/MRP
Invoice
Receipt
Sales
Process
Check
Availability
Completion
Confirmation
Payment
to Vendor
Sales Order
Entry
Quality
Inspection
Pick
Materials
Goods
Receipt
Order Settlement
Receipt of
Payment
Post Goods
Issue
January 2008
© SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.
Invoice
Customer
© SAP AG and The Rushmore Group, LLC 2008

52. Business Process Integration
ECC 6.0
Business Process Integration
January 2008 FI SD MM
Transactions
Org Data
Master Data FI MM SD
Rules FI MM SD FI
In the Business Process Integration class we use the stool as a metaphor for the SAP structure. There are four basic components needed to run execute SAP. Three of these are the legs of the stool: org data, master data, and rules. These ‘hold up’ the transactions. Transactions cannot be run unless these are setup.
The legs are typically configured during the implementation process.
During BPI 1 we will setup the stool for Finance, Materials management and Sales and Distribution. MM SD
January 2008
© SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.
© SAP AG and The Rushmore Group, LLC 2008

53. Business Process Integration
ECC 6.0
January 2008
Business Process Integration FI MM PP SD
Transactions
Master Data MM PP SD
Org Data
Rules MM PP SD FI FI FI MM
In the Business Process Integration class we use the stool as a metaphor for the SAP structure. There are four basic components needed to run execute SAP. Three of these are the legs of the stool: org data, master data, and rules. These ‘hold up’ the transactions. Transactions cannot be run unless these are setup.
The legs are typically configured during the implementation process.
During BPI 1 we will setup the stool for Finance, Materials management and Sales and Distribution. PP SD
January 2008
© SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.
© SAP AG and The Rushmore Group, LLC 2008