BM MPE Lecture

Roman Pietroń, D.Sc.
BUSINESS MODELING
Modelowanie biznesu, Modelowanie biznesowe (pol.)
Course edition for Mechanical & Power Engineering Faculty
Teaching workload: 30h (total: 90h)

Credit rating: 3 ECTS
Wrocław, 2022/2023.
Roman Pietroń, D.Sc.
• Work location:
– Wrocław University of Science and Technology (pol. Politechnika Wrocławska),
Faculty of Management, Department of Operations Research and Business
Intelligence (K-43), B1 building (413c)
• Contact:
– e-mail: [email protected]
– Materials: http://p.wz.pwr.edu.pl/~pietron.roman (https://www.ii.pwr.edu.pl/~roman.pietron)
– Contact hours: Monday (16.45-18.45), Wednesday (9.00-11.00) – 413c B1 (also on-line MS Teams)
• Teaching background:
– Projektowanie systemów zarządzania (w, p), Języki programowania (w, lab), Badania operacyjne (lab)
– Modelowanie symulacyjne (w, p, lab), Modelowanie symulacyjne w logistyce (w, lab), Gry kierownicze (ćw)
– Ubezpieczenia (w, sem), Analiza finansowa w ubezpieczeniach (w, ćw), Rynkowy system finansowy –
ubezpieczenia (w, ćw), Ubezpieczenia gospodarcze (w, ćw), Commercial Insurance (l, ex)
– Ekonomika przedsiębiorstwa (w), Economical Modelling (l, lab, p)
– Process Management (l), Analiza, projektowanie i implementacja procesów biznesowych (lab)
– Business Modelling (l, lab, p), Business Modelling & Analysis (l, ex), Business Process Modelling (l, lab, p)
– Zarządzanie logistyką (w, sem), Logistyka (w, ćw), Logistics (l, ex), Logistics Management Tools (l)
Basic textbook
• Pietroń R., Business Modelling, e-material, Wrocław

University of Science and Technology, 2022.
• Pietroń R., Process Management, Wrocław University
of Technology, Wyd. PRINTPAP Łódź, 2011.
Bibliography
• Bitkowska A., Zarządzanie procesami biznesowymi w przedsiębiorstwie, VIZJA PRESS & IT,
Warszawa 2009. (in Polish)
• Gabryelczyk R., ARIS w modelowaniu procesów biznesu, Difin, Warszawa 2006. (in Polish)
• Gołębiowski T., Dudzik T.M., Lewandowska M., Witek-Hajduk M., Modele biznesu polskich
przedsiębiorstw, Wyd. DSGH Warszawa, Warszawa 2008. (in Polish)
• Grajewski P. Organizacja procesowa, PWE, Warszawa 2007. (in Polish)
• Jacka J.M., Business process mapping: improving customer satisfaction, J.Wiley & Sons,
NY, 2002.
• Kasprzak T., (red.), Modele referencyjne w zarządzaniu procesami biznesu, Wyd. Difin,
Warszawa 2005. (in Polish)
• Pacholski L., Cempel W., Pawlewski P., Reengineering. Reformowanie procesów biznesowych i
produkcyjnych w przedsiębiorstwie, Wyd. Polit. Poznań 2009. (in Polish)
• Perechuda K. (Ed), Advanced business models, Wyd. UE Wrocław, Wrocław 2015.
• Scheer A.-W., et al. (eds), Business process excellence: ARIS in 2002 practice, Springer-
Verlag, 2002.
• Van der Aalst W., et al. (eds), Business process management: models, techniques, …,
Springer, Berlin 2002.
• Vand der Pijl P., Lokitz J., Solomon L.K., Nowoczesne projektowanie modeli biznesowych,
OnePress - J.Wiley & Sons Inc (2016) / Helion, Gliwice 2018. (in Polish)
• Weske, M. (2007), Business process management: concepts, languages, architectures.
Springer, Berlin 2007.
• White S.A., Miers D., BPMN modeling and reference guide, Future Strategies Inc.,
Lighhouse Point 2008.
• and more …
Bibliography – cont.
Selected articles from professional journals (see PWr. Library)
Journals:
• Business Process Management Journal
• International Journal of Advanced Manufacturing Technology
• Journal of Operations and Production Management
Lecture course description
• The lecture enables students to learn the basic concepts
of business (enterprise) modelling and experiment /
simulation methodology with its applications in
management of business systems. It consists of the
following parts: methodology of modelling (business
strategies, object-oriented, process-oriented, operations
research, simulation/gaming concepts and methods),
modelling concepts, techniques, verification,
optimisation, interpretation of model results. The
practical part of the course includes survey and an
application of some modelling methods and software
tools for business management modelling (particularly
BPM).
Lecture course content
• Introduction to business and business systems modelling. Origins
and background.
• Introduction to business and BPM modelling. Business structure,
effectiveness and competitiveness.
• Application of modelling in business and management. Case
studies.
• Fundamentals of modelling. Notions, objects, relations,
architectures, functions, processes.
• Methodology of quantitative and qualitative modelling.
Simulation, OR, AI, ABM, BPM, BPR.
• Continuous, discrete and hybrid simulation modelling. Examples
of projects.
• Simulation games. Management and decision games for business
management.
• Computer simulation languages and systems for BPM. Software and
applications.
Lecture course content
• The concept of ARIS approach. The 5-element architecture, process
life-cycle.
• ARIS Product family. ARIS Toolset, ARIS ABC, ARIS Simulation.
• Implementation of ARIS methodology. Planning, implementation,
design, improvement.
• Structured approach to business modelling and analysis. IDEF
family of methods, modelling notations (UML, EPC, BPMN).
• Structured approach to business modelling and analysis. iGrafx Six
Sigma system.
• Course summary - practical conclusions and assessments
Lecture class assessment
LECTURE ASSESSMENT:
Colloquium (100%) + attendance bonus points
Date of colloquium:
25th of January 2023, 1115-1245
1st of February 2023, 1115-1245 (Retake)
Students
Lecture class audience
CAE
W09/ RSE
ENGAN
Erasmus?
RAC
W09/
MBEAN Erasmus?
ISG IME
Questions to answer (1)
• BUSINESS AND BUSINESS PROCESS MODELLING (business, business modelling,
business architectures, business process, business process modelling, modelling
methods and tools)
1. What is the purpose of a business and what types of businesses do you know?
2. What are the basic organisation structures of business management?
3. List and discuss the strengths and weaknesses of functional management structure.
4. List and discuss the strengths and weaknesses of divisional management structure.
5. List and discuss the strengths and weaknesses of hybrid management structure.
6. List and discuss the strengths and weaknesses of matrix management structure.
7. What is a process management and a business process management?
8. What are differences between function-oriented and process-oriented management in enterprises?
9. What are the reasons and positive effects of process management implementation in organisations?
10. What new positions and roles (responsibilities and authorities) in organisation structure does a process-
oriented management create?
11. What are the maturity stages that an organisation goes through when becoming a process oriented
organisation?
12. What are measures and attributes of processes in organizations?
13. What are principles to establish process measurements? (RUMBA model)
14. What are the methods of business modelling (processes, functions, and objects)?
15. Business model and business process model – is it the same?
• BUSINESS AND BUSINESS PROCESS MODELLING (cont.)
16. What is the difference between an orchestration and choreography process descriptions?
17. What patterns for process activity instances do you know? (sequence, loop, split, join, multi-merge, etc.).
18. Describe an evolution of BPM modelling techniques (traditional vs. framework).
19. Describe the main process modelling techniques (Flow Chart, Data Flow Diagram, DFD, Role Activity Diagram
Role Interaction Diagram RID, Gantt Chart, IDEF, WorkFlow).
20. What are the elements of BPMN (BPMN 2.0) notation in BPM modelling? Build a simple multi-pool and multi-
lane process map with application of BPMN notation (e.g. service system, production line).
21. What are the elements of EPC notation in BPM modelling? Build a simple process diagram with application of
EPC (eEPC) notation (e.g. service system, production line).
22. What UML models are developed in BPM modelling?
23. What BPM architectures, frameworks and reference models do you know and what are their main elements
(Zachman, CIMOSA, GRAI, ARIS, IDEF)?
24. What are the IDEF family technologies for business process modelling?
25. What is the ARIS concept and method for business (business process) modelling?
26. Describe dimensions (views and lifecycles) in ARIS House, ARIS HOBE and ARIS Business Process Excellence.
27. What is a structure of basic (most popular) models developed in ARIS method and tools (Organizational
Chart, Function Tree, Function Allocation Diagram, EPC Diagram, eEPC Diagram, Value-Added Chain
Diagram, Industrial Process Diagram, Product/Service Tree, Event Diagram, Information Flow Diagram)?
28. What basic functions and operations are performed during a modelling session with ARIS Toolset/ARIS Easy
Design/ARIS Platform (ARIS Express) software?
29. What is a concept of iGrafx Process for Six Sigma method of modelling?
30. What basic functions and operations are in modelling session with iGrafx Process for Six Sigma software?
• SIMULATION IN BUSINESS MODELLING (continuous simulation, discrete simulation,
games)
31. What are the basic advantages and disadvantages of business simulation?
32. What are the purposes and stages of business simulation modelling?
33. What are the assumptions of System Dynamics (SD) method of modelling?
34. What is a definition of SD method and what are the basic elements of SD models?
35. Explain the feedback loop and relation between its polarity and behaviour.
36. Build a simple model of a system with 1st or 2nd order positive and/or negative feedback loop (e.g. business
development, financial system, production-inventory control).
37. Explain the numerical problems (DT time step, integration) in SD simulation modelling.
38. What are the basic functions of typical modern software for SD simulation modelling and what software
systems and languages do you know for such area?
39. Explain the meaning of SD simulation modelling in business systems’ modelling (Iceberg Model).
40. What is a difference between “continuous”, “discrete” and “hybrid” simulation?
41. What are the basic elements of discrete simulation models?
42. What methods of discrete simulation modelling do you know?
43. What are the common basic elements of discrete simulation modelling represented in different modelling
systems and languages?
44. What are the basic functions of typical modern software for discrete simulation modelling and what software
systems and languages do you know for such area?
45. Why do we need a ‘warm up’ period in discrete simulation runs?
• SIMULATION IN BUSINESS MODELLING (continuous simulation, discrete simulation,
games)
46. Build a simple simulation model of a discrete system with application of a discrete modelling language or
system (e.g. production line, service system, queuing system).
47. Give some examples of business simulation game taxonomies (classifications).
48. What activities are performed in simulation gaming runs?
49. What basic functions and operations are performed during a modelling session with VENSIM PLE software?
50. What basic functions and operations are performed during a modelling session with ARENA software?
• OPERATIONS RESEARCH IN BUSINESS MODELLING (forecasting, linear programming,
network programming)
51. What is a forecast and what are the functions of the forecasting?
52. What classifications and methods (models) of forecasting do you know?
53. What are the elements of any time series and what is a decomposition method in forecasting?
54. Explain the idea of time-series forecasting and explain the mechanisms of forecasting on some examples
(moving averages, simple exponential smoothing, and time-series linear trends).
55. Explain the idea of judgmental and analogy forecasting by analogy and give some examples.
56. Give examples of measuring forecast errors that are commonly used in practice.
57. What is a general description of a LP (linear programming) model?
58. Formulate a LP (linear programming) model for a specific decision making situation (example).
59. What is a general description of a network (network programming) model?
60. Formulate a network (network programming) model for a specific decision making situation (example).
Grading system - assessment
MARKS:
• Excellent (≥ 90%): 5.5 (Celujący),
• Very Good (≥ 80%): 5.0 (Bardzo dobry),
• Good+ (≥ 70%): 4.5 (Ponad dobry),
• Good (≥ 60%): 4.0 (Dobry),
• Sufficient+ (≥ 50%): 3.5 (Ponad dostateczny),
• Sufficient (≥ 40%): 3.0 (Dostateczny),
• Fail (< 40%): 2.0 (Niedostateczny).
Lecture 1-2
BUSINESS MODELLING
BUSINESS AND MANAGEMENT
AN INTRODUCTION
Business model
A course concept
Business as Business Model Business as an

an interest organisation
Strategy,
vision, mission Any model to
in business support
business
Key Key
Value
partners activities …
Relations
Key Customers
with
resources segments
customers
Channels Cost Income

structure streams
Business modelling mind map
Business
Modelling
Domain
Modelling
Strategy Business
Implementation
Classes Methodology
Structure ICT
Mental support
Procedures
Functions Theories
MS ABM
Symbolic SSM
Processes
Physical
VAC BPM OR
Results
Graph
AI
Org. Graphical Formal

Str. Analogue
Architectures
Frameworks
VSM EPC OR
IDEF Sim
BPMN
Demand for improved business
management
• Improving business effectiveness and customer service
– Bringing new products to market, and reducing cost inefficiencies all push
business processes and their effective management to the top of the priority list.
• Leveraging the assets
– Increasingly, firms are looking for a different way of improving business
processes, avoiding investment in large, expensive, and risky new application
projects that have so often led to disappointment. Instead, they want to
leverage the existing assets and investment and concentrate their efforts on the
automation of processes across those assets.
• Increasing the capability of IT
– After several years of heavy investment in technology, many organisations
question the capability of IT functions, and the technology vendors and
consultants that support them, to deliver the benefits they promise. They are
wary of investing more in IT, yet place greater demands on IT, and expect IT to
respond faster. The demand for new or improved business processes drives these
requirements.
• Process automation and integration
– One aspect of the response to these pressures on IT has been a change in the way
that organisations are looking to approach process automation and integration.
Role of IT and modelling in business
management
The many roles of IT and modelling in business
management improvement
(Source: Davenport …)
• Automating: Automate a process;

• Informational: Captures process information for
purposes of understanding;
• Sequential: Changes process sequence or enables
parallelism;
• Tracking: Closely monitors business status and objects;
• Analytical: Improves analysis of information and decision
making;
• Geographical: Coordinates processes across distances;
• Integrative: Coordinates tasks and processes;
• Intellectual: Captures know how;
• Disintermediating: Eliminates intermediaries from a
process.
Business model – ways of
understanding
• There are many ways of business model defining and comprehensions.
Business model is usually defined as a general framework to develop
different variants of business activity and as a tool to evaluate efficiency,
and effectiveness of these variants.
• As a simplification of the real (or hypothetical) business activity, business
model is basically a composition of necessary fundamental business
“streams” – values for business actors (partners, customers), financial
incomes, business logistics (structure, technology, management), and must
be differentiated from only a business strategy.
• Some definitions of business model identify the following elements:
mission, structure, processes, incomes, legal aspects, and technology.
Dimensions of business model describe basic choices and decisions, which
must be made in any business activities, particularly in a strategic context
of functioning. These business dimensions include: customers (market
segmentation), income and profit (value creation), business strategy
(differentiation, competence advantage), business domain and structure
(type of products and services, value chain, logistics chain).
understanding
• The term „business model” was introduced for the first time in
1957 by R. Bellman and C. Clark, then by G. Jones in 1960. (see:
Osterwalder A., Pigneur Y., Tucci C.L., Clarifying Business Models: Origins, Present, and Future of the Concept,
Communications of the Association for Information Systems, vol. 15, 2005, p. 4)
• Basic contexts of „business model” concept are: basic assumptions

for a business as an activity, a business activity logic – an activity
pattern, a way to choose business basic resources, a scope and
character of internal and external business relations, or main cause-
effect relations between business model elements.
• Business means an interest, a venture, an enterprise or economic
activity. Also in a large sense it is a transactional system – an
organisation to exchange values between system participants and to
fulfil needs and expectations.
• Remark: there is a problem to find a clear difference between
business model and strategy (business strategy).
understanding
• Business model is a term (still not so clear and ill-defined term) to
refer to how a business aims to operate and make money in a given
market. Although this term is not related directly to BPM (business
process management) modelling, a detailed business model might
typically contain descriptions of basic business processes implied or
necessary for the model to operate.
• Business architecture is a term basically referring to the structure
of a business and it contains management program (e.g. tools for
resource planning and allocation, policy standardising, decision
making support, life-cycle approach), and documenting methods
(e.g. application of frameworks in modelling, as-is analysis, to-be
design, implementation process).
• Business reference model is a key (usually computerised and
diagrammatic) to understanding and using business architecture
model. It presents core structural elements as fixed or to modify.
understanding
• Differences between business models and strategies:
– Definitions and concept evolutions;
– Abstraction level: high (business model), low (business strategy);
– Levels (layers) in organisational hierarchy;
– Business scale: small (no real difference), large (many business models);
– Means for value creation (business model) and keeping competitive advantage
(business strategy);
– Financial sources and importance to investors (business strategy);
– Knowledge and competence limits (business model).
• Assumptions for capability creating organisation concept to change
business models:
– Find an asymmetry between organisation (business) and environment;
– Identify potentials and use unique resources and competencies;
– Design goal oriented configurations of resources;
– Take advantage from new chances appearing in environment.
understanding
• Business model vs. business strategy – a comparison
Criteria Strategy Business Model
Elements (Construction) In classic approach it contains: the goals of the Complex construction. Depends on the approach
company, the measures (tools) of their it can contain diversified set of elements
realization. It can contain information containing both internal and external
concerning the ways of achieving competitive environment of the company as well as partners,
advantage, behaviours in regard to competitive the elements of value chain etc., and
companies, the mission, the vision, etc. competitive strategy.
Postulated Matching to other elements of the company as Matching in internal and external aspect,
well as the situation in given sector. individual elements should be coherent, support
characteristics each other mutually. Innovativeness, durability.
Formulation process More often by acting that has analytical nature More often by acting that has intuitive nature,
based on rational premises, information, reports highlighting the meaning of learning, experience
etc. The continual learning of the company and etc. Iterative nature of process.
its members is essential as well as basing on
experience. Iterative nature of process.
Formalization The effect is often a formal document. The effect has no formalized nature, eventually
some elements are formalized.
Level of analysis The level of the whole organisation (e.g. The business model spans whole organisation
company). (e.g. company) and the strategy (most of all the
competitive strategies) in many concepts of
business model is its part.
Value creation/gaining Pressure on gaining competitive advantage in a Pressure on creating value and its generating as
given sector. well as the profit protection.
competitive advantage
understanding
• Factors to design, develop and implement effective business models:
– Offering unique values to buyers (e.g. new ideas, combinations of product/service
attributes);
– Increase of a relations „utility value – cost of the value”;
– Business model reuse by competitors difficulty (imitation difficulty);
– Realistic assumptions for business model design, development and implementation (e.g.
buyers’ behaviour analysis, financial expenditures calculation, profit centre identification);
– Systems approach to design, development and implementation of business model.
• Suggestions to change business models:
– Step-by-step extension of business model scope (e.g. new market segments, new products) in
a business domain;
– Modification or development of new business models based on new competencies, unique
resources or new business domains;
– Extension of business models by an introduction of additional activities to increase
competitive advantage;
– Changes in value structure of offer to buyers;
– Development of new business models due to join business alliances or business fusions;
– Radical business model change due to new assumptions and strategies.
understanding
• Canvas model – a structure for more innovative business
model design (a concept by A. Osterwalder)
Source: http://businessmodelgeneration.com/canvas
understanding
• Taking strategic level of business description (input vs. output), we
can identify the following strategic business models:
– Strategic financial model (I: resources and sale, O: profit and capital);
– Strategic response model (I : resources and profit, O: sale and capital);
– Strategic enterprise model (I: resources and capital, O: sale and profit);
– Strategic firm model (I: sale and profit, O: output and capital);
– Strategic innovation model (I: profit and capital, O: resources and sale);
• Considering ownership and landlord rights, intermediary brokers,
and business resources, we can identify variants of 4-element
business models based on the following elements:
– Creators (entrepreneur, manufacturer, inventor, human creator);
– Distributors (financial trader, wholesaler/retailer, intellectual property trader,
human distributor);
– Landlords (financial, physical, intellectual, attractor-contractor);
– Brokers (financial, physical, intellectual property, human resource).
understanding
• Considering a type of business activity to create a profit and a
“price – customer value” relation, we can identify the following 8-
variant business models:
– Price models (buying club, “one-stop” low price shopping, under the umbrella pricing, free
for advertising, “razor and blade”);
– Convenience models (“one-stop” convenient shopping, instant gratification, comprehensive
offering);
– Experience models (experience selling, experience destination, “cool” brands);
– Commodity models (low price reliable commodity, reliable commodity operations, branded
reliable commodity, mass-customized commodity, service-wrapped commodity);
– Chain models (channel maximization, “cat-daddy” selling, quality selling, value-added
reseller);
– Intermediary models (market aggregation, multi-party market aggregation, open-market
making, exclusive market making, transaction service and exchange intermediation);
– Trust models (trusted operation, trusted solution, trusted advisor, trusted product
leadership, de facto standard, trusted service leadership);
– Innovation models (incomparable products, incomparable service, breakthrough markets).
understanding
• Considering versatility of business activity to create a profit we can
identify the following 11-variant business models:
– Profit by customer service improvement;
– Profit by product/service pyramid;
– Profit by multi-element approach;
– Profit by complex service;
– Profit by innovation;
– Profit by „super-production” (high B+R cost, short cycle time);
– Profit by multiplication;
– Profit by specialisation;
– Profit by user-oriented supporting service;
– Profit by standardising;
– Profit by branding, value chain, leadership, etc.
understanding
• Considering value to customer, resources and competencies, supply chain
structure, and income sources we can identify the following 6-variant
normative business models*:
– Traditionalist (material value and utility-cost relations; financial abilities; design, manufacturing, sale,
transactional link, passive role in supply chain; manufacturing and service delivery );
– Market player (material and emotional value, transactional cycle, relations to final customer;
infrastructure, financial abilities, branding, advanced technology, management competencies, market
knowledge; design, manufacturing, marketing, sale, partnership, coordination in supply chain; manufacturing
and service delivery, other then sale forms of product/service delivery );
– Production or Service to Order (material value and utility-cost relations; infrastructure;
manufacturing, transactional link, passive role in supply chain; manufacturing and service delivery );
– Specialist (material and emotional value, transactional cycle, relations to final customer; branding,
advanced technology, management competencies, market knowledge; design, manufacturing, marketing,
partnership; manufacturing and service delivery, other then sale forms of product/service delivery );
– Distributor – Intermediary Actor (transactional cycle, utility-cost relations; market knowledge; sale,
transactional link; commercial intermediary);
– Integrator (material and emotional value, relations to final customer; branding, management
competencies, market knowledge; design, marketing, sale, partnership, coordination; commercial
intermediary, other then sale forms of product/service delivery).
*See: Gołębiowski T., Dudzik T.M., Lewandowska M., Witek-Hajduk M., Modele biznesu polskich przedsiębiorstw, Wyd. SGH
Warszawa, Warszawa 2008, pp. 82-93).
E-Business model – ways of
understanding
• Classifications of e-business models take into account the following
criteria: product configuration, services, information flow, business
actors, actors’ roles, actors’ values, income sources, level of
integration, level of control, and business location in value chain.
• For example, mixing some of these criteria, e-business models can
be classified into the following types:
– e-shop, e-procurement, e-auction, e-mall, virtual community, collaboration
platform, third-party marketplace, value chain integrator, value chain service
provider, information brokerage, trust and other third-party services.
• Considering levels of control and integration, e-business models
can be classified into:
– agora, aggregation, value chain, alliance, and distribution network.
E-Business model – ways of
understanding
• The business location in value chain classification divides e-business
models into:
– brokerage model, advertising model, information intermediary model,
manufacturer direct model, affiliate model, community model, subscription
model, and utility model.
• In the other proposal of e-business models classification with the
same criterion (location in value chain) there are following types of
models:
– content provider, direct to customer, full-service provider, intermediary, shared
infrastructure, value net integrator, virtual community, and whole-of-
enterprise/government.
Business modelling vs.
Business process modelling
• The main •
design decisions
Business to be represented
modelling vs. in a
business model are:
– who areBusiness process
the value adding modelling
business actors involved;
– what are the offerings of which actors to which other
actors;
– what are the elements of offerings;
– what value-creating or adding activities are
producing and consuming these offerings;
– which value-creating or adding activities are
performed by which actors.
Business modelling vs.
Business process modelling
• A business process model typically shows the
following design decisions:
– who are the actors involved in the operations;
– which operational activities can be distinguished;
– which activities are executed by which actors;
– what are the inputs and outputs of activities;
– what is the sequence of activities to be carried out
for a specific case;
– which activities can be carried out in parallel for a
specific case.
BM vs. BPM modelling
Lifecycle
Concept Discovery
generation & Analysis Process
Identification
As Is
Preparations Scaling Process Process Process

Points of Monitoring Analysis
View Discovery
To Be
Verification Prototyping Process Process

Implementation Redesign
BM Lifecycle BPMM Lifecycle

Philosophy in modelling
• Abstraction (leaving out certain features while
interpreting);
• Idealisation (models always claim an ideal finish, but
“ideal” rarely exists in reality);
• Pragmatism (orientation by the useful through questions
“For who?”, “Why?” and “What for?”);
• Model Platonism (models are not universally usable,
therefore can’t be always right, defining the
circumstances in advance is crucial).
Philosophy in modelling
• Rationalism - our mind is able to recognise the objective structure
of a truth by following pure reason (rationality) or intuition;
• Empiricism - all ideas come to us through experience (through the 5
senses or through sensations like pain and pleasure)  knowledge is
based on or derived from experience, logical positivism to connect
experience with rationalism (maths);
• Constructivism - reality is independent of human thought, but
meaning or knowledge is always a human construction, there is
no single valid methodology;
• Positivism - opposite of constructivism,
knowledge is obtained by interpreting
positive results, successful
experiments;
• ….
MODELS and MODELLING
• A noun
The word "model" implies representation. The architect might represent a proposed building with a scale model.
• An adjective
The word "model" may also be used as an adjective. This use of word carries with it an implication of ideal. Thus, a
man may be referred to as a model husband or a child or a student.
• A verb
Finally, the same word may be used as a verb, as in the case of woman employed to model clothes. Here the verb
"to demonstrate" could have been used.
• Models can be classified as:

– physical,
– schematic (graphical),
– mathematical.
• A mathematical model employs the language of mathematics and, like other models, may be a
description and also an explanation of the system it represents. Although its symbols may be more
difficult to comprehend than verbal symbols, they do provide a much higher degree of abstraction
and precision in their application.
• Dynamic models in economics and business already have a rich tradition, and the field is still full
of activity. New developments are spurred by the general availability of considerable
computational power allowing the analysis of a large variety of complex models, by the
abundance of data in particular in financial applications, and by developments in neighbouring
fields of research, such as economic and financial theory and the theory of dynamic systems.
Model – 3 characteristics
• Representation
– Models are representations of something else
• Simplification
– Models possess a reductive trait in that they map a subset of
attributes of the phenomenon being modelled
• Pragmatic orientation
– Models have a substitutive function in that they substitute a
certain phenomenon as being conceptualised by a certain subject
in a given temporal space with a certain incentive or operation in
mind
Domains to study
• Strategic management
• Business process management (BPM)
• Business process reengineering (BPR)
• Business information systems (BIS)
• Simulation modelling
• Systems thinking and organizational learning
• Operations research (OR/MS)
• Quantitative methods in management
Business Modelling
Neighbouring Domains
BASIC METHODS OF MODELLING:

• OPERATIONS RESEARCH (OR/MS)
• DECISION MAKING
• QUANTITATIVE MODELLING AND ANALYSIS
• FORECASTING
• ECONOMETRICS
• SYSTEM, STRUCTURE AND OBJECT ORIENTED APPROACHES
• VISIBLE (VISUAL) THINKING
• SIMULATION
• RISK ANALYSIS
• MACRO- AND MICROECONOMICS
• ACCOUNTING AND FINANCIAL ANALYSIS
• ARTIFICIAL INTELLIGENCE
• AGENT BASED TECHNOLOGY
Business Modelling
Neighbouring Domains
BASIC TOOLS OF MODELLING:

• STATISTICS
• PROBABILITY CALCULUS
• DERIVATION AND INTEGRATION CALCULUS
• NUMERICAL CALCULATIONS
• FEED BACK (CAUSE-EFFECT) ANALYSIS
• GRAPH ANALYSIS & DIAGRAMMING
• SEMANTIC ANALYSIS
Business models – contents
• Visions and mission
• History and tradition
• Organisational structure
• Management system
• Process
• Knowledge and intellectual capital
• Techniques and technologies
• Staff
• Organisational culture
• Resources
• Relations chains and networks
Business models design - principles
• Holistic approaches
• No borders
• Free, unlimited process flow
• Short product/service life cycles
• Non-linearity
• Non-continuity (rather event approaches)
• Rapid fluctuations
• New visions and ideas
Business modelling purposes
• Facilitate human understanding and communication
• Facilitate business reuse and repeatability
• Support of business analysis and improvement
• Support business management (business status)
• A basis to automate business agents coordination and
guidance
• A basis to automate execution support of the business
run (automation of repetitive and non interactive steps)
Why model?
1. Explain (very distinct from predict)
2. Guide data collection
3. Illuminate core dynamics and/or suggest dynamical analogies
4. Reveal the apparently simple (complex) to be complex (simple)
5. Discover new questions and promote a scientific habit of mind
6. Illuminate core uncertainties and crisis options in near-real time
7. Demonstrate trade-offs / suggest efficiencies
8. Challenge the robustness of prevailing theory through perturbations
9. Expose prevailing wisdom as incompatible with available data
10.Discipline the policy dialogue
11.Train practitioners
12.Educate the general public
Business/Enterprise modelling goals
• Developing the business

– Developing visions and strategies
– Designing/redesigning business
– Developing information systems
• Ensuring the quality of the business
– Maintaining and sharing the knowledge
– Ensuring the acceptance of decisions
Business models in Business Plan
• A business plan provides direction, keeping on track and requirement.
Depending on a business type, the plan could include the following sections:
– Title page - describes what the plan is for and includes general information on the business.
– Business Summary - A one-page overview written after the business plan is finalised.
– About the business – as a management plan or operations plan it covers details about the
business including structure, registrations, location and premises, staff, and
products/services. Examples of models: organisational structure, product/service trees.
– About the market - This is the marketing plan. It should outline marketing analysis of the
industry to enter, customers and competitors. This section should also cover the key
marketing targets and strategies for delivering on these targets. Examples of models:
SWOT/TOWS analysis, supply chain models, pricing models, risk models, competition models.
– About the future - This section covers plans for the future and can include a vision
statement, business goals and key business milestones. Examples of models: business strategy
and vision, sales forecasts models, five-year profit projection, function and process models.
– About finances - The financial plan includes description of ways to finance the business,
costing and financial projections. Examples of models: financial models, break-even analysis,
operational plan models.
– Supporting documentation - List of all attachments under this heading in the plan for
referral. For example: copies of emergency procedures, maps, resumes, or financial tables.
Business modelling cognitive goals
• Forecasting
Determination of quantitative and qualitative characteristics of
system's functioning in pre-defined conditions. Known: input,
transformation function. Unknown: output.
• Identification
Determination of quantitative and qualitative principles and rules of
system's functioning. Known: input, output. Unknown:
transformation function.
• Rationalisation (Optimisation)
Determination of system's functioning conditions, in which
quantitative and qualitative characteristics fulfil rational (optimal)
criteria. Known: output, transformation function. Unknown: input
Input Output
F
Transformation
Business types
• Businesses can have the following types:
– manufacturing/production businesses: flow from raw material
to final consumer products (e.g. manufacturer, logistic
operator),
– commercial businesses (e.g. wholesaler, distributor, retailer),
– service businesses (e.g. communications, transport, utilities,
hospitality and health),
– non-profit organisations (e.g. local authority, government).
Business environment
• All the businesses function within an environment, which
influences the business functioning and process
performance. Some elements of the environment are:
– economic situation and regulation,
– legal factors,
– cultural factors,
– competitive factors,
– global scale influence on goods and services,
– global scale logistics and co-operation.
Types of business models
• Data models
– represent and relate business information
• Structure models
– represent ontology of entities in business system
• Process models
– represent flow of activity in business processes
• Work-flow models
– represent the sequence of human activities required to carry out
business processes
• Financial models
– used to project the consequences of various decisions and external
influences on the financial status of organizations
• Simulation models
– used to represent dynamic states of the entities in an organization
Business modelling methods &
techniques
Types of models
• Time criterion:
– Static modelling
– Dynamic modelling
• Uncertainty criterion:
– Deterministic modelling
– Stochastic modelling
Types of dynamic models
• Continuous
Changing in system's states has a continuous nature (continuous
function). Time lapse: continuous function or quasi-continuous
function.
• Discrete
Changing in system's states has a discrete nature (discrete function).
Time lapse: discrete function (from event to event).
• Hybrid
Changing in system's states has a continuous and discrete nature
(continuous and discrete function). Time lapse: continuous function
or quasi-continuous function or discrete function.
Architectures and frameworks
ARIS House
Zachman Framework
What? How? Where? Who? When? Why?

TM
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why
Scope
Planner SCOPE List of Things Important
to the Business
List of Processes the
Business Performs
List of Locations in which
the Business Operates
List of Organizations
Important to the Business
List of Events Significant
to the Business
List of Business Goals/Strat
SCOPE (contextual)
(CONTEXTUAL) (CONTEXTUAL)
Enterprise model
Planner ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/ Planner
Business Thing Business Process People = Major Organizations Time = Major Business Event Critical Success Factor
Location
Owner ENTERPRISE
e.g. Semantic Model e.g. Business Process Model e.g. Logistics Network e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE
MODEL
MODEL
(CONCEPTUAL) (CONCEPTUAL)
(conceptual)
Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Owner
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
e.g. Logical Data Model e.g. "Application Architecture" e.g. "Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
SYSTEM
SYSTEM
MODEL
Architecture" Architecture
MODEL
(LOGICAL) System model
Designer (LOGICAL)
Designer
Ent = Data Entity Proc .= Application Function
Node = I/S Function
(Processor, Storage, etc) People = Role Time = System Event
Cycle = Processing Cycle
End = Structural Assertion Designer
(logical)
Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Means =Action Assertion
e.g. Physical Data Model e.g. "System Design" e.g. "System Architecture" e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY
TECHNOLOGY
MODEL CONSTRAINED
(PHYSICAL) MODEL
(PHYSICAL)
Builder Node = Hardware/System

Technology model
Builder Ent = Segment/Table/etc. Proc.= Computer Function Time = Execute End = Condition Builder
(physical)
Software People = User
Reln = Pointer/Key/etc. I/O = Screen/Device Formats Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action
e.g. Data Definition e.g. "Program" e.g. "Network Architecture" e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
DETAILED
REPRESEN- REPRESEN-
TATIONS TATIONS
(OUT-OF- (OUT-OF
CONTEXT) CONTEXT)
Sub- Sub-
Contractor Ent = Field
Reln = Address
Proc.= Language Stmt
I/O = Control Block
Node = Addresses
Link = Protocols
People = Identity
Work = Job
Time = Interrupt
Cycle = Machine Cycle
End = Sub-condition
Means = Step
Sub-
Contractor Detailed
contractor FUNCTIONING
ENTERPRISE
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
FUNCTIONING
ENTERPRISE
representations
Zachman Institute for Framework Advancement - (810) 231-0531 Copyright - John A. Zachman, Zachman International
(out of context)
Data Function Network People Time Motivation
BUSINESS MODELS
(An Overview of models)
BUSINESS MODELS
(An Overview of models)
BUSINESS MODELS
(SADT syntax)
CO NTROL
INPUT ACTIVITY OUTPUT
page # LABEL
MECHANISM
BUSINESS MODELS
(IDEF model)
BUSINESS MODELS
(IDEF model)
BUSINESS MODELS
(FC - Flow Chart model)
BUSINESS MODELS
(DFD - Data Flow Diagram model)
BUSINESS MODELS
(RAD - Role Activity Diagram model)
BUSINESS MODELS
(RID – Role Interaction Diagram model)
BUSINESS MODELS
(Workflow model)
BUSINESS MODELS
(Product/Service tree model)
BUSINESS MODELS
(Function tree model)
BUSINESS MODELS
(EPC – Event driven Process Chain model)
BUSINESS MODELS
(BPMN – Collaboration Process Chain model)
Trackpoint Order
Trackpoints Trackpoint Notices Acceptance Certificate
Entries Log
more Trackpoints
Issue
Log Trackpoint
Trackpoint
Order Entry
Notice
Create
Acceptance
Certificate
Freight delivered
Initiate
Shipment
Status Inquiry
24 hours
BUSINESS MODELS
(BPMN – Collaboration Multi Pool Process Chain model)
BUSINESS MODELS
(VACD – Value Added Chain Diagram model)
BUSINESS MODELS
(VSM – Value Stream Mapping model)
BUSINESS MODELS
(Network programming model)
• Networks (e.g. Gantt Chart, PERT)

• Gantt Charts
– Useful for depicting simple processes (projects) or parts of large processes;
– Show start and completion dates for individual tasks;
– Visually shows duration, time overlap between tasks and slack time.
• PERT Charts
– PERT (Program Evaluation Review Technique);
– Show order of activities or dependencies between activities;
– Visually shows dependencies between tasks, tasks can be done in parallel and
slack time by data in rectangles.
BUSINESS MODELS
(Pareto / ABC classification)
100
Percentage of Dollars
80
60
40
20
0
0 10 20 30 40 50 60 70 80 90 100
Percentage of Items
BUSINESS MODELS
(SD – System Dynamics Stock-Flow model)
births material
Population & Food deaths pollution
mult tab birth rate normal death rate normal mult tab
birth rate normal 1 death rate normal 1 <pollution ratio>
<material
standard of switch time 1 switch time 3
living> <Time> <Time>
Population
births material multiplier births deaths
deaths pollution multiplier
births pollution multiplier
deaths material multiplier
population initial
births births food multiplier
pollution deaths deaths food multiplier
mult tab crowding crowding
births crowding
multiplier
multiplier
deaths
births food land area material
mult tab births <food deaths mult tab
crowding population crowding crowding
mult tab density normal mult tab> deaths food <material standard of
<pollution ratio> mult tab
mult tab living>
food crowding multiplier capital agriculture

food ratio fraction indicated tab
food pollution
multiplier
food capital agriculture fraction indicated
pollution <Time>
mult tab food per capita potential
switch time 7 <capital ratio agriculture>
food coefficient food per food per capita
food coefficient 1 capita normal potential tab
BUSINESS MODELS
(Cobb-Douglass Production functions model)
Deterministic Cobb-Douglass production function
a 1-a
Q  AK L
Q - production output, K - capital, L – labour, A, a - parameters (A>0, 0<a<1)
Stochastic Cobb-Douglass production function
a 1-a u
Q  AK L e
u - random variable.
BUSINESS MODELS
(Econometric linear model)
General Linear Model (GLM) with stochastic variable

n
y   bi  xi  u
i 0
y - dependent variable of interest,
xi – non-stochastic observable variable,
bi - fixed and known constant,
u - unobservable random variable.
BUSINESS MODELS
(OR/MS - EOQ decision model)
Inventory I(t)
I(t)=Q-D·t
Annual Cost
Q Total Costs Carrying
Cost
Average
inventory
Q/2
0 Order/Set-up Cost
T=Q/D Time t

Size of Order Quantity
TCT (Q)  c h  I (t )dt  P  Q  co  c h  (Q  T  D  T 2 / 2)  P  Q  co
0
TC (Q) 
D
Q
    c  D ch  Q
 c h  Q  T  D  T 2 / 2  P  Q  co  P  D  o
Q

2
dTC (Q) c D c
 o 2  h 0
dQ Q 2
2  co  D
EOQ  TC EOQ   2  D  c o  c h  P  D
ch
Lecture 3-5
BUSINESS PROCESS MANAGEMENT
BUSINESS PROCESS, BPM TECHNOLOGY, BPM PRINCIPLES,
BPM STANDARDS, ARCHITECTURES
Business process
• Basic definitions:
– A set of logically related tasks performed to achieve a defined business outcome
(Davenport and Short, 1990);
– The logical organization of people, materials, energy, equipment and procedures
into which activities are designed to produce a specified end result - work
product (Pall, 1987);
– It implies a strong emphasis on how work is done within an organization, in
contrast to a product focus’ emphasis on what. A process is thus a specific
ordering of work activities across time and place, with a beginning and an end,
and clearly identified inputs and outputs: a structure for action (Davenport, 1993);
– A collection of activities that take one or more kinds of input and creates an
output that is of value to the customer (Hammer & Champy, 1993);
– A related group of steps or activities in which people use information and other
resources to create value for internal or external customers. The steps are
related in time and place, have a beginning and an end, and have inputs and
outputs (Alter, 2002).
Business process
• Some other modern definitions:
– A business process is the complete and dynamically coordinated set of
collaborative and transactional activities that deliver value to customer (Smith &
Fingar, Business Process Management: The Third Wave, 2003);
– A process is a coherent set of activities carried out by a collaborating set of roles
to achieve a goal (Ould, Business Process Management: A Rigorous Approach, 2005).
– A business process consists of a set of activities that are performed in
coordination in an organizational and technical environment. These activities
jointly realize a business goal. Each business process is enacted by a single
organization, but it may interact with business processes performed by other
organizations (Weske, Business Process Management: Concepts, Languages, Architectures, 2007).
Business process elements
• A business process has:
• goals (may be conflicting),
• specific inputs,
• outputs (products or services),
– ”… there is no product or services without a process; and no process
without a product or service …” (Harrington, 1991),
• activities and tasks,
• resources,
• triggering events,
• participants,
• documents/information,
• an architecture and boundaries,
• customers and value for customers.
There are hundreds of business processes ...
Processes in business
(basic vs. supporting processes)
• Basic processes
– Market research and analysis, customer requirements analysis
– New customer searching
– R&D for products and services
– Manufacturing and logistics
– Sale and invoicing
• Supporting processes
– HRM and staff development
– IT and strategy management
– Financial management
– Resource management
– Change and improvement management
(other classifications)
• Classification #1 of business processes:

– Core (primary) business processes
• Inbound logistics (inventory control, vehicle scheduling, returns)
• Outbound logistics (collecting, order processing, delivery operation,
scheduling)
• Operations (machining, packaging, assembly)
• Marketing and sales (advertising, promotion, quoting)
• Service (installation, repair, training)
– Support business processes
• Cost and results accounting control, financial accounting
• Information management
• Information and coordination processes

– Value-Adding (VA) business processes
– Non Value-Adding (NVA) business processes
(other classifications)

– Primary processes
• produce the company’s products or services.
– Secondary processes
• purchase and maintenance of machinery, vehicles, and premises,
• personnel rolls, dismissal, financial administration.
– Tertiary processes:
• the managerial processes that direct and coordinate the primary and
secondary process.
(Value Chain)
Value Activities
Firm Infrastructure M
A
Support Human resource management R
Activities Technology development
G
I
Procurement N
S
M
A
Inbound Operations Outbound Marketing Service R
logistics logistics & sales G
I
N
S
Primary Activities
Porter's Generic Value Chain.
(Value Chain)
• VALUE CHAINS
– Value chains are tools for determining a company's competitive
advantage.
– Every firm is a collection of activities that range from:
• Design,
• Marketing,
• Production, Delivery and Support.
– Value chains break these down to strategically relevant
categories. Everything a company does can be fit into primary
and support activities.
– Those activities that contribute best to a firm's competitive
advantage are categorised - a value chain is defined.
– An organisational structure is created around those activities
that can most improve a companies competitive advantage.
Value Stream Mapping
• A simple, visual approach to:
– Focusing on a “product family”.
– Creating a clear picture of current material and information flow
associated with that product family.
– Identifying Lean tools and techniques that can improve flow and
eliminate waste.
– Incorporating those ideas in a new picture of how material and
information “should” flow for that product group.
– Creating an action plan that makes the new picture a reality for
that product family.
• Value stream mapping is a paper and pencil tool that
helps to see and understand the flow of material and
information as a product or service makes its way
through the value stream. Value stream mapping is
typically used in Lean, it differs from the process
mapping of Six Sigma in four ways:
– It gathers and displays a far broader range of information than a
typical process map;
– It tends to be at a higher level (5-10 boxes) than many process
maps;
– It tends to be used at a broader level, i.e. from receiving of raw
material to delivery of finished goods;
– It tends to be used to identify where to focus future projects,
subprojects, and/or kaizen events.
• A value stream map takes into account not only the activity of the
product, but the management and information systems that support
the basic process. This is especially helpful when working to reduce
cycle time, because it gives insight into the decision making flow in
addition to the process flow. It is actually a Lean tool.
• It helps to visualize more than just the single-process level, i.e.
assembly, welding, etc. it helps to see more than waste.
• It helps to see the sources of waste in the value stream, it provides a
common language for talking about manufacturing processes, it
makes decisions about the flow apparent, so it allows to discuss
them.
• It forms the basis of an implementation plan, it shows the linkage
between the information flow and the material flow.
• It is much more useful than quantitative tools and layout diagrams
that produce a tally of non-value added steps, lead time, distance
travelled, the amount of inventory.
Business process and task
• A process
– A coordinated and standard flow of tasks.
– Conditions  determine the order of the tasks.
– Can traverse functional or departmental boundaries.
– Achieve business objectives that creates value for internal or
external customers.
• A task
– Logical unit of work that is carried out as a single whole by one
resource.
– Resource is the generic name for a person, machine, etc.
– A task can also be defined as a process that cannot be
subdivided any further: an atomic process.
Activities of business processes
• Business processes consist of activities and their coordinated
execution realizes some business goal. These activities can be:
– manual activities,
– user interaction activities,
– system activities.
• Manual activities are not supported by information systems.
– An example: sending a parcel to a business partner.
• User interaction activities go a step further: these are activities that
knowledge workers perform, using information systems. There is no physical
activity involved.
– An example: entering data on an insurance claim in a call centre environment. Since humans
use information systems to perform these activities, applications with appropriate user
interfaces need to be in place to allow effective work. These applications need to be
connected to back-end application systems that store the entered data and make it available
for future use.
• System activities do not involve a human user; they are executed by
information systems.
– An example: retrieving stock information from a stock broker application or checking the
balance of a bank account. It is assumed that the actual parameters required for the
invocation are available. If a human user provides this information, then it is a user
interaction activity. Both types of activities require access to the respective software
systems.
Functions vs. processes
Customer
support
R&D
Production
Marketing
Customers
Cross-functional process and
markets
Functional vs. process management
Mission/Vision
Billing Customer
Product Development Customer Strategic

Plan
Customer
Distribution
Key business
Board of objectives
Directors
Functional Objectives
Functional structure & the silo effect
• The functional structure
– Typical organizational structure where functions operate independently of each other
– Each function is responsible for a set of closely related activities
– Business processes (BPs) are cross-functional / cross-organizational
• The silo effect (consequence of functional structure)
– Effective execution of BPs requires careful coordination between functions
– Coordination is achieved through exchange of relevant information among different functions
– Poor coordination causes delays: Communication between functions takes time
– Poor coordination causes lack of visibility across BPs: No information readily available on
status of the process and on how well it is performing over time
• Importance of Information Systems (IS)
– IS: Computer-based systems that capture, store and retrieve data related to process
activities
– Functional IS: Support individual departments (built independently of each other)
– Enterprise Systems: Support an entire BP (execute BP + capture and store process data +
monitor process performance
 Current BPR efforts: Restructure BP activities + Manage flow of data around the
process + Manage knowledge around the process
Functional structure & the silo effect
• Reasons “destructive” silos development:
– Lack of top management awareness and involvement
– Absence of cross-functional knowledge, processes, and tools
– Fear of sharing knowledge
– Misaligned metrics
– “I win – you lose” phenomenon
Basic functional activities
• Purchasing: Identify vendors + Select vendors + Create and send
purchase order + Evaluate vendor performance
• Warehousing (or inventory management): Receive goods from
vendor + Perform quality control on received goods + Prepare goods
to be returned to vendors + Prepare goods for shipment to customers
+ ship good to customers + received goods returned by customers
• Operations: Plan capacity + Schedule production + Execute
production + Perform quality controls
• Marketing & Sales: Identify customers + Manage relationships with
customers + Promote products and services + Receive customer
orders + Initiate processing of orders received + Provide after-sale
services
• Finance & Accounting: Process incoming payments + Process
outgoing payments + Manage cash flow + Manage capital needs +
Prepare financial statements
• Other functions: HR, IT, R&D
Functional structure
• Functional structure of organisation has many strengths and also
weaknesses. Some advantages and strengths of this structure are as
follows:
– strategic decisions are made at the top, facilitating a unity of direction as top management
provides coordination and control to the organisation and departments can be provided with
goals and objectives that will support the overall organisation strategy,
– efficient use of resources, particularly by having departments and units which share
common facilities or machinery in one place and by economies of scale each department is
able to serve other departments efficiently
– enhanced coordination within functions, as common backgrounds within department and
collegiality imply that members of the department are more likely to work as a team to
achieve the department’s goals,
– in-depth skill development, as department members have opportunities to specialize their
skill to a greater extend by sharing information and more intensive training due to the
similarity of knowledge,
– clear career paths, as employees have a clear understanding of job requirements and the
path leading to career promotion.
Functional structure
• However the functional structure has also some disadvantages and
weaknesses, e.g.:
– poor coordination across functions, as members of each department are isolated towards
other departments it implies that members of the department are more resistant to support
or compromise with other departments to achieve the overall organisational goals,
– slow decision making, because of senior managers overloading causing delays, and lowering
quality of decision making,
– performance responsibility unclear, as contribution of each department to the
organisational result (success or failure) is not easily understood even all departments
contribute to accomplishment of an organisational goal,
– less innovative, as employees become focused only on departmental goals rather than on
the overall organisational goals (local optimization) some new product/service ideas, new
methods and technologies suggestions are lost, particularly when an inter-departmental
coordination and communication is needed,
– limited inter-departmental management training, as extensive training and experience in
one department reduce opportunity for developing broader management.
Divisional structure
• Some advantages and strengths of the divisional structure are as follows:
– high customer satisfaction, as customers receive more attention under divisional structuring
and customer tailoring,
– high task coordination, as employees tend to identify more with the product than with
functional department and there is more communication and teamwork across departments,
– flexibility and adaptation to unstable environment, as relatively small division can adapt
more easily to changes and divisional managers can make specific decisions responding more
quickly to changes in the environment,
– clear performance responsibility, as each division can be made a profit centre with an
assignment of specific objectives to be met and top management can assess the performance
of each division separately,
– general management training, as divisional managers learn how to coordinate and control
activities among many departments within a division and also managers can be shifted to
different divisions to learn the various divisional attributes (e.g. product lines, customer and
geographic patterns).
Divisional structure
• Nevertheless in the function-oriented management with divisional structure
the strengths begin to offset the weaknesses of function atomization, there
are still some typical disadvantages, as follows:
– focus on division objectives, as coordination across divisions is often difficult and members
of a division become focused on the unit’s objectives with a direct competition between
divisions without possibility to optimize performance due to broader goals of the
organisation,
– inefficient use of resources, as there is a dispersion of resources across divisions and costs
become higher,
– loss of control, as divisions become radically different to be successfully managed by top
management by implementing rules and regulations or schedules across all divisions,
– low in-depth training, as decrease in the number of divisional personnel reduces the
opportunity to specialize the knowledge and develop skills by interactions.
Hybrid structure
• Some advantages and strengths of the hybrid structure are as follows:
– integration of goals with objectives, as hybrid structure provides autonomy for divisions to
modify their objectives with centralized functions serving to generate awareness of overall
organisation goals among divisions,
– efficiency and adaptability, as divisional units are able to adapt to the opportunities and
constraints with focusing on efficiency by functional departments,
– coordination, as centralized functions enable coordination across divisions by establishing
activities that direct each division toward a common purpose.
• Some weaknesses and disadvantages of the hybrid structure are as follows:
– conflict between top and divisional management, as functional departments in hybrid
structure do not have supervisory authority over divisions,
– slow response to some exceptional case situations, as in divisional units some unique
situations may happen and a resolution must be obtained from top management level which
leads to delays and inefficiencies,
– increase of administration overhead, as centralized functions have a tendency to grow in
order to control of divisions.
Matrix structure
• Some advantages and strengths of the matrix structure are the same as in
functional, divisional and hybrid structures and are as follows:
– provides flexibility, as teams can be created and dissolved quickly as a response to
environmental change,
– encourages resource efficiency and adaptability, as resources can be utilized efficiently by
assignment and rotating personnel through specialized work and projects,
– allows demands from environment to be met simultaneously, as teams can respond
promptly and efficiently to pressures for quality, multiple products and innovation,
– increases skill development, as employees can learn a variety of skills through involvement
in multiple work and projects,
– increases motivation and commitment, as decentralization and delegating of decision
making to the work or project level provides more opportunities for employees to contribute,
– increases quality of strategic management, as top management has more time for long-
range planning while day-to-day decisions are sent to matrix dimensions’ managers.
Matrix structure
• Unfortunately matrix structure is not a solution to all organisations. Some
weaknesses and disadvantages of the matrix structure are as follows:
– creates conflicts and dual authority confusion, as subordinates may receive contradictory
directives or instructions from and should report to many superiors (a violate of unity-of-
command, power struggles),
– requires large amount of time and increases delays, as management needs frequent
meetings to integrate activities,
– generates high implementation cost, as additional staff have to be involved and trained to
be successful in implementing a mature structure,
– requires interpersonal training, as the structure requires many interactions, communication
channel development, problem solving and team work.
New management
• Modern management paradigms lead us to new principles for
management, which should allow to:
– create the value, which is a basic social duty of the organisation,
– develop the quality, which is a fundamental competitive requirement,
– react on the environmental change and customers‘ expectations,
– be agile and flexible in communication and operations,
– be innovative by taking care new ideas, using the staff creativity,
– integrate technology in order to be competitive,
– work in a team by creating and developing decentralized multifunction
and multidisciplinary teams in organisation.
Reasons for BPM
• There are many reasons to change the organisation management vision to
process oriented one. For example it could be a case for process oriented
vision when:
– realized tasks do not relate to building the value of the firm,
– nobody manages or controls processes and nobody is responsible for it,
– there is a considerable level of bureaucracy (e.g. a complicated flow of
documents or the description of tasks), which makes difficult the efficient
performance of an organisation,
– many varied procedures and instruction exist, which implies knowledge
dispersion,
– nobody is able to co-ordinate the whole process, many persons are engaged in
processes, but this is not the work of one functional department or unit,
– processes which are divided into fragments and specialized structures are, as a
rule, not flexible enough to react on essential environmental changes,
– there is a lack of control of the process efficiency (by: costs, quality, time).
Functional vs. process management
6 basic process attributes
• Process cost
• Process time flow (an average time to complete)
• Process flexibility (agility)
• Process quality
• Process importance for the organisation
• Process importance for the customer
Process flexibility types
• Flexibility by design – for handling anticipated changes in the
operating environment, where supporting strategies can be defined
at design-time;
• Flexibility by deviation – for handling anticipated unforeseen
behaviour, where differences with the expected behaviour are
minimal;
• Flexibility by under-specification – for handling anticipated
changes in the operating environment, where strategies cannot be
defined at design-time, because the final strategy is not known in
advance or is not generally applicable;
• Flexibility by change – either for handling occasional unforeseen
behaviour, where differences require process adaptation, or for
handling permanent unforeseen behaviour.
Process Capability
• Process Stability and Capability

– Once a process is stable, the next emphasis is to ensure
that the process is capable.
– Process capability refers to the ability of a process to
produce a product that meets specifications.
– A process is capable if individual products consistently
meet specifications.
– A process is stable if only common variation is present in
the process.
– Six-sigma program such as those pioneered by Motorola
Corporation results in highly capable processes.
Six Sigma
• Modern quality programs have their roots in the 1950s in the U.S. and in
Japan where Walter Shewhart and W. Edwards Deming popularized
continuous process improvement as leading to quality production.
• Six Sigma is the practice of continuous improvement that follows methods
developed at Motorola and is based on the notion that no more than 3.4
defects per million are acceptable. This means that a company fulfilling one
million orders per year, and having only one error opportunity per order
with 3-sigma correctness (99.95%) will experience 66,738 errors versus a 6-
sigma (99.9997%) company, which would experience 3.4 errors. As
engineered product complexity has increased (in telecommunications, for
instance, the potential for over 50,000 errors per product are possible),
without the type of quality management provided through Six Sigma tenets,
virtually every product would experience some type of defect.
Six Sigma
Six Sigma
• Six-Sigma (6σ) Quality

– DPMO (Defects per Million Opportunities)
Sigma level DPMO Probability

2 308537 0,308537
3 66807 0,066807
4 6210 0,006210
5 233 0,000233
6 3,4 0,0000034
Six Sigma
• Six-Sigma (6σ) Quality

– DPMO – example
Stage Result Calculation Example
1 Process total result in units 1283
2 Process result without defects 1138
3 Process effectiveness Stage2/Stage1 0,8870
4 Process error indicator 1-Stage3 0,113
5 Process defects critical attributes N 24
6 Defects indicator per critical attribute (DPO) Stage4/Stage5 0,0047
7 DPMO Stage6*10^6 4700
8 Sigma level Normal 4,1

Process Control Charts
• Interpreting Control Charts
– The figures show different signals for concern that are sent by a control chart.
When a point is found to be outside of the control limits, we call this an “out of
control” situation. When a process is out of control, the variation is probably not
longer random.
Each point represents

Upper Control
data that are plotted
Limit (UCL)
sequentially
Center
Line (CL)
Lower Control
Limit (LCL)
Process Control Charts
• Control Chart Evidence for Investigation
Models and Tools of QM
• Design and improvement methodology
– „PDCA”= plan, do, check, act
– „DMAIC” = define, measure, analyze, improve, control
– „DMADV” = define, measure, analyze, design, verify
• Brainstorming (problem analysis)
• SIPOC (supplier, input, process, output, customer)
• Flowcharts (process)
• Pareto Charts (size of problem)
• Trend Charts (trend of problem )
• Cause-and-Effect, or Fishbone, Diagrams
• Tree Diagrams (process, cause and effect)
• ...
Business Process Management (BPM)
• „True Business Process Management is an amalgam of
traditional workflow and the 'new' BPM technology. It
then follows that as BPM is a natural extension of – and
not a separate technology to – Workflow, BPM is in fact
the merging of process technology covering 3 process
categories: interactions between (i) people-to-people;
(ii) systems-to-systems and (iii) systems-to-people –
all from a process-centric perspective. This is what true
BPM is all about.” [Jon Pyke, CTO Staffware]
Business Process Management
Issues in BPM
• However thinking in categories of processes can also have some barriers
and disadvantages, for example it limits:
– the possibility of integration of activities in team forms of work,
– shortening the information flow by taking advantage from hierarchic structures,
– transfer of decision authorizations to the direct places of doing the works,
– the development of workers’ innovations and broadening the competence
range,
– overcoming contradictions from the lack of conjunction between tasks,
authorizations and responsibility.
Evolution of BPM
BPM Milestones
Evolution of BPM
Evolution of BPM – other views
BPM Parents
Office Automation
(since 1980)
SOA Computer Supported Cooperative
(since 2000) Work / Groupware (since 1985)
Business Objects Workflow Systems

(since 2000) (since 1985)
Business
Process
Management
BPM (BPM)
(since 2000) Enterprise Application
Integration
(since 1995)
Process Modelling Business Reengineering

(since 1990) (since 1990)
Continuous Improvements
(since 1990)
BPM
Business Process
is defined in a (i.e. what is intended to happen) is managed by
Process Definition Workflow Management

(a representation of what is Systems
intended to happen) used to create
used to create & manage
& manage Process Instances
composed
of
include one or more
Activities
during execution
are represented by Activity Instances
which include
Manual Automated
Activities Activities Work Items Invoked Applications
(tasks allocated to a (tools used to
workflow participant) support activity)
BPM and BPM technology
• This new approach has been labelled business process management
(BPM), and is being addressed with a collection of technologies that
make up the BPM suite.
• BPM technology includes everything to design, enact, analyse, and
control operational business processes:
– Process Modelling and Design make it possible to quickly and rigorously define
processes that span value chains, and to orchestrate the roles and behaviours of
all necessary people, systems, and other resources.
– Integration allows to include any information system, control system, data
source, or other technology into business processes. Service-Oriented
Architecture (SOA) makes it faster and easier than ever before. Nothing of value
need be discarded; everything is reusable.
– Composite Application Frameworks allow to build and deploy fully-functional
web-based applications code-lessly and almost instantly.
– Execution directly turns models into real-world action, orchestrating processes
in real-time.
– Business Activity Monitoring tracks process performance as it’s happening,
monitoring many indicators, displaying key process metrics and trends, and
predicting future behaviours.
– Control allows to respond to process events based on circumstances, such as rule
changes, notifications, exceptions, and escalations.
Surveys in BPM
(see Roeser T., Kern E.M., Surveys in business process management – a literature review, BPMJ,
vol. 21, no. 3, 2015, p.698)
• Classes of BPM research in journals:

– Class I: investigation regarding BP modelling and BP design
– Class II: investigation of the impact of BPM/BPO on a dependant variable
– Class III: investigation of the implementation of the BPM/BPO concept
– Class IV: presentation of the status quo of BPM in practice
– Class V: investigation of the requirements of practitioners vs. the
scientific research focus
– Class VI: operationalisation of the BPO concept
• Conclusions:
– Surveys are often used by BPM scholars for descriptive, explorative and
explanative purposes
– Mostly cross-industrial samples are investigated (a recommendation to choose
industry-specific samples, countries and regions, not only managers)
– Research has to build relevant theories using rich qualitative data and taking into
account the context of the organisations
BPM Applications
Principles of BPM
(see vom Brocke J., Schmiedel Th., Recker J., Trkman P., Mertens W., Viaene S., Ten principles
of good business process management, BPMJ, vol. 20, no. 4, 2014, p.533)
Principles of BPM
Principles of BPM
Standards in BPM modelling
• According to prominent BPM researcher van der Aalst et al. (2003), BPM is
defined as “supporting business processes using methods, techniques and
software to design, enact, control and analyse operational processes
involving humans, organisations, applications, documents and other sources
of information”. Software tools supporting the management of such
operational processes became known as business process management
systems (BPMS).
• A wide variety of paradigms and methodologies from organisation
management theory, computer science, mathematics, linguistics, semiotics,
and philosophy were adopted, making BPM a cross-disciplinary “theory in
practice” subject.
• There is a need to:
– discuss and rationalize the terminologies associated with BPM and its standards;
– systematically categorize/classify BPM standards;
– discuss the current strengths and limitations of each standard;
– clarify, the differences of theoretical underpinnings of prominent BPM standards;
– explore the gaps of knowledge of current BPM standards and how these may be bridged.
• BPM is mainly a cross-discipline “theory in practice” subject with many
views, definitions and perspectives. Because of its multi-disciplinary
nature, it is often easy to find business process research materials across
many subjects’ databases.
• To effectively understand the terminologies and features of BPM, one should
start from an appreciation of the BPM life cycle. There are many views of
the generic BPM life cycle.
• BPM life cycle consists of:
– Process design. In this stage, fax- or paper-based as-is business processes are electronically
modelled into BPMS. Graphical standards are dominant in this stage.
– System configuration. This stage configures the BPMS and the underlying system
infrastructure (e.g. synchronization of roles and organization charts from the employee’s
accounts in the company’s active directory. This stage is hard to standardize due to the
differing IT architectures of different enterprises.
– Process enactment. Electronically modelled business processes are deployed in BPMS
engines. Execution standards dominate this stage.
– Diagnosis. Given appropriate analysis and monitoring tools, the BPM analyst can identify and
improve on bottlenecks and potential fraudulent loopholes in the business processes. The
tools to do this are embodied in diagnosis standards.
• BPM life cycle

Diagnosis Process design
Process enactment System configuration

• A proposal of a cleaner separation of features found in standards
addressing the process design and process enactment phase into
three clear-cut types of standards:
– Graphical standards. This allows users to express business processes and their
possible flows and transitions in a diagrammatic way.
– Execution standards. It computerizes the deployment and automation of
business processes.
– Interchange standards. It facilitates portability of data, e.g. the portability of
business process designs in different graphical standards across BPMS; different
execution standards across disparate BPMS, and the context-less translation of
graphical standards to execution standards and vice versa.
• BPM suites often have these 3 categories of process design and
enactment standards, but often overlook one type of standard that
facilitates the diagnosis phase:
– Diagnosis standards. It provides administrative and monitoring (such as runtime
and post-modelling) capabilities. These standards can identify bottlenecks, audit
and query real-time the business processes in a company.
• Graphical standards
– Graphical standards allow users to express the information flow,
decision points and the roles of business processes in a diagrammatic
way. Amongst the four categories of standards, graphical standards are
currently the most human-readable and easiest to comprehend without
prior technical training. Unified Modelling Language activity diagrams –
UML AD (Object Management Group – OMG, 2004b), BPMN (OMG, 2001,
2004, 2006, 2011), event-driven process chains – EPC (Scheer, 1992),
role-activity diagrams (RADs) and flow charts are common techniques
used to model business processes graphically.
– These techniques range from common notations (e.g. flow charts) to
standards (e.g. BPMN). And of the standards, UML AD and BPMN are
currently the two most expressive, easiest for integration with the
interchange and execution level, and possibly the most influential in the
near future.
• Strengths and weaknesses of graphical notations
– The notable use of the Workflow Pattern Framework to evaluate BPMN and UML AD
demonstrate that both notations could adequately model most of the workflow patterns.
– The only exception was the absence of an adequate graphical representation of the
interleaved parallel routing pattern in UML AD, even though the underlying UML AD
metamodel has the appropriate structure to create the pattern. The fact that both notations
provide similar flow control solutions to most of the patterns underscore their similarities.
The UML AD and the BPMN share many graphical symbols (e.g. rounded rectangles for
activities, diamonds for decisions, etc.). These similarities are understandable because both
UML AD and BPMN are designed to represent procedural business processes.
– Graphical notations like UML AD and BPMN are easy for non-technical business users to
understand and use. Compared to the text-based execution-level standards like BPEL,
graphical standards visually reveal patterns, loopholes and bottlenecks of a business process.
However, the finite set of process diagram elements may restrict design freedom somewhat.
– Because of the absence of semantic and computational formalisms in graphical notations,
their models will never be able to fully translate into executable code. There will always
be some loss of data or semantics of the control flow.
– Although graphical standards provide a high-level representation of business processes, its
focus is on flow control. Graphical standards are weak on the formulation, evaluation and
measurement of the fulfilment of goals. Goal-based notations or language intrinsic to the
language are desirable.
• Execution standards
– Execution standards enable business process designs to be
deployed in BPMS and their instances executed by the BPMS
engine. There are currently two prominent execution standards:
BPML and BPEL. Of the two, BPEL is more widely adopted in
several prominent software suites (e.g. IBM Websphere, BEA
AquaLogic BPM Suite, SAP Netweaver, etc.) even though BPML
can better address business process semantics.
• Current trends and research directions of BPM
standards - Recent consolidation of BPM standards
– In the early 2000s, there were many standards which eventually
lost favour with practitioners. Fortunately in recent years, these
consolidated into essentially three key standards in the
modelling, interchange and the execution of business processes:
• BPMN (OMG, 2004a). By the former BPMI, now a part of the OMG, the BPMN
represents the high-level notation/graphical representation of business
processes easily understood by business analysts, and especially useful in
communicating business requirements.
• BPEL and OASIS. By the OASIS, the execution level BPEL allows automation of
business processes and makes use of the web services platform.
• XPDL (WfMC, XML). By the WfMC, the XPDL functions as a file format and
acts as a popular interchange language for the easy translation either:
between different software using the BPMN notations without a loss of
information integrity; or more importantly from the notational BPMN to
executable BPEL.
BPM life-cycle
• BPM is a continuous cycle comprising the

following phases:
– Process identification
– Process discovery (design)
– Process analysis
– Process redesign
– Process implementation
– Process monitoring and controlling
BPM life-cycle
BPM life-cycle
– Process identification. In this phase, a business problem is posed, processes relevant to the
problem being addressed are identified, delimited and related to each other. The outcome of
process identification is a new or updated process architecture that provides an overall view
of the processes in an organization and their relationships. In some cases, process
identification is done in parallel with performance measure identification. However,
performance measure identification can be associated also with the process analysis phase,
given that performance measures are often used for process analysis.
– Process discovery (also called as-is process modelling, process design). Here, the current
state of each of the relevant processes is documented, typically in the form of one or several
as-is process models.
– Process analysis. In this phase, issues of the as-is process are identified, documented and
whenever possible quantified using performance measures. The output of this phase is a
structured collection of issues. These issues are typically prioritized in terms of their impact,
and sometimes also in terms of the estimated effort required to resolve them.
– Process redesign (also called process improvement). The goal of this phase is to identify
changes to the process that would help to address the issues identified in the previous phase
and allow the organization to meet its performance objectives. To this end, multiple change
options are analysed and compared in terms of the chosen performance measures. This
entails that process redesign and process analysis go hand-in-hand: As new change options
are proposed, they are analysed using process analysis techniques. Eventually, the most
promising change options are combined, leading to a redesigned process. The output of this
phase is typically a to-be process model, which serves as a basis for the next phase.
BPM life-cycle
– Process implementation. In this phase, the changes required to move from the as-is process
to the to-be process are prepared and performed. Process implementation covers two
aspects: organisational change management and process automation. Organisational change
management refers to the set of activities required to change the way of working of all
participants involved in the process. Process automation on the other hand refers to the
development and deployment of IT systems (or enhanced versions of existing IT systems) that
support the to-be process. The focus with respect to process implementation is on process
automation, as organisational change management is an altogether separate field. More
specifically, it is one approach to process automation wherein an executable process model
is derived from the to-be process model and this executable model is deployed in a BPMS.
– Process monitoring and controlling. Once the redesigned process is running, relevant data
are collected and analysed to determine how well is the process performing with respect to
its performance measures and performance objectives. Bottlenecks, recurrent errors or
deviations with respect to the intended behaviour are identified and corrective actions are
undertaken. New issues may then arise, in the same or in other processes, requiring the cycle
to be repeated on a continuous basis.
BPM identification
• The identification of processes is an initial stage of the process management (PM)
approach in organisation. Usually it is defined in rather broader context (largo
meaning) as the recognizing and description of the organisation processes, which
should answer the question: what processes are of the primary meaning and
indispensable at the organisation in order to satisfy customers needs and
requirements. To answer to this question, the approach top-down (from general to
particular) or bottom-up (from particular to general) is possible to apply.
– In the top down approach the strategy of the enterprise is a point to start the identification stage. The
activity areas, customers groups with their requirements and a product/service offer create an output
information and data in order to identify all existing organisation processes, also necessary to define new
processes, not running yet at the organisation. One identifies basic (key) processes in this approach first and
in the next order the processes supporting them.
– In the bottom-up approach the identification stage is conducted in an opposite order. The elementary
activities (also tasks), which really exist in the organisation processes and are located at the lowest process
level, are the starting point to recognition and description is the organisation processes. Then starting from
single processes and macro-processes an aggregation into larger groups of processes is goes on. This
approach takes already existing processes, and their evaluation and selection from the customer needs and
requirements point of view, and a contribution to creating the value added for the organisation or to reach
organisation goals, is in the practice considerably limited or does not happen at all. Applying this approach
helps however in introducing the ABC (Activity Based Costing) accounting system for processes. However in
the process oriented management approach practice both identification approaches are in use – the only
thing is to take advantage from their advantages and strengths and to avoid know some weaknesses.
BPM identification
• The majority of processes at organizations are having a hierarchical
structure. The processes are complicated and complex, processes
also consist of sub-processes, and then of actions and tasks. In many
cases processes are doubling actions, there are also loops and a lack
of the understanding how activities create processes. For example,
the questions to be asked in the analysis of the process are as
follow:
– What operations and actions are within a particular process?
– What is an execution order of operations and activities (sequential or parallel)?
– Which operation cannot start, until the other one is not finished?
– How long does every operation last?
– Does any idleness exist among operation executions?
BPM identification
• The practical principles and rules to identify and to model or design a
process structure are based on some general and logical principles of
systems, e.g. it is recommended to apply the following rules:
– Every process begins and finishes for the particular customer (internal or external one), who
formulates requirements and uses the results (effects) of this process;
– Every process consists of sub-processes, and finally elementary activities and tasks (a
structure hierarchy);
– Every process has the responsible person for the process - its “owner” (the responsibility and
authority allocation for the process);
– In every process only one object is produced or delivered (the settlement of the process
object);
– The process elements not adding a value are eliminated (the concentration on creating the
value);
– The most profitable, effective and efficient structure is settled for every process (the
formation of the process structure and flow);
– For every process there is a need to assure the proper input delivery from suppliers
(settlement the process inputs and suppliers).
BPM identification
• In the implementation of business process approach in management
all processes must be identified, measured, evaluated and modelled.
For identification phase of process management usually eight-step
procedure is being suggested. In this part of process recognition and
representation an organisation must complete the following list of
steps:
– Customer modelling;
– Measurement and life-cycle analysis;
– Process modelling;
– Integration programmes in supply chain;
– Workflow analysis;
– Organisation mapping and structure design;
– ABC process analysis;
– VA process analysis.
Stakeholders in BPM life-cycle
• There are different stakeholders involved with

a business process throughout its lifecycle.
Among them we can distinguish the following
individuals and groups:
– Management Team
– Process Owners
– Process Participants
– Process Analysts
– System Engineers
– BPM Group
• Management Team. Depending on how the management of a company is organised,
one might find the following positions. The Chief Executive Officer (CEO) is
responsible for the overall business success of the company. The Chief Operations
Officer (COO) is responsible for defining the way operations are set-up. In some
companies, the COO is also responsible for process performance, while in other
companies, there is a dedicated position of Chief Process Officer (CPO) for this
purpose. The Chief Information Officer (CIO) is responsible for the efficient and
effective operation of the information system infrastructure. In some organizations,
process redesign projects are driven by the CIO. The Chief Financial Officer (CFO) is
responsible for the overall financial performance of the company. The CFO may also
be responsible for certain business processes, particularly those that have a direct
impact on financial performance. Other management positions that have a stake in
the lifecycle of processes include the Human Resources Director (HRD) . The HRD and
their team play a key role in processes that involve significant numbers of process
participants. In any case, the management team is responsible for overseeing all
processes, initiating process redesign initiatives, and providing resources and
strategic guidance to stakeholders involved in all phases of the business process
lifecycle.
• Process Owners. A process owner is responsible for the efficient and effective
operation of a given process. The process owner is responsible on the one hand for
planning and organizing, and on the other hand for monitoring and controlling the
process. In their planning and organizing role, the process owner is responsible for
defining performance measures and objectives as well as initiating and leading
improvement projects related to their process. They are also responsible for securing
resources so that the process runs smoothly on a daily basis. In their monitoring and
controlling role, process owners are responsible for ensuring that the performance
objectives of the process are met and taking corrective actions in case they are not
met. Process owners also provide guidance to process participants on how to resolve
exceptions and errors that occur during the execution of the process. Thus, the
process owner is involved in process modelling, analysis, redesign, implementation
and monitoring. Note that the same individual could well be responsible for multiple
processes. For example, in a small company, a single manager might be responsible
both for the company’s order-to-cash process and for the after-sales customer service
process.
• Process Participants. Process participants are human actors who perform the
activities of a business process on a day-to-day basis. They conduct routine work
according to the standards and guidelines of the company. Process participants are
coordinated by the process owner, who is responsible to deal with non-routine
aspects of the process. Process participants are also involved as domain experts
during process discovery and process analysis. They support redesign activities and
implementation efforts.
• Process Analysts. Process analysts conduct process identification, discovery (in
particular modelling), analysis and redesign activities. They coordinate process
implementation as well as process monitoring and controlling. They report to
management and process owners and closely interact with process participants.
Process analyst typically have one of two backgrounds. Process analysts concerned
with organizational requirements, performance, and change management have a
business background. Meanwhile, process analysts concerned with process automation
have an IT background.
• System Engineers. System engineers are involved in process redesign and
implementation. They interact with process analysts to capture system requirements.
They translate requirements into a system design and they are responsible for the
implementation, testing and deployment of this system. System engineers also liaise
with the process owner and process participants to ensure that the developed system
supports their work in an effective manner. Oftentimes, system implementation,
testing and deployment are outsourced to external providers, in which case the
system engineering team will at least partially consist of contractors.
• The BPM Group (also called BPM Centre of Excellence). Large organisations that have
been engaged in BPM for several years would normally have accumulated valuable
knowledge on how to plan and execute BPM projects as well as substantial amounts
of process documentation. The BPM Group is responsible for preserving this
knowledge and documentation and ensuring that they are used to meet the
organisation’s strategic goals. Specifically, the BPM group is responsible for
maintaining the process architecture, prioritizing process redesign projects, giving
support to the process owners and process analysts, and ensuring that the process
documentation is maintained consistently and that the process monitoring systems
are working effectively. The BPM group is responsible for maintaining a BPM culture
and ensuring that it is supporting the strategic goals of the organization.
BPM modelling - models in enterprise
BPM change models
Semantic BPM Lifecycle
■ Modelling – add semantic
(ontological) annotations to
business processes
■ Configuration – map from the
business model to an
executable process
specification
■ Execution – process execution
with discovery & composition
of SWS
■ Analysis – monitor, analyse &
improve processes
Conceptual model of business
processes
Horizontal abstraction - levels of
modelling (See: M.Weske …)
Vertical abstraction - domains of
modelling (See: M.Weske …)
BPM modelling approaches
• Diagramming techniques
– One of the most common description of process models
– Can be in many different forms because there are many different diagramming techniques
for different purposes
– Formal diagramming techniques:
• DFD (Data Flow Diagrams)
• PF (Process Flowcharts)
• IDEF, …
• Business process modelling approach:
– Object Property Relationship OPR Modelling
– RAD (Role Activity Diagram), RIN (Role Interaction Net)
– AW (Action Workflow)
– REAL (Resources, Events, Agents, Locations)
– IDEF, ARIS, …
• Linguistic approach
– Structured English (Pseudocode)
– OPR STATEMENT, …
• Object oriented approach
– ERA (Entity-Relationship Attribute), …
• Traditional modeling techniques
– Flowcharts --> 60’s
• single thread
– Yourdon’s Structured Analysis and Structured Design (SA/SD) -->
70’s
• functional decomposition
– DeMarco’s Structured Systems Analysis (SSA) --> 70-80’s
• dataflow diagrams, state-transition, E-R
– Ross’ Structured Analysis and Design Technique (SADT) --> 70-
80’s
• hierarchical, formal syntax, DFDs for functions and data
– Integrated Computer Aided Manufacturing Definition (IDEF) -->
90’s
• DoD’s mechanized SADT
• DFD model example
asset data
LIBRARIAN
new conceptual
terms closeness
metrics
Fill Update Tune

Catalog Class ifi- Class ifi-
Entry cation cation
cataloged user
valid terms
asset behavior
report
Class ification Conc eptual
CATALOG Dis tanc e
and Thesauri
Graphs
asset valid terms

description
similarity
requests Query & Analyze

Retrieve Usage usage
reports
USER
descriptors
Usage Data ASSET
MANAGER
descriptors Order
As set
query log, inspection log, orders
As sets
• SADT Syntax
CO NTROL
INPUT ACTIVITY OUTPUT
page # LABEL
MECHANISM
• SADT/IDEF0 Example
STARS Guidelines & Standars
Organization
Information
& Resources
Develop Assessment Reports

Candidate Domains
STARS Reuse
Libraries Domain Models
Existing Systems A0 Customized STARS Library

10
Manage
STARS Reuse Operations/Management
Libraries Reports
B0
STARS
SRLPM Staff
Specialists
Staff from
Client Org.
Impacts (Source: www.enterprise-architectur.info 2004)
Practice (Source: www.enterprise-architectur.info 2004)
BPM and architecture
• Architecture = structure(s) of a system in
terms of:
– components,
– their externally visible properties,
– their relations,
– and the underlying principles “Structure with a
vision”.
• Architecture = normative restriction of
design freedom  design principles.
• Descriptive vs. prescriptive notions of
architecture:
– Descriptive: describes the design elements and
their relations. Used in communication with
stakeholders such as clients or engineers;
– Prescriptive: limits the set of design elements
and relations. Used by the architect himself.
What is a good architecture?
• Provides the overview: the most important functions,

the most important domains, etc.
• A means of communication between various stakeholders
(architects, managers, customers, engineers, …)
• A starting point for more detailed designs
• Depends on the stakeholders, relate to purpose
• Conceptual integrity
– underlying “theme”, “vision”
– one set of design ideas: “single mind”
– e.g. design patterns
– role of the architect
• Correct, and as complete as necessary (but not more)
• Architecture Rule No. 1
– Think about the purpose!
– Why is the architecture created?
• describing the as-is situation
• planning changes (to-be)
• performance analysis
• cost/benefit analysis
• outsourcing
• …
• Architecture Rule No. 2

– Think about the stakeholders!
– Not just architects, but anyone who needs information from or has influence on
the architecture, e.g.:
• Upper-level management
• Operational manager
• Project manager
• Developer
• End user
• Architects of other organisations
• …
• Coherence
Product architecture
Information architecture
?
Process architecture
?
?
Application architecture ?
Technical architecture
?
Problems with a good architecture for BPM
analysis
• Lack of Focus on What’s Important
• Lack of Precision and Clarity
• Lack of Repository Support
• Lack of Support for Impact Analysis (Decisions to
Concerns, Decisions to Decisions, and Decisions
to Architecture Assets)
• Difficulty in Linking with the Views
• Lack of Support for Temporal Mapping
Zachman Framework

TM
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why
Scope
Planner SCOPE List of Things Important
to the Business
List of Processes the
Business Performs
List of Locations in which
the Business Operates
List of Organizations
Important to the Business
List of Events Significant
to the Business
List of Business Goals/Strat
SCOPE (contextual)
(CONTEXTUAL) (CONTEXTUAL)
Enterprise model
Planner ENTITY = Class of Function = Class of Node = Major Business Ends/Means=Major Bus. Goal/ Planner
Business Thing Business Process People = Major Organizations Time = Major Business Event Critical Success Factor
Location
Owner ENTERPRISE
e.g. Semantic Model e.g. Business Process Model e.g. Logistics Network e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE
MODEL
MODEL
(CONCEPTUAL) (CONCEPTUAL)
(conceptual)
Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Owner
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
e.g. Logical Data Model e.g. "Application Architecture" e.g. "Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
SYSTEM
SYSTEM
MODEL
Architecture" Architecture
MODEL
(LOGICAL) System model
Designer (LOGICAL)
Designer
Ent = Data Entity Proc .= Application Function
Node = I/S Function
(Processor, Storage, etc) People = Role Time = System Event
Cycle = Processing Cycle
End = Structural Assertion Designer
(logical)
Reln = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Means =Action Assertion
e.g. Physical Data Model e.g. "System Design" e.g. "System Architecture" e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY
TECHNOLOGY
MODEL CONSTRAINED
(PHYSICAL) MODEL
(PHYSICAL)
Builder Node = Hardware/System

Technology model
Builder Ent = Segment/Table/etc. Proc.= Computer Function Time = Execute End = Condition Builder
(physical)
Software People = User
Reln = Pointer/Key/etc. I/O = Screen/Device Formats Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action
e.g. Data Definition e.g. "Program" e.g. "Network Architecture" e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
DETAILED
REPRESEN- REPRESEN-
TATIONS TATIONS
(OUT-OF- (OUT-OF
CONTEXT) CONTEXT)
Sub- Sub-
Contractor Ent = Field
Reln = Address
Proc.= Language Stmt
I/O = Control Block
Node = Addresses
Link = Protocols
People = Identity
Work = Job
Time = Interrupt
Cycle = Machine Cycle
End = Sub-condition
Means = Step
Sub-
Contractor Detailed
contractor FUNCTIONING
ENTERPRISE
e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
FUNCTIONING
ENTERPRISE
representations
Zachman Institute for Framework Advancement - (810) 231-0531 Copyright - John A. Zachman, Zachman International
(out of context)
Zachman Framework
Zachman Framework
Inventory management example
physical
technology
infrastructure
physical
technology
infrastructure
physical
technology
abstract
infrastructure
platform physical
technology
abstract
infrastructure
platform physical
technology
abstract
infrastructure
A-Muse Framework
serviceplatform physical
technology
abstract
infrastructure
realisation
service
serviceplatform
abstract
realisation platform
service
service
service
realisation platform
service
specification service
service
realisation
service
specification service
service
realisation
service
specification
business service
application
service
realisation
business
process specification
business service
Scope
business
business service
business
business
network business
business
business
process
network business
other aspects
business
business
process
network business
quality
business
business
process
value network
business
network
information
business
network
structure
behaviour
Detail
Aspect
ArchiMate Framework
Environment
Product
domain
Information Process Organisation
Business domain domain
domain
Data
Application domain Application domain
Technology Technical infrastructure domain
Information Behaviour Structure

Compared to Zachman
Planner
Business
Information
Behaviour
Structure
Owner
Application
Designer
Technology
Builder
Sub-
contractor

CEAF
• The Commission Enterprise Architecture Framework is a framework which was
specifically developed in order to help maintain the vast number of IT applications
used by the European Commission. However, it can also be implemented on lots of
businesses, because the praxis today is that companies posses lots of new software
and technologies and they try to integrate them, which in a lots of cases can be very
difficult. In order to help to solve this problem, this architecture framework has been
developed within the IT department of the European Union's institutions.
• The CEAF implements the model of integrating the architecture from the status "As-
is" to "To-be" while using the standards and transitional processes.
• It also uses four different perspectives to look at the architecture.
CIMOSA
• Computer Integrated Manufacturing Open System
Architecture is a modelling framework which
focused on integrating three parts of enterprise –
machines, computers and people.
• It has been developing since 1980s when the first
proposals for CIM architectures were called by ESPRIT
(European Strategic Programme for Research in
Information Technology). Then the project was called
AMICE (European CIM Architecture). In 1994, the CIMOSA
Association has been established and worked together
with ESPRIT on the project AMICE. There were also some
other projects like CODE or CIMPRES. These projects couldn't
be done without the help of some industrial companies, e.g. Fiat,
Hewlett Packard or IBM. This architecture was used in a lot of types
of automobile industry (gearbox production in Fiat) or in paper
production planning.
• The main structural idea of this architecture is
that uses three dimensions to describe the model
of the enterprise. Then there is a life cycle
dimensions which is kind of a examination of the
model. It depicts the phases of its existence.
DoDAF
• The Department of Defense Architecture Framework is a framework that provides the
way how to organize the Enterprise Architecture and system architecture into one
integrated view. It mostly suits to large systems which are very complex and connects
wide scale of problems.
• The framework has its roots in the 90s of the 20th century when the C4ISR
Architecture Framework was developed and was the starting point for the invention
of DoDAF later around the year 2003, when the version 1.0 was introduced. In
comparison with C4ISR (military concept - command, control, communications,
computers, intelligence, surveillance, and reconnaissance), DoDAF offered wider
usage of application of the framework. The year later the documentation for it was
released. In 2007, the version 1.5 with some additional concepts was released. Last
version, that is still used, was released in 2009 and it was version 2.0. Last year, in
2010 a new version 2.02.
DoDAF
• The framework works on the basic of different views:
– All View (AV)
– Operational View (OV)
– Systems and Services View (SV)
– Technical Standards View (TS)
EAP
• Enterprise Architecture Planning is the tool for making
the architecture for planning process within the
enterprise. It was developed during the 1990s and is
based on top-to-bottom hierarchy of activities.
• EAP model is built by four layers:
– layer 1 – getting started – this is where top-level management
needs to be think of, main component is Planning initiation,
which describes the general methodology and questions, who
should be involved, what support is needed and what toolset
will be used
– layer 2 – where we are today – here is baseline for definition
the architecture and long-term plan, main components are
Business Process Modelling (describing business functions and
process) and Current Systems and Technology (describing
current information technology and systems)
– layer 3 – the vision where we want to be – sketch of basic
process flow consisting of components like Data Architecture
(data needed to support the business process), Application
Architecture (main applications necessary to manage the data)
and Technology Architecture (technology needed to support
applications that manage the data)
– layer 4 – how we plan to get there – the strategy to achieve
goals above, main component is Implementation / Migration
Plan (how and when the chosen application will be used, a
cost/benefit analysis and a path for migration
FEA
• Federal Enterprise Architecture was developed by the
initiative of US Office of Management and Budget in
order to provide a methodology for information
technology use, acquisition and disposal in the Federal
Government. The main purpose was to simplify and ease
the sharing the information and resources among the
federal agencies.
• This architecture is based on five main reference models:
– Performance Reference Model (PRM) – main task is to measure the
performance of IT investment and identification opportunities where
the process can be improved
– Business Reference Model (BRM) – this model provides every day
business operations in a functionally driven approach
– Service Component Reference Model (SRM) - in this case, the model
is performance-driven and describes services in the way how they
support main business operations
– Data Reference Model (DRM) – shows the aggregate level of data flow,
provides a view on interactions between the agencies and the citizens
or other subjects
– Technical Reference Model (TRM) – this is component-driven
framework describing standards and technologies in categories to
support and enable the delivery of Service Components
FEA
TEAF
• Treasury Enterprise Architecture Framework is a enterprise architecture
framework derived from previous frameworks such as TISAF and FEAF
(Federal Enterprise Architecture Framework). It is also based on Zachman
Framework. Main purpose of this architecture is to provide IT systems for
investment planning, streamline systems and systems that ensures the
business reaches the strategic goals.
• First version of TEAF was released during the year 2000. Nowadays, the
TEAF developed into the TEA (Treasury Enterprise Architecture).
TISAF
• The Treasury Information System Architecture
Framework is also one of the frameworks
helping the important institution of the USA
(US Department of the Treasury). It was
developed during the 1997 and it was the
starting point for derived framework TEAF
(Treasury Enterprise Architecture
Framework).
• Main idea of TISAF about the complete
architecture comprises of four parts
representing different view of the company:
– functional – representing main business processes and how can
company use the information to support its business operations
– work – describing of where and how the information systems
are used throughout the company
– information – describing the information necessary to support
business operations
– infrastructure – describing the hardware and software
necessary to implement the information systems within the
company
TOGAF
• The Open Group Architecture Framework is another
framework for enterprise architecture which provides
methods and tools for developing IT and business models. It
is developed by The Open Group whose members are IBM,
Hewlett Packard or Fujitsu.
– The development started in the 1990s, while the first version was
introduced in 1995. It was based on TAFIM (Technical Architecture
Framework for Information Management), which was the framework
developed by the US Department of Defence. However, they gave the Open
Group the permission to use it as a starting point. The development
continued and during the year 2009 the version TOGAF 9 was released.
• TOGAF itself is based upon four architectural domains:
– business architecture – defining main business processes, strategies and
within the company
– applications architecture – providing sketches of individual application
systems that can be used, also what interactions can be achieved between
the systems and relationships to the main processes from business
architecture
– data architecture - describing physical and logical data structure of the
company and resources data management
– technical architecture – describing parts of the organization comprising
software, hardware and network infrastructure necessary to support the
main business processes
ARIS
• ARIS: Architecture of Integrated Information
Systems
• ARIS Method:
– a modelling framework and method rather than one technique
– an architecture for describing business
– a framework and method for business modelling (not only
limited to process modelling, but focus on the support of
business processes)
– has a strong focus on modelling complex business relationships
– helps to captures a wide range of descriptive aspects of
business process
– support life-cycle modelling (requirement definition, conceptual
design to logical design and physical implementation
descriptions)
ARIS
• ARIS Toolset
– software tool/environment for
business modelling following the
ARIS method
– tools for generating,
constructing, configuring and
simulating models
– a multi-user process design tool
– capable of fully distributed
model development
– one main use is defining business
implementations of the SAP R/3
ERP systems
– supports software system
modelling using UML
ARIS
• To understand how business operates we need to understand many
things:
– business processes, objectives and metrics
– data
– systems, organization, culture, skills
– products, risks
– regulation
– interfaces, environments
• ARIS aims at modelling all aspects of a complex business:
– processes structure, organization, data, documents, resources, systems,
information, products, knowledge, business objectives, information flows
– uses Event-driven Process Chain methodology
• ARIS was developed independent of any particular method; ARIS
concepts especially help in creating enterprise wide as well as inter-
business business models and production models.
ARIS House
1. Functional View: How?
– What activities are being carried out?
2. Organisation View: Who?
– Who carries out the activities?
– Human resources, machines,
hardware software…
3. Data View: With what data?
– Documents and events generating
documents
4. Control View: How?
– Integration of the functional,
organisational and data view into one
control view
– In this control view the other views
are integrated in one logical sequence
5. Output (Product/Service) View
– All artefacts resulting as output from
the above
ARIS HOBE
ARIS modelling in life cycle
• The ARIS House or ARIS House of
Business Engineering (HOBE)
supports all phases of business
design:
– Phase 1: Initial strategic situation:
Objectives
– Phase 2: Conceptual development
(capture and model requirements;
capture and model conceptual
design)
– Phase 3: Logical development
(Model logic)
– Phase 4: Implementation
description
ARIS Engineering Roadmap
Strategy Design Implementation Controlling
Identify Execute Setup Monitor
business segments as-is (requirement) system business
& objectives analysis infrastructure performance
Record Design Execute Monitor

enterprise map to-be processes process system
(SAP neutral) configuration performance
Determine Monitor
end-to-end Select Execute organizational
scenarios SAP components process performance
integration
Determine Build Perform Control

key performance Initial prototype test and service-Level
indicators (feasibility) validation Agreements
Perform Design Perform Verify

enterprise to-be processes User cost benefit
analysis (SAP based) training calculation
Trigger
Define Create Execute corrective
business Business go-live actions
case Blueprint management
Business Case Business Blueprint Live System Improvement Strategy

ARIS Symbols
ARIS Easy Design version
ARIS Symbols
ARIS Easy Design version
ARIS Model Example
Sales
Europe
Direct Sales manage- Partner

sales ment europe sales
Direct sales
cars
east europe
Direct sales
cars
west europe
Sales Sales team T. Jungmann

team manager
germany
Secretary R. Eckert
Sales employee M. Bernardy
E. Schauf
V. Stark
T. Becker
Process Chain Analysis
Description of Business Problems
• Before the individual descriptive objects within the ARIS architecture (views
and levels) can be modelled, the initial semantic business process, i.e. the
business problem, must already exist. In this context, the weak points of
the information systems in use are described as far as the support of the
business processes and the target concept’s essential contents of the
projected system are concerned. The weak points thus found also mirror the
objectives that new information systems will have to attain. The model
expressing this problem description therefore needs to cover as many facts
as possible from the data, function and organizational structure views
including the interrelationships existing between them.
• Moreover, the model must allow the target concept to be specified to such
an extent that this specification can serve as a starting point for the rest of
the modelling process. Thus, the development process of the requirements
definitions triggers the division into views corresponding to the ARIS
architecture. Due to the requirement that the initial business situation has
to be described in a comprehensive way and that the weak points of the
existing information systems have to be displayed in condensed form, the
use of common modelling methods is limited. Since their main analysis
features are focused on different aspects, these methods can only be used
for modelling individual views. These interrelationships are registered in
condensed form as process chain diagrams (PCDs).
Process Chain Diagrams (PCDs)
• In a process chain diagram a process chain is displayed as a closed
loop. Thus, the views of a business process established earlier
(organization view, data view, function view and resource view) and
their interrelationships are expressed in a still more coherent form.
• Example: process chain for Order processing
Modelling within the Views of the ARIS
Function View - Requirements Definition
• Modelling methods often display functions in connection with

objects from the other descriptive views of ARIS. The relationship
between data and functions is displayed for example to specify the
transformation process of a function via the input/output data of
that function.
• ARIS architecture, on the other hand, strictly separates the
various areas of analysis. Within the function view only those
representational forms are used which illustrate the connections
between the functions. One example is the relationship between
functions and data displayed in the control view of ARIS.
• Definition: A function is a technical task or action performed on
an object to support one or more company goals.
Function View
• Functions are displayed as rectangles with rounded corners:
Illustration of the “Check customer inquiry“ function.

• Usually, the criterion for establishing such a function is an
information object such as a customer inquiry or a production order.
This should also be expressed in the description of a function.
Customer inquiry defines the object, and Check defines the task
that will be performed on this object. On a higher level, only a noun
is used to describe functions (e.g. Procurement logistics, production,
sales).
Function Tree
• Functions can be described on different compression levels. At the
highest compression level are complex functions in the form of
business processes or process chains. An example of this is the
processing of a customer order from the customer inquiry to
shipping. Such a business process thus represents a complex function
that can be divided into sub-functions to reduce its complexity.
Hence, the term Function can be used on all hierarchy levels. But
other terms are also often used to explain the hierarchy level in a
more descriptive way: transaction, process, sub-function or
elementary function.
• Dividing functions can involve several hierarchy levels. Elementary
functions represent the lowest level in semantic function trees.
• Definition: Elementary functions are functions which cannot be
divided up any further for the purpose of BPM analysis.
• In order to group functions in a function tree, different criteria may be
employed. Often used criteria for this purpose include: processing of the
same object (object-oriented), dividing depending on the process belonged
to (process-oriented) or combining functions according to the same tasks
(task oriented).
Function Tree – an example
Function tree
An example of an object-oriented breakdown
Function tree
An example of a process-oriented breakdown
Function tree
An example of a task-oriented breakdown
Function tree
• On the one hand, representing functions in a function tree reduces complexity, but
on the other hand, it is a static representation. In addition to this static
representation it might also be of interest to see the procedural sequence of
functions chronologically.
• Event driven process chains (EPCs) are used to represent chronological procedural
sequences. They do not only contain functions but also events forming the links
between the functions. Events must be assigned to the ARIS data view. EPCs are
described in the ARIS control view – in accordance with the principle of the
separation of ARIS views.
• Describing the functions from a subject-related point of view not only involves the
property that a function can be broken down into its elements - other function
properties are of interest, too. This is especially true for properties which take part
in the design of business processes. Thus, each function draft should include
information on whether it requires user input or whether it can run
automatically. Therefore, functions of the same type, which can be executed
without user intervention, may be bundled and processed closed (batch run).
• Information on the quantity structure of a function (e.g. number of enquiries that are
processed in a day) provide the basis for recreating business processes and the total
length of time it takes to perform the function.
• The total time can be further subdivided into individual time elements (orientation
time, processing time, waiting time). ARIS saves this information as attributes to the
Function object type.
Y Diagram
• The Y diagram is used to represent the functions (tasks) of a
company on a highly aggregated level. Here, we are dealing with
major functional areas such as Product design, Materials
management, Maintenance. The structured illustration in the form
of the Y-CIM model shows the classification of the individual
functions.
• Scheer allocates the primary business-administrative planning functions of
production planning and control to the left branch of the Y, while the right
contains the technically-oriented functions of product planning and
product realization. The planning functions are arranged in the higher
portions of the Y while the control and realization functions can be found in
its lower portions.
• Thus, the Y-CIM model represents a frame for sorting all functions of a
production company.
• Within ARIS, this model type can be used for the function-oriented approach
to complex reference models. The objects shown are of the Function object
type. Arranged in a hierarchy, this object type can be linked, for example,
to the Function tree and eEPC model type.
Y Diagram – an example
SAP Applications Diagram
• The SAP applications diagram permits an approach to the SAP R/3
reference model implementation that is oriented towards the SAP
R/3 application system modules.
• In the R/3 reference model, a process selection matrix is assigned to
every object of this model type. It displays the main processes
available in the individual R/3 modules and the process scenarios
which can thus be illustrated.
Objective Diagram
• Before you start modelling, analysing or optimizing business processes
(business process reengineering), you should define your company’s
business process modelling objectives.
• In the objective diagram you can - among other things - define (company)
targets and create target hierarchies.
• Definition: A target is the definition of future company goals which
should be reached by supporting critical factors and realizing new
business processes.
• You can specify critical factors for reaching the target, arrange them in a
hierarchy and assign them to the targets that they are helping to attain.
• Definition: Critical factors specify the aspects which need to be
considered in order to reach a particular company target. They are
assigned to company targets in the objective diagram.
• This model type is linked to the other model types of the requirements
definition by means of the Function object type. For every target, you can
display which function (business process) leads to attaining this target.
During the business process modelling and optimizing phase, you should
consider the target priority set here and the assigned functions when
specifying the process model.
Objective Diagram – an example
Design Specification
Application System Type Diagram
• The design specification of the function view contains the
specification for the application system and module types, for the
modular structure, the draft of the individual transaction steps and
the definition of input and output presentations in the form of lists
and screen drafts.
• The main questions that are answered by specifying the IT design of
the function view are:
– How can the functions defined in the requirements definition be supported by
using application system types, module types or IT functions?
– How are application system types or module types set up in a modular form?
– Which lists and forms are necessary to perform a function?
– Which lists can be created with an application system type or a module type and
which forms do application system types and module types use?
– What technological basis (operating systems user interfaces or database
management systems) does an application system type have?
– What company objectives are pursued when using a specific application system
type?
• The main design specification object type in the function view is
therefore the Application system type.
• Unlike a specific application system that is not seen until the
implementation level of the function view and an individual
application system that is identifiable by a license number in the
company, an application system type is produced by the typification
of all application systems that are on precisely the same
technological basis.
• Definition: An application system type represents the typification
of individual application systems which are based on exactly the
same technology.
• Example: ARIS Toolset version 4.1 represents an application system type. You can
obtain several licenses and therefore several individual application systems from this
application system type.
• The following graphic represents application system types:
• Application system types are mainly modular in structure. The

application system type diagram enables this modular structure to
be shown. The individual parts of an application system type are
module types.
• Module types are components of application system types. They
represent components that can run to completion on their own.
• Definition: A module type is a component of an application
system type that can run to completion on its own. Module types
represent the typification of individual modules which have
exactly the same technological basis.
• Application system types and module types can be put into any
hierarchy. Module types can be divided at the lowest level of the IT
function types.
• Definition: IT function types are the smallest units of a module
type as far as a transaction is concerned. They are produced by
individual program modules and must always be carried out
completely to process an individual work step.
• Example:
• The application system type diagram allows the functions of the

requirements definition that are supported by the defined application
system types and module types to be specified. This assignment thus forms
the link between the requirements definition and the design
specification of the function view. An example illustrating this:
• Processing a technical function with the help of an application
system means using various screen diagrams and producing or using
various lists that are provided by the corresponding application
system. The List and Screen objects are available to represent this
and can be assigned either to the technical function or the
application system types and module types.
• If first of all general procedural sequences are to be defined without
reference to specific application system types, List draft and Screen
draft objects can also be used to specify the necessary screens and
lists. Both object types specify first of all generally which type of
list or screen is to be used (example input customer data) without
making a specific reference to application system type lists or
screens. Subsequently you can link these list and screen drafts with
specific lists and screens. The assignment thus defines the
implementation possibilities available.
• An example illustrating:
Implementation
Application System Diagram
• In the application system diagram the specific application systems
and modules can be assigned to the application system and module
types described in the design specification. This means the existing
copies of an application system type in the company that can for
example be uniquely identified by the license numbers.
• Definition: An application system (module) is a single copy of an
application system type (module type) that can, for example, be
specifically identified by the license number.
Implementation
• The implementation level not only allows the actual existing
application systems and modules to be shown but also defines the
technical program (physical) conversion of the application systems in
the form of individual program files.
• To do this the program module types that are necessary to produce
an application system type or module type can be shown in the
application system diagram.
• Definition: A program module is each program file on a data
carrier obtained by buying a license (e.g. an EXE file or COM file).
A program module type is formed by typifying program modules
that have exactly the same technological basis.
• An example of the assignment of program module types to an application system type
and or individual program modules to program module types.
Implementation
Data View
Requirements Definition
• The requirements definition of the data view includes a description
of the semantic data model of the field which is to be examined.
According to the ARIS division principle this description contains
both the objects which specify the start and end events of a process
chain as well as the status descriptions of a process chain’s relevant
environment.
• When comparing the modelling of functions and data, the latter is
particularly demanding as far as the method is concerned. In the
function view the only object examined is the function. In terms of
interrelationships between functions only the super- and
subordinations are illustrated.
• Chen’s entity-relationship model (ERM) is the most widespread
designing method for semantic data models (see Chen, Entity-
Relationship Model 1976). This modelling method uses various terms
such as entity type, relationship type, attribute, etc. The
relationships which exist between those objects are numerous and -
compared with function modelling - are significantly more difficult
to classify.
Data View
• The original model distinguishes between entities, attributes and
relationships. Generally, the type level can be differentiated from the
occurrence level.
• Definition: Entities are real or abstract objects of interest for a given
segment of an company’s tasks.
• This descriptive object may be a business process, for example. According
to the ARIS structural model, the data objects of interest are objects of the
environment and objects specifying events.
• Examples of entities in the Processing customer order process are:
– Customer 1235,
– Data View 4-22,
– Article 4711,
– Order 11.
• Entities are described more precisely by certain attributes (properties). This
means that a customer for example can be specified more precisely by his
name, first name and address.
• Definition: If entities of the same type are grouped into sets, they are
called entity types. The individual occurrences of these are entities.
• Entities of the same type can be described by the same attributes. Thus customer Maier and customer Müller are
grouped under the customer entity type. Article 4710 and article 4712 are grouped under the article entity type.
Entity types are displayed in the ER model as rectangles (entity types will be indicated by capital letters).
Data View
• Definition: Attributes are properties describing entity types.
Attribute occurrences are specific values of attributes of individual
entities.
– For example, customer 1235 can be described by the Miller, Peter, Munich etc. attribute occurrences. The relevant attributes are
Name, First name, and Address.
• Attributes are usually represented by an oval or a circle. Attributes

are represented by ovals.
• The difference between entity types and attributes is often hard to
find and can sometimes only be determined from the context of the
modelling procedure.
– For example, the customers’ addresses can be understood as entities and not as an attribute of CUSTOMER. In this case, a
separate entity type, ADDRESS would be modelled which would have a relationship to CUSTOMER. When specifying whether you
are dealing with an entity type or an attribute, the fact that entities possess attributes is a helpful criterion. Attributes, on the
other hand, cannot have attributes. Thus, if an attribute is created in an ER model which is supposed to be described by further
attributes later on, it becomes an entity type. Whether an object is to be assigned interrelationships with other entity types or
not is another helpful question. If this question can be answered positively the object in question, too, is an entity type.
• Examples of attributes for the CUSTOMER entity type:
Data View
• Definition: A relationship is a logical link between entities. Hence,
the existence of relationships directly depends on the existence of
entities.
• Definition: If relationships of the same kind are grouped into sets,
they are called relationship types.
• An example: A relationship type between SUPPLIER and PART could be SUPPLIES.
• Relationship types are also indicated by capital letters. In an ER model, relationship
types are displayed as diamonds and are linked with the entity types via connections.
Data View
• Often, when naming relationship types they can only be read in one
direction for the links to make sense. We differentiate between a number of
relationship types. In this context, the number of entity types they link, on
the one hand, and the degree of a relationship’s complexity, on the other
hand, serve as distinguishing criteria.
• In the above example, the relationship Supplier supplies Part is supposed to be
expressed. From right to left this would read Part supplies Supplier which does not
make sense. If the correct direction cannot be determined uniquely this difficulty
must be avoided by skilful selection of superior terms.
• Relationship types are distinguished according to the number of entity types
linked to them, i.e. unary, binary or n-ary relationships.
• Definition: The degree of complexity or cardinality indicates how
many entities of one entity type are assigned to an entity of the
other entity type.
• Four different kinds of relationships can be distinguished (cardinalities):
– 1:1 relationship,
– 1:n relationship,
– n:1 relationship,
– n:m relationship.
Data View
• In a 1:1 relationship, each entity
of the first set is precisely assigned
to an entity of the second set.
• In a 1:n relationship, each entity
of the first set is assigned to each
entity of the second set, but n
entities of the first set are
assigned to each entity of the
second set.
• An n:1 relationship carries out the
same task but in the reverse order.
• In an n:m relationship, several
entities of the second set are
assigned to one entity of the first
set and vice versa.
Data View
Data View
• Definition: The value ranges of attributes are called domains.
• The assignment of elements of the domains to elements of the
entity or relationship types also describes relationships. They can be
represented by a connection which is labeled with the name.
• Definition: A 1:1 relationship must exist between one entity type
and at least one domain. The values of this domain uniquely
identify the individual entities. Therefore, they are called the
key attributes of the entity type.
• In the example, the entities of CUSTOMER are uniquely identified by the customer
number key attribute.
• Relationships are identified by fusing the key attributes of the linked
entities. Thus, the key attributes of the RESIDES AT relationship type
are customer number and address number.
• The descriptive attributes of the relevant data objects are defined
by values deriving from domains having a 1:n relationship with entity
or relationship types.
Data View
Data View
• Through classification, objects (entities) of the same kind are
identified and assigned to a concept (entity type). One object is
identical to another if it is described by the same properties
(attributes).
• In generalization, similar object types are grouped under one
superior object type. By specialization we understand that a
generic concept is divided into sub-concepts.
• Aggregation describes the formation of new object types by
combining existing object types. In this context, the new object
type can be a repository of new properties.
• Through grouping, groups are formed from the elements of an
entity set.
Data View
Classification Generalization
Specialization Aggregation & Grouping

Data View
• In modelling, especially in data modelling, we have to deal with one
difficulty that occurs frequently. This is the variety of terms defining
information objects in larger companies. What is understood by the
term Order in the purchasing department is totally different from
what people in the production department associate with it. By
employing consistent terminology for a company and its
departments, the acceptability of the specified information can be
increased.
• For this reason, the method set of ARIS contains so-called technical
term models which not only allow the different terms in the sense
of synonym management to be managed, but also enable the
relationships between the data model’s objects (entity type,
relationship type, etc.) to be maintained as well as the technical
terms specified by the company.
– An example:
Combining Organization with Data
• We are considering the same questions we have dealt with in the
design specification:
– Which organizational units are responsible for data objects?
– Who has access to which data objects?
– Which data objects are stored on which hardware components?
• Unlike the design specification, the relationships are now established to those data
objects shown at the implementation level of the data view. This means that the
responsibility for data objects is no longer defined for relationships and attributes of
the relational diagram but for the physical structures, i.e. tables, fields and their
specimens (table (specimen), field (specimen)).
• In order to represent these dependencies, connections are drawn between the
objects of the organization view (organizational unit, position, human resource, etc.)
and the table diagram’s objects mentioned earlier (table, field, view (physical), etc.)
in the access diagram (physical).
• When drawing a connection between the organizational units and the tables and
fields the meaning of every relationship must be defined separately. Is responsible
for means that this particular organizational unit is responsible for the contents of
the respective table or field; accesses means that this particular position or human
resource is authorized access to the data objects shown.
Combining Organization with Data
• In addition to the definition of access privileges and responsibilities
you can use the hardware component object (organization
view/implementation) to define on which hardware components that
actually exist - and which can be uniquely identified using the
inventory number, for instance - certain information objects of the
company are located.
• For this purpose, the Hardware components object may be linked to
information objects at the implementation level (tables, fields,
etc.), the design specification level (relations, attributes) or the
requirements definition level (entity types, data clusters, etc.) in
the access diagram (physical).
• An example:
Combining Organization With
Functions
• In the design specification, the Application system type—Location
relationship was used to define which application system types may
be situated at particular locations of the company. In order to
specify exactly where in the company the individual licenses that
have been obtained for an application system type are used, it is
possible to link locations with the Application system, Module and IT
function object types in an access diagram (physical).
• An example:
Combining Functions with Data
Event Control – Event-Driven Process Chain (EPC)
• The procedural sequence of functions in the sense of business

processes is illustrated in the form of process chains. This means
that the start and end events can be specified for each function.
Events not only trigger functions but are also results of functions.
• Definition: By an event we understand the fact that an
information object has taken on a business-relevant status which
is controlling or influencing the further procedure of the business
process. Events trigger functions and are the results of functions.
Unlike a function, which is a time-consuming occurrence, an
event is related to one point in time.
• Events are graphically represented as hexagons. The description

should not only contain the information object itself (order) but also
its status modification (received).
• Examples (events):
• Definition: Events trigger functions and are the results of
functions. By arranging this event to function change in a
sequence, so-called event-driven process chains (EPCs) are
created. An event-driven process chain (EPC) shows the
chronological course of a business process.
• Since events determine which state or condition will trigger a
function and which status will define the end of a function, the
starting and end nodes of an EPC like this are always events. Several
functions can originate simultaneously from one event and
conversely, a function can result in several events. A link in the form
of a circle is used to represent these branches and processing loops.
These connections, however, not only serve as graphic operators but
define the logical links between the objects they connect.
• We can basically distinguish between two different types of
operators:
– Event operators,
– Function operators.
• An example of an EPC:
Function Allocation Diagram (I/O)
• As well as the representation of event control, the transformation of
input data to output data and the representation of the data flows
between functions represent a link between the data view and the
function view in the ARIS concept.
• The transformation of input data into output data can be illustrated
in so-called function allocation diagrams (I/O) which basically
correspond to pure input/output diagrams used in other methods.
• An example:
Process chain diagram (PCD)
• In the PCD objects have to be arranged according to the column
description. The EPC representation permits a free arrangement of
objects. However, adding input/output data may result in confusing
models. Therefore it is recommended to use a PCD representation
especially for business processes executed in sequence.
Information Flow Diagrams
• Information flow diagrams are suitable for
illustrating the flow of data between
functions. For this purpose two functions
can be interlinked by a data flow object in
an information flow diagram. This object
shows that there is a data flow from the
source function to the target function. In
order to specify the data objects flowing
between the displayed functions more
precisely, this data flow object can be set
in a hierarchy which, in turn, allows
assigning a data model to that object.
• This data model represents the information
objects which are exchanged between the
functions. Depending on the degree of
detail of the examined functions, the
information objects can be data clusters,
entity types or ERM attributes.
• An example of this type of representation:
Event Diagram
• Events define the fact that the status of information objects has
changed. Thus, every event is a reference to particular information
objects of the data model and defines the status of this information
object at a given point in time.
• First of all, events are roughly specified in a top-down operating
process (example: Customer order has been processed). The next
detailed step of the process modelling level involves specification of
the events in more detail. If they are combined in a certain way, the
events occur on the roughly defined level.
• For example, the total of the following events that have occurred: Customer data
checked, Order header registered, Order items registered and Feasibility checked
could define the Customer order status.
Value-Added Chain Diagram
• Above all, the value-added chain diagram is used to identify those
functions within a company which are directly involved in the
creation of a company’s added value. These functions can be
interlinked by creating a function sequence and thus a value-added
chain.
• An example of a value added chain:
Other Models
Business Controls Diagram
• A Business Controls Diagram displays potential
risks of a process or function as well as ways of
covering these risks.
• Definition: A risk means the potential danger
of a process not reaching the desired process
target.
• Definition: A risk control is a general way of
eliminating or mitigating risks.
• Definition: A risk solution means implementing
a risk control in relation to a risk.
• The Business Controls Diagram layout
corresponds to a matrix or table. Risk solutions
are now inserted as operators between a risk
and a risk control. Additionally, organizational
units (in the sense of user requirements) and
documents, which also support implementation
of a risk control regarding a risk, may be added
to the model.
Other Models
Quick Model
• The Quick model type allows to model without method restrictions.
The Quick model contains the Quick object type with over 30
different symbols. Relationships of the has relation with type can be
created between quick objects. Several connections of this type are
allowed between two objects. The corresponding standard attributes
can be maintained for models, objects and connections. Each object
can be assigned several quick models for any object type in the ARIS
method.
• A quick object can also be assigned any number of models in the
ARIS method regardless of model type. Quick model types and/or
Quick object types can be transformed into method based models or
objects using the Semantics Generator in ARIS.
Other Models
C3 Method
• The c³ method model type can describe the first entry of a process
above the process level in a change management project.
• Here the focus is always on the process to be improved. For each
process examined a number of different objects are modelled that
illustrate relevant information for the project in list form. This
includes information on:
– organizational aspects, e.g. process responsibility and deputizing rules
– tasks that will be carried out to improve the process
– indices by which the improvement in the process will be measured
– tools to be used to improve the process
– activities planned to change the process in the near future
– improvement potential for the process examined
– the skills needed to carry out the process
– targets aimed at by the project
– tools that are currently being used (software, methods, continuous training)
– tools that should be used to improve the process and integrate it into the whole
system.
Other Models
C3 Method
Performance Modelling
Product/Service Exchange Diagram
• The product/service exchange diagram is used to illustrate the
creation of products/services as well as their exchange within the
company. A performance can be either a service or a product and is
represented by a corresponding symbol.
• Products can be material types, operating resource types, technical
aid types and/or packing material types, that you are familiar with
for example from the eEPC (material flow). Performances as input
and/or output of functions can be connected with the starting or
ending events of these functions.
• This product/service exchange between business functions can be
utilized in a beneficial way already on an abstraction level that is
situated between the value added chain diagram and the eEPC.
Along with the exchange relationships from a functional viewpoint,
the exchange relationships of performances can be illustrated from
an organizational viewpoint. For this purpose, the product/service
exchange diagram also offers several modelling options.
• An example of a product/service exchange diagram.
Product/Service Exchange Diagram
Product/Service Tree
• Performances can be viewed from different
abstraction levels. It is therefore useful to
include these relationships in a model in which
the performance parts that make up an entire
performance are represented. This static
aspect is represented in the product/service
tree. A complex product, for example,
contains many different modules, each of
which has various component parts. Each of
these items can be understood as a
performance.
• In the product/service tree, substitution
relationships to other performances such as
(potential) replacement products or services
can also be represented.
• In this static model the relationships of the
performances to the (company) goals are also
represented.
• An example of a product/service tree:
Product Allocation Diagram
• In addition to the general product/service
diagrams which belong to the graphic
models, the product models offer the
possibility of creating a more abstract
representation. The product allocation
diagram is used to analyse product creation
in public administration. Just like the
product/service exchange diagram, this
model type can show which organizational
unit provides or uses which products, and
which functions are required for the creation
of the products, or for which functions the
products provide an input. In addition, the
(legal) order basis of each respective
product is shown here. The objectives to be
accomplished with the various products can
be represented as well.
• An example of a product allocation diagram for a public
service:
Product Tree
• The purpose of the product tree is to analyse the composition of

products in public administration. This model corresponds essentially
to the product/service tree, whereby the possibility of modelling
replacement products is dispensed with.
• An example of a product tree:
Product Selection Matrix
• In the product selection matrix

the focus is on an organizational
unit and the products under its
responsibility. These products
can be allocated to the
functions necessary for their
production.
• The model is suitable as a
starting point from which
organizational charts, product
trees and processes relevant to
the creation of products can be
navigated.
• An example of a product selection
matrix:
Competition Model
• This model supports the analysis and
evaluation of the competitive
environment in which the company
competes. The industry structure
strongly influences the strategies which
are potentially available to the company.
• In this model it is possible to represent
relationships within a company, the
resulting products and services, and
market partners. It is also possible to
represent which clients are using which
products and services, which products
and services are provided by suppliers
and which replacement products and
services are offered by (potential)
competitors. Thus, a window on the
competitive situation of the company can
be represented.
• An example of a competition model.
ARIS Type of Models
• Diagrams and trees of ARIS (approximate 100)
ARIS Examples of Applications
Scenario Scenario tasks Model types
General company Documentation of the company’s: objectives, value Objective diagram; Value-added chain diagram; Organizational
documents added, organizational structure, functions, processes chart; Function tree; Office process; Industrial process; eEPC/PCD
Database management / Data structuring/database design; Database ERM; SAP - SERM – SeDaM; IEF data model; Relations diagram;
data warehousing administration/access management Table diagram; Class diagram; Class description diagram
Groupware Integrating Lotus Notes and ARIS
PC hardware and network Identification of the IT infrastructure requirements; Network topology; Network diagram
management Documentation of the IT infrastructure; Access
privileges
Activity-based cost Description of the process and organizational eEPC; PCD; Organizational chart; CD Diagram; Cost category
calculation structures; Cost centre analysis; Process calculation diagram
Quality management Structure of QM documentation; Certification Product tree; Product selection matrix; eEPC; PCD; Office process
procedure; Certification documents diagram; Industrial process diagram; Value-added chain diagram;
Structuring model; Organizational chart
Reorganization measures Project documentation; Reorganization Value-added chain diagram; eEPC; Organizational chart; Product
implementation model; Performance model; Objective diagram; PCD
Introducing ERP SAP R/3 Phase analysis; Specification (project preparation); eEPC; Organizational chart
Phase design (business blueprint)
Software development and Project documentation; Determination of application Value-added chain diagram; Organizational chart; eEPC; Use case
introduction systems and modules; Description of the DP diagram; Application system diagram; Application system type
processes; Development of the system interface diagram; Program flow chart; Screen diagram
Knowledge management Knowledge map, or Yellow page; Knowledge Knowledge map; Knowledge structure diagram; eEPC; PCD; Office
categorization; Knowledge processing in business process; Industrial process; Function allocation diagram
processes
Workflow management Process customizing of workflow management systems Right diagram; eEPC; Function allocation diagram; Application
system diagram; Application system type diagram
Lecture 6-7
BUSINESS MODELLING
MODELLING NOTATIONS
EPC, IDEF, UML, BPMN
Ingredients of business process
Perspectives of Process Modelling
Historical Overview
• Behavioural perspective
• Functional perspective
• Structural perspective
• Goal and Rule perspective
• Object-Oriented perspective
• Communication perspective
• Actor and Role perspective
• Topological perspective
Behavioural Perspective
• Basic concepts:
– states,
– transformations;
• Languages:
– ST Diagrams, ST Matrices, Petri Nets, Coloured
Petri Nets, System Dynamics;
• Vocabulary:
– state, event, condition, transition, action.
Functional Perspective
• Basic concepts:
– activities (transform input into output),
– information and resources;
• Languages:
– Use Case/Activity Diagram/Context Diagram
(UML), IDEF, DFD, EPC, BPMN;
• Vocabulary:
– input, output, transition, action.
Structural Perspective
• Basic concepts:
– entities, attributes, data
– relationships;
• Languages:
– ER;
• Vocabulary:
– entity, attribute, relationship.
Goal and Rule Perspective
• Basic concepts:
– rules,
– constraints;
• Languages:
– Event-Condition-Action (ECA), Declarative
Approaches;
• Vocabulary:
– rule, rule violation, constraint.
Object-Oriented Perspective
• Basic concepts:
– object,
– class;
• Languages:
– UML, PML;
• Vocabulary:
– object, class, encapsulation, inheritance,
polymorphism, subtyping.
Communication Perspective
• Basic concepts:
– speech act theory concepts,
– private goals, coordinating action;
– negotiation commitment;
• Languages:
– COORDINATOR, Action Workflow;
• Vocabulary:
– speaker, hearer, time, location,
circumstances.
Actor and Role Perspective
• Basic concepts:
– role, actor, agent,
– resource, event (exchange, conversion);
• Languages:
– Role Interaction Nets (RIN), Role Activity
Diagram (RAD), Role Interaction Diagram
(RID), Role Enterprise Architecture (REA);
• Vocabulary:
– swimlane, pool, role, actor, agent.
Topological Perspective
• Basic concepts:
– space, place, location, geography,
– process place, distributed process, groups;
• Languages:
– Extended Activity Diagram (UML);
• Vocabulary:
– state, event, condition, transition, action,
communication infrastructure, location.
BPM modelling notations
• There are many languages for modelling business processes
diagrammatically. Perhaps one of the oldest ones are flowcharts. In their
most basic form, flowcharts consist of rectangles, representing activities,
and diamonds, representing points in the process where a decision is made.
More generally, we can say that regardless of the specific notation used, a
diagrammatic process model typically consists of two types of node:
activity nodes and control nodes. Activity nodes describe units of work
that may be performed by humans or software applications, or a
combination thereof. Control nodes capture the flow of execution between
activities. Although not all process modelling languages support it, a third
important type of element in process models are event nodes. An event
node tells us that something may or must happen, within the process or in
the environment of the process, that requires a reaction. Also other types of
node may appear in a process model.
• Several extensions of flowcharts exist, like cross-organizational flowcharts,
where the flowchart is divided into so-called swimlanes that denote
different organizational units (e.g. different departments in a company).
Event Process Chain Diagram (EPC)
Semantics
• Functions:
activities of the business process
• Events:
EPC EPC
pre- and post-conditions of functions Activity Pre- & Post-
Function Event condition
• AND split:
activates all subsequent branches
in concurrency
XOR XOR
• OR split: Join Split
triggers one, two or up to all of multiple
subsequent branches.
• XOR split: AND AND
defines a choice to activate one of multiple Join Split
subsequent branches.
• AND join:
waits for all incoming branches to complete. OR OR
• OR join: Join Split
waits for all active branches to complete.

• XOR join:
continue when one of alternative branches
has completed.
Event Process Chain Diagram - EPC
Evolution of IDEF
• IDEFØ Function (Activity) Modeling
• IDEF1 Information Modeling
• IDEF1X Data (Logical Data) Modeling
• IDEF2 Dynamic (Process) Modeling
• IDEF3 Process Modeling

• IDEF4 Object-oriented Design/Analysis
• IDEF5 Ontology Description
• IDEF9 Business Constraint Description
Evolution of IDEF
Currently Envisioned Methods:

 IDEF6 - Design Rationale Capture
 IDEF7 - Information System Audit Method
 IDEF8 - Human-System Interaction Modeling
 IDEF9 - Business-Constraint Discovery Method
 IDEF10 - Implementation Architecture Modeling
 IDEF11 - Information Artifact Modeling
 IDEF12 - Organizational Design Method
 IDEF13 - 3-Schema Architecture Design Method
 IDEF14 - Network / Distribution Design Method
Evolution of IDEF
Released methods (published method reports)

 IDEF3 - Process Description Capture
 IDEF4 - Object-Oriented (OO) Design
 IDEF4C++ - OO Design using the C++ Language
 IDEF5 - Ontology Description Capture
 IDEF6 - Design Rationale Capture
 IDEF8 - Human Systems Interaction Design
 IDEF9 - Business-Constraint Discovery
 IDEF14 - Network Design
IDEF0 – ICOM Box
Controls (constraints on an activity, e.g.,

procedures, budgets, etc.)
Inputs Function or Outputs

Activity
(what is required (Verb Phase) (what is produced by an
before an activity can activity, e.g., reports,
occur, e.g., purchase products, etc.)
order, supervisor’s Call
signature, etc.) (sub-system used in a non exclusive
Mechanisms
way - can not be detailed as a sub-
function)
(what enables an activity, e.g., equipment,
personnel assignments, etc.)
What is IDEF0?
• Developed since 1970s.
• USAF (US Air Force) Project ICAM (Integrated Computer
Aided Manufacturing).
• ICAM DEFinition (IDEF): Structured modelling languages.
• Objective: Description of functions of the enterprise
with the help of graphical notations.
• At the origin, IDEF0 was developed to improve the
communication between actors trying to understand the
system.
• Today, IDEF0 is used for documentation, understanding,
design, analysis, planning, and integration.
IDEF0 – types of diagrams
• Top-level context diagram (A-0)

– each model shall have a top-level context diagram
– present the subject of the model by a single box with
its bounding arrows
• Child diagram
– decompose higher level context diagram into its
major sub-functions
• Parent diagram
– contains one or more parent boxes
Remark: a diagram may be both a parent diagram and a child diagram

IDEF0 – ICOM Box
An Example
Introduction to UML
Architecture and Requirements
• Use Case Diagram
Use case diagram describes a system‘s external behaviour from the user‘s
perspective.
• Activity Diagram
Used for high level descriptions of program behaviour, often associated with software
architecture. It shows:
– the activities a program carries out,
– which activities may be conducted in parallel,
– which activities must be synchronized for correct operation.
• Module diagram
One of the main diagrams used to describe software architecture. It:
– shows calling dependencies between modules.
• Architectural Diagram
Like a module diagram but may show non-module files
• Context diagram
Also a high level description, used in documentation of architecture. It is:
– used to show how a program interacts with its environment.
Introduction to UML
Architecture and Requirements
• Data Flow diagram
Used in requirements documents. It:
– represents processing requirements and the information flows necessary to sustain them.
• Class diagram (OMT diagram)
– shows classes that are used in a program along with their relationships,
– sometimes also shows their physical packaging into modules
• Event Trace diagram
– illustrates the timing of important messages (member function invocations) between objects
in the program
• Structure Chart
– shows calling relationships between every function in a module and the calls into and out of
the module
• State Diagram
– shows how program navigates through its states
• Data structure diagram
– illustrates the layout and relationships between important pieces of data in the program
Unified Modelling Language in BPM
UML Models: UML Use Case Diagram
• In a UML Use case diagram application
cases (Use cases) and Actors involved in
the use cases are described. Actors
represent users who use an application
system to perform their tasks. The UML
Use case diagram describes a system‘s
external behaviour from the user‘s
perspective.
• Connections between Actors and Use cases
are communicates with relationships. They
express the fact that the Actor is
executing the Use case. Relationships
between Use cases are established with a
generalizes relationship, whose
connections are depicted with a triangular
point. Extends depicts an extended
relationship in which one Use case extends
the application of another Use case, in
exceptional situations, for example. Uses
depicts a uses relationship. If this is the
case, the Use case uses the application
case description of another Use case,
allowing it to be re-used.
• Often, when naming relationship types they can
only be read in one direction for the links to
make sense. We differentiate between a
number of relationship types. In this context,
the number of entity types they link, on the one
hand, and the degree of a relationship’s
complexity, on the other hand, serve as
distinguishing criteria.
• Definition: The degree of complexity or
cardinality indicates how many entities of one
entity type are assigned to an entity of the
other entity type.
• Four different kinds of relationships can be
distinguished (cardinalities): 1:1 relationship, 1:n
relationship, n:1 relationship, n:m relationship.
– In a 1:1 relationship, each entity of the first set is
precisely assigned to an entity of the second set.
– In a 1:n relationship, each entity of the first set is
assigned to each entity of the second set, but n entities of
the first set are assigned to each entity of the second set.
– An n:1 relationship carries out the same task but in the
reverse order.
– In an n:m relationship, several entities of the second set
are assigned to one entity of the first set and vice versa.
UML Models: UML Activity Diagram
• A UML Activity diagram describes the process as a
sequence of activities. In UML, Activities refer to objects.
• Because activity diagrams are considered to be a special
form of automatic status, an activity diagram must begin
with an Initial state and end with a Final state. Activities
represent a state with an internal action and one or more
outgoing transitions. Activities may have simple or
multiple relationships with other activities:
– Several outgoing conditions can be formulated as Decision conditions
(diamond). Modelling a condition with the Decision symbol is optional;
alternatively, users could simply model several outbound connections. It
is recommended that the condition in the Connection role attribute of
the is predecessor of or activated relationship connection be shown in
the model.
– The Split/Synchro symbol (vertical or horizontal dash) can be used to
activate several sequential Activities at the same time, or to make the
activation of an Activity with the transitions of previous Activities.
• Activities may assume specific object states and create
specific object states as a result. Object states are
depicted by the Object state object type, which possesses
has input or has output connections (dashed arrows) in
the form of relationships with Activities. UML depicts the
organizational responsibility for executing Activities using
so-called “swimlanes.“ A swimlane is a column listing all
Activities for which an organizational unit is responsible.
UML Models: UML Statechart Diagram
• A UML Statechart diagram
depicts automatic status and
describe a process as a sequence
of activities, but focuses on
object states. It describes the
sequence of states that an object
can assume in the course of its
existence. Furthermore, it can
contain actions related to the
state. These actions are either
prerequisites for the entry of a
state (entry/), are executed
during the state (do/), or are
executed upon leaving the state
(exit/).
• The UML Statechart diagram
provides the State symbol. State
transitions, also called
transitions, connect the States
using directed connections (has
transition to). As with the UML
Activity diagram, a statechart
must begin with an Initial state
and end with a Final state.
BPMN language in BPM
• Origins of BPMN
– The Business Process Management Institute (BPMI—now a part of
the OMG) develops BPML (an XML process execution language)
and realizes need for a graphical representation
• BPML was later replaced by BPEL as the target execution language
– August, 2001, the Notation Working Group is formed. The group
was composed of 35 companies, organizations, or individuals.
– BPMN 1.0, BPMN 2.0
• May, 2004, the BPMN 1.0 specification was released to the public.
• February, 2006, BPMN 1.0 was adopted as an OMG standard.
• January, 2011, BPMN 2.0 was adopted as an OMG standard.
Introduction to BPMN
• What is Process Modelling?
– The capturing of an ordered sequence of business activities and
supporting information
– Business processes describe how a business pursues its objectives
• There are different levels of process modelling:
• Process Maps – simple flow charts of the activities
• Process Descriptions – flow charts extended with additional information,
but not enough to fully define actual performance
• Process Models – flow charts extended with enough information so that
the process can be analysed, simulated, and/or executed
BPMN supports each of these levels

Business Process Modelling by BPMN
• Real business process

• Model of business process
Business process model

Packaging
A1 A3
Advisor
A2 A5
Manager
Quality Assurance
A4
Account
Accounting
Shipping
• Advantages of modelling the business processes
• Better understanding of existing business processes
• Documents the business process
• Basis for improving existing business processes
• Basis for experiencing and simulating new concepts and impact
on the organisation
• Basis for continued optimisation
• Basis for creating information systems that support the business
processes
• One One type is known as Workflow Management Systems
• Challenges
• Difficult to model the world with people and systems interacting
together.
• Real world process is not understood.
• Different people has different views of the process.
• Processes often cross organisational borders.
• No common vocabulary to use.
• Many different aspects of a process. It can consist of several
models at different abstraction levels linked together.
• Business Process Modelling Notation(BPMN)

• Similar to UML activity diagrams
• Contains much more symbols-> easier to
visualise how the process should behave.
• Can model most of the 21 workflow patterns
• 3 Kinds of Processes
– Private (Internal) Business Processes
– Abstract (Public) Processes
– Collaboration (Global) Processes
• Private (Internal)
– Private (Internal) Business Process
– Internal to a specific organization
– Represents typical Workflow or BPM Processes
Notify Applicant of
Determine Order Check Record of Determine Approve or Reject
Approval or
is Complete Applicant Premium of Policy Policy
Rejection
• Abstract (Public) Process

– Interactions between a private business process and another
process or participant
– Shows only the activities that communicate outside the private
process, plus flow control
Patient
8) Pickup your medicine

6) I feel sick 10) Here is your medicine
and you can leave
1) I want to see doctor
5) Go see doctor 9) need my medicine
Doctor’s Office
Receive Send Receive

Receive
Doctor Send Appt. Prescription Medicine Send Medicine
Symptoms
Request Pickup Request
• Collaboration (Global) Process

– Interactions between 2 or more business entities
– Shown as 2 or more abstract processes communicating with each
other
– The private representations of the processes will contain much
more details
Patient
Receive
Send Doctor Send Send Medicine Receive
Receive Appt. Prescription
Request Symptoms Request Medicine
Pickup
Illness
Occurs
8) Pickup your medicine
6) I feel sick 10) Here is your medicine
and you can leave
1) I want to see doctor
5) Go see doctor 9) need my medicine
Receptionist/
Doctor
Receive Send Receive

Receive
Doctor Send Appt. Prescription Medicine Send Medicine
Symptoms
Request Pickup Request
• Organisational Elements in Process Models - Two basic
abstractions:
– Resource: Human actor or equipment (e.g. printer) that is required to
perform an activity
– Resource class: Set of resources with shared characteristics, e.g. Clerk,
Manager, Insurance Officer. A resource class may be a:
• Role (skill, competence, qualification)
Classification based on what a resource can do or is expected to do.
• Group (department, team, office, organizational unit)
Classification based on the organization’s structure.
• Resource Modelling in BPMN
– In BPMN, resource classes are captured using:
• Pools – independent organizational entities, e.g.
– Customer, Supplier, City Hospital, Clinic
• Lanes – resource classes in the same organizational space and sharing common systems
– Sales Department, Marketing Department
– Clerk, Manager, Engineer
• Pools and Lanes – Notation

• Order Management Process with Pools

Customer
Place
Make
purchase
payment
order
Invoice
Order Rejection Notification Shipment notification
Purchase Order confirmation

order notification Send invoice
Confirm order
Supplier
Check stock
Ship goods
availability
Reject order
• Elements of BPMN
• Elements of BPMN
• Elements of BPMN 2.0
• Elements of BPMN 2.0
• Elements of BPMN 2.0 in process flow
• Elements of BPMN 2.0 in process flow
(Examples)
(Example)
more Trackpoints
Issue
Log Trackpoint
Trackpoint
Order Entry
Notice
Create
Acceptance
Certificate
Freight delivered
Initiate
Shipment
Status Inquiry
24 hours
(Insurance claim completion example)
Valid?
Registering Evaluation
Checking No Sending
validity refusal decision
Yes
Simple? Yes
Insurance
Evaluation of No Sending form Checking No

for complex
severity completeness
claim
Yes Complete?
Sending form
for simple claim
Claiment
Preparing claim Filling forms Updating forms
Build the process model with BPMN (iGrafx 2013 Process for SixSigma) for the following
Claim Completion process definition. When a claim is received, it is first checked whether
the claimant has a valid insurance policy. If not, the claimant is informed that the claim is
rejected due to an invalid policy. Otherwise, the severity of the claim is evaluated. Based on
the outcome (simple or complex claims), relevant forms are sent to the claimant. Once the
forms are returned, they are checked for completeness. If the forms are complete, the claim
is registered in the Claims Management system and the evaluation of the claim may start.
Otherwise, the claimant is asked to update the forms. Upon reception of the updated forms,
they are checked again.
(Insurance claim completion example)
(Airport example)
Patterns of process flow
• Sequence pattern
• Split pattern (and, or, xor)
• Join pattern (and, or, xor, N-out-of-M)
• Multi-merge pattern
• Discriminator pattern
• Cycles pattern
Type of process flow pattern Semantics
Sequence pattern
M. Weske: Business Process Management,

© Springer-Verlag Berlin Heidelberg 2007
A B
Even ordering induced by sequence
enable begin terminate enable begin terminate

a b
Sequence pattern with a loop Fig 4.2. Sequence pattern, with event diagram of process instance
A B
a1 b1 a2 b2 a3 b3

Split pattern (and) Fig 4.3. Sequence pattern as part of a loop and event diagram showing three loop iterations
enable(b)
B
Even ordering induced

A
by and split
C terminate(a)
enable(c)
Fig 4.4. And split pattern

Split pattern (or) terminate(a)
enable(b)

Option 1:
Enable b
B Option 2:
Enable c
A
terminate(a)
enable(c)
C
enable(b)
Option 3:
Enable b and c
terminate(a)
enable(c)
Fig 4.8. Or split pattern
Split pattern (xor) B

terminate(a)
enable(b)
Option 1:
Enable b
A
Option 2:
Enable c
C
terminate(a)

enable(c)
Fig 4.6. Xor split pattern
Join pattern (and) B

terminate(b)
Even ordering induced
by and join
enable(d)
C
terminate(c)
Fig 4.5. And join pattern

Join pattern (or)
terminate(b)
enable(d)
Option 1:
b terminates
enable(d)
B
Option 2:
terminate(c)
D c terminates
C terminate(b)
Option 3:
b and c terminate
enable(d)
terminate(c)
Fig 4.9. Or join pattern
Join pattern (xor)

terminate(b)
B enable(d)
Option 1:
b terminates
D
Option 2:
c terminates
C
enable(d)
terminate(c)

Fig 4.7. Xor join pattern
Multi merge pattern

terminate(b)
B enable(d1)
When
b terminates
MM D
When
c terminates
C
enable(d2)
terminate(c)
Discriminator pattern terminate(b)
B
enable(d)
First b terminates
Dis D
When now
c terminates, the discriminator is
C ready for the next thread
terminate(c)
Fig 4.13. Discriminator pattern

N-out-of-M join pattern terminate(b)
B
enable(e)
C 2 E
terminate(c)
When any 2 activity instances in

{b,c,d} terminate, e is enabled
D
(in the example b and c terminated)
Fig 4.16. N-out-of-M join pattern

Arbitrary cycles pattern
A B C D
Fig 4.17. Graphical representation of arbitrary cycles pattern

BPMN Examples
Loan application
BPMN Examples
Timer events in billing
• Exercise. Model the billing process of an Internet Service Provider (ISP). The ISP sends an invoice
by email to the customer on the first working day of each month (Day 1). On Day 7, the customer
has the full outstanding amount automatically debited from their bank account. If an automatic
transaction fails for any reason, the customer is notified on Day 8. On Day 9, the transaction that
failed on Day 7 is re-attempted. If it fails again, on Day 10 a late fee is charged to the customer’s
bank account. At this stage, the automatic payment is no longer attempted. On Day 14, the
Internet service is suspended until payment is received. If on Day 30 the payment is still
outstanding, the account is closed and a disconnection fee is applied. A debt-recovery procedure
is then started.
BPMN Examples
Replenishment ordering with event-based exclusive split
• The competition between external events is captured by means of the event-based exclusive
(XOR) split. An event-based exclusive split is represented by a gateway marked by an empty
pentagon enclosed in a double-line circle. Example below features an event-based exclusive split.
When the execution of the process arrives at this point (in other words—when a token arrives at
this gateway), the execution stops until either the message event or the timer event occurs.
Whichever event occurs first will determine which way the execution will proceed. If the timer
event occurs first, a shipment status inquiry will be initiated and the execution flow will come
back to the event-based exclusive gateway. If the message signalling the freight delivery is
received first, the execution flow will proceed along the sequence flow that leads to the AND-
join.
BPMN Examples
Travel Agency
BPMN Examples
Log in to bank account
(Compensations, exceptions and cancellations)
• Events may change

the flow
• Events can interrupt activities
– Activity stops
– Flow proceeds from the event
 Activities can be transactions

 Transactions have double borders
 Compensation events occur when the
transaction doesn’t complete
 For example:
Typical BPM modelling errors
• Process formation errors

– Cell processing
• Path errors
– Quick looping
– Deadlock
• Process mapping errors
– Decision redundancy
• Notation errors
BPM modelling errors & solutions
Process vs. nest (cell) orientation
Quick looping
Deadlock
Deadlock
Deadlock and Livelock
Too many decisions (gates)
Too many decisions (gates)
Notation errors
What BPM modellers can learn from programmers?
Volker Gruhn, Ralf Laue, Computer Science Faculty, University of Leipzig (2006)
• Common errors in BPM maps and their corrections

What BPM modellers can learn from programmers?
Volker Gruhn, Ralf Laue, Computer Science Faculty, University of Leipzig (2006)
• Results of BPM maps surveys

BPMN vs. EPC
Some comparisons
BPMN vs. EPC
Some comparisons
Guidelines of BPM modelling
• The investigation for any improvement is not new, neither is the one for best
practices. Best-practices research also can be one of the most effective tools for
organizational improvements. More than a century ago, within theory of management
studies (e.g. by Frederick Taylor) some empirical bases for best practices in
organizations were already presented. Thus began the real search for best practices
as means for organizational improvement. Business process management (BPM)
modelling is applied in practice, but failures, pitfalls, and quality of models as a
result of best practice guidelines, have not been considered very often. It seems
that, a problem is still the low level of modelling competence and a lack of
commonly accepted standards.
• Existing approaches towards selection of better approaches to increase quality of
BPM models might be of benefit, but frameworks like SEQUAL and the Guidelines of
Modelling are too abstract to be applicable for beginners and non-experts in practice,
and collections of pragmatic issues are presented without a research foundation.
Becker et al [3] presented a framework (GoM) to structure factors for the evaluation
of process models. Also Mendling et al [15] presented a study of research on
relationships between model structure and error probability with a synthesis as a set
of seven process modelling guidelines (7PMG). These guidelines are built on strong
empirical insights, and are formulated to be rational to practitioners.
Best practices in BPM modelling
Best practices in BPM modelling
BUSINESS PROCESS MODELS
(Matrix methods: Service Blueprint)
• Service Blueprint
– Infrastructure Elements, Customer Activities, Direct-Contact Staff,
Back-Stage Activities, Supporting Elements
– Example:
(Matrix methods: Service Blueprint)
• Service Blueprint
– Example:
(Matrix methods: RACI, SIPOC, CATWOE)
• RACI matrix
– Responsible, Accountable, Consult, Inform
– Example:
• SIPOC matrix
– Supplier, Input, Process, Output, Customer
– Example:
• OBASHI matrix
– Ownership, Business Process, Applications, Systems, Hardware, Infrastructure
• CATWOE representation in SSM

– Customer, Actors, Transformation, Worldview, Output, Environment
(Matrix methods: FMEA)
• FMEA
– Procedure that examines each item or process in a system, considers
how that item can fail and then determines how that failure will affect
(or cascade through) the system.
– FMEA is a systematic method of identifying and preventing system,
product and process problems before they occur.
– FMEA is focused on preventing problems, enhancing safety, and
increasing customer satisfaction.
– Ideally, FMEA’s are conducted in the product design or process
development stages, although conducting an FMEA on existing products
or processes may also yield benefits.
– Acronyms:
• FMEA: Failure Modes and Effects Analysis
• FMECA: Failure Modes and Effects and Criticality Analysis
• FMEA motivation
– Improves design by discovering unanticipated failures.
– Highlights the impact of the failures.
– Potentially helpful during legal actions.
– Provides a method to characterize product safety.
– Often required (e.g. procurement).
• FMEA steps
– Identify all components or systems at given level of the design hierarchy.
– List the function of each identified component or system.
– Identify failure modes for each component/system. Typically there will be several ways in
which a component can fail.
– Determine the effect (both locally and globally) on the system.
– Classify the failure by its effects on the system operation.
– Determine the failure’s probability of occurrence.
– Identify how the failure mode can be detected (may point out what needs to be inspected on
a regular basis).
– Identify any compensating provisions or design changes to mitigate the failure effects.
• FMEA decomposition
– Function comes from functional analysis, functional decomposition
– Potential failure mode comes from things that have gone wrong in the past, concerns of
designers, and brainstorming. Possible considerations are partial function, intermittent
function, excess function.
– Potential effects are consequences to the design, the user, and the environment. Safety and
regulation noncompliance are critical issues.
• FMEA calculations and planning (what to do?)

– Assign values to Severity, Occurrence, and Detection using the tables (next page).
– Determine the RPN (Risk Priority Number): Severity * Occurrence * Detection.
– Develop an action plan.
– Implement an action plan.
• FMEA effect ranking
• FMEA occurrence ranking
• FMEA detection ranking

The issues for BPM modelling
1. Strength of the functional organisation.
2. Lack of true integration due to inadequate
communication and collaboration between internal
functions and external partners (suppliers etc.).
3. Weak advance planning of projects — lack of
coordination.
4. Poor estimating and planning of human and other
resources.
5. Lack of human resource (particularly in the engineering
functions).
6. Lack of standardisation, particularly at process level
(weak process understanding across functions).
Critical enablers for BPM
• There are five critical enablers for a high-performance process:
– Process design. This is the most fundamental aspect of a process: the specification of what
tasks are to be performed, by whom, when, in what locations, under what circumstances, to
what degree of precision, with what information, and the like. The design is the specification
of the process; without a design, there is only uncoordinated individual activity and chaos.
– Process metrics. Most enterprises use functional performance metrics, which create
misalignment, sub-optimization, and confusion. Processes need end-to-end metrics that are
derived from customer needs and enterprise goals. Targets need to be set in terms of these
metrics and performance monitored against them. A balanced set of process metrics (such as
cost, speed, and quality) must be deployed.
– Process performers. People who work in processes need a different set of skills and
behaviours from those who work in conventional functions and departments. To realize the
potential of end-to-end work they need an understanding of the overall process and its goals,
the ability to work in teams, and the capacity to manage themselves.
– Process infrastructure. Performers need to be supported by IT and HR systems if they are to
discharge process responsibilities. Functionally fragmented information systems do not
support integrated processes, and conventional HR systems (training, compensation, and
career, etc.) reinforce fragmented job perspectives. Integrated systems (such as ERP systems
and results-based compensation systems) are needed for integrated processes.
– Process owner. An organization serious about its processes must have process owners: senior
managers with authority and responsibility for a process across the organization as a whole.
Principles of BPM
• It can be helpful to summarize the concepts of process
management in terms of a handful of axiomatic
principles, some obvious, some not, that together
express its key themes :
– All work is process work;
– Any process is better than no process;
– A good process is better than a bad process;
– One process version is better than many;
– Even a good process must be performed effectively;
– Even a good process can be made better;
– Every good process eventually becomes a bad process.
Principles of BPM
• All work is process work. Sometimes the assumption is made that the concepts of
process and process management only apply to highly structured, transactional work,
such as order fulfilment, procurement, customer service, and the like. Nothing could
be further from the truth. The virtues of process also adhere to developmental
processes, which centre on highly creative tasks, such as product development,
demand creation, and so on. Process should not be misinterpreted as a synonym for
routine or automation, reducing creative work to simplistic procedures. Process
means positioning individual work activities – routine or creative – in the larger
context of the other activities with which it combines to create results. Both
transactional and development processes are what is known as core processes –
processes that create value for external customers and so are essential to the
business. Organizations also have enabling (or support) processes, which create value
for internal customers; these include hire to retire, information systems
development, and financial reporting. Such processes have customers and create
value for them (as must any process, by definition), but those customers are internal.
The third category is governing processes, the management processes by means of
which the company is run (such as strategic planning, risk management, and
performance management). (Process management is itself a governing process!)
Principles of BPM
• Any process is better than no process. Absent a well-defined process design, chaos
reigns. Individual heroics, capriciousness, and improvisation rule the day – and results
are inconsistent and unsustainable. A well-defined process will at the least deliver
predictable, repeatable results, and can serve as the staging ground for
improvement.
• A good process is better than a bad process. This statement is not as tautological as
it seems. It expresses the criticality of process design, that the type of a process
design is a critical determinant of its performance, and that some processes are
better designed than others. If a company is burdened a bad process design, it needs
to replace it with a better one.
• One process version is better than many. Standardizing processes across all parts of
an enterprise presents a single face to customers and suppliers, yields profound
economies in support services such as training and IT systems, allows the
redeployment of people from one business unit to another, and yields a host of other
benefits. These payoffs must be balanced against the intrinsically different needs of
different units and their customers, but our bias should be in favour of
standardisation.
Principles of BPM
• Even a good process must be performed effectively. A good process design is a
necessary but insufficient prerequisite for high performance; it needs to be combined
with carefully managed execution, so that the capabilities of the design are realized
in practice.
• Even a good process can be made better. The process owner needs to stay
constantly vigilant, looking for opportunities to make modifications to the process
design in order to further enhance its performance.
• Every good process eventually becomes a bad process. No process stays effective
forever in the face of change. Customer needs change, technologies change,
competition changes, and what used to be a high level of performance becomes a
poor one – and it is time to replace the formerly good process with a new one.
Lecture 8-11
BUSINESS SIMULATION MODELLING
CONTINUOUS AND DISCRETE SIMULATION,
BUSINESS AND MANAGEMENT GAMING
OPERATIONS RESEARCH (OR/MS) IN MANAGEMENT
(History)
Operational Research (UK), Operations Analysis (USA-air force), Operations Research

(USA-force), Operations Evaluation (USA-navy)
History of largo OR activities - some early examples
• Platon i Xenofont
• Leonardo da Vinci
• Pascal (1642) - calculating tool
• Guillame Amontons (1663-1705) – workforce,
• Vauban (Strasbourg, 02.06.1668) - time management
• De la Hire (geometry) - workforce calculation in military constructions
• Jean-Rodolphe Perronet (1708-1794, 1739) - work and cost studies
• Adam Smith (1723-1790, 1778) - work and cost studies
• Coulomb (24.02.1798) - agricultural work memorial
• Eli Whitney (1798), Colt - continuation of Whitney's work
• Fourier (1829) - work allocation
• Louis Blanc (1841) - work organisation
• Charles Babbage (1832): On the economy of machinery & manufactures
OPERATIONS RESEARCH (OR/MS) IN MANAGEMENT
(History)
History of largo OR activities – XXth C.

• Frederic Winslow Taylor (1874, 1895, 1898, 1903, 1947) - management
• Henry L.Gantt (1861-1919) - management
• Frank B., Lilien M. Gilbreth - management
• Walter Shewhart (1920) - statistic quality control
• Ford Harris (1915), R.H.Wilson (1926) - inventory control
• F.E.Raymond: Quantity and Economy in Manufacture
• F.J.Roethlisberger (1927-1939) - Hawthorne experiment
• L.H.Tippet (1930) - new application of statistics in production
• Walter Rautenstrauch - turning point
• Pile (gen. in UK): coordination work for radar project
• Blacket (physicist - Nobel Price): "Blacket's Circus", era of OR (1942)
• Ford-Fulkerson i Dantzing - optimization in networks, linear programming)
• Forrester (1958) – Industrial Dynamics simulation method
• Simon, Holt, Modigliani, Muth – forecasting, production engineering
• Bowmann&Fetter: Analysis for Production and Operation Management
• Mauchly Group (Du Pont): Mauchly, Kelley, Walker, at al. - CPM
• POLARIS Group (1958) - PERT
• Quantitative methods (more mathematics)
OR/MS FOR MANAGEMENT –
NEW CHALLENGE OR R.I.P.?
• CLASSICAL OR/MS METHODOLOGY

• OR/MS PROJECTS IN PRACTICE
• OR/MS AS A TOOL BOX? CRITICS OF OR/MS PARADIGMS
• SOFT OR/MS
• SIMULATION & AI AND SSM AND AS A REMEDY?
CLASSICAL OR/MS PARADIGMS
• PROBLEM, PROBLEM SITUATION

Real situation is described and formulated as a "problem" situation.
• PREDICT AND PREPARE
Basic formula for research procedure is "predict and prepare".
• SINGLE OBJECTIVE OPTIMISATION
Model is formulated with a single objective optimisation. Multiple objectives (if
considered) are translated on single objective.
• DATA PROBLEMS
There exists a crucial problem with data in terms of availability and credibility.
• SCIENTISATION AND DEPOLITICISATION
Scientism („science culture”) and depolitics (no conflicts of interests) are preferred
and a consensus is assumed.
• PEOPLE AS PASSIVE OBJECTS
People are treated as passive objects and they must just follow OR/MS conclusions.
• SINGLE DECISION MAKING
There is assumption of single decision maker with abstract objectives from which
concrete actions can be deduced through a hierarchical chain of command.
• ELIMINATION OF FUTURE UNCERTAINTY
There is attempting to abolish future uncertainty and pre-take future decisions.
SOFT OR/MS PARADIGMS
• NONOPTIMISATION
Non-optimisation and seeking alternative solutions that are acceptable on different
independent dimensions.
• DATA REDUCTION
Reducing data demands by integration, aggregation of hard and soft data with social
judgements.
• COMPLEXITY REDUCTION
Reducing complexity by simplification of models and clarifying different views.
• PEOPLE AS ACTIVE OBJECTS (SUBJECTS)
Including people as active subjects and developing group model building procedure.
OR/MS APPLICATION - SUCCESS OR FAILURE?
(3 Dimensions)
Dimension Factors
• Organisational changes,
Customer (client) oriented • Quantity of data (deficiency vs. accuracy),
• Quality of data (uncertainty vs. certainty),
• Scale of the problem (small-scale vs. large-scale),
• Organisational resistance to change,
• Complexity of the problem,
• Financial results (savings/profits vs. costs),
• Quality of decision making.
• Complexity of the model,
OR/MS oriented • Simplicity and clarity of the model,
• Flexibility and reusability of the model,
• Computer-time consumption,
• Time of solving problem (progress),
• Quality of modelling project management,
• Level of generalisation,
• Quality of software or technique.
Relation (social) oriented • Appropriateness between model and problem

(mismatch vs. fitting),
• Validity and relevance of the model and it's results,
• OR/MS people involvement,
• User-friendliness of the model,
• Higher management support,
• User involvement, co-operation and
comprehension.
OR/MS AND SIMULATION IN MANAGEMENT -
RESEARCH SURVEYS
Some research examples
W.J.Vatter (1967), G.W.Gershefski (1970), E.Turban (1972),

L.Lonnstedt (1973), T.H.Naylor, Ch.Jeffers (1975), P.H.Grinyer,
J.Wooller (1975), J.F.Cox, W.N.Ledbetter, J.M.Smith (1977),
N.Ledbetter, J.F.Cox (1977), C.Thomas, I.DaCosta (1979),
C.P.Pappis (1981), G.A.Forgionne (1983), C.B.Tilanus (1983),
F.N.Ford, D.A.Bradbard, J.F.Cox, W.N.Ledbetter (1987), P.Pappis,
G.D.Nikitas, S.Patrikalakis (1988), J.S.Moore, A.K.Reichert (1989),
J.Harpell, M.Lane, A.Mansour (1989), G.J.Scholl (1995), Ch.Kao i
S.T.Liu (1997), M.Pankowski (1984), R.Pietroń (1998), ...
OR/MS AND SIMULATION IN MANAGEMENT
• W.J.Vatter 1967
USA, questionnaire, 360/3500 corporations in USA (10.3%). Goal: Use
of OR techniques in corporations. Results: PERT/CPM (62.8%),
Statistics analysis (55.8%), Inventory theory (51.9%), Simulation
(50.3%), Linear programming (46.1%), Regression analysis (45.8%),
Queuing models (22.5%).
• J.Harpell, M.Lane, A.Mansour 1973, 1978, 1983
USA ORSA, questionnaire - people from ORSA Society: education
98/250 (39,2%), practice 92/250 (36,8%) in USA. Goal: usefulness of
OR techniques in practice, OR techniques education, quality and
opinions on of OR techniques education. Results: Statistics (54.3% /
44.3 %/ 43.7%), Probability analysis (23.9% / 17.0% / 17.7%), Linear
programming (22.9% / 21.6% /27.1%), Simulation (20.7% / 11.4% /
35.4%).
• Ch.Kao,S.-T.Liu 1997
Taiwan (China), questionnaire - sample of 2000 biggest Taiwan firms
(1000 from manufacturing, 1000 from service): 91/1000 (9.1%),
81/1000 (8.1%). Goal: use of OR in Taiwan firms, popularity of OR
methods, management functions in OR models. Results: Statistics
(85.5%), Networks (70.9%), Other probability models (69.2%), Linear
programming (61.6%), Simulation (59.3%), Decision theory (56.4%),
Math programming (48.3%), Queuing theory (36.6%).
• R.Pietroń 1998
Poland, questionnaire – sample of the best 100 Polish enterprises:
19%. Goal: use of simulation and other techniques (OR/MS) in Polish
firms in year 1998. Results: Statistics (63.2%), Simulation (57.9%),
Forecasting methods (47.4%), Linear programming (10.5%), Networks
(10.5%), Regression analysis (10.5%), Heuristics (10.5%), Expert
systems (5.3), Other (42.1%).
• The literature of BM contains much material on mathematical

models used to describe business and economic behaviour. By
contrast, the literature on theory of the individual industrial firm
seems to contain relatively less work on mathematical models for
the firm as a whole. Especially this is true for the dynamic, time-
dependent interplay of money, materials, and information flow
between parts of the industrial organization.
• The verdict seems to be generally accepted that model formulation
has thus far been rather unsuccessful. Many reasons are advanced
for failures, including influences of external effects, inherent
unpredictability of people, inability to get good data, impossibility
of controlled experiments and many others.
• Thus far, the comments have been mostly non-constructive criticism
of past efforts. However, if these judgements prove to be partly
correct, they may point the way toward new approaches to
mathematical models which are expected to predict and describe
the behaviour of economic & business systems and industrial
companies. This is also true for discussion on models for the
economy and for the individual firm.
• A brief, and perhaps too casual, examination of past attempts at

model building leads us to believe that the reasons for their limited
success lie much deeper and that the difficulties are of a more
fundamental nature. Some of these deficiencies are as follows:
– Closed loop systems
– Interrelationship of goods, money, information, and labour
– Volatility and irrationality
– Evaluation of models
– Linear equations, simultaneous algebraic equations
– Superposition
– Time intervals
– Differences of large magnitudes
– Model complexity, assumptions, omissions
– Explicit solutions
– Symbolism
– Coefficient accuracy
Simulation modelling in practice
(Source: Murthy S.P., Perera T., Successes and failures in UK/US development of simulation,
Simulation Practice and Theory, 2002, Vol. 9, pp. 333-348)
• UK/USA cultural differences in simulation needs

UK USA
Simulation is not taught at an undergraduate/ postgraduate level because US industry has identified a need for simulation and thus undergraduate
there is currently little requirement for simulation from within UK industry courses, i.e. Industrial Engineering, teach a significant level of simulation
Very few mechanisms of promotion have led to a lack of exposure and Much promotion of current and potential industrial applications of
awareness of the potential and importance of simulation within industry simulation has created much understanding and awareness of this
technology
The absence of a simulation community and events has seriously limited Vendors and industry have both managed to create a community of
the growth of simulation within industry, and forced a lack of simulation practitioners and conferences actively using and developing simulation in
experience industry
A shortage of relevant research within universities and industry has come Extensive research into simulation by universities and industry has
from the low priority and awareness of simulation evolved and supported the development and use of simulation within
industry
Lack of any company leader(s) has meant other companies have not Several companies lead the way in the use of simulation, enabling other
seen the application, benefits and importance of simulation within industry companies to recognise the practical capabilities and benefits of
simulation
Little company management support and confidence in simulation and Through previous education or earlier project successes, managers are
scepticism of its benefits come from their limited education and aware of the benefits of using simulation and support it as a business tool
experience
No corporate funding available to investigate the capabilities of simulation Often a corporate policy and funding available to further apply simulation
because of the limited resources to develop unknown technologies capabilities into new areas of the business
There is a lack of software vendors located in the country, limiting support The abundance and resources of software vendors located in the country
and close contact needed for industry to introduce and utilise simulation have offered the much-needed support in implementing simulation within
industry
Simulation modelling in practice
(Source: Murthy S.P., Perera T., Successes and failures in UK/US development of simulation,
Simulation Practice and Theory, 2002, Vol. 9, pp. 333-348)
• UK/USA differences in simulation practice

UK USA
Companies having one or two simulation experts due to their limited Develop structured teams of simulation experts and engineers, through team
application within the company, the lack of corporate funding and few building exercises and the availability of resources and educated recruits
educated recruits
Lack of corporate funding for simulation research and development plus The selection of software has been influenced by the high level of support
limited support from vendors has restricted the introduction of new software from vendors and resources to help introduce and develop this technology
Few isolated applications of simulation through Company leaders demonstrate practical benefits
lack of evidence that simulation is successfully and repeatedly apply simulation to their business
being introduced and applied by similar companies and experiencing successful project results
Simulation has a low company profile and is only used as an optional project Simulation used as an integral project tool within the business and major
tool within industry due to the lack of project successes and proven results projects due to past project successes and the strong management support
No evidence of companies reusing models, only model coding, for new Evident reuse of models, modules and coding for new model applications,
applications because of the limited number of applications conducted through model flexibility, model management, and easy access to models
Do not supply customers with fast model results through rapid modelling, There is an increasing importance of rapid modelling using model interfaces
using a front-end model interface or generic model templates and templates, to keep customers satisfied with fast model results
No established integration link between simulation and business systems to Emphasis on model data collection, management and the integrity of the
facilitate the collection of model data and the effective updating of models model using integration links with the principal sources of valid and real data
Low priority in sharing knowledge due to the few simulation experts within Retain and share knowledge within the company’s in-house expertise and
the company and the extensive use of consultants for modelling work focus on the development and management of a simulation knowledge base
The use of simulation does not extend past the few simulation experts Increasing numbers of new team recruits and domain users due to the
because of the availability of experienced users and lack of training provided transfer of knowledge and understanding across the company
No standardised procedures, methodologies or techniques in the effective Developed methodologies and standards to guide all users in the effective
manner of setting-up and approaching simulation activities within a company approach to modelling, project management and personal development
SIMULATION IN BUSINESS MODELLING
• Simulation etymology
Similis (Latin) - similarity, similar; Similo (Latin) – similar; Simulare
(Latin) - imitate, to be similar; Mimeisthai (Greek) - imitate, play
role; Imitatio (Latin) - imitation
• Simulation aspects
– System (systemic, holistic and interdisciplinary approaches, also
adaptation of various techniques);
– Genetic (biological, psychological and sociological conditions (e.g.
mimicry);
– Historical (permanent recurring of paradigms and methods over time,
inclination to simulate and forecast);
– Philosophical (relation to basic philosophical questions and problems);
– Cultural (individual behaviour, social context, education,
entertainment, ethics).
• Conditions to use simulation

– Lack of other methods
• There are not other methods to solve a research problem
(e.g. lack of analytical model solutions with a set of
differential equations).
– Economic benefits, ethical/biological circumstances
• There are other methods to solve a research problem, but in
terms of economic criteria (e.g. saving energy or
effectiveness), ethical or biological criteria (e.g. safety
conditions) it is less attractive or appropriate than using
simulation method.
• Simulation advantages
– Universal approach in various fields and domains
– Ability to aggregate or disaggregate the model
– Ability to eliminate time factor in system's observation
– Repeating simulation experiments with the same environment
– Ability to experiment in hard and difficult real environment
– Ability to do "non-destructive" research
– Ability to do research without prototyping
• Simulation disadvantages
– Lack of meta-rules to develop domain models
– Lack of universal methods in order to validate/verify models
– Lack of possibility to automate of modelling procedures
– Time and cost consuming method of model building
– Sensitivity of simulation project's effects to "art mistakes"
• Simulation errors
– Ill defined purpose of simulation research
– Insufficient level of model complexity
– Lack of model credibility and validity
– Using wrong methods and techniques in model building
– Inductive reasoning beyond experiment environment
– Little communication with model user in building stages
– Neglecting communication with user in simulation results transfer
– Ethical faults
• Philosophical origins of simulation

• Abstraction and idealisation
Abstraction in modelling is a mental "separation", neglecting and omitting object features and relations from a
set of objects considered as originals with focusing on selected important features and relations. Idealisation
creates ideal notions ("final", "finite"), which usually do not exist in reality. According to M.Weber, in natural
sciences dominates abstraction, while in human and social sciences (e.g. economy, management) dominates
idealisation.
• Empiricism (epistemological phenomenalism)
Empiricism (Greek empeiria - experience). All ideas come to us through experience (through the 5 senses or
through sensations like pain and pleasure). Knowledge is based on or derived from experience. Logical
Positivism to connect experience with rationalism (maths).
• Positivism (neopositivism)
Positivism (science culture) - knowledge by pure experience. Neopositivism (Vienna Circle) - sensitive and
mental experience with great role of a universal language. "Limits of my language are limits of my world"
(L.Witggenstein). Knowledge is obtained by interpreting positive results, successful experiments.
• Apriorism i aposteriorism
Apriorism (Latin a priori - original, primeval) , Aposteriorism (Latin a posteriori - secondary)
• Conventionalism
Theories as sets of sentences created from axioms and providing with conventions.
• Rationalism
Rationalism (Latin ratio - mind) - verification by rational evidences. Our mind is able to recognise the objective
structure of a truth by following pure reason (rationality) or intuition.
• Systemism, emergentism
Holistic and complex view to modelling real systems.
• Utilitarisms
Focus on practical applications.
• Definition of simulation
– General definition
• Simulation is a mapping of state history of an
original object by creation of state history on a
specific, dynamic model.
– Specific definition
• Simulation can be defined as a numerical
technique in order to make experiments on special
mathematics (formal) models, which describe
using digital machines (computers) behaviour of
complex systems in long term period of time
[T.H.Naylor 1975]
• Stages and model building procedures

1. Defining the system, problem situation and simulation purposes
2. Building the model (conceptualisation, formalisation)
3. Setting model input data
4. Model programming (operationalisation)
5. Validation and verification of the model
6. Planning the simulation experiments Validation Validation
7. Simulation experimenting Real system
8. Simulation results analysis and conclusion
9. Documenting the whole simulation project
10. Practical application of simulation results EX CM
Operational
Conceptual
1. Identification of
7. Implementation model
problem situation
of system’s
SM model
changes OM
6. Definition of
desired and
5. Comparison of possible changes Symbolic
2. Definition of models with real to implement
problem situation situation
model
Verification Validation
Real system
Systems
3. Definition of key thinking on
4. Concept models
elements of problem reality
development
situation
• Classifications of simulation models

• Process features
– Continuous models
– Discrete models
– Hybrid models
• Modelling openness
– Hard models
– Soft models
• Determinism vs. indeterminism (randomness)
– Deterministic models
– Stochastic models
• Types of simulation modelling projects

• Type 1: simulation modelling as a software engineering
project
• Type 2: simulation modelling as a design and gaming by
simulation game
• Type 3: simulation modelling as a project of
organisational change or intervention
• Type 4: simulation modelling as a group model building
and discussion
• Type 5: simulation modelling as a part of modelling by
BPM package
• Time factor in simulation

• Continuous simulation
E1 E2 E3 E4=E5 E6
Czas
DT DT DT DT DT
T1 T2 T3 T4 T5 T6
• Discrete simulation
E1 E2 E3 E4=E5 E6
Czas
T1 T2 T3 T4=T5 T6
Continuous Simulation
• CONTINUOUS SIMULATION
FORMAL BASES
– The methodology of continuous simulation is based on the state-space theory,
where a model of a dynamic system is a set of differential equations (or
difference equations), i.e. a set of state- equations.
– The model as a set of state-equations is build with selection of particular
variables - system's attributes. We have n attributes of a system being considered
and these attributes are interpreted as important in the conceptualisation
process. Then in the model conceptualisation we set their values and in this way
we determine current position of a material point in state-space as a vector:
x  x1 , x 2 ,..., x n 
xt   x1 t , x 2 t ,..., x n t 
  
x 1 t , x 2 t ,..., x n t 
• CONTINUOUS SIMULATION
FORMAL BASES
– The mathematical model of any dynamic system is formulated as a set of
differential equations describing and mapping meta-rules of some subject
domains, as regards the system being analysed. Assuming that we have first order
differential equations, the model is a following representation:

x 1 t   f1 x 1 t , x 2 t ,..., x n t , t 

x 2 t   f 2 x 1 t , x 2 t ,..., x n t , t 
....

x n t   fn x 1 t , x 2 t ,..., x n t , t 
• HISTORICAL BACKGROUND OF SD METHOD

– The history of application of System Dynamics method (SD method) started in the
early 50 of XX century, when in the "Lincoln" Laboratory at the M.I.T. (U.S.A.), a
young engineer Jay Wright Forrester launched in 1952 a military project "SAGE
System" for air defence system in U.S.A. The research group directed by Jay
Forrester, later on professor at Sloan School of Management, M.I.T., developed
and applied to industrial system modelling an original method of modelling
(1958). This method used some ideas of different theories and sciences:
cybernetics, automatics and computing. Because of its first non-military
applications in industry this method was called Industrial Dynamics (1961).
Afterwards, applications of this method were focused on investigations of Urban
Dynamic Systems (1970) and World Dynamics (1972). The bases for universal
applications of this method in system dynamics analysis was initiated in 1971,
when first book on Principles of Systems was published (1972).
• SYSTEM DYNAMICS AND MANAGEMENT SCIENCE

– System dynamics can be interpreted as the branch of management science which
deals with the dynamics and controllability of managed systems.
– The issues that SD addresses are:
• Under what circumstances, should the firm use different policies to control its behaviour as time
passes and circumstances change?
• How can its policies be designed so that the firm becomes robust against change and is able to create
and exploit opportunities and avoid, or defend itself against, setbacks?
• How can the organization design its information feedback structure to ensure that effective policies
become possible?
– The paradigm, or basic viewpoint and associated methodologies, of system
dynamics requires that we first define a 'system'.
– System is a collection of parts organized for a purpose.
– The system may fail to achieve its purpose.
Information
State Dk Knowledge
Consequences Ds Dc Action
Choice
• THE PARADIGM OF SYSTEM DYNAMICS

– We analyse a managed system so as to:
• model the ways in which its information, action and consequences components interact to
generate dynamic behaviour,
• diagnose the causes of faulty behaviour,
• tune its feedback loops to get better behaviour.
– The first is a wish to make matters better by suggesting how people can act
upon the system, which is why we term them 'managed systems'. This is
expressed in the important principle of robustness, which states that: the
system should always perform as well as the circumstances allow, regardless
of what the circumstances are.
– The second thing that managed systems have in common is the everywhere
presence of feedback loops in all these systems. There are, however, two types
of feedback loop: goal-seeking, or negative loops and growth-producing or
positive loops.
• SYSTEMS THINKING IN SD MODELLING

– Systems thinking:
• Seeing what’s below the surface
– Thinking Process Maps:
• Stocks/Accumulations
• Behaviour-Over-Time Graphs (BOTG)
• Causal Loops
• Stock/Flow Diagrams
• Dynamic Modelling
• SYSTEMS THINKING IN SD MODELLING

- ICEBERG MODEL
– Events
• What happened?
– Patterns of Behaviour
• What’s been happening?
• What are the trends?
• What changes have occurred?
– Underlying Structures
• What has influenced the patterns? (e.g.
policies, laws, physical structures)
• What are the relationships among the
parts?
– Mental Models
• What assumptions, beliefs, and values do
people hold about the system?
• DEFINITIONS OF SYSTEM DYNAMICS

– J.W.Forrester, the founder of system dynamics, defined it as (1961):
• . . . the investigation of the information-feedback characteristics of [managed] systems and the
use of models for the design of improved organizational form and guiding policy.
– R.G.Coyle, stated that system dynamics is (1979):
• . . . a method of analysing problems in which time is an important factor, and which involve the
study of how the system can be defended against, or made to benefit from, the shocks which falI
upon it from the outside world.
• or, alternatively: . . . that branch of control theory which deals with socio-economic systems, and
that branch of Management Science which deals with problems of controllability.
– E.F.Wolstenholme offered (1990):
• . . . a rigorous method for qualitative description, exploration and analysis of complex systems
in terms of their processes, information, organizational boundaries and strategies; which
facilitates quantitative simulation modelling and analysis for the design of system structure and
behaviour.
– None of these is completely satisfactory. Forrester does not say what type of
models are involved. Neither Forrester's nor Wolstenholme's definitions refer to
time, and Coyle’s does not mention information feedback. Wolstenholme rightly
mentions qualitative analysis but does not include the powerful optimization
methods.
– Perhaps something on the following lines will suffice to start us on our study:
• System dynamics deals with the time-dependent behaviour of managed systems with the aim of
describing the system and understanding, through qualitative and quantitative models, how
information feedback governs its behaviour, and designing robust information feedback
structures and control policies through simulation and optimization.
• ASSUMPTIONS OF SD METHOD:
– CAUSALITY
Description of systems by cause-effect relations.
– FOCUS ON DYNAMICS
Focus on dynamics (not kinetics) of changes in system's functioning. The sources for dynamics is system's
structure (feedbacks, delay, amplification) in dual aspects "real system - control system".
– CONTINUITY
Models represent continuous (quasi continuous) processes of continuous systems (interpreted as
continuous).
– PERIODIC REGULATIONS
Control actions in systems are being made periodically.
• PARADIGMS OF SD METHOD:
– MICROSTRUCTURE DRIVES MACROBEHAVIOUR
System’s behaviour has endogenous characteristic and comes from its structure. E.g. positive feedback
destabilise system and negative feedback stabilise system (in most cases).
– ISOMORPHISM OF STRUCTURES AND BEHAVIOURS
Systems with similar structures behave in similar ways. But also: systems with different structures may
behave in similar ways.
– ANTIINTUITIVE BEHAVIOURS (COUNTER INTUITIVE)
In complex systems it is difficult to predict system's behaviour. There are many myths and wrong believes
(archetypes) about system's behaviour.
– NON-LINEARITY OF SYSTEM'S BEHAVIOURS
Many systems (most of) behave in non-linear pattern (effect of feedbacks, delays,...).
– LIMITED RATIONALITY
Decisions are being made with reduced rationality.
– LACK OF MODELLING METAPRINCIPLES
Intuition, experts knowledge and experience, domain theories, empirical observations are to be used.
• A STRUCTURED APPROACH TO SYSTEM DYNAMICS ANALYSIS

– The first stage is to recognize the problem and to find out which people care about it, and
why. It is rare for the right answers to be found at this stage, and one of the attractive
features of system dynamics as a management science methodology is that one is often led
to reexamine the problem that one is attempting to solve.
– Secondly, and the first stage in system dynamics as such, comes the description of the
system by means of an influence diagram, sometimes referred to as a 'causal loop diagram'
or ‘cause-effect diagram’. This is a diagram of the forces at work in the system which appear
to be connected to the phenomena underlying people's concerns about it. Influence diagrams
are constructed following well-established techniques.
– Having developed an initial diagram, attention moves to Stage 3, 'qualitative analysis'. The
term simply means looking closely at the influence diagram in the hope of understanding the
problem better. This is, in practical system dynamics, a most important stage which often
leads to significant results.
– lf qualitative analysis does not produce enough insight to solve the problem, work proceeds
to Stage 4, the construction of a simulation model. At this stage, we exploit the important
property that the influence diagram can be drawn at different levels of aggregation. It is
usually not even necessary to show every single detail, because, if the influence diagram bas
been properly drawn, the simulation model can be written from it without a separate
stage of flow charting. Stage 5 is where results based on quantitative analysis start to
emerge. Initially, use is made of the insights from the bright ideas and pet theories from
qualitative analysis. This stage represents exploratory modelling of the system's
characteristic patterns of behaviour with the aim of enhancing understanding.
Stage 1 Problem Recognition

(who cares, and why)
Stage 2 Problem Understanding and System Description

(Influence Diagrams)
Stage 3 Qualitative Analysis

(bright ideas and pet theories)
Stage 4 Simulation Modelling

(special computer simulation languages)
Model testing
Stage 5 Policy Testing and Design

Sensitivity testing
5A Exploratory ModelIing and Policy Design by Simulation
(assessment by judgement)
Insights Ideas
(objective function)
5B Policy Design by Optimisation Robust Policies

Stage Result
Problem Definition
2 System Description 3 Understanding

(Influence Diagram) and Ideas
5A
4 Simulation Model Verification, Ideas
5B Policy Design Robust Policies

(e.g. optimisation)
• SOME BASIC SD MODELS’ ELEMENTS

Basic system’s and model’s elements
– ACCUMULATIVE STOCK/LEVEL Stock, level
PO
– FLOW (PO - symbol of a variable)
– RELATION Material or energetic rate

Document flow rate (orders, tasks)
Information flow
– FEEDBACK
Rate regulation
– AUXILIARY/CONVERTER STR
(STR - symbol of a variable)
– CONSTANT WPO
Axiliary variable
(WPO - symbol of a variable)
– FUNCTION/MULTIPLIER Z
Exogenious variable
(Z - symbol of a variable)
– DELAY
C Constant
– SMOOTH (C - symbol of a constant)
Dn Exponential delay of n-order
– … P
SWY (PO - symbol of a delay stock,
CT SWY - symbol of an input rate,
CT - symbol of a delay time,
Dn - symbol of n-order delay)
Source
Mouth

FEEDBACK LOOPS
Positive loop
– Positive feedback loop in relation to an element of a system means that change
of this element's characteristics imply, after some delay, a new change of this
characteristic in the same direction change. Typical examples of positive
feedback loops are models: of inflation (as a result of positive cause-effect
relations between manufacturing cost, price of good, "pressure" to increase
salaries and salaries), Maltus population (as result of positive cause - effect
relations between population and its rate of increase - births minus deaths).
Negative loop
– Negative feedback loop means that changes in characteristics of system's
element are balanced by actions against such changes, implying "negative effect"
to changes. Examples of such feedbacks are models of temperature regulation
(central heating control system).

FEEDBACK LOOPS
a) b)
Local
+
Manufacturing
Population
temperature Desired
cost of a good Change in
+ + temperature
+
temperature -
Salaries Price of + + - +
+ Difference
+ a good
+
Births of temperature
+
+ Heat +
Pression Device Temperature-
delivered
to increase efficiency + heat
salaries by device
constant constant
• STOCKS (LEVELS) AND RATES

EQUATIONS AND CALCULATIONS IN SD SIMULATION
There are 3 types of equations in SD models:

• stock (level) equations,
• rate (flow) equations,
• auxiliary equations.
LEVEL.K = LEVEL.J + DT (INPUTS.JK - OUTPUTS.JK),

RATE.KL = f (Levels.K, Auxiliaries.K, Rates.JK, Rates.KL,Constants),
AUXILIARY.K = h (Levels.K, Auxiliaries.K, Rates.JK, Constants),
Calculus in SD models
1 2'
4
3' 5''
2''
3'' 6''
5' 6'
J K L Time
DT DT
Legend:
Stock Auxiliary Rate
• Characteristic patterns of system behaviour in SD

models
Performance Performance
Goal
Exponential growth Time Goal-seeking Time

Performance
Performance
S - shaped Time Fluctuation (oscillation) Time

• Basic dynamic patterns - examples

Temperature
+ Setting
Bank Balance
Gap
- +
+ Actual
Temperature
Interest Earned
Desired
Temperature
Size of Market Delay

Motivation/ Niche - Reputation
Service
+ Productivity
+ -
Morale Sales - Saturation of - Gap +
+ Customer Demand
+ +Market Niche -
Income +
Opportunities Service Standard -
Delay
Service Quality
Continuous Simulation – Structure vs. Behaviour
• Feedback loop polarity dominance analysis

(LPDA).
• Behavioral analysis of feedback loop dominance
(BAFLD).
• Feedback loop pathway participation metrics
analysis (PPMA).
• Feedback loop graph theory analysis (GTA).
• Algorithmic detection of archetypal feedback
loop structures (ADAS).
• Feedback loop polarity dominance analysis

– The concept of dominance is a temporal one, depending on the operating conditions of the
system - different feedback loops can be activated and deactivated, causing a change in the
feedback loop dominance. The concept of feedback loop polarity, particularly important in
the LPDA mathematical method (analysis of feedback loop polarity dominance), is a concept
that allows to read loop dominance in a certain way. The feedback in the system contains
(should contain) at least one state variable as an integration variable (SD method stock x(t)
at time t).
– Let us consider feedback loop with a stock (resource) x and the flow variable described by
the differential equation: x = dx / dt . The polarity of the feedback loop containing the
resource variable x and it’s derivate (dx/dt) representing an inflow to resource, is calculated
as: sign(dx / dx) = sign((dx / dt) / dx) .
– For example, in a dynamic system structure with two feedback loops of the 1st order and dynamic
equation given as: x  ax  bx  a  b  x , where a and b are constant parameters. According to this
definition, polarity of the system with the two feedback loops is equal to sign(a-b). It means, that
when a>0 and b>0, the polarity as sign(a-b)>0 if a>b, and polarity as sign(a-b)<0 if a<b.
x
zx1 zx2
a b
4
60 0
4
40 0
x
4
4 3
20 0 3
4 3
3 3
1 2 3 4 1 2 2 2 2
1 1 1 1
0
0 20 40 60 80 10 0
Time
• Behavioural analysis of feedback loop dominance

– The BAFLD method (see [Ford 1999]) for the identification and
behavioural analysis of feedback loop dominance consists of an
iterative 8-step heuristic procedure:
• Identification and selection of a model variable of interest to the analyst from the point of
view of feedback loop dominance, for which a preliminary simulation is performed and a
trajectory of time behaviour is determined.
• Identification of time periods in which the selected model variable behaves in an elementary
way. Reference patterns of behaviour are linear, exponential and logarithmic. The conditions
for obtaining elementary standards are determined by the structure and model parameters.
• Identification of the model feedback loops affecting the tested model variable and selection
of one feedback loop as the dominant loop to be found, starting from the feedback loop
containing the tested variable inside.
• Identification or creation of a control variable in the tested feedback loop, which is not a
variable belonging to other model feedback loops at the same time. This variable should
influence the polarity of the test feedback loop and is used to activate or deactivate the test
feedback loop.
• Simulation of behaviour of the tested variable in time intervals with the tested feedback
loop in the deactivation state and identification of an elementary pattern(s) of behaviour of
the tested variable in time intervals.
• Behavioural analysis of feedback loop dominance

– BAFLD method (see [Ford 1999]) 8-step heuristic procedure – cont.:
• Identification of time periods in which the observed variable behaves in an
elementary pattern. If the elementary behaviour in the time interval determined in the
previous step is different from the behaviour initially determined (in step 2), the
feedback loop under test is dominant for the behaviour of the model variable under test
under system conditions. If the behaviour is the same, two situations are possible: a)
the tested feedback loop is not a dominant loop, b) the tested feedback loop is a
dominant loop, but it also has a “parallel" feedback loop, a “shadow" type loop. In order
to identify the shadow loop, repeat steps 4-6 with the tested feedback loop
deactivated, which will allow to unambiguously identify the parallel loops. After the
identification of a shadow loop, it should be deactivated and then the dominance tests
for the tested loop should be repeated. If there is no change in the behaviour of the
model variable being tested, it is possible to conclude that there is no dominance of the
feedback loop for the model variable being tested.
• Repeat steps 3-6 with the active test feedback loop to identify possible multiple
dominant feedback loops in the test intervals.
• Repeat steps 1-7 for different time periods to identify changes in feedback loop
dominance and loop dominance for other model variables.
• Feedback loop pathway participation metrics analysis

– The PPMA feedback loop pathway participation metrics analysis
algorithm (see [Mojtahedzadeh et al. 2004]) is based on the use of feedback
loop participation metrics in the overall behaviour of the dynamic
system. Therefore, it is a formal algorithm supporting intuitive research
of the system by an analyst. The concept of pathway is not interpreted
as a self-contained whole feedback loop. It is rather a kind of “tree
branch” belonging to one of the feedback loops and leading to a specific
model variable. Since the influences of different feedback loops may be
crossing in the model variable under test, the analysis of the model is
based on the identification of the most significant feedback loops by
evaluating the effects of single paths. The basic intuitive assumption of
the PPMA method is also based (similarly to the BAFLD method) on the
identification of elementary patterns of behaviour. The analysis is based
on the following 7 elementary patterns of behaviour: linear growth,
linear decline, reinforcing growth, reinforcing decline, balancing
growth, balancing decline, equilibrium.
• Feedback loop pathway participation metrics analysis

– The PPMA procedure consists of the following stages:
• Identification and selection of a model variable of interest to the analyst from the point
of view of feedback loop dominance, for which a preliminary simulation is performed
and a trajectory of time behavior is determined.
• Division (decomposition) of the trajectory of the tested model variable into phases
corresponding to one of the 7 elementary patterns of system behavior (identification of
elementary phases).
• Looking for fragments of structures responsible for elementary patterns of system
behavior identified at the step of decomposition in appropriate feedback loops, i.e.
being a significant reason for the observed behavior of a variable. In the appropriate
mathematical procedure for a given model variable (x) the influence of the change of
this variable (dx/dt) on the calculated variable ((dx/dt)/dx), which is a measure of a
given path participation in the Total Pathway Participation Metrics, is determined. This
metrics shall contain information about the derivatives (1st and 2nd) for the model
variable being tested.
• Identification of the feedback loop path that has a significant influence on the system
behavior using the calculated participation metrics. The dominant feedback loop path is
identified as the one for which the calculated metrics is the largest and has the same
polarity (character) as the total changes.
• Feedback loop graph theory analysis

– As a result of automated calibration (AC) approach to systems dynamics
modelling, a new interesting concept for classical structure – behaviour problem
solving with an application of some elements of graph theory and tools was also
created (see [Oliva 2004]). This approach aims at formalizing the heuristics for
model partitions and a sequencing strategy for the calibration/testing process
in modelling. Even it tends only towards incremental improvements in SD model
confidence in the model design process, it can be helpful to identify and assess
particular system structure elements in the context of their influence to overall
system behaviour.
– The argument is that it is possible to focus on the structural complexity of
system dynamics (SD) models to design a part-by-part modelling policy that
maximizes the test points between the model and the real world, and a
calibration sequence that permits an incremental development of model
confidence. And some insights and tools from graph theory could be applied as a
basis for making sense of the structural complexity of SD models, and that this
structure could be used as a basis for more formal analysis.
• Feedback loop graph theory analysis – cont.

– Given an available set of data series (model variables and input parameters for
which historical data are available), it is possible to iteratively identify the set
of equations (for variables and parameters) that are directly involved in the
outcome variable calculations. Therefore, it is possible to identify the minimum
equation set that can be used for estimation purposes. The minimum equation
set will guarantee that all parameters used in the estimation are involved in the
generation of the selected model outcomes and, hence, that the best use of the
input data is made. However, in most practical modelling situations, it will be
necessary to develop a sequence of partial model calibrations, and results from
early calibrations may be used to tune further calibrations. Confidence in a
dynamic system hypothesis is usually built by step-by-step procedure to integrate
more complex and strongly connected components of the system into simple and
observable parts of structure. Therefore, the same approach should be used to
develop a sequence of calibration problems that yields increasing confidence in
the model structure and enables the use of insights and findings from simple
structures in testing structure components.
• Feedback loop graph theory analysis – cont.

– The GTA method for the identification and behavioural analysis of feedback loop
dominance, and model parameters calibration consists of an iterative 5 step
heuristic procedure with graph theory optimizations:
• Identification of dynamic system model relations between quantities (variables and
parameters) and setting relational matrixes – adjacency matrix (AM) and reachability
matrix (RM) in graph theory formalisms to visualize and analyse model structure.
• Identification of data-availability partitions according to empirical set of data.
• Structural partitions for SD model levels. Identification of level partitions in AM by
blocking (i.e. block consists of only one model level) – the algorithm generates an array
with the list of vertices that correspond to each level in each cell. If the adjacency
matrix (AM) is reordered according to level structure, the resulting matrix is a lower
block triangular with each block representing a level.
• Structural partitions for SD model feedback loop cycles. Identification of cycle partition
as a set of strongly connected elements that contain all the feedback complexity of a
dynamic system model structure. By an application of RM it is possible then to calculate
the distance matrix (DM) that shows in each cell the length of the shortest path (a
sequence of non-repeating connected vertices and edges) between two vertices.
• Identification of minimal structures by calculation of geodetic cycle lists and model
graph parameters.
• Algorithmic detection of archetypal feedback loop

structures
– The algorithmic detection of archetypal structures (ADAS) method (see
[Schoenenberger et al 2015]) is an approach to test dynamic
hypotheses about archetypal structures belonging to the four generic
system’s archetypes (i.e.: the underachievement, relative
achievement, relative control, and out-of-control) as a result of
intended and unintended consequences of system’s feedback loops. This
approach is based on classical (analytical) feedback loops and cycles’
partitions, and it takes also graph theory analysis (GTA) method as an
assumption. However, for the detection of generic structure archetypes,
it requires not only vertices and edges but also other dynamic
parameters as input data – polarities, magnitudes and delays.
• Algorithmic detection of archetypal feedback loop

structures – cont.
– A qualitative, algorithmic procedure of ADAS method consists of
the following 8 stages:
• Identification of archetype reference behaviour of a variable of interest.
• Formulation of a dynamic hypothesis (SFD model) to explain particular system’s
behaviour.
• Conversion of SFD model into directed graph in adjacency matrices (AM) for polarities
and delays.
• Setting the variable of interest (from stage 1) as the outcome (observable) variable in
the algorithm.
• Algorithmic checking for the variable of interest the other archetype structures with a
presence of this variable.
• Identification of plausible archetypal structures that cause the problematic behaviour of
the variable of interest, and then reinterpreting the archetypes in stage 5 in the context
of SFD model in stage 2.
• Introducing policies as classical SD solutions.
• Simulation of the model and reviewing the behaviours for the variable of interest.
• Age Chain Model

• aging middle = Population Middle / average time in middle
Units: person/Year
• aging old = Population Old / average time in old
Units: person/Year
• aging young= Population Young / average time in young
Units: person/Year
• average time in middle= 47
Units: Year
• average time in old= 10
Units: Year
• average time in young= 18
initial pop
Units: Year infant average time in young average time in middle average time in old
• birth rate= 0.08
Units: fraction/Year
• births= Population Middle * birth rate
Units: person/Year Population Population Population
• FINAL TIME = 100 Young Middle Old
Units: Year births aging young aging middle aging old
initial pop infant=100000
Units: person
• initial pop middle=2e+007 birth rate initial pop
Units: person initial pop
• initial pop old=1e+006 middle old
Units: person
• INITIAL TIME = 0
Units: Year
Population Middle= INTEG (+aging young - aging middle,initial pop middle)
Units: person
• Population Old= INTEG (aging middle - aging old,initial pop old)
Units: person
• Population Young= INTEG (births - aging young,initial pop infant)
Units: person
• SAVEPER = TIME STEP
Units: Year
TIME STEP = 0.25
Units: Year
• Epidemic Model
Contacts
between infected
and unaffected
rate of potential
infectious contacts
Fraction of
population infected
rate that people fraction infected
contact other people from contact
Susceptible Infected
Population Population
infections
initial susceptible initial infected
total population
• Production Model
a)
WS  PP  PG
ZSP ZST
Preparations Work in
WS PP progress WIP PG
Input Input
OD ZSP ZST
Final
to preparations to production
 PG  
production
Input
T1 _
T2 T1 T2 T3
Preparation time T3
Purchasing time
Production time
OD OD  NPT  ZST  0
Difference NPT
b) WIP norm
ZST  NPT
OD.K = max (NPT - ZST.K, 0) [w] T
PG.KL = ZST.K/T3 [w/day] ZSP  NPT  2
WS.KL = OD.K/T1 + PG.KL [w/day] T3
PP.KL = ZSP.K/T2 [w/day]
ZSP.K = ZSP.J + DT * (WS.JK - PP.JK) [w]
ZSTK = ZST.J + DT * (PP.JK - PG.JK) [w]
A = const [day]
B = const [day]
G = const [day]
NPT = const [w]
ZST: 1 - 2 - 3 - 4 - 5 -
ZSP ZST 1: 200
WS PP PG
T2
T3
T1
OD NPT
1
1: 100 1 1 2 1 2 3
2 3 4
4 5
3 5
4
5
2 3 4 5
1: 0
1.00 50.75 100.50 150.25 200.00
Page 3 Months 12:36 16 mar 2004
Untitled
ZST: 1 - 2 - 3 - 4 - 5 -
ZSP ZST
1: 200
WS PP PG
T2
T3
T1
OD NPT
1: 100 1
1 1 1
2 2 2 2
3 4 3 4 3 4 3 4
5 5 5 5
1: 0
1.00 50.75 100.50 150.25 200.00
Page 4 Months 12:41 16 mar 2004
Untitled
• Corporate Growth Model

effect of delivery
normal delivery delay recognized
delay recognized lookup
effect of delivery
delay recognized Delivery Delay
Recognized
time for delivery
sales effectiveness delay recognition
normal sales
effectivness
(-) delivery delay
impending
Sales Force orders booked
net hires normal backlog
delivery rate
effect of backlog
sales force on delivery rate
adjustment time budget
indicated sales force
effect of backlog on
delivery rate lookup normal
(-) delivery rate
sales person salary revenue to sales
Backlog
orders entered orders completed
• Prey- Predator Model

Prey(t) = Prey(t - dt) + (BrthPrey - DeathPrey) * dt
XPrey YPray INIT Pray = 50
Pray
INFLOWS:
BrthPray = Pray*XPrey
BrthPray DeathPrey OUTFLOWS:
DeathPrey = Pray*Predator*YPrey
Predator(t) = Predator(t - dt) + (BirthPred - DeathPred) * dt
INIT Predator = 10
Predator
INFLOWS:
BirthPred = Prey*Predator*XPred
OUTFLOWS:
BirthPred DeathPred
DeathPred = Predator*YPred
XPred = 0.0001
XPrey = 0.01
YPray = 0.0001
YPred
YPred = 0.001
XPred

1: Drapieznik 2: Of iara Drapieznik v . Of iara: 1 -
1: 400 400
2: 750
1 1
1: 200 2 200
2: 400
1
1 2
2
2
1: 0 0
2: 50
50 400 750
1.00 25.75 50.50 75.25 100.00
Page 1 Of iara 21:52 13 gru 2004
Page 1 Months 21:52 13 gru 2004
Untitled
Untitled

1: Drapieznik 2: Of iara
1: 500
2:
2 2 2 2 Drapieznik v . Of iara: 1 -
1: 250 151
2:
1 1 1 1
1: 150
2: 0
1.00 25.75 50.50 75.25 100.00
Page 1 Months 21:56 13 gru 2004
Untitled
149
299 300 301
Page 1 Of iara 21:56 13 gru 2004
Untitled
• World 2 model
births material
Population & Food deaths pollution
mult tab birth rate normal death rate normal mult tab
birth rate normal 1 death rate normal 1 <pollution ratio>
<material
standard of switch time 1 switch time 3
living> <Time> <Time>
Population
births material multiplier births deaths
deaths pollution multiplier
births pollution multiplier
deaths material multiplier
population initial
births births food multiplier
pollution deaths deaths food multiplier
mult tab crowding crowding
births crowding
multiplier
multiplier
deaths
births food land area material
mult tab births <food deaths mult tab
crowding population crowding crowding
mult tab density normal mult tab> deaths food <material standard of
<pollution ratio> mult tab
mult tab living>
food crowding multiplier capital agriculture

food ratio fraction indicated tab
food pollution
multiplier
food capital agriculture fraction indicated
pollution <Time>
mult tab food per capita potential
switch time 7 <capital ratio agriculture>
food coefficient food per food per capita
food coefficient 1 capita normal potential tab
• World 2 model
capital Capital & Quality of Life
investment
rate normal switch time 5 capital depreciation
switch time 4 <Time> normal
capital <Time>
investment capital depreciation
rate normal 1 normal 1
Capital
capital investment capital depreciation <crowding>
quality
crowding <food ratio>
capital capital initial mult tab quality
investment food
capital ratio mult tab
multiplier
<Population> quality
capital capital crowding
investment material standard of living agriculture capital ratio multiplier quality food
mult tab fraction normal agriculture multiplier
effective
capital ratio effective capital ratio
normal quality pollution
<naturalquality
resource extraction multiplier>
<natural resource multiplier
material extraction
mult tab multiplier> quality of life
quality material multiplier
Capital <pollution ratio>

capital investment Agriculture quality
from quality ratio pollution
Fraction mult tab
quality of life
normal
capital <quality food <capital capital agriculture capital
investment multiplier> agriculture fraction fraction adjustment agriculture
quality ratio tab indicated> time fraction initial
• World 2 model
Pollution & Natural Resources
switch time 6
<Time>
pollution per
capita normal 1 Pollution
pollution pollution
generation absorption
pollution per
capita normal pollution
initial pollution
pollution capital absorption time
multiplier
pollution pollution ratio
capital pollution
mult tab absorption
<Population>
<capital ratio> time tab
pollution standard
natural resource switch time 2

fraction remaining <Time>
Natural
Resources natural resource natural resource
natural resource utilization utilization normal 1
extraction
multiplier
natural
resources nat res matl multiplier natural resource
initial utilization normal
natural resource
extraction mult tab <material standard of living> natural resource material mult tab
• World 2 model
Population Capital
6B 10 B
4.5 B 7.5 B
3B 5B
1.5 B 2.5 B
0 0
1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100
Time (Year) Time (Year)
Population : Current Pollution Person Capital : Current Capital units
40 B Natural Resources
1e+012
30 B
750 B
20 B
500 B
10 B
250 B
0 0
1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100
Time (Year) Time (Year)
Pollution : Current Pollution units Natural Resources : Current Resource units

• World 2 model
quality of life
2
1.6
1.2
0.8
0.4
1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100
Time (Year)
quality of life : Current Satisfaction units

• Some examples of SD in practice (System Dynamics Review)

– Instabilities in evolutionary systems.
– Regulation and safety in industrial firms.
– Bifurcations in models of economic long wave.
– Growth strategy in biotechnology firms.
– Exchange rate and inflation rate in oil-exporting economy.
– Commodity taxation, energy tax.
– National energy policy planning.
– Kuhnian science models.
– Cost effectiveness of US energy policies.
– Food self-sufficiency in Vietnam.
– Value of information in business firm.
– „88 Shanghai type A hepatitis” case.
– Business cycles models.
– Rural development in Southern Sudan.
– New York State solid waste system.
– Structure and economy of fur farming and trading.
– Sea-level rise in a coastal area.
– Urban system.
– Managing a live insurance company.
– Corporate strategy in pulp and paper industry.
– Project management.
– Innovation processes.
– World system (Limits to growth, sustainable development,...).
– Market power across gas and electricity markets.
– Flexible assembly systems, highway construction, ....
– National Health Service systems, epidemiology of HIV/AIDS,...
– Resource allocation.
– Restructuring the firms (LUL).
• Restructuring LUL (London, UK)

(Source: Donna D.Mayo, Martin J.Callaghan & William J.Dalton, Aiming for restructuring success at London
Underground, System Dynamics Review, vol.17, no.3, Fall 2001, pp.261-289)
– Project time: July 1997 – July 2000
– Project sponsor: London Underground Limited (LUL)
– Project team: PA Consulting Group (staff: 75)
– Project main goals:
• Investigation of restructuring options influence to LUL (personnel, trade unions,
customers, government, private sector)
• Investigation of change scale associated with restructuring options
– Project stages:
• Stage 1 - System, dynamic aspects, environment (chart diagrams, IDs)
• Stage 2 - Qualitative analysis and evaluation of 10 restructuring options (criteria map,
risk map, opportunities map)
• Stage 3 - Quantitative analysis and evaluation of restructuring options (simulation
modelling, LUL simulator)




• Strategic aspects of management

• SD software
Optimization methods DYNAMO
delivered from (1960)
numerical DYSMAP
mathematics (1970)
COSMIC and COSMOS STELLA

(1984) ITHINK
(1985)
VENSIM POWERSIM
(1990) (1992)
• IThink/STELLA
• Vensim
• Application of EXCEL software

ZSP ZST
WS PP PG
T2
T3
T1
OD NPT
160,00
140,00
120,00 Serie1
Serie2
100,00
Serie3
80,00 Serie4
Serie5
60,00
Serie6
40,00
Serie7
20,00
0,00
1 3 5 7 9 11 13 15 17 19 21
Discrete Simulation
• Discrete-event simulation concerns the modeling of a system as it

evolves over time by representation in which the state variables
change only in discrete way (discrete function) at a countable
number of points in time.
• These points in time are the ones at which an event occurs, where
an event is defined to be an instantaneous occurrence which may
change the state of a system.
Discrete Simulation
TIME ADVANCE MECHANISMS IN DISCRETE SIMULATION

• Continuous time-advance approach
• Next event time-advance approach (event scheduling)
When an event occurs, some activities must be done to procedure
this event and register the change of system’s states, and then
simulated time is moved to the time of the next event.
NETWORK MODELLING IN DISCRETE SIMULATION

• Queueing networks
• Petri Nets
• Evaluation Nets
Discrete Simulation
• Queuing network is a graph, with nodes representing

(mapping) sources of transactions, queues of tasks,
service points and other system’s resources connected by
edges, describing task flow between network nodes.
• Service points are one-channel (facility) or multi-channel
(storage) service points. Queues and service points
create service centers.
1
… End
Begin Queue
n
Discrete Simulation
• Petri net is a set (M, P, K), where K M x P

P x M, is a set of net edges and M is a set of nodes
called places (graphical representation: circles), P is a
set of nodes called transitions (graphical representation:
lines). Places in nets are marked.
KW3
Stanowiska obsługi
KW1
S1
P1 P2 R1 T1 Wyjście
K1 K2 K3 SW1 Z
P1
Zgłoszenie Kolejka S2
R2 T2
ZW
KW2
SW2
...
Sn
Rn Tn
SWn
Discrete Simulation
• Evaluation net is a set E = (M, W, D, P), where M is non-

empty set of places, W is a set of input and output
places, D is a set of decision making places, P is a set of
transitions with times and procedures.
S1
Kolejka
WE K1 K2 K3 S2 WY
P1 P2 P3
...
Sn
P4 P5
Stanowiska
obsługi
Discrete Simulation
• The tasks are selected for processing by applying some

algorithms as queuing rules. The most applied
algorithms are:
– FIFO/FCFS rule (first in first out, first come first served), which
is based on a chronological order of incoming tasks,
– LIFO rule (last in first out), which is based on reverse
chronological order of incoming tasks,
– SPT rule (shortest processing time), which is based on the
processing time – selection by processing time (shortest time first
to be served),
– priority rule, which is based on selection of tasks by increasing
priorities (higher priority first to be served),
– random rule, which is based on random selection of tasks to be
served.
Discrete Simulation
• The are 3 methods of discrete simulation - event

oriented, activity oriented and process oriented.
• Differences between methods of discrete simulation are
based on the processing and mapping of the basic three
elements: event, activity and process.
– Event is a change of system’s state. It could be a change of some
attributes of system’s objects or introducing/cancelling new
objects (transactions or tasks).
– Activity is a set of elementary (not dividable) operations leading
to change of system’s states.
– Process is a chronological set of events related to only one
transaction flowing through the system. Process consists of
activities, and activity is defined by two events (start, end).
Discrete Simulation
• Event Oriented Method (Event Scheduling)

The EO method is based on a proceeding of event calendar, which
defines the sequence of events with details of particular activities to
be performed when events occur.
• Activity Oriented Method (Activity Selection)
The AO method is based on a proceeding of all activities in order to
determine which one has to be started and/or finished when a
particular event occurs.
• Process Oriented Method (Process Interaction)
The PO method is based on grouping of all activities in processes,
which are performed on dynamic system’s objects (transactions)
from the beginning to the end of their presence in the system.
Discrete Simulation
• There are 2 types of events:

– unconditional events, as events directly dependent
on time (e.g. customer arrival),
– conditional events, as events not-directly dependent
on time and directly dependent on system’s states
(e.g. start to customer service).
Event 1 Event 2 Event 3 Event 4 Event 5 Event 6
Transaction 1 Start to service Transaction 2 Start to service End of service End of service
enters of transaction 1 enters of transaction 2 for transaction 1 for transaction 2
Tim
Activity - Waiting Activity - Waiting e
Activity - Service
Activity - Service
Process no 1
Process no 2
Discrete Simulation
• Basic elements of models:

– Clock (Simulation Clock), which is a dynamic object to register real time of a system – it is a
variable giving the current value of simulated time;
– Calendar, which is a dynamic object with system’s clock, and a set of information about
events (types, parameters) as Event List;
– Transactions, which are dynamic objects (tasks) entering the system with attributes;
– Resources, which are static objects of a system as service points (one-channel facility,
multi-channel storage).
– Queuing and Service Rules, which describe the way (order) to process incoming tasks to
resources and queues.
• Other components:
– Statistical counters - variables used to store statistical information about system;
– Initialization routine - a module used to initialize the simulation model at time zero;
– Timing routine - a module which determines the next event from the event list and then
advances the simulation clock to the time when that event is to occur;
– Event routine - a module which updates the system state when a particular type of event
occurs (there is one event routine for each event type);
– Report generator - A module which computes estimates (from the statistical counters) of
the measures of performance and prints a report when the simulation ends;
– Main program - a subprogram which calls the timing routine to determine the next event
and then transfers control to the corresponding event routine to update the system state.
Discrete Simulation
EVENT ORIENTED
• A list of planned non-conditional events is in calendar
• Description of the system by events and service actions
• Selection of events made by simulation control program
• Application: many transactions (processes) and less actions
• Within service actions are next event planning actions
ACTIVITY ORIENTED
• In calendar are conditional and non-conditional events
• Description of the system by activities
• No event planning, but a list of logical conditions for events
• Each entity has its own clock
• Application: many activities
PROCESS ORIENTED
• Combination of event and activity oriented methods
• Description of the system by process flow
Discrete Simulation
The System and simulation example

Since a lot of simulation models involve waiting lines or queues as building
blocks, let’s consider a very simple case of such a model representing a
portion of a manufacturing facility. "Blank" parts arrive, are processed by a
single machine, and then leave. If a part arrives and finds the machine idle,
it’s processing by the machine starts right away; otherwise, it waits in a
first-in, first-out (FIFO) queue. This is the logical structure of the model.
Machine
Arriving (Server)
Blank Departing Finished Parts
Parts
Queue
Part in Service
Discrete Simulation
• Specification of the numerical

aspects: start of the simulation,
Part Arrival Inter- Service
stop of simulation, time units
No. Time arrival Time
(minutes). Remember: be consistent Time
about time units everywhere.
• The system starts at time 0 minutes 1 0.00 6.84 4.58
with no parts present and the
machine idle. This empty-and-idle 2 6.84 2.40 2.96
assumption would be realistic if the
system starts afresh each morning, 3 9.24 2.70 5.86
but might not be so great as a 4 11.94 2.59 3.21
model of the initial situation to
simulate an ongoing operation. 5 14.53 0.73 3.11
• The time durations are in table.
• The simulation will stop at exactly
time 15 minutes. If there are parts
present at that time (in service at
the machine or waiting in the
queue), they never are finished.
Discrete Simulation
Goals of the Study

Given a logical/numerical model, next it is to decide what output
performance measures are to be collected.
• The total production (number of parts that complete their service
at the machine and leave) during the 15 minutes of operation.
Presumably, more is better.
• The average waiting time in queue of parts that enter service at
the machine during the simulation. This time in queue records only
the time a part is waiting and the queue and not the time it spends
being served at the machine. If Di is the delay in queue of the ith
part and it turns out that N parts complete their delays in queue
during the 15-minute run, this average is
N
D
i 1
i
N
Discrete Simulation
• The maximum time waiting in queue of parts that enter service at

the machine during the simulation. This is a worst-case measure,
which might be of interest in giving service-level guarantees to
customers. Small is good.
• The time-average number of parts waiting in the queue (again,
not counting any part in service at the machine). By "time average"
we mean a weighted average of the possible queue lengths (0, 1, 2,
...) weighted by the proportion of time during the run that the
queue was at that length. Such time-persistent statistics are
common in simulation. This one indicates how long the queue is (on
average), which might be of interest for allocating floor space.
Letting Q(t) be the number of parts in the queue at any time instant
t, this time-average queue length is the total area under the Q(t)
curve, divided by the length of the run, 15. In integral-calculus
terms, this is 15
 Qt dt
0
15
Discrete Simulation
• The maximum number of parts that were ever waiting in the

queue. Actually, this might be a better indication of how much floor
space is needed than is the time average if you want to be
reasonably sure to have room at all times. This is another worst-case
measure, and smaller is presumably better.
• The average and maximum flowtime of parts that finish being
processed on the machine and leave; flowtime (cycle time), for a
part is the time that elapses between its arrival and its departure,
so it's the sum of the part's delay in queue and its service time at the
machine. This is a kind of turnaround time, so smaller is better.
• The utilization of the machine, defined, as the proportion of time
the machine is busy during the simulation. This is another time-
persistent statistic, but of the "busy" function
1 if the machine is busy at time t
Bt   
0 if the machine is idle at time t
The utilization is the area under B(t), divided by the length of the run. Resource utilizations are
of obvious interest in many simulations, but it's hard to say whether you "want" them to be high
(close to 1) or low (close to 0). High is good since it indicates little excess capacity, but can also
be bad since it might mean a lot of congestion in the form of long queues and slow throughput.
Discrete Simulation
Analysis Options
With the model, its inputs, and its outputs defined, next it is to
figure out how to get the outputs by transforming the inputs
according to the model's logic.
• Educated Guessing
While we 're not big fans of guessing, a crude "back-of-the-envelope" calculation can
sometimes lend at least qualitative insight (and sometimes not). How this goes, of
course, completely depends on the situation.
A possible first cut in our example is to look at the average inflow and processing
rates. From time table, it turns out that the average of the five inter-arrival times
is 3.05 minutes, and the average of the five service requirements is 3.94 minutes.
This looks pretty bad, since parts are arriving faster than they're being served,
implying heavy congestion (at least after a while, probably longer than the 15-minute
run we have planned). Indeed, if this situation persists, the queue will "explode„.
Suppose, on the other hand, that the numbers had come out so that the average
inter-arrival time was more than the average service time. As long as you're
supposing, suppose further that these averages were exactly what happened for each
part-no variation either way. Then there would never be a queue, and all delays in
queue would be zero, which is a happy thought. The truth, as usual, will probably be
between the extremes. Clearly, guessing has its limits.
Discrete Simulation
• Queuing Theory
Since this is a queue, why not use queuing theory? It's been around for almost a
century, and a lot of very bright people have worked very hard to develop it. In some
situations, it can result in simple formulas from which you can get a lot of insight.
Probably the simplest and most popular object of queuing theory is the M/M/1
queue. The first "M" states that the arrival process is Markovian; i.e., the inter-arrival
times are independent and identically distributed "draws" from an exponential
probability distribution. The second "M" stands for the service-time distribution, and
here it's also exponential. The "1" indicates that there's just a single server. So at
least on the surface this looks pretty good for our model. Better yet, most of our
output performance measures can be expressed as simple formulas. For instance, the
average delay in queue (expected from a long run) is just
 s
A  s
where  A is the expected value of the inter-arrival time distribution and  S is the
expected value of the service-time distribution (assuming that  A   S so the queue
doesn't explode). So one immediate idea is to use the data to estimate  A and  S ,
then plug these estimates into the formula (although this won't work in our case since
the average inter-arrival time is less than the average service time).
Discrete Simulation
• Such an approach can sometimes give a reasonable order-of-magnitude

approximation that might facilitate crude comparisons. But there are
problems too:
– The estimates of  A and  S aren't exact, as there will be error in the result
as well.
– The assumptions of exponential inter-arrival-time and service-time
distributions are essential to deriving the formula above, and we probably
don't satisfy these assumptions. This calls into question the validity of the
formula. While there are more sophisticated versions for more general
queuing models, there will always be assumptions to worry about.
– The formula is for long-run performance, not the 15-minute period we want.
This is typical of most (but not all) queuing theory.
– The formula doesn't capture the natural variability in the system. This is not
only a difficulty in analysis but might also be of inherent interest itself, as in
the variability of production. (It's sometimes possible, though, to find other
formulas that measure variability)
– Many people feel that queuing theory can prove valuable as a first-cut
approximation to get an idea of where things stand and to provide guidance
about what kinds of simulations might be appropriate at the next step in the
project.
Discrete Simulation
• Mechanistic Simulation
By "mechanistic" we mean that the individual operations (arrivals,
service by the machine, etc.) will occur as they would in reality. The
movements and changes of things in the simulation model occur at
the right "time," in the right order, and have the right effects on
each other and the statistical-accumulator variables.
Discrete Simulation
Discrete Simulation
Discrete Simulation
• Sampling methods in DS
– It is clear that many discrete event simulations include elements
that are random or stochastic. Very often in simulation, the
modeller must decide whether to model something within a
system by a sampling procedure.
– All models are approximations and the aim is to develop a model
that is appropriate for its intended purpose.
– Random sampling is used within a discrete simulation so as to
produce from a probability distribution a set of samples that
have two important properties:
• Firstly, the samples that are produced should have the same distribution as
the probability distribution from which they are taken (the distribution of
the samples should be in the same proportions as the distributions from
which they come)  in statistical terms, the sample mean and variance
should be the same as the population mean and variance.
• Secondly, when a set of samples is placed in the sequence in which it is
produced, there is no unintended pattern in that sequence. So any sequence
of random numbers, R1, R2, …, must have two important statistical
properties: uniformity and independence.
Discrete Simulation
• Random number generator in DS

– What is meant by random? There is no
such thing as a single random number.
– Generally, what is meant by randomness is
that the process which produces the
number is not deterministic (we cannot be
sure what number will be produced next).
– Streams of numbers that have been
produced by a process that is believed to be
random are usually described as truly
random numbers.
– One example might be the spinning of a
roulette wheel. Other physical devices that
operate by electronic and radio-active
means are much faster in their generation
of truly random numbers but are not used
in discrete event simulation for obvious
reasons.
Discrete Simulation
• Pseudo-random number generator in DS

– If a simulation is being used to compare various ways of
operating a system, it is clearly vital that each policy is
examined under the same conditions. Hence to control a
simulation and to ensure fair comparisons, it may be important
to ensure that the same random numbers are used for each
policy alternative.
– So it is vital that the stream of random numbers be reproducible.
To overcome such, employ a truly random device to generate a
stream of random numbers and then store them in some way or
other.
• Random number tables (could be found in statistical tables) are examples of
numbers treated in this way. Could be stored on disk and then read into a
computer simulation as the numbers are needed.
• Not truly random since we know what comes next. This suggests another
approach: the use of methods that are deterministic, but which produce
streams of numbers that look as if they are random. These pseudo-random
numbers are produced by generators that are based on well-understood
mathematics.
Discrete Simulation
• Good random number generator properties in DS

– It should produce numbers that are random (statistically
independent from one another).
– It should be fast and not require much computer storage.
– It should have a long period before cycling.
– It should not degenerate.
– It should generate random numbers that can be reproduced.
• The role of uniform distribution in random number
generator
– If random variable X has value [a, b] with the same probability,
its density function is constant and equal (a-b)-1 for a≤x≤b and 0
for x being out of the [a,b]. The variable X has uniform
distribution in [a,b] with average (a+b)/2.
– Application
• Description of random choice: one from many,
• Construction of a random generator of any probability distribution.
Discrete Simulation
• Construction of random generators with uniform

distribution
– Basic principle: recurrent (mixed generator)
xi = bxi-1 + c (mod m),
where xi, xi-1, b, c are integer numbers from [0,m]. To get random
numbers uniformly distributed on (0,1), one has to take ri = xi/m).
– If c=0, we get multiplicative generator
xi = bxi-1 (mod m)
– Example (Linear congruential generator)
• Use the linear congruential method to generate a sequence of random
numbers with x0 = 27, a = 17, c = 43, and m = 100.
• The sequence of xi and subsequent Ri values are computed as follows: X0 =
27, X1 = (17 x 27 + 43) mod 100 = 502 mod 100 = 2, R1 = 2/100 = 0.02, X2 =
(17 x 2 + 43) mod 100 = 77 mod 100 = 77, R2 = 77/100 = 0.77, X3 = (17 x 77 +
43) mod 100 = 1352 mod 100 = 52, R3 = 52/100 = 0.52
Discrete Simulation
• Random DSM output data

Since most DSM use random variables as input, the simulation output data
are themselves random and care must be taken in drawing conclusions
about model’s true characteristics. The behaviour of discrete systems with
DSM is evaluated by macro- and statistics categories with synthetic
characteristics (e.g., means, variances).
• Stochastic processes in DSM
A stochastic process is a collection of random variables {Xt} all defined on a
common sample (probability) space. The set of all possible values that Xt
can take on for any value of t is called the state space of the stochastic
process. If T is a countable set (usually the positive integers), {Xt} is called a
discrete-time stochastic process. If T is an uncountable subset of the set of
real numbers (usually the nonnegative real numbers), {Xt} is called a
continuous-time stochastic process. Stochastic processes are: stationary
(statistical characteristics are constant) and non-stationary (statistical
characteristics are functions of time). Non-stationary process is a basic
problem of DSM output data analysis – it has to be reduced.
Discrete Simulation
• Parts of stochastic process in DS:

– non-steady part (non-stationary),
– steady-state part (stationary)
• Methods of elimination of non-
steady-state simulation part
influence on output data:
– Extending the observation time,
– Making experiments with 2 stages:
• „warm-up” period without collection of
information,
• experimental run with collection of
information.
Discrete Simulation
The purpose of DS experiments – estimation and evaluation of

selected statistics about observed processes.
Examples of estimates of statistical characteristics for stochastic

processes:
N
• Mean (average value) X  1   X
i
N i 1
where Xi – observation value of steady-state random process X(t), N

– number of observations.
• Variance of random variable  2  1  N X  X 
x
N 1

i 1
i
where X – average value, Xi – observation value of steady-state

random process X(t), N – number of observations.
Discrete Simulation
• Determining the number of observations by confidence intervals:

Pr obX        1  
where ε – estimation error, 1-α – assumed confidence probability, X
– average value.
• For long samples and any random distribution function X, average
variable X has normal distribution.
Pr obX  c       X  c     1  
where 0 ≤ c ≤ 1 and  X2
  c  P
N
and P is a point on normal probability distribution curve, as:
1
P
 y2  
  exp
  
 dy  1 
2   2  2
• Optimal number Nopt of observations in DSM experiment is:

2
 P 
N opt   2
  
X
 c 
Discrete Simulation
• Determining the number of observations by confidence intervals –

an example:
It’s probably obvious that the way to reduce the half width of the
confidence interval is to increase the sample size n. Suppose you have an
initial set of replications from which you compute a sample average and
standard deviation, and then a confidence interval whose half width is
large. For instance, for 20 replications we got X=11.3, s=3.81, and the half
width of the 95% confidence interval turned out to be
s 3.81
t n 1,1 / 2   2.09   1.78
n 20
which represents some 16% error in the point estimate 11.3. If you want to
achieve a specific half-width h, presumably smaller than the one you got
from initial set of replications, try setting h equal to the half-width formula
above and solve for n (and replacing t-distribution with standard normal
distribution:
s s
n  t 2n 1,1 / 2   z 2
1  / 2 
h2 h2
Discrete Simulation
• Example 1
SIMULATE
*
* ONE-LINE, SINGLE-SERVER QUEUEING MODEL
*
GENERATE 18,6 ;ARRIVALS EVERY 18 +- 6 MINUTES
ADVANCE 0.5 ;HANG UP COAT
SEIZE JOE ;CAPTURE THE BARBER
ADVANCE 15,3 ;HAIRCUT TAKES 15 +- 3 MINUTES
RELEASE JOE ;FREE THE BARBER
TERMINATE 1 ;EXIT THE SHOP
*
START 100
END
Discrete Simulation
Example 2
; GPSS World Sample File - SAMPLE3.GPS

*******************************************************
* Barbershop - Some Customer Leave Without *
* Getting a Haircut *
* Time is in minutes *
*******************************************************
GENERATE 5,1.667 ;Create next customer.
QUEUE Barber ;Begin queue time.
SEIZE Barber ;Own or wait for barber.
DEPART Barber ;End queue time.
TRANSFER 200,Altdest ;20% leave without haircut.
ADVANCE 10,3.334 ;Haircut takes a few minutes.
Altdest RELEASE Barber ;Haircut done. Give up.
TERMINATE 1 ;Customer leaves.
Discrete Simulation
• Example 3
***************************************************************************
* Bank simulation (GPSS) *
* Time unit: hour *
***************************************************************************
Czas EQU 0.1112 ;Średni czas obsługi (komentarz od znaku ;)
Kod VARIABLE C1+10 ;Kod czasu dla Urzednik2.
Func1 FUNCTION RN1,D2 ;Prawdopodobieństwo wyboru urzędnika. Klienci wybierają Urzednika1 z
.7,Urzednik1/1,Urzednik2 ; prawdopodobieństwem 0.7, Urzędnika2 z prawd. 0.3.
GENERATE 0.0834,0.0278 ;Kreowanie (generowanie) kolejnego klienta w banku.
ASSIGN Urzednik_nr,FN$Func1 ;Przypisanie numeru urzędnika do parametru transakcji.
QUEUE P$Urzednik_nr; ;Początek dla statystyki kolejkowej.
SEIZE P$Urzednik_nr ;Zajęcie urzędnika.
DEPART P$Urzednik_nr ;Koniec dla statystyki kolejkowej.
ADVANCE CzasObslugi,0.0028 ;Wykonanie obsługi klienta.
RELEASE P$Urzednik_nr ;Zwolnienie urzędnika.
TERMINATE ;Klient opuszcza bank.
***************************************************************************
* Segment 2 *
* Timer and statistics collection *
***************************************************************************
GENERATE ;Pomiar statystyk co 1 godzinę pracy banku.
SAVEVALUE C1,Q$Urzednik1 ;Pomiar długości kolejki przed Urzednik1.
SAVEVALUE V$KodCzasu,Q$Urzednik2 ;Pomiar długości kolejki przed Urzednik2.
TERMINATE 1 ;Koniec kolejnej godziny pracy banku.
START 8 ;Symulacja 8 godzinnego dnia pracy banku.
Simulation games
• Simulation games are part of an interactive simulation.

A decision maker is included into the model.
– A man is an element (a part) of simulation model – in some ways is
biologically, functionally included into the model structure. Such
simulation is defined as symbiotic simulation or sometimes as a
soft/gaming simulation.
• Decision simulation game is a simulation, in which
people (players) are part of a model. People make
decisions and there are the following conditions:
– There is a game goal (purpose);
– There is a dynamic system model;
– Players are part of model;
– There is a game drama represented by game rules and scenario;
– There is a game manager (arbiter);
– Game ends up with debriefing (summary).
Simulation games
Military applications – some examples
• " WEI-HAI" (Sun-Tzu, China) - 3000 y. b.c.

Abstractive logical game.
• "CZATURANGA" - 2000 y. B.c.
Board game (8x8) with a battle of 4-element platoons. It is a chess antecedent.
• "TAROTH" - XIII w.
Tool to improve strategic and logical thinking (Templarius).
• "KOENIGSSPIEL" (Chr. Weikhman) - 1664.
Modern military chess.
• "LE JUE DE LA GUERRE" (France) - 1710.
• "CORMONTAIGNE" (Ludwik Cormontaigne) - 1741.
• "GUIBERT" (Jacques A.H. de Guibert) - 1753-1758.
Simulation games
• "OELSNITZ" (von Oelsnitz) - 1770.

• "CLERK" (John Clerk) - 1779.
First British maritime war game (applicated by admiral Nelson - St. Vincent,
Trafalgar).
• "KRIEGSSPIEL" (Helwig of Brunszwig) - 1780.
Board game with quantitative military modelling. Modification: "Neuer Kriegsspiel"
(1797 r.).
• "MONTALEMBERT" (Marek R.Montalembert) - 1793.
Effectiveness analysis for defence.
• "VON REISSWITZ" (von Reisswitz) - 1812.
First war game (kriegsschachspiel) in a form of chess, developed next by his son -
Johann, who changed board and build a mathematical model.
• "BOUSMARD" (France – Mezieres, Henri J.Bousmard) - 1814.
• "MIEROSŁAWSKI" (Ludwik Mierosławski) - 1830.
Simulation games
• "McCARTY" (William McCarty Little) - 1889.

Naval war games played in US Naval War College Newport.
• "SUKMOMLINOW" (Sukmomlinow) - 1905.
Russian war game for strategic analysis.
• "VON SCHLIEFFEN" (Alfred von Schlieffen) - 1892-1906.
German game to be applied during the I World War (attack to France).
• "VON MANSTEIN" (Erich von Manstein) - 1929.
German war game for analysis of hypothetical Polish agression to Germany – gaming
at General HeadQuater of Reichswehr.
• "ARDEN" (von Stilpnagel) - 1940.
German war game played during the II World War (OKH Wehrmacht).
• "MONOPOLOG"
American war game for airforce logistic problems (US Air Force).
Simulation games
Business and management applications – some early examples
• "MONEY GAME" (Norman Angell) – 1912 (UK)

• "PRODUCTION START MANAGEMENT GAME" - 1932.
• "FAILURE GAMES" – 1933, "RED WEAVER” – 1936 (U.S.S.R)
• "MONOPOLY" – 1930 (USA)
• "AMA" – since 1956/1957 (USA)
• "McKINSEY's GAME" (G.R. Andlinger, J.R. Greene) – 1957 (USA)
• "CARNEGIE" – since 1957/1959 (USA)
• "HBS" – since 1958 (USA)
• "UCLA" - since 1959 (USA)
• "INTOP" – since 1960 (USA)
• "NYU" – since 1958 (USA)
Simulation games
• Game procedure
Arbiter of the
simulation game
Results of
Scenario of the decisions for the time
tn+1
simulation game
Players of
the simulation Simulation
game Decisions for model
the time tn (Simulator) tn+1=tn+T
Information on results
Simulation games
If you were to demand 'Show me a management game being played' you would
probably find yourself observing small groups, but those groups might be doing
any of the following gaming activities:
• Debating and writing lists
This is a typical activity in ranking exercises. Players have to decide the relative importance of
certain items: each individual makes a list, and then the players try to reach a group solution.
• Debating and putting cards into piles
In card-sort exercises, players classify items rather than rank them, and put like with like.
• Problem-solving
This involves working as a group to complete an imposed task. The tasks vary and may have a
tangible element. It is less likely that the players will remain in constant discussion-group format.
Different parts of the group may be in different places, doing different things.
• Building something
Some exercises simulate a construction activity by using model materials. Groups can be found
building towers, bridges, etc. out of Lego bricks.
• Manufacturing (e.g. making paper aircraft)
There art exercises which require the establishment of a small production line, which is judged by
its ability to use real objects. Like building exercises, these involve movement, perhaps requiring
elements from the work area.
Simulation games
• Sitting at a board with dice and tokens

Board-based decision-making games use dice, cards, tokens and symbols.
• Sitting at a microcomputer
Computer-controlled games give details of an imaginary company and call for keyboard-entered
decisions about how it should be run.
• Debating policy and completing forms
The traditional business management exercise requires decisions about the running of an
imaginary company. These can be complicated and need careful thought. The decisions are
written on a form and passed to a controller. Players are likely to be sitting amongst a mass of
paper, over complex sets of figures.
• Acting
Same games require players to act out roles created for them such as employer/trade unionist,
salesman/customer or recruiter/applicant. It will look like a rehearsal for a play.
• Making face-to-face deals
Trading games require constant movement between customer and supplier and competitor. The
likely appearance is near-chaos, with people running from room to room making 'orders' or
carrying simulated 'deliveries'.
• Running through the woods with paint guns
Outdoor management development takes many forms. As well as the traditional rock climbing and
sailing, there are more game-like activities that offer a sanitized version of gang warfare.
Simulation games
• EDUCATION, TRAINING
Simulation game as education and training tool for
students/managers.
• EDUCATION AND ENTERTAINMENT
Simulation game as educational and entertainment tool
(edutainment).
• SCIENTIFIC RESEARCH
Describing economic systems behaviours, modelling and building
economic theories, describing systems structural changes, risk
analysis, decision-making, relations between people in economic
systems.
Simulation games
• Differentiation by tradition
– The richness of the field is partly due to the fact that it is
influenced by several different traditions.
– Management games reveal a scientific tradition and a social
science tradition, but predating them both is a pragmatic
tradition of experiment and practice. More recently, ideas have
been drawn from an entertainment tradition. A common result
is that anyone who arrives in the field of 'management games'
thinks that their route towards it was somehow the 'natural' one.
– A problem associated with this convergence is that practitioners
rooted in one tradition are not always aware of their own
attitudes and assumptions. They may view the work of other
traditions as 'wrong' and overlook cooperative opportunities from
which they might otherwise gain.
Simulation games
• The pragmatic tradition

– The construction of practice situations to fill the gap between receiving
instruction and attempting a task appears to be instinctive. It is clearly visible
in the make-believe games of children, and we claim to see it in the play of
young animals. It is not a product of modern science, and the earliest
hunter/gatherers probably had same sort of practice routine whereby they tried
to improve their chances of making a skill. We use simulation quite naturally as a
response to situations in which we will have to display skill and take risks;
– Such 'practice runs' vary as widely as the human activities they are meant to
assist, because the original objective of their design is to produce something like
each specific reality. Accordingly, there is no commonality in appearance. Nor is
there any theoretical definition or standard to which they must conform. There
are just two conditions they must meet - usefulness and an acceptable cost.
– Usefulness and cost, which are both pragmatic considerations, have a refining
effect on simulations. People ask analytical questions like 'What are the key skills
that this device is meant to foster?' Less important objectives are thus discarded,
with the features that supported them, and cost decreases. Reality is pushed a
little further into the background and the simulation becomes more like a game.
The key factors are need, purpose and cost. Thus the pragmatic approach ran
extend from quite crude scenarios to highly scientific simulations and it is not
really possible to say that any one approach is in itself 'better' than another. The
correct question is 'What are we trying to achieve?' or to put it another way,
perfect modelling is not the objective of the pragmatic tradition.
Simulation games
• The scientific tradition

– The scientific tradition is derived from scientific study and has its roots in
operations research. The desire is to find theoretically optimum solutions that
will improve on 'seat of the pants' pragmatism: a commonly cited example is the
development of the convoy system to protect ships at sea against enemy action.
Operations Research simulates reality by expressing it in terms of mathematical
relationships. It aims and sometimes succeeds (as in the convoy case) at finding a
method which is better in practice than the experience-based alternatives. The
tradition was influential in universities and business schools (aided by the
emergence of the computer) and specific type of management game emerged,
which sought to create situations in which the best-known practice (which was
carefully researched) would obtain the best results. Some of these devices were
set up to allow competition between different teams. All of their strategies were
taken into account, so that they affected each other and affected the
environment. The competitive element made it natural to speak of them as
'games'. However, there is still a valid distinction between business simulations
and business games. The former do not involve interaction between different
teams and it is 'the real environment' which determines the relative success of a
player's decisions. Using this approach it is theoretically possible to research the
market and build a set of rules which will judge in the same way. Where
interaction is allowed, opposing teams may behave in a manner that would not
happen in real life, but they still have an effect on the results of other teams.
They distort reality, and prevent those other teams from experiencing a wholly
realistic response.
Simulation games
• The social science tradition

– Games in the social science tradition reflect the development of social science in
the second part of this century, and are concerned with what happens between
people and between groups in emotional rather than intellectual terms. An
influential task was the T-group, a training method which demonstrated to those
taking part that our actions are not always governed by logic but are partly a
response to inner, psychological needs.
– We can 'see' human behaviour in a much more immediate way than we can
ever 'see' a market relationship. And perhaps because of this, we do not have
means to 'represent' human behaviour in the way that we have developed for
abstractions. In knowledge based games we use representational methods
because we do have them and because we do not have reality: in behavioural
games we do have reality to work with and we do not have adequate
representation techniques. Therefore it is not surprising that games about
behaviour have a quite different appearance. They sometimes involve data,
briefing papers and physical objects, but these items only exist to set boundaries
within which the players will act. It is the actions and attitudes of the players
that are the subject of study, not the item about which they are interacting. It is
the process of human interaction which is significant, not the content (subject
matter) about which it takes place. Games about behaviour tend to demand less
time than games about knowledge, and often have a narrower, more precise aim.
Some seek to help players discover aspects of themselves and their behaviour
that are not particularly welcome. Thus they gain from drama, and from a quick
feedback cycle.
Simulation games
• The entertainment tradition

– Games and simulations have always benefited from the fact that they are fun to
play, but in education and training this was seen as a characteristic needing
control. If students enjoyed games too much, it was felt their attention might be
distracted from the serious business of learning. Today, more credence is given
to the idea that enjoyment of an activity creates a positive attitude towards the
activity itself and the learning that accompanies it. To illustrate the idea in a
school setting, if math lessons are found to be enjoyable (for whatever reason)
then the concept of 'math' acquires a good image, more effort is put in, better
results are achieved, and more maths is learned. Practitioners who want to
create this upward spiral ask openly and aggressively 'what do people enjoy?
What gives them their kicks?' An obvious place to look for models is in
entertainment, including sport. Some management games now look remarkably
like popular television shows, and one firm marketing management games makes
an explicit claim to be employing 'the notion that people enjoy competitive
games' as a management tool.
Simulation games
• Differentiation by usage
– Most games can be used in different ways and for more than one
purpose. In fact it is fair to say that the method of use is a
greater variable than any inherent quality of the game itself.
This is because much of the learning comes from reflecting
afterwards on the experience, and the nature of that experience
is influenced by the choices made by the facilitator. Therefore
the skill of such a person is important. Facilitators can alter the
experience, and alter the value people receive from it by their
handling of post-event reviews. The following purposes are
common.
Simulation games
• Promoting knowledge and skill

– Reasons commonly given under this heading are to reinforce instruction, to integrate functional viewpoints and to improve
decision-making.
• Reinforce instruction
– Games and simulations about running an imaginary business are used to help players discover whether they have grasped, and are
able to apply, what they have learnt theoretically. With this purpose can be grouped the concept of allowing students to discover
for themselves new lessons that perhaps they have not been told in class. With it, goes the concept of practice: trying out those
skills that are hard to grasp in theory but become more obvious when applied to a specific case.
• Help players set the broad picture
– This is similar to the first objective, but it needs to be distinguished because it is the most common declared purpose for using
the 'imaginary business' type of game. Most business education is based on a functional/departmental split and many managers
rise in an organization through a single specialized channel. Development practitioners therefore find a widespread need for a
device that will 'Show them how it all fits together'.
• To improve decision-making
– The information presented to the players of a management game is often structured to create a 'window' between making
decisions and discovering the result. This makes it possible to review the decision clinically before the results are known. It is
advantageous, because outcomes do not always prove that a decision was 'good' or 'bad', both in real life and in games they may
be affected by chance, or by unforeseeable factors, so that a theoretically good decision produces a poor result (or the reverse).
When that happens, the analysis of the decision is apt to be too strongly coloured by the outcome.
• Increasing behavioural skill
– It is human to be concerned with oneself and one's own objectives, and to pay inadequate attention to the effect one's behaviour
is having on those who observe it. The social sciences have had a large influence on management training by demonstrating some
critical facts. Facts such as these: how we appear to others, behaviours to achieve short-term goals that are counter- productive
in terms of other goals because they damage relationships, working together demands a range of skills that are not intellectual in
nature but, rather, social: skills in building relationships and in creating an environment where people feel comfortable, single
skill items, of which the best example is perhaps 'listening skill‚ human tendency to make assumptions and treat them as facts,
the tendency to evaluate ideas by reference to the status of the person offering them rather than their inherent merit.
• Giving pleasure and promoting teamwork
– The words 'giving pleasure' have been used deliberately because good teamwork and pleasure are closely related. This is
essentially a request about teambuilding, recognizing that people work better together (especially in terms of communicating) if
there is knowledge and respect between them. The situation has become the motivator, not the task objective or an extrinsic
reward.
Simulation games
• CARD-SORT EXERCISE
Participants receive cards, which identify a range of people, skills, actions, or characteristics.
They must sort the cards into piles according to some prescribed criterion. The result is often
compared with an expert answer. Quantitative scoring is possible, but is seldom used.
• BOARD GAME
A game in which developments are controlled and displayed by moving tokens on a board, or
writing on a board.
• COMMUNICATION GAME
A game whose principal intended benefit is the improvement of communicative skills. Numerous
different situations are used to provide the subject matter for communication.
• DISCUSSION GAME
Participants discuss one or more problems or case studies and formally agree an answer, proposal
or recommendation. This is subject to staff comment and comparison with accepted wisdom. The
game is judged in a qualitative rather than a quantitative manner.
• ICEBREAKER
A short exercise requiring interaction between participants as a first step in getting to know each
other.
• IN-TRAY EXERCISE
A game in which participants receive a mixed bag of tasks (usually as papers) representing the
current workload of an administrator or decision-maker. Each must be annotated with the action
thought appropriate. The decisions are normally judged in a qualitative manner against expert
opinion.
Simulation games
• INTERACTIVE COMPUTER CONTROLLED BUSINESS GAME

A game based on written data about a simulated company. Playing teams are required la make
quantitative decisions about prescribed variables (e.g. price of the product). These are entered
into a microcomputer program, which uses a set of mathematical equations (a model) to compare
them with one another. Results are calculated and returned to the teams, and the cycle repeats.
Manual control is also referred to problem usually intellectual and paper-based, to which there is
only one correct answer. It is a decision-making exercise in which players receive limited data
about a problem and have to choose between several answers provided for them. For each answer
there is a different consequence, creating a new situation and offering another set of choices. It
is a multi-stage exercise.
• INTERACTIVE COMPUTER CONTROLLED BUSINESS SIMULATION
This is a device based on written data about a simulated business. Playing teams are asked to
make quantitative decisions about prescribed variables (e.g. price of the product). These are
entered into a microcomputer program, which uses a set of rules (a model) to determine the
consequence. The decisions of the teams are treated separately, so that competition exists only
through the comparison of performance figures, i.e. strategies of the teams do not impact on
each other. The term direct access may be used to indicate that teams enter decisions directly
into a microcomputer rather than completing a decision form for entry by an administrator.
• INTERACTIVE COMPUTER CONTROLLED MANAGEMENT SIMULATION
Similar in form to the business simulation, this type of game applies to a non-business activity
(e.g. a government department or a natural system).
Simulation games
• PROBLEM SOLVING EXERCISE

This is a form in which problems of any conceivable type are used to test and improve cooperative
skills. Results can usually be judged as 'right' or 'wrong'. The title is often followed by a statement
of the means by which the problem is presented (e.g. card based).
• PROGRAMMED SIMULATION
A decision-making exercise in which players receive limited data about a problem and have to
choose between several answers provided for them. Expert comment is provided for each answer,
and all players (whatever choice they make) then encounter a different, but related problem.
This is a multi-stage exercise.
• RANKING EXERCISE
Players are given a list of items and asked to rank them in order of value, importance or priority,
with reference to some described situation. The most common form is the survival exercise.
Rankings are first made by individuals, then by the group, and are then compared with an expert
answer. Quantitative scoring is sometimes used.
• ROLE PLAY
Used as a title when a situation is simulated by direct, unconstrained speech between the parties.
• SIMULATION
A replication of the whole or some part of a work activity or work situation. The method used to
simulate the activity (e.g. physical models) is normally specified. This heading excludes computer
simulation.
Lecture 12-13
OPERATIONS RESEARCH IN BUSINESS
FORECASTING METHODS AND MODELS,
LINEAR PROGRAMMING,
NETWORK MODELS
OR IN BUSINESS MODELLING
History – first contributions
• Adam Smith (1723-1790)

– „Wealth of Nations” ed. 1776: „The wealth of nations is productivity”;
– Work division and specialization - the way to improve productivity.
• Frederick W. Taylor (1856-1915)

– Known as ‘father of scientific management’;
– In 1881, as chief engineer for Midvale Steel, studied how tasks were done;
– Began first: time & motion studies;
– Created efficiency principles;
– Taylor: Management Should Take More Responsibility for:
• Matching employees to right job
• Providing the proper training
• Providing proper work methods and tools
• Establishing motivation for work to be accomplished
• Henry Ford (1863-1947) ‘Make

– In 1903, created Ford Motor Company;
them all
alike!’
– In 1913, first used moving assembly line to make Model T;
– Unfinished product moved by conveyor next to work station;
– Paid workers very well for 1911 ($5/day!).
OR aims
• Operations – problems that concern how to conduct

and coordinate the operations within an organization
• Research – use of the scientific method to address
these problems
• Interdisciplinary – brings together:
– mathematics
– statistics
– industrial engineering
– management (“management science”)
– systems engineering...
• Highly application oriented
Why to study?
• Build analytical thinking skills

– Focus on relevant variables
• Modelling/spreadsheet skills are valuable to employers
– For both “producer” and “consumer” of model results
• Leverage “dominant” technology
– Supply chain management, asset management
• Exploit computer revolution
– Easier, cheaper and more powerful tools (everywhere data –
what to do with it?)
• Combine the general and specific knowledge
– Eliminate the “expert” vs. “analytical” debate
• Integrates other disciplines
– Marketing/finance/operations
OR modelling
Structuring the real-life situation into a mathematical

model, abstracting the essential elements so that a
(Understand) solution relevant to the decision maker's objectives can
Model be sought.
(and verify) This involves looking at the problem in the context of the
entire system .
Exploring the structure of such solutions and developing

systematic procedures for obtaining them.
(Strategize)
Developing a solution, including the mathematical theory, if
Solve necessary, that yields an optimal value of the system
(and make recommendations) measure of desirability (or possibly comparing alternative
courses of action by evaluating their measure of
desirability).
OR modelling stages
• Defining the system, problem situation and optimisation

purposes
• Building the model (conceptualisation, formalisation)
• Setting model input data
• Model programming (operational modelling)
• Validation and verification of the model
• Finding optimal solution and planning the sensitivity
experiments
• Sensitivity analysis experiments and robust analysis
• Analysis of output data, conclusion
• Documenting the OR/MS project
• Practical application of OR/MS modelling results
OR modelling toolset
• Linear Programming
• Nonlinear Programming
• Integer Programming
• Network Programming
• PERT/ CPM
• Dynamic Programming
• Game Theory
• Decision Analysis
• Markov Chains
• Queuing Theory
• Inventory Theory
• Markov Decision Processes
• Stochastic Programming
• Forecasting
• Simulation modelling (??)
Prescriptive vs. descriptive
• Prescriptive models make a recommendation on a course of action

– Mathematical Programming models
• Also known as “Optimization Models”: Linear programming, Integer,
quadratic
• Given known inputs interaction and limitations
• Prescribe (or recommend) an optimal strategy
– Decision-making models
• Decision making under uncertainty (probabilistic models)
• Game-theoretic models (considering the reaction of others to a decision)
• Descriptive models describe and outcome of a course of action
– Statistical Models
• Specifically - Regression analysis
• Given a number of variables with unknown quantitative relationship,
• Estimate the impact of one set of variables on another
– Simulation Models
• Given random or unspecified variation in inputs and dynamic interactions
between inputs
• Describe likely outcomes of a given set of inputs (“What-if” analysis)
Business problem example to apply multiple model types
• Optimal pricing for a suite of interrelated products

– Interrelated by their cost structures – cost of one affects the cost
of another
– Interrelated by their demand – consumption of one affects the
consumption of another
– Example: Rail freight transportation services
• Regression analysis
– Estimates the cost curves, demand curves
• Optimization
– Recommends optimal prices, given costs and demands
– (may be a math program or decision-making/game theoretic
model)
• Simulation
– Evaluates “robustness” of recommendations against future
unknown variations (e.g. customer response to price change,
shifts in demand)
Math Programming Model ingredients
• An Objective –
– a mathematical expression
– to be maximized or minimized
– By changing values of decision variables
– E.g. Maximize Profits; Minimize Total Distance, etc.
• And Constraints -
– Relationships among the decision variables which somehow limits
their use
• “Subject To:” – used to identify the constraints
– E.g.
• Minimum output produced must be greater than or equal to customer
demand
• Maximum used must be less than or equal to total available inputs
• Production of one product must equal production of another
Math Programming Model forms
• Linear Program (LP) – objective function and constraints are

linear
– Constraints are one of: ≥, ≤, or =
– All decision variables are continuous (can take on a fractional
value)
• Integer Program (IP)
– Like an LP, but (some) decision variables can take on only
integer values
• E.g. How many jobs are assigned to a machine
– Special case IP: variables take on values of only 0 or 1 (binary)
• E.g. Should a warehouse be open or not? (yes or no; nothing in between)
• Quadratic Program (QP)
– Like an LP, but the objective can take on a squared value
• E.g. Pricing maximization, portfolio variance minimization
Forecasting models in business
• Prediction
Reasoning about unknown events by a knowledge about known
events. Unknown events belong to the past or to the future.
• Forecasting
Reasoning about unknown events belonging to the future by a
rational and scientific knowledge about known events. Forecasting is
a rational and scientific prediction of the future events. „Scientific”
– the whole research process, embracing learning the past
(collecting data, diagnosing, transforming data from the past to the
future, formulating assumptions, conclusions,...) uses scientific
knowledge (methodologies, theories, rules, problems).
• Forecast object
It is a system (set), to which a forecast is to be dedicated.
• Forecast event
It is an event which occurs in a forecast object.
• Forecast variables
There are quantitative and qualitative variables describing forecast
event.
– Simple event – described by only one variable.
– Complex event – described by many variables.
• Forecasting approaches
– Ontological (the nature of events and their inter-relations).
– Gnoseological (the knowledge about the nature of events, their inter-relations’
mechanisms).
Functions of forecasts
• Preparation function
Forecasting as an activity in order to prepare other activities (e.g.,
decision making).
• Activation function
Forecasting as an introduction to take some actions in order to have
positive effects or in order to act against negative effects.
Research forecast – to recognize the future and possible versions of
the future.
Warning forecast – to predict negative events.
• Information function
Forecasting as an information about incoming changes in order to
avoid future fear.
Realistic forecast – with high level of accuracy and customers
confidence.
Classification of forecasts
• Criterion of state-variable representation

– Quantitative (point, interval),
– Qualitative.
• Criterion of state-variable changes
– Short-term (only quantitative),
– Medium-term (quantitative and small qualitative),
– Long-term (quantitative and large qualitative).
• Criterion of possibility to control
– Control variables,
– Non-control variables.
Forecasting methods
• Time-series analysis and forecasting methods

(extrapolation methods),
• Cause-effect forecasting methods (causal
methods),
• Analogy forecasting methods,
• Heuristic methods (judgmental methods),
• Mixed methods (e.g., scenario method).
Forecasting methods
• DECOMPOSITION
Classical decomposition assumes that the data are made up of at least
three components: seasonality, trend, and randomness. The method
attempts to separate these components to simplify the forecasting problem.
Quantitative forecasting models assume that the time series follows some
pattern which can be extrapolated into the future.
yt
Cycles
Seasonality
Trend
Constant level
Randomness
Time
Forecasting methods
• Four kinds of trends are shown coupled with three kinds of

seasonality. The patterns are often called forecast profiles because
they show how the forecasts look if they are plotted against time.
• The constant-level models assume no trend at all in the data. The
time series is assumed to have a relatively constant mean. The
forecast for any period in the future is a horizontal line.
• The linear trend models forecast a straight-line trend for any period
in the future.
• The exponential trends forecast that the amount of growth will
increase continuously. At long horizons, these trends become
unrealistic. Thus models with a damped trend have been developed
for longer range forecasting. The amount of trend extrapolated
declines each period in a damped trend model. Eventually, the trend
dies out and the forecasts become a horizontal-line.
• The additive seasonal pattern assumes that the seasonal
fluctuations are of constant size. The multiplicative pattern
assumes that the seasonal fluctuations are proportional to the data.
As the trend increases, the seasonal fluctuations get larger.
• TYPES OF EXTRAPOLATION METHODS

Moving averages and exponential smoothing are
related extrapolation methods which use special kinds of
averages of the most recent data to forecast. Trend line
analysis is the comparison of regression models of the
rate of growth of the data over time. In the regression
model, the dependent variable is sales and the
independent variable is some function of time. The
straight-line projection is similar, except the company
does not bother with comparing different regression
models - a linear (straight-line) trend is always used.
• Naive method
Forecasting rule:
y  y t 1
*
t
*
where: y t - forecast of variable Y for time t, y t 1 -
observation of real value of variable Y in time t-1
• Moving average method

t 1
1
y *t    yi
k i t k
• Weighted moving average method

t 1
y  *
t y
it k
i  w i  t  k 1
k
w
i 1
i 1
• Simple exponential smoothing method

y    y t 1  1     y
*
t
*
t 1 y *
t 1 
   y t 1  y *
t 1 
• Linear trend method

yt  a  b  t
n
 t  t   y t  n 1
b t 1
a  y  bt t
n
2
 t  t 2
t 1
• Naive method yt*  yt 1

1 t 1
• Moving average method yt*   
k i t  k
yi
t 1 k
• Weighted moving average method yt*  y w
i t  k
i i t  k 1 w 1 i
i 1
• Simple exponential smoothing method

yt*    yt 1  1     yt*1  yt*1    yt 1  yt*1  

yt  a  b  t
n
• Linear trend method
 t  t   y
t 1
t
 n 1
a  y bt b n
t
   2

2
where: t t
y t*- forecast of variable Y for time t, t 1
yt 1 - observation of real value of variable Y in time t-1,
k, w, α, a, b, n – parameters.
Linear programming in business
Linear programming is used to solve problems in

a diversity of areas such as:
– Airline crew scheduling
– Portfolio management
– Product mixing
– Diet and nutrition
– Military problems
– Agriculture
– Environmental studies and management
– etc.
• An example: Tables and Chairs

• A furniture manufacturer is deciding on tables and chairs production for the
upcoming quarter. Each chair sold nets the manufacturer $20. Each table
makes $30 in profit.
• The manufacture has a supply of 500 board feet each week and 100 labour
hours to allocate. Each chair takes 10 board feet of wood, each table takes
20 board feet.
• Each chair requires 4 labour hours; each table takes 2 hours of labour.
• The manufacturer wants to produce no more than 40 chairs and no more
than 20 tables
• What should the manufacturer do?

• Identifying the key ingredients to the math model

• Decision Variables:
– Manufacturer must decide how many tables („T”) and chairs („C”) to produce
– The objective and constraints must be functions of these decision variables
• Objective:
– The manufacturer’s objective? Unstated in problem
– If it is to minimize costs – should produce 0 units
– If it is to maximize T or C, should produce T=25 or C=20
– It may be safe to assume (or clarify with the business owner) that this
manufacturer wants to MAXIMIXE PROFITS
– Maximize Profit = $20*C + $30*T
• Constraints:
– Total board feet used = 20*T + 10*C ≤ 500
– Total labour used = 4*C + 2*T ≤ 100
– Total Chairs = C ≤ 40
– Total Tables = T ≤ 20
– (Implied that T, C are both >= 0)
• Model formulation
• Objective:
Max Profit = 20C + 30T
• Subject to:
4C + 2T <= 100 (Labour)
10C + 20T <= 500 (Wood)
T <=20 (Tables)
C<= 40 (Chairs)
• The “Simplex” method

– Like knowing how internal combustion works in order to drive a car
– Nice to know, but not necessary…
• Linear Programs often start with a feasible solution
– Meets all constraints
– Example: produce 0 units (T=0, C=0)
• Model looks at trade-offs between variables
– Benefit produced by increasing one output (increased profit)
– Compared to the cost of giving up an alternative output (each chair means you give up some
capacity for building tables)
• Change current solution by moving in profit-improving directions
– Continually try different combinations of outputs
– Until no profit-improving possibilities exist
• Efficiently checks only the intersections of constraints
– Because of the linear nature of the problem, we know that the optimal solution will end up
at a corner of two constraints
• Graphical solution
Chairs Problem: Maximize Profit
Table Constraint Wood Supply = 500 board feet
50
Labor Supply = 100 hours
40 Chair uses 10 wood and 4 labor;
Chair Constraint Table uses 20 wood and 2 labor;
Chair = $20 profit; Table = $30 profit
Wood Constraint Customer orders: 20 Tables, 40 chairs
Problem Statement:
Max Profit = 20C + 30T
Subject to
25
4C + 2T <= 100 (Labor)
10C + 20T <= 500 (Wood)
(16.67T,16.67C)
T <=20
(20T,10C) C<= 40
Feasible
Solution
Space
Labor constraint
20 25 50
Tables
Table Constraint
Chairs 50
40
Chair Constraint
Wood Constraint
25 Optimum Solution:
S0’: Profit = 500 Approx. (16.67T,16.67C)
(20T,10C)
Labor constraint
S0: Profit=$0 20 25 S3: Profit = $833 Tables
S2: Profit = 800
S1: Profit = 600

• Special Case LP results that can occur:

• Unbounded
– The need to maximize something, and there are no constraints on the decision
variables
– The optimal solution is to produce infinite!!
– Unbounded problems are usually missing important constraints
• Infeasible
– By the time in implementing all the constraints, the feasible region is null (nada,
zip, zilch, nothing, empty)
– The problem has no solution
– Usually the constraints are implemented incorrectly (units, etc.)
– Sometimes a cost is represented as a constraint
• Sensitivity Analysis:
• Sometimes we want to understand how much an optimum solution will
change if some input data changed
– Remember, we have assumed perfect data and information to this point
• Examples:
– How much would the Table constraint have to be reduced before it
became “important” – has an effect on the solution?
• Currently, maximum tables is set at 20; if it were set at 16.67 or
less (a reduction of 3.33), it would become important to (or change)
the solution
– What if we could sell tables for a higher price (more profit); Would that
change the optimal mix?
• This is like changing the slope of the isoprofit curve
– What would it be worth to expand labour or wood constraints?
• A parallel shift of one of the constraints
• Sensitivity Analysis: Making a loose table constraint

tight
• Sensitivity analysis: Price of chairs falls by $5

• Sensitivity analysis: One more unit of labour

• Presentation of results
• We recommend 16.67 chairs and 16.67 tables be
produced per week in order to earn $833 in profit per
week
• All labour and wood inputs are fully utilized with this
solution
• We suggest if it is possible, that we expand labour as
much as 70 hours per week in order to gain $1.66 in
profit per week increase per labour hour (116 total
potential)
• Problem with Chairs and Tables solution!

• A marketing expert exasperatedly informs us that it is crazy to produce
equal numbers of chairs and tables
– First of all, we sell chairs at a ratio of no less than 4:1 over tables (that
make sense)
– And chairs break more often than tables, so we have a thriving
replacement business (We can exceed 4:1, but we better not fall below
it)
• Going back to our operations expert, we inquire if this is true.
• Of course, he indicates, “&%*$ yes, it’s true, why do you think I told you we
never produce more than 20 tables or 40 chairs??”
• We now realize we never had a well-defined problem… so we go back and
reformulate the problem with this new constraint
• Revised Table and Chairs problem

• Sensitivity analysis terms: Adjustable Cells

• In Excel, two tables are produced in a sensitivity analysis:
– “Adjustable Cells” and “Constraints”
• Adjustable Cells Sensitivity analysis
– Final Value – optimal solution for the decision variable
• E.g. 16.67 Tables in our base solution
– Reduced cost – amount the coefficient in the objective function on a decision has
to change before it appears in the solution
• No example in our problem – both Tables and Chairs have a positive value in
the final solution
– Allowable increase/decrease – amount an objective function coefficient can
change before changing the
• E.g. Chair profit can go down $5, or Table profit can go up $10, without changing the
chair/table mix of 16.67 apiece
– Objective coefficient – the input data value of each decision variable to the
objective function
• E.g. Tables = $30; Chairs = $20
• Sensitivity analysis terms: Constraints

• Constraints:
– Final value - the final value of the use of a resource in a constraint
• E.g. we use all 100 units of labor and 500 units of wood in the base solution
– Shadow Price – the amount the objective function would grow if the constraint were
expanded by one unit
• E.g. The objective function increased by $1.67 by expanding the labor constraint one
unit
– Allowable increase or decrease
• Amount a constraint can change before the shadow price changes
• In the case of the Table constraint, can decrease the maximum table constraint by 3.33
before the shadow price changes from 0
– Constraint R.H. (Right Hand) side
• Original value (input data) of the constraint maximum or minimum
• Called R.H. side because typically constraints are stated as:
f(decision variables) <= max
and “max” is on the right hand side of the inequality.
Economic order quantity (EOQ) model
Economic Order Quantity Model – EOQ

Annul cost
D - annual demand
HC - annual holding cost
H - holding cost per unit per year
SC - total order (set up) cost per year
Sc - cost per order (set up cost)
Total Cost TC – total cost
Cmin – minimal total cost
Q - order quantity
Cmin EOQ= Q*- economic order quantity
Holding Cost
Order (Setup)
Cost
Economic Order Quantity
Q* Q
Objective: Total cost minimisation 2DSc
Q*  EOQ 
TC  HC  OC  min H
Economic order quantity (EOQ) model
Economic Order Quantity Model – EOQ

EOQ Model - example
DATA Number of orders per year
D 1200
D = 1200 units/year ON    6 orders / year
Sc = 100 $/order Q* 200
H = 6 $/unit./year Annual holding cost
WD = 240 working days /year
Q* 200
HC  H   6  $600
2 2
Economic Order Quantity
Total order cost per year
2 D Sc 2 1200 100 D 1200
Q*    200 units SC   Sc  100  $600
H 6 Q* 200
Maximal stock Total inventory cost
S  Q*  200 units TC  HC  SC  600  600  $1200
Average stock Order cycle
S Q * 200 WD 240
Sav     100 units T   40 days
2 2 2 ON 6
Economic order quantity (EOQ) with discount model
EOQ Model with Quantity Discounts

Quantity Discounts Inventory Model
1. Inventory holding cost is fixed (not dependent on the price)
Cost TC (P1)
One common order PROCEDURE for determining economic order
quantity Q* for different TC (P2) quantity when the unit holding cost is a fixed value
price.
TC (P3) (unit holding H cost is not dependent on the price).
1. Calculate Q* common for all prices:
2DSc
Q* 
H
HC (P1, P2, P3) 2. Define curve of real total cost TC for Q*.
3. If Q* is in real scope of TC curve with the
lowest price than Qd* = Q*.
4. If Q* is in real scope of other curve, calculate
total cost for Q* and for points where price
drop down.
OC 5. Compare costs. Economic order quantity is
Q with the lowest TC.
Qd* = Q (TC min)
Q* Q
Economic production order quantity (POQ) model
Production Order Quantity Model – POQ

EOQ with Gradual Replenishment Model
MODEL ASSUMPTIONS
• EOQ assumptions Quantity parameters:
• Gradual inventory replenishment Qp -production quantity, batch size
S - maximal stock
Inventory Sav - average stock
T1 T2 p – production rate
Qp d – inventory consumption rate
Time parameters:
S
T1 - production and consumption
Qp period
T2 - inventory consumption period
Sav
IC - inventory cycle
PC – production cycle
Time
PC
IC
Economic production order quantity (POQ) model
Production Order Quantity Model – POQ

EOQ with Gradual Replenishment Model
POQ model parameters (2)
2D Sc p
Economic production quantity Qp*  
H pd
pd
Maximal inventory S  Qp *   S  PC   p  d 
 p 
S
Average inventory S av 
2
D
Annual setup numbers SN 
Qp *
LD Qp* Production Qp*
Inventory cycle CZ   cycle
PC 
LZ d p
Decision trees
• Analysing problems with decision trees involves five steps:

1. Define the problem.
2. Structure or draw the decision trees.
3. Assign probabilities to the states of nature.
4. Estimate payoffs for each possible combination of decision alternatives and
states of nature.
5. Solve the problem by computing expected monetary value (EMV) for each state-
of-nature node. This is done by working backward – that is, by starting at the
right of the tree and working back to decision nodes on the left.
FM (0.5)
• Example: EMV(1) = €10.000 €200.000
1
States of Nature LP UM (0.5) - €180.000
Alternatives Favourable Unfavourable
Market (FM) Market (UM) EMV(2) = €40.000
Construct large plant (LP) €200.000 - €180.000 SP

FM (0.5)
€100.000
Construct small plant (SP) €100.000 - € 20.000
2
UM (0.5)
Do nothing (DN) € 0 € 0 - € 20.000
DN
€ 0
Multi-criteria selection problem solving
• Multifactor Evaluation Process (MFEP)

– Individuals subjectively and intuitively consider the various
factors in making their selection and decision making by
quantitative approach. All of the important factors can then be
given appropriate weights and each alternative can be evaluated
in terms of these factors.
• Analytic Hierarchy Process (AHP)
– Individuals cannot be able to quantify preferences for various
factors and alternatives. The process of the selection and
decision making uses pairwise comparisons and then computes
the weighting factors and evaluations for use.
• Multifactor Evaluation Process (MFEP)

– Example:
• Assume that there are four criteria that are being used to evaluate suppliers, quality, price, service
and delivery. These attributes were weighted with the relative importance considered by the buyer on
a 0 (less important) to 1(most important) scale. Further, assume that proposals from four suppliers are
being considered (Supplier 1, Supplier 2, Supplier 3 and Supplier 4) - matrix with weighted attributes.
• The following equation presents how the result for Supplier 1 is calculated:
Supplier 1= (0.46*0.48) + (0.30*0.24) + (0.14*0.12) + (0.11*0.16) = 0.32
• According to the other results, the higher weight belongs to Supplier 2, and is judged to be the best.

– The Analytical Hierarchical Process (AHP) is a decision-making method developed
by Saaty (1980) for prioritizing alternatives when multiple criteria must be
considered and allows the decision maker to structure complex problems in the
form of a hierarchy, or a set of integrated levels. Generally, the hierarchy has at
least three levels: the goal, the criteria, and the alternatives. For the supplier
selection problem, the goal is to select the best overall supplier The criteria can
be quality, price, service, delivery, etc.
– The AHP offers a methodology to rank alternative courses of action based on the
decision maker’s judgments concerning the importance of the criteria and the
extent to which they are met by each alternative. For this reason, AHP is ideally
suited for the supplier selection problem.
– The problem hierarchy is based on an analysis based on the impact of a given
level on the next higher level. The process begins by determining the relative
importance of the criteria in meeting the goals. Next, the focus shifts to
measuring the extent to which the alternatives achieve each of the criteria.
Finally, the results of the two analyses are synthesized to compute the relative
importance of the alternative in meeting the goal.

– Managerial judgments are used to drive the AHP approach. These judgments are expressed in
terms of pairwise comparisons of items on a given level of the hierarchy with respect to
their impact on the next higher level. Pairwise comparisons express the relative importance
of one item versus another in meeting a goal or a criterion. Each of the pairwise comparisons
represents an estimate of the ratio of the weights of the two criteria being compared.
Because AHP utilizes a ratio scale for human judgments, the alternatives weights reflect the
relative importance of the criteria in achieving the goal of the hierarchy.
– The use of the AHP approach offers a number of benefits. One important advantage is its
simplicity. The AHP can also accommodate uncertain and subjective information, and
allows the application of experience, insight, and intuition in a logical manner.
– The AHP approach, as applied to the supplier selection problem, consists of the following five
steps:
1. Specify the set of criteria for evaluating the supplier’s proposals;
2. Obtain the pairwise comparisons of the relative importance of the criteria in achieving the goal, and
compute the priorities or weights of the criteria based on this information;
3. Obtain measures that describe the extent to which each supplier achieves the criteria;
4. Using the information in step 3, obtain the pairwise comparisons of the relative importance of the
suppliers with respect to the criteria, and compute the corresponding priorities;
5. Using the results of steps 2 and 4, compute the priorities of each supplier in achieving the goal of the
hierarchy.

– Example:
• Assume that there are three criteria to evaluate suppliers: quality (Q), price (P), delivery (D). Further,
assume that proposals from three suppliers are being considered: supplier 1 (S1), supplier 2 (S2),
supplier 3 (S3). The decision making hierarchy is: Q(S1/S2/S3), P(S1/S2/S3), D(S1/S2/S3).
• The key to using AHP is pairwise comparisons and to compare two different alternatives a scale that
ranges from equally preferred to extremely preferred is to be set ( 1 – Equally Preferred, 2 - Equally to
Moderately Preferred, 3 – Moderately Preferred, 4 – Moderately to Strongly Preferred, 5 – Strongly Preferred, 6 – Strongly to
Very Strongly Preferred, 7 – Strongly Preferred, 8 – Very to Extremely Strongly Preferred, 9 – Extremely Preferred). Once
the column totals is determined, the numbers are divided by the respective column totals.
• To determine the priorities for quality criterion for the three suppliers, the average of the various rows
in matrix must be calculated.

– Example – cont.:
• Next step of the AHP algorithm is to calculate a consistency ratio. First is to determine the weighted
sum vector by multiplying the factor evaluation number for all alternatives (suppliers) times the
relevant column of the original pairwise comparison matrix. Then the consistency vector is calculated
by dividing the weighted sum vector by the factor evaluation values determined previously.
Quality Quality
[2.0423] = (0.6583 ∙ 1) + (0.2819 ∙ 3) + (0.0598 ∙ 9) [3.1025] = 2.0423 / 0.6583
Weighted sum [0.8602] = (0.6583 ∙ 0.3333) + (0.2819 ∙ 1) + (0.0598 ∙ 6) Consistency [3.0512] = 0.8602 / 0.2819
vector [0.1799] = (0.6583 ∙ 0,1111) + (0.2819 ∙ 0.1677) + (0.0598 ∙ 1) vector [3.0086] = 0.1799 / 0.0598
• Next step of the AHP algorithm is to compute values for consistency vector average (λ) and
consistency index (CI) with the formula CI = (λ -n) / (n-1), where n is the number of items to be
compared. In the example is: λ = (3.1025 + 3.0512 + 3.0086) / 3 = 3.0541; CI = (3.0541 – 3) / (3 -1) =
0.0270.
• Finally, the consistency ratio (CR) must be calculated as consistency index divided by the random
index (RI). RI is a direct function of the number of alternatives being considered. CR = CI / RI = 0.270 /
0.58 = 0.0466. For CR greater than 0.10, the decision maker must consider re-evaluating comparisons.
n 2 3 4 5 6 7 8
RI 0 0.58 0.90 1.12 1.24 1.32 1.41


– Example – cont.:
• Next step of the AHP algorithm is to make the same calculations for the other factors, namely price (P)
and delivery (D) calculate a consistency ratio. As it was for quality factor it starts with the matrix of
pairwise comparisons. Then the same calculations must be done and it ends up with factor evaluations.
Assume that pairwise comparisons matrixes for price and delivery factors are as follow:
• Finally, the factor evaluation matrix, factor weights and the total weighted evaluations are to be
calculated.
• Final decision for this multi-criteria analysis by AHP algorithm is: the best supplier is Supplier 3.
Waiting lines
• Waiting line models are useful in both manufacturing and service

areas. Analysis of queues in terms of waiting line length, average
waiting time, and other factors helps us to understand service
systems, maintenance activities, and shop-floor control activities.
There are three parts of a waiting-line, or queuing system:
1. Arrivals or inputs to the system.
2. Queue discipline, or the waiting line itself.
3. The service facility.
• Waiting line system characteristics:
– Arrival characteristics:
• Size of arrival population;
• Pattern of arrivals to the system;
• Behaviour of arrivals.
– Waiting-line characteristics (e.g. FIFO, LIFO, SPT);
– Service facility characteristics:
• Queuing system (single-channel, multi-channel);
• Service time distribution.
Gantt, PERT and CPM
• Gantt Charts
– Planning charts used to schedule resources and allocate time;
– Useful for depicting simple processes (projects) or parts of large processes;
– Show start and completion dates for individual tasks;
– Visually shows duration, time overlap between tasks and slack time.
• PERT Charts
– PERT (Program Evaluation Review Technique) is a technique to enable managers to schedule, monitor, and
control large and complex projects by employing three time estimates for each activity;
– Show order of activities or dependencies between activities;
– Visually shows dependencies between tasks, tasks can be done in parallel and slack time by data in
rectangles.
• Critical Path Method (CPM)

– CPM is a network technique using only one time factor per activity that enables managers to
schedule, monitor, and control large and complex projects.
Gantt, PERT and CPM
• PERT and CPM Framework

– PERT and CPM both follow the following six basic steps:
1. Define the project and prepare the work breakdown structure;
2. Develop relationships among the activities. Decide which activities must precede and which must
follow others.
3. Draw the network connecting all of the activities.
4. Assign time and/or cost estimates to each activity.
5. Compute the longest time path through the network. This is call the critical path.
6. Use the network to help plan, schedule, monitor, and control the project.
– PERT and CPM are important because they can help answer questions
such as the following about projects with many activities:
• When will the entire project be completed?
• What are critical activities or tasks in the project – that is, the ones that will delay the entire project if
they are late?
• Which are the noncritical activities – the ones that can run late without delaying the whole project’s
completion?
• What is the probability that the project will be completed by a specific date?
• At any particular date, is the project on schedule, behind schedule, or ahead of schedule?
• On any given date, is the money spent equal to, less than, or grater than the budgeted amount?
• Are there enough resources available to finish the project on time?
• If the project is to be finished in a shorter amount of time, what is the best way to accomplish this
goal at the least cost?
Gantt, PERT and CPM
• Scheduling parameters (Gantt, PERT, CPM, CPA)

• Optimistic time
– It is the „best” activity completion time that could be obtained in a PERT network.
• Probable time
– It is the most likely time to complete an activity in a PERT network.
• Pessimistic time
– It is the „worst” activity time tat could be expected in a PERT network.
• Slack time
– It is the amount of time an individual activity in a network can be delayed without delaying
the entire project.
• Critical Path Analysis (CPA)
– The objective of CPA is to determine the following quantities for each activity:
• ES – earliest activity time. All predecessor activities must be completed before an activity can be
started. The ending time of the predecessor activities is the earliest time activity can be started;
• LS – latest activity time. All following activities must be completed without delaying the entire project.
This is the latest time an activity can be started without delaying the entire project;
• EF – earliest activity finish time;
• LF – latest activity finish time;
• S – activity slack time, which is equal to LS-ES or LF-EF.
Gantt, PERT and CPM
• The critique of PERT and CPM

– Advantages of PERT and CPM:
1. Useful at several stages of project management, especially in the scheduling and control of large
projects.
2. Straightforward in concept and not mathematically complex.
3. Graphical displays using networks help to perceive quickly relationships among project activities.
4. Critical path and slack time analyses help pinpoint activities that need to be closely watched.
5. Networks generated provide valuable project documentation and graphically point out who is
responsible for various activities.
6. Applicable to a wide variety of projects and industries.
7. Useful in monitoring not only schedules, but costs as well.
– Limitations of PERT and CPM:
• Project activities have to be clearly defined. Independent, and stable in their relationships.
• Precedence relationships must be specified and networked together.
• Time estimates tend to be subjective and are subject to fudging by managers who fear the dangers of
being overly optimistic on not pessimistic enough.
• There is the inherent danger of too much emphasis being placed on the longest, or critical, path. Near
critical paths need to be monitored closely as well.
Gantt, PERT and CPM
• Production and delivery scheduling (e.g. Gantt Chart, PERT)

• Gantt load chart
– This chart is shows the loading and idle times of several departments, machines, or facilities.
It displays the relative workloads in the system so that the manager knows what adjustments
are appropriate. For example, when one work centre becomes overloaded, employees from a
low-load centre can be processed at different work centres, some jobs at high-load centres
can be transferred to low-load centres. Versatile equipment may also be transferred among
centres. Gant load chart does have a major limitation: it does not account for production
variability such as unexpected breakdowns or human errors that require reworking a job.
Consequently, the chart must also be updated regularly to account for new jobs and revised
time estimates.
• Gantt schedule chart
– This chart is used to monitor jobs in progress. It indicates which jobs are on schedule and
which are Ahead of behind schedule. In practice, many versions of the chart are found.
Theory of constraints
• The theory of constraints (TOC)

– This is the body of knowledge that deals with anything that limits an
organisation’s ability to achieve its goals. It was popularised by Dr
Eliyahu Goldratt, a physicist, in a book „The Goal: A Process of Ongoing
Improvement” in 1986. Constraints can be physical (such as process or
personnel availability, raw materials, or supplies) or nonphysical (such
as procedures, morale, training). Recognising and managing these
limitations through a five-step process is the basis of the theory of
constraints:
• Step 1: Identify the constraints;
• Step 2: Develop a plan for overcoming the identified constraints;
• Step 3: Focus on resources on accomplishing step 2;
• Step 4: Reduce the effect of the constraints by off-loading work or by
expanding capability. Make sure that the constraints are recognised by all
those who can have impact upon them;
• Step 5: Once one set of constraints is overcome, go back to step 1 and
identify new constraints.
Lecture 14
BUSINESS & BPM MODELLING PRACTICE
DESIGN & IMPLEMENTATION OF BUSINESS MODELS
BPM CASES
FINAL CONCLUSIONS & COURSE SUMMARY
Implementation of BPM models
• Experiences, surveys of business models

implementation
• Architectures and reference models for business
• Best practices and guidelines for business
modelling
• Integration of knowledge and business models
• Models of business model implementation
BPM modelling purpose
Davies I., Green P., Rosemann M., Gallo S., Conceptual Modelling – What and Why in Current Practice, p. 30-42 [in:] Atzeni P., Chu W.,
Lu H., Zhou S., Ling T.(Eds.), Conceptual Modeling – ER 2004, 23rd Int. Conf. on Conceptual Modeling, Shanghai, China, November 8-12,
2004 Proceedings, Springer, 2004 (survey at Queensland University of Technology)
Modelling technique, size & experience
Davies I., Green P., Rosemann M., Gallo S., Conceptual Modelling – What and Why in Current Practice, p. 30-42 [in:] Atzeni P., Chu W., Lu
H., Zhou S., Ling T.(Eds.), Conceptual Modeling – ER 2004, 23rd Int. Conf. on Conceptual Modeling, Shanghai, China, November 8-12, 2004
Proceedings, Springer, 2004 (survey at Queensland University of Technology)
Modelling tool, size & experience
Davies I., Green P., Rosemann M., Gallo S., Conceptual Modelling – What and Why in Current Practice, p. 30-42 [in:] Atzeni P., Chu W.,
Lu H., Zhou S., Ling T.(Eds.), Conceptual Modeling – ER 2004, 23rd Int. Conf. on Conceptual Modeling, Shanghai, China, November 8-12,
2004 Proceedings, Springer, 2004 (survey at Queensland University of Technology)
Implementation models
• Courbon’s decision loop
• Simon’s canonical decision model

Implementation models
• Soft Systems Methodology
Systems thinking in business modelling
Roles of business models
(David A., Models implementation. A state of the art., European Journal of Operational Research, vol. 134 (2001), 459-480)
Business model design and implementation
(David A., Models implementation. A state of the art., European Journal of Operational Research, vol. 134 (2001), 459-480)
Critical enablers for BPM
• There are five critical enablers for a high-performance process:
– Process design. This is the most fundamental aspect of a process: the specification of what
tasks are to be performed, by whom, when, in what locations, under what circumstances, to
what degree of precision, with what information, and the like. The design is the specification
of the process; without a design, there is only uncoordinated individual activity and chaos.
– Process metrics. Most enterprises use functional performance metrics, which create
misalignment, sub-optimization, and confusion. Processes need end-to-end metrics that are
derived from customer needs and enterprise goals. Targets need to be set in terms of these
metrics and performance monitored against them. A balanced set of process metrics (such as
cost, speed, and quality) must be deployed.
– Process performers. People who work in processes need a different set of skills and
behaviours from those who work in conventional functions and departments. To realize the
potential of end-to-end work they need an understanding of the overall process and its goals,
the ability to work in teams, and the capacity to manage themselves.
– Process infrastructure. Performers need to be supported by IT and HR systems if they are to
discharge process responsibilities. Functionally fragmented information systems do not
support integrated processes, and conventional HR systems (training, compensation, and
career, etc.) reinforce fragmented job perspectives. Integrated systems (such as ERP systems
and results-based compensation systems) are needed for integrated processes.
– Process owner. An organization serious about its processes must have process owners: senior
managers with authority and responsibility for a process across the organization as a whole.
Principles of BPM
• It can be helpful to summarize the concepts of process
management in terms of a handful of axiomatic
principles, some obvious, some not, that together
express its key themes:
– All work is process work;
– Any process is better than no process;
– A good process is better than a bad process;
– One process version is better than many;
– Even a good process must be performed effectively;
– Even a good process can be made better;
– Every good process eventually becomes a bad process.
Principles of BPM
• All work is process work. Sometimes the assumption is made that the concepts of
process and process management only apply to highly structured, transactional work,
such as order fulfilment, procurement, customer service, and the like. Nothing could
be further from the truth. The virtues of process also adhere to developmental
processes, which centre on highly creative tasks, such as product development,
demand creation, and so on. Process should not be misinterpreted as a synonym for
routine or automation, reducing creative work to simplistic procedures. Process
means positioning individual work activities – routine or creative – in the larger
context of the other activities with which it combines to create results. Both
transactional and development processes are what is known as core processes –
processes that create value for external customers and so are essential to the
business. Organizations also have enabling (or support) processes, which create value
for internal customers; these include hire to retire, information systems
development, and financial reporting. Such processes have customers and create
value for them (as must any process, by definition), but those customers are internal.
The third category is governing processes, the management processes by means of
which the company is run (such as strategic planning, risk management, and
performance management). (Process management is itself a governing process!)
Principles of BPM
• Any process is better than no process. Absent a well-defined process design, chaos
reigns. Individual heroics, capriciousness, and improvisation rule the day – and results
are inconsistent and unsustainable. A well-defined process will at the least deliver
predictable, repeatable results, and can serve as the staging ground for
improvement.
• A good process is better than a bad process. This statement is not as tautological as
it seems. It expresses the criticality of process design, that the type of a process
design is a critical determinant of its performance, and that some processes are
better designed than others. If a company is burdened a bad process design, it needs
to replace it with a better one.
• One process version is better than many. Standardizing processes across all parts of
an enterprise presents a single face to customers and suppliers, yields profound
economies in support services such as training and IT systems, allows the
redeployment of people from one business unit to another, and yields a host of other
benefits. These payoffs must be balanced against the intrinsically different needs of
different units and their customers, but our bias should be in favour of
standardisation.
Principles of BPM
• Even a good process must be performed effectively. A good process design is a
necessary but insufficient prerequisite for high performance; it needs to be combined
with carefully managed execution, so that the capabilities of the design are realized
in practice.
• Even a good process can be made better. The process owner needs to stay
constantly vigilant, looking for opportunities to make modifications to the process
design in order to further enhance its performance.
• Every good process eventually becomes a bad process. No process stays effective
forever in the face of change. Customer needs change, technologies change,
competition changes, and what used to be a high level of performance becomes a
poor one – and it is time to replace the formerly good process with a new one.
The issues as the cause of difficulties
• Strength of the functional organisation.
• Lack of true integration due to inadequate
communication and collaboration between internal
functions and external partners (suppliers etc.).
• Weak advance planning of projects — lack of
coordination
• Poor estimating and planning of human and other
resources
• Lack of human resource (particularly in the engineering
functions).
• Lack of standardisation, particularly at process level
(weak process understanding across functions).
BPM Traditions
• Quality Control Tradition
• Management Tradition
BPM Traditions
• IT Tradition
Six Core Elements of BPM
• Strategic Alignment
• Governance
• Methods
• Information & Communication
Technology
• People
• Culture
• Strategic Alignment: BPM needs to be aligned with the overall strategy of
an organization. Strategic alignment (or synchronization) is defined as the
tight linkage of organizational priorities and enterprise processes enabling
continual and effective action to improve business performance. Processes
have to be designed, executed, managed, and measured according to
strategic priorities and specific strategic situations (e.g., stage of a product
lifecycle, position in a strategic portfolio). In return, specific process
capabilities (e.g., competitive advantage in terms of time to execute or
change a process) may offer opportunities to inform the strategy design
leading to process-enabled strategies.
• Governance: BPM governance establishes appropriate and transparent
accountability in terms of roles and responsibilities for different levels of
BPM (portfolio, program, project, and operations). A further focus is on the
design of decision-making and reward processes to guide process-related
actions.
• Methods: Methods in the context of BPM are defined as the set of tools and
techniques that support and enable activities along the process lifecycle and
within enterprise-wide BPM initiatives. Examples are methods that facilitate
process modelling or process analysis and process improvement techniques.
Six Sigma is an example for a BPM approach that has at its core a set of
integrated BPM methods.
• Information & Communication Technology: ICT-based solutions are of
significance for BPM initiatives. With a traditional focus on process analysis
(e.g., statistical process control) and process modelling support, BPM-
related ICT solutions increasingly manifest themselves in the form of
process-aware information systems (PAIS). Process-awareness means that
the software has an explicit understanding of the process that needs to be
executed. Such process awareness could be the result of input in the form
of process models or could be more implicitly embedded in the form of
hard-coded processes (like in traditional banking or insurance applications).
• People: People as a core element of BPM is defined as individuals and
groups who continually enhance and apply their process and process
management skills and knowledge in order to improve business
performance. Consequently, this factor captures the BPM capabilities that
are reflected in the human capital of an organization and its ecosystem.
• Culture: BPM culture incorporates the collective values and beliefs in
regards to the process-centred organization. Although commonly considered
a “soft-factor”, comparative case studies clearly demonstrate the strong
impact of culture on the success of BPM. Culture is about creating a
facilitating environment that complements the various BPM initiatives.
However, it needs to be recognized that the impact of culture-related
activities tends to have a much longer time horizon than activities related
to any of the other five factors.
ICT related components of BPM
• Process modelling. Business processes are modelled according to a standard
notation; e.g. event-driven process chains (EPC, BPMN) or activity diagrams
of UML. The process models are used either by the human actor who carries
out the process manually or by a process engine (e.g. a workflow system).
• Process/workflow engine. These ICT systems are used as components of
process-based applications. They guarantee that processes are performed
according to their specification.
• Real-time monitoring. This function addresses the fact that the state of
running processes (instances) should be easily identifiable.
• Process performance measurement. To determine the performance of
business processes via a given set of performance indicators.
• Business rule management. It aims at extracting business rules from
traditional software applications and to store and manage them via a
separate component, called business rules engine.
The effects of BPM on performance
• Link between BPM and financial performance
– BPM introduces transparency in the organization and by discovering and analysing an
organization’s business processes, non-value adding activities are easily detected. The
elimination of non-value adding activities therefore should lead to cost reductions which in
turn should lead to improved financial performance. Some studies reveal that certain process
management methods improve profitability and provide evidence that BPM helps companies
to improve business performance, reduce inter-functional conflict and improve “esprit de
corps”.
• Link between BPM and product quality
– Considerably less attention has been paid to the effects of BPM on non-financial firm
performance. Several authors argue the BPM leads to higher product quality. There is a
positive relationship between BPM and product quality. It is therefore expected that BPM is
positively related to product quality.
• Link between PO and customer satisfaction
– Silo-oriented organizations do not easily permit their employees to concentrate on the
customers and their problems. Departments are trying to make their internal issues perfect
(they are internally focused), but they do not think about possible improvements in terms of
the customer which may result from collaborating with other departments. As business
processes are aligned with customer requirements, BPM implements customer orientation
which in turn should lead to a higher customer satisfaction.
The effects of BPM on performance
• Link between BPM and delivery speed
– By discovering and analysing an organization’s business processes, non-value adding activities
are easily detected. The elimination of non-value adding activities therefore should lead to
throughput speed improvements and throughput time reductions. The empirical studies show
that BPM has been perceived to have a positive effect on cycle time speed. It is therefore
expected that PO leads to delivery speed improvements.
• Link between BPM and time-to-market speed
– Process management enhances incremental innovation, but is detrimental to exploratory
innovation. There is a positive relationship between the extent of rules and procedures
within organizational units and exploitative innovation. By the application of process
management, the amount of products which are not developed to market on time can be
significantly reduced. Process management leads to significantly shortened time-to-market.
Therefore, it is expected that BPM is positively related to time-to-marked speed.
• Link between BPM and delivery reliability
– Delivery reliability – defined as the extent to which an organization delivers its orders on
time (an order-qualifier instead an order-winning criterion). If a company continues to not
deliver on time, customers will stop considering the company as a potential supplier.
Customers have become so demanding that if their suppliers do not deliver on time, they
take their business elsewhere. Business processes which are not under control may cause
insufficient delivery reliability - BPM leads to delivery reliability improvements.
Credit Suisse case
Source: Kuen P., Hagen C., The fruits of Business Process Management: an experience report from a Swiss bank, BPM
Journal, vol. 13, no. 4, 2007, p. 477-487.
• Credit Suisse is a global bank, operating in over 50 countries, and

headquartered in Zurich. It includes global private banking, corporate and
retail banking in Switzerland, global investment banking and global asset
management. At Credit Suisse, more than 1,000 software applications are in
place, supporting more than 60,000 employees in performing their tasks.
• In the past, business processes suffered from various shortcomings. One
major aspect was that process cycle time was too long. Another issue was
that succeeding business processes were not seamlessly integrated which
could lead to the entry of the same data twice. The third weakness is
related to unsatisfactory guidance of the employees through the processes;
and this implies that process participants could not easily identify the state
of a certain case/process instance.
• At Credit Suisse, the concept of BPM has been applied in more than ten
major processes so far. Following four real business processes represent
examples where the concept of BPM (in combination with BPM systems) has
been applied.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• The “direct trade finance” process

– Problem statement. In the past, the trade finance process (e.g. the processing of letter of
credits) included many different manual steps. Communication to and from the customers
was paper-based and time-consuming. In addition, the customers were limited regarding
hours of availability as they were bound to the office hours of the bank.
– Process reengineering. In a first step the “old” trade finance process was visualized
graphically. Through the modelling approach it became transparent that not everybody
involved in the process had the same understanding of the process structure and its related
tasks. Based on the process model, the organizational and IT-related opportunities for
improvement were identified. It became clear that an IT-based interface to external
customers must be implemented. Moreover, all cases must be handled via a modernized IT
system. To simplify the handling and tracking of the cases the use of a BPM system was
suggested. For the detailed specification of the requirements use cases (www.omg.org) were
applied. The new process established is more detailed than the previous one, consisting of
four sub-processes and 16 activities; 10 different roles are involved in the process execution.
The solution built is based on various IT components and MQS workflow system was used.
– Outcome. Currently, about 300 cases (occurrences) are executed per day. Although the
process is pre-defined to a large extent, the customers’ requirements can be met to a very
large degree. The electronic channel helped to increase competitiveness since the customers
are now able to submit orders at any time and they can track the cases easily. Internally the
restructuring and partial automation of the process led to an increase in productivity.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• The “closing accounts” process

– Problem statement. Credit Suisse has more than two million customers in retail and
corporate banking; and many of its customers have several accounts. Every day, several
hundred accounts have to be closed for various reasons. For example, customers move from
one geographic area to another, have different needs and may need another type of account,
consolidate several accounts, want to transfer their money to another bank, or die. In the
past, the “closing accounts” process consisted of many manual steps. A customer who wished
to close an account had to speak with or write to a relationship manager. He then filled out a
paper-based form or wrote a special kind of an e-mail (called flow mail) which he sent to the
administration staff, who sorted out the kinds of steps to do, updated the “pending tasks”
database and sent the order to the accounting clerk who initiated the transactions (payments
from one account to another) to be executed. If the forms were not properly filled out or
data was inconsistent, the accounting clerk had to inquire further. All in all the old process
was error-prone, slow and not very efficient.
– Process reengineering. The analysis of the process showed that administrators and the
accounting clerk had to use different back-end systems (core banking systems running on the
mainframe) to carry out their tasks. Furthermore, the analysis revealed that most account
closure cases can be handled in a uniform way; i.e. the proportion of add-cases was
relatively small. To improve the weaknesses, the process was redesigned and streamlined. In
particular, the redesign focused on reduction of the various media to be used and a
reduction in the number of roles involved in this process.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

– Process reengineering. Based on an analysis it was decided to build a new software
application that handles the closing accounts requests in an efficient and structured way.
This new application is based on a process engine (MQS workflow) that controls the activities
to be carried out. One the one hand, it controls human interaction with the system, on the
other, it invokes back-end systems which collect customer-related data needed in the
process or executes transactions automatically. The new process consists of 26 activities
(many of which interact with back-end systems), and the process can be initiated by
approximately 10,000 of the bank’s employees.
– Outcome. The performance of the new process, which is initiated several hundred times a
day, has increased to a large extent. The new, workflow-supported process led to a
reduction in cycle time by 50 percent. The number of errors has been reduced to a rate of 1
in 10,000 cases. Moreover, this process execution (controlled by a process engine) guarantees
that new rules and instructions are carried out “automatically.” To measure the degree of
automation, a useful metric is STP which stands for straight through processing. STP refers to
the complete automation of a business process, i.e. handling cases without human
interaction. STP is favoured when the number of cases (instances) is very high on the one
hand and the proportion of special cases (cases that need special processing procedures) is
low on the other. The analysis of the new STP rate shows that a large majority (80%-85%) of
the “closing accounts” cases can be handled without any manual intervention from back
office staff. In those 85% of cases, only the relationship manager is involved; in the old
process, all cases had to be handled by three different roles. Cycle time is reduced to 1 day.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

– Old process
– New process
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• The “settlement of securities” process

– Problem statement. Securities operations is a very transaction-intensive business and
therefore it is not astonishing that automation has started very early. This was also the case
at Credit Suisse. The early automation efforts led to very large PL/1 application programs.
Since, these programs were built many years ago and have been extensively modified, their
modularity has suffered and, consequently, the maintenance became expensive and – even
more important – flexibility to adapt to new demands became more and more limited. A
modification in a securities operations process was a lengthy affair. At the same time, the
number of regulations (imposed by internal or external bodies) which had an impact on the
securities processes increased. In addition, monitoring facilities were poor. Checking
adherence to service level agreements was time-consuming and not feasible.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

• Process reengineering. Based on the limitations just mentioned, Credit Suisse chose the
approach to sub-divide their old software applications into smaller chunks, called services.
To control the settlement of securities process, which requires the interaction of many
services, was decided to build a tailor-made process engine called AM (which stands for
“Auftragsmanager” – the German word for “order execution management system”). To
improve the insufficient process measurement facilities a process measurement too was
implemented. Prior to the implementation of the process engine, the old process and the
applications used had to be analysed in great detail. The involved teams used the process-
modelling software ARIS Toolset and printed the created process map on large pieces of
paper and placed them in the corridors between cubicles. If a certain issues regarding the
securities process had to be discussed, people did not go the PC, instead they debated in
front of the large pieces of paper. The graphical notation used was EPC which stands for
event-driven process chain (Scheer, 2004). To improve legibility and modularity of the
process models, five levels of detail were used. The top level showed the entire value chain,
whereas the bottom level points to services that are called. The process definition (specified
as EPCs) is loaded into a DB2 database. The Auftragsmanager interprets the process
definition and interacts with the software components (called services) needed. Execution-
relevant data is written in a log file.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

– Outcome. Through the process reengineering and the use of a process engine, a production-
style process with high predictability was established. Today about 30,000-40,000 cases are
performed daily. It is close to a fully automated process with very little human intervention.
The use of a process engine has led to major improvements in the “settlement of securities”
process. First of all, only 1 in 10,000 cases needs human intervention; 99.99 percent of
orders are processed completed automated. This leads to two highly relevant aspects: First,
manual efforts needed have decreased and this in turn leads to lower overall costs. Second,
the process’ cycle time has shortened massively. Prior to the implementation of the new
system, orders were processed in hourly batch jobs. Moreover, the new system makes it
possible to monitor cycle time of critical processes very carefully. Further useful reports that
can be created with the current technical setup are: the relative frequency that a certain
path of the process model has been utilized; and whether the process model contains paths
(sequences of events and activities) that are unused. Based on this information the process
model can be re-arranged, simplified and further improved.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• The “special orders” process

– Problem statement. In the financial services industry a large proportion of customer orders
can be handled in a rather standardized way. However, to guarantee excellent banking
services to the various customer segments, the management of special orders (i.e. orders
which cannot be processed via standard procedures) remains important since its impact on
customer satisfaction is considerable. In the past, the management of special orders suffered
from some weaknesses. First, to perform special orders many different functions and roles
were involved. It was not unusual that the fulfilment of a special order required people from
the front, the middle, and the back offices, all of which may be located in different areas.
Second, since almost each special order requires different steps – carried out by different
people using different tools and communication media – it was hard to identify the state of a
particular case. Moreover, cycle time of special orders often was high, as some cases were
not immediately forwarded after a certain step was carried out.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

– Process reengineering. To eliminate these drawbacks a generic business process was
designed for handling all special orders. The new process is only loosely structured; i.e. there
is no given sequence of activities to be carried out. The kind and number of required
activities, as well as the roles involved are identified while the process is running; this is a
clear difference to the three processes that have been presented above. Tracking of cases
submitted by customers is essential. As the sequence of activities may vary from case to
case, tracking and forwarding cannot be performed via a given process model. In this
example of process a set of pre-defined states a case can take was established. Moreover, for
each case all of the agents involved are recorded. In addition to that, each individual case is
attributed to a case owner. This setup makes it possible that responsibility of each special
order is determined and for each case the current state as well as the currently involved
agent can be identified. This generic process model was implemented in an IT system which
is based on the process engine of Action Works Metro.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.

– Outcome. Today, more than 2,000 cases are performed by the new special order process and
the people involved are very satisfied. The new process, combined with the process-oriented
IT system, led to significant effects: First, cycle time for special orders has been reduced by
30 percent; response time has sped up by a factor of 10. Today the bank fulfils many
customer requests in half-a-day versus two days previously. Second, productivity increased
by 15-30 percent. The new system freed up the bank’s highly compensated employees from
hours of daily administrative work allowing them to focus on servicing their customers.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• Through the application of BPM and the use of process-oriented IT

systems (BPM systems) in Credit Suisse quality and performance of
processes has increased substantially. The most important effects are:
– Cycle time has been reduced. This is mainly due to the fact that waiting time has almost disappeared. As
soon as a certain process step is finished the case is automatically moved forward by the BPM system.
Another element that has reduced cycle time is that employees are actively notified by the system about the
work that has to be done.
– Output per employee has increased. All process steps that can be performed by a machine (without loosing
quality) are executed by the IT system. Prior to automation, employees had to use long checklists for certain
processes to ensure the process was carried out correctly. Now it is taken over by the process engine.
– Quality of work products has increased. Quality of the cases performed has improved. Five aspects may
have caused this effect: the processes have been improved (partial re-engineering) as part of BPM, today’s
processes are more clearly defined than in the past, process automation enforces correctness of process
execution, the role (includes duty and responsibility) of the process participants has become clearer, the
structure of the processes is more visible to employees.
• The use of BPM systems in Credit Suisse has some limitations too. Credit
Suisse have been confronted with the following:
– In general, the importance of packaged software (commercial off-the-shelf software) is increasing in the
field of financial institutions. However, the various systems available do not always offer cost-efficient
integration mechanisms for BPM systems.
– Almost every BPM system available has its own reporting and performance measurement concept. Some of
them are rather rudimentary, other systems are provided with broad and user-friendly analysis functions.
Credit Suisse case
Journal, vol. 13, no. 4, 2007, p. 477-487.
• Based on the experiences with BPM Credit Suisse learned that:

– BPM makes it possible to re-arrange the “old” processes. Existing activities or sub-
processes can be newly combined in order to provide new or better services to the customer.
This is important because competition in banks depends mainly on the services offered.
– The effect of business process re-engineering can be leveraged by the use of BPM
systems. In particular, lead time can be reduced to a degree that would never be in scope
using traditional methods and tools. Moreover, the use of BPM systems leads to a better
conformance; i.e. the processes are executed in a way that is consistent to specifications.
– Automated collection of performance-relevant data is central. Data collection should not
be an additional manual task for the employees and real-time information can hardly be
gathered manually. In other words, process performance measurement can be applied more
efficiently by an integrated approach.
– BPM systems make it possible to monitor critical processes very carefully. This can be
important for different reasons: it may be important to know when and how often service
level agreements are violated, poor parts of processes can be identified if long-running cases
are identified by the system, if the load of a particular process is known, organizational and
technical corrective actions can be taken, objective metrics can be used to introduce a
performance-based salary scheme.
– BPM is not a question of all or nothing. It is a continuum, which ranges from better process-
related know-how of the employees to an organizational and technological solution that
covers every aspect (the use of a BPM system is not a silver bullet for all business processes).
Lecture 15
BUSINESS MODELLING
COURSE SUMMARY
ASSESSMENTS RULES
Summary – concluding remarks
• Assessment rules
– Test form:
• 2-3 page form with 15-20 open and close questions
• No negative points
• No communication
– Test date:
• 25th of January 2023, 1115-1245
• 1st of February 2023, 1115-1245 (retake)
Thank you
GOOD LUCK

BM MPE Lecture

Uploaded by

Copyright:

Available Formats

BM MPE Lecture

Uploaded by

Document Information

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

BM MPE Lecture

Uploaded by

Copyright:

Available Formats

Roman Pietroń, D.Sc.

Course edition for Mechanical & Power Engineering Faculty

Teaching workload: 30h (total: 90h)

• Pietroń R., Business Modelling, e-material, Wrocław

Business as Business Model Business as an

Channels Cost Income

Org. Graphical Formal

• Automating: Automate a process;

• Basic contexts of „business model” concept are: basic assumptions

Preparations Scaling Process Process Process

Verification Prototyping Process Process

BM Lifecycle BPMM Lifecycle

• Models can be classified as:

BASIC METHODS OF MODELLING:

BASIC TOOLS OF MODELLING:

• Developing the business

What? How? Where? Who? When? Why?

Builder Node = Hardware/System

INPUT ACTIVITY OUTPUT

• Networks (e.g. Gantt Chart, PERT)

food crowding multiplier capital agriculture

Deterministic Cobb-Douglass production function

Stochastic Cobb-Douglass production function

General Linear Model (GLM) with stochastic variable

• Classification #1 of business processes:

• Classification #2 of business processes:

• Classification #3 of business processes:

Product Development Customer Strategic

• Process Stability and Capability

• Six-Sigma (6σ) Quality

Sigma level DPMO Probability

• Six-Sigma (6σ) Quality

2 Process result without defects 1138

3 Process effectiveness Stage2/Stage1 0,8870

4 Process error indicator 1-Stage3 0,113

5 Process defects critical attributes N 24

6 Defects indicator per critical attribute (DPO) Stage4/Stage5 0,0047

7 DPMO Stage6*10^6 4700

8 Sigma level Normal 4,1

Each point represents

Business Objects Workflow Systems

Process Modelling Business Reengineering

Process Definition Workflow Management

• Classes of BPM research in journals:

• BPM life cycle

Process enactment System configuration

• BPM is a continuous cycle comprising the

• There are different stakeholders involved with

Fill Update Tune

asset valid terms

requests Query & Analyze

INPUT ACTIVITY OUTPUT

Develop Assessment Reports

Existing Systems A0 Customized STARS Library

• Provides the overview: the most important functions,

• Architecture Rule No. 2

What? How? Where? Who? When? Why?

Builder Node = Hardware/System

Technology Technical infrastructure domain

Information Behaviour Structure