The Enterprise Systems Configuration Spring, 2012 The Enterprise Systems Configuration Spring, 2012

Track Vision ES Design ES Operations ES IT

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

ESE Framework Enterprise elements WorkDecisionResourceInformation System facets StrategyCompetencyCapacityStructure Engineering activities SpecificationAnalysisDesign implementatio n Performance measure CostTimeQuality Benefit (profit)

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

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

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

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

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.

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

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.

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.

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)

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

RowPerspective Constraint Model 1 PlannerFinancial/externalScope (an executive summary of system scope, cost, and how it would perform) 2 OwnerUsage/policyEnterprise (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 BuilderTechnology Technology model (adapting information model to the details of programming languages, tools, I/O devices, and others) 5 SubcontractorImplementation Out of context models (detailed specifications given to programmers who code modules) 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) 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 modelOrganization chart (org. unit, work product) Master schedule (business event and bus. cycle) Business plan (business objective and bus. strategy) System modelHuman interface architecture (role, deliverable) Processing structure (system event and processing cycle) Knowledge architecture (criterion, option) Technology modelHuman/technology interface (user, job) Control structure (execute, component cycle) Knowledge design (condition and action) ComponentsSecurity architecture (identity, transaction) Timing definition (interrupt and machine cycle) Knowledge definition (sub condition, step) Zackman’s Enterprise Framework

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

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

IDEF Concept (1) IDEF (ICAM Definition) ◦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

IDEF Concept (2) IDEF0 ◦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

IDEF Concept (3) IDEF Methodology ◦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.

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.

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),

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

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.

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.

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.

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.

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.

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.

Enterprise Systems Configuration SAP Implementation Spring, 2012 Enterprise Systems Configuration SAP Implementation Spring, 2012

R/3 SAP Module View Integrated Solution Client / Server Open Systems Financial Accounting Controlling Fixed Assets Mgmt. Project System Workflow Industry Solutions Production Planning Sales & Distribution Materials Mgmt. Human Resources Plant Maintenance Quality Mgmt.

SAP Enterprise Structure Example Financial Client GBI Operating Concern (global) GL## CA Europe EU## CA North Am. NA## CA Asia AS## Chart of Accounts (global) GL## CoA US## CC US## CA## CC CA## CoA DE## CC DE## GB## CC GB ## AU## CC AU## JP## CC JP ## Business Area – Bicycles BI##

Procurement Client GBI CC US## Dallas DL## Miami MI## S. Diego SD## CA## Toronto TO## Shipping Point DL## Storage Location RM## MI##SD##HD##HH## AU## Perth PE## Central Purchasing Organization (global) GL## Purchasing Org. US## CC DE## Heidelb. HD## Hamburg HH## SF## FG## MI## TG## FG## MI## TG## FG## MI## TG## FG## MI## RM## SF## FG## MI## TG## FG## MI## TO## TG## FG## MI## PE## CA## Purchasing Group North America N## PO DE## PGr Europe N## AU## Asia AS## SAP Enterprise Structure Example

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

Enterprise Structure Plant Client Chart of Accounts CompanyCode Fiscal Year Variant Credit Control Area PurchasingOrganization PurchasingGroup ShippingPoint SalesOrganization DistributionChannel Division Sales Area Controlling Area SL10SL20

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

January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.52 Business Process Integration FI MM SD Org Data Rules FI MM SD Master Data FI MM SD FISD MM

Business Process Integration January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved.53 MM PP SD Org Data Rules MM PP SD Master Data MM PP SD FISD MM FI PP