Академический Документы
Профессиональный Документы
Культура Документы
Areti Manataki
Master of Science
Artificial Intelligence
School of Informatics
University of Edinburgh
2007
Abstract
Supply Chain Management is becoming more and more important for the success of
todays business world. Dell has realized this trend from its very first steps and has
become one of the most successful PC companies in the world by putting emphasis
on its supply chain, orchestrating its build-to-order and direct sales strategies.
While most of the literature that covers Dells business and supply chain strategies is
too theoretical, we suggest an analysis of a lower level using knowledge-based
techniques. So, we have developed a business process model for Dell that captures its
supply chain strategies, and which is strategic, business-goal-oriented and executable.
In order to make this BPM executable we have designed and implemented a
workflow engine that simulates BPM execution and calculates the related total time
and cost. Using the workflow engine we have then run experiments on Dells BPM
improvement and on its comparison with a traditional PC company, thus providing a
useful framework for supply chain strategies comparison.
This work is expected to provide a good insight into the successful supply chain of
Dell on the one hand, and demonstrate whether knowledge-based techniques can
provide good analysis of business and supply chain strategies in general on the other
hand.
i
Acknowledgements
I would first of all like to thank my supervisor, Dr. Jessica Chen-Burger, for her
guidance and help throughout this project, as well as for the support in difficult
moments of the project period. I would also like to thank Dimtrios Mavroeidis and
Ioanna Manataki for their participation in the evaluation procedure of the developed
business process model.
ii
Declaration
I declare that this thesis was composed by myself, that the work contained herein is
my own except where explicitly stated otherwise in the text, and that this work has
not been submitted for any other degree or professional qualification except as
specified.
(Areti Manataki)
iii
Table of Contents
1 Introduction.............................................................................................................1
1.1 Motivation.................................................................................................... 1
1.2 Gap, Aim and Objectives.............................................................................1
1.3 Thesis Outline ..............................................................................................2
2 Background Information........................................................................................ 3
2.1 Supply Chain Management.......................................................................... 3
2.1.1 Importance of Supply Chain Management ...................................... 6
2.1.2 Supply Chain Management Approaches.......................................... 7
2.1.3 Hot topics in Supply Chain Management..................................... 8
2.2 Dells Supply Chain Strategies ..................................................................10
2.2.1 General Information about Dell .....................................................10
2.2.2 Directs Sales................................................................................... 11
2.2.3 Build-to-order and integration with suppliers................................ 12
2.2.4 Other interesting approaches.......................................................... 14
2.3 Business Process Modelling....................................................................... 15
2.3.1 General Information about BPM....................................................15
2.3.2 BPM Methods and Tools ...............................................................17
2.4 Workflow Management .............................................................................18
2.4.1 Definition and General Information............................................... 18
2.4.2 Different Approaches and Trends in Workflow Management....... 19
2.5 Fundamental Business Process Modelling Language (FBPML) ............... 20
2.5.1 Notation in FBPML .......................................................................20
2.6 Three-Layered Business Process Modelling Approach............................. 24
iv
3.3.1 Weaknesses of Dells BPM sequenced version .............................41
3.3.2 Enriched-MIT Process Handbook version of Dells BPM ............ 42
5 Experiments ........................................................................................................... 80
5.1 Dells BPM simulation............................................................................... 80
5.1.1 Dells BPM specification and representation................................. 81
5.1.2 Dells BPM simulation results .......................................................88
5.1.3 Discussion of Dells BPM simulation results ................................ 89
5.2 Experiments & Results...............................................................................90
5.2.1 Experiment 1: Improve the actual BPM ........................................91
5.2.2 Experiment 2: Compare Dell with a traditional computer company
95
5.3 Discussion and conclusions ..................................................................... 103
v
6.2.3 Completeness evaluation.............................................................. 109
6.2.4 Evaluation of the level of detail ................................................... 110
6.3 Evaluation of developed workflow engine .............................................. 111
6.3.1 Soundness evaluation................................................................... 111
6.3.2 Completeness evaluation.............................................................. 112
6.3.3 Coverage evaluation..................................................................... 113
6.3.4 Ease of use ................................................................................... 113
vi
List of Figures
Figure 1: Types of channel relations and flows across a supply chain.........................4
Figure 2: Analysis of SCM System [53].......................................................................5
Figure 3: Cost-Responsiveness Efficient Frontier and Zone of Strategic Fit [10].......8
Figure 4: Distribution channel of Dell vs. a traditional company [31].......................11
Figure 5: FBPML notation..........................................................................................20
Figure 6: FBPML joint and split junctions.................................................................22
Figure 7: Combinations of FBPML junctions............................................................ 23
Figure 8: Three-layered BPM approach.....................................................................24
Figure 9: Sample entry of the MIT Process Handbook for buy..............................27
Figure 10: Sample entry of the MIT Process Handbook for Identify potential
customers in custom channel {Dell}................................................................ 27
Figure 11: Decomposition of Create computers to order (MIT Process Handbook)
28
Figure 12: Decomposition of Design product and process (MIT Process
Handbook).......................................................................................................... 29
Figure 13: Decomposition of Buy standard item to stock (MIT Process Handbook)
29
Figure 14: Decomposition of Sell using customized sales channel {Dell} (MIT
Process Handbook).............................................................................................31
Figure 15: Decomposition of manage as a creator (MIT Process Handbook)........32
Figure 16: Decomposition of Create computers to order (Sequenced MIT Process
Handbook version)............................................................................................. 34
Figure 17: Decomposition of Design product and process (Sequenced MIT Process
Handbook version)............................................................................................. 35
Figure 18: Decomposition of Develop product and process design (Sequenced MIT
Process Handbook version)................................................................................ 35
Figure 19: Decomposition of Buy standard item to stock (Sequenced MIT Process
Handbook version)............................................................................................. 36
Figure 20: Decomposition of Manage suppliers (Sequenced MIT Process
Handbook version)............................................................................................. 36
Figure 21: Decomposition of Sell using customized sales channel (Sequenced MIT
Process Handbook version)................................................................................ 37
Figure 22: Decomposition of Identify potential customers in custom channel
(Sequenced MIT Process Handbook version).................................................... 38
Figure 23: Decomposition of Manage as a creator (Sequenced MIT Process........38
Figure 24: Decomposition of Manage resources by type of resource (Sequenced
MIT Process Handbook version)........................................................................39
Figure 25: Decomposition of Manage other external relationships (Sequenced MIT
Process Handbook version)................................................................................ 39
Figure 26: Decomposition of Manage regulatory relationships (Sequenced MIT
Process Handbook version)................................................................................ 40
Figure 27: Decomposition of Create computers to order (Enriched version).........43
Figure 28: Decomposition of Develop product and process...................................44
Figure 29: Decomposition of Develop product and process design (Enriched
version)...............................................................................................................44
vii
Figure 30: Decomposition of Buy standard item to order (Enriched version)........45
Figure 31: Decomposition of Share info with supplier (Enriched version)............46
Figure 32: Decomposition of Share real-time info via Value Chain (Enriched
version)...............................................................................................................46
Figure 33: Decomposition of Get inventory from supplier (Enriched version)......47
Figure 34: Decomposition of Manage supplier (Enriched version)........................47
Figure 35: Decomposition of Build to order (Enriched version)............................48
Figure 36: Decomposition of Sell directly (Enriched version)...............................49
Figure 37: Decomposition of Sell directly to home and small business customers
(Enriched version).............................................................................................. 49
Figure 38: Decomposition of Manage home and small business customers
(Enriched version).............................................................................................. 50
Figure 39: Decomposition of Support home and small business customers
(Enriched version).............................................................................................. 50
Figure 40: Decomposition of Get feedback from home and small business
customer (Enriched version).............................................................................51
Figure 41: Decomposition of Sell directly to large business and public sector
customers (Enriched version)........................................................................... 51
Figure 42: Decomposition of Identify potential corporate customers (Enriched
version)...............................................................................................................52
Figure 43: Decomposition of Manage large business and public sector customers
(Enriched version).............................................................................................. 52
Figure 44: Decomposition of Support large business and public sector customers
(Enriched version).............................................................................................. 53
Figure 45: Decomposition of Support large business and public sector customers
(Enriched version).............................................................................................. 53
Figure 46: Decomposition of Manage as a creator (Enriched version)..................54
Figure 47: Decomposition of Manage resources by type of resource (Enriched
version)...............................................................................................................54
Figure 48: Decomposition of Manage other external relationships (Enriched
version)...............................................................................................................55
Figure 49: Decomposition of Manage regulatory relationships (Enriched version)
55
Figure 50: Relation between workflow engine mission, conceptualisation and
requirements, design decisions and assumptions............................................... 60
Figure 51: Example BPM with a process branch....................................................64
Figure 52: An example BPM for the workflow engine..............................................66
Figure 53: Relation of workflow engine with model, process and entity specification
70
Figure 54: Flowchart of our workflow engine............................................................72
Figure 55: Flow state of the execution of a simple BPM using our workflow engine
73
Figure 56: Graphical representation of workflow engine use.................................... 78
Figure 57: Decomposition of Buy standard item to order (Enriched version)........81
Figure 58: Decomposition of Sell directly to large business and public sector
customers (Enriched version)........................................................................... 85
Figure 59: Original (sequenced) and parallelized part of Buy standard item to order
for experiment 1, version 1.................................................................................92
viii
Figure 60: Original (sequenced) and parallelized part of Buy standard item to order
for experiment 1, version 2.................................................................................93
Figure 61: myCompanys BPM for Buy standard item to stock.............................96
Figure 62: Comparison of simulation results of time between Dells Buy standard
item to order and myCompanys Buy standard item to stock....................... 98
Figure 63: Comparison of simulation results of cost between Dells Buy standard
item to order and myCompanys Buy standard item to stock....................... 98
Figure 64: myCompanys BPM for Sell via intermediary to business customers . 99
Figure 65: Comparison of simulation results of time between Dells Sell directly to
large business and corporate customers and myCompanys Sell via
intermediary to business customers................................................................ 102
Figure 66: Comparison of simulation results of cost between Dells Sell directly to
large business and corporate customers and myCompanys Sell via
intermediary to business customers................................................................ 102
Figure 67: Comparison of simulation results of time between Dells and
myCompanys processes...................................................................................104
Figure 68: Comparison of simulation results of cost between Dells and
myCompanys processes...................................................................................105
Figure 69: Level of detail of Dells BPM.................................................................111
Figure 70: Example BPM to illustrate that backward chaining is inappropriate for
start time estimation..........................................................................................122
Figure 71: Execution times of processes of Figure 70............................................. 122
Figure 72: Example BPMs to illustrate sophisticated treatment of process waiting
time...................................................................................................................123
Figure 73: Example BPM to illustrate the need for prior knowledge of events
occurrence.........................................................................................................125
Figure 74: Example BPM with a process branch.....................................................126
Figure 75: Example BPMs to illustrate the need for conditions iii) and iv) of
execution completion........................................................................................127
Figure 76: Example BPMs for a transforming a BPM containing a loop................128
Figure 77: Example BPM for simulation................................................................. 138
Figure 78: Graphical representation of workflow engine use framework................139
Figure 79: Screenshot of myProcess.pl.................................................................... 140
Figure 80: Screenshot of myJunctions.pl................................................................. 141
Figure 81: Screenshot of myWorld.pl.......................................................................143
Figure 82: Screenshot of workflowEngine.pl...........................................................144
Figure 83: Screenshot of Sicstus Prolog environment in Windows......................... 145
Figure 84: Screenshot of run command of workflow engine in Sicstus Prolog.......145
Figure 85: Screenshot of BPM simulation output.................................................... 146
ix
List of Tables
Table 1: Dells appropriate coupling of supply chain capabilities with processes and
people..................................................................................................................15
Table 2: Key principles for Dells business model according to Pearlson et al [41]. 15
Table 3: Common characteristics of Business Process definitions.............................16
Table 4: Contribution of Business Process Modelling, according to Luo et al [33].. 17
Table 5: Model specification of junction-followed-by-junction in our workflow
engine..................................................................................................................67
Table 6: Process specification of Buy standard item to order.................................82
Table 7: Process specification of Sell directly to large business and public sector
customers.......................................................................................................... 86
Table 8: Simulation results of Dells Buy standard item to order...........................88
Table 9: Simulation results of Dells Sell directly to large business and public sector
customers.......................................................................................................... 89
Table 10: Simulation results of myCompanys Buy standard item to stock...........97
Table 11: Simulation results of myCompanys Sell via intermediary to business
customers........................................................................................................ 101
Table 12: Results of experiment 2 for Dell and myCompany..................................104
Table 13: Completeness Evaluation Checklist for Dells BPM................................109
Table 14: Completeness Evaluation Checklist for the developed workflow engine112
x
Chapter 1
Introduction
1.1 Motivation
The role of Supply Chain Management (SCM) is becoming more and more important
in todays business world. From a purely operational approach to SCM of the 1960s
we have moved to a more integrated and strategic approach. Hence, supply chain
management is today considered as a source of competence and innovation. In the
modern business world, companies are competing not only through their product
range and customer relations, but also through their supply chains.
In this, Dell has been held as the golden example of Supply Chain Management.
Dell has achieved to become one of the most successful PC companies in the world,
by emphasizing and aligning its strategies with the design of its supply chain (SC).
The innovative ideas of its founder, Michael Dell, and their successful
implementation have turned Dell into the most quoted example of the Supply Chain
research community.
Even though several research efforts have examined Dells supply chain strategies,
most of the adopted approaches fall into the category of strategic and theoretical,
abstract view of the subject. On the other hand, the business world is starving for
examples and practical, realistic advice for strategies and operations. So, there seems
1
to be some gap between academia and the business world concerning the
treatment of the subject of SCM.
Our aim is to fill this gap by providing an analysis of a lower level, thus use
knowledge-based techniques to analyze and model Dells business and SC strategies.
After examining these strategies, we will develop a business process model (BPM)
for Dell that is strategic, business-goal-oriented and executable. To make the BPM
executable we will create a workflow engine for BPM simulation and calculation of
the total execution time and cost.
So, the primary objective of our work is to have an insight into Dells supply chain
strategies. The secondary objectives include: i) the development of a BPM for Dell
that illustrates its SC strategies, ii) the creation of a workflow engine for BPM
simulation that is business context sensitive, and iii) the simulation of the developed
BPM using the workflow engine for further analysis of Dells strategies.
The thesis has been divided into 7 chapters, starting from this introductory one. The
remaining chapters are organised as follows:
Chapter 2 gives an overview of literature that is related to our work, and
hence covers Supply Chain Management, Dells Supply Chain Strategies,
Business Process Modelling and Workflow Management
Chapter 3 describes the developed Business Process model for Dell and
explains the relevant decisions
Chapter 4 covers the development of the workflow engine and illustrates its
mission and objectives, some design decisions and assumptions we have
made
Chapter 5 presents the experiments we have conducted on Dells BPM using
our workflow engine and illustrates the relevant conclusions
Chapter 6 covers the evaluation of our work
Chapter 7 summarizes the work done, presents interesting conclusions and
suggests future extensions of this work
2
Chapter 2
Background Information
In this chapter we will review literature that is relevant to our work and that will be
helpful to the reader to bear in mind throughout the report. Since our work combines
a business-oriented subject with a computer science methodology, it is meaningful to
review literature of both sciences. So, we will first present some general background
information about supply chain management, and then we will review literature that
handles Dells supply chain strategies. In the second half of this chapter we will give
an introduction to business process modelling and workflow management, and then
we will explain some topics that we will base our work on, thus FBPML and the
three-layered business process modelling approach.
Supply chains can differ in size, complexity of relations between the members and
distribution of physical presence. In the following figure two different types of
channel relations can be seen: direct, where the SC consists of one supplier and one
customer of an organisation, and extended, where apart from the above, a suppliers
supplier, a customers customer, etc. are included. In general, supply chains are
3
dynamic, and involve the flow of information, products and funds between different
stages [30], as shown in the following figure.
Customers
Suppliers Supplier Organization Customer
Supplier Customer
Products
Information
Fund
Supply chain management has the objective to have the right products in the right
quantities at the right time at minimal cost [13], a situation that would guarantee
optimal service levels for the customer and optimal performance for the organizations
as a whole and separately. So, SCM involves the management of flows between and
among members of the supply chain in order to maximize total supply chain
profitability [10], hence maximize the total value generated throughout the SC.
Even though the term Supply Chain Management is popular in both academia and
business world, its meaning seems to be ambiguous, as Mentzer et al. [38] suggest.
Some authors view SCM as a management philosophy (with systems approach,
strategic orientation and customer focus as key features), others use the term to refer
to the set of activities to implement a management philosophy (with integrated
behaviour, mutually sharing information, risks and awards, cooperation and
integration of processes being the most important ones), while a third approach is in
terms of a set of management processes (the definition given above by Chopra et al.
[10] adopts this approach). In our work we will adopt the last definition of SCM,
4
while recognizing the existence and importance of the others an organization needs
first to decide about its supply chain strategy and then translate it into actions and
processes that fulfil it.
Apart from this, there seems to be a confusion between the term of Supply Chain
Management and Logistics. In fact, the two terms are very closely related, and they
are sometimes used alternatively. However, logistics involves the management of
order processing, inventory, transportation and warehousing and the challenge
within a firm is to coordinate functional competency into an integrated operation
focused on servicing customers, while in the broader supply chain context,
operational synchronization is essential with customers and suppliers in order to link
internal and external operations as one integrated process [4]. This is made clear by
the following figure by Zografos [53]: Logistics involves the operations of a single
enterprise, while supply chain management involves the interoperations between the
different supply chain members.
Supply Chain
Management Organization
ORGANIZATION LOGISTICS
ORGANIZATION
SALES
ORGANIZATION MANUFACTURING
ORGANIZATION
Logistics
Transportation Operation
system ORDER PROCESSING
TRANSPORTATION
SERVICES RESOURCES
INVENTORY
WAREHOUSING
Bearing in mind the different dimensions of SCM, there are three types of SCM
decisions: strategic, tactical and operational [39]. Strategic SCM decisions involve
the design and configuration of the supply chain, capacity planning and facility
location; tactical decisions include supplier selection and evaluation, bidding and
5
contracts; operational decisions include inventory management, production planning
and scheduling, and replenishment policy. The research concerning SCM decisions is
wide, and it includes the five illustrative decision models by Narasimhan et al. [39],
thus buyer-supplier behaviour, sourcing, integrated operations and marketing and
logistics models.
6
Finally, we should take into account the emergence of Internet and E-Commerce.
Internet and new technologies, such as ERP, have facilitated the sharing of
information between firms, thus highlighting how much a company can benefit from
cooperation with other members of its supply chain. As Lawton et al. [29] suggest,
Internet has extended the benefits of ERP from the value chain of an individual firm
to the entire value system of firms and their suppliers and customers. Relevant
literature [11] deals with the other side of the same coin, i.e. how different companies
can use the strengths of Internet in order to improve their supply chain performance.
One can tackle this problem through modelling models of successful supply chains
are expected to give insight into SC theory and extend it. Beamon [2] provides us
with a focused review of multi-stage supply chain modelling, differentiating four
types of SC models: deterministic analytical, stochastic analytical, economic models
and simulation models. In the same article an analysis is given on the different SC
performance measures being used, divided into qualitative and quantitative
categories.
It is also common practice to examine and analyse important issues of supply chain
management. For example, it has been argued [10] that competitiveness and supply
chain strategies must have the same goal, in other words a company should achieve
a strategic fit by aligning its SC strategies with the customer priorities. Towards this,
three steps should be followed: understand the customer and supply chain
uncertainty, understand the supply chain capabilities and achieve the strategic fit. As
far as the second step is concerned, one should bare in mind the so-called cost-
responsiveness efficient frontier, which can be seen in the figure below.
7
High Zone of strategic fit
Responsiveness
Low
High Low
Cost
Figure 3: Cost-Responsiveness Efficient Frontier and Zone of Strategic Fit [10]
Many researchers are also concerned with the strategic dimension of SCM. Cohen et
al. [12] propose five disciplines for top performance: view your supply chain as a
strategic asset, develop an end-to-end process architecture, design your organization
for performance, build the right collaborative model and use metrics to drive business
success.
All these issues are often addressed in SCM literature, illustrating the importance of
the extended enterprise (sometimes also called virtual enterprise). For instance, Lee
[30] investigates the significance of integration in modern supply chains and how
value can be created, suggesting that supply chain integration is neither an easy nor
a simple task but the payoff can be handsome. Similarly, Gattorna [18] takes us
from firms alignment and alignment in the supply chain to dynamic alignment,
introducing a four-level framework to achieve this: marketplace-, strategy-, culture-
and leadership-related. Thomas et al. [50] argue that firms are moving from
decoupled decision making process toward more coordinated and integrated design
8
and control of their components in order to provide goods and services to the
customer at low cost and high service levels and present three categories of
operational coordination (buy-vendor, production-distribution and inventory-
distribution), as well as strategic planning models that support SC coordination.
A related hot topic is the so-called bullwhip effect in supply chains. Bullwhip
effect is the phenomenon of the amplification of demand order variability as we
move up in the supply chain [31], which has as consequence excessive inventories,
poor forecasts and poor customer service. Even though different suggestions have
been made on how to deal with this problem, there are still many companies suffering
from bullwhip effect symptoms.
Important research is also done in the field of different SCM trends and strategies.
Mass production techniques, pioneered by Ford in the 1920s [29], have been
common practice in the twentieth century and are still seen as the most popular rule
for doing business. A challenge to this model has been the just-in-time (JIT) scheme
introduced by Toyota in the 1960s, which facilitated rapid product innovation,
flexible production and cost saving through lower level of inventory [29]. The term
JIT refers broadly to a philosophy where the entire supply channel is synchronized
to respond to the requirements of operations or customers [16], and it involves
manufacturing (with small lot sizes and short lead times) and purchasing (with
frequent deliveries of small lot sizes as central point). Build-to-order (sometimes also
referred as make-to-order) is another popular operations paradigm, which leads to a
flexible and responsive supply chain [19]. What is also common in todays supply
chains is the vertical disintegration of production, meaning that companies tend to
focus on their core competence and outsource their logistics and secondary
operations (3PL) in order to save money. Postponement is another common practice,
where there is a delay in decision making and especially in manufacturing of a
product, resulting in better predictions about the end product demand over time [44].
9
2.2 Dells Supply Chain Strategies
Dells success remained for the following years, however could not entirely avoid the
general crisis of the PC industry of the new millennium; Dells growth rate has fallen,
resulting in a fall in its stock price. However, Dell has managed to remain a
successful company, as its growth rate continues to outpace the industry as a whole
[28]. Apart from this, Dell has decided to enter new markets and, thus, expand its
product portfolio: servers, workstations, printers and PDAs, as well as flat-screen
TVs and digital cameras are the new challenge for the company. Under this scope,
Dell changed its name in 2003 from Dell Computer Corporation into Dell Inc., in
order to reflect the evolution of the company from a computer manufacturer to a
company that provides a wide array of technology-related services [45].
Michael Dells strategic choices and his effective way of realizing them have played
a significant role in Dells success story. The key element of his successful business
model of the company is its supply chain management; hence, many theorists of
Supply Chain Management have tried to investigate Dells SC strategies, and several
companies have attempted to copy Dells business model, without success
however. This fact shows the complexity of Dells SC strategies and its unique way
10
of putting them into practice. The core elements of Dells business model are its
direct sales model, usually referred as direct model, and the build-to-order strategy.
PC Retailers
Suppliers maker Distributors Resellers Final
Integrators Customer
In fact, Dell sells directly to all its customers, from home-PC users to the worlds
largest corporations [54]. This way it creates a direct relationship with each
individual customer, which turns out to be a great source of competitive advantage.
As Michael Dell has stated, this direct relationship creates valuable information
about the customer, thus Dell knows who the end users are, what they have bought
from Dell and what their preferences are, a fact that allows Dell to offer add-on
products and services, and stay, in general, closer to the customer [27]. As Lawton et
al [29] suggest, this provides Dell with a wealth of marketing and product
development information.
11
finer and finer in order to better approach the customers. This fact, in combination
with the direct model, leads to the ability to better forecast demand [34].
12
customer has placed an order; then lean manufacturing and just-in-time production
take place. This means that once an order is placed, configuration details are sent to
the manufacturing floor and the assembly begins; once the computer is built and the
requested software is downloaded, it is shipped by a 3PL to the customer.
What is special in the case of Dell is its relationship to its suppliers, which also
facilitates its build-to-order model. Dell fully adopts the approach of the extended
enterprise by viewing its suppliers as an integral part of doing business and a key
factor for its success. The supplier effectively becomes our partner, as Michael
Dell states [15].
Dell selects suppliers that have expertise, experience and the ability to deliver
value [51], and their performance is regularly evaluated against pre-agreed
measures. In fact, every quarter Dell meets with its suppliers to provide direct
feedback on performance and future expectations [17]. The performance is evaluated
through a scorecard that compares each supplier with its competitors based on cost,
quality, reliability and continuity of supply. As a reward, Dells well-performing
suppliers are provided with training and support in order to improve their processes.
Under the effort of minimizing its inventories, Dell demands from its suppliers to
provide them with goods in a high speed so instead of orders such as deliver
5000 to this warehouse every two weeks, the form of orders is more like tomorrow
morning we need 6.795 to be delivered at door A3 (of the warehouse) by 7 am [51].
A new notion that Dell has introduced is the one of inventory velocity, and it focuses
13
on minimizing inventory and maximizing speed. It is worth mentioning that Dell
holds an average of less than 6 days of inventory, while the corresponding average of
its competitors is 6 weeks [36]. (This fact will be later factored in our model design
for simulation, in Chapter 5.) In order to deal with these high rhythms, the main
suppliers are required to maintain inventory near or in Dells plants; they can either
produce close or keep inventories in revolvers or supplier logistics centres (small
warehouses close to Dells assembly plants, that are shared by suppliers who pay the
corresponding rent) [24].
Of course, all the practices described above require close collaboration between Dell
and its suppliers mutual trust and sophisticated data exchange are key factors to
achieve it. This wouldnt have been possible without the use of Internet and IT: The
most important facility towards information sharing is the website
ValueChain.Dell.com which operates as an extranet between Dell and its suppliers.
Through ValueChain.Dell.com Dells suppliers can get informed about the level of
inventory in the supply chain, supply and demand data, component quality metrics
and new part transitions [24]. This way, Dell shares demand and production forecasts
with its suppliers, so they can themselves decide on production levels, avoiding the
bullwhip effect.
1
4
SCM Capabilities Processes People
Maniacal about execution / Bias
Demand Management Direct Model / Build-to-order
for action
Internal Collaboration Information Technology Culture of information sharing
Linked partner planning and Value of personal/business
Leverage Partners execution relationships
Business Fundamentals Balance sheet and P&L Rewarded for decreasing costs
Table 1: Dells appropriate coupling of supply chain capabilities with processes
and people
According to Kraemer et al. [27], there are three central points in Dells value web
model: Dells powerful role in coordination and control of the value network, its
close physical integration with its suppliers and business partners, and the importance
of information technology, the Internet and other electronic communications.
Chopra et al. [11] have evaluated Dell by viewing it as an example of e-business that
has used Internet to align it with its supply chain strategies. Pearlson et al. [41] view
Dell as a zero-time organisation and identify four key principles apart from build-to-
order and direct model, which can be seen in the following table and which we will
not analyse any further.
15
Lindsay et al. [32] suggest, business processes are not adequately defined, a fact that
leads to confusion in the academic and especially in the business sector. For example,
there seems to be some confusion about whether a process description refers to the
end product or not, and whether the analysis of a business process is appropriate for
decision-making modelling.
Business Process Modelling (BPM) has captured the attention of the business world
in the mid 1990s and is becoming increasingly popular since then. As Aguilar-Savn
suggests [46], business process models are mainly used either to learn, make
decisions about the process or develop business process software. Kalpic et al. [23]
emphasise the importance of process modelling as a tool that allows the capturing,
externalisation, formalization and structuring of knowledge about enterprise
processes, thus enabling knowledge management. In other words, even though
business processes are nothing new to enterprises, their modelling makes their
existence explicit and provides a common ground for relative discussion.
On the other hand, it has been argued that process management has failed to fulfil its
promises. In fact, Benner et al. [3] have shown that pressures towards process
management stunt a firms dynamic capabilities and that process management
activities are beneficial for organizations in stable contexts, but not in dynamic
innovation and change. However, the contribution of business process modelling
and management is still widely recognised for the reasons mentioned in Table 4. Not
to forget that BPM is usually the first step towards Business Process Reengineering
16
(BPR), a very popular management approach aiming at the improvement of the
performance of business processes with respect to cost, quality, service and speed.
Contribution of BPM
Common process representation Common understanding of process
Analysis of process behaviour and Basis for process improvement and
performance management
Process guidance and execution support Process control
automation
Table 4: Contribution of Business Process Modelling, according to Luo et al [33]
It is sometimes not clear which modelling method is appropriate for a project. Luo et
al. [33] suggest a framework for selecting BPM methods based on BPM objectives.
In this framework we start with the BPM objectives (communication, analysis or
control) and continue with the required perspectives of modelling methods (object,
activity or role) and their required characteristics (formality, scalability, enactability
and ease of use). The latter two are matched to the different modelling methods, thus
leading to the selection of the most appropriate one.
17
representation system is provided. Soffer et al. [49] also deal with the integration of
goals into process modelling by distinguishing goals from soft-goals or business
measures. Kavakli and Loucopoulos [25] suggest a different way of relating goals to
business process modelling: Under the larger framework of Enterprise Knowledge
Development, an enterprise goal submodel is created and this is linked to the
enterprise process submodel. The connection between the two has as following:
Goals related to a business process are presented in a hierarchical way, with the top
business goal being realized by the process, and the leaf node goals being realized by
some role (related to some actor of the process) of the business process.
Workflow Management Systems have been around since the early nineties and they
have become very popular in both academia and business world, as they support the
analysis and optimisation of business operations. It is a wide belief that the
application of WfMS improves organizational performance; in fact, it has been found
by Reijers and van der Aalst [43] that they decrease significantly the lead-, service-
and wait-time of business process execution, and increase the utilization of involved
human resources. Recognizing their increasing importance and the need for
standardisation, the Workflow Management Coalition was founded in 1993. Its
18
goal is to facilitate the use of workflow technologies across vendor products and to
develop standard architectures for workflow specification to allow the
interoperability by various WfMS [37].
19
2.5 Fundamental Business Process Modelling Language
(FBPML)
Fundamental Business Process Modelling Language (FBPML) is a visual modelling
language which is a merger of two recognised process modelling languages, PSL and
IDEF3. The combination of these two languages guarantees rich visual modelling
methods on the one hand and formal semantics (e.g. description of business processes
in logical sentences) on the other hand. This language is designed to support both
software and workflow system development, and it is characterised as standard,
accessible, collaborative, precise, executable and formal [7].
The notation of FBPML consists of main nodes, junctions, links and annotations. We
will now briefly describe each one of these points:
20
Main nodes:
Activity: denotes the type of process that may be decomposed or specialised
into subprocesses
Primitive Activity: denotes a leaf node activity that may not be further
decomposed or specialised
Role: describes the role that an enabler plays on the context of described
activities
Time Point: indicates a particular point in time during the enactment of a
process model
Links:
Precedence Link: places a temporal constraint on process execution (e.g. in
Figure 5 activity b may not start execution before the execution of activity a is
finished)
Synchronisation Bar: places a temporal constraint between two time points
(e.g. in Figure 5, the begin time of activity d should be synchronised with the
end time of activity c)
Junctions:
Start and Finish junctions: indicate the logical starting and finishing points of
a process
And and Or junctions: these can be fan-in (many-to-one relationship) or fan-
out (one-to-many relationship), as Figure 6 shows, and they can be broken
down to:
o And Joint: indicates that all of the preceding activities that have been
triggered must finish execution before the following activity can be
executed. So, if from activities A, B and C of Figure 6-a, A and B are
triggered, D can start execution once both A and B have finished
execution.
o Or Joint: indicates that only one of the preceding activities is required
to be triggered and finished before the following activity can be
executed. So, if from activities A, B and C of Figure 6-b, A completes
execution first (e.g. at timepoint T), D can start execution at T.
21
o And Split: indicates that all of the following activities (e.g. all B, C
and D of Figure 6-c) must be completed after the preceding activity
(here, A) is finished
o Or Split: indicates that at least one of the following activities (e.g. all
B, C and D of Figure 6-d) must be completed after the preceding
activity (here, A) is finished
To make the above clear, we will provide an explanation of the combinational use of
branching junctions, as these are shown in Chen-Burger et al [7], and based on our
experience with FBPML. The four different junction combinations can be seen in the
following figure, where each process is assigned a symbol of type 3 or X , which
denotes whether the process has been triggered (i.e. if it has been triggered and x if
not) and the time its execution finishes (e.g. 3).
3 3
1
1
X
5
2
2
3 3
1 1
5
5
X
7
In Figure 7-a an AND-AND junction can be seen, which means that all
processes B, C, D must finish execution (because of the and-split junction),
and E starts execution when all have finished execution (because of the and-
joint junction). So, for the example provided where all B, C and D are
triggered, and the maximum completion time is 7, E can start execution at 7.
An OR-OR junction can be seen in 7-b, and it denotes that at least one of the
processes B, C, D must finish execution (because of the or-split junction), and
E starts execution at the minimum completion time of one of them (because
of the or-joint junction). So, for the example provided where only B and D are
triggered, and only B finishes execution at time 3, E can start execution at 3.
Figure 7-c gives an example of AND-OR junction, which means that all B, C
and D must finish execution (because of the and-joint junction), but E starts
execution at their minimum completion time (because of the or-joint
junction). So, for the example provided where the minimum completion time
is 3, E can start execution at 3.
An OR-AND junction can be seen in 7-d, and it denotes that at least one of
the processes B, C, D must finish execution (because of the or-split junction),
and E starts execution when all triggered processes among B, C and D have
finished execution (because of the and-joint junction). So, for the example
provided where only B and C are triggered, and the maximum completion
time is 5, E can start execution at 5.
23
Annotations:
Idea Note: records textual information that is relevant to, but beyond the
scope of, a process model
Navigation Note: records the relationships between diagrams in a model
The three-layered business modelling approach has been developed in the Artificial
Intelligence Applications Institute of the University of Edinburgh, and it supports the
development of workflow systems from business process models and provides the
means to describe higher level business processes, objectives and policies [9]. The
three layers of the approach that can be seen in Figure 8, are described as follows:
The Business Layer describes business requirements of an organisation,
processes that are to be carried out by the organisation and relevant needed
information. The related documentation is higher-level descriptions that may
be formal or informal.
The Logical Layer expresses a logical description of business processes, so it
is a semi-formal business process model that describes business operations in
ordered activities.
The Implementation Layer gives detailed step-by-step algorithmic
procedure for software modules that implement processes described in the
logical layer.
24
Chapter 3
In this section we will move from the business layer of the Three-Layered Business
Process Modelling Approach, thus the textual description of Dells SC strategies, to
the logical layer; hence, we will illustrate the business process model (BPM) that we
have developed for Dell and how we came up with this model. First we have to make
clear that the BPM created involves Dell and does not show directly the business
processes along the whole supply chain. However, one can easily identify some basic
activities that involve cooperation with suppliers and customers, thus supply chain
management activities. Our BPM it shows all activities basic and supporting ones
that take place when Dell creates a computer for some customer, hence the whole
process in which Dell does business in order to create and sell a computer. Note
that we focus only on the creation of computers and not other Dell products such as
PDAs or digital cameras.
We have based our business process model on the MIT Process Handbook [60],
which has provided us with a generic BPM for Dell, called: Dell Create computers
to order [59]. The MIT Process Handbook was a challenging research project of the
Massachusetts Institute of Technology in the 90s that took about 10 years to be
completed. The projects basic aim was to develop a comprehensive framework for
organizing large amounts of useful knowledge about business. With respect to this
approach there are three primary kinds of entries in the Handbook: (1) generic
models of typical business activities (e.g., buying, making, and selling) that occur in
many different businesses, (2) specific case examples of interesting things particular
companies have done, and (3) frameworks for classifying all this knowledge [35]. As
stated by the project members [35], the result of this work is an on-line process
handbook which can be used to help people: (1) redesign existing business
processes, (2) invent new processes (especially those that take advantage of
25
information technology), and (3) organize and share knowledge about organizational
practices. In our case, it is the last contribution of the Handbook that has been of use
to us.
As we have already mentioned, the MIT Process Handbook provides us with generic
business processes, as well as with specific processes of companies such as Dell. In
the figures below we can see a sample entry of a generic process, buy, as shown in
the Handbook, and a process specific for Dell, Identify potential customers in
custom channel {Dell}, respectively. As one can notice, every process entry in the
handbook includes the following information about the process:
name (or the title of the process)
description: this can be short or long, depending on the importance of relevant
information; it explains what the process involves as well as how some
processes are being executed; especially in the case example processes,
supplementary interesting information is included such as historical data,
sources and links to other web pages.
parts: the subprocesses are given, without however any defined sequence,
hence as a list. These parts may include subparts, some of which may in turn
include further subparts. The full decomposition can be extracted by
navigating through the process handbook.
properties: date of last modification of the process entry
related processes: these include specializations and bundles (processes that
show how a process can be done or what the object of the process is,
respectively, hence all other ways that the same processes can be done), uses
(all other processes that use the described process) and generalizations (all
other processes that are like the described process)
26
Figure 9: Sample entry of the MIT Process Handbook for buy
Figure 10: Sample entry of the MIT Process Handbook for Identify potential
customers in custom channel {Dell}
27
3.1 Dell BPM The MIT Process Handbook version
We will now briefly describe the BPM that the MIT Process Handbook has
developed for Dell. The full version can be found in [59].
0
Create
computers
to order
1 2 3 4 5
Design Buy standard Configure to Sell using Manage
product and item to stock order using customized as a
process internet sales channel creator
The above figure shows the decomposition of the basic Dell process, Create computers to
order. Note that no sequence is implied by the Handbook, but only the parts of the parent
process are given. Hence, in this case, the subprocesses of create computers to order are:
design product and process, buy standard item to stock, configure using internet, sell using
customized sales channel, and manage as a creator, but no sequence is specified. So,
according to the MIT Process Handbook, in order to create a computer to order, Dell needs
to have already designed the corresponding product (as well as the manufacturing process)
and bought the needed components from its suppliers; the order is configured through
Dells web site and the computer is sold to the customer (here implied a corporate
customer) via a customized web site called Premier Page. Throughout the whole process,
Dell manages as a creator (this involves general business tasks, such as strategy, and
managing resources and relationships). We should make clear that the numbering of the
processes above does not imply any sequence between the processes, but it has been
introduced for matters of ease (especially for decomposition); the same holds for the
numbering of all the processes of the MIT Process Handbook version that follow.
28
Further decomposition of each subprocess can be seen below:
1.3.1 1.3.2
Develop the Develop the
characteristics of process of
a product/ producing a
service product/service
Figure 12: Decomposition of Design product and process (MIT Process Handbook)
The process design product and process consists of 3 parts, as shown above, and
has as a result the identification of the product design and the corresponding
manufacturing process. What is interesting here is that there is integrated product and
process design, meaning that the process and the product are designed in parallel. As
far as the parts are involved, we should mention the following: The identification of
needs or requirements can be done from the view of either the consumer or the
producer, and it involves the specification of the usability parameters of a resource.
The product capabilities are identified such that the product will be usable by the
consumer. Also, the process develop product and process design is further
decomposed into 2 subparts, as shown in the figure above.
2.1 2.2
Identify Identify 2.3 2.4 2.5 2.6 2.7
potential own Place order Receive Select Pay Manage
sources needs supplier suppliers
2.7.3
2.7.1 2.7.2
Manage
Evaluate Manage
supplier
suppliers supplier policies relationships
Figure 13: Decomposition of Buy standard item to stock (MIT Process Handbook)
29
According to the MIT Process Handbook, buying a standard item to stock is done
always in advance of a particular need or custom requirement of a particular
instance [60]. So, in the case of Dell, and according to the MIT Process Handbook
(note that in section 3.3 we will not agree with the Handbook for this process), the
company buys standard items (usually of low cost) and keeps them as inventory in
order to use them at the computer assembly procedure some time later. The process
buy standard item to stock consists of 7 parts, which can be seen above. (Note that,
as mentioned above, the numbering does not imply any ordering between the
processes, but it is set according to the order the processes are listed in the
Handbook.) So, in order to buy standard items to stock, Dell needs to identify a need
for some item, identify the potential sources for this item, choose a supplier, place an
order, receive it and pay for it; in the meantime, Dell also manages the supplier for
this item, meaning that it manages the supplier policies and their relationships and
evaluates them. Dell configures its customers orders using the internet, as all
relevant information is obtained by its web site, Dell.com, where customers place
their orders. The MIT Process Handbook does not suggest any further decomposition
for this process.
The MIT Process Handbook treats the next process, sell using customized sales
channel as of great importance in the case of Dell, thus Dell-specific, while all the
other processes we have already mentioned are generic processes that hold for the
Dell case. Dell uses the Internet as its basic sales channel, and it has created
customized web sites for its big clients, the Premier Pages (we have covered these in
section 2.2).
In Figure 14 we can see the parts of this process. So, in order to sell computers using
the Premier Pages, Dell needs to identify potential customers (here implied corporate
customers and individual customers within these organizations, such as employee
groups) and their needs, inform them about the different possible PC configurations
and prices, obtain an order from a customer and the corresponding payment and
deliver the ordered product; in the meantime Dell manages its customer relationships.
As we have mentioned in section 2.2, the use of Premier Pages, and
30
thus online customized sales and support, differentiates Dell from other PC
companies and provides a competitive advantage.
4.1.1 4.1.2
Identify potential Identify potential
corporate individual
customers customers
Figure 14: Decomposition of Sell using customized sales channel {Dell} (MIT
Process Handbook)
31
5.2 5.3 5.4
5.1
Manage Manage Manage other
Develop
resources by learning and external
strategy type of resource change relationships
5.4.1.1 5.4.1.2
Manage tax Manage legal
and duty compliance
compliance
Hence, if we wish to have an insight into Dells supply chain strategies using a BPM,
we get little/incomplete information from the given BPM from the MIT Process
Handbook. So, our next step is to use the model we have presented in the above
section in order to create a new version that incorporates sequence. The decision
on the sequence between processes will be made based on relevant literature
concerning Dell, as well as on known general business practices. However, it is
beyond the scope of this section to provide detailed justification for the sequence
between every business process pair.
Before presenting our sequenced MIT Process Handbook version of Dells BPM, we
should mention that in some cases the numbering of the processes of the earlier
version has changed. This happens because in the last version we introduced numbers
in the processes (these were not part of the Handbook Dell case) for matters of ease,
hence these do not imply any sequence. However, in this section, where process
sequence is introduced, numbering does actually have some meaning concerning
sequence. Since in our previous version the numbers of the processes were defined
based on the order of the processes in the parts list, it is commonsense that this order
may not match the sequence of the processes in the BPM, resulting into a change of
numbering.
In Figure 16 we can see the decomposition of the basic Dell process, Create
computers to order after taking ordering into account. In order to decide on the
33
sequence between the five processes, we have considered the case of creating one
computer to order, thus design one product (one computer in our case) and process,
buy standard items needed for the assembly of this computer, configure one order for
the specific computer, sell it and manage as a creator (of this product). In order to
create a computer to order, the first step is to design the corresponding product and
process (process 1). Once the product and the manufacturing process is designed,
Dell can start the procedure for its physical creation and sale (processes 2, 3 and 4),
but also it has to start managing as a creator in order to succeed (process 5). Hence,
after process 1 we have an AND-junction that indicates that process 5 takes place
concurrently with processes 2, 3 and 4. After Dell buys the needed items to stock
(process 2), it configures an order for this product (process 3) and after the
completion of this procedure, Dell can sell it using its customized sales channel
(process 4). As already explained, Dell has to manage as a creator in the meantime
(process 5).
The sequence of the parts of process 1, Design product and process, is quite trivial:
In order to design a product and its manufacturing process, Dell first has to identify
the needs or requirements that this product will fulfil. Then, and based on those
needs, the product capabilities are defined, and finally the product and process design
is developed by taking into account the previous two steps. Hence, the three
processes, 1.1, 1.2 and 1.3, are sequential.
34
Figure 17: Decomposition of Design product and process (Sequenced MIT
Process Handbook version)
35
reason: Once a supplier is selected for the needed item, an order is placed, then the
requested items are received and finally Dell pays for its order to the supplier (pay
could actually precede receive, but we have assumed that Dell first receives and then
pays for its orders, at least for the current version of our BPM).
Now we will explain the sequenced version of the decomposition of process 4, Sell
using customized sales channel, which can be seen in Figure 21. At the first glance it
reminds us to some extent the sequenced version of process 2, Buy standard item to
stock. Like in process 2, most of the parts of process 4 are sequential, except for
36
4.7, which involves managing (just like 2.7) and takes place at the same time with
some other parts. In a few words, the sequenced version of the decomposition of
process 4 has as follows: In order to sell using its customized sales channel, Dell
needs first to identify potential customers (process 4.1); once these are identified two
processes start execution: manage relationships with these customers (process 4.7)
and identify potential customers needs (process 4.2). Once potential customers
needs are identified, they are informed about the product range and prices (process
4.3) and then orders are obtained from the customers (process 4.3). The next step is
to receive the payment from the customers and only after this is completed will Dell
deliver the ordered product.
The first subprocess of sell using customized sales channel, Identify potential
customers in custom channel (process 4.1), is further decomposed, as the following
figure shows. The sequence of its two parts is sequential, as Dell first identifies
potential corporate customers (process 4.1.1), such as Boeing, and then identifies
potential individual customers within the corporate customers (process 4.1.2), usually
the employees of the customer organization (e.g. managers, purchasing agents and
end users in Boeing).
37
Figure 22: Decomposition of Identify potential customers in custom
channel (Sequenced MIT Process Handbook version)
38
Figure 24: Decomposition of Manage resources by type of resource (Sequenced
MIT Process Handbook version)
39
Similarly, the two subprocesses of Manage regulatory relationships (process 5.4.1)
are parallel, as there is no dependency between them.
40
3.3 Dell BPM The enriched version
First it is still too generic for such a specific focus area as supply chain management.
As it is completely based on the MIT Process Handbook, many of the parts of Dell
Create computers to order are not Dell-specific but generic, thus they are used in
many other case examples. For instance, the process buy standard item to stock
(process 2) is generic and does not reflect how Dell cooperates with its suppliers in
order to buy standard items; this is even more obvious with its part receive (process
2.5), as it does not show any of the relevant interesting findings from our literature
review (e.g. the case where Dell does not receive the items at its plant, but it gets
them from the suppliers plant). This fact shows another weakness of the current
BPM: it is sometimes too high-level, thus leaving out interesting information for
Dells supply chain strategies.
Third, considering the literature about Dells supply chain strategies, there seem to be
some mistakes in MIT Process Handbooks Dell case. The most important one is the
fact that Dell does not, in general, buy to stock but it buys to order. This is a key issue
for Dells cooperation with suppliers and organization of assembly preparation, and a
very important point in Dells SC strategies. However, according to the MIT Process
Handbook (process 2), Dell buys standard items to stock, which seems to be an
important mistake.
There also seems to be an important gap in the MIT Process Handbook business
process model, thus the manufacturing/assembly process of computers is not
thoroughly treated, as it is not further decomposed. However, this is an important
process for Dell, and the way Dell goes about it demonstrates Dells ability towards
speed and combination and alignment of supply chain strategies with manufacturing;
therefore, it would preferred to present computers assembly in a more detailed way.
41
Another gap results from the focus on corporate customers that the MIT Process
Handbook has adopted; however, we believe that customer segmentation is an
important aspect and should be incorporated in the final BPM.
Last, because of the high-level approach of the MIT Process Handbook, the resulting
BPM is, in some cases, too simplistic. For example, it seems to consider only the
case where no errors occur (no exception handling) and it does not take into account
several decisions that may have to be met (e.g. what happens when a during some
product design it turns out that this product is not profitable for Dell?).
We will now move on to the presentation and explanation of Dells enriched business
process model, which is the final version for our project.
42
In Figure 27 we can see the decomposition of Create computers to order. If we
compare it with the corresponding figure of the sequenced-MIT Process Handbook
BPM (Figure 16), we will see that they differ. Even though the previous Create
computers to order decomposition may seem more logical and understandable, the
new version had to be changed because of the different decomposition of each
subprocess. This means that the processes 2, 3 and 4 are interleaved (e.g. Dell
receives an order from a customer (process 4), suppliers provide Dell with needed
inventory (process 2) and computers are assembled according to customers order
(process 3), then extra needed items, such as monitor, may be received from a
supplier (process 2), and finally the order is delivered to the customer (process 4)),
and thus they are executed in parallel.
The decomposition of Design product and process has been enriched and it now
contains a process for feasibility and profitability checking (process 1.4): If the
product to be designed seems unprofitable or not feasible to manufacture, then its
design should be abandoned (this explains the arrow to finish in the figure below).
Also we distinguish two alternative cases for needs or requirements identification:
Customers requirements may involve a new product (process 1.2) or an already
existing product (process 1.1).
43
Figure 28: Decomposition of Develop product and process
The composition of process 1.5 is the same as in the previous version of Dells BPM,
as the following figure shows.
Figure 29: Decomposition of Develop product and process design (Enriched version)
The process Buy standard item to order has replaced our previous Buy standard
item to stock and it is very important for Dells supply chain strategies. As Figure 30
shows, the procedure begins with the identification of Dells needs on some item
(process 2.1), then potential suppliers are identified (process 2.2), from which one is
selected (process 2.3), and then contracts and the replenishment environment are
44
negotiated (process 2.4). This is an important step, as Dell needs to make sure that its
cooperation with the supplier will be as wished, and that the supplier will agree on
Dells high expectations. After the completion of this step two processes start
execution: suppliers managing (process 2.8) and information sharing (process 2.5).
Process 2.5 has been introduced, as information sharing between Dell and its
suppliers is the cornerstone of their successful cooperation. Based on this information
sharing, suppliers provide inventory to Dell (process 2.6) based on Dells demand
forecasts and the level of inventory. Finally, the suppliers are paid (process 2.7).
Below the decomposition of Share info with supplier is shown. Its three
subprocesses are executed concurrently and they involve: Sharing real-time info that
involves the level of inventory and real-time orders via Value Chain (process 2.5.1),
sharing demand forecasts (process 2.5.2) and sharing general business information
(process 2.5.3). The latter has to do with information of general business or product
interest, such as the existence of new trends in the market (e.g Sony could inform
Dell about high-selling monitors or Dell could let Intel know about the requirements
of its big customer from processors).
45
Figure 31: Decomposition of Share info with supplier (Enriched version)
As we have already mentioned, real-time info exchange involves inventory levels and
end customer orders. This can also be seen in the following figure that shows us the
decomposition of process 2.5.1, Share real-time info via Value Chain. Its two
subprocesses are executed in parallel.
Figure 32: Decomposition of Share real-time info via Value Chain (Enriched version)
The decomposition of process 2.6, Get inventory from supplier, which can be seen
in the Figure 33, is different from our previous version of Dells BPM. Here we
distinguish two alternatives: inventory may be received in Dells plant (process 2.6.1)
(this is the case where Dells supplier delivers inventory without waiting for a
specific order from Dell) or Dell may place an order (process 2.6.2) and get the
46
inventory from the suppliers plant (process 2.6.3). The latter covers the case of
standard items that are not required for plant assembly, such as monitors.
Manage supplier is similar to our previous version of Dells BPM, with the only
difference that process 2.8.2, Provide feedback and support has been introduced
after Evaluate supplier. This is an important process of Dells cooperation with its
suppliers, as it helps them reach Dells high standards and improve their
performance. So, Dell gives its suppliers detailed feedback on their performance
according to a scorecard, and they are supported to overcome difficulties or further
improve themselves.
47
Now we will show how process 3, Build to order, is decomposed. First components
that are required for plant assembly are identified and get (process 3.1), then the
hardware is assembled in Dells plant (process 3.2), and standard software is loaded
(process 3.3). Then either customer specific software is loaded (e.g. some helpdesk
software specific for a British Airways) or we move on to product testing (process
3.5). In the first case, the product is also tested after customer-specific software
loading. If the tested product is in good condition, we move on to packaging (process
3.6); otherwise, we return to process 3.1 and start product assembly once again. If the
product that is being built contains items that do not need to be assembled in Dells
plant, such as monitors, Dell can get them from the suppliers plant (process 3.7), in
order to match them later with all the other order components (process 3.8). The
whole procedure is completes after the different order components are matched.
Another important process for Dells supply chain strategies is Sell directly
(process 4). In this version we distinguish two customer segments, and thus two
alternatives: selling directly to small customers (process 4.1), thus home and small
48
business customers, and selling directly to big customers (process 4.2), meaning
large business and public sector customers.
Figure 37 shows the decomposition of process 4.1, Sell directly to home and small
business customers. The whole procedure begins with the identification of customer
segments (e.g. high-tech small business, students, etc) (process 4.1.1) and their needs
(process 4.1.2). Based on these needs, Dell identifies appropriate and valid computer
configurations (process 4.1.3) and informs the customers about them (process 4.1.4).
After this step is completed, two processes start execution: managing home and small
business customer relationships (process 4.1.5) and the ordering procedure, which
includes processes 4.1.6, 4.1.7 and 4.1.8 sequentially.
49
Process 4.1.5 is further decomposed in two parallel subprocesses, Support home and
small business customers (process 4.1.5.1) and Get feedback from home and small
business customers (process 4.1.5.2), as Figure 38 shows.
These are further decomposed, as the following two graphs show. Home and small
business customers are offered technical support (process 4.1.5.1.1) and customer
service (process 4.1.5.1.2) via Internet and phone. Dell also gets feedback from them
about their customer experience (process 4.1.5.2.1) and general feedback about its
products and business performance (process 4.1.5.2.2) through forums and blogs,
such as Direct2Dell and IdeaStorm.
50
Figure 40: Decomposition of Get feedback from home and small business
customer (Enriched version)
Now we will present how process 4.2, Sell directly to large business and public
sector customers, is decomposed. As the figure below shows, the decomposition is
very similar to the one of 4.1, Sell directly to home and small business customers,
so there is no need to explain it in detail.
Figure 42 shows how process 4.2.1 is decomposed. So, in order to identify potential
corporate customers, Dell needs first to identify key personnel of the potential
corporate customer (process 4.2.1.1), such as IT manager, and then identify employee
groups within the customer (process 4.2.1.2), such as helpdesk personnel, managers
and end users.
51
Figure 42: Decomposition of Identify potential corporate customers (Enriched version)
Management of large business and public sector customers involves offer of support
(process 4.2.8.1) and getting feedback from them (process 4.2.8.2), which take place
in parallel. These two processes are further decomposed, as the following figures
show. The support that is offered to big clients is distinguished into technical
support (process 4.2.8.1.1), customer service (process 4.2.8.1.2) and general business
support (process 4.2.8.1.3), and they are offered via Premier Pages, phone, Account
Team and Platinum Councils. As in the case of small customers, the feedback that
Dell gets from its big clients involves customer experience (process 4.2.8.2.1) and
Dells products and business practices (process 4.2.8.2.2).
52
Figure 44: Decomposition of Support large business and public sector
customers (Enriched version)
53
Figure 46: Decomposition of Manage as a creator (Enriched version)
54
Figure 48: Decomposition of Manage other external relationships (Enriched version)
Workflow Engine
In this section we will describe the workflow engine that has been developed in
Prolog in order to create an executable version of Dells BPM. It is business context
sensitive, meaning that it calculates the total time of a business processs execution,
as well as the total cost involved. Our workflow engine does not do any validation or
verification, as we assume that the BPM provided is correct; instead, it focuses on
measuring business goals expressed in terms of time and cost, as this information is
important in order to argue about supply chain strategies.
The idea behind the workflow engine implementation can be summarized in the
following three sentences: The workflow engine is initialized by the model and
process specification, and after the event and entity database is loaded, the BPM
execution begins. The BPM runs in a forward chaining manner and keeps an explicit
time record; so in each timepoint actions may be executed, junctions may be reached
and processed, and processes may start execution. When there are no more processes
to be executed, the BPM finishes execution and provides us with information about
the total cost and time.
In order to make the above description clearer, we will first describe the design
decisions and the assumptions we have made, as well as some interesting issues in
workflow engine creation. We will continue with the discussion about the logical
representation of the business process model for execution, such as model and
process specification, and the entity and event database representation. Then we will
explain the workflow engine algorithm and some important relevant points. Finally
we will draw interesting conclusions concerning the workflow engine creation and
use, and we will show examples of its actual use.
56
4.1 Workflow engine design and assumptions
57
Since we are only interested in the simulation of the usual and correct business
process model, there is no actual need for validation or verification. After all, why
check the correctness of a BPM if we already know it is correct? So, our workflow
engine does not provide validation or verification, as there is no need for this, under
the assumption that the provided BPM is correct. The logical path that led us to this
assumption can be seen in Figure 50, coloured in violet.
Additionally, reasoning about business strategies has another impact on the use and
design of the workflow engine: In order to analyze and compare different strategies
through BPM execution, one should reduce the business operations (and the
corresponding time and cost) to the single case. For example, if we want to
compare the computer assembling procedure of two companies, such as Dell and
IBM, then it makes more sense to compare the time and cost related with assembling
one computer. This design requirement has two implications: First, that the modeller
should already know the cost and time of each single case business process and
second, that there are no other needed variables for the workflow engine apart from
the time and cost of each process. Hence, other variables like number of suppliers, or
proportion of big and small customers, are beyond the scope of our workflow engine.
The biggest part of the workflow engine design conceptualisation involves general
and standard workflow engine issues. Since the workflow engine will be used to
make a BPM executable, it will have to conform to some general workflow engine
requirements. This means that it will have to be able to execute processes, keep
track of the workflow state (e.g. know which processes have been executed so far),
understand the current world state (e.g. know which entities and data hold at each
timepoint) and update it according to the actions executed, and give some feedback to
the user about the business process execution results. To make this clearer, some
general requirements for our workflow engine are the following:
i. Understand the business process model, hence understand and execute the
different junctions of the model.
ii. Understand the definition of business processes and execute them according
their special conditions (trigger conditions, preconditions, etc.) and the
current world state.
58
iii. Understand and update the current world state according to the actions and
processes executed.
iv. Keep track of the workflow state, thus remember which junctions have
been reached and which processes have been executed.
v. Inform the user about the business process execution status.
The first requirement means that junction definition has to be formally specified, so
that it is understandable by the workflow engine. Since we have used FBPML for
Dells business process model, our workflow engine will also be based on FBPML
for junction definition and execution. So, it should understand what the start and
finish junctions signify, and distinguish between and-split, or-split, and-joint
and or-joint junctions, and execute them according to their definition. (This topic is
covered thoroughly in 4.2.1.)
Similarly, the second requirement means that processes have to be formally defined.
This definition should include data important for their execution, such as trigger
conditions, preconditions and actions they invoke.
In order to make the executable version of a BPM realistic, we should incorporate the
description of the world in our workflow engine. Since the world changes according
to the workflow state we are in (e.g. what processes and actions have been executed),
our workflow engine should be able to update the world state accordingly.
The last requirement is actually imposed from the user-side, as the users of a
workflow engine need to know real-time what is happening during business process
simulation. So, after starting BPM simulation, it would be useful to provide
information such as current timepoint and workflow state; it is also essential to
inform the user when the BPM execution is completed and the total cost involved.
59
MISSION
Executable Business context
-Implementation -Measure time and cost
layer -Realistic, real- -Support analysis about
time behaviour different strategies
DESIGN CONCEPTUALISATION-
REQUIREMENTS
GENERAL SPECIFIC
-Model and execute junctions -Calculate the total time and
-Execute processes cost for a BPM execution
-Represent and update the -Model only the normal case
world state -Model only the single case
-Control the workflow state
-Give feedback to the user
ASSUMPTIONS
-The BPM provided is correct.
-Junctions connect only processes between them, hence no
junction is connected with another junction except for the case
where a start or finish junction is involved.
-Each process can execute only once.
-There is prior knowledge about events occurrence.
-The minimum process duration is 1 and the minimum cost is 0.
DESIGN DECISIONS
-Forward vs. backward chaining
-Simplistic vs. sophisticated treatment of waiting time
-Explicit vs. implicit time measurement
-Implicitly vs. explicitly treat junctions
-Which junction cases covered?
-Deterministic vs. non-deterministic occurrence of events -Treat
a process branch as a block vs. as a sequence of processes
-Dynamically update vs. keep track of world state for each timepoint
60
All the above-mentioned requirements can be seen in Figure 50, which presents how
the purpose and mission of the workflow engine affects its design conceptualisation
and requirements, as well as some assumptions that are related to them.
61
has to do with external factors. When such processes are executed in parallel with
other processes, then it may become difficult to calculate the starting time of some
process following them (see Appendix A for a thorough analysis). So, here arises the
question of how we want to deal with such waiting time in a simplistic or a
sophisticated way? Since one of the basic requirements of our workflow engine is to
measure time, we have decided to adopt a more sophisticated and flexible
approach. This means that we will estimate process starting time by taking the
corresponding waiting time, if any, into account, and not by neglecting it, as the
simplistic approach would suggest.
Explicit time measurement and real time BPM execution vs. estimation of
start and finish time
Another crucial design decision is how to treat time in BPM execution: implicitly, by
estimating each processs start and finish time, or explicitly, by representing the
world and workflow state in each timepoint? Even though the second option may be
more costly in the case of processes with long duration, it actually turns out that it
guarantees a more precise and correct process start time estimation, especially in case
we want to model the waiting time for some process (see Appendix A). Since we
have decided to treat waiting time in a more sophisticated way, we are obliged to
measure time explicitly throughout BPM execution.
62
inventing a new junction which is actually a combination of the two, thus a
start/and, a start/or, a finish/and and a finish/or junction (this topic is
covered thoroughly in section 4.2.1). So, the corresponding assumption is that
junctions connect only processes between them, except for the case where a start or a
finish junction is connected to some other junction.
Process instantiation
Most workflow engines require a process to be instantiated in order to be eligible for
execution, and we will adopt this approach as well. We will regard a process to be
instantiated when it is reached through the workflow state, thus when the junction
preceding it has been reached and processed. Then, this process instance may be
checked for the special conditions (trigger conditions and preconditions) that specify
whether it can start execution. Note that for matters of ease we will assume that each
process can be instantiated and executed only once, thus our workflow engine will
not provide any loop-handling.
63
of a process branch. Such an example BPM can be seen in the following figure,
where the process branch includes processes p1, p2 and p3.
In such cases arises the question of how to treat the process branch: as part of a block
of processes, where they are either all executed or none, or as a sequence of
independent processes, where the execution of one process does not directly depend
on the execution of the other? The block approach would mean for the above
example that the or-joint junction is reached only if all processes p1, p2, p3 and p4
are executed, while the process sequence approach would mean that the or-joint
junction is reached when one of p3 or p4 finishes execution. In order to simplify the
description of the process model for our workflow engine, as well as the algorithm
itself, we will adopt the process sequence approach. However, one should keep in
mind that the processes of the same branch are not completely independent (see
Appendix A for further analysis), e.g. the trigger condition of the last process, here
p3, is related to the execution result of the preceding processes, here p1, p2.
Dynamically update world state vs. track world state for each timepoint
As we have already mentioned, a process can start execution at some timepoint T if it
is already instantiated (at some timepointT), triggered (at some timepointT) and its
preconditions hold at T. But then arises the question of how to check for
preconditions, hence how to treat the representation and update of the world state:
dynamically update it or keep track of the world state for each timepoint? The choice
of dynamic update means in concrete that the predicates that represent the world state
are dynamic, and hence they can be inserted or deleted from our database without
keeping track of the world state history. Such a choice seems to agree with the
explicit time measurement that we have decided. On the other hand, one could argue
64
that keeping track of the world state history (e.g. keeping a database where the world
state is given for each timepoint throughout BPM execution) would give us better
control over BPM simulation. However, such a decision could be costly, especially if
the duration of the BPM execution is long. Therefore, we will dynamically update
the world state instead.
Now that the workflow engine design and assumptions have been decided and
explained, we can move on to the logical representation of the executable business
process model. This formal specification is necessary for the workflow engine to
understand the BPM and proceed to its execution. So, it can be seen as a
convention to which the potential user should conform whenever our workflow
engine is to be used for a BPM simulation. The specification of the logical
representation includes the following: junctions, processes, world state (data and
entities) and events.
65
4.2.1 Junction representation
When one decides to use the workflow engine in order to run a BPM, he first has to
identify the process model by specifying how the several processes are connected
with each other, thus describe the junctions of the BPM. The standard predicate for
describing a junction is the following:
So, a junction is specified by its type (which can be start, finish, link, and-
split, and-joint, or-split or or-joint), the list of the processes preceding it and
the list of the processes following it, where the processes are specified by their ID
(this is covered in the next section). The process model below includes some example
junctions to be modelled, and its specification is following.
66
Model specification of junction-followed-by-junction in our workflow engine
To make things even clearer, let us repeat that the finish_and junction above,
behaves as a finish and as an and-joint junction at the same time, thus only when both
p1 and p2 finish execution is the junction hit, indicating the end of the BPM
execution.
67
4.2.2 Process representation
In order to use the workflow engine to run a BPM, all involved processes must first
be described, so that their characteristics (e.g. preconditions) are known. The process
specification should be included in a separate file where each process is described by
the following predicate:
process(s4, urgentlySendComputerInBag,
[exist(event_occ(needCompBag)),
exist(event_occ(urgentNeedComputer))],
[exist(entity_occ(computer)), exist(entity_occ(computerBag)),
exist(data(addressToShip))], [create_data(computerInBagSent,
[time_today])], 8, 80).
process(pr2, discussWithBoss, [true], [], [], 1, 0).
The Action variable specifies the list of actions that are fired by a process as we
have already mentioned in 4.1.3, the different types of actions that are supported by
our workflow engine are create entity, create data, delete entity and delete data.
Duration is the (average expected) duration of the process and Cost is the (average
expected) cost of the process. We should note once again that each process has
duration of at least 1, while the minimum cost allowed is 0.
68
4.2.3 World state representation
When executing a BPM we somehow need to know what our current world looks like
at each timepoint. For instance, in the case of Dell, which are our suppliers, or what
information is there in our database about our customer X? Hence, we need to know
what entities exist in some state and what data there is in the organizations database
in some timepoint. Since the current state may change (e.g. new entities or data may
be created or deleted), and bearing in mind that we have decided to update the world
state dynamically, the predicates describing entities and data are defined as dynamic.
:- dynamic entity_occ/3. :-
dynamic data/3.
An entity occurrence is described by its name and ID, as well as its attributes. The
EnitityAttribute variable is a list of attribute names and values of the entity (in the
form attrname_attrvalue). Below a standard entity specification and an example is
provided.
event_occ(EventId, EventName, T)
69
4.3 Workflow engine creation
Now that we have presented the workflow engine design and assumptions, and the
logical representation of processes, junctions, events and the world state, we can
move on to the explanation of the main points of the workflow engine creation.
Process model
Modellers
conceptualizations
Notation explanation
: static junction
and process model
World state Workflow state
: instances for
organizations
world state (Dell)
Processes executed
: process
Junctions reached
data instances executed,
entity event junctions reached
Current state
(dynamic)
Figure 53: Relation of workflow engine with model, process and entity specification
As the figure above shows, the workflow engine uses both the static modellers
conceptualization, thus junction and process specification, as well as the dynamic
world description, meaning workflow state and world state, in order to check through
all the possible processes for execution. In fact, the algorithm takes each process of
the BPM and by checking the current state (what processes have already been
executed, what processes are pending, which junctions have been reached, as well as
70
what entities and data currently exist in the world) and bearing in mind the processs
preconditions and trigger conditions (specified by the modeller), it decides which
processes can be executed at the current timepoint.
The main workflow engine algorithm is to be seen in Figure 54, and it can be
summarized as follows: In every step there are three main tasks carried out by the
algorithm: execute actions, execute junctions and execute processes. The execution of
actions modifies the current state of the world (data and entity_occ). Junctions are
executed if their type is satisfied (e.g. an or-junction is executed if there is at least one
preceding process that has been triggered and executed), and these executions create
the so-called model instances, which are actually instances of the post-processes.
Then, processes are executed if they already have a model instance created, if they
have already been triggered and if their preconditions hold. When a process is fired
for execution, its completion time is calculated and stored in an agenda
(CompleteProcessAgenda) and its actions are scheduled for its completion time
(ActionsAgenda). At the end of each step (where time is updated), it is checked
whether we have reached the end of the execution of the BPM. If yes, then we stop
and calculate the total cost involved. Otherwise, we move to the next step.
7
1
Process Model specification
World
Process Junction description
specification specification (data, entity,
event)
Workflow Engine
Execute action(s)
Actions
Execute process(es)
Agenda
Complete Process
Update time T=T+1 Agenda
static specification
repository
72
To make the above clear, we will show the flowchart for the following simple BPM,
where:
p1 p2
Start Finish
- -
T=0 T=1
ActionsAgenda=[] ActionsAgenda=[create car, 1]
Execute actions: - Execute actions: create car
SofarCompletedProcesses=[] SofarCompletedProcesses=[p1]
Execute junctions: start Execute junctions: link
ModelInstances=[p1] ModelInstances=[p2]
Execute processes: p1 Execute processes: -
CompleteProcessAgenda=[p1,1] CompleteProcessAgenda=[]
ActionsAgenda=[create car, 1] ActionsAgenda=[]
END
T=2
T=3 ActionsAgenda=[]
ActionsAgenda=[create carMatch, 3] Execute actions: -
Execute actions: create carMatch SofarCompletedProcesses=[p1]
SofarCompletedProcesses=[p1,p2] Execute junctions: -
Execute junctions: finish ModelInstances=[p2]
ModelInstances=[] Execute processes: p2
Execute processes: - CompleteProcessAgenda=[p2,3]
CompleteProcessAgenda=[] ActionsAgenda=[create carMatch, 3]
ActionsAgenda=[]
Figure 55: Flow state of the execution of a simple BPM using our workflow engine
In the above figure we show what happens (what is executed, coloured in violet) and
what holds in our database (all the different agendas and lists that we keep in
73
memory for our convenience, coloured in grey) in each timepoint. The reader is
expected to be able to follow the flow state, so we will not explain it any further. We
should mention, however, that this is an abstract and quite simplified view of what
takes place in our workflow engine when it is loaded with such a BPM.
We will now present and explain some important parts of the workflow engine code.
The predicate execute_step is the one that controls the flow of the BPM execution. A
step corresponds to one time point, in which three things may happen: actions can
execute, junctions may be reached and executed or processes may start or finish
execution. The execute_step goal presented here is a simplified version of the actual
one, which can be found in Appendix B, and it reflects the flowchart of Figure 54.
execute_step(PreviousActAgenda, JunctionsPending,
PreviousJunctionsExecuted, PreviousModelInstance, ProcessPending,
PreviousProcessExecuted, PreviousCompleteProcessAgenda, T):-
execute_actions_agenda(PreviousActAgenda, T),
findall(P,(
member([P,CompletionTime],PreviousCompleteProcessAgenda),
CompletionTime =< T), CompletedProcessTillNow),
execute_junction_pending(JunctionsPending,PreviousJunctionsExecuted,
NowJunctionsExecuted, PreviousModelInstance, NowModelInstance,
CompletedProcessTillNow, T),
execute_process_pending(ProcessPending, PreviousProcessExecuted,
NowProcessExecuted, PreviousActAgenda, NowActAgenda,
PreviousCompleteProcessAgenda, NowCompleteProcessAgenda,
NowModelInstance, T),
update_time(T, NewT), difference(JunctionsPending,
NowJunctionsExecuted, NewJunctionsPending),
difference(ProcessPending, NowProcessExecuted, NewProcessPending),
execute_step(NowActAgenda, NewJunctionsPending, NowJunctionsExecuted,
NowModelInstance, NewProcessPending, NowProcessExecuted,
NowCompleteProcessAgenda, NewT).
As the flowchart of Figure 54 illustrates, the BPM finishes execution at the timepoint
when all of the following hold:
i. the finish junction is hit
ii. there is no process on execution (no process that has already started execution
is now waiting to complete execution at some point later)
iii. we are not waiting for some event that will trigger a process of which we
already have a model instance
iv. all post-processes of reached and-split junctions have been successfully
triggered and executed
74
The first two conditions are trivial to understand, as we cannot say that a BPM has
successfully finished execution if we have not reached the finish junction or if a
process is still on execution (e.g. if a process that started execution at timepoint 3 will
finish at timepoint 7, and we are currently at timepoint 5, we cannot say that the BPM
has completed execution). Condition iii) deals with the case where an event is
expected to occur at some later timepoint and this event will trigger a process of
which we have a model instance, and hence could start execution. The importance of
this case has to do with our sophisticated way of treating waiting time, and it is
further explained in Appendix A. Condition iv) has to do with the special case of and-
split junction specification, and how this affects the BPM execution completion (for
further analysis see Appendix A).
Bearing these conditions in mind, the base case of execute_step is easy to understand:
execute_step(_ActionsAgenda, _JunctionsPending,
PreviousJunctionsExecuted, PreviousModelInstance, _ProcessPending,
PreviousProcessExecuted, PreviousCompleteProcessAgenda, T):-
(member(junction(finish,_LastProcess,[]),PreviousJunctionsExecuted);
member(junction(finish_and,_LustProcess,[]),
PreviousJunctionsExecuted);
member(junction(finish_or, _LasstProcess, []),
PreviousJunctionsExecuted) ), findall(P,
(member([P,CompletionTime],PreviousCompleteProcessAgenda),
CompletionTime >= T),[]),
findall(NotYetTriggeredProcess,
(member(NotYetTriggeredProcess,PreviousModelInstance),
gets_triggered(NotYetTriggeredProcess, TriggerT),
TriggerT >= T), []),
findall(AndPostProcess,
(member(AndPostProcess,PreviousModelInstance),
find_AllAndPostPr(X), member(AndPostProcess, X),
\+ member(AndPostProcess,PreviousProcessExecuted) ), []),
findall(Cost, ( process(Pid, _PName, _Trigger, _Precond, _Action,
_Duration, Cost),
member([Pid,_CompletionTime],PreviousCompleteProcessAgenda)),
CompletedCosts),
sum_list(CompletedCosts, TotalCost),
write('Base case hit!'), nl, write('The BPM has finished execution
at time '), reduce_one(T, NewT), write(NewT), nl,
nl, write('Results:'), nl, write('The junctions executed are: '),
write(PreviousJunctionsExecuted), nl,
write('The processes executed are: '),
write(PreviousProcessExecuted), nl,
write(' with finish times: '), write(PreviousCompleteProcessAgenda),
nl, write(' and with total cost: '), write(TotalCost).
75
Even though our workflow engine is designed to be used only for correct BPMs, we
have decided to provide a more flexible option and model the case of an unsuccessful
BPM execution. So, in case the BPM we check does not seem to finish execution,
either because of an untriggered process or because of an unsatisfied process
precondition, then the workflow engine would keep updating time and never reach an
end. In order to avoid this situation, and at the same time provide some feedback to
the user, we have decided to stop BPM execution after some big time point (currently
arbitrarily set to 100, but easy to change), and inform the user that the workflow
engine has been running for too long, a situation that probably signifies some
model or entity error.
such as action definition, junctions handling, checking for process execution, etc.
Actions
action_result(create_entity(EntityName, EntityAttribute)):-
asserta(entity_occ(EntityName, _EntityId, EntityAttribute)).
The clause above defines the create_entity action, which asserts an entity_occ clause
in our world state database. The other actions (delete_entity, create_data,
delete_data) are defined in a similar way.
Junctions
junc_type_satisfied(junction(start,_Pre,_Post),
_CompletedProcessTillNow, _T).
junc_type_satisfied(junction(and_joint, Pre, _Post),
CompletedProcessTillNow, T):-
find_all_PreTriggered(Pre, PreTriggered),
all_triggered_completed(PreTriggered, CompletedProcessTillNow, T).
Junctions can be reached and processed only if their type is satisfied. Above we can
see two examples of junction satisfaction, an easy one (start) and a more complicated
one (and_joint). The latter is satisfied only if all its triggered pre-processes have
completed execution.
76
Process execution
The execute_process predicate is of the form
execute_process(Process,ActionsAgenda,CompletionAgenda,NowModelInsta
nce,T)
This definition agrees with Figure 44 which indicates that a process may be executed
only if it has a model instance, if it is triggered and its preconditions hold.
The developed workflow engine is designed for BPM simulation, and its business
context sensitive approach (expressed in terms of time and cost) lets us check and
compare strategic decisions. Its implementation in Prolog, which adopts FBPML,
satisfies all design requirements that have been addressed in 4.1.2 and conforms to its
mission, as it is addressed in section 4.1.1.
We will now illustrate how the workflow engine can be used and what output it is
expected to give (See Appendix C for a relevant demo). By using the example BPM
of Figure 55, we will show the steps that the user has to follow when simulating a
BPM and the relevant output of the system. First, the processes of the BPM have to
be defined and stored in a file (lets call it myProcess), the junctions of the BPM
have to be defined and stored in a file (lets call it myJunctions), the initial world
state has to be described in terms of entity_occ and data and stored in a file (lets call
it myWorld), and the event occurrence list has to be specified and stored (lets store
it in myWorld).
7
7
Process Junction Initial world Event
specification specification description occurrences list
Results
Workflow -Total time
Engine -Total cost
-Real-time workflow state
So, for our example BPM the relevant files would look like this:
myProcess:
process(p1, p1, [true], [],[create_entity(car,[colour_red])],1,100).
process(p2, p2,
[exist(event_occ(needForCar))],
[exist(entity_occ(car))], [create_data(carMatch,
[quality_good])], 1, 50).
myJunctions:
junction(start, [], [p1]).
junction(link, [p1], [p2]).
junction(finish, [p2], []).
myWorld:
event_occ(e1, needForCar, 2).
After these files are loaded, if we type run_bpm. then the BPM starts execution and
we get the following output:
--------------------------------------
Time=0
The completed processes till now are []
Junction junction(start,[],[p1]) hit
Model instances of processes [p1] created
The SofarTriggered processes are [p1]
Process p1 starts now execution till timepoint 1
and actions [[create_entity(car,[colour_red])],1] are added to the
ActionsAgenda
--------------------------------------
Time=1
The following actions are executed: [create_entity(car,[colour_red])]
Action create_entity(car,[colour_red]) executed
The completed processes till now are [p1]
Junction junction(link,[p1],[p2]) hit
78
Model instances of processes [p2] created
The SofarTriggered processes are [p1]
The SofarTriggered processes are [p1]
--------------------------------------
Time=2
The following actions are executed: []
The completed processes till now are [p1]
The SofarTriggered processes are [p1,p2]
Process p2 starts now execution till timepoint 3
and actions [[create_data(carMatch,[quality_good])],3] are added to the
ActionsAgenda
--------------------------------------
Time=3
The following actions are executed: [create_data(carMatch,[quality_good])]
Action create_data(carMatch,[quality_good]) executed
The completed processes till now are [p2,p1]
Junction junction(finish,[p2],[]) hit
Model instances of processes [] created
--------------------------------------
Base case hit!
The BPM has finished execution at time 3
Results:
The junctions executed are: [junction(finish,[p2],[]),junction(link,[p1],
[p2]),junction(start,[],[p1])] The processes executed are: [p2,p1]
with finish times: [[p2,3],[p1,1]]
and with total cost: 150
yes
The above example shows that the workflow engine behaves the way it should and
gives meaningful feedback to the user. Let us now give an interesting advice to the
user that wishes to use our workflow engine for a BPM that involves a loop: Since
our workflow engine does not support loop handling, the BPM can be transformed
appropriately, so that it can be dealt with from our workflow engine. The BPM
transformation involves the creation of new copies of the processes of the loop. A
relevant example is given in Appendix A.
To sum up, we believe that the developed workflow engine serves its mission and
objectives, as addressed in 4.1.1, but also provides extra flexibility by tracking wrong
BPMs and dealing with loops to some extent.
79
Chapter 5
Experiments
Now that we have developed the workflow engine, we can use it to create an
executable version of Dells business process model, and hence move to the
implementation layer of the Three-Layered Business Process Modelling Approach.
The goal of this version is to experiment with time and cost and reason about Dells
supply chain strategies. Under this scope, there is no point in executing every single
process model (out of the 20 in total!) of Dells BPM, but only the ones that illustrate
Dells supply chain strategies. So, we have decided to model and execute two process
models (of Dells enriched BPM version): Buy standard item to order (process 2)
and Sell directly to large business and public sector customers (process 4.2), as
these reflect in the best way Dells main supply chain strategies, thus direct sales and
build-to-order. After the simulation of these two processes, experiments will take
place. Our experiments are expected to answer two questions: First, whether we can
improve Dells actual BPM by making some processes parallel, and second, whether
Dells BPM is actually better (in terms of time and/or cost) than the BPM of a
traditional computer company.
We have decided to simulate two of Dells processes, Buy standard item to order
(process 2) and Sell directly to large business and public sector customers (process
4.2). These processes have been chosen because of their close relation with Dells
basic supply chain strategies, thus direct sales and build-to-order. The simulation
consists of two steps: The first one is the specification and representation of the
involved processes and junctions, of the initial world state and the events list. The
second is the actual execution with the help of the workflow engine, and the related
results.
80
5.1.1 Dells BPM specification and representation
In this section we will present and explain the specification and representation of the
two processes to be executed, thus process 2 and 4.2. For each process we will first
provide the process specification and explain some relevant assumptions, and then
we will describe the initial world state and the events list. Note that we will focus on
the process specification, as this is actually the cornerstone of the execution
procedure; hence, a full analysis and representation will be provided here for the
process specification, while the other topics will be covered partly here and partly in
Appendix D.
81
Process Specification of Buy standard item to order BPM
Pid PName Trigger Precondition Action Dur Cost
(time (money
units) units)
p2_1 identifyOwnNeed - exist_entity(needs create_data(needs 1 200
s OnXinventory) OnXinventory)
create_data(current
XInventoryLevel)
create_event(need
ForNewXinventory
)
p2_2 identifyPotential needForNewXin exist_data(needs create_data( 21 1000
Suppliers ventory OnXinventory) potentialXsuppliers
exist_data(relevant )
Xsuppliers)
not_exist_entity(
supplierX)
p2_3 selectSupplier needForNewXin exist_data(potential create_entity( 21 1000
ventory Xsuppliers) supplierX)
not_exist_entity(
supplierX)
p2_4 negotiate needForNewXin exist_entity(supplie create_entity( 8 750
ventory rX) contractXsupplier)
exist_data(needs create_event(
OnXInventory) integrateXsupplier)
not_exist_entity( create_entity(value
contractXsupplier ChainForX)
p2_5 shareInfo integrateXsupplie exist_entity(value create_data(shared 1 100
r ChainForX) CurrentXInventory
exist_data(current Level)
XInventoryLevel) create_data(shared
exist_data(demand DemandForecast)
Forecast) create_data(shared
exist_data(general GeneralBusiness
BusinessInfo) Info)
p2_6 getInventory lowXinventory exist_entity( create_entity( 1 1000
integrateXsupplie contractXsupplier) inventoryX)
r exist_data(shared create_event(arrive
CurrentXInventory InventoryX)
Level) delete_data(current
exist_data(shared XInventoryLevel)
DemandForecast) delete_data(shared
CurrentXInventory
Level)
create_data(update
dXInventoryLevel)
p2_7 paySupplier arriveInventoryX exist_entity(money create_data( 1 40
) supplierXpaid)
p2_8 manageSupplier integrateXsupplie - - 20 1000
r
82
Process p2 shows the whole procedure for buying a standard item to order, when
there is no supplier for this item yet, thus when the item is new. The specification of
process p2_1 is an excellent example to illustrate the difference between entity and
data in world description, that we have explained in 4.1.3. As the table above shows,
Dell is always in position to identify its own needs on a new item (the trigger
condition is true), a fact that reflects the high importance that Dell places on quickly
adapting to new situations. The process starts execution once there is an actual need
on some specific new item (lets call it X), which has not been needed in the past.
This need is represented by an entity in Dells world representation. Once such a need
is identified, Dell keeps a record of this need in its database (hence the relevant
create_data action). So, even though there may be a need (as an entity) for some item,
it is only when it is identified by the company (and tracked as a fact, thus data) that it
is recognized and can fire the processes following p2_1 (hence create_event). Process
p2_1 is assumed to be short in duration (only 1 time unit) and not costly (100 money
units).
Once the internal event needForNewXinventory takes place, processes p2_2, p2_3
and p2_4 are triggered. The identification of potential suppliers can start only if there
is no supplier already for this item and given that Dell has a list of suppliers which
are relevant with item X. Once the potential suppliers are identified, Dell stores
information about them in its database.
The supplier selection process (p2_3) requires the existence of such a list, so that Dell
can choose one supplier among all potential ones. Since Dell has high expectations
form its suppliers, the searching and selection procedure usually lasts longer and
costs more than in a traditional computer company, thus 21 time units and 1000
money units for each process.
If a supplier is found, the negotiation process can start execution, which is expected
to complete in about 8 time units with a signed contract from both sides, and with the
invocation of integration with the supplier. The internal event of integration fires the
collaboration between Dell and its suppliers, and thus triggers all the following
processes.
83
The info-sharing procedure begins (given that ValueChain is customized for the
supplier, and there is information to share) and since it is electronic, its duration and
cost are low. Dell keeps a record of the shared information in its database, and thus
the create_data for shared information are the relevant actions.
As we have seen in chapter 2, this information sharing allows Dell to place orders, if
any, late and demand fast delivery from its suppliers (usually the following day). In
fact, it is quite rare that orders are placed; instead the suppliers decide themselves
whether and how much inventory Dell would need at a certain point. So, if there is an
internal event that signifies a need on inventory X, and the supplier has knowledge
about this, then delivery starts execution; since most suppliers are obliged to maintain
inventory close to Dells plants, delivery lasts only one day (here: time unit). Once
inventory arrives to the assembly plant, the suppliers payment is triggered.
Process p2_8 is quite complex, and it involves supplier evaluation and policies and
relationships management. We assume that it lasts for about 21 time units and costs
around 1000 money units both values are much higher than in a traditional
computer company because of Dells decision to integrate and collaborate closely
with its suppliers.
Now that we have described the specification of process 2, we can move on to the
initial world description and the events list. In the initial world state Dell has money
in its bank account and a new need for item X, while its database contains
information about suppliers relevant for X, demand forecast for some product and
some general business information:
entity_occ(needsOnXinventory, ent1, [item_X]).
entity_occ(money, ent2, [euros_3000]).
data(d1, relevantXsuppliers, [item_X, [sup1_good, sup2_ok]]).
data(d2, demandForecastX, [item_X, time_oneWeek, level_2000]).
data(d3, generalBusinessInfo, [increasingImportance_edi]).
The event occurrence list is defined according to the expected finish times of the
related process, and hence we have:
84
event_occ(e1, needForNewXInventory, 1).
event_occ(e2, integrateWithXsupplier, 51).
event_occ(e3, lowXInventory, 52).
event_occ(e4, arriveInventoryX, 53).
Process 4.2: Sell directly to large business and public sector customers
The figure below is a reproduction of Figure 41, which represents the BPM for Sell
directly to large business and public sector customer.
The relevant process specification is presented in the following Table 12, and, like
Table 11, it is a more readable version of the actual code, which can be found in
Appendix D. Again, trigger conditions, preconditions, actions, duration and cost were
not found in literature, but are assumptions we have made.
Process Specification of Sell directly to large business and public sector customers
BPM
Pid PName Trigger Precondition Action Dur Cost
(time (money
units) units)
p4_2_1 identifyPotential - exist_entity( create_data( 25 750
CorporateCustom potentialCorporate potentialCorporate
ers Customer) Customer)
create_entity(corpo
rateCustomer)
create_data(
customerAddress)
create_event(new
CorporateCustomer
p4_2_2 identifyCorporate newCorporateCu exist_entity( create_data( 8 100
CustomersNeeds stomer corporateCustomer corporateCustomer
) Needs)
8
5
p4_2_3 identifyCorrespo newCorporateCu exist_entity(corpor create_data(custom 3 100
ndingConfigurati stomer ateCustomer) erConfigurations)
ons exist_data(
corporateCustomer
Needs)
exist_data(product
Specifications)
p4_2_4 informCorporate newCorporateCu exist_entity(corpor create_entity( 10 350
CustomersViaPre stomer ateCustomer) customerPremierPa
mierPages exist_data(custome ge)
rConfigurations) create_event(
integrateCustomer
ViaPremierPage)
p4_2_5 obtainOrder integrateCustome exist_entity( create_data(custom 7 40
rViaPremierPage customerPremierPa erOrder)
ge) create_event(
customerNeedOn customerOrder)
Product
p4_2_6 receivePayment customerOrder exist_entity( create_data(custom 1 40
customerPremierPa erOrderPaid)
customerPaymen ge) create_event(
t paidCustomerOrde
r)
p4_2_7 deliverOrder paidCustomerOr exist_entity(ordere create_data(custom 5 200
der dItems) erOrderDelivered)
assembled exist_data(custome
CustomerOrder rAddress)
p4_2_8 manageBigCusto newCorporateCu - - 2 300
merRelationships stomer
Table 7: Process specification of Sell directly to large business and public sector
customers
86
So, once a customer is identified, Dell discusses and identifies the organizations
needs on products (process p4_2_2, which takes about 8 time units and costs around
100 money units), and then specifies configurations that correspond to these needs.
This requires explicit description of the customers needs as well as explicit
description of each products specifications.
Customers are informed about the purchasing options they have through the
companys customized Premier Page, which is a result of process p4_2_4, and takes
about 10 time units to be finished. Once a customized Premier Page is created, and
given that the customer is ready to order (thus the trigger condition
customerNeedOnProduct), the employees of the organization can choose the products
that suit them, while the purchasing team of the company monitors the whole
procedure, thus leading to duration of 10 time units for the ordering process. It is
worth mentioning here that the electronic form of ordering saves Dell and the
corporate customer time and money, a situation that holds for the payment process as
well. Hence, when a customer order is placed, and the customer pays in electronic
form, the whole monitoring procedure is accelerated by its electronic form, thus has
duration of 1 time unit.
The order delivery process is triggered at the moment when a customer has paid and
the ordered products have been assembled, and after its execution Dell updates its
database about the delivery success. Process p4_2_8 involves supporting and getting
feedback from the customer, and it is triggered once a new customer is found.
Now we can proceed to the initial world description and the events list. In the initial
world state Dell has some potential corporate customers, and its database contains
information about its product specifications. We should note here that we will include
the existence of items to be ordered in the initial world state (even though this is not
actually the case) because these entities are product of process 3, which actually runs
in parallel with 4.2, and our workflow engine cannot force the creation of the items
during the execution of 4.2. So the initial world state is described by the following:
87
entity_occ(potentialCorporateCustomer, ent1, [potCC_custA]).
entity_occ(orderedItems, ent2, [prodID_sk32, orderID_thre34,
amount_5000]).
data(d1, productSpecifications, [prodID_sk32, performance_medium,
media_good]).
The event occurrence list is defined according to the expected finish times of the
related processes, and hence we have:
event_occ(e1, newCorporateCustomer, 25).
event_occ(e2, integrateCustomerViaPremierPage, 46).
event_occ(e3, customerNeedOnProduct, 46).
event_occ(e4, customerOrder, 53).
event_occ(e5, customerPayment, 53).
event_occ(e6, paidCustomerOrder, 54).
event_occ(e7, orderAssembled, 55).
Results:
The junctions executed are: [junction(finish_and,[p2_7,p2_8],[]),
junction(link,[p2_6],[p2_7]),junction(link,[p2_5],[p2_6]),
junction(and_split,[p2_4],[p2_5,p2_8]),junction(link,[p2_3],[p2_4]),
junction(link,[p2_2],[p2_3]),junction(link,[p2_1],[p2_2]),
junction(start,[],[p2_1])]
The processes executed are:
[p2_7,p2_6,p2_8,p2_5,p2_4,p2_3,p2_2,p2_1]
with finish times: [[p2_7,54],[p2_6,53],[p2_8,71],[p2_5,52],
[p2_4,51],[p2_3,43],[p2_2,22],[p2_1,1]]
and with total cost: 5090
88
Process 4.2: Sell directly to large business and public sector customers
According to the results of the simulation of process 4.2, selling computers
directly to a new big customer takes 60 time units and costs 1880 money units.
Results:
The junctions executed are: [junction(finish_and,[p4_2_7,p4_2_8],[]),
junction(link,[p4_2_6],[p4_2_7]),junction(and_split,[p4_2_5],[p4_2_6]),
junction(link,[p4_2_4],[p4_2_5]),junction(link,[p4_2_3],[p4_2_4]),
junction(link,[p4_2_2],[p4_2_3]), junction(and_split,[p4_2_1],
[p4_2_2,p4_2_8]), junction(start,[],[p4_2_1])]
The processes executed are: [p4_2_7,p4_2_6,p4_2_5,p4_2_4,p4_2_3,p4_2_8,
p4_2_2,p4_2_1]
with finish times: [[p4_2_7,60],[p4_2_6,54],[p4_2_5,53],[p4_2_4,46],
[p4_2_3,36],[p4_2_8,27],[p4_2_2,33],[p4_2_1,25]]
and with total cost: 1880
Table 9: Simulation results of Dells Sell directly to large business and public sector
customers
Lets suppose that Dell has been collaborating with Intel for processors supplying for
some years now. This means that their relationship is established, thus processes 2.1,
2.2, 2.3 and 2.4 have already finished execution (contracts have already been signed),
89
while process 2.8 is constantly running. Their daily collaboration for processors
supply consists then of info-sharing, inventory receipt and payment (represented by
processes 2.5, 2.6 and 2.7), and their execution takes only 3 time units and costs 1140
money units (the corresponding time and cost of the three processes).
Similarly, we can suppose that Boeing is a customer of Dell some years now (thus
existing customer), and hence processes 4.2.1 4.2.2 and 4.2.3 have already been
executed, while 4.2.8 is constantly running. Dell keeps informing Boeing about
products that may be of interest (hence process 4.2.4, which now has shorter duration
of 1 time unit and lower cost of 50 money units, as the customized Premier Page
already exists and only needs to be updated), and Boeing may order from time to
time, thus processes 4.2.5, 4.2.6 and 4.2.7 may execute several times. So, the
purchasing collaboration between Dell and Boeing would actually take only 15 time
units and cost 330 money units.
Another point worth mentioning is the way we treat the single case requirement
mentioned in chapter 3. In process 2, the single case corresponds to buying from one
supplier items of one type in a fixed amount (lets say 100 items). Similarly, in
process 4.2, the single case corresponds to selling directly to one big customer items
of one order in a fixed amount (lets say 1000 products in average).
After the realistic versions of process 2 and process 4.2 have been simulated, we can
proceed to the experiments. The experiments are an important part of this work, as
they are expected to reflect issues about Dells supply chain strategies and
operations. We should, however, keep in mind that the realistic versions of the
processes are, in a big part, based on assumptions about time and cost; hence, one
should reason with respect to the magnitude of these business goals, rather than the
actual values (e.g. duration difference of 1 time unit is not important, in contrast to a
difference of seven time units).
90
The experiments we wish to conduct are designed to answer two questions for each
BPM:
st
-1 experiment: Can the actual BPM be improved (e.g. make two sequenced
processes parallel)?
nd
-2 experiment: How is Dells BPM different from the corresponding BPM of a
traditional computer company?
In the following sections we will try to answer the two questions for each business
process model with the use of our workflow engine, and then we will discuss the
relevant results.
We will not check every possible combination of processes within a BPM, but only
some that make sense to make parallel. In order to check the alternative BPM
conceptualizations, only the junctions of the model will be changed (sequenced
processes turned into parallel), while the process and initial world state will not be
altered. Hence, checking will actually involve testing whether the trigger conditions
and preconditions are satisfied for the new BPM conceptualization under the previous
process and world circumstances. Also, the checking procedure will mainly be
manual, but can also sometimes be supported by the workflow engine. (Remember
that the workflow engine may not be designed to provide validation and verification,
but its flexibility allows us to use it for some basic checking.)
91
Either make some of the first processes (2.1, 2.2, 2.3 and 2.4) parallel, or push the
last sequenced process, 2.4 into the and-split-and-joint block.
The first does not seem very plausible, as semantically such a transformation would
not make sense (hence potential suppliers cannot be identified if needs are not first
identified, a supplier cannot be selected if there is no potential supplier being
identified first, and contracts can be negotiated only if a supplier has already been
found). However, we will check the case of parallelizing processes 2.2 and 2.3, so
that we are completely certain about this claim. So, the difference in the BPM of
Figure 57 will concern the part shown in the figure below:
Figure 59: Original (sequenced) and parallelized part of Buy standard item to order
for experiment 1, version 1
92
Another way to treat the same experiment would be to relax the BPM (e.g. relaxing
the preconditions of 2.3) by allowing 2.2 and 2.3 execute in parallel and in an
interactive way. This means that potential suppliers would be constantly identified
but for every identified potential supplier, the selection procedure would execute (in
parallel with the identification of the next potential supplier). Such an alternative
would be expected to have shorter duration than the original sequenced version but
also longer than the maximum duration of the two processes. Also, note that such a
BPM transformation raises questions of a managerial-business aspect, thus whether a
company would approve and be comfortable with such a choice.
The second experiment of the same type involves pushing process 2.4 into the and-
split-and-joint block, thus changing the part shown in the following figure in the way
presented.
Figure 60: Original (sequenced) and parallelized part of Buy standard item to order
for experiment 1, version 2
Once again, this experiment does not seem semantically very plausible, as processes
2.5 and 2.8 require that a contract with the supplier be signed, thus process 2.4 has to
have already finished execution before 2.5 and 2.8 begin. This is understandable, as
the collaboration between Dell and its supplier has to be official, when information
sharing and relationships management take place. This is also logically made clear, as
process 2.4 triggers processes 2.5 and 2.8. So, like in the previous experiment, the
BPM will behave as the sequenced one. This is verified by the simulation with our
workflow engine, which gives us exactly the same results as before (total time 71 and
total cost 5090, and p2_5 and p2_8 starting execution at timepoint 51, after the
93
completion of p2_4). So, making process 2.4 parallel with 2.5, 2.6, 2.7 and 2.8
does not improve the BPM execution.
Additionally, we could consider the case of relaxing the BPM, like before. However,
relaxing the BPM in this case would result into the creation of business risks, as
sharing information with a (potential) supplier with whom no contract has been
signed could cause problems of security to Dell. So, such an alternative is not
suggested.
From the above experiments it seems that Dell has organized its operations
regarding buying items to order in the best way.
Process 4.2: Sell directly to large business and public sector customers
We will now check whether process 4.2 can be improved by turning sequenced
processes into parallel ones. If we have a look at Figure two, we will see that there is
a big and-split-and-joint block, which involves processes 4.2.2-4.2.7 in the one
branch and 4.2.8 in the other. So, this BPM could, theoretically, be improved again in
two ways: Either push the 4.2.1 into the and-split-and-joint block or make some of
the processes of the longer branch parallel.
The first approach is once again semantically not plausible because only when a
customer is created, can processes 4.2.2 and 4.2.8 start execution. This is also
logically shown, as according to the process specification, 4.2.1 triggers both of
them. We will not analyse this deeper, as it is the same case as with process 2
(pushing 2.4 into the and-split-and-joint block). So, making process 4.2.1 parallel
with 4.2.2-4.2.7 and 4.2.8 does not improve the BPM execution.
The second approach would be to make some of the processes of the longer branch
parallel. We will try the case of making 4.2.2 and 4.2.3 parallel. As before, 4.2.3
requires 4.2.2 to have finished execution (and thus the precondition of existence of
data about customers needs, which is actually a post-condition of 4.2.2). So, the
BPM execution is not improved.
94
However, there is a relevant recommendation that could actually be helpful: the two
processes could be parallel in the sense that process 1, Design Product and Process
combines the processes Design Product and Design Process. So, we could create
a new process, namely Identify corporate customers need and corresponding
configurations, which would mean that Dell would talk with the customer to identify
his needs, but at the same time orientate the discussed needs around Dells products.
So, the customers needs would be identified at the same time as the appropriate
configurations. If this can be achieved and interests the business world (and hence
both sides, seller and buyer), then time and cost advantages could be involved, as the
parallel version of the two processes would reduce mistakes to a great extent.
However, this is something that should be tested in practice, and we cannot argue
about this option any further.
95
the other hand. Unfortunately, our BPMs, which are based on the MIT Process
Handbook, do not reflect whether inventory is kept or not, so we will basically focus
on the very same buying process and the related time and cost.
The Buy standard item to stock BPM of myCompany is based on the suggestion of
the MIT Process Handbook for Dells corresponding process (see Figure 19 in
section 3.2), and we believe that it reflects the relevant procedure in a traditional
computer company. Its reproduction can be seen in the following figure.
Somebody could argue that it does not differ much from Dells corresponding BPM,
as the junctions specification is quite similar. However, in reality there are some
important differences that concern aspects other than the junctions specification.
This means that the details of the processes specification differ between the two
companies, especially time duration and cost. We will not define each process of
Figure 61 for myCompany here (the detailed description can be found in Appendix
D), but we will explain what duration and cost is assigned to each one.
96
hand, the collaboration between a traditional company and its (existing) supplier is
longer and more costly compared to Dell, as no virtual integration is aimed; let us not
forget the great advantages that Dell has from ValueChain. So, the order placement
procedure lasts 2 time units and costs 100 money units, and the payment procedure
takes another 2 time units and costs 40 money units, while the order takes about 10
time units to arrive and costs 1000 money units. Based on Dell-relevant literature, we
assume that process 2.1 is the same as for Dell (duration of 1 time unit and cost of
200 money units), while process 2.7 is assumed to be shorter and cheaper for
myCompany (about 10 time units and 400 money units), as Dell places unusually
great importance in its relationship with the suppliers.
After the process specification, the events list and the initial world state is specified
for myCompany (for further information see Appendix D), we can move on to the
simulation of the companys Buy standard item to stock BPM. According to the
simulation results, the total execution time is 43 time units and the total involved cost
is 3440 money units. The more detailed simulation results can be seen below:
Results:
The junctions executed are: [junction(finish_and,[p2_6,p2_7],[]),
junction(link,[p2_5],[p2_6]), junction(link,[p2_4],[p2_5]),
junction(and_split,[p2_3], [p2_4,p2_7]),junction(link,[p2_2],[p2_3]),
junction(link,[p2_1],[p2_2]),junction(start,[],[p2_1])]
The processes executed are: [p2_6,p2_5,p2_7,p2_4,p2_3,p2_2,p2_1] with
finish times: [[p2_6,43],[p2_5,41],[p2_7,39],[p2_4,31],[p2_3,29],
[p2_2,16],[p2_1,1]] and with total cost: 3440
Table 10: Simulation results of myCompanys Buy standard item to stock
If we compare the above results with the corresponding ones of Dell (see the
following figures), we will see that buying standard items to order costs to Dell much
more time and money than buying to stock to a traditional computer company. This
fact was actually expected, as the results concern the case of a new supplier, and
since Dell places great importance on finding the right supplier and integrating with
him, the corresponding time and cost should be higher. As we have already made
clear, the required time and cost of the daily collaboration between Dell and a
97
supplier is actually only 3 time units and 1140 money units (for processes 2.5, 2.6
and 2.7). Similarly, the daily collaboration between myCompany and an existing
supplier is represented by processes 2.4, 2.5 and 2.6, and hence requires 14 time
units and 1140 money units.
80
60
Duration (in time 40 Dell
units) myCompany
20
0
new customer existing customer
Figure 62: Comparison of simulation results of time between Dells Buy standard
item to order and myCompanys Buy standard item to stock
6000
5000
4000
Cost (in money Dell
units) 3000
myCompany
2000
1000
0
new customer existing customer
Figure 63: Comparison of simulation results of cost between Dells Buy standard
item to order and myCompanys Buy standard item to stock
The conclusion from this experiment is that Dell spends more time and money in
order to establish a close relationship with its suppliers, but has an advantage of
speed in their daily collaboration, a fact that turns out to be a strong point on the
98
long run. This conclusion agrees with Dells strategic choice to work with only a few,
elite suppliers, with whom virtual integration is supported.
Dells Sell directly to large business and public sector customers vs.
myCompanys Sell via intermediary to business customers
Dells strategic choice of direct sales contradicts with traditional PC companies use
of intermediaries for selling. This experiment aims to highlight this strategic and
operational difference and provide results about time and cost involved.
So, we will assume that myCompany sells indirectly to the customer, hence via
distributor or some other third party. This means that the contact with the customer,
as well as the sales procedure is driven mainly by the third party and only to some
extent from the manufacturer for big clients. The BPM for Sell via distributor of
myCompany can be seen below, and it is based on MIT Process Handbooks case of
Compaq. Note that as customer is meant the final customer (here a business
customer), and since the sales procedure is driven by the third party, the related time
and cost is high (as there are always two steps incorporated: one between
myCompany and the intermediary, and one between the intermediary and the
customer).
Figure 64: myCompanys BPM for Sell via intermediary to business customers
This BPM may seem to be very similar to Dells corresponding BPM, shown in
Figure 58 (except for the fact that the identification of corresponding configurations
is not explicitly represented here, as it is a much more simplified procedure than for
Dell). However, apart from the junctions specification, there are important
99
differences in the details of the processes specification, especially in time duration
and cost. We will not define each process of Figure 6 for myCompany here (the
detailed description can be found in Appendix D), but we will explain what duration
and cost is assigned to each one.
As we have already mentioned, many of the processes of the above BPM are
implemented in two steps, one that connects the computer company with the
intermediary and one that connects the intermediary with the business customer. Such
processes are 4.4, 4.5, 4.6 and 4.7. So, an order has to be placed first to the
intermediary, and the intermediary passes it to the computer company; also, the
ordering procedure from the customer to the intermediary is usually not electronic,
thus leading to higher costs and time (especially if we take into account the errors
that may arise throughout the procedure and the difficulty for the customer to manage
his order), thus 11 time units and 140 money units. The payment receipt is also split
in two steps, leading to a duration of 2 time units (the cost is assumed to be 40). We
assume that order delivery takes 10 time units for myCompany, as traditional
companies do not place as much importance on delivery speed and responsiveness as
Dell does; the corresponding cost is however lower (150 money units), as slower
delivery usually means cheaper as well. It is also worth mentioning that since
traditional companies tend to keep stock of finished products, there is no delay for the
trigger of 4.6, unlike the case of Dell. Process 4.7 is much more complex for a
traditional company, as managing customer relationships is driven by the third party
and only partly from the PC company; also, the non-electronic implementation of
CRM (customer relationships management) raises time and cost to 7 time units and
700 money units (thus much higher than Dells 2 time units and 300 money units).
On the other hand, informing a new customer about products (process 4.3) is
assumed to be shorter and cheaper for myCompany, as it does not involve
customizing the information medium (for myCompany that is catalogues and
meetings with the customer), or customizing the products themselves. So, we assign
process 4.3 a duration of 7 time units and a cost of 250 money units. Process 4.1 is
fairly similar for myCompany and Dell (with the difference that it is initiated by
myCompanys third party), and hence the assigned time and cost is the same (25 time
units and 750 money units). Last, the identification of potential customers needs
100
incorporates the identification of corresponding products for myCompany, and hence
has duration of 10 time units (8+2 time units) and cost of 150 money units (100+50
money units).
Now that we have specified the processes for myCompanys Sell via intermediary to
business customer, we can move on to the simulation of the BPM (the needed
events list and initial world state description can be found in Appendix D). So,
according to the simulation results, the total execution time is 65 time units and the
total involved cost is 2180 money units. The more detailed simulation results can be
seen below:
Results:
The junctions executed are: [junction(finish_and,[p4_6,p4_7],[]),
junction(link,[p4_5],[p4_6]), junction(link,[p4_4],[p4_5]),
junction(link,[p4_3],[p4_4]), junction(link,[p4_2],[p4_3]),
junction(and_split,[p4_1],[p4_2,p4_7]),junction(start,[],[p4_1])]
The processes executed are: [p4_6,p4_5,p4_4,p4_3,p4_7,p4_2,p4_1]
with finish times:
[[p4_6,65],[p4_5,55],[p4_4,53],[p4_3,42],[p4_7,32],[p4_2,35],[p4_1,25]]
and with total cost: 2180
Table 11: Simulation results of myCompanys Sell via intermediary to business
customers
If we compare the above results with the corresponding ones for Dell, we will see
that selling via intermediary costs more for a traditional company in time and
money, than it costs for Dell to sell directly through its website. A graphical
representation of the comparison is to be seen in the figures below. This conclusion
seems logical, as selling directly means bypassing the intermediaries and hence
saving the time it takes to coordinate and collaborate with them. Also, it is widely
accepted that intermediaries add extra cost to the supply chain (as they need to make
some profit as well), a fact that can be reflected from the above result. So, given that
our assumptions about process duration and cost are correct, selling directly
guarantees a faster and cheaper selling procedure.
101
Dell's "Sell directly to large business and corporate customers" vs.
myCompany's "Sell via intermediary to business customers"
70
60
50
Duration (in time 40 Dell
units) 30 myCompany
20
10
0
new customer existing customer
Figure 65: Comparison of simulation results of time between Dells Sell directly to large
business and corporate customers and myCompanys Sell via intermediary to business
customers
2500
2000
1500 Dell
Cost (in money
units) 1000 myCompany
500
0
new customer existing customer
Figure 66: Comparison of simulation results of cost between Dells Sell directly to large
business and corporate customers and myCompanys Sell via intermediary to business
customers
It is also interesting to see the relevant results for the more frequent collaboration
between myCompany and an existing business customer (via the intermediary). So,
we will assume that an already existing customer of myCompany wishes to order
once again, and we will check the related time and cost for such a transaction
(processes 4.5, 4.6 and 4.7). Note that process 4.3 is also part of the daily
collaboration between myCompany and the customer, as informing the already
existing customers is an important aspect of CRM, but now requires slightly less
102
time and money, as the communication media and codes have already been
established (thus a duration of 4 time units and a cost of 150 money units). So, this
gives us a daily collaboration where 27 time units and 480 money units are
required, in contrast to Dells corresponding need for 15 time units and 330 money
units; note here that this difference is proportionally much higher than the one
mentioned above, for the case of a new customer (this is more obvious in the relevant
figures above). Therefore, it is clear that direct sales provides a big advantage in
terms of time and cost on the long run.
The conclusion from this experiment is that Dell spends less time and money for its
direct sales (for both new and existing customers) than a traditional computer
company does for its sales via intermediaries.
This section aims to clarify even further issues that have to do with the conducted
experiments. Hence, we will first describe the aim of each experiment and then we
will provide the results in a graphical representation and as aggregated as possible.
We will sum up with the discussion of some interesting related points.
The aim of the first experiment is to check whether Dells two BPMs (for process 2
and process 4.2) can be improved in terms of time. For each process model we have
picked one or more combinations of sequenced processes and turned them into
parallel; then we checked the trigger conditions, preconditions and actions of these
processes to see whether such a transformation is legal, and we calculated the total
execution cost (manually but also with the help of our workflow engine). The
experiments result for both processes is that the given BPMs cannot be improved
any further.
103
myCompany which correspond to Dells process 2 and 4.2, and we simulated their
execution. Note here that, as in the Dell case, we have assumed the required time and
cost values based on our knowledge of the computer industry. The total time and cost
results can be seen in the following table and figures:
80
70
60
50
duration (in time
40
units)
30 Dell
20 myCompany
10
0
new existing new existing
customer customer customer customer
process 2 process 4
Figure 67: Comparison of simulation results of time between Dells and myCompanys
processes
104
6000
5000
4000
cost (in money
3000
units)
Dell
2000
myCompany
1000
0
new existing new existing
customer customer customer customer
process 2 process 4
We should make clear that the original BPMs deal with the case of a new supplier or
a new customer. However, we believe that the daily collaboration between a
company and its already existing supply chain partners is also important, and hence
we have distinguished this case and estimated the corresponding time and cost in an
informal way (manually). The simulation results for this case can be seen after the
slash character / in the above table.
As the figures above show, Dells choice of buying to order and virtually integrating
with its suppliers results in higher cost and time values in the case of a new supplier,
but it leads to lower time from a traditional PC company on the long run, thus when
the relationship with the supplier has already been established. In addition, Dells
strategic choice of direct sales guarantees a faster and cheaper sales procedure for
both the case of a new or already existing customer, as Dell virtually integrates with
the customer by providing him an online customized sales, support and
communication channel, thus Premier Page.
We should point out here that throughout the experiments, our workflow engine has
been used as tool that supports analysis about different strategies; in other words, we
have used the workflow engine to calculate duration and cost for each BPM, and then
we have based our argumentation on these results. It is also highly important that the
simulation and comparison results are not a means of arguing whether one business
105
model is better than the other, as this is not our object of discourse. On the contrary,
the above results aim to distinguish the different supply chain strategies and show
how the related time and cost differ. After all, if we wanted to argue about the
correctness and/or the business advantages of each SC strategy, we would have to
take several other factors into account, such as quality, impact on demand, etc.
106
Chapter 6
Evaluation
Now that we have completed the planned work, thus the development of an
executable business process model that illustrates Dells supply chain strategies, we
can continue to its evaluation. The framework that we will adopt for evaluation is
explained in section 6.1, while the evaluation results follow in sections 6.2 and 6.3.
As we have made clear in Chapter 1, our work consists mainly of two parts: the
development of a business process model that provides an insight into Dells supply
chain strategies, and the creation of a workflow engine that is used to simulate the
developed BPM. We will adopt a theoretical evaluation approach (with some points
being evaluated in an empirical way as well) for each part of the project, thus:
Theoretical evaluation of Dells business process model
Theoretical evaluation of the developed workflow engine, based on its use
for the conducted experiments
We will now review the developed business process model for Dell (the enriched
version, which is the final one), which had the objective to illustrate Dells supply
chain strategies, and evaluate it along the following dimensions and corresponding
questions:
soundness: is the developed BPM correct according to FBPML specification?
107
realism: does the developed BPM correspond to Dells business and SCM
reality?
completeness: does the developed BPM cover all basic strategic choices of
Dell?
level of detail: is it abstract enough to provide an overall view of Dells SC
strategies, and detailed enough to provide interesting information?
108
guaranteed. Second, Dells BPM has been developed based on Dell-relevant
literature, as it is presented in 2.2, and based on the MIT Process Handbook, which
involved the study of the Dell case for the relevant BPM provided. We should also
mention that after the completion of Dells BPM development, we have crosschecked
it with the relevant literature. So, we can conclude from the above that
the developed BPM corresponds to the actual Dells business model and supply
chain strategies.
The decision of whether a SCM topic is covered by our BPM is taken based on the
answer of the following question: Could a reader that has some knowledge of SCM
but is not familiar with Dells SC strategies conclude each of the above-mentioned
SCM topics after studying our BPM for Dell? The above answers where the ones
109
we got from a PhD student with such a background, Ioanna Manataki. Most of them
are clear and positive, so we will only comment on the negative and (implied)
answers. The latter refer to the SC strategies which are in brackets in the table, thus
buying PC components instead of manufacturing them (key point 4), and not keeping
inventory of finished products (key point 5). The answers for these questions were of
the type I dont know; it is not clear from the BPM. Even though we would prefer a
positive answer, it is understandable that the reader will not be sure, as the absence of
a process for inventory management could either be on purpose (which actually is in
our case) or it could just be an omission of the developed BPM. Similarly, the fact
that there is no process like manufacture standard item, does not make clear to the
reader that Dell only buys PC components and does not manufacture them (for key
point 4). Last, the fact that the BPM does not cover the fact that no/low inventory of
standard items is kept (key point 7) is considered as a weakness of the developed
BPM. However, we believe that Dells BPM is in general complete concerning SC
strategies.
110
level and strategic approach while 4 a more detailed and operational one, we would
assign it class 2.
1 2 3 4
We will now evaluate the workflow engine that we have developed for BPM
simulation and for related time and cost calculation. We will follow a theoretical
evaluation of the workflow engine; hence we will we will test the aspects of
soundness, completeness, coverage and ease of use, and we will answer each
evaluation criterion question based on the behaviour of the workflow engine when
used for the experiments of Chapter 5. Let us remind the reader that the conducted
experiments involve Dells processes 2 and 4.2, and include sequenced and parallel
processes, with and-split-and-joint process branches.
111
6.3.2 Completeness evaluation
We will now evaluate the completeness of the workflow engine, thus we will check
whether it covers all of the necessary concepts and functionalities. To clarify the
evaluation procedure, we will provide a list of requirements against which our
system will be evaluated.
Table 14: Completeness Evaluation Checklist for the developed workflow engine
As one can see, our workflow engine covers most of the above concepts and
functionalities. It does not cover the representation of roles and synchronisation bars,
which are a part of the formal FBPML specification, in order to keep the workflow
engine development procedure simpler and manageable within the project time. For
the same reasons, junction execution is partly supported: only junctions that are
followed by a process can be executed, and not junctions followed by another
junction (except for the start- and finish-junctions). However, as the above table
shows, our workflow engine seems to be adequately complete, at least as far as our
general and specific requirements are concerned, as they are illustrated in Figure 41.
112
6.3.3 Coverage evaluation
We will now check whether our workflow engine covers all possible scenarios. Based
on the conducted experiments, we can say that it can deal with the average BPM and
simulate it successfully. But it cannot deal with some cases that are restrained by our
assumptions, as addressed in Figure 41. So, the workflow engine does not provide
loop-handling and it does not deal with the case of a wrong BPM through validation
or verification (it just does not execute it, without suggesting what the error might
be). However, as we have shown in section 4.4 and in Appendix A, we can transform
a BPM with a loop so that it can be simulated by our workflow engine, and there also
is some feedback to the user in case of a wrong BPM. So, we do not regard these
scenarios which are not covered as too serious shortcomings of our workflow engine.
113
Chapter 7
7.1 Overview
This projects motivation comes from the increasing importance of Supply Chain
Management and the interest in the successful case of Dell on the one hand, and the
need for a relevant analysis of a lower-level, on the other hand. We have tackled this
problem by developing a business process model that illustrates Dells supply chain
strategies, and which is strategic and business goal-oriented. In order to make this
BPM executable, we have designed and implemented a workflow engine that
simulates BPM execution and calculates the related total time and cost. Furthermore,
we have simulated two processes of the developed BPM and we have conducted
experiments for their improvement and for their comparison with according
processes of a traditional computer company.
7.2 Conclusions
In general the project was completed successfully. The developed BPM for Dell was
evaluated as correct, and it was found to cover most of the interesting points of Dells
supply chain strategies, and to correspond to reality. We also believe that it manages
to provide an insight into Dells supply chain strategies avoiding a too abstract and
high-level approach, even though in some cases more depth of detail would be
helpful. As far as the workflow engine is concerned, it serves its mission and
objectives, as addressed in 4.1.1, and it provides us with a correct and accurate BPM
simulation, given that the relevant assumptions are respected.
114
execution time and cost for each process part. These assumed time and cost values
were based on our knowledge of general practices in the business world and on the
literature that covers Dells SC strategies, and we regard them as assumptions of
medium strength. Therefore, the conclusions of experiment 2, which involves the
comparison of Dell with a traditional computer company, are based on the assumed
time and cost values, and hence they are not regarded as completely reliable. We
would rather suggest that one should look upon the second experiment as a good
framework for comparison of different SC strategies. On the other hand, the results of
the first experiment are reliable (i.e. that we cannot improve the two processes by
transforming a sequenced pat of them into parallel).
The future work of this project is focused on two main approaches: the improvement
of Dells BPM and the enrichment of the developed workflow engine. As far as
Dells BPM enhancement is concerned, the following topics are interesting and
meaningful:
Further decompose the processes of the developed BPM, so that more
operational details are covered. This way the reader would be able to move
from the strategic view of the upper level to the operational one, from the
very same BPM.
Find and replace the assumed execution time and cost values with the actual
ones.
Extend the BPM for the whole supply chain, thus show the strategies and
operations throughout the whole supply chain, from a supplier to the final
customer, instead of focusing only on Dell.
Our suggestions for the improvement of the workflow engine include the
following:
Model and execute the case of a junction followed by another junction.
Provide validation and verification of the BPM to be executed, hence check
its correctness and suggest what the error might be, if any.
115
Provide loop-handling.
No prior knowledge about the event occurrences. Instead the user feeds on
real-time the workflow engine about external events, and internal events are
produced by the workflow engine.
Adopt a more SCM-friendly approach, thus model and calculate distance,
inventory volume, inventory velocity, etc.
Include a graphical interface for the definition of the BPM to be simulated, as
well as for the simulation procedure.
116
Bibliography
[2] Beamon, B. M. (1998). "Supply chain design and analysis: Models and
methods." International Journal of Production Economics 55(3): 281-294
[4] Bowersox, D. J., Closs, David. J., Cooper, M. Bixby (2002). Supply Chain
Logistics Management. New York, McGraw-Hill/Irwin.
[9] Chen-Burger, Y.-H., Stader, J. (2003). "Formal Support for Adaptive Workflow
Systems in a Distributed Environment". Workflow Handbook 2003. Layna
Fischer, Workflow Management Coalition, Future Strategies Inc.
[10] Chopra, S., Meindl, P. (2003). Supply Chain Management: Strategy, Planning
and Operation, Prentice Hall.
[11] Chopra, S., Van Mieghem J. A. (2000). "Which e-business is Right for Your
Supply Chain?" Supply Chain Management Review 4(3).
117
[12] Cohen, S., Roussel, J. (2005). Strategic Supply Chain Management. McGraw-
Hill.
[13] Cutting-Decelle, A., Das, B., Young, R., Rahimifard, S., Anumba, C.,
Bouchlaghem, N. (2006). "Building Supply Chain Communication Systems: A
Review of Methods and Techniques". Data Science Journal, 5: 1-23
[15] Dell, M., Fredman, C. (2006). Direct from Dell: Strategies that Revolutionized
an Industry, Collins.
[16] Dong, Y., Carter, C. R., Dresner, M. E. (2001). "JIT purchasing and
performance: an exploratory analysis of buyer and supplier perspectives".
Journal of Operations Management, 4(19): 471-483.
[17] Fugate, B. S., Mentzer, J. T. (2004). "Dell's Supply Chain DNA". Supply Chain
Management Review,p.20-24.
[18] Gattorna, J. (2006). "Supply Chains are the Business". Supply Chain
Management Review, September 2006.
[21] Harrison, A., (2003). Lecture Notes of Supply Chain Management Course,
Competing Through Supply Chains, Department of Management Science and
Technology, Athens University of Economics and Business.
[22] Jaeger, T., A. Prakash, et al. (1994). "A framework for automatic improvement
of workflows to meet performance goals". Proceedings, Sixth International
Conference on Tools with Artificial Intelligence.
[23] Kalpic, B. and P. Bernus (2002). "Business process modelling in industry - the
powerful tool in enterprise management." Computers in Industry 47(3): 299-
318.
118
[26] Koehn, N. F, Michael Dell. (2001). "Winning on the Demand Side of the
Information Revolution", Harvard Business School Case 801 363.
[28] Kraemer K. L, Dedrick, J., Yamashiro, S. (2000). "Dell Computer: Refining and
Extending the Business Model with IT". The Information Society 16:5-21.
[29] Lawton, T.C., Michaels, K.P. (2001). "Advancing to the virtual value chain:
learning from the Dell model". Irish Journal of Management 22:91-112, ISSN:
1649-248X.
[30] Lee, H. L. (2000). "Creating Value through Supply Chain Integration". Supply
Chain Management Review, September 2000.
[31] Lee, H. L., Padmanabhan, V., Whang, S. (1997). "The Bullwhip Effect in
Supply Chains". Sloan Management Review 38 (3): 93-102.
[32] Lindsay, A., D. Downs, et al. (2003). "Business processes - attempts to find a
definition." Information and Software Technology 45(15): 1015-1019.
[33] Luo, W. and Y. A. Tung (1999). "A framework for selecting business process
modeling methods." Industrial Management & Data Systems 99(7): 312 - 319.
[34] Magretta, J. (1998). "The power of virtual integration: An interview with Dell
Computers Michael Dell", Harvard Business Review, 76 (2): 73-84
[37] Mentzas, G., C. Halaris, et al. (2001). "Modelling business processes with
workflow systems: an evaluation of alternative approaches." International
Journal of Information Management 21(2): 123-135.
[38] Mentzer, J. T., W. DeWitt, et al. (2001). "Defining Supply Chain Management."
Journal of Business Logistics 22(2): 1-25.
[39] Narasimhan, R., Mahapatra, S. (2004). "Decision models in global supply chain
management". Industrial Marketing Management 33 (1): 21-27.
[40] Nurcan, S., A. Etien, et al. (2005). "A strategy driven business process
modelling approach." Business Process Management Journal 11(6): 628 - 649.
119
[41] Pearlson, K., Raymond Y. (1999), Dell Computer Corporation: A Zero-Time
Organization, flowallience.com 1999
[45] Rivkin, J. W., Giorgi, S. (2004). "Matching Dell (B): 1998-2003", Harvard
Business School Cases January 29, 2004, 9-704-476.
[47] Shi, M., G. Yang, et al. (1998). "Workflow management systems: a survey".
Communication Technology Proceedings, 1998. ICCT '98. 1998 International
Conference on Communication Technology.
[48] Sinha, A., "Dell: From a Low-Cost PC Maker to an Innovative Company", ecch
case study, 2007, 307-023-1.
[49] Soffer, P. and Y. Wand (2005). "On the notion of soft-goals in business process
modeling." Business Process Management Journal 11: 663-679.
[51] Vedpuriswar, AV, (2004). "Business Model Innovation at Dell". ICFAI Center
for Management Research. BSTA058
[53] Zografos, K. G., (2003). Lecture Notes of Supply Chain Management Course,
Lecture 1, Department of Management Science and Technology, Athens
University of Economics and Business.
[54] http://www.dell.com/
[55] http://www.dellcommunity.com/
[56] http://www.dellideastorm.com/
120
[57] http://direct2dell.com/one2one/default.aspx
[58] www.fortune.com
[59] http://process.mit.edu/Activity.asp?ID=990929112221UF15790
[60] http://process.mit.edu/Default.asp
121
Appendix A
5 - 12
12 - 14
5 9
7-9
5 - 13
Figure 70: Example BPM to illustrate that backward chaining is inappropriate for start
time estimation
p1
p2
0
5 7 9 p3 12 13 14
p4
122
However, if we tried to calculate the start time of p4 through backward chaining then
it would either be set to 9 (because the or-joint junction would be found to be reached
at timepoint 9) instead of 12 or it would not execute at all, because of the following
rationale: A simple way to calculate a processs start time is by picking the maximum
value between its trigger time and the timepoint that the junction preceding it is
reached; according to this, p4 should start execution at timepoint 9. However, before
starting execution we should check whether its preconditions are satisfied at this
timepoint, which are actually not in the above case, and so p4 would not execute. In
order to find the actual start time of p4, the algorithm should go back in the workflow
state, before the or-joint junction is reached and check through its preceding
processes. However, this makes the whole procedure much more complicated, as it
should take into account many different factors apart from the last junction.
0-2 0-2
0 0 2 2 5 5
0 0
4-5 4-5
Figure 72: Example BPMs to illustrate sophisticated treatment of process waiting time
123
However, if we wanted to simplify the above case we could assume that there is no
waiting time for p2. This assumption could be based on the fact that we check
business strategies, and hence the normal case, where no errors occur. In this case,
both p1 and p2 start execution at time 0, and the and-joint junction is reached at the
maximum of their durations, thus 2, while the or-joint junction is reached at the
minimum duration of the two, thus at time 1. Note that the time difference of this
case under the above-mentioned assumption from the actual case is quite big.
On the other hand, the assumption that we based this simplistic approach on does not
seem very plausible for real-life business. This means that an organization cannot
control everything that affects its operations, as external events also take place (e.g.
some activity from the supplier or the customer side). So, the normal case
incorporates waiting time as well, and therefore it should be treated in a more
sophisticated way.
124
as at each timepoint we check which actions are to be executed (and thus update the
current world state), and which junctions and processes have been and are to be
executed (precise workflow state). So, in the above example the algorithm would do
the following: When timepoint 9 is reached, p2 would finish execution, the or-
junction would be reached, and p4 would become eligible for execution but not
execute because of its unsatisfied precondition. Then time would be updated and set
to 10, the same actions-junctions-processes checking procedure would take place and
so on, until we reach timepoint 12, where the actions of p1 are executed and hence
the precondition of p4 is satisfied. This example shows that measuring time in an
explicit way is a more natural approach for a workflow engine, as it is closer to
reality, thus ensuring correct start time estimation and world state control.
0 0 5 5
4-5
Figure 73: Example BPM to illustrate the need for prior knowledge of events occurrence
125
However, if we had prior knowledge that p2 will be triggered at 4, then the and-joint
junction would wait for p2 (remember the definition of and-joint junctions), and
hence be reached at the correct timepoint 5. So, having an event occurrence list
before the BPM is loaded to the workflow engine for simulation is essential for a
correct simulation.
The preceding processes of a fan-in junction are defined as the last processes of each
branch, hence for our example p3 and p4. So, in the case of an and-joint junction, like
in our example, if p3 is triggered then it must be executed before the and-joint
junction is reached. Baring in mind that we have complete prior information about
event occurrences, either internal or external, and if, according to the event-list, p3 is
triggered, then it must be executed; hence the processes preceding it, p1 and p2, must
also be executed. So, if p1 or p2 is not executed, then the and-junction cannot be
reached, therefore there is some dependence between processes p1, p2 and (the
trigger condition of) p3. Since such information is complicated to incorporate in the
workflow engine algorithm, and in order to avoid confusion, we will expect the
trigger condition of p3 to be relevant to the execution of p1 and p2 (e.g. the relevant
event is a post-condition of p1 or p2).
126
Why conditions iii) and iv) are essential in order to check BPM execution
completion
Condition iii) says that if we are waiting for some event that will trigger a process of
which we already have a model instance, then the BPM cannot complete execution.
This is made clear in the following figure, in the example case 1, where the following
holds: Supposing that process p1 is triggered and executed at timepoint 0 till 2, then
the finish junction is reached at timepoint 2. But if process p2 is triggered at
timepoint 4 and starts execution, then we have to wait for p2 to start and complete (at
timepoint 5) in order to say that the whole BPM has finished execution, thus just
hitting the finish junction is not enough.
Example Case 1 0
Example Case 2 0
2 2 2 2
0 0 0 0
Figure 75: Example BPMs to illustrate the need for conditions iii) and iv) of
execution completion
Condition iv) says that a BPM cannot be considered to have completed execution, if
some post-process of a reached and-split junction has not been triggered or executed.
The example case 2 illustrates the need for condition iv) in the following way:
Supposing that p2 is not triggered (or its preconditions do not hold) then the and-split
specification about post-processes is not satisfied, and hence the BPM is not
successful.
127
How to transform a BPM that involves a loop in order to simulate it with
our workflow engine
Even though our workflow engine does not support loop handling, transforming the
BPM by creating new copies of the processes involved in the loop lets us deal with
loops in an indirect way. The following figure illustrates how to transform such a
BPM.
Transformed BPM
128
Appendix B
% ---------------------------------------------------
% run_bpm/0
%----------------------------------------------------
/* Predicate run_bpm: finds all junctions and processes of the model
and fires BPM simulation for time 0 */
run_bpm:-all_junctions(JunctionsList),
all_processes(ModelProcessesList),
% ---------------------------------------------------
% execute_step/8
%----------------------------------------------------
/* Predicate execute_step(+ActionsAgenda, +JunctionsPending,
+PreviousJunctionsExecuted,+PreviousModelInstance,+ProcessPending,
+PreviousProcessExecuted,+PreviousCompleteProcessAgenda,+T)
executes a step that corresponds to time T, firing actions',
processes' and junctions' execution */
% BPM halts execution if it has been running for a long time (here
% arbitrarily set to 100)
execute_step(_ActionsAgenda,_JunctionsPending,
_PreviousJunctionsExecuted,_PreviousModelInstance, _ProcessPending,
_PreviousProcessExecuted, _PreviousCompleteProcessAgenda, 100):-
nl, write('The BPM cannot finish execution, either because of
some unsatisfied process precondition or because of a
necessary process not being triggered.').
129
% Base case: BPM stops execution when the finish junction is reached
% and there is no process pending for execution completion and no
% reached process will be triggered and no and-split post process is
% pending
execute_step(_ActionsAgenda, _JunctionsPending,
PreviousJunctionsExecuted, PreviousModelInstance, _ProcessPending,
PreviousProcessExecuted, PreviousCompleteProcessAgenda, T):-
( member(junction(finish,_LastProcess,[]),
PreviousJunctionsExecuted);
member(junction(finish_and, _LastProcess, []),
PreviousJunctionsExecuted);
member(junction(finish_or, _LastProcess, []),
PreviousJunctionsExecuted) ),
findall(P, (member([P,CompletionTime],
PreviousCompleteProcessAgenda), CompletionTime >= T),[]),
findall(NotYetTriggeredProcess,
(member(NotYetTriggeredProcess,PreviousModelInstance),
gets_triggered(NotYetTriggeredProcess, TriggerT),
TriggerT >= T), []),
findall(AndPostProcess,
(member(AndPostProcess, PreviousModelInstance),
find_AllAndPostPr(X), member(AndPostProcess, X),
\+ member(AndPostProcess,PreviousProcessExecuted) ),
[]),
findall(Cost,
(process(Pid, _PName, _Trigger, _Precond, _Action,
_Duration, Cost),
member([Pid,_CompletionTime],PreviousCompleteProcessAgen
da) ),CompletedCosts),
sum_list(CompletedCosts, TotalCost),
nl, write('-------------------------------------- '), nl,
write('Base case hit!'), nl,
write('The BPM has finished execution at time '),
reduce_one(T, NewT), write(NewT), nl, nl, write('Results:'),
nl, write('The junctions executed are: '),
write(PreviousJunctionsExecuted), nl,
write('The processes executed are: '),
write(PreviousProcessExecuted), nl, write('
with finish times: '),
write(PreviousCompleteProcessAgenda), nl,
write(' and with total cost: '), write(TotalCost).
execute_step(PreviousActAgenda, JunctionsPending,
PreviousJunctionsExecuted, PreviousModelInstance, ProcessPending,
PreviousProcessExecuted, PreviousCompleteProcessAgenda, T):-
nl, write('-------------------------------------- '), nl,
write('Time='), write(T), nl,
execute_actions_agenda(PreviousActAgenda, T),
findall(P,
(member([P,CompletionTime],PreviousCompleteProcessAgenda),
CompletionTime =< T), CompletedProcessTillNow),
write('The completed processes till now are '),
write(CompletedProcessTillNow), nl,
execute_junction_pending(JunctionsPending,
PreviousJunctionsExecuted, NowJunctionsExecuted,
PreviousModelInstance, NowModelInstance,
CompletedProcessTillNow, T),
execute_process_pending(ProcessPending,
130
PreviousProcessExecuted, NowProcessExecuted,
PreviousActAgenda, NowActAgenda,
PreviousCompleteProcessAgenda, NowCompleteProcessAgenda,
NowModelInstance, T),
update_time(T, NewT), difference(JunctionsPending,
NowJunctionsExecuted,
NewJunctionsPending),
difference(ProcessPending, NowProcessExecuted,
NewProcessPending), execute_step(NowActAgenda,
NewJunctionsPending,
NowJunctionsExecuted, NowModelInstance, NewProcessPending,
NowProcessExecuted, NowCompleteProcessAgenda, NewT).
/* -----------------------------------------------------------
MAIN STUFF: execute_actions_agenda, execute_junction_pending,
execute_process_pending
-------------------------------------------------------------*/
% ---------------------------------------------------
% execute_actions_agenda/2
%----------------------------------------------------
/* Predicate execute_actions_agenda(+ActionsAgenda, +T): executes all
actions of the process agenda that have execution time T */
execute_actions_agenda([], _T).
execute_actions_agenda(ActionsAgenda, T):-findall(Actions,
member([Actions,T], ActionsAgenda),
ActionsList),
flatten(ActionsList, FlatActionsList),
write('The following actions are executed: '),
write(FlatActionsList), nl,
do_actions(FlatActionsList).
% ---------------------------------------------------
% execute_junction_pending/7
%----------------------------------------------------
/* Predicate execute_junction_pending(+JunctionsPending,
+PreviousJunctionsExecuted, -NowJunctionsExecuted,
+PreviousModelInstance, -NowModelInstance,
+CompletedProcessTillNow, +T)
processes/executes all junctions that are pending and that can be
reached based on the completed processes till now (time T)
and creates model instances of their post processes */
131
execute_junction_pending(Rest, [First|
PreviousJunctionsExecuted], NowJunctionsExecuted,
IntermedModelInstance, NowModelInstance,
CompletedProcessTillNow, T).
execute_junction_pending([First|Rest], PreviousJunctionsExecuted,
NowJunctionsExecuted, PreviousModelInstance, NowModelInstance,
CompletedProcessTillNow, T):-
\+ execute_one_junction(First, _NoModelInstanceCreated,
CompletedProcessTillNow, T),
execute_junction_pending(Rest, PreviousJunctionsExecuted,
NowJunctionsExecuted, PreviousModelInstance,
NowModelInstance, CompletedProcessTillNow, T).
% ---------------------------------------------------
% execute_one_junction/4
%----------------------------------------------------
/* Predicate execute_one_junction(+Junction, +ModelInstancesCreated,
+CompletedProcessTillNow, +T)
succeeds if the junction's type is satisfied */
% ---------------------------------------------------
% execute_process_pending/9
%----------------------------------------------------
/* Predicate execute_process_pending(+ProcessPending,
+PreviousProcessExecuted, -NowProcessExecuted, +PreviousActAgenda,
-NowActAgenda,+PreviousCompleteProcessAgenda,
-NowCompleteProcessAgenda, +NowModelInstance, +T)
fires the execution of pending processes that can start execution at
time T and puts their actions in the ActionsAgenda */
execute_process_pending([], ProcessExecuted, ProcessExecuted,
ActAgenda, ActAgenda, CompleteProcessAgenda,
CompleteProcessAgenda, _NowModelInstance, _T).
execute_process_pending([First|Rest], PreviousProcessExecuted,
NowProcessExecuted, PreviousActAgenda, NowActAgenda,
PreviousCompleteProcessAgenda, NowCompleteProcessAgenda,
NowModelInstance, T):-
execute_process(First, ActionsAgenda, CompletionAgenda,
NowModelInstance, T),
execute_process_pending(Rest, [First|PreviousProcessExecuted],
NowProcessExecuted, [ActionsAgenda|PreviousActAgenda],
NowActAgenda, [CompletionAgenda|
PreviousCompleteProcessAgenda], NowCompleteProcessAgenda,
NowModelInstance, T).
132
execute_process_pending([First|Rest], PreviousProcessExecuted,
NowProcessExecuted, PreviousActAgenda, NowActAgenda,
PreviousCompleteProcessAgenda, NowCompleteProcessAgenda,
NowModelInstance, T):-
\+ execute_process(First, _NoActionsAgenda,
_NoCompletionAgenda, NowModelInstance, T),
execute_process_pending(Rest, PreviousProcessExecuted,
NowProcessExecuted, PreviousActAgenda, NowActAgenda,
PreviousCompleteProcessAgenda, NowCompleteProcessAgenda,
NowModelInstance, T).
% ---------------------------------------------------
% execute_process/5
%----------------------------------------------------
/* Predicate execute_process(+Process, -ActionsAgenda,
CompletionAgenda, +NowModelInstance, +T)
succeeds when Process has a model instance, it has already been
triggered, and its preconditions hold at time T */
execute_process(Process, [Actions,F], [Process, F],NowModelInstance,
T):-
process(Process, _PName, _Trigger, Precond, Actions, Duration,
_Cost),
member(Process, NowModelInstance),
findall(Proc, (gets_triggered(Proc, TriggerT), TriggerT =< T),
SofarTriggered),
write('The SofarTriggered processes are '),
write(SofarTriggered), nl,
member(Process, SofarTriggered),
precondition_holds(Precond),
F is T+Duration,
write('Process '), write(Process),
write(' starts now execution till timepoint '), write(F), nl,
write(' and actions '), write([Actions,F]),
write(' are added to the ActionsAgenda'), nl.
%************
% JUNCTIONS
%************
% ---------------------------------------------------
% junc_type_satisfied/3
%----------------------------------------------------
/* Predicate junc_type_satisfied(junction(+Type, +Pre, +Post),
+CompletedProcessTillNow, +T)
succeeds if the type of the junction is satisfied at time T based on
the processes that have completed execution until time T */
junc_type_satisfied(junction(start, _Pre, _Post),
_CompletedProcessTillNow, _T).
junc_type_satisfied(junction(start_and, _Pre, _Post),
_CompletedProcessTillNow, _T).
133
junc_type_satisfied(junction(start_or, _Pre, _Post),
_CompletedProcessTillNow, _T).
junc_type_satisfied(junction(link, Pre, _Post),
CompletedProcessTillNow, T):-
all_triggered_completed(Pre, CompletedProcessTillNow, T).
% ---------------------------------------------------
% all_triggered_completed/3
%----------------------------------------------------
/* Predicate all_triggered_completed(+ProcessList,
+CompletedProcessesTillNow, +T)
succeeds if all processes of ProcessList have completed execution
till now (time T) */
all_triggered_completed([], _CompletedProcessesTillNow, _T).
all_triggered_completed([First|Rest], CompletedProcessesTillNow,T):-
member(First, CompletedProcessesTillNow),
all_triggered_completed(Rest, CompletedProcessesTillNow, T).
% ---------------------------------------------------
% find_all_PreTriggered/2
%----------------------------------------------------
134
/* Predicate find_all_PreTriggered(+ProcessList,-TriggeredProcesses)
finds all processes in ProcessList that have already been
triggered */
find_all_PreTriggered(ProcessList, TriggeredProcesses):-
findall(Process, (member(Process, ProcessList),
gets_triggered(Process, _AnyTime)), TriggeredProcesses).
% ---------------------------------------------------
% one_triggered_completed/3
%----------------------------------------------------
/* Predicate one_triggered_completed(+ProcessList,
+CompletedProcessTillNow, +T)
succeeds if at least one process in ProcessList has already
completed execution at time T */
one_triggered_completed(ProcessList, CompletedProcessTillNow, _T):-
member(SomeProcess, ProcessList),
member(SomeProcess, CompletedProcessTillNow).
%***********
% TRIGGERS
%***********
% ---------------------------------------------------
% gets_triggered/2
%----------------------------------------------------
% Predicate gets_triggered(+Pid, -T): returns the trigger time of
% process Pid
%if no triggers then created at time 0
gets_triggered(Pid, 0):-
process(Pid, _PName, [true], _Precond, _Action, _Duration,
_Cost).
% if trigger becomes true at point T
gets_triggered(Pid, T):-
process(Pid, _PName, TriggerCond, _Precond, _Action,
_Duration, _Cost),
\+ (member(Trigger,TriggerCond),\+ trigger_holds(Trigger,_T)),
findall( TriggerT, ( member(ATrigger,TriggerCond),
trigger_holds(ATrigger,TriggerT) ), AllTriggerTimes),
max_list(AllTriggerTimes, T).
135
%***************
% PRECONDITIONS
%***************
% ---------------------------------------------------
% precondition_holds/1
%----------------------------------------------------
% Predicate precondition_holds(PreconditionList): succeeds if all
% preconditions of the list currently hold
precondition_holds([]).
precondition_holds([exist(entity_occ(EntityName))|Rest]):-
entity_occ(EntityName, _EntityId, _EntityAttribute),
precondition_holds(Rest).
precondition_holds([not_exist(entity_occ(EntityName))|
Rest]):-\+ entity_occ(EntityName, _EntityId,
_EntityAttribute), precondition_holds(Rest).
precondition_holds([exist(data(Subject))|Rest]):-
data(_SubjectID, Subject, _Attributes),
precondition_holds(Rest).
precondition_holds([not_exist(data(Subject))|
Rest]):-\+ data(_SubjectID, Subject,
_Attributes), precondition_holds(Rest).
%*********
% ACTIONS
%*********
action_result(create_entity(EntityName, EntityAttribute)):-
asserta(entity_occ(EntityName, _EntityId, EntityAttribute)).
action_result(delete_entity(EntityName, EntityAttribute)):-
retract(entity_occ(EntityName, _EntityId, EntityAttribute)).
action_result(create_data(Subject, Attributes)):-
asserta(data(_SubjectID, Subject, Attributes)).
action_result(delete_data(Subject, Attributes)):-
retract(data(_SubjectID, Subject, Attributes)).
% ---------------------------------------------------
% do_actions/1
%----------------------------------------------------
% Predicate do_actions(+ActionsList) fires the execution of all
% actions in the ActionsList
do_actions([]).
do_actions([First|Rest]):-
action_result(First),
write('Action '), write(First), write(' executed'),nl,
do_actions(Rest).
136
%********
% USEFUL
%********
update_time(T, NewT):-
NewT is T + 1.
reduce_one(T, NewT):-
NewT is T - 1.
find_AllAndPostPr(X):-
findall(P, ( (junction(and_split,_Pre,Post);
junction(start_and,_Pre,Post) ), member(P,Post) ), X).
all_junctions(X):-
findall(junction(Type,Pre,Post), junction(Type,Pre,Post), X).
all_processes(ModelProcessesList):-
findall(Pid, process(Pid, _PName, _Trigger, _Precond, _Action,
_Duration, _Cost), ModelProcessesList).
flatten([],[]):- !.
flatten([H|T],L3):-
!,
flatten(H,L1),
flatten(T,L2),
append(L1,L2,L3).
flatten(X,[X]).
difference([], _, []).
difference([H|T], L, NewList):-
member(H, L), !,
difference(T, L, NewList).
difference([H|T], L, [H|NewList]):-
difference(T, L, NewList).
137
Appendix C
In this document we will illustrate how one can use the developed workflow engine
for BPM simulation. Note that the user is expected to know the cost and time needed
for the execution of each process in the BPM to be simulated, as well as the initial
world state and list of events that are expected to take place. In this demo we will use
a simple BPM for simulation, which is provided in the following graph:
Figure 78 shows the framework for simulating BPMs with our workflow engine
includes the specification of the processes and junctions in the BPM, the description
of the initial world state and the specification of the event occurrences list.
Processes specification includes information such as preconditions and time and cost
of a process, and junction specification includes the type of each junction, its pre- and
post-processes. The world state is described in terms of entities that exist in the world
and data that the object of discourse (usually the organization) has in its database.
The output of the system is real-time information resulted from BPM executions
(which processes have been executed at each timepoint, which junctions have been
reached, etc.) and the final results of the total time and cost of the execution. The
details of the framework will be explained in a comprehensive way later on.
138
1
The workflow engine is implemented in Prolog (SICSTUS Prolog ), and the user is
expected to be in some extent familiar with the running environment. Under UNIX,
Prolog is started from a shell command, while in Windows it is normally started by
clicking on the corresponding icon (or from the Programs tab).
Results
Workflow -Total time
Engine -Total cost
-Real-time workflow state
Considering the above workflow engine framework, one has to follow five steps in
order to simulate a BPM using our workflow engine:
1) Specify the processes of the BPM
2) Specify the junctions of the BPM
3) Describe the initial world state and provides an event occurrence list
4) Initialize the workflow engine
5) Run the workflow engine in Prolog
Each of these steps will be now explained for the simulation of our example BPM.
1
http://www.sics.se/isl/sicstuswww/site/index.html
139
Step 1: Specify the processes of the BPM
In this step we define all processes of our BPM, thus p1 and p2. The process
specification is written with a standard text editor, and it is saved with a suffix
.pl. A process can be defined by the following predicate:
where Pid is the ID of the process, PName is the name of the process, Trigger is the
list of the trigger conditions of the process, Precond is the list of the preconditions of
the process, Action is the list of the actions that the process fires, and Duration and
Cost is the related execution time and cost.
So, for our BPM example we type the following and save it as .pl file, lets say
myProcess.pl:
140
Step 2: Specify the junctions of the BPM
In this step we define all junctions of our BPM, thus for our example BPM the start
and finish junction, as well as the two precedence links. The junction specification is
written with a standard text editor, and it is saved with a suffix .pl. A junction can
be defined by the following predicate:
where JunctionType is the type of the process, PreProcesses is the list of the
processes preceding the junction and PostProcesses is the list of the processes
following the junction.
So, for our BPM example we type the following and save it as .pl file, lets say
myJunctions.pl:
141
Step 3: Describe the initial world state and provide the event occurrence list
In this step we describe the initial world state in terms of entities and data, and define
all the events that will happen throughout BPM execution. This specification is
written with a standard text editor, and it is saved with a suffix .pl.
Data can be defined by the following predicate, where Subject is the subject of the
data entry, SubjectID is the ID of the data entry and Attributes is the list of the
attributes of this data item:
data(SubjectID, Subject, Attributes).
An event can be defined by the following predicate, where EventId is the ID of the
event, EventName is the event name and T is the timepoint of occurrence of this
event:
event_occ(EventId, EventName, T)
Note that data and entities are defined as dynamic predicates, (meaning that they can
be created or deleted dynamically, at run-time) thus before defining them in our file
we need to type:
:- dynamic entity_occ/3. :-
dynamic data/3.
For our example, as it is explained in section 4.3 of the thesis, there is no data or
entities in the initial world state, while there is only one event occurrence at timepoint
2, needForCar. So, for our BPM example we type the following and save it as .pl
file, lets say myWorld.pl:
142
Figure 81: Screenshot of myWorld.pl
143
Step 4: Initialize the workflow engine
In this step the above files are loaded in the workflow engine, in order to initialize it.
This is done in the body of the workflow engine code, thus we have to open the file
of the workflow engine workflowEngine.pl with a text editor and type:
:- ['myWorld.pl']. :-
['myProcess.pl']. :-
['myJunctions.pl'].
144
Step 5: Run the workflow engine in Prolog
In this step the workflow engine file is run in Prolog, simulating the BPM. The steps
for this procedure are the following. First we start Prolog; this is done either by
typing sicstus in Unix or by clicking the corresponding icon in Windows. In
Windows the Sicstus Prolog environment looks like Figure 83.
After Prolog is started, we load the workflow engine file, either by typing
[workflowEngine.pl] or by choosing FileLoad and then choosing the file
workflowEngine.pl
After the workflow engine is loaded we can start the BPM simulation, simply by
typing run_bpm. and pressing enter. This is shown in the following figure:
145
Then the BPM execution is simulated and we get the relevant output from the Sicstus
window. In our example case, the output looks like Figure 85:
146
Appendix D
Experiments Code
Process Specification
process(p2_1, identifyOwnNeeds, [true],
[exist(entity_occ(needsOnXinventory))],
[create_data(needsOnXinventory, [item_X]),
create_data(currentXInventoryLevel, [item_X, inv_0])], 1, 200).
process(p2_2, identifyPotentialSuppliers,
[exist(event_occ(needForNewXInventory))],
[not_exist(entity_occ(supplierX)), exist(data(needsOnXinventory)),
exist(data(relevantXsuppliers))], [create_data(potentialXsuppliers,
[sup1_good, sup2_ok])], 21, 1000).
process(p2_3, selectSupplier,
[exist(event_occ(needForNewXInventory))],
[exist(data(potentialXsuppliers)),not_exist(entity_occ(supplierX))],
[create_entity(supplierX, [sup1, good])], 21, 1000).
process(p2_4, negotiateContracts,
[exist(event_occ(needForNewXInventory))],
[exist(entity_occ(supplierX)), exist(data(needsOnXinventory)),
not_exist(entity_occ(contractXsupplier))],
[create_entity(contractXsupplier, [sup_sup1, reput_good]),
create_entity(valueChainForX, [sup_sup1])], 8, 750).
process(p2_5, shareInfoWithSupplier,
[exist(event_occ(integrateWithXsupplier))],
[exist(entity_occ(valueChainForX)),
exist(data(currentXInventoryLevel)), exist(data(demandForecastX)),
exist(data(generalBusinessInfo))],
[create_data(sharedCurrentXinventoryLevel, _),
create_data(sharedDemandForecast, _),
create_data(sharedGeneralBusinessInfo,_)], 1, 100).
process(p2_6, getInventoryFromSupplier,
[exist(event_occ(lowXInventory)),
exist(event_occ(integrateWithXsupplier))],
147
[exist(entity_occ(contractXsupplier)),
exist(data(sharedCurrentXinventoryLevel)),
exist(data(sharedDemandForecast))],
[create_entity(inventoryX, [item_X, amount_1000]),
delete_data(currentXInventoryLevel,[item_X, _]),
delete_data(sharedCurrentXinventoryLevel, _),
create_data(updatedXInventoryLevel, [item_X, amount_1000])],
1, 1000).
process(p2_7, paySupplier, [exist(event_occ(arriveInventoryX))],
[exist(entity_occ(money))],
[create_data(supplierXpaid, [sup1, 1000])], 1, 40).
process(p2_8, manageSupplier,
[exist(event_occ(integrateWithXsupplier))], [], [], 20, 1000).
The workflow engine is designed to give feedback about the workflow state in each
timepoint. In order to save space, and because not in every timepoint there is
interesting information, we will present here the feedback for only the meaningful
timepoints.
--------------------------------------
Time=0
The completed processes till now are []
Junction junction(start,[],[p2_1]) hit
Model instances of processes [p2_1] created
The SofarTriggered processes are [p2_1]
Process p2_1 starts now execution till timepoint 1
and actions
[[create_data(needsOnXinventory,[item_X]),create_data(currentXInventoryLevel ,[item_X,inv_0])],1]
are added to the ActionsAgenda
--------------------------------------
Time=1
The following actions are executed: [create_data(needsOnXinventory,
[item_X]),create_data(currentXInventoryLevel, [item_X,inv_0])]
Action create_data(needsOnXinventory,[item_X]) executed
Action create_data(currentXInventoryLevel,[item_X,inv_0]) executed
The completed processes till now are [p2_1]
Junction junction(link,[p2_1],[p2_2]) hit
148
Model instances of processes [p2_2] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4]
Process p2_2 starts now execution till timepoint 22
and actions [[create_data(potentialXsuppliers,[sup1_good,sup2_ok])],22]
are added to the ActionsAgenda
--------------------------------------
Time=2
The following actions are executed: []
The completed processes till now are [p2_1]
--------------------------------------
Time=21
The following actions are executed: []
The completed processes till now are [p2_1]
--------------------------------------
Time=22
The following actions are executed:
[create_data(potentialXsuppliers,[sup1_good,sup2_ok])]
Action create_data(potentialXsuppliers,[sup1_good,sup2_ok]) executed
The completed processes till now are [p2_2,p2_1]
Junction junction(link,[p2_2],[p2_3]) hit
Model instances of processes [p2_3] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4]
Process p2_3 starts now execution till timepoint 43
and actions [[create_entity(supplierX,[sup1,good])],43] are added to the
ActionsAgenda
--------------------------------------
Time=23
The following actions are executed: []
The completed processes till now are [p2_2,p2_1]
--------------------------------------
Time=42
The following actions are executed: []
The completed processes till now are [p2_2,p2_1]
--------------------------------------
Time=43
The following actions are executed: [create_entity(supplierX,[sup1,good])]
Action create_entity(supplierX,[sup1,good]) executed
The completed processes till now are [p2_3,p2_2,p2_1]
Junction junction(link,[p2_3],[p2_4]) hit
Model instances of processes [p2_4] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4]
Process p2_4 starts now execution till timepoint 51
and actions [[create_entity(contractXsupplier,
[sup_sup1,reput_good]),create_entity(value ChainForX,[sup_sup1])],51] are
added to the ActionsAgenda
--------------------------------------
Time=44
The following actions are executed: []
The completed processes till now are [p2_3,p2_2,p2_1]
--------------------------------------
Time=50
The following actions are executed: []
The completed processes till now are [p2_3,p2_2,p2_1]
--------------------------------------
Time=51
149
The following actions are executed: [create_entity(contractXsupplier,
[sup_sup1,reput_good]),create_entity(valueC hainForX,[sup_sup1])]
Action create_entity(contractXsupplier,[sup_sup1,reput_good]) executed
Action create_entity(valueChainForX,[sup_sup1]) executed
The completed processes till now are [p2_4,p2_3,p2_2,p2_1]
Junction junction(and_split,[p2_4],[p2_5,p2_8]) hit
Model instances of processes [p2_5,p2_8] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4,p2_5,p2_8]
Process p2_5 starts now execution till timepoint 52
and actions
[[create_data(sharedCurrentXinventoryLevel,_10257),create_data(sharedDemandF
orecast,_10252),create_data(sharedGeneralBusinessInfo,_10247)],52] are added
to the ActionsAgenda
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4,p2_5,p2_8]
Process p2_8 starts now execution till timepoint 71
and actions [[],71] are added to the ActionsAgenda
--------------------------------------
Time=52
The following actions are executed:
[create_data(sharedCurrentXinventoryLevel,_10787),create_data(sharedDemandFo
recast,_10782),create_data(sharedGeneralBusinessInfo,_10777)]
Action create_data(sharedCurrentXinventoryLevel,_10787) executed
Action create_data(sharedDemandForecast,_10782) executed
Action create_data(sharedGeneralBusinessInfo,_10777) executed
The completed processes till now are [p2_5,p2_4,p2_3,p2_2,p2_1]
Junction junction(link,[p2_5],[p2_6]) hit
Model instances of processes [p2_6] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4,p2_5,p2_6,p2_8]
Process p2_6 starts now execution till timepoint 53
and actions [[create_entity(inventoryX,
[item_X,amount_1000]),delete_data(currentXInvento ryLevel,
[item_X,_11195]),delete_data(sharedCurrentXinventoryLevel,_11192),cr
eate_data(updatedXInventoryLevel,[item_X,amount_1000])],53] are added to the
ActionsAgenda
--------------------------------------
Time=53
The following actions are executed: [create_entity(inventoryX,
[item_X,amount_1000]),delete_data(currentXInventor yLevel,
[item_X,_11553]),delete_data(sharedCurrentXinventoryLevel,_11550),cre
ate_data(updatedXInventoryLevel,[item_X,amount_1000])]
Action create_entity(inventoryX,[item_X,amount_1000]) executed
Action delete_data(currentXInventoryLevel,[item_X,inv_0]) executed
Action delete_data(sharedCurrentXinventoryLevel,_11550) executed
Action create_data(updatedXInventoryLevel,[item_X,amount_1000]) executed
The completed processes till now are [p2_6,p2_5,p2_4,p2_3,p2_2,p2_1]
Junction junction(link,[p2_6],[p2_7]) hit
Model instances of processes [p2_7] created
The SofarTriggered processes are [p2_1,p2_2,p2_3,p2_4,p2_5,p2_6,p2_7,p2_8]
Process p2_7 starts now execution till timepoint 54
and actions [[create_data(supplierXpaid,[sup1,1000])],54] are added to the
ActionsAgenda
--------------------------------------
Time=54
The following actions are executed: [create_data(supplierXpaid,[sup1,1000])]
Action create_data(supplierXpaid,[sup1,1000]) executed
The completed processes till now are [p2_7,p2_6,p2_5,p2_4,p2_3,p2_2,p2_1]
--------------------------------------
Time=55
The following actions are executed: []
The completed processes till now are [p2_7,p2_6,p2_5,p2_4,p2_3,p2_2,p2_1]
--------------------------------------
150
Time=70
The following actions are executed: []
The completed processes till now are [p2_7,p2_6,p2_5,p2_4,p2_3,p2_2,p2_1]
--------------------------------------
Time=71
The following actions are executed: []
The completed processes till now are
[p2_7,p2_6,p2_8,p2_5,p2_4,p2_3,p2_2,p2_1]
Junction junction(finish_and,[p2_7,p2_8],[]) hit
Model instances of processes [] created
--------------------------------------
Base case hit!
The BPM has finished execution at time 71
Results:
The junctions executed are: [junction(finish_and,[p2_7,p2_8],
[]),junction(link,[p2_6],[p2_7]), junction(link,[p2_5],
[p2_6]),junction(and_split,[p2_4],[p2_5,p2_8]), junction(link,
[p2_3],[p2_4]),junction(link,[p2_2],[p2_3]), junction(link,[p2_1],
[p2_2]),junction(start,[],[p2_1])]
The processes executed are: [p2_7,p2_6,p2_8,p2_5,p2_4,p2_3,p2_2,p2_1]
with finish times:
[[p2_7,54],[p2_6,53],[p2_8,71],[p2_5,52],[p2_4,51],[p2_3,43],[p2_2,22],[p2_1 ,1]]
Process Specification
process(p4_2_1, identifyPotentialCorporateCustomer, [true],
[exist(entity_occ(potentialCorporateCustomer))],
[create_data(potentialCorporateCustomer, [potCC_custA]),
create_entity(corporateCustomer, [cc_custA, size_1000]),
create_data(customerAddress, [cc_custA, address_eh92bh])],25, 750).
process(p4_2_2, identifyCorporateCustomersNeeds,
[exist(event_occ(newCorporateCustomer))],
[exist(entity_occ(corporateCustomer))],
[create_data(corporateCustomersNeeds, [cc_custA, amount_100,
perf_medium])], 8, 100).
process(p4_2_3, identifyCorrespondingConfigurations,
[exist(event_occ(newCorporateCustomer))],
[exist(entity_occ(corporateCustomer)),
exist(data(corporateCustomersNeeds)),
exist(data(productSpecifications))],
[create_data(customerConfigurations, [cc_custA, prodID_sk32])],
151
3, 100).
process(p4_2_4, informCorporateCustomerViaPremierPage,
[exist(event_occ(newCorporateCustomer))],
[exist(entity_occ(corporateCustomer)),
exist(data(customerConfigurations))],
[create_entity(customerPremierPage, [cc_custA, ppID_ppc32])],
10, 350).
process(p4_2_5, obtainOrder,
[exist(event_occ(integrateCustomerViaPremierPage)),
exist(event_occ(customerNeedOnProduct))],
[exist(entity_occ(customerPremierPage))], [create_data(customerOrder,
[orderID_thre34, cc_custA, prodID_sk32,
amount_100])], 7, 40).
process(p4_2_6, receivePayment, [exist(event_occ(customerOrder)),
exist(event_occ(customerPayment))],
[exist(entity_occ(customerPremierPage))],
[create_data(customerOrderPaid, [orderID_thre34, cc_custA,
amount_5000])], 1, 40).
process(p4_2_7, deliverOrder, [exist(event_occ(paidCustomerOrder)),
exist(event_occ(orderAssembled))], [exist(entity_occ(orderedItems)),
exist(data(customerAddress))], [create_data(customerOrderDelivered,
[orderID_thre34,method_truck])], 5, 200).
process(p4_2_8, manageBigCustomerRelationships,
[exist(event_occ(newCorporateCustomer))], [], [], 2, 300).
152
junction(link, [p2_5], [p2_6]).
junction(finish_and, [p2_6, p2_7], []).
Process Specification
process(p2_1, identifyOwnNeeds, [true],
[exist(entity_occ(needsOnXinventory))],
[create_data(needsOnXinventory, [item_X]),
create_data(currentXInventoryLevel, [item_X, inv_0])], 1, 200).
process(p2_2, identifyPotentialSources,
[exist(event_occ(needForNewXInventory))],
[not_exist(entity_occ(supplierX)), exist(data(needsOnXinventory)),
exist(data(relevantXsuppliers))], [create_data(potentialXsuppliers,
[sup1_good, sup2_ok])], 15, 700).
process(p2_3, selectSupplier, [exist(event_occ(needForNewXInventory))],
[exist(data(potentialXsuppliers)), exist(data(needsOnXinventory)),
not_exist(entity_occ(contractXsupplier))],
[create_entity(contractXsupplier, [sup_sup1, reput_good])],13,1000).
process(p2_4, placeOrder,
[exist(event_occ(collaborateWithXsupplier)),
exist(event_occ(lowXInventory))],
[exist(entity_occ(contractXsupplier)),
exist(data(currentXInventoryLevel))], [create_data(orderToX,
[sup_sup1, orderID_thrk32])], 2, 100).
process(p2_5, receive, [exist(event_occ(orderPlaced))],
[exist(entity_occ(contractXsupplier)), exist(data(orderToX)),
exist(entity_occ(transportMedium))],
[create_entity(inventoryX, [item_X, amount_1000]),
delete_data(currentXInventoryLevel,[item_X, _]),
create_data(updatedXInventoryLevel, [item_X,amount_1000])],
10, 1000).
process(p2_6, paySupplier, [exist(event_occ(arriveInventoryX))],
[exist(entity_occ(money))],
[create_data(supplierXpaid, [sup1, 1000])], 2, 40).
process(p2_7, manageSupplier,
[exist(event_occ(collaborateWithXsupplier))], [], [], 10, 400).
153
Logical representation of myCompanys Sell via
intermediary to business customers
Junctions Specification
junction(start, [], [p4_1]).
junction(and_split, [p4_1], [p4_2, p4_7]).
junction(link, [p4_2], [p4_3]).
junction(link, [p4_3], [p4_4]).
junction(link, [p4_4], [p4_5]).
junction(link, [p4_5], [p4_6]).
junction(finish_and, [p4_6, p4_7], []).
Process Specification
process(p4_1, identifyPotentialCorporateCustomer, [true],
[exist(entity_occ(potentialCorporateCustomer))],
[create_data(potentialCorporateCustomer, [potCC_custA]),
create_entity(corporateCustomer, [cc_custA, size_1000]),
create_data(customerAddress, [cc_custA, address_eh92bh])],25, 750).
process(p4_2, identifyCorporateCustomersNeeds,
[exist(event_occ(newCorporateCustomer))],
[exist(entity_occ(corporateCustomer)),
exist(entity_occ(corporateCustomersNeeds)),
exist(data(productSpecifications))],
[create_data(corporateCustomersNeeds,
[cc_custA,amount_100,perf_medium]),
create_data(customerAppropriateProducts, [cc_custA, prodID_sk32])],
10, 150).
process(p4_3, informCorporateCustomer,
[exist(event_occ(newCorporateCustomer))],
[exist(entity_occ(corporateCustomer)),
exist(data(customerAppropriateProducts))],[], 7, 250).
process(p4_4, obtainOrder, [exist(event_occ(customerInformed)),
exist(event_occ(customerNeedOnProduct))],
[exist(entity_occ(orderingMedium))],
[create_data(customerOrder, [orderID_thre34, cc_custA, prodID_sk32,
amount_100])], 11, 140).
process(p4_5, receivePayment, [exist(event_occ(customerOrder)),
exist(event_occ(customerPayment))],
[], [create_data(customerOrderPaid, [orderID_thre34, cc_custA,
amount_5000])], 2, 40).
process(p4_6, deliverOrder, [exist(event_occ(paidCustomerOrder))],
[exist(entity_occ(orderedItems)), exist(data(customerAddress))],
[create_data(customerOrderDelivered, [orderID_thre34,method_truck])],
10, 150).
process(p4_7, manageCustomerRelationships,
[exist(event_occ(newCorporateCustomer))], [], [], 7, 700).
154
entity_occ(potentialCorporateCustomer, ent1, [potCC_custA]).
entity_occ(orderedItems, ent2, [prodID_sk32, orderID_thre34,
amount_5000]).
entity_occ(corporateCustomersNeeds, ent3, [cc_custA, amount_100,
perf_medium]).
entity_occ(orderingMedium, ent4, [meidum_edi]).
155