WORK SYSTEMS

A work system is a system in which human participants

and/or machines perform work using information,
technology, and other resources to produce products and/or
services for internal or external customers. Typical business
organizations contain work systems that procure materials from suppliers, produce products,
deliver products to customers, find customers, create financial reports, hire employees,
coordinate work across departments, and perform many other functions.
The work system concept is like a common denominator for many of the types of systems that
operate within or across organizations. Operational information systems, service systems,
projects, supply chains, and ecommerce web sites can all be viewed as special cases of work
systems.
An information system is a work system whose processes and activities are devoted to
processing information.
A service system is a work system that produces services for its customers.
A project is a work system designed to produce a product and then go out of existence.
A supply chain is an interorganizational work system devoted to procuring materials and
other inputs required to produce a firms products.
An ecommerce web site can be viewed as a work system in which a buyer uses a sellers
web site to obtain product information and perform purchase transactions.
The relationship between work systems in general and the special cases implies that the same
basic concepts apply to all of the special cases, which also have their own specialized
vocabulary. In turn, this implies that much of the body of knowledge for the current information
systems discipline can be organized around a work system core.
Specific information systems exist to support (other) work systems. Many different degrees of
overlap are possible between an information system and a work system that it supports. For
example, an information system might provide information for a non-overlapping work system,
as happens when a commercial marketing survey provides information to a firms marketing
managers. In other cases, an information system may be an integral part of a work system, as
happens in highly automated manufacturing and in ecommerce web sites. In these situations,
participants in the work system are also participants in the information system, the work system
cannot operate properly without the information system, and the information system has little
significance outside of the work system.

Work system framework[edit]
The work system approach for understanding systems includes both a static view of a current (or
proposed) system in operation and a dynamic view of how a system evolves over time through planned
change and unplanned adaptations. The static view is summarized by the work system framework, which
identifies the basic elements for understanding and evaluating a work system. An easily recognized
triangular representation of the work system framework has appeared in Alter (2002, 2008) and
elsewhere.
The work system itself consists of four (4) elements: the processes and
activities, participants, information, and technologies.
Five (5) other elements must be included in even a rudimentary understanding of a work systems
operation, context, and significance. Those elements are the products and services produced,
customers, environment, infrastructure, and strategies. This framework is prescriptive enough to be useful
in describing the system being studied, identifying problems and opportunities, describing possible
changes, and tracing how those changes might affect other parts of the work system.

The definitions of the 9 elements of a work system are as follows:
1. Processes and activities include everything that happens within the work system. The
term processes and activities is used instead of the term business process because many
work systems do not contain highly structured business processes involving a prescribed
sequence of steps, each of which is triggered in a pre-defined manner. Such processes are
sometimes described as artful processes whose sequence and content depend on the skills,
experience, and judgment of the primary actors. (Hill et al., 2006) In effect, business process is
but one of a number of different perspectives for analyzing the activities within a work system.
Other perspectives with their own valuable concepts and terminology include decision-making,
communication, coordination, control, and information processing.
2. Participants are people who perform the work. Some may use computers and IT extensively,
whereas others may use little or no technology. When analyzing a work system the more
encompassing role of work system participant is more important than the more limited role of
technology user (whether or not particular participants happen to be technology users)
3. Information includes codified and non-codified information used and created as participants
perform their work. Information may or may not be computerized. Data not related to the work
system is not directly relevant, making the distinction between data and information secondary
when describing or analyzing a work system. Knowledge can be viewed as a special case of
information.
4. Technologies include tools (such as cell phones, projectors, spreadsheet software, and
automobiles) and techniques (such as management by objectives, optimization, and remote
tracking) that work system participants use while doing their work.
5. Products and services are the combination of physical things, information, and services that the
work system produces. This may include physical products, information products, services,
intangibles such as enjoyment and peace of mind, and social products such as arrangements,
agreements, and organizations.
6. Customers are people who receive direct benefit from products and services the work system
produces. They include external customers who receive the organization's products and/or
services and internal customers who are employees or contractors working inside the
organization.
7. Environment includes the organizational, cultural, competitive, technical, and regulatory
environment within which the work system operates. These factors affect system performance
even though the system does not rely on them directly in order to operate. The organizations
general norms of behavior are part of its culture, whereas more specific behavioral norms and
expectations about specific activities within the work system are considered part of its processes
and activities.
8. Infrastructure includes human, informational, and technical resources that the work
system relies on even though these resources exist and are managed outside of it and are
shared with other work systems. For example, technical infrastructure includes computer
networks, programming languages, and other technologies shared by other work systems and
often hidden or invisible to work system participants.
9. Strategies include the strategies of the work system and of the department(s) and
enterprise(s) within which the work system exists. Strategies at the department and enterprise
level may help in explaining why the work system operates as it does and whether it is operating
properly.
Work system life cycle model[edit]
The dynamic view of a work system starts with the work system life cycle (WSLC) model, which shows
how a work system may evolve through multiple iterations of four phases: operation and
maintenance, initiation, development, and implementation. The names of
the phases were chosen to describe both computerized and non-computerized systems, and to apply
regardless of whether application software is acquired, built from scratch, or not used at all. The terms
development and implementation have business-oriented meanings that are consistent with Markus and
Maos (2004) distinction between system development and system implementation.
This model encompasses both planned and unplanned change. Planned change occurs through a full
iteration encompassing the four phases, i.e., starting with an operation and maintenance phase, flowing
through initiation, development, and implementation, and arriving at a new operation and maintenance
phase. Unplanned change occurs through fixes, adaptations, and experimentation that can occur within
any phase. The phases include the following activities:
Operation and maintenance[edit]
Operation of the work system and monitoring of its performance
Maintenance of the work system (which often includes at least part of information systems that
support it) by identifying small flaws and eliminating or minimizing them through fixes, adaptations, or
workarounds.
On-going improvement of processes and activities through analysis, experimentation, and adaptation

Initiation[edit]
Vision for the new or revised work system
Operational goals
Allocation of resources and clarification of time frames
Economic, organizational, and technical feasibility of planned changes



Development[edit]
Detailed requirements for the new or revised work system (including requirements for information
systems that support it)
As necessary, creation, acquisition, configuration, and modification of procedures, documentation,
training material, software and hardware
Debugging and testing of hardware, software, and documentation

Implementation[edit]
Implementation approach and plan (pilot? phased? big bang?)
Change management efforts about rationale and positive or negative impacts of changes
Training on details of the new or revised information system and work system
Conversion to the new or revised work system
Acceptance testing
As an example of the iterative nature of a work systems life cycle, consider the sales system in a
software start-up. The first sales system is the CEO selling directly. At some point the CEO cant do it
alone, several salespeople are hired and trained, and marketing materials are produced that can be used
by someone less expert than the CEO. As the firm grows, the sales system becomes regionalized and an
initial version of sales tracking software is developed and used. Later, the firm changes its sales system
again to accommodate needs to track and control a larger salesforce and predict sales several quarters in
advance. A subsequent iteration might involve the acquisition and configuration of CRM software. The
first version of the work system starts with an initiation phase. Each subsequent iteration involves
deciding that the current sales system is insufficient; initiating a project that may or may not involve
significant changes in software; developing the resources such as procedures, training materials, and
software that are needed to support the new version of the work system; and finally, implementing the
new work system.
The pictorial representation of the work system life cycle model places the four phases at the vertices of
rectangle. Forward and backward arrows between each successive pair of phases indicate the planned
sequence of the phases and allow the possibility of returning to a previous phase if necessary. To
encompass both planned and unplanned change, each phase has an inward facing arrow to denote
unanticipated opportunities and unanticipated adaptations, thereby recognizing the importance of
diffusion of innovation, experimentation, adaptation, emergent change, and path dependence.
The work system life cycle model is iterative and includes both planned and unplanned change. It is
fundamentally different from the frequently cited Systems Development Life Cycle (SDLC), which actually
describes projects that attempt to produce software or produce changes in a work system. Current
versions of the SDLC may contain iterations but they are basically iterations within a project. More
important, the system in the SDLC is a basically a technical artifact that is being programmed. In contrast,
the system in the WSLC is a work system that evolves over time through multiple iterations. That
evolution occurs through a combination of defined projects and incremental changes resulting from small
adaptations and experimentation. In contrast with control-oriented versions of the SDLC, the WSLC treats
unplanned changes as part of a work systems natural evolution.

Work system method[edit]
The work system method (Alter, 2002; 2006) is a method that business professionals (and/or IT
professionals) can use for understanding and analyzing a work system at whatever level of depth is
appropriate for their particular concerns. It has evolved iteratively starting in around 1997. At each stage,
the then current version was tested by evaluating the areas of success and the difficulties experienced by
MBA and EMBA students trying to use it for a practical purpose. A version called work-centered analysis
that was presented in a textbook has been used by a number of universities as part of the basic
explanation of systems in organizations, to help students focus on business issues, and to help student
teams communicate. Ramiller (2002) reports on using a version of the work system framework within a
method for animating the idea of business process within an undergraduate class. In a research setting,
Petrie (2004) used the work system framework as a basic analytical tool in a Ph.D. thesis examining 13
ecommerce web sites. Petkov and Petkova (2006) demonstrated the usefulness of the work system
framework by comparing grades of students who did and did not learn about the framework before trying
to interpret the same ERP case study.
Results from analyses of real world systems by typical employed MBA and EMBA students indicate that a
systems analysis method for business professionals must be much more prescriptive than soft systems
methodology (Checkland, 1999). While not a straitjacket, it must be at least somewhat procedural and
must provide vocabulary and analysis concepts while at the same time encouraging the user to perform
the analysis at whatever level of detail is appropriate for the task at hand.

The latest version of the work system method is organized around a general problem-solving outline that
includes:
Identify the problem or opportunity
Identify the work system that has that problem or opportunity (plus relevant constraints and other
considerations)
Use the work system framework to summarize the work system
Gather relevant data.
Analyze using design characteristics, measures of performance, and work system principles.
Identify possibilities for improvement.
Decide what to recommend
Justify the recommendation using relevant metrics and work system principles.
In contrast to systems analysis and design methods for IT professionals who need to produce a rigorous,
totally consistent definition of a computerized system, the work system method:
encourages the user to decide how deep to go
makes explicit use of the work system framework and work system life cycle model
makes explicit use of work system principles.
makes explicit use of characteristics and metrics for the work system and its elements.
includes work system participants as part of the system (not just users of the software)
includes codified and non-codified information
includes IT and non-IT technologies.
suggests that recommendations specify which work system improvements rely on IS changes, which
recommended work system changes dont rely on IS changes, and which recommended IS changes
wont affect the work systems operational form.
References[edit]
Alter, S. (2002) The Work System Method for Understanding Information Systems and Information
Systems Research, Communications of the Association for Information Systems 9(9), Sept., pp. 90
104, http://cais.aisnet.org/articles/default.asp?vol=9&art=6
Alter, S. (2003) 18 Reasons Why IT-Reliant Work Systems Should Replace The IT Artifact as the Core
Subject Matter of the IS Field, Communications of the Association for Information Systems, 12(23), Oct.,
pp. 365-394, http://cais.aisnet.org/articles/default.asp?vol=12&art=23
Alter, S. (2006) The Work System Method: Connecting People, Processes, and IT for Business Results,
Larkspur, CA: Work System Press.
Bostrom, R.P. and J.S. Heinen, (1977) MIS Problems and Failures: A Socio-Technical Perspective.
PART I: The Causes. MIS Quarterly, 1(3), December, pp. 1732.
Bostrom, R. P. and J. S. Heinen, (1977) MIS Problems and Failures: A Socio-Technical Perspective.
PART II: The Application of Socio-Technical Theory. MIS Quarterly, 1(4), December, pp. 1128.
Checkland, P. (1999) Systems Thinking, Systems Practice (Includes a 30-year retrospective), Chichester,
UK: John Wiley & Sons.
Hill, C., R. Yates, C. Jones, and S. L. Kogan, (2006) Beyond predictable workflows: Enhancing
productivity in artful business processes, IBM Systems Journal, 45(4), pp. 663682.
Markus, M.L. and J.Y. Mao (2004) Participation in Development and Implementation Updating an Old,
Tired Concept for Todays IS Contexts, Journal of the Association for Information Systems, Dec.,
pp. 514544.
Petersson, J. (2008) Work system principles: towards a justified design theory on the grounds of socio-
instrumental pragmatism, in Proceedings of the 3rd International Conference on the Pragmatic Web,
ACM International Conference Proceeding Series; Vol. 363, pp. 69
76. http://portal.acm.org/citation.cfm?id=1479190.1479200&coll=ACM&dl=ACM&CFID=22048689&CFTO
KEN=63832475
Petrie, D.E. (2004) Understanding the Impact of Technological Discontinuities on Information Systems
Management: The Case of Business-to-Business Electronic Commerce, Ph.D. Thesis, Claremont
Graduate University.
Ramiller, N. (2002) Animating the Concept of Business Process in the Core Course in Information
Systems, Journal of Informatics Education and Research, 3(2), pp. 53-71. viewed
at http://iaim.aisnet.org/jier/V3N2/
Sumner, M. and T. Ryan (1994). The Impact of CASE: Can it achieve critical success factors? Journal of
Systems Management, 45(6), p. 16, 6 pages.


A business process or business method is a collection of related,
structured activities or tasks that produce a specific service or product
(serve a particular goal) for a particular customer or customers. It often can
be visualized with a flowchart as a sequence of activities with interleaving
decision points or with a Process Matrix as a sequence of activities with
relevance rules based on the data in the process.

There are three types of business processes:
1. Management processes, the processes that govern the operation of a system. Typical
management processes include "corporate governance" and "strategic management".
2. Operational processes, processes that constitute the core business and create the
primary value stream. Typical operational processes
are purchasing, manufacturing,advertising and marketing, and sales.
3. Supporting processes, which support the core processes. Examples
include accounting, recruitment, call center, technical support.
A business process begins with a mission objective and ends with achievement
of the business objective.
Process-oriented organizations break down the barriers of structural departments and try to
avoid functional silos.
A business process can be decomposed into several sub-processes,
[1]
which have their own attributes,
but also contribute to achieving the goal of the super-process. The analysis of business processes
typically includes the mapping of processes and sub-processes down to activity level.
Business Processes are designed to add value for the customer and should not include unnecessary
activities. The outcome of a well designed business process is increased effectiveness (value for the
customer) and increased efficiency (less costs for the company).
Business Processes can be modeled through a large number of methods and techniques. For instance,
the Business Process Modeling Notation is a Business Process Modelingtechnique that can be used for
drawing business processes in a workflow.

Business Process Model and Notation (BPMN) is a standard for business process modeling that provides
a graphical notation for specifying business processes in a Business Process Diagram (BPD),
[2]
based on
a flowcharting technique very similar to activity diagrams from Unified Modeling Language (UML).
[3]
The
objective of BPMN is to supportbusiness process management, for both technical users and business
users, by providing a notation that is intuitive to business users, yet able to represent complex process
semantics. The BPMN specification also provides a mapping between the graphics of the notation and
the underlying constructs of execution languages, particularly Business Process Execution
Language (BPEL).
[4]

The primary goal of BPMN is to provide a standard notation readily understandable by all business
stakeholders. These include the business analysts who create and refine the processes, the technical
developers responsible for implementing them, and the business managers who monitor and manage
them. Consequently, BPMN serves as a common language, bridging the communication gap that
frequently occurs between business process design and implementation.
Currently there are several competing standards for business process modeling languages used by
modeling tools and processes.
[5]
Widespread adoption of the BPMN will help unify the expression of basic
business process concepts (e.g., public and private processes, choreographies), as well as advanced
process concepts (e.g., exception handling, transaction compensation).
BPMN topics[edit]
Scope[edit]
BPMN is constrained to support only the concepts of modeling applicable to business processes. Other
types of modeling done by organizations for non-process purposes are out of scope for BPMN. Examples
of modeling excluded from BPMN are:
Organizational structures
Functional breakdowns
Data models
[6]

In addition, while BPMN shows the flow of data (messages), and the association of data artifacts to
activities, it is not a data flow diagram.
Elements[edit]
BPMN models consist of simple diagrams constructed from a limited set of graphical elements. For both
business users and developers, they simplify understanding business activities' flow and process.
BPMN's four basic element categories are:
Flow objects
Events, activities, gateways
Connecting objects
Sequence flow, message flow, association
Swim lanes
Pool, lane
Artifacts
Data object, group, annotation
These four categories enable creation of simple business process diagrams (BPDs).
BPDs also permit making new types of flow object or artifact, to make the diagram more
understandable.
Flow objects and connecting objects[edit]

Event

Activity

Gateway

Connections
Flow objects are the main describing elements within BPMN, and consist of three core
elements: events, activities, and gateways.
Event
An Event is represented with a circle and denotes something that happens (compared with an
activity, which is something that is done). Icons within the circle denote the type of event (e.g., an
envelope representing a message, or a clock representing time). Events are also classified
as Catching (for example, if catching an incoming message starts a process) or Throwing (such
as throwing a completion message when a process ends).
Start event
Acts as a process trigger; indicated by a single narrow border, and can only be Catch, so is
shown with an open (outline) icon.
Intermediate event
Represents something that happens between the start and end events; is indicated by a double
border, and can Throw or Catch (using solid or open icons as appropriate). For example, a task
could flow to an event that throws a message across to another pool, where a subsequent event
waits to catch the response before continuing.
End event
Represents the result of a process; indicated by a single thick or bold border, and can
only Throw, so is shown with a solid icon.
Activity
An activity is represented with a rounded-corner rectangle and describes the kind of work which
must be done.
Task
A task represents a single unit of work that is not or cannot be broken down to a further level of
business process detail without diagramming the steps in a procedure (which is not the purpose
of BPMN)
Sub-process
Used to hide or reveal additional levels of business process detail. When collapsed, a sub-
process is indicated by a plus sign against the bottom line of the rectangle; when expanded, the
rounded rectangle expands to show all flow objects, connecting objects, and artifacts.
Has its own self-contained start and end events; sequence flows from the parent process must
not cross the boundary.
Transaction
A form of sub-process in which all contained activities must be treated as a whole; i.e., they must
all be completed to meet an objective, and if any one of them fails, they must all be compensated
(undone). Transactions are differentiated from expanded sub-processes by being surrounded by
a double border.
Call Activity
A point in the process where a global process or a global Task is reused. A call activity is
differentiated from other activity types by a bolded border around the activity area.
Gateway
A gateway is represented with a diamond shape and determines forking and merging of paths,
depending on the conditions expressed.
Exclusive
Used to create alternative flows in a process because only one of the paths can be taken, it is
called exclusive
Event Based
The condition determining the path of a process is based on an evaluated event.
Parallel
Used to create parallel paths without evaluating any conditions.
Inclusive
Used to create alternative flows where all paths are evaluated.
Exclusive Event Based
An event is being evaluated to determine which of mutually exclusive paths will be taken
Complex
used to model complex synchronization behavior
Parallel Event Based
Two parallel process are started based on an event but there is no evaluation of the event
Connections
Flow objects are connected to each other using Connecting objects,
which are of three types: sequences, messages, and associations.
Sequence Flow
A Sequence Flow is represented with a solid line and arrowhead, and shows in which order the
activities are performed. The sequence flow may also have a symbol at its start, a small diamond
indicates one of a number of conditional flows from an activity, while a diagonal slash indicates
the default flow from a decision or activity with conditional flows.
Message Flow
A Message Flow is represented with a dashed line, an open circle at the start, and an open
arrowhead at the end. It tells us what messages flow across organizational boundaries (i.e.,
between pools). A message flow can never be used to connect activities or events within the
same pool.
Association
An Association is represented with a dotted line. It is used to associate an Artifact or text to a
Flow Object, and can indicate some directionality using an open arrowhead (toward the artifact to
represent a result, from the artifact to represent an input, and both to indicate it is read and
updated). No directionality is used when the Artifact or text is associated with a sequence or
message flow (as that flow already shows the direction).
Swimlanes and artifacts[edit]

Swimlanes

Data objects

Groups

Annotation
Swim lanes are a visual mechanism of
organising and categorising activities, based
on cross functional flowcharting, and in BPMN
consist of two types:
Pool
Represents major participants in a process, typically separating different organisations. A pool
contains one or more lanes (like a real swimming pool). A pool can be open (i.e., showing internal
detail) when it is depicted as a large rectangle showing one or more lanes, or collapsed (i.e.,
hiding internal detail) when it is depicted as an empty rectangle stretching the width or height of
the diagram.
Lane
Used to organise and categorise activities within a pool according to function or role, and
depicted as a rectangle stretching the width or height of the pool. A lane contains the flow objects,
connecting objects and artifacts.
Artifacts allow developers to bring
some more information into the
model/diagram. In this way the
model/diagram becomes more readable.
There are three pre-defined Artifacts
and they are:
Data objects: Data objects show the
reader which data is required or
produced in an activity.
Group: A Group is represented with
a rounded-corner rectangle and
dashed lines. The group is used to
group different activities but does
not affect the flow in the diagram.
Annotation: An annotation is used to
give the reader of the
model/diagram an understandable
impression.
Examples of business
process diagrams[edit]
Click on small images for full-size
version

Discussion cycle

E-mail voting process

Collect votes
BPMN 2.0[edit]
The vision of BPMN 2.0 is to have one
single specification for a new Business
Process Model and Notation that
defines the notation, metamodel and
interchange format but with a modified
name that still preserves the "BPMN"
brand. The features include
Aligning BPMN with the business
process definition meta
model BPDM to form a single
consistent language
Enabling the exchange of business
process models and their diagram
layouts among process modeling
tools to preserve semantic integrity
Expand BPMN to allow model
orchestrations and choreographies
as stand-alone or integrated models
Support the display and interchange
of different perspectives on a model
that allow a user to focus on specific
concerns
Serialize BPMN and provide XML
schemes for model transformation
and to extend BPMN towards
business modeling and executive
decision support.
The final version of the specification was
released in January, 2011.
[7]

Comparison of BPMN
versions[edit]

This
section may be
too technical f
or most
readers to
understand. Pl
ease
help improve th
is section
to make it
understandable
to non-experts,
without
removing the
technical
details.
The talk
page may
contain
suggestions. (D
ecember 2012)
Attributes BPMN 1.0 BPMN 1.1 BPMN 1.2 BPMN 2.0 Beta 1
Consortiu
m
BPMI OMG OMG OMG
Date of
release
May 2004 January 2008 January 2009 August 2009
Models
Collaborative (public) B2B processes,
internal (private) business processes.
collaborative
(public) B2Bprocesses,
internal (private) business
processes,
a choreography expected
behavior between two or more
business participants,
collaborations, which is a
collection of participants and
their interaction and
a conversation the logical
relation of message
exchanges.
event
start (none,
message, timer,
rule, link, multiple)
intermediate (none
, message, timer,
error, cancel,
compensation, rule,
link, multiple)
end (none,
message, error,
cancel,
compensation, link,
terminate, multiple)
start (none, message,
timer, conditional, signal,
multiple)
intermediate (none,
message, timer, error,
cancel, compensation,
conditional, link, signal,
multiple)
end (none, message,
error, cancel,
compensation,
signal,terminate, multiple)
start
top-level (none, message,
timer, conditional, signal,
multiple, parallel multiple)
event sub-process
interrupting(message,
timer, escalation,
conditional, error,
compensation, signal,
multiple, parallel multiple)
event sub-process non-
interrupting(message,
timer, escalation,
conditional, signal,
multiple, parallel multiple)
intermediate
catching (message, timer,
conditional, link, signal,
multiple, parallel multiple)
boundary
interrupting(message,
timer, escalation,
conditional, error, cancel,
compensation, signal,
multiple, parallel multiple)
boundary non-
interrupting(message,
timer, escalation,
conditional, signal,
multiple, parallel multiple,
terminate)
throwing (none, message,
escalation, link,
compensation, signal,
multiple, parallel multiple)
end (none, message,
escalation, error, cancel,
compensation, signal, multiple,
terminate)
activity
task (atomic)
process/sub-process (nonatomic)
collapsed sub-process
expanded sub-process
task (atomic)
choreography task
collapsed choreography
sub-process
expanded choreography
sub-process
process/sub-
process(nonatomic)
collapsed sub-process
expanded sub-process
gateway
XOR exclusive
decision and
merging. both data-
based and event-
based. data-based
can be shown with
or without the "x"
marker.
OR inclusive
decision and
merging
complex complex
conditions and
situations
AND forking and
joining
exclusive decision and
merging. both data-based
and event-based. data-
based can be shown with
or without the "x" marker.
inclusive decision and
merging.
complex complex
conditions and situations.
parallel forking and
joining.
exclusive decision and
merging. both data-based and
event-based. exclusive can be
shown with or without the "x"
marker.
inclusive gateway decision
and merging
complex gateway complex
conditions and situations
parallel gateway forking and
joining
sequence
flow
normal flow
uncontrolled flow
conditional flow
default flow
exception flow
message
flow
message flow
association association
pool pool
lane lane
data
objects
data object
data object
collection
data input
data output
groups group
annotation
s
annotations
message / / / message
other
elements
looping
activity looping
sequence flow looping
multiple instances
process break
transactions
nested/embedded sub-process
off-page connector
compensation association
looping
activity looping
sequence flow looping
multiple instances
process break
transactions
nested/embedded sub-process
off-page connector
compensation association
communication
(subcommunication)
communication link
Number of
all
elements
48 55 55 116
Major
changes
/
The new
specificati
on
introduce
s a
categoriz
ation of
event
triggers
into
"catching"
and
"throwing"
events.
I.e. there
are two
kinds of
intermedi
The BPMN 1.2
minor revision
changes
consist of
editorial
corrections
and
implementatio
n bug fixes.
Consequently,
these minor
changes affect
modeling tool
vendors more
than modelers
(users).
[8]

Choreographies
Choreographies-model
Conversation-model
Complete Metamodel
BPMN Core
BPMN ExecutionSemantics
BPMN BPEL Mapping
XPDL (BPMN XMLSerialization
)
Diagram Interchange
Elements For Abstraction
Callable Element
Call Activity
Global Task
Gateways (Updated)
Exclusive/Parallel Event-
based Gateway (they
ate
message
events
now
one kind
responsib
le for
reception
of
message
s
("catching
") and
one kind
responsib
le for
sending
message
s
("throwing
").
In
addition
to the old
types, it
introduce
s a new
type,
thesignal
event.
Start and
end link
events do
not exist
any
stand at the beginning of
the process)
Tasks/SubProcesses
(Updated)
Event-Subprocess (Used
to handle events in the
bounding subprocess)
BusinessRule task
Sequential Multi-Instance
Activity
Service Task
Artifacts (Updated)
Data Objects (Collection,
Data Input, Data Output)
longer in
BPMN
1.1.
The old
"rule
events"
where
renamed
to conditi
onal
events.
The
semantic
s and
appearan
ce have
not
changed.
The
event-
based
gateway
in BPMN
1.1 looks
slightly
different
to what it
looked
like in
1.0.
Instead of
the
hexagona
l star it
now has
a
pentagon
in its
center.
The same
shape is
also used
for the
multiple
events
(start,
intermedi
ate, end).
There is
an
additional
line
separatin
g your
lane's
descriptio
n from its
content.

Types of BPMN sub-model[edit]
Business process modeling is used to communicate a wide variety of information to a wide variety
of audiences. BPMN is designed to cover this wide range of usage and allows modeling of end-
to-end business processes to allow the viewer of the Diagram to be able to easily differentiate
between sections of a BPMN Diagram. There are three basic types of sub-models within an end-
to-end BPMN model: Private (internal) business processes, Abstract (public) processes, and
Collaboration (global) processes:
Private (internal) business processes
Private business processes are those internal to a specific organization and are the type of
processes that have been generally called workflow or BPM processes. If swim lanes are used
then a private business process will be contained within a single Pool. The Sequence Flow of the
Process is therefore contained within the Pool and cannot cross the boundaries of the Pool.
Message Flow can cross the Pool boundary to show the interactions that exist between separate
private business processes.
Abstract (public) processes
This represents the interactions between a private business process and another process or
participant. Only those activities that communicate outside the private business process are
included in the abstract process. All other internal activities of the private business process are
not shown in the abstract process. Thus, the abstract process shows to the outside world the
sequence of messages that are required to interact with that business process. Abstract
processes are contained within a Pool and can be modeled separately or within a larger BPMN
Diagram to show the Message Flow between the abstract process activities and other entities. If
the abstract process is in the same Diagram as its corresponding private business process, then
the activities that are common to both processes can be associated.
Collaboration (global)
processes
A collaboration process depicts the interactions between two or more business entities. These
interactions are defined as a sequence of activities that represent the message exchange
patterns between the entities involved. Collaboration processes may be contained within a Pool
and the different participant business interactions are shown as Lanes within the Pool. In this
situation, each Lane would represent two participants and a direction of travel between them.
They may also be shown as two or more Abstract Processes interacting through Message Flow
(as described in the previous section). These processes can be modeled separately or within a
larger BPMN Diagram to show the Associations between the collaboration process activities and
other entities. If the collaboration process is in the same Diagram as one of its corresponding
private business process, then the activities that are common to both processes can be
associated.
Within and between these three BPMN sub-models, many types of Diagrams can be created. The
following are the types of business processes that can be modeled with BPMN (those with asterisks may
not map to an executable language):
High-level private process activities (not functional breakdown)*
Detailed private business process
As-is or old business process*
To-be or new business process
Detailed private business process with interactions to one or more external entities (or Black Box
processes)
Two or more detailed private business processes interacting
Detailed private business process relationship to Abstract Process
Detailed private business process relationship to Collaboration Process
Two or more Abstract Processes*
Abstract Process relationship to Collaboration Process*
Collaboration Process only (e.g., ebXML BPSS or RosettaNet)*
Two or more detailed private business processes interacting through their Abstract Processes and/or a
Collaboration Process
BPMN is designed to allow all the above types of Diagrams. However, it should be cautioned that if too
many types of sub-models are combined, such as three or more private processes with message flow
between each of them, then the Diagram may become too hard for someone to understand. Thus, we
recommend that the modeler pick a focused purpose for the BPD, such as a private process, or a
collaboration process.
Weaknesses of BPMN[edit]
The weaknesses of BPMN could relate to:
ambiguity and confusion in sharing BPMN models
support for routine work
support for knowledge work, and
converting BPMN models to executable environments
BPEL and BPMN[edit]
The BPMN specification includes an informal and partial mapping from BPMN to BPEL 1.1. A more
detailed mapping of BPMN to BPEL has been implemented in a number of tools, including an open-
source tool known as BPMN2BPEL. However, the development of these tools has exposed fundamental
differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to
generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-
to-BPEL round-tripengineering: generating BPEL code from BPMN diagrams and maintaining the
original BPMN model and the generated BPEL code synchronized, in the sense that any modification to
one is propagated to the other.
[citation needed]

See also[edit]
BPEL
Business Process Management
Business Process Modeling
Comparison of Business Process Modeling Notation tools
Event-driven Process Chains
Function model
Functional Software Architecture
Workflow
Workflow patterns
XPDL
YAWL
References[edit]
1. Jump up^ "BPMN Information". Retrieved 2011-03-29.
2. Jump up^ An XML Representation for Crew Procedures, Richard C. Simpson (2004), Final Report NASA
Faculty Fellowship Program (Johnson Space Center)
3. Jump up^ Process Modeling Notations and Workflow Patterns, paper by Stephen A. White of IBM
Corporation (2006)
4. Jump up^ Stephen A. White (3 May 2004). "Business Process Modeling Notation v1.0". for the Business
Process Management Initiative (BPMI)
5. Jump up^ "Business Process Modeling FAQ". Retrieved 2011-03-29.
6. Jump up^ OMG. "BPMN Working Draft". Retrieved 2012-05-01.
7. Jump up