College of Computing and Informatics
Case Study
Deadline: Monday 05/06/2023 @ 23:59
[Total Mark is 14]
Student Details:
CRN:
Name:
Name:
Name:
ID:
ID:
ID:
Instructions:
• You must submit two separate copies (one Word file and one PDF file) using the Assignment Template on
Blackboard via the allocated folder. These files must not be in compressed format.
• It is your responsibility to check and make sure that you have uploaded both the correct files.
• Zero mark will be given if you try to bypass the SafeAssign (e.g. misspell words, remove spaces between
words, hide characters, use different character sets, convert text into image or languages other than English
or any kind of manipulation).
• Email submission will not be accepted.
• You are advised to make your work clear and well-presented. This includes filling your information on the cover
page.
• You must use this template, failing which will result in zero mark.
• You MUST show all your work, and text must not be converted into an image, unless specified otherwise by
the question.
• Late submission will result in ZERO mark.
• The work should be your own, copying from students or other resources will result in ZERO mark.
• Use Times New Roman font for all your answers.
Description and Instructions
Pg. 01
Description and Instructions
Case Study Objective:
This case study is an opportunity for you to practice your knowledge and to develop
skills of working in teams.
•
Total Marks = 14
Project Report
Presentation
10 marks
4 marks
•
Group Size = 3-4 Members.
•
One group member (group leader/coordinator) should submit all files: Project
Report and Presentation Slides on blackboard.
•
Marks will be given based on your submission and quality of the contents.
Project Report
•
Each Project Report will be evaluated according to the marking criteria mentioned
in each question section.
Presentation
•
Students (Group) need to present their projects (either F2F or Virtual) in week#11.
(Considered as last week before the final review)
•
Presentation schedule with date and allocated timing will be shared with the
students via Blackboard before the end of Week #10.
Description and Instructions
Pg. 02
SAMPLE CASE STUDY
▪ Introduction:
Gold pizza is a Pizza restaurant established in 2000. The pizza restaurant uses food
ingredients, including meat, vegetables, and seafood, which meet the set standards. It is
a small restaurant owned by two people. One of them was responsible for buying goods
and bringing them to the restaurant two times a day: every morning and late afternoon.
The other owner manages the restaurant activities and organizes shifts for employees.
Because the restaurant is open 24 hours, seven days a week, with three shifts, they
employ well-experienced employees on each shift. The restaurant has three chefs for
making the dough of pizza and sauce, three well-trained employees for preparing and
putting the ingredients in the pizza, and three well-trained employees for cooking the
pizza and controlling the oven heat. The owners work in this restaurant with other
employees to help them.
▪ Business process: (The order process )
The process starts by welcoming the customer and giving them the menu. The customer
looks into the menu and then places their order. The cashier writes down the order on a
separate paper for each customer, calculates the prices, and then asks the customer to
pay (3 minutes). After getting the payment, the cashier handed the paper of each order
to the second employee. The second employee then starts pizza preparation based on the
order (the restaurant has two bases of dough: the thin dough and the thick dough) (4
minutes). The next employee is responsible for filling the pizza with the ingredients
based on each customer’s order (2 minutes). The next employee takes the pizza, puts it
into the oven until it is ready, and then gets it back (3 minutes for thin dough base and
5 minutes for thick dough base). The last employee cuts the pizza and packages it, then
hands it to the customer (2 minutes).
▪ The current situation:
The restaurant starts to get a lot of orders that are over its capacity due to its reputation.
It usually gets around 25 orders from persons coming to their restaurant in each hour.
Description and Instructions
Pg. 03
Each order – on average – includes 4 Pizza of different bases and ingredients. However,
the restaurant lost a couple of its experienced employees responsible for preparing and
cooking pizzas.
▪ The Issues:
The Gold pizza restaurant was very successful and had many customers and significant
revenue. However, the restaurant starts to lose many of its loyal customers and receives
a considerable number of complaints. The managers started to investigate the complaints
they received. They also contacted their loyal customers to understand the different
issues more clearly. After this deep investigation, they categorized the issues into the
following categories:
o Some of the pizza’s bases and ingredients are unavailable in the early afternoon
or late night.
o The waiting time becomes unacceptable to customers.
o The quantity of ingredients is not always the same which affecting the taste of
the pizza.
o The thick dough base of pizza is sometimes undercooked.
o The customers sometimes get some of their pizza cold.
o The customers sometimes get the wrong order.
Note: the above mentioned case study is just an example;
students are supposed to find a separate case study for any
area of manufacturing, business, market, etc.
Question One
Pg. 04
Learning
Outcome(s):
CLO1: Explain
the
interdisciplinary
concepts,
theories, and
trends in ES and
their role in
supporting
business
operations.
Question One
4 Marks
A- Your first task is to select a case study (from the real world, using the
internet, or any resource). It can be related to enterprise systems, an
organization/store, or any relevant topic.
B- After selecting the case study, describe it in your own words using the
following points.
▪
Clear headline (introduction): It should give the most important
information that describes the case study.
▪
Business process: describe in detail the activity, how the business
process is done, and the main Input and Output. (If there are many
business processes, select one with issues)
▪
The current situation: It describes the current situation based on the
business process. By providing the main points, including the client’s
name/industry, the product/service used, and quick result stats.
▪
The Issues: State the problem/issues, consequences, and any
hesitations in the business process.
Marking criteria:
1- Selection of relevant case study and introduction.
[1 Marks]
2- Describing it using the business process, current situation, and issues
[3 Marks]
Question Two
Pg. 05
Learning
Outcome(s):
CLO4: Design ES
architectural
Question Two
3 Marks
A- Model (As-Is) process using BPMN 2.0 using any tool such as Visio. (1
mark)
models for
various business
processes.
B- Then analyze As-Is process from at least two perspectives. (2 mark)
For example, if quality and time perspectives are taken then mention at
least 1 issue related to quality and 1 issue related to time in the process
Marking criteria:
1- Model current (As-Is) process using BPMN 2.0 utilizing any tool
[1 Marks]
2- Analyze As-Is process from at lest two perspectives.
[2 Marks]
As-Is Process Model:
See Appendix 1 for As-Is process model example.
Question Three
Pg. 06
Learning
Outcome(s):
Question Three
3 Marks
A- Propose at least two ideas for improving process of your selected case
CLO3: Discuss
study from any perspectives: for example: (a) equipment perspective,
the issues and
(b) employees perspective, (c) IT & IS technologies perspective, etc.
challenges
associated with
B- Also explain how your suggestions will solve business process issues?
implementing ES
and their impacts
on corporate
Marking criteria:
enterprises.
1- Improvement suggestions from any perspectives.
[2 Marks]
2- The explanation of how suggestions will help to solve the issues.
[1 Marks]
Pg. 01
Appendix 1: As-Is
Appendix
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 1
Introduction
1.
2.
3.
4.
Contents
Saudi Vision 2030
Saudi Digital Library
Git and Github
Stackoverflow
• Demonstrate the Saudi Digital Library and searching for
knowledge
• Understand the Major Objective of Saudi Vision 2030
Weekly
Learning
Outcomes
• Saudi Vision 2030
Weekly
Learning
Outcomes
Saudi Vision 2030
• Under the leadership of the Custodian of the Two Holy Mosques, Vision
2030 was launched, a roadmap drawn up by His Royal Highness the Crown
Prince, to harness the strengths God bestowed upon us – our strategic
position, investment power and place at the center of Arab and Islamic
worlds. The full attention of the Kingdom, and our Leadership, is on
harnessing our potential to achieve our ambitions.
Reference: https://www.vision2030.gov.sa/
Saudi Vision 2030
• Vision 2030 Draws on The Nation’s Intrinsic Strengths
1. Saudi Arabia is the land of the Two Holy Mosques which positions the Kingdom at
the heart of the Arab and Islamic worlds
2. Saudi Arabia is using its investment power to create a more diverse and
sustainable economy
3. The Kingdom is using its strategic location to build its role as an integral driver of
international trade and to connect three continents: Africa, Asia and Europe
Reference: https://www.vision2030.gov.sa/
• Saudi Digital Library
Weekly
Learning
Outcomes
Saudi Digital Library
• Saudi Digital Library, is the largest academic gathering of information
sources in the Arab world, with more than (310،000) scientific reference,
covering all academic disciplines, and the continuous updating of the
content in this; thus achieving huge accumulation cognitive in the long run.
Library has contracted with more than 300 global publisher. The library
won the award for the Arab Federation for Libraries and Information
‘know’ for outstanding projects in the Arab world in 2010.
Reference: https://sdl.edu.sa/sdlportal/en/publishers.aspx
Saudi Digital Library
• Advantages:
• One central management, manages this huge content, and constantly updated.
• Common share for the benefit of, any University would benefit other universities
that are now available to the other, in any scientific field.
• Enhance the status of universities when evaluating, for Academic Accreditation, and
through sources rich, modern, and publish the best Global Publishers.
• Bridging the gap between Saudi universities, where emerging universities can get
the same service, you get major Saudi universities.
Reference: https://sdl.edu.sa/sdlportal/en/publishers.aspx
• Git and Github
Weekly
Learning
Outcomes
What is GIT?
• Git
• is a version control system for tracking changes in computer files and
coordinating work on those files among multiple people.
• It is primarily used for source code management in software development and
was initially created by Linus Torvalds for development of the Linux Kernel.
• Git is not Github.
• Git is the version control software
• Github is a git repository hosting service which offers all the source code
management provided in git.
• Github is where you upload your git repository.
Reference: https://medium.com/@lucasmaurer/git-gud-the-working-tree-staging-area-and-local-repo-a1f0f4822018
Version control
• Version control is:
• a system that records changes to a file or set of files over time so that you can
recall specific versions later.
• If you are a graphic or web designer and want to keep every version of an
image or layout (which you would most certainly want to), a Version Control
System (VCS) is a very wise thing to use.
• It allows you to revert selected files back to a previous state, revert the entire
project back to a previous state, compare changes over time, see who last
modified something that might be causing a problem, who introduced an issue
and when, and more.
• Using a VCS also generally means that if you lose files, you can easily recover.
Reference: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
What Is GitHub
• GitHub is
• a for-profit company that offers a cloud-based Git repository hosting
service.
• Essentially, it makes it a lot easier for individuals and teams to use Git for
version control and collaboration.
• GitHub’s interface is user-friendly enough so even novice coders
can take advantage of Git.
Reference: https://guides.github.com/activities/hello-world/
Create a Repository
Reference: https://guides.github.com/activities/hello-world/
Make and commit changes
Reference: https://guides.github.com/activities/hello-world/
• Stack overflow
Weekly
Learning
Outcomes
Stack overflow
• Stack Overflow is
• a question-and-answer website for professional and enthusiast programmers.
• It is the flagship site of the Stack Exchange Network, created in 2008 by Jeff Atwood
and Joel Spolsky.
• It features questions and answers on a wide range of topics in computer programming.
• Stack Overflow only accepts questions about programming that are tightly focused on a
specific problem.
• Questions of a broader nature–or those inviting answers that are inherently a matter of
opinion– are usually rejected by the site's users and marked as closed.
https://stackoverflow.com/
Reference: https://en.wikipedia.org/wiki/Stack_Overflow
Thank You
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 2
Enterprise Systems and Enterprise Resource Planning
Required Reading
1. Chapter 1 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Weekly Learning Outcomes
1. Introduce the concept of Enterprise Systems (ES) and
Enterprise Resource Planning (ERP)
2. Describe the importance of business processes in enabling
flexible and adaptable enterprise-wide cross-functional
integration.
Contents
1. Evolution of Enterprise Systems
2. Extended Enterprise Systems
3. Enterprise Resource Planning (ERP)
4. Enterprise Business Processes
• Evolution of Enterprise Systems
Evolution of Enterprise Systems
• Enterprise systems (ES) are an information system that integrates
business processes with the aim of:
1. creating value
2. reducing costs
• Achieved by making the right information available to the right
people at the right time
➢Result – Making good decisions in managing resources proactively and
productively.
• ES have evolved from simple materials requirement planning (MRP)
to ERP, extended enterprise systems (EES), and beyond.
Evolution of Enterprise Systems
Materials Requirement Planning (MRP)
• MRP is a heuristic based on three main inputs:
1. the Master Production Schedule, which specifies how many products are
going to be produced during a period of time;
2. the Bill of Materials, which describes how those products are going to be
built and what materials are going to be required;
3. the Inventory Record File, which reports how many products, components,
and materials are held in-house.
• MRP employs backward scheduling,
➢lead times are used to work backwards from a due date to an order release
date.
• While the primary objective of MRP was to compute material
requirements, the MRP system is also a useful scheduling tool.
Closed-Loop Materials Requirement Planning
• Real-time (closed loop) MRP systems replaced regenerative MRP systems in
response to:
1.
2.
Changing business needs
Improved computer technology
➢ Time-sharing replaced batch processing as the dominant computer processing mode.
• This closed the control loop with timely feedback for decision-making by
incorporating current data from the factory floor, warehouse, vendors,
transportation companies, and other internal and external sources
➢ Gives the MRP system the capability to provide current information for
better planning and control.
• The transformation of MRP into a planning and control tool by closing the loop,
planned and controlled various manufacturer resources that led to MRP II.
Manufacturing Requirement Planning II
• The MRP system evolved from a “material” requirements planning system
into a planning and control system for resources in “manufacturing”
operations.
• MRP II systems became more widespread and sophisticated, particularly
when used in manufacturing to support and complement computerintegrated manufacturing.
• Databases started replacing traditional file systems, allowing for better
systems integration and greater query capabilities to support decisionmakers.
• Telecommunications network became an integral part of these systems in
order to support communication between distributed systems
components.
Manufacturing Requirement Planning II
• MRP II was developed based on MRP principles, but incorporated some
important operational restrictions such as available capacity, maintenance
turnaround time, and financial considerations.
• MRP II introduced simulation options to enable the exploration and
evaluation of different scenarios.
• MRP II is defined as business planning, sales and operations planning,
production scheduling, MRP, capacity requirements planning, and the
execution support systems for capacity and material.
• MRP II integrated financial considerations, improved management control
and performance of operations and made different manufacturing
approaches comparable.
Enterprise Resource Planning (ERP)
• New advances in information technology (IT), such as local area
networks, personal computers, and object-orientated programming
allowed some of MRPs deterministic assumptions to be relaxed.
• Early ERP systems typically ran on mainframes like MRP and MRP II,
but many migrated to client/server systems where networks were
central and distributed databases were more common.
• Extended Enterprise Systems (EES)
Extended Enterprise Systems
• Businesses are looking beyond the enterprise.
• Enterprises look for ways to support and improve relationships and
interactions with customers, suppliers, partners, and other
stakeholders.
• While integration of internal functions is still important and, in many
enterprises, still has not been achieved to a great extent, external
integration is now receiving much attention.
Extended Enterprise Systems Framework
The conceptual framework of EES consists of four distinct layers:
• Foundation layer - consists of the core components of EES, which shape
the underlying architecture and also provide a platform for the EES systems
• Process layer - the central component of EES, which is Web-based, open,
and componentized and may be implemented as a set of distributed Web
services.
• Analytical layer - consists of the corporate components that extend and
enhance the central ERP functions by providing decision support to manage
relations and corporate issues.
• Electronic business layer - the portal of the EES systems and this layer
consists of a set of collaborative components.
Extended Functionality
• The capability of Web services to allow businesses to share data,
applications, and processes across the Internet may result in ES of the future
relying heavily on the idea of service-oriented architecture, within which
Web services are created and stored, providing the building blocks for
programs and systems.
• The use of “best in breed” Web service-based solutions might be more
palatable to businesses, since it might be easier and less risky to plug-in a
new Web service-based solution than replace or add-on a new product
module.
• While the “one source” alternative seems most popular at present, the “best
in breed” approach will be good if greater interoperability/integration
among vendor products is achieved.
• There is a need for greater “out of the box” interoperability, thus a need for
standards.
Traditional vs. ES Software Implementations
The traditional software implementation involving the development of
applications was characterized by the following:
• Requirement-driven functional decomposition
• Late risk resolution
• Late error detection
• Use of different languages or artifacts at different phases of the
project
• Large proportion of scrap and rework
• Adversarial stakeholder relationships with non-IT users
• Priority of techniques over tools
• Greater emphasis on current, correct, complete, and consistent
documentation
• Greater emphasis on testing and reviews
Traditional vs. ES Software Implementations
ES software implementations are characterized by the following:
• Primacy of the architecture, process-oriented configurability
• Primacy and direct participation of the business user
• Early risk resolution
• Early error and gap detection
• Iterative life-cycle process, negligible proportion of scrap and rework
• Changeable and configurable functionality
• Participatory and cohesive stakeholder relationships with non-IT users
• Priority of functionality over tools followed by techniques
• Quality of the functional variability and flexibility of the available
functionality
Traditional vs. ES Software Implementations
Off-the-shelf packages and especially enterprise-wide solutions such as
ES were considered to be the best approach due to:
• ES ensure better validation of user requirements directly by the user.
• ES ensure consistent quality of delivered functionality.
• ES provide a cohesive and integrated information system architecture.
• ES ensure a fair degree of standardization.
• ES provide a consistent and accurate documentation of the system.
• ES provide outstanding quality and productivity in the development
and maintenance of the system
• Enterprise Resource Planning (ERP)
The Concept of Enterprise Resource Planning
• The main focus of ERP has been to integrate and synchronize the
isolated functions into streamlined business processes.
• ERP not only coordinates multiple divisions but also requires
companies to enter data only once for the information to be
distributed to all of the integrated business processes.
• ERP systems consist of several integrated suites of software modules,
which share common data and provide connectivity.
• The information about the processes in the company is represented
consistently and is up to date in all business divisions at all times.
Enterprise Resource Planning System
ERP could be defined reasonably as follows:
“An ERP software applications package is a suit of pre-engineered,
ready-to-implement integrated application modules catering to all of
the business functions of an enterprise and which possesses the
flexibility for configuring and customizing dynamically the delivered
functionality of the package to suit the specific requirements of the
enterprise. ERP enables an enterprise to operate as an integrated
enterprise wide, process-oriented, information-driven real-time
enterprise.”
Enterprise Resource Planning System
• At the heart of an ERP system, resides a CASE-like repository that
stores all details of these predeveloped applications.
• These details include every single data item, data table, and software
program that is used by the complete system.
• The major development of the ERP systems over the information
engineering approaches was in terms of providing predefined,
already-built-in comprehensive functionality of the application
systems.
• The success of ERP packages is based on the principle of reusability.
Enterprise Resource Planning System
• Information and
material flows
in a functional
business model
Enterprise Resource Planning System
• Information
and material flows
in a business process
model.
Characteristics of Enterprise Resource Planning
The distinguishing characteristics of ERP are as follows:
1. ERP transforms an enterprise into an information-driven enterprise.
➢ ERP began treating information as a resource for the operational requirements
of the enterprise.
➢ Unlike the traditional resources, information resource as made available by ERP
systems can be reused and shared multiply without dissipation or degradation.
➢The impressive productivity gains resulting from the ERP systems are related to
using information as an inexhaustible resource.
Characteristics of Enterprise Resource Planning
2. ERP fundamentally perceives an enterprise as a global enterprise.
➢ ERP systems cater to corporate-wide requirements even if an enterprise is
involved in disparate businesses such as discrete industries; process
industries; and services industries.
➢ ERP enables the management to plan, operate, and manage such
conglomerates without any impediments of mismatching of systems for
different divisions.
Characteristics of Enterprise Resource Planning
3. ERP reflects and mimics the integrated nature of an enterprise.
➢ ERP offerings like SAP provides a powerful medium for supporting,
reconciling, and optimizing the conflicting goals of different functions of the
enterprises.
4. ERP fundamentally models a process-oriented enterprise.
➢ Process modeling permits the true comprehension of the characteristic
structure and dynamics of the business.
➢ Business processes are the most important portions of the reality that had
been ignored by the traditional IS.
Characteristics of Enterprise Resource Planning
5. ERP enables the real-time enterprise.
➢ In non-ERP enterprises, closely related processes are typically done
sequentially because they are usually handled by the same set of personnel,
who may be obviously constrained to address them only in a sequence.
➢ ERP systems like SAP can perform all these processes concurrently because of
ready availability of all of the relevant, complete, and consistent information
at the same time.
Characteristics of Enterprise Resource Planning
6. ERP Elevates Information Technology Strategy as a Part of the Business Strategy
➢ This arises primarily from the fact that information itself has become a vital
resource for an enterprise in the same league as the traditional resources like
manpower, materials, money, and time.
7. ERP Represents a Major Advance on the Earlier Manufacturing Performance
Improvement Approaches
➢ ERP systems provide the basic platform for devising techniques and tools for
better implementations of the earlier approaches
Characteristics of Enterprise Resource Planning
8. Represents the Departmental Store Model of Implementing Computerized
Systems
➢ An ERP is the analog of the great departmental store of functionalities or
processes required within an enterprise.
9. ERP is a Mass-User-Oriented Application Environment
➢ ERP brings computerization to desktops and, in this sense, is an end-useroriented environment.
➢ In traditional systems, users access the system directly only in well-defined
pockets within the enterprise.
➢ In ERP, end users are truly the personnel actually involved with the
operations of the business.
Advantages of Enterprise Resource Planning
• Reconciliation and optimization of the conflicting goals of different divisions or
departments.
• The ability to know and implement global best practices.
• Alteration of the function-oriented organization toward a more team-based,
cross-functional, process-oriented enterprise, thus leading to a more flexible,
flatter, and tightly integrated enterprise.
• ERP provides a responsive medium for undertaking all variants on process
improvement programs and methodologies including PI, process improvement,
and business process.
• ERP also provides a responsive medium for quality improvement and
standardization efforts including quality control, quality assurance, and TQM.
Advantages of Enterprise Resource Planning
• ERP is a fertile ground for implementing activity-based management efforts, be it
for budgeting, costing, efficiency, or quality.
• ERP could assist in the implementation of, for instance, the balanced scorecard
within the enterprise.
• ERP systems, because they customarily implement best-of-class practices, provide
the best means for benchmarking the organization’s competitiveness.
• An ERP system enables an enterprise to scale up its level of operations drastically
or even enter into different businesses altogether without any disruption or
performance degradation.
• An ERP system ensures real-time creation of data directly during the actual
physical transaction or processes by the persons who are actually responsible for
it.
Advantages of Enterprise Resource Planning
• An ERP system pushes the latest data and status to the actual operational-level
persons for better and faster decisions at least on routine issues and empowers
and gives ownership to the operational personnel at the level of actual work.
• An ERP system prompts the integration of data of the enterprise into a single
comprehensive database.
• An ERP system enables online availability of correct and up-to-date data.
• ERP provides the most current, correct, consistent, and complete operational
data that could be populated into the enterprise data warehouse for analysis and
reporting.
• ERP greatly reduces the cost of maintaining systems.
Disadvantages of Enterprise Resource Planning
• ERP reinforces the silo-oriented functioning of the traditional
functional organizations.
• ERP enhances team-based operations in the organization, but, often,
these teams remain confined to the traditional functional silos in that
they do not cross the boundaries of the functional departments.
• ERP implementations render the personnel enabled for system-based
operations but do not necessarily do so for collaborative operations
especially across traditional departmental boundaries.
Enterprise Business Processes
• Businesses take inputs (resources) in the form of material, people, and
equipment and transform these inputs into goods and services for
customers.
• Managing these inputs and the business processes effectively requires
accurate and up-to-date information.
• In the process-oriented model, the flow of information and management
activity is horizontal across functions, in line with the flow of materials and
products.
• This horizontal flow promotes flexibility and rapid decision-making and
stimulates managers to see the importance of managing business
processes.
• Now, information flows between the operating levels without top
management’s involvement
Main Reference
1. Chapter 1 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Thank You
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 3
Characteristics of Business Processes
Required Reading
1. Chapter 2 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Weekly Learning Outcomes
1. Describes the framework for measuring business process
performance in terms of the dimensions of timeliness, cost,
and quality.
Contents
1. Business Process
2. Process Performance
3. Process Cycle Time
4. Process Costs
5. Process Quality
6. Measuring Process Performance
• Business Process
Business Process
• A business process is a set of logically related tasks performed to achieve a
well-defined business outcome.
• A business process defines:
➢ The results to be achieved,
➢ The context of the activities,
➢ The relationships between the activities,
➢ The interactions with other processes and resources.
• A business process may produce events for input to other applications or
processes.
• A business process is a coordinated and logically sequenced set of work
activities and associated resources that produce something of value to a
customer.
Business Process
Business
Steps
Business
Goals
Business
Process
Stakeholders
Business Process
A business process has the following behaviors:
• It may contain defined conditions triggering its initiation in each new
instance and defined outputs at its completion.
• It may involve formal or relatively informal interactions between
participants.
• It has a duration that may vary widely.
• It may contain a series of automated activities and/or manual activities.
Business Process (cont.)
A business process has the following behaviors:
• It exhibits a very dynamic nature.
• It is widely distributed and customized across boundaries within and
between enterprises.
• It is usually long-running—a single instance of a process may run for
months or even years.
Process Performance
Process-oriented enterprises consider any enterprise as a process that converts
input into output characterized by:
1. Inputs and outputs:
• Inputs are any tangible or intangible items that flow into the process from the
environment.
• Outputs are any tangible or intangible items that flow from the process back
into the environment.
2. Flow units: A flow unit or job is an item that flows throughout the process.
3. A network of activities and buffers:
• An activity is the simplest form of transformation; it is actually a miniprocess
in and of itself.
• A buffer stores flow units that have finished one activity but are waiting for
the next activity to start.
Process Performance
4. Resources are tangible assets that are usually divided into two
categories: capital and labor.
5. Information structure describes the information that is needed and
available in order to perform activities or to make managerial decisions.
➢ The process flow is a dynamic process that starts when an input
enters a process and continues processing throughout different kinds
of process activities and ends when it leaves the process as its
output.
Process Performance
Three key measures of the process flow:
1. Cycle time or flow time, which is the time it takes to complete an
individual flow unit or job from start to finish.
➢ Processing time
➢ Inspection time
➢ Transporting time
➢ Storage time
➢ Waiting time
2. Flow rate or throughput, which is the number of jobs per unit of
time.
Process Performance
3. Inventory, which is the total number of flow units present within the
process boundaries.
• The inventory within the framework of the process depends on the difference
between the inflow rate and outflow rate.
R(t) means the flow rate at a certain point of time t.
Ri(t) means inflow; this is the flow rate of flow units that enter the process
through its entry points.
Ro(t) means outflow; this is the flow rate of flow units that leave the process
through its exit points.
Process Performance
4. Little’s Law For a stable process: defines the fundamental
relationship between average inventory, average flow rate, and
average cycle time in a stable process.
• Average flow rate or throughput is the average number of flow units that
flow through the process per unit of time.
• A stable process is one in which the average inflow rate is the same as the
average outflow rate across an extended period of time; that is R = Ri = Ro
• The average cycle time is the average across all flow units that exit the
process during a specific period of time.
• Average inventory is the number of flow units within the process boundaries
at any point in time.
➢ The average inventory equals the average flow rate times the average cycle time;
that is, I = R*T.
➢ Example.
Process Cycle Time
1. Theoretical cycle time
• The theoretical cycle time of a process is the minimum amount of time
required for processing a typical flow unit without any waiting.
• It is the sum of the times of those activities that the flow unit passes through
and where specific kinds of tasks are undertaken to process it.
• Activity time is the time required by a typical flow unit to complete the
activity once.
2. Critical path: A process flow is presented using a diagrammatic
technique like a flowchart. The longest path in the process
flowchart is the critical path.
• All activities that constitute the critical path of the process flowchart are
called critical activities.
Process Cycle Time
3. The critical path method is based on calculating a variable called the
slack time of an activity.
• The extent to which an activity could be delayed without affecting process flow
time.
• A critical activity is an activity whose slack time is equal to 0.
➢ The critical path consists of all those activities for which the slack time is
equal to 0.
• To determine the critical path, two schedules have to be calculated:
a. Forward schedule - calculates the earliest possible start time (ES) and the
earliest possible finish time (EF) of each activity within the process.
1st activity, ES = 1, where 1 means 1 time unit.
Other activities, ES = 1 + max(EF) of immediate predecessor activities.
EF = ES + d + 1, where d is duration time of the activity
Process Cycle Time
b. Backward schedule - calculates the latest possible start time (LS) and the latest
possible finish time (LF) for each activity of the process.
1st activity, LF = EF
Other activities, LF = min(LS) of immediate successor activities −1
LS = LF − d + 1, where d is the duration time of the activity.
4. Slack time (S): The slack time of an activity is the amount of time that could be
spent in addition to the duration time of the activity, without causing a delay to the
start times of immediate successor activities.
S = LF − EF = LS − ES
5. Cycle-time efficiency: the ratio between the theoretical cycle time and the
average cycle time.
Cycle-time efficiency = theoretical cycle time/average cycle time
Computing Cycle Time
1. The sum of the theoretical and waiting times.
Cycle time = theoretical cycle time + waiting time
Average cycle time of a process can be obtained by:
• Treating waiting in each buffer as an additional (passive) activity with an
activity time equal to the amount of time in that buffer.
• Adding waiting times to the theoretical cycle time of the appropriate path.
• Obtaining the average cycle time of the process by finding the path whose
overall length (activity plus waiting) is the longest.
Computing Cycle Time
2. Using value-adding and non-value-adding activities.
• Value-adding activities are those activities that increase the economic value
of a flow unit because the customer values them.
• Non-value-adding activities are activities that, while required by the firm’s
process, do not directly increase the value of a flow unit.
Cycle time = value-adding cycle time − non-value-adding cycle time
3. Computing the cycle time using Little’s law.
• Computing the average cycle time of a process by finding the longest cycle
time of the process flowchart—that is, by finding the critical path of the
process.
Process Flow Aspects
1. Rework
• A process flowchart may contain one or more segments of a number of sequential
activities whose execution needs to be repeated several times, depending on a
decision activity, where the value of a certain condition is defined.
• This is known as a rework or execution loop; each repetition of a rework loop is called a
visit.
2. Multiple Paths
• There are a number of cases in a process flowchart where, after a decision activity, the
process flow splits into two or more paths.
• This formula can be used to compute the average cycle time for a process flow that
splits into multiple paths after a decision activity:
T = p1*T1 + p2*T2 + … + pm*Tm
pi is the probability of following the flow of path i
Ti is the sum of times of activities within path i
m is the number of paths
Process Flow Aspects
3. Parallel Paths
• The process flowchart may contain one or more segments that are
constructed from parallel activities.
• The cycle time of the part of the process with parallel paths is represented by
the maximum sum of times of activities in the parallel paths.
T = max( T1, T2, … , Tm)
Ti is the sum of times of activities within path i
m is the number of paths
Process Capacity
• Considering that the average flow rate or throughput is defined as the
average number of flow units or jobs that flow through the process
per unit of time, the process capacity is the maximum sustainable
flow rate of a process.
• Resources - the capacity of a process depends on the resources that
are used in the process. Performing any activity requires one or more
resources, and every resource may be involved in performing one or
more activities.
• Resource pool - a collection of interchangeable resources that can
perform an identical set of activities.
• Resource-pooling - associating different resource pools into a joint
resource pool in order to carry out a set of activities within a process.
Process Capacity
• Theoretical Capacity - The theoretical process capacity is the
maximum sustainable throughput rate for the process operating
without interruption. The actual process capacity will always be less
than the theoretical capacity due to:
• Resource breakdowns: A machine may become unavailable due to a
breakdown or a human resource may be absent.
• Preventive maintenance: Machines require regular maintenance to operate at
maximum efficiency; this scheduled preventive maintenance makes the
resource unavailable for processing.
• Process flow inefficiencies: A resource may become idle due to the
unavailability of work.
• Demand variation: As described earlier, the mismatch between demand and
capacity can cause underutilization.
Process Capacity
• The flow unit on its way through different activities is processed by a
number of resource pools with predetermined capacities;
• The pool with the lowest capacity is termed as the resource bottleneck of
the process.
• Since the capacity of a process cannot be better than the process’s
bottleneck resource pool, this effectively makes it the defining capacity of
the whole process.
• Assuming that we have a resource pool p with cp resource units,
Rp = cp / Tp
Rp is the theoretical capacity of the resource pool
cp is the number of resource units in the pool p
Tp is the unit load of the resource pool
Process Capacity
• If the resource units in a certain resource pool do not have the same
theoretical capacity,
➢ the theoretical capacity of the resource pool is computed as the sum of all of the
theoretical capacities of its constituting resource units, provided the following
conditions are true:
1.
2.
The flow units are performed by resource units sequentially one by one.
The resource units are available the same quantity of time.
• Load-batching and scheduled availability are important factors that have a
real effect on the theoretical capacity of the process.
• Load batching as the ability of a resource unit to process a number of flow units
simultaneously
• Scheduled availability as the quantity of time in which a resource unit is scheduled to
perform a determined work
• Thus, the theoretical capacity of resource pool p with cp resources is,
Rp = cp / Tp * load batch * scheduled availability
Process Capacity
• Capacity Utilization - measures the degree to which resources are
effectively utilized by a process.
• It indicates the extent to which resources, which represent invested capital,
are utilized to generate outputs.
• For each resource pool, capacity utilization of the process is defined as the
capacity utilization of the bottleneck resource pool.
ρp = R / Rp
R is the throughput
Rp is the theoretical capacity of a resource pool
Process Capacity
The theoretical capacity can be improved by:
1. Decreasing the unit load on the bottleneck resource pool (i.e., work
faster, work smarter)
2. Increasing the load batch of resources in the bottleneck resource
pool (i.e., increase the scale of the resource)
3. Increasing the number of units in the bottleneck resource pool (i.e.,
increase the scale of the process)
4. Increasing the scheduled availability of the bottleneck resource
pool (e.g., work longer)
Process Costs
A cost component is any activity for which a separate cost measurement is
desired (e.g. the materials consumed, inventory, labor, or overhead of the
process).
1. Direct costs - costs that can be directly and exclusively attributed to a
particular cost object. These are traced to the work unit and assigned
2. Indirect costs - costs that cannot be directly and exclusively attributed to a
particular cost object. These cannot be traced to the work unit because they
are common to many work units.
Other ways to classify the process cost components are:
1. Fixed costs, which remain constant for all levels of output.
2. Variable costs, which are the costs per work unit and therefore vary with the
amount of sales.
Process Quality
Quality can be defined from the two different perspectives:
1. Customer’s perspective - the degree to which a product or service satisfies the
needs and expectations of the customer.
2. Enterprise’s perspective - the degree to which a product or service conforms to
the specifications designed for the product or service.
• Quality-by-Design – A product or service cannot meet customer needs unless
the enterprise perceives those customer needs and designs a product or service
to fulfil those needs and designs a product or service to fulfil those needs.
Process quality
To institute quality processes, an enterprise performs three main
functions:
1. Design quality products and services by understanding customer needs and
translating them into product and service specifications.
a. The quality functional deployment methodology and tools translate the customer
needs into the attributes of a product or service. The primary tool of quality
functional deployment is:
➢ The house of quality, a matrix that denotes the strength of the association between a
product or service attribute and customer expectations using a range from 0 to 9, with 9
indicating a very strong association.
➢ This matrix indicates the degree of correlation between product attributes as either
weak, medium, or strong.
Process Quality
b. Poka-yoke: To design quality into the product, the process that produces the product
should be failproof.
➢ In manufacturing, parts may be designed so that they can only be assembled in the correct
way, thus removing the need for the worker to think about how the parts go together and
possibly making an error.
➢ In service industries, checklists are used to remind the person to do all of the procedures for
every customer.
• Poka-yoke designs the process so as to eliminate the possibility of quality problems
before they can happen.
c. Taguchi method: Any deviation from the target is undesirable. Normally, any value that
fell within the lower and upper specifications was considered good.
➢ The quadratic loss function says that any deviation from the target value results in a loss.
Process Quality
2. Deliver quality products and services by having processes that produce no
defects and demonstrate little variability.
• The underlying principle of statistical quality control is that all processes
exhibit variation in their output.
• Some of the variation is called common cause variation and is due to the
inherent characteristics of the process.
• Other variation is the result of special causes that can be attributed to a
specific problem.
• Statistical process control uses control charts to monitor processes.
• The design of a quality process involves instituting the correct feedback loops
so as to constantly monitor and control the process.
• The usage of control charts helps to maintain process variability within a small
range of values within which the variability is explained only by common
cause variation.
Process Quality
3. Improve the quality of their processes by establishing continuous process
improvement programs (e.g. DMAIC, Six Sigma) that run parallel to the core
business processes.
The analysis teams need to identify improvement opportunities to:
• Eliminate waiting time (a waste)
• Eliminate wasted movement or effort
• Minimize inventory
• Eliminate repair and rework
• Minimize material movement 40 Enterprise Process Management Systems
• Minimize inspections
• Reduce the variation of inputs, process, and outputs
• Reduce cycle time
• Improve machine reliability
• Improve flexibility of resources
Measuring Process Performance
A process performance measurement
system focuses on an individual
business process, rather than on the
entire company or an organizational
unit.
Concepts for Performing Measurement
1. Process performance measurement based on indicators, measures,
and figures.
• Two performance indicators can be identified: time (as an input factor) and
service quantity (as an output factor).
• Performance measures represent the operationalization of each identified
performance indicator.
• Performance figures enable the summarization and representation of large
amounts of data in a condensed and precise manner.
Concepts for Performing Measurement
2. Measurements to determine process performance
• Performance figures are highly dynamic. The selection of strategically
important performance indicators is related to the notion of “critical success
factors”.
• Quality indicators describe the degree to which the actual product attributes
and properties conform to the underlying product specifications.
• Time indicators are considered to be an indicator of competitiveness and
process performance.
• Flexibility indicators describe the degree to which a production or service
process can be modified, including the timeline and costs associated with the
restructuring of a production or service process.
Frameworks for Measuring Process Performance
• The performance pyramid framework stresses a hierarchical view of performance.
It considers the relationship between:
• Strategic performance
(e.g., fulfilling the vision)
• Process performance
(e.g., quality, cycle time)
• The layer connecting the two
hierarchical levels depicts those
performance indicators that impact
both levels (e.g., customer
satisfaction, flexibility, and productivity).
Frameworks for Measuring Process Performance
This framework constructs a process-oriented performance measurement system
that highlights the distinction between input, throughput, and output that is
considered for determining performance indicators according to this classification.
Main Reference
1. Chapter 2 (Enterprise Process Management Systems:
Engineering Process-Centric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Thank You
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 5
Enterprise Architecture (EA)
Required Reading
1. Chapter 4 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Weekly Learning Outcomes
1. Explain enterprise architecture as a well-defined practice for
conducting enterprise analysis, design, planning, and implementation,
using a holistic approach at all times, for the successful development
and execution of enterprise strategy.
2. Describe the viewpoints, views, and perspectives that enable an
enterprise architecture.
Contents
1. Architecture
2. Viewpoints and Views
3. Change, Availability, and Scalability Perspectives
4. Enterprise Architecture Frameworks
Architecture
• An EA provides a high-level design of the entire enterprise that will
guide all other enterprise projects.
• An architecture represents significant, broad design decisions for the
enterprise, from which all other design decisions should be
consistent.
• The Software Engineering Institute (SEI) defines architecture as:
“The architecture of a software-intensive system is the structure or
structures of the system, which comprise software elements, the
externally visible properties of those elements, and the
relationships among them”.
Enterprise Architecture
EAs major goals:
1. For the EA, its units, policies, processes, strategies, and
technological infrastructure (e.g., IT systems) to successfully
support all stakeholders in achieving short and long-term business
goals and objectives of the enterprise.
2. For the EA to foster an alignment of the technological systems
developed by and used by an enterprise with its business goals and
strategic direction
3. For the EA to help an enterprise to learn, grow, innovate, and
respond to market demands and changing basic conditions
4. For the EA foster and maintain the learning capabilities of
enterprises so that they may be sustainable
Architectural Element
• An architectural element is a fundamental piece from which a system
can be considered to be constructed.
• An architectural element possesses several key attributes:
• A clearly defined set of responsibilities
• A clearly defined boundary
• A set of clearly defined interfaces, which define the services that the element
provides to the other architectural elements
Systems Structures
System structures are of two kinds:
1. The static structures of a software system define its internal designtime elements and their arrangement.
• Internal design-time software elements might be modules, object-oriented
classes or packages.
• Internal data elements include classes, relational database entities/tables,
and data files.
• Internal hardware elements include computers or their constituent parts such
as disk or central processing unit and networking elements such as cables.
2. The dynamic structures of a software system define its runtime
elements and their interactions.
• They show how the system actually works, what happens at runtime, and
what the system does in response to external (or internal) stimulus.
System Structures
External properties manifest in two forms:
1. The externally visible behavior of a software system defines the
functional interactions between the system and its environment.
• The externally visible behavior of a system (i.e., what it does) is determined
by the combined functional behavior of its internal elements.
2. A quality property is an externally visible, nonfunctional property of
a system such as performance, security, or scalability.
• The quality properties of a system such as performance, scalability, and
resilience (how it does it) arise from the quality properties of its internal
elements.
Quality Attributes
1. Implementation attributes (not observable at runtime); include:
a. Interoperability: Universal accessibility and the ability to exchange data
among internal components and with the outside world.
b. Maintainability and extensibility: The ability to modify the system and
conveniently extend it.
c. Testability: The degree to which the system facilitates the establishment of
test cases.
d. Portability: The system’s level of independence on software and hardware
platforms. Systems developed using high-level programming languages
usually have good portability (e.g. Java)
e. Scalability: A system’s ability to adapt to an increase in user requests.
Scalability disfavors bottlenecks in system design.
f.
Flexibility: The ease of system modification to cater to different environments or
problems for which the system was not originally designed.
Quality Attributes
2. Runtime attributes (observable at runtime); include:
a. Availability: A system’s capability to be available 24/7.
b. Security: A system’s ability to cope with malicious attacks from outside or
inside the system.
c. Performance: Increasing a system’s efficiency with regard to response time,
throughput, and resource utilization, which are attributes that are usually in
conflict with each other.
d. Usability: The level of human satisfaction derived from using the system.
e. Reliability: The failure frequency, the accuracy of output results, the
meantime-to-failure, the ability to recover from failure, and the failure
predictability
f. Maintainability (extensibility, adaptability, serviceability, testability,
compatibility, and configurability); the ease of software system change.
Quality Attributes
Business attributes, include:
a. Time to market: The time it takes from requirements analysis to the
date a product is released.
b. Cost: The expense of building, maintaining, and operating the
system.
c. Lifetime: The period of time that the product is “alive” before
retirement.
Attribute Tradeoffs
1. Tradeoff between space and time: For example, to increase the time
efficiency of a hash table means a decrease in its space efficiency.
2. Tradeoff between reliability and performance: For instance, Java
programs are well protected against buffer overflow due to security
measures such as boundary checks on arrays. Such reliability features
come at the cost of time efficiency, as compared with the simpler and
faster C language that provides the “dangerous,” yet efficient, pointers.
3. Tradeoff between scalability and performance: For example, one typical
approach to increase the scalability of a service is to replicate servers. To
ensure consistency of all servers, performance of the whole service is
compromised.
Candidate Architecture
• A candidate architecture for a system is a particular arrangement of
static and dynamic structures that have the potential to exhibit the
system’s required externally visible behaviors and quality properties.
• An architecture style (also known as an “architecture pattern”)
abstracts the common properties of a family of similar designs.
• An architecture style contains a set of rules, constraints, and patterns
of how to structure a system into a set of elements and connectors.
• An architecture style is a viewpoint abstraction for a software
structure that is domain-independent.
• A system can adopt heterogeneous architectures—that is, more than
one architecture style can coexist in the same design.
Architecture Style
Key components of an architecture style:
• Elements that perform functions required by a system
• Connectors that enable communication, coordination, and cooperation among
elements
• Constraints that define how elements can be integrated to form the system
• Attributes that describe the advantages and disadvantages of the chosen
structure
For example:
• In the data-centric style, the data store plays a central role and is accessed
frequently by other elements that modify data.
• In the dataflow style, input data are transformed by a series of computational
or manipulative elements.
Architecture Style
Multitier architecture is commonly used for distributed systems. It
usually consists of three element types, as follows:
1. The client element is responsible for graphical user interface presentation,
accepting user requests, and rendering results.
2. The middleware element gets the requests from the client element,
processes the requests based on the business logic, and sends a data
request to the backend tier.
3. The data store server element manages data querying and updating.
All three types of elements are connected via a network (e.g., the
Internet).
Stakeholder
• A stakeholder in a architecture is a person, group, or entity with an
interest in or concerns about the realization of the architecture.
• A concern about an architecture is a requirement, an objective, an
intention, or an aspiration a stakeholder has for that architecture.
• A good architecture is one that successfully meets the objectives,
goals, and needs of its stakeholders.
• Stakeholders (explicitly or implicitly) drive the whole shape and
direction of the architecture, which is developed solely for their
benefit and to serve their needs.
• Stakeholders ultimately make or direct the fundamental decisions
about scope, functionality, operational characteristics, and structure
of the eventual product or system.
Viewpoints and Views
• A view is a representation of structural aspects of an architecture that
illustrates how the architecture addresses concerns held by stakeholders.
• An architectural view is a way to portray those aspects of the architecture
that are relevant to the concerns with reference to this view.
• A viewpoint is a collection of patterns, templates, and conventions for
constructing one type of view.
• A viewpoint defines the stakeholders whose concerns are reflected in the
viewpoint and the guidelines, principles, and template models for
constructing its views.
• Viewpoints make available a library of templates and patterns that can be
used to guide the creation of an architectural view that can be inserted into
an architectural description.
Viewpoint Catalog
• Information, describes the way that the architecture stores, manipulates,
manages, and distributes information.
• Functional, describes the system’s functional elements, their
responsibilities, interfaces, and primary interactions.
• Concurrency, describes the concurrency structure of the system and maps
functional elements to concurrency units to clearly identify the parts of the
system that can execute concurrently and how this performance is
coordinated and controlled.
• Development, describes the architecture that supports the software
development process.
• Deployment, describes the environment into which the system will be
deployed, including capturing the dependencies the system has on its
runtime environment.
• Operations, describes how the system will be operated, administered, and
supported when it is running in its production environment.
Viewpoint Benefits
• Management of complexity
• Communication with stakeholder groups
• Separation of concerns
• Improved developer focus considers the idea that the architectural
description is the foundation of the system design
Perspectives
• An architectural perspective is a collection of activities, tactics, and
guidelines that are used to ensure that a system exhibits a particular
set of related quality properties that require consideration across a
number of the system’s architectural views.
• Most important perspectives for large information systems include:
• Performance and Scalability
• Availability and Resilience
• Security
• Evolution
Perspectives Advantages
1. A perspective is a useful store of knowledge, helping one to quickly
review their architectural models for a particular quality property
without having to absorb a large quantity of highly detailed
material.
2. A perspective acts as an effective guide when one is working in an
area that is new to them/when they are unfamiliar with its typical
concerns, problems, and solutions.
3. A perspective is a useful memory aid when one is working in an
area that they are more familiar with, to make sure that they don’t
forget anything important.
Benefits of Applying Perspectives to a View
• Provides common conventions, measurements, or even a notation or
language that can be used to describe the system’s qualities.
• Defines concerns that guide architectural decision-making to help
ensure that the resulting architecture will exhibit the quality
properties considered by the perspective.
• Describes how one can validate the architecture to demonstrate that
it meets its requirements across each of the views.
• May offer recognized solutions to common problems, thus helping to
share knowledge between architects.
• Helps working in a systematic way to ensure that the relevant
concerns are addressed by the system.
Perspectives Catalog
Perspectives Catalog
Perspectives are defined with details like:
• Applicability: explains which of your views are most likely to be
affected by applying the perspective.
• Concerns: defines the quality properties that the perspective
addresses.
• Activities: identifies the important quality properties, analyzing the
views against these properties, and making architectural design
decisions that modify and improve the views.
• Architectural tactics: an established and proven approach one can
use to help achieve a particular quality property.
• Problems and pitfalls: explains the most common things that can go
wrong and gives guidance on how to recognize and avoid them.
Perspectives Catalog
The Change Perspective
• Desired quality: The ability of the system to be flexible in the face of the
inevitable change experienced after deployment.
• Applicability: More important for longer-lived and widely used systems.
• Concerns: Magnitude of change, dimensions of change, likelihood of
change, timescale for change, and when to pay for change.
• Activities: Characterize the change needs, assess the current ease of
change, and consider the change tradeoffs.
• Architectural tactics: Contain change, create flexible interfaces, apply
change-oriented architectural styles, and build variation points into the
software.
• Problems and pitfalls: Prioritization of the wrong dimensions, changes that
never happen, and impacts of change on critical quality properties.
Applicability of the Change Perspective
a. Functional view may be informed by the Change perspective by enabling
the functional structure to reflect the required change.
b. Information view may be informed by the Change perspective by
mandating a flexible information model.
c. Concurrency view may be informed by the Change perspective by
dictating a particular element packaging or some constraints on the
concurrency structure
d. Development view may be informed by the Change perspective by
determining the impact on the development environment.
e. Deployment view may be informed by the Change perspective by
defining impact on the Deployment view because system change usually
affects structures described in other views.
f. Operational view may be informed by the Change perspective to the
extent that it impacts on the operational view.
Tactics for enhancement
• Contain change
• Create flexible interfaces
• Build variation points into the system
• Use standard extension points
• Implement reliable changes
• Apply change-oriented architectural styles
Availability Perspectives
• Desired quality: the ability of the system to be fully or partly operational as and
when required and to effectively handle failures that could affect system
availability.
• Applicability: any system that has complex or extended availability requirements,
complex recovery processes, or a high visibility profile
• Concerns: classes of service, planned downtime, unplanned downtime, time to
repair, and disaster recovery
• Activities: capture the availability requirements, produce the availability
schedule, estimate platform availability, estimate functional availability, and
assess against the requirements.
• Architectural tactics: select fault-tolerant hardware, use hardware-clustering and
load-balancing, log transactions, and apply software availability solutions.
• Problems and pitfalls: a single point of failure, ineffective error detection,
overlooked global availability requirements, and incompatible technologies.
Applicability of the Availability Perspective
• The Functional view may be informed by the Availability perspective by
enabling the business’s ability to operate effectively.
• The Information view may be informed by the Availability perspective by
considering the set of processes and systems for backup and recovery.
• The Concurrency view may be informed by the Availability perspective by
incorporating features such as hardware replication and failover in the
system.
• The Development view may be informed by the Availability perspective by
imposing design constraints on the software modules
• The Deployment view may be informed by the Availability perspective by
mandating a fault-tolerant production environment.
• The Operational view may be informed by the Availability perspective to
allow the identification and recovery of problems in the production
environment.
Tactics for Enhancement
• Select fault-tolerant hardware
• Use hardware clustering and load balancing
• Log transactions
• Implement fault-tolerant software
• Implement software availability solution
• Implement backup and disaster recovery solutions
Scalability Perspective
• Desired quality: the ability of the system to predictably execute
within its mandated performance profile.
• Applicability: systems with complex performance requirements; and
systems where future expansion is likely to be significant
• Concerns: response time, throughput, scalability, predictability,
hardware resource requirements, and peak load behavior.
• Activities: capture the performance requirements, create the
performance models, and analyze the performance models.
• Architectural tactics: optimize repeated processing, reduce
contention via replication, and prioritize processing.
• Problems and pitfalls: imprecise performance and scalability goals,
unrealistic models, and use of simple measures for complex cases.
Applicability of the Scalability Perspective
• The Functional view may be informed by the Scalability perspective
by revealing the need for changes and compromises to one’s ideal
functional structure to achieve the system’s performance
requirements.
• The Information view may be informed by the Scalability perspective
by providing useful input to performance models, identifying shared
resources and the transactional requirements of each.
• The Concurrency view may be informed by the Scalability perspective
to change the concurrency design by identifying problems such as
excessive contention on key resources.
Applicability of the Scalability Perspective
• The Development view may be informed by the Scalability
perspective through a set of guidelines related to performance and
scalability that should be followed during software development.
• The Deployment view may be informed by the Scalability perspective
through crucial inputs to the process of considering performance and
scalability.
• The Operational view may be informed by the Scalability perspective
by highlighting the need for performance monitoring and
management capabilities.
Tactics for Enhancement
• Optimize repeated processing
• Reduce contention through replication
• Prioritize processing
• Minimize use of shared resources
• Minimize partition and parallelize
• Make design compromises
Enterprise Architecture Frameworks
• Helps stakeholders to make decisions about enterprise design and
operation.
• Provides users with some confidence that the use of the reference
architecture will be successful in the current project.
• Facilitates communication of the enterprise design.
• Applicable to a wide range of enterprise systems and scenarios.
• Establishes a common means to organize, interpret, and analyze
architectural descriptions
• Identifies architectural concerns, generic stakeholders, viewpoints, and
abstraction levels.
• Encourages reuse.
• Provides a unified, unambiguous definition of terminology.
The Zachman Framework
Six types of views
1. Planner’s View - executive summary for the project.
2. Owner’s View - a high-level view of the system from the owner’s point of
view.
3. Designer’s View - more technically detailed view of the system.
4. Builder’s View - emphasis will be on implementation issues and
constraints.
5. Subcontractor’s View - detailed designs that are given to the development
team.
6. Actual System View - the actual systems that are being developed.
The Open Group Architecture Framework
• TOGAF provides an approach for designing, planning, implementing,
and governing an enterprise IT architecture.
• TOGAF is a set of phases and associated processes in the form of an
architecture development method (ADM) that will enable an EA to be
created for an organization.
• Instead of views, TOGAF focuses largely on management and
planning, rather than the actual development of the architecture and
its views.
TOGAF ADM
The ADM is an iterative process
covering all phases of EA development
that is adaptable to the specific needs
of any enterprise.
Federal Enterprise Architecture Framework
• FEAF is primarily intended for EA development ongoing in federal
agencies for the purpose of standardizing the development and use of
architectures within and between these federal agencies.
• FEAF provides both, a structure (the Consolidated Reference Model)
and a methodology (the Collaborative Planning Methodology).
• The Consolidated Reference Model consists of six reference models
and provides standardized categorization for strategic, business, and
technology model.
• The Collaborative Planning Methodology is a full planning and
implementation life cycle for federal EAs consisting of two main
phases: (1) organize and plan and (2) implement and measure.
Department of Defense Architecture Framework
• DODAF is a view-oriented architecture framework that provides an
organized meta-model-based visualization infrastructure for
addressing specific stakeholders concerns.
• The framework consists of eight main viewpoints that define specifies
rules for constructing a view on the system under development.
• All DODAF views must follow a Unified Modeling Language-based
meta-model.
• DODAF contains only a high-level, six-step phase model for dealing
with the development process of an EA.
Ministry of Defense Architecture Framework
• Each viewpoint of MODAF offers a different perspective on the system
of a systems project to support different stakeholder concerns and
interests.
• MODAF consists of seven different viewpoints:
1. All Views viewpoint – define the generic, high-level information
that applies to all of the other viewpoints.
2. Strategic View viewpoint –defines views that support the analysis
and optimization of military capability.
3. Operational View viewpoint –contains views that describe the
operational elements required to meet the capabilities defined in
the strategic views.
MODAF Viewpoints
4. System View viewpoint –contains views that relate directly to the
solution that is being offered to meet the required capabilities that
have been identified in the strategic views and expanded upon in the
operational views.
5. Technical Standards View viewpoint – contains two views that allow
all of the relevant standards to be defined.
6. Acquisition View viewpoint –used to identify programs and projects
that are relevant to the framework and that will be executed to
deliver the capabilities that have been identified in the strategy
views.
Main Reference
1. Chapter 4 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Thank You
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 6
Process Architecture
Required Reading
1. Chapter 5 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Weekly Learning Outcomes
1. Describe the process views and perspectives that enable an
enterprise process architecture.
2. Describe the workflow reference model (WFMS) as the
reference process architecture for the enterprise process
architecture.
Contents
1. Process Change, Perspectives, and Views
2. Reference Process Architecture: Workflow Systems
3. Workflow Reference Model
Lewin’s Change Management Model
Lewin observed three stages of change:
1. Unfreeze phase: In order to encourage change, it is necessary to
unfreeze the environment by motivating people to accept the
change.
2. Transition phase: This is where the change (plan) is executed and
actual change is being implemented.
3. Refreeze stage: This is when the organization once again becomes
unchanging/ frozen until the next time a change is initiated
Deming Cycle Change Management Model
• A continuous improvement model composed of four sequential
subprocesses.
1. Plan: Recognize an opportunity and plan a change. Understand the gap
between residents’ expectations and what is being delivered; set
priorities for closing gaps; and develop an action plan to close the gaps.
2. Do: Execute the plan in a small scale to prove the concept. Implement
changes and collect data to determine if gaps are closing.
3. Check: Evaluate the performance of the change and report the results to
the sponsor(s). Observe the effects of the change and test—analyze data
and pinpoint problems.
4. Act: Decide on accepting the change and standardizing it as part of the
process.
Hierarchical Orientation
The key concepts associated with hierarchical orientation are:
a. Environments are characterized by stability, limited
uncertainty, and limited “consumerism”.
b. People follow the structure and rules defined by virtue of
their position and responsibilities.
c. Markets do not change rapidly and the focus is not on
flexibility, quality, service, or innovation.
Process Orientation
• A process orientation adopts a horizontal view of organizations by
emphasizing notions of processes, process owners, teams, and
empowerment and deemphasizing hierarchical structures.
• Business process change integrates different views from quality,
information technology, organizational change, innovation, and work
redesign.
• A process-oriented organization is an organization that defines and
manages business processes explicitly.
Business Process Management
• Models of business processes are the basis for BPM.
• BPM includes areas such as business process modeling, formal
models, analysis and verification of business processes, process
mining, and workflow management.
• A BPM support system is a generic software system driven by explicit
business process designs that enacts and manages operational
business processes.
• A BPM system allows for the modification of the processes it
supports, the deletion of processes, or the incorporation of new
processes.
Process Architecture
• Process architecture is the design and organization of business
processes and related components into a unified structure and
hierarchy.
• Process components, also known as process elements, describe the
various units of a process.
• Process Architecture aligns perspectives and efforts across all levels
and functions in a business.
Process Architecture Benefits
• Process ownership: ensures accountability for the improvement of end-toend processes across the enterprise.
• Strategy creation: A comprehensive overview of the processes across a
company aid in the creation and adjustment of business strategies.
• Strategic alignment: provides a line of sight between corporate strategies
and frontline operational improvement activities.
• Change management: helps get employees ready, willing, and able to
accept and embrace new ways of working.
• Standardization: serves as a guideline for process analysts to devise best
practices for high-level and basic processes.
• Costing: assist with highlighting areas of waste as well as where process
outputs do not justify investment.
Process Architecture Benefits
• Automation opportunities: identify activities within processes that
could be automated to reduce the burden on staff members and
increase speed and efficiency.
• Simplification: enables process architectures to highlight redundant
and complicated processes.
• Process visibility: provides the ability to view and analyze end-to-end
processes individually and in the wider context of the enterprise.
• Performance metrics: embeds key performance indicators within
processes to provide immediate feedback on process performance.
• Reduced cost: The automation of processes should result in reduced
operational costs for the enterprise.
Process Architecture Benefits
• Faster reactions: Simplification and increased automation should also
result in quicker reaction to changing market conditions.
• Impact prediction: offer managers insight into how processes
interrelate and how modifications to any process may affect
synchronized processes.
• Training benefits: provide a visual representation of the processes
and procedures of an enterprise and can be a powerful for training
new or existing staff.
Process Perspectives
• Process architecture designs and organizes business processes and related
components into a unified structure and hierarchy.
• Architecting the business processes entails looking at it through various
perspectives or viewpoints
• Functional perspective: describes the processes themselves and their
structures.
• Data and dataflow perspective: describes which data (or documents) a
process step consumes or produces
• Behavioral perspective: describes the order in which processes must be
executed.
• Organizational perspective: defines persons or roles that are responsible
for the execution of a given process.
• Operational perspective: defines tools or systems that support the
execution of a process.
Process Views
• An architectural view is a representation of a system from the
perspective of a related set of concerns.
• The architectural view concept offers a separation of concerns that has
the potential to resolve the complexity challenges of a Service
Oriented Architecture (SOA) process.
• Perspectives on business process and service interactions are used as
central views, in which each of them represents a certain part of the
processes and services.
• A basic view is defined called the core view as a foundation for the
other views.
• Other views are defined by extending the core view.
The Core View
• The core view is the place wherein the relationships among the views
are maintained.
• The core view provides a number of important abstract elements,
specifically, View, Process, and Service.
• At the heart of the core view is
the View element that captures
the architectural view concept.
• Each specific view represents
one perspective on a particular
Process.
The Core View
• A Service specifies external functions that the Process provides or
requires.
• A view acts as a container for view elements representing the objects
which appear inside the Process.
• The view that represents concerns of a business process are mostly
derived from the core view.
• The hierarchical structures in which those elements are roots can be
used to define the integration points that are used to merge views.
The Control-flow View
• An Activity element is the base class for other elements such as
Sequence, Flow, and Switch.
• Sequence: An activity is only enabled after the completion of another
activity in the same sequence structure.
• Flow: All activities of a flow structure are executed in parallel.
• Switch: Only one of many alternative paths of control inside a switch
structure is enabled according to a condition value.
• A SimpleActivity element represents a concrete action such as a
service invocation, a data processing task, and so on.
• The StructuredActivity element is an abstract representation of a
group of related activities.
The Collaboration View
• The collaboration view extends the relationship between Process and
Service elements in the core view.
• The Service element from the core view is extended by a specific Service
element that exposes a number of Interfaces.
• An Operation represents an action that might need some inputs and
produces some outputs via correspondent Channels.
• A Channel only holds a reference to a Message entity.
• The ability and the responsibility of an interaction partner are modeled by
the Role element.
• These concepts are captured by using the PartnerLink and the
PartnerLinkType elements, as are their relationships with the Role
element.
• An interaction between the process and one of its partners is represented
by the Interaction element that associates with a particular PartnerLink.
The Control-flow (a) vs. Collaboration View (b)
The Information View
• Involves the representation of data object flows inside the process
and message objects traveling back and forth between the process
and the external world.
• Consists of a number of BusinessObjects elements.
• Data flowing inside the process might go through some
transformations that convert existing data to form new pieces of data.
• The transformations are performed inside a DataHandling object.
• The source or the target of a certain transformation is an
ObjectReference entity that holds a reference to a particular
BusinessObject.
The Human View
• The Human view defines human roles and their relationships to the
respective process and tasks.
• It Process elements that require human interactions are called as
Tasks.
• It establishes a role-based abstraction.
• This role-based abstraction can be used for role-based access control.
• Role-based access control is administered through roles and role
hierarchies that mirror an enterprise’s job positions and
organizational structure.
• Users are assigned membership into roles consistent with their
duties, competency, and responsibility.
The Information (a) vs. Human (b) View
(a)
(b)
Reference Process Architecture: Workflow Systems
• Workflows are useful for the coordination of interrelated activities carried
out by organization members in order to execute a business process.
• A WfMS defines, creates and manages the execution of workflows through
the use of software, running on one or more workflow engines.
• Workflow is defined, according to the WfMC, as the automation of a
business process, in which documents, information, or tasks move from
one participant to another in order to perform some actions in accordance
with a set of procedure rules.
• A distributed workflow is executed across an extended enterprise, in
which different individuals participate in order to reach global objectives.
• Collaborative process planning can be considered as a business process
that can be managed using distributed workflows.
Basic Workflow Components
• Activity: A description of a piece of work that forms one logical step within a
process.
• Participant: A resource that performs the work represented by a workflow
activity instance.
• Role: A mechanism that associates participants to a collection of workflow
activities.
• Routing: A route defines the sequence of the steps that information must
follow within a workflow.
• Transition rule: A transition rule is a logic expression that determines what
actions need to be carried out, depending on the value of logic operators.
• Event: An occurrence of a particular condition that causes the workflow
management software to take one or more actions.
• Deadline: A time-based scheduling constraint, which requires that a certain
activity work be completed by a certain time.
Types of Workflow
1. Administrative workflow: used to perform workflow processes
with defined procedures, though not as structured as in the case of
Production workflow, as each instance of the workflow can have a
different amount of work associated with it.
2. Production workflow: consists of highly automated workflow
processes—the goal of a Production workflow is to automate the
process as much as possible.
3. Ad hoc workflow: implemented by a user to perform a string of
actions that arise for a business scenario.
4. Collaborative workflow: involves a team of people working
together.
Workflow Perspectives
1. Data or Informational Perspective:
• Consists of data flow between workflow activities.
• Each activity is assigned a set of input and a set of output parameters.
• The transfer of data between workflow activities is known as data
flow.
• The modeling of data is required to permit workflow management
systems to control the transfer of workflow relevant data as
generated by workflow activities during workflow executions.
• By providing graphic language constructs to represent data flow
between activities, the informational perspective can be visualized
and used to validate and optimize application processes.
Workflow Perspectives
2. Context of Organizational Perspective:
• WfMS requires information on the context that is organizational as well as
on the technical environment in which the workflows will be executed.
• Atomic workflows can be either automatic or manual.
• Manual atomic workflows are executed by persons who may use
application programs to do so.
• automatic atomic workflows are executed by software systems without
human involvement.
• The role concept is defined dependent on the structure of an organization
in which the workflow is executed.
• When an activity is about to start, the system uses predefined role
information to select people to perform the requested activity.
Workflow Perspectives
3. Interaction or Operational Perspective:
1. When persons are selected by role resolution to perform workflow
activities.
2. When a person chooses to perform an activity, then the defined
application program is started and the input data as specified in the
workflow model are transferred to that application program.
3. When the person completes that activity, the output data generated
by that activity are collected in the output parameters of the activity
to be transferred by the WfMS to the next workflow activity, as
specified in the respective workflow model.
Workflow Perspectives
4. Processing or Functional and Behavioral Perspective:
• The processing perspective covers the functional decomposition of
activities as present in application processes.
• It specifies which activities have to be executed within a workflow.
• Workflows have a tree structure, where root node represents the toplevel workflow, inner nodes represent other complex workflows, and
leaf nodes represent bottom-level atomic activities.
• The controlled execution of a complex workflow by a WfMS has to
take into account interrelationships of the subworkflows covered in
the subordinate behavioral perspective.
Workflow Reference Model
• The WRM divides the workflow system into five components:
1.
2.
3.
4.
5.
Process definition tool
Workflow engine
Workflow client application
Invoked application
Administration and monitoring tool
• The WRM provides the following guidelines:
• Common terminology for the workflow product category
• WRM is the functional components necessary in a WfMS.
• Interfaces that connect the various functional components
WRM Components and Interfaces
Workflow Process Definition Tool
• The process definition tool is a design tool that allows the workflow
designer to design and model the workflow process.
• It provides a graphical interface for the process designer to graphically
design the business process.
• The result of the design activity is a workflow process model.
• Once the workflow process model has been designed, the process
definition tool creates an output of the model using a process
definition language.
• The workflow process that is included in the calling workflow process
is called a subprocess and can be nested further.
Workflow Process Definition Tool
• An activity is work performed by a specific resource.
• The participants in a workflow process could be an explicitly named
human user, a role defined in an organizational structure, a position
that is part of the organizational unit, or an information system.
• There are four generic flow control mechanisms: sequential, parallel,
iteration, and nesting.
• Transition defines the criteria for moving to the next activity and it is
usually represented as a line from one activity to the next in the
graphical workflow process model.
• Transition can be of two types: conditional and unconditional.
Workflow Client Application
• Workflow client application is an application that requests services
from the workflow engine including the retrieval of a worklist
generated by the workflow engine for participants to execute.
• The workflow engine generates the work items assigned to specific
users, which are retrieved by the workplace portal and then displayed
to each user for action.
• The workflow client application would need to instantiate a workflow
process instance, execute a work item, and update the worklist in the
workflow engine as to the status of a particular work item.
Workflow Engine
• The workflow engine is the runtime environment of the WfMS.
• It creates process instances of the workflow process based on a
trigger event for the creation of a workflow process instance.
• An event is a predefined circumstance the workflow engine is
listening for.
• The trigger could be some status change of an application
transaction.
• When a workflow process instance is created, the workflow engine
manages workflow relevant data throughout the life cycle of the
workflow process instance.
Invoked Application
• The workflow engine to perform work calls the invoked application.
• The invoked application is the backend application that creates
business transactions.
• It is a system participant that usually performs a transaction as a
result of the workflow process.
• An example is the purchasing requisition process; an online request
form completed by a human participant might trigger the process.
• Once the workflow engine has received the purchase request form,
the next activity in the workflow process is to create a purchase
requisition in the backend ERP system.
Administration and Monitoring Tool
• Allows system administrators to manage the WfMS users, roles, and
resources.
• Provides functions such as audit reporting, querying of process status,
and updating active process instances.
• Workflow engines store events and record updates to process
instances in workflow logs.
• The administration and monitoring tool retrieves workflow logs for
process instances that have completed and instances that are still in
progress.
• These statistics provide data for process analysis, which lead to
process improvements.
Workflow Reference Model Interfaces
1. Interface 1 links the workflow process definition tool to the
workflow engine.
2. Interface 2 links the workflow client application to the workflow
engine.
3. Interface 3 connects the workflow engine to the business
applications invoked during the processing of the workflow model.
4. Interface 4 enables integration between heterogeneous workflow
engines by providing a set of APIs that one WfMS can invoke on
another.
5. Interface 5 enables integration between workflow engines with the
administration and monitoring tool.
Main Reference
1. Chapter 5 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)
Thank You
ر
الجامعة السعودية االلكتونية
ر
االلكتونية
الجامعة السعودية
26/12/2021
College of Computing and Informatics
IT402
Integrated Enterprise Systems
IT402
Integrated Enterprise Systems
Week 7 - Enterprise and Process Modeling
Contents
1. Model and Types of Models
2. Modeling and Modeling Ontology
3. Requirements of Modeling
4. Enterprise Modeling
5. Process Modeling
6. Process Description for Storing Business Process Models
Weekly Learning Outcomes
1. Understand Enterprise Modeling and Process Modeling
2. Modeling Ontology and recognizing various requirements of
modeling
3. Process Description for Storing Business Process Models
Required Reading
1. Chapter 6: Enterprise Modeling
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise information
systems: A pattern based approach (3rd ed.). New York: McGraw Hill
Higher Education. ISBN: 007240429 (print), 9781308469676 (e-text).
2. Enterprise Modeling
https://docs.oracle.com/search/?q=enterprise+modeling
This Presentation is mainly dependent on the textbook: Enterprise Information Systems: Contemporary Trends and Issues
Enterprise Modeling
Enterprise Modelling
• Implementing process-oriented architectures has proven to be
difficult for many companies.
• Implementing process concepts within organizations is only one step
toward achieving an enterprise-wide focus on processes.
• Process management deals with the efficient and effective execution
of business processes.
Enterprise Modelling
• It consists of the planning, implementation, enactment, and
controlling of processes and forms a life cycle that leads to continuous
process improvement.
• There is a gap between approaches for modeling business processes
and those for modeling information systems.
• There is a strong need for a methodology for creating a supporting
information system that is based on the process architecture of an
organization.
Model
• A model is a form of representing something: it is not a replication
but rather an intentional selective construction of a new thing or
system that has the purpose of representing another thing or system.
• No model is unique or exclusive, as there can be a multitude of them;
furthermore, models are generally not correct or incorrect—it is only
what it is with reference to the defining purpose of the respective
model.
Characteristics of a model
Characteristic
Description
Abstraction:
A model is a reduced description of the system.
Accuracy:
For the properties of interest, a model provides a true-to-life repr...
Purchase answer to see full
attachment