Companies law

From Wikipedia, the free encyclopedia

(Redirected from Types of business units)
Jump to: navigation, search
The examples and perspective in this article may not represent a worldwide view
of the subject. Please improve this article and discuss the issue on the talk page.
(August 2010)

Companies law

Company

Business

Business entities

Sole proprietorship

Partnership

Corporation

Cooperative

European Union / EEA

EEIG

SCE

SE

SPE

UK / Ireland / Commonwealth

Community interest company

Limited company

by guarantee

by shares

Proprietary

o
o

Public

Unlimited company
United States

Benefit corporation

C corporation

Series LLC

LLC

LLLP

S corporation

Delaware corporation
Delaware statutory trust

Massachusetts business trust

Nevada corporation

Additional entities

AB

AG

ANS

A/S

AS
GmbH

K.K.

N.V.

Oy

S.A.

more

Doctrines

Business judgment rule

Corporate governance

De facto corporation and corporation by estoppel

Internal affairs doctrine

Limited liability

Piercing the corporate veil

Rochdale Principles

Ultra vires

Corporate laws

United States

Canada

United Kingdom

Germany

France
South Africa

Australia

Vietnam

Related areas

Civil procedure

Contract

Companies law (or the law of business associations) is the field of law concerning
companies and other business organizations. This includes corporations, partnerships and
other associations which usually carry on some form of economic or charitable activity. The
most prominent kind of company, usually referred to as a "corporation", is a "juristic person",
i.e. it has separate legal personality, and those who invest money into the business have
limited liability for any losses the company makes, governed by corporate law. The largest
companies are usually publicly listed on stock exchanges around the world. Even single
individuals, also known as sole traders may incorporate themselves and limit their liability in
order to carry on a business. All different forms of companies depend on the particular law of
the particular country in which they reside.
The law of business organizations originally derived from the common law of England, but
has evolved significantly in the 20th century. In common law countries today, the most
commonly addressed forms are:

Corporation

Limited company

Unlimited company

Limited liability partnership

Limited partnership

Not-for-profit corporation

Company limited by guarantee

Partnership

Sole Proprietorship

The proprietary limited company is a statutory business form in several countries, including
Australia.
Many countries have forms of business entity unique to that country, although there are
equivalents elsewhere. Examples are the limited liability company (LLC) and the limited
liability limited partnership (LLLP) in the United States.
Other types of business organizations, such as cooperatives, credit unions and publicly owned
enterprises, can be established with purposes that parallel, supersede, or even replace the
profit maximization mandate of business corporations.
For a country-by-country listing of officially recognized forms of business organization, see
Types of business entity.
There are various types of company that can be formed in different jurisdictions, but the most
common forms of company are:

a company limited by guarantee. Commonly used where companies are formed for
non-commercial purposes, such as clubs or charities. The members guarantee the
payment of certain (usually nominal) amounts if the company goes into insolvent
liquidation, but otherwise they have no economic rights in relation to the company .

a company limited by guarantee with a share capital. A hybrid entity, usually used
where the company is formed for non-commercial purposes, but the activities of the
company are partly funded by investors who expect a return.

a company limited by shares. The most common form of company used for business
ventures.

an unlimited company either with or without a share capital. This is a hybrid

company, a company similar to its limited company (Ltd.) counterpart but where the
members or shareholders do not benefit from limited liability should the company
ever go into formal liquidation.

There are, however, many specific categories of corporations and other business
organizations which may be formed in various countries and jurisdictions throughout the
world.

Contents

1 US companies law

2 Companies law theory

3 Companies law study

4 See also

5 Notes

6 References

7 External links

US companies law
In the United States, corporations are generally incorporated, or organized, under the laws of
a particular state. The corporate law of a corporation's state of incorporation generally
governs that corporation's internal governance (even if the corporation's operations take place
outside of that state). The corporate laws of the various states differ - in some cases
significantly - from state to state. Because of these differences, corporate lawyers are often
consulted in an effort to determine the most appropriate or advantageous state in which to
incorporate, and a majority of public companies in the U.S. are Delaware corporations.[1] The
federal laws of the United States and local law may also be applicable sources of corporate
law.

Companies law theory

A corporation is described to be a person in a political capacity created by the law, to endure
in perpetual succession.[2] Americans in the 1790s knew of a variety of corporations
established for various purposes, including those of commerce, education, and religion. As
the law of corporations was articulated by the Supreme Court under Chief Justice Marshall,
over the first several decades of the new American state, emphasis fell, in a way which seems
natural to us today, upon commercial corporations. Nonetheless, Wilson believed that, in all
cases, corporations should be erected with caution, and inspected with care. The actions of
corporations were clearly circumscribed: To every corporation a name must be assigned; and
by that name alone it can perform legal acts. For non-binding external actions or
transactions, corporations enjoyed the same latitude as private individuals; but it was with an
eye to internal affairs that many saw principal advantage in incorporation. The power of
making by-laws was tacitly annexed to corporations by the very act of their
establishment.[2] While they must not directly contradict the overarching laws of the land,
the central or local government cannot be expected to regulate toward the peculiar
circumstances of a given body, and so they are invested with authority to make regulations
for the management of their own interests and affairs.[2]

The question then arises: if corporations are to be inspected with care, what - if not the
commercial or social conduct, or the by-laws - is to be inspected and by whom? Do
corporations have duties? Yes: The general duties of every corporation may be collected
from the nature and design of its institution: it should act agreeably to its nature, and fulfill
the purposes for which it was formed.[2] Who sees that corporations are living up to those
duties? The law has provided proper persons with proper powers to visit those institutions,
and to correct every irregularity, which may arise within them.[2] The Common Law
provided for inspection by the court of kings bench. In 1790, at least, the powers of the
court of king's bench [were] vested in the supreme court of Pennsylvania.[2] As for the
dissolution of corporations, there seems not to have been much question that a corporation
might surrender its legal existence into the hands of that power, from which it was received.
From such a surrender, the dissolution of the body corporate ensues.[2] Nor does there seem
to have been much question that by a judgment of forfeiture against a corporation itself, it
may be dissolved.[2] However, Supreme Court Justice Wilson, lecturing in his unofficial
capacity, at least, suggests his displeasure with the doctrine that corporate dissolution cannot
be predicated by a judgment of ouster against individuals. God forbid such is the
sentiment of Mr. Justice Wilmot that the rights of the body should be lost or destroyed by
the offenses of the members.[2]
As theorists such as Ronald Coase have pointed out, all business organizations represent an
attempt to avoid certain costs associated with doing business. Each is meant to facilitate the
contribution of specific resources - investment capital, knowledge, relationships, and so forth
- towards a venture which will prove profitable to all contributors. Except for the partnership,
all business forms are designed to provide limited liability to both members of the
organization and external investors. Business organizations originated with agency law,
which permits an agent to act on behalf of a principal, in exchange for the principal assuming
equal liability for the wrongful acts committed by the agent. For this reason, all partners in a
typical general partnership may be held liable for the wrongs committed by one partner.
Those forms that provide limited liability are able to do so because the state provides a
mechanism by which businesses that follow certain guidelines will be able to escape the full
liability imposed under agency law. The state provides these forms because it has an interest
in the strength of the companies that provide jobs and services therein, but also has an interest
in monitoring and regulating their behavior.

Companies law study

Law schools typically offer either a single upper level course on business organizations, or
offer several courses covering different aspects of this area of law. The area of study
examines issues such as how each major form of business entity may be formed, operated,
and dissolved; the degree to which limited liability protects investors; the extent to which a
business can be held liable for the acts of an agent of the business; the relative advantages
and disadvantages of different types of business organizations, and the structures established
by governments to monitor the buying and selling of ownership interests in large
corporations.
The basic theory behind all business organizations is that, by combining certain functions
within a single entity, a business (usually called a firm by economists) can operate more
efficiently, and thereby realize a greater profit. Governments seek to facilitate investment in
profitable operations by creating rules that protect investors in a business from being held

personally liable for debts incurred by that business, either through mismanagement, or
because of wrongful acts committed by the business[citation needed].

See also

Business ethics

Corporate crime

Corporate law

Corporation sole

European Company Statute

Business process
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Not to be confused with business strategy.
This article needs additional citations for verification. Please help
improve this article by adding citations to reliable sources. Unsourced
material may be challenged and removed. (September 2010)

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.
Contents

1 Overview

2 History
o

2.1 Adam Smith

2.2 Other definitions

3 Importance of the Process Chain

4 Policies, Processes and Procedures

5 Manual / Administrative vs. Computer System-Based Internal Controls

6 Information Reports as an Essential Base for Executing Business

Processes

7 Supporting theories and concepts

o

7.1 Span of control

7.2 Information management concepts

8 See also

9 References

10 Further reading

Overview

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 Modeling technique
that can be used for drawing business processes in a workflow.
History
Adam Smith

One of the most significant people in 18th century to describe processes was Adam Smith in
his famous (1776) example of a pin factory. Inspired by an article in Diderot's Encyclopdie,
Smith described the production of a pin in the following way:
One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth
grinds it at the top for receiving the head: to make the head requires two or three distinct
operations: to put it on is a particular business, to whiten the pins is another ... and the
important business of making a pin is, in this manner, divided into about eighteen distinct
operations, which in some manufactories are all performed by distinct hands, though in others
the same man will sometime perform two or three of them.
Smith also first recognized how the output could be increased through the use of labor
division. Previously, in a society where production was dominated by handcrafted goods, one
man would perform all the activities required during the production process, while Smith

described how the work was divided into a set of simple tasks, which would be performed by
specialized workers. The result of labor division in Smiths example resulted in productivity
increasing by 24,000 percent (sic), i.e. that the same number of workers made 240 times as
many pins as they had been producing before the introduction of labor division.
It is worth noting that Smith did not advocate labor division at any price and per se. The
appropriate level of task division was defined through experimental design of the production
process. In contrast to Smith's view which was limited to the same functional domain and
comprised activities that are in direct sequence in the manufacturing process, today's process
concept includes cross-functionality as an important characteristic. Following his ideas the
division of labor was adopted widely, while the integration of tasks into a functional, or
cross-functional, process was not considered as an alternative option until much later.
Other definitions

In the early 1990s, US corporations, and subsequently companies all over the world, started
to adopt the concept of reengineering in an attempt to re-achieve the competitiveness that
they had lost during the previous decade. A key characteristic of Business Process
Reengineering (BPR) is the focus on business processes. Davenport (1993)[2] defines a
(business) process as:
a structured, measured set of activities designed to produce a specific output for a particular
customer or market. It implies a strong emphasis on how work is done within an
organization, in contrast to a product focuss emphasis on what. A process is thus a specific
ordering of work activities across time and space, with a beginning and an end, and clearly
defined inputs and outputs: a structure for action. ... Taking a process approach implies
adopting the customers point of view. Processes are the structure by which an organization
does what is necessary to produce value for its customers.
This definition contains certain characteristics a process must possess. These characteristics
are achieved by a focus on the business logic of the process (how work is done), instead of
taking a product perspective (what is done). Following Davenport's definition of a process we
can conclude that a process must have clearly defined boundaries, input and output, that it
consists of smaller parts, activities, which are ordered in time and space, that there must be a
receiver of the process outcome- a customer - and that the transformation taking place within
the process must add customer value.
Hammer & Champys (1993)[3] definition can be considered as a subset of Davenports. They
define a process as:
a collection of activities that takes one or more kinds of input and creates an output that is of
value to the customer.
As we can note, Hammer & Champy have a more transformation oriented perception, and put
less emphasis on the structural component process boundaries and the order of activities in
time and space.

Rummler & Brache (1995)[4] use a definition that clearly encompasses a focus on the
organizations external customers, when stating that
a business process is a series of steps designed to produce a product or service. Most
processes (...) are cross-functional, spanning the white space between the boxes on the
organization chart. Some processes result in a product or service that is received by an
organization's external customer. We call these primary processes. Other processes produce
products that are invisible to the external customer but essential to the effective management
of the business. We call these support processes.
The above definition distinguishes two types of processes, primary and support processes,
depending on whether a process is directly involved in the creation of customer value, or
concerned with the organizations internal activities. In this sense, Rummler and Brache's
definition follows Porter's value chain model, which also builds on a division of primary and
secondary activities. According to Rummler and Brache, a typical characteristic of a
successful process-based organization is the absence of secondary activities in the primary
value flow that is created in the customer oriented primary processes. The characteristic of
processes as spanning the white space on the organization chart indicates that processes are
embedded in some form of organizational structure. Also, a process can be cross-functional,
i.e. it ranges over several business functions.
Finally, let us consider the process definition of Johansson et al. (1993).[5] They define a
process as:
a set of linked activities that take an input and transform it to create an output. Ideally, the
transformation that occurs in the process should add value to the input and create an output
that is more useful and effective to the recipient either upstream or downstream.
This definition also emphasizes the constitution of links between activities and the
transformation that takes place within the process. Johansson et al. also include the upstream
part of the value chain as a possible recipient of the process output. Summarizing the four
definitions above, we can compile the following list of characteristics for a business process:
1. Definability : It must have clearly defined boundaries, input and output.
2. Order : It must consist of activities that are ordered according to their
position in time and space.
3. Customer : There must be a recipient of the process' outcome, a customer.
4. Value-adding : The transformation taking place within the process must
add value to the recipient, either upstream or downstream.
5. Embeddedness : A process can not exist in itself, it must be embedded in
an organizational structure.

6. Cross-functionality : A process regularly can, but not necessarily must,

span several functions.

Frequently, a process owner, i.e. a person being responsible for the performance and
continuous improvement of the process, is also considered as a prerequisite...
Importance of the Process Chain

Business processes comprise a set of sequential sub-processes or tasks, with alternative paths
depending on certain conditions as applicable, performed to achieve a given objective or
produce given outputs. Each process has one or more needed inputs. The inputs and outputs
may be received from, or sent to other business processes, other organizational units, or
internal or external stakeholders.
Business processes are designed to be operated by one or more business functional units, and
emphasize the importance of the process chain rather than the individual units.
In general, the various tasks of a business process can be performed in one of two ways
1. manually and
2. by means of business data processing systems such as ERP systems.

Typically, some process tasks will be manual, while some will be computer-based, and these
tasks may be sequenced in many ways. In other words, the data and information that are
being handled through the process may pass through manual or computer tasks in any given
order.
Policies, Processes and Procedures

The above improvement areas are equally applicable to policies, processes and detailed
procedures (sub-processes/tasks). There is a cascading effect of improvements made at a
higher level on those made at a lower level.
For instance, if a recommendation to replace a given policy with a better one is made with
proper justification and accepted in principle by business process owners, then corresponding
changes in the consequent processes and procedures will follow naturally in order to enable
implementation of the policies
Manual / Administrative vs. Computer System-Based Internal Controls

Internal controls can be built into manual / administrative process steps and / or computer
system procedures.
It is advisable to build in as many system controls as possible, since these controls, being
automatic, will always be exercised since they are built into the design of the business system
software. For instance, an error message preventing an entry of a received raw material

quantity exceeding the purchase order quantity by greater than the permissible tolerance
percentage will always be displayed and will prevent the system user from entering such a
quantity.
However, for various reasons such as practicality, the need to be flexible (whatever that
may signify), lack of business domain knowledge and experience, difficulties in
designing/writing software, cost of software development/modification, the incapability of a
computerised system to provide controls, etc., all internal controls otherwise considered to be
necessary are often not built into business systems and software.
In such a scenario, the manual, administrative process controls outside the computer system
should be clearly documented, enforced and regularly exercised. For instance, while entering
data to create a new record in a material system databases item master table, the only internal
control that the system can provide over the item description field is not to allow the user to
leave the description blank in other words, configure item description as a mandatory field.
The system obviously cannot alert the user that the description is wrongly spelt,
inappropriate, nonsensical, etc.
In the absence of such a system-based internal control, the item creation process must include
a suitable administrative control through the detailed checking, by a responsible officer, of all
fields entered for the new item, by comparing a print-out taken from the system with the item
data entry sheet, and ensuring that any corrections in the item description (and other similar
fields where no system control is possible) are promptly carried out.
Last but not least, the introduction of effective manual, administrative controls usually
requires an overriding periodic check by a higher authority to ensure that such controls are
exercised in the first place.
Information Reports as an Essential Base for Executing Business Processes

Business processes must include up-to-date and accurate reports to ensure effective action.
An example of this is the availability of purchase order status reports for supplier delivery
follow-up as described in the section on effectiveness above. There are numerous examples
of this in every possible business process.
Another example from production is the process of analysis of line rejections occurring on
the shop floor. This process should include systematic periodical analysis of rejections by
reason, and present the results in a suitable information report that pinpoints the major
reasons, and trends in these reasons, for management to take corrective actions to control
rejections and keep them within acceptable limits. Such a process of analysis and
summarisation of line rejection events is clearly superior to a process which merely inquires
into each individual rejection as it occurs.
Business process owners and operatives should realise that process improvement often occurs
with introduction of appropriate transaction, operational, highlight, exception or M.I.S.

reports, provided these are consciously used for day-to-day or periodical decision-making.
With this understanding would hopefully come the willingness to invest time and other
resources in business process improvement by introduction of useful and relevant reporting
systems.
Supporting theories and concepts

Frederick Winslow Taylor developed the concept of scientific management. The concept
contains aspects on the division of labor being relevant to the theory and practice around
business processes. The business process related aspects of Taylor's scientific management
concept are discussed in the article on Business Process Reengineering.
Span of control

The span of control is the number of sub-ordinates a supervisor manages within a structural
organization. Introducing a business process concept has a considerable impact on the
structural elements of the organization and thus also on the span of control.
Large organizations that are not organized as markets need to be organized in smaller units departments - which can be defined according to different principles.
Information management concepts

Information Management and the organization design strategies being related to it, are a
theoretical cornerstone of the business process concept.
See also

Business analysis

Business Process Automation

Business Process Definition Metamodel

Business process improvement

Business process management

Business process mapping

Business process modeling

Business Process Modeling Notation

Business process outsourcing

Business process reengineering

Business process reengineering

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Business Process Reengineering Cycle

Business process re-engineering is a business management strategy, originally pioneered in

the early 1990s, focusing on the analysis and design of workflows and processes within an
organization. BPR aimed to help organizations fundamentally rethink how they do their work
in order to dramatically improve customer service, cut operational costs, and become worldclass competitors.[1] In the mid-1990s, as many as 60% of the Fortune 500 companies claimed
to either have initiated reengineering efforts, or to have plans to do so.[2]
BPR seeks to help companies radically restructure their organizations by focusing on the
ground-up design of their business processes. According to Davenport (1990) a business
process is a set of logically related tasks performed to achieve a defined business outcome.
Re-engineering emphasized a holistic focus on business objectives and how processes related
to them, encouraging full-scale recreation of processes rather than iterative optimization of
subprocesses.[1]
Business process re-engineering is also known as business process redesign, business
transformation, or business process change management.
Contents

1 Overview

2 History
o

2.1 Reengineering Work: Don't Automate, Obliterate, 1990

2.2 Development after 1995

3 Business process reengineering topics

o

3.1 The role of information technology

3.2 Research and methodology

4 BPR success & failure factors

o

4.1 Organization wide commitment

4.2 BPR team composition

4.3 Business needs analysis

4.4 Adequate IT infrastructure

4.5 Effective change management

4.6 Ongoing Continuous Improvement

5 Critique

6 See also

7 References

8 Further reading

9 External links

Overview

Reengineering guidance and relationship of Mission and Work Processes to

Information Technology.

Business Process Re-engineering (BPR) is basically rethinking and radically redesigning an

organization's existing resources. BPR, however, is more than just business improvising; it is
an approach for redesigning the way work is done to better support the organization's mission
and reduce costs. Reengineering starts with a high-level assessment of the organization's
mission, strategic goals, and customer needs. Basic questions are asked, such as "Does our
mission need to be redefined? Are our strategic goals aligned with our mission? Who are our
customers?" An organization may find that it is operating on questionable assumptions,
particularly in terms of the wants and needs of its customers. Only after the organization
rethinks what it should be doing, does it go on to decide how best to do it.[1]
Within the framework of this basic assessment of mission and goals, re-engineering focuses
on the organization's business processesthe steps and procedures that govern how resources
are used to create products and services that meet the needs of particular customers or
markets. As a structured ordering of work steps across time and place, a business process can
be decomposed into specific activities, measured, modeled, and improved. It can also be
completely redesigned or eliminated altogether. Re-engineering identifies, analyzes, and redesigns an organization's core business processes with the aim of achieving dramatic
improvements in critical performance measures, such as cost, quality, service, and speed.[1]
Re-engineering recognizes that an organization's business processes are usually fragmented
into subprocesses and tasks that are carried out by several specialized functional areas within
the organization. Often, no one is responsible for the overall performance of the entire
process. Re-engineering maintains that optimizing the performance of subprocesses can result
in some benefits, but cannot yield dramatic improvements if the process itself is
fundamentally inefficient and outmoded. For that reason, re-engineering focuses on redesigning the process as a whole in order to achieve the greatest possible benefits to the
organization and their customers. This drive for realizing dramatic improvements by
fundamentally re-thinking how the organization's work should be done distinguishes reengineering from process improvement efforts that focus on functional or incremental
improvement.[1]
History

Business process re-engineering (BPR) began as a private sector technique to help

organizations fundamentally rethink how they do their work in order to dramatically improve
customer service, cut operational costs, and become world-class competitors. A key stimulus
for re-engineering has been the continuing development and deployment of sophisticated
information systems and networks. Leading organizations are becoming bolder in using this
technology to support innovative business processes, rather than refining current ways of
doing work.[1]

Reengineering Work: Don't Automate, Obliterate, 1990

In 1990, Michael Hammer, a former professor of computer science at the Massachusetts

Institute of Technology (MIT), published the article "Reengineering Work: Don't Automate,
Obliterate" in the Harvard Business Review, in which he claimed that the major challenge for
managers is to obliterate forms of work that do not add value, rather than using technology
for automating it.[3] This statement implicitly accused managers of having focused on the
wrong issues, namely that technology in general, and more specifically information
technology, has been used primarily for automating existing processes rather than using it as
an enabler for making non-value adding work obsolete.
Hammer's claim was simple: Most of the work being done does not add any value for
customers, and this work should be removed, not accelerated through automation. Instead,
companies should reconsiditors, their inability to satisfy customer needs, and their
insufficient cost structure[citation needed]. Even well established management thinkers, such as
Peter Drucker and Tom Peters, were accepting and advocating BPR as a new tool for
(re-)achieving success in a dynamic world.[4] During the following years, a fast growing
number of publications, books as well as journal articles, were dedicated to BPR, and many
consulting firms embarked on this trend and developed BPR methods. However, the critics
were fast to claim that BPR was a way to dehumanize the work place, increase managerial
control, and to justify downsizing, i.e. major reductions of the work force,[5] and a rebirth of
Taylorism under a different label.
Despite this critique, reengineering was adopted at an accelerating pace and by 1993, as many
as 60% of the Fortune 500 companies claimed to either have initiated reengineering efforts,
or to have plans to do so.[2] This trend was fueled by the fast adoption of BPR by the
consulting industry, but also by the study Made in America,[6] conducted by MIT, that showed
how companies in many US industries had lagged behind their foreign counterparts in terms
of competitiveness, time-to-market and productivity.
Development after 1995

With the publication of critiques in 1995 and 1996 by some of the early BPR proponents[citation
needed]
, coupled with abuses and misuses of the concept by others, the reengineering fervor in
the U.S. began to wane. Since then, considering business processes as a starting point for
business analysis and redesign has become a widely accepted approach and is a standard part
of the change methodology portfolio, but is typically performed in a less radical way as
originally proposed.
More recently, the concept of Business Process Management (BPM) has gained major
attention in the corporate world and can be considered as a successor to the BPR wave of the
1990s, as it is evenly driven by a striving for process efficiency supported by information
technology. Equivalently to the critique brought forward against BPR, BPM is now
accused[citation needed] of focusing on technology and disregarding the people aspects of change.
Business process reengineering topics

The most notable definitions of reengineering are:

"... the fundamental rethinking and radical redesign of business processes

to achieve dramatic improvements in critical contemporary modern
measures of performance, such as cost, quality, service, and speed." [7]

"encompasses the envisioning of new work strategies, the actual process

design activity, and the implementation of the change in all its complex
technological, human, and organizational dimensions." [8]

BPR is different from other approaches to organization development (OD), especially the
continuous improvement or TQM movement, by virtue of its aim for fundamental and radical
change rather than iterative improvement.[9] In order to achieve the major improvements BPR
is seeking for, the change of structural organizational variables, and other ways of managing
and performing work is often considered as being insufficient. For being able to reap the
achievable benefits fully, the use of information technology (IT) is conceived as a major
contributing factor. While IT traditionally has been used for supporting the existing business
functions, i.e. it was used for increasing organizational efficiency, it now plays a role as
enabler of new organizational forms, and patterns of collaboration within and between
organizations[citation needed].
BPR derives its existence from different disciplines, and four major areas can be identified as
being subjected to change in BPR - organization, technology, strategy, and people - where a
process view is used as common framework for considering these dimensions.
Business strategy is the primary driver of BPR initiatives and the other dimensions are
governed by strategy's encompassing role. The organization dimension reflects the structural
elements of the company, such as hierarchical levels, the composition of organizational units,
and the distribution of work between them[citation needed]. Technology is concerned with the use of
computer systems and other forms of communication technology in the business. In BPR,
information technology is generally considered as playing a role as enabler of new forms of
organizing and collaborating, rather than supporting existing business functions. The people /
human resources dimension deals with aspects such as education, training, motivation and
reward systems. The concept of business processes - interrelated activities aiming at creating
a value added output to a customer - is the basic underlying idea of BPR. These processes are
characterized by a number of attributes: Process ownership, customer focus, value adding,
and cross-functionality.
The role of information technology

Information technology (IT) has historically played an important role in the reengineering
concept.[10] It is considered by some as a major enabler for new forms of working and
collaborating within an organization and across organizational borders[citation needed].
BPR literature [11] identified several so called disruptive technologies that were supposed to
challenge traditional wisdom about how work should be performed.

Shared databases, making information available at many places

Expert systems, allowing generalists to perform specialist tasks

Telecommunication networks, allowing organizations to be centralized and

decentralized at the same time

Decision-support tools, allowing decision-making to be a part of

everybody's job

Wireless data communication and portable computers, allowing field

personnel to work office independent

Interactive videodisk, to get in immediate contact with potential buyers

Automatic identification and tracking, allowing things to tell where they

are, instead of requiring to be found

High performance computing,and school, allowing on-the-fly planning and

revisioning

In the mid-1990s, especially workflow management systems were considered as a significant

contributor to improved process efficiency. Also ERP (Enterprise Resource Planning)
vendors, such as SAP, JD Edwards, Oracle, PeopleSoft, positioned their solutions as vehicles
for business process redesign and improvement.
Research and methodology

Model based on PRLC approach

Although the labels and steps differ slightly, the early methodologies that were rooted in ITcentric BPR solutions share many of the same basic principles and elements. The following
outline is one such model, based on the PRLC (Process Reengineering Life Cycle) approach
developed by Guha.[12] Simplified schematic outline of using a business process approach,
exemplified for pharmaceutical R&D

1. Structural organization with functional units

2. Introduction of New Product Development as cross-functional process
3. Re-structuring and streamlining activities, removal of non-value adding
tasks

Benefiting from lessons learned from the early adopters, some BPR practitioners advocated a
change in emphasis to a customer-centric, as opposed to an IT-centric, methodology. One
such methodology, that also incorporated a Risk and Impact Assessment to account for the
impact that BPR can have on jobs and operations, was described by Lon Roberts (1994).[13]
Roberts also stressed the use of change management tools to proactively address resistance to
changea factor linked to the demise of many reengineering initiatives that looked good on
the drawing board.
Some items to use on a process analysis checklist are: Reduce handoffs, Centralize data,
Reduce delays, Free resources faster, Combine similar activities. Also within the management
consulting industry, a significant number of methodological approaches have been developed.
[14]

BPR success & failure factors

Over the past years, BPR projects and efforts have revealed some interesting findings for
both academics and practitioners. Some BPR researchers have focused on key factors in the
BPR process that enabled a successful outcome. Many lessons were learned and many
elements were identified as essential to the success of a BPR activity. Some important BPR
success factors, which will be discussed in further details later, include, but are not limited to
the following:
1. Organization wide commitment.
2. BPR team composition.
3. Business needs analysis.
4. Adequate IT infrastructure.
5. Effective change management.
6. Ongoing continuous improvement

Generally, BPR does not only mean change, but rather dramatic change. The constituents of
this drastic change include the overhaul of organizational structures, management systems,
employee responsibilities and performance measurements, incentive systems, skills
development, and the use of IT. BPR can potentially impact every aspect of how business is
conducted today. Change on this scale can cause results ranging from enviable success to
complete failure. In spite of the depth of change involved in undertaking BPR efforts, a recent

survey showed that some 88 percent of CIOs were satisfied with the end result of BPR
efforts.[15] Successful BPR can result in enormous reductions in cost or cycle time. It can also
potentially create substantial improvements in quality, customer service, or other business
objectives. The promise of BPR is not empty; it can actually produce revolutionary
improvements for business operations. Reengineering can help an aggressive company to stay
on top, or transform an organization on the verge of bankruptcy into an effective competitor.
The successes have spawned international interest, and major reengineering efforts are now
being conducted around the world.[16]
On the other hand, BPR projects can fail to meet the inherently high expectations of
reengineering. In 1998, it was reported that only 30 percent of reengineering projects were
regarded as successful.[17] The earlier promise of BPR has not been fulfilled as some
organizations have put forth extensive BPR efforts only to achieve marginal, or even
negligible, benefits. Other organizations have succeeded only in destroying the morale and
momentum built up over their lifetime. These failures indicate that reengineering involves a
great deal of risk. Even so, many companies are willing to take that risk because the rewards
can be astounding.[16]
Many unsuccessful BPR attempts may have been due to the confusion surrounding BPR, and
how it should be performed. Organizations were well aware that changes needed to be made,
but did not know which areas to change or how to change them. As a result, process
reengineering is a management concept that has been formed by trial and error or, in other
words, practical experience. As more and more businesses reengineer their processes,
knowledge of what caused the successes or failures is becoming apparent.[16] To reap lasting
benefits, companies must be willing to examine how strategy and reengineering complement
each other by learning to quantify strategy in terms of cost, milestones, and timetables, by
accepting ownership of the strategy throughout the organization, by assessing the
organizations current capabilities and process realistically, and by linking strategy to the
budgeting process. Otherwise, BPR is only a short-term efficiency exercise.[18]
Organization wide commitment

There is no doubt that major changes to business processes have a direct impact on processes,
technology, job roles, and workplace culture. Significant changes to even one of those areas
require resources, money, and leadership. Changing them simultaneously is an extraordinary
task.[16] Like any large and complex undertaking, implementing reengineering requires the
talents and energies of a broad spectrum of experts. Since BPR can involve multiple areas
within the organization, it is extremely important to get support from all affected
departments. Through the involvement of selected department members, the organization can
gain valuable input before a process is implemented; a step which promotes both the
cooperation and the vital acceptance of the reengineered process by all segments of the
organization.
Getting enterprise wide commitment involves the following: top management sponsorship,
bottom-up buy-in from process users, dedicated BPR team, and budget allocation for the total

solution with measures to demonstrate value. Before any BPR project can be implemented
successfully, there must be a commitment to the project by the management of the
organization, and strong leadership must be provided.[19] Reengineering efforts can by no
means be exercised without a company-wide commitment to the goals to be achieved.
However, top management sponsorship is imperative for success.[20] Commitment and
leadership in the upper echelons of management are often cited as the most important factors
of a successful BPR project.[21] Top management must recognize the need for change, develop
a complete understanding of what is BPR, and plan how to achieve it.[15]
Leadership has to be effective, strong, visible, and creative in thinking and understanding in
order to provide a clear vision to the future.[22] Convincing every affected group within the
organization of the need for BPR is a key step in successfully implementing a process. By
informing all affected groups at every stage, and emphasizing the positive end results of the
reengineering process, it is possible to minimize resistance to change and increase the odds
for success. The ultimate success of BPR depends on the strong, consistent, and continuous
involvement of all departmental levels within the organization. It also depends on the people
who do it and how well they can be motivated to be creative and to apply their detailed
knowledge to the redesign of business processes.[23]
BPR team composition

Once organization wide commitment has been secured from all departments involved in the
reengineering effort and at different levels, the critical step of selecting a BPR team must be
taken. This team will form the nucleus of the BPR effort, make key decisions and
recommendations, and help communicate the details and benefits of the BPR program to the
entire organization. The determinants of an effective BPR team may be summarized as
follows:

competency of the members of the team, their motivation, [24]

their credibility within the organization and their creativity, [25]

team empowerment, training of members in process mapping and

brainstorming techniques,[26]

effective team leadership,[27]

proper organization of the team,[28]

complementary skills among team members, adequate size,

interchangeable accountability, clarity of work approach, and

specificity of goals.[29]

The most effective BPR teams include active representatives from the following work
groups: top management, business area responsible for the process being addressed,
technology groups, finance, and members of all ultimate process users groups. Team

members who are selected from each work group within the organization will have an impact
on the outcome of the reengineered process according to their desired requirements. The BPR
team should be mixed in depth and knowledge. For example, it may include members with
the following characteristics:

Members who do not know the process at all.

Members who know the process inside-out.

Customers, if possible.

Members representing impacted departments.

One or two members of the best, brightest, passionate, and committed

technology experts.

Members from outside of the organization

[20]

Moreover, Covert (1997) recommends that in order to have an effective BPR team, it must be
kept under ten players. If the organization fails to keep the team at a manageable size, the
entire process will be much more difficult to execute efficiently and effectively. The efforts of
the team must be focused on identifying breakthrough opportunities and designing new work
steps or processes that will create quantum gains and competitive advantage.[15]
Business needs analysis

Another important factor in the success of any BPR effort is performing a thorough business
needs analysis. Too often, BPR teams jump directly into the technology without first
assessing the current processes of the organization and determining what exactly needs
reengineering. In this analysis phase, a series of sessions should be held with process owners
and stakeholders, regarding the need and strategy for BPR. These sessions build a consensus
as to the vision of the ideal business process. They help identify essential goals for BPR
within each department and then collectively define objectives for how the project will
impact each work group or department on individual basis and the business organization as a
whole. The idea of these sessions is to conceptualize the ideal business process for the
organization and build a business process model. Those items that seem unnecessary or
unrealistic may be eliminated or modified later on in the diagnosing stage of the BPR project.
It is important to acknowledge and evaluate all ideas in order to make all participants feel that
they are a part of this important and crucial process. Results of these meetings will help
formulate the basic plan for the project.
This plan includes the following:

identifying specific problem areas,

solidifying particular goals, and

defining business objectives.

The business needs analysis contributes tremendously to the reengineering effort by helping
the BPR team to prioritize and determine where it should focus its improvements efforts.[20]
The business needs analysis also helps in relating the BPR project goals back to key business
objectives and the overall strategic direction for the organization. This linkage should show
the thread from the top to the bottom of the organization, so each person can easily connect
the overall business direction with the reengineering effort. This alignment must be
demonstrated from the perspective of financial performance, customer service, associate
value, and the vision for the organization.[16] Developing a business vision and process
objectives relies, on the one hand, on a clear understanding of organizational strengths,
weaknesses, and market structure, and on the other, on awareness and knowledge about
innovative activities undertaken by competitors and other organizations.[30]
BPR projects that are not in alignment with the organizations strategic direction can be
counterproductive. There is always a possibility that an organization may make significant
investments in an area that is not a core competency for the company and later outsource this
capability. Such reengineering initiatives are wasteful and steal resources from other strategic
projects. Moreover, without strategic alignment, the organizations key stakeholders and
sponsors may find themselves unable to provide the level of support the organization needs in
terms of resources, especially if there are other more critical projects to the future of the
business, and are more aligned with the strategic direction.[16]
Adequate IT infrastructure

Researchers consider adequate IT infrastructure reassessment and composition as a vital

factor in successful BPR implementation.[22] Hammer (1990) prescribes the use of IT to
challenge the assumptions inherent in the work process that have existed since long before
the advent of modern computer and communications technology.[31] Factors related to IT
infrastructure have been increasingly considered by many researchers and practitioners as a
vital component of successful BPR efforts.[32]

Effective alignment of IT infrastructure and BPR strategy,

building an effective IT infrastructure,

adequate IT infrastructure investment decision,

adequate measurement of IT infrastructure effectiveness,

proper information systems (IS) integration,

effective reengineering of legacy IS,

increasing IT function competency, and

effective use of software tools are the most important factors that
contribute to the success of BPR projects.

These are vital factors that contribute to building an effective IT infrastructure for business
processes.[22] BPR must be accompanied by strategic planning which addresses leveraging IT
as a competitive tool.[33] An IT infrastructure is made up of physical assets, intellectual assets,
shared services,[34] and their linkages.[35] The way in which the IT infrastructure components
are composed and their linkages determines the extent to which information resources can be
delivered. An effective IT infrastructure composition process follows a top-down approach,
beginning with business strategy and IS strategy and passing through designs of data,
systems, and computer architecture.[36]
Linkages between the IT infrastructure components, as well as descriptions of their contexts
of interaction, are important for ensuring integrity and consistency among the IT
infrastructure components.[32] Furthermore, IT standards have a major role in reconciling
various infrastructure components to provide shared IT services that are of a certain degree of
effectiveness to support business process applications, as well as to guide the process of
acquiring, managing, and utilizing IT assets.[35] The IT infrastructure shared services and the
human IT infrastructure components, in terms of their responsibilities and their needed
expertise, are both vital to the process of the IT infrastructure composition. IT strategic
alignment is approached through the process of integration between business and IT
strategies, as well as between IT and organizational infrastructures.[22]
Most analysts view BPR and IT as irrevocably linked. Walmart, for example, would not have
been able to reengineer the processes used to procure and distribute mass-market retail goods
without IT. Ford was able to decrease its headcount in the procurement department by 75
percent by using IT in conjunction with BPR, in another well-known example.[33] The IT
infrastructure and BPR are interdependent in the sense that deciding the information
requirements for the new business processes determines the IT infrastructure constituents,
and a recognition of IT capabilities provides alternatives for BPR.[32] Building a responsive IT
infrastructure is highly dependent on an appropriate determination of business process
information needs. This, in turn, is determined by the types of activities embedded in a
business process, and their sequencing and reliance on other organizational processes.[37]
Effective change management

Al-Mashari and Zairi (2000) suggest that BPR involves changes in people behavior and
culture, processes, and technology. As a result, there are many factors that prevent the
effective implementation of BPR and hence restrict innovation and continuous improvement.
Change management, which involves all human and social related changes and cultural
adjustment techniques needed by management to facilitate the insertion of newly designed
processes and structures into working practice and to deal effectively with resistance,[26] is
considered by many researchers to be a crucial component of any BPR effort.[38] One of the
most overlooked obstacles to successful BPR project implementation is resistance from those
whom implementers believe will benefit the most. Most projects underestimate the cultural
impact of major process and structural change and as a result, do not achieve the full potential
of their change effort. Many people fail to understand that change is not an event, but rather a
management technique.

Change management is the discipline of managing change as a process, with due

consideration that employees are people, not programmable machines.[16] Change is implicitly
driven by motivation which is fueled by the recognition of the need for change. An important
step towards any successful reengineering effort is to convey an understanding of the
necessity for change.[20] It is a well-known fact that organizations do not change unless people
change; the better change is managed, the less painful the transition is.
Organizational culture is a determining factor in successful BPR implementation.[39]
Organizational culture influences the organizations ability to adapt to change. Culture in an
organization is a self-reinforcing set of beliefs, attitudes, and behavior. Culture is one of the
most resistant elements of organizational behavior and is extremely difficult to change. BPR
must consider current culture in order to change these beliefs, attitudes, and behaviors
effectively. Messages conveyed from management in an organization continually enforce
current culture. Change is implicitly driven by motivation which is fueled by the recognition
of the need for change.
The first step towards any successful transformation effort is to convey an understanding of
the necessity for change.[20] Management rewards system, stories of company origin and early
successes of founders, physical symbols, and company icons constantly enforce the message
of the current culture. Implementing BPR successfully is dependent on how thoroughly
management conveys the new cultural messages to the organization.[19] These messages
provide people in the organization with a guideline to predict the outcome of acceptable
behavior patterns. People should be the focus for any successful business change.
BPR is not a recipe for successful business transformation if it focuses on only computer
technology and process redesign. In fact, many BPR projects have failed because they did not
recognize the importance of the human element in implementing BPR. Understanding the
people in organizations, the current company culture, motivation, leadership, and past
performance is essential to recognize, understand, and integrate into the vision and
implementation of BPR. If the human element is given equal or greater emphasis in BPR, the
odds of successful business transformation increase substantially.[19]
Ongoing Continuous Improvement

Many organizational change theorists hold a common view of organizations adjusting

gradually and incrementally and responding locally to individual crises as they arise [20]
Common elements are:

BPR is a successive and ongoing process and should be regarded as an

improvement strategy that enables an organization to make the move
from traditional functional orientation to one that aligns with strategic
business processes.[30]

Continuous improvement is defined as the propensity of the organization

to pursue incremental and innovative improvements in its processes,
products, and services.[20] The incremental change is governed by the
knowledge gained from each previous change cycle.

It is essential that the automation infrastructure of the BPR activity

provides for performance measurements in order to support continuous
improvements. It will need to efficiently capture appropriate data and
allow access to appropriate individuals.

To ensure that the process generates the desired benefits, it must be

tested before it is deployed to the end users. If it does not perform
satisfactorily, more time should be taken to modify the process until it
does.

A fundamental concept for quality practitioners is the use of feedback

loops at every step of the process and an environment that encourages
constant evaluation of results and individual efforts to improve. [40]

At the end users level, there must be a proactive feedback mechanism

that provides for and facilitates resolutions of problems and issues. This
will also contribute to a continuous risk assessment and evaluation which
are needed throughout the implementation process to deal with any risks
at their initial state and to ensure the success of the reengineering efforts.

Anticipating and planning for risk handling is important for dealing

effectively with any risk when it first occurs and as early as possible in the
BPR process.[41] It is interesting that many of the successful applications of
reengineering described by its proponents are in organizations practicing
continuous improvement programs.

Hammer and Champy (1993) use the IBM Credit Corporation as well as
Ford and Kodak, as examples of companies that carried out BPR
successfully due to the fact that they had long-running continuous
improvement programs.[40]

In conclusion, successful BPR can potentially create substantial improvements in the way
organizations do business and can actually produce fundamental improvements for business
operations. However, in order to achieve that, there are some key success factors that must be
taken into consideration when performing BPR.
BPR success factors are a collection of lessons learned from reengineering projects and from
these lessons common themes have emerged. In addition, the ultimate success of BPR
depends on the people who do it and on how well they can be committed and motivated to be
creative and to apply their detailed knowledge to the reengineering initiative. Organizations
planning to undertake BPR must take into consideration the success factors of BPR in order
to ensure that their reengineering related change efforts are comprehensive, wellimplemented, and have minimum chance of failure.
Critique

Many companies used reengineering as an pretext to downsize their companies dramatically,

though this was not the intent of reengineering's proponents; consequently, reengineering
earned a reputation for being synonymous with downsizing and layoffs.[42]

In many circumstances, reengineering has not always lived up to its expectations. Some
prominent reasons include:

Reengineering assumes that the factor that limits an organization's

performance is the ineffectiveness of its processes (which may or may not
be true) and offers no means of validating that assumption.

Reengineering assumes the need to start the process of performance

improvement with a "clean slate," i.e. totally disregard the status quo.

According to Eliyahu M. Goldratt (and his Theory of Constraints)

reengineering does not provide an effective way to focus improvement
efforts on the organization's constraint [citation needed].

Others have claimed that reengineering was a recycled buzzword for commonly-held ideas.
Abrahamson (1996) argued that fashionable management terms tend to follow a lifecycle,
which for Reengineering peaked between 1993 and 1996 (Ponzi and Koenig 2002). They
argue that Reengineering was in fact nothing new (as e.g. when Henry Ford implemented the
assembly line in 1908, he was in fact reengineering, radically changing the way of thinking in
an organization).
The most frequent critique against BPR concerns the strict focus on efficiency and
technology and the disregard of people in the organization that is subjected to a reengineering
initiative. Very often, the label BPR was used for major workforce reductions. Thomas
Davenport, an early BPR proponent, stated that:
"When I wrote about "business process redesign" in 1990, I explicitly said that using it for
cost reduction alone was not a sensible goal. And consultants Michael Hammer and James
Champy, the two names most closely associated with reengineering, have insisted all along
that layoffs shouldn't be the point. But the fact is, once out of the bottle, the reengineering
genie quickly turned ugly." [43]
Hammer similarly admitted that:
"I wasn't smart enough about that. I was reflecting my engineering background and was
insufficient appreciative of the human dimension. I've learned that's critical." [44]
See also

Business Process Management

Business Process Improvement

Business Process Modeling Notation (BPMN)

Kaizen

Process improvement

Workflow

References
This article incorporates public domain material from the United States General
Accounting Office document "Business Process Re-engineering Assessment Guide, May
1997".
1.

^ a b c d e f Business Process Re-engineering Assessment Guide, United States

General Accounting Office, May 1997.

2.

^ a b Hamscher, Walter: "AI in Business-Process Reengineering", AI Magazine

Voume 15 Number 4, 1994

3.

^ (Hammer 1990)

4.

^ Forbes: Reengineering, The Hot New Managing Tool, August 23, 1993

5.

^ (Greenbaum 1995, Industry Week 1994)

6.

^ Michael L. Dertouzos, Robert M. Solow and Richard K. Lester (1989)

Made In America: Regaining the Productive Edge". MIT press.

7.

^ Hammer and Champy (1993)

8.

^ Thomas H. Davenport (1993)

9.

^ Johansson et al. (1993): "Business Process Reengineering, although a close

relative, seeks radical rather than merely continuous improvement. It escalates the
efforts of JIT and TQM to make process orientation a strategic tool and a core
competence of the organization. BPR concentrates on core business processes, and
uses the specific techniques within the JIT and TQM toolboxes as enablers, while
broadening the process vision."

10.

^ Business efficiency: IT can help paint a bigger picture, Financial Times,

featuring Ian Manocha, Lynne Munns and Andy Cross

11.

^ e.g. Hammer & Champy (1993),

12.

^ Guha et al. (1993)

13.

^ Lon Roberts (1994) Process reengineering: the key to achieving

breakthrough success.

14.

^ A set of short papers, outlining and comparing some of them can be found
here, followed by some guidelines for companies considering to contract a
consultancy for a BPR initiative:

Overview

Andersen Consulting (now Accenture)

Bain & Co.

Boston Consulting Group

McKinsey & Co.

Comparison

Guidelines for BPR consulting clients

15.

^ a b c (Motwani, et al., 1998)

16.

^ a b c d e f g (Covert, 1997)

17.

^ (Galliers, 1998)

18.

^ (Berman, 1994)

19.

^ a b c (Campbell & Kleiner, 1997)

20.

^ a b c d e f g (Dooley & Johnson, 2001)

21.

^ (Jackson, 1997)

22.

^ a b c d (Al-Mashari & Zairi, 1999)

23.

^ (King, 1994)

24.

^ (Rastogi, 1994)

25.

^ (Barrett, 1994)

26.

^ a b (Carr, 1993)

27.

^ (Berrington & Oblich, 1995)

28.

^ (Guha, et al., 1993)

29.

^ (Katzenbach & Smith, 1993)

30.

^ a b (Vakola & Rezgui, 2000)

31.

^ (Malhotra, 1998)

32.

^ a b c (Ross, 1998)

33.

^ a b (Weicher, et al., 1995)

34.

^ (Broadbent & Weill, 1997)

35.

^ a b (Kayworth, et al., 1997)

36.

^ (Malhotra, 1996)

37.

^ (Sabherwal & King, 1991)

38.

^ (Towers, 1996)

39.

^ (Zairi & Sinclair, 1995)

40.

^ a b (Gore, 1999)

41.

^ (Clemons, 1995)

42.

^ [1]

43.

^ (Davenport, 1995)

44.

^ (White, 1996)

Further reading

Abrahamson, E. (1996). Management fashion, Academy of Management Review, 21,

254-285.

Champy, J. (1995). Reengineering Management, Harper Business Books, New York.

Davenport, Thomas & Short, J. (1990), "The New Industrial Engineering: Information
Technology and Business Process Redesign", in: Sloan Management Review, Summer
1990, pp 1127

Davenport, Thomas (1993), Process Innovation: Reengineering work through

information technology, Harvard Business School Press, Boston

Davenport, Thomas (1995), Reengineering - The Fad That Forgot People, Fast
Company, November 1995.

Drucker, Peter (1972), "Work and Tools", in: W. Kranzberg and W.H. Davenport
(eds), Technology and Culture, New York

Dubois, H. F. W. (2002). "Harmonization of the European vaccination policy and the

role TQM and reengineering could play", Quality Management in Health Care, 10(2):
pp. 4757. "PDF"

Greenbaum, Joan (1995), Windows on the workplace, Cornerstone

Guha, S.; Kettinger, W.J. & Teng, T.C., Business Process Reengineering: Building a
Comprehensive Methodology, Information Systems Management, Summer 1993

Hammer, M., (1990). "Reengineering Work: Don't Automate, Obliterate", Harvard

Business Review, July/August, pp. 104112.

Hammer, M. and Champy, J. A.: (1993) Reengineering the Corporation: A Manifesto

for Business Revolution, Harper Business Books, New York, 1993. ISBN 0-06662112-7.

Hammer, M. and Stanton, S. (1995). "The Reengineering Revolution", Harper

Collins, London, 1995.

Hansen, Gregory (1993) "Automating Business Process Reengineering", Prentice

Hall.

Hussein, Bassam (2008), PRISM: Process Re-engineering Integrated Spiral Model,

VDM Verlag [2]

Industry Week (1994), "De-engineering the corporation", Industry Week article,

4/18/94

Johansson, Henry J. et al. (1993), Business Process Reengineering: BreakPoint

Strategies for Market Dominance, John Wiley & Sons

Leavitt, H.J. (1965), "Applied Organizational Change in Industry: Structural,

Technological and Humanistic Approaches", in: James March (ed.), Handbook of
Organizations, Rand McNally, Chicago

Loyd, Tom (1994), "Giants with Feet of Clay", Financial Times, Dec 5 1994, p 8

Malhotra, Yogesh (1998), "Business Process Redesign: An Overview", IEEE

Engineering Management Review, vol. 26, no. 3, Fall 1998.

Ponzi, L. and Koenig, M. (2002). "Knowledge management: another management

fad?", Information Research, 8(1).

"Reengineering Reviewed", (1994). The Economist, 2 July 1994, pp 66.

Roberts, Lon (1994), Process Reengineering: The Key To Achieving Breakthrough

Success, Quality Press, Milwaukee.

Rummler, Geary A. and Brache, Alan P. Improving Performance: How to Manage the
White Space in the Organization Chart, ISBN 0-7879-0090-7.

Taylor (1911), Frederick, The principles of scientific management, Harper & Row,
New York]

Thompson, James D. (1969), Organizations in Action, MacGraw-Hill, New York

White, JB (1996), Wall Street Journal. New York, N.Y.: Nov 26, 1996. pg. A.1

Business Process Redesign: An Overview, IEEE Engineering Management Review

External links
Wikimedia Commons has media related to Business Process Reengineering.

BPR Articles

[3] Reengineering relationship of Mission and Work Processes to Information

Technology.

BPR : Decision engineering in a strained industrial and business environment

Workflow
From Wikipedia, the free encyclopedia
Jump to: navigation, search
This article includes a list of references, but its sources remain unclear
because it has insufficient inline citations. Please help to improve this
article by introducing more precise citations. (April 2009)

A workflow consists of a sequence of connected steps where each step follows without delay
or gap and ends just before the subsequent step may begin. It is a depiction of a sequence of
operations, declared as work of a person or group,[1] an organization of staff, or one or more
simple or complex mechanisms. Workflow may be seen as any abstraction of real work. For
control purposes, workflow may be a view of real work in a chosen aspect,[2] thus serving as a
virtual representation of actual work. The flow being described may refer to a document or
product that is being transferred from one step to another.
Workflows may be viewed as one primitive building block to be combined with other parts of
an organisation's structure such as information silos, teams, projects, policies and hierarchies.
Contents

1 Related concept

2 Historical development
o

2.1 Beginnings in manufacturing

2.2 Maturation and growth

2.3 Quality era

3 Workflow management system

4 Examples

5 Features and phenomenology

6 Workflow improvement theories

7 Workflow components

8 Workflow applications

9 See also

10 References

11 Further reading

12 External links

Related concept

The concept of workflow is closely related to several fields in operations research and other
areas that study the nature of work, either quantitatively or qualitatively, such as artificial
intelligence (in particular, the sub-discipline of AI planning) and ethnography. The term
workflow is more commonly used in particular industries, such as printing and professional
domains, where it may have particular specialized meanings.
1. Processes: A process is a more specific notion than workflow and can
apply to physical or biological processes, for instance. In the context of
concepts surrounding work, a process may be distinguished from a
workflow by the fact that it has well-defined inputs, outputs and purposes,
while the notion of workflow may apply more generally to any systematic
pattern of activity (such as all processes occurring in a machine shop).
2. Planning and scheduling: A plan is a description of the logically
necessary, partially ordered set of activities required to accomplish a
specific goal given certain starting conditions. A plan, when augmented
with a schedule and resource allocation calculations, completely defines a
particular instance of systematic processing in pursuit of a goal. A
workflow may be viewed as an (often optimal or near-optimal) realization
of the mechanisms required to execute the same plan repeatedly.
3. Flow control is a control concept applied to workflows, to distinguish
from static control of buffers of material or orders, to mean a more
dynamic control of flow speed and flow volumes in motion and in process.
Such orientation to dynamic aspects is the basic foundation to prepare for
more advanced job shop controls, such as just-in-time or just-in-sequence.
4. In-transit visibility is a monitoring concept that applies to transported
material as well as to work in process or work in progress, i.e., workflows.
Historical development

The development of the concept of workflow occurred over a series of loosely defined,
overlapping, eras.
Beginnings in manufacturing

The modern history of workflows can be traced to Frederick Taylor[3] and H. Gantt. Rudolf
Laban and Warren Lamb contributed to this in England. Together, Taylor and Gantt launched
the study of the deliberate, rational organization of work in the context of manufacturing. The
types of workflow of concern to Taylor and his contemporaries primarily involved mass and
energy flows. These were studied and improved using time and motion studies. While the
assembly line remains the most famous example of a workflow from this era, the early
thinking around work was far more sophisticated than is commonly understood. The notion
of flow was more than a sequential breakdown of processing. The common conceptual

models of modern operations research, including flow shops, job shops and queuing systems,
[4]
can be found in early forms in early 20th century industry.
Information-based workflows began to grow during this era, although the concept of an
information flow lacked flexibility. A particularly influential figure was Melvil Dewey
(inventor of the eponymous Dewey Decimal System, who was also responsible for the
development of the hanging file folder)[citation needed]. This era is thus identified with the simplest
notions of workflow optimization: throughput and resource utilization.
The cultural impact of workflow optimization during this era can be understood through films
such as Chaplin's classic Modern Times. These concepts did not stay confined to the shop
floor. One magazine invited housewives to puzzle over the fastest way to toast three slices of
bread on a one-side, two-slice grill. The book Cheaper by the Dozen introduced the emerging
concepts to the context of family life.
Maturation and growth

The invention of the typewriter and the copier helped spread the study of the rational
organization of labor from the manufacturing shop floor to the office. Filing systems and
other sophisticated systems for managing physical information flows evolved. Two events
provided a huge impetus to the development of formalized information workflows. First, the
field of optimization theory matured and developed mathematical optimization techniques.
Second, World War II and the Apollo program were unprecedented in their demands for the
rational organization of work.
The classic management book The Organization Man, published in 1956, culturally captured
the nature of work in this era.
In 1995, the publishing industry studied how traditional publishing processes could be reengineered and streamlined into digital processes in order to reduce lagtime, as well as
substantial printing and shipping costs for delivering print copies of books and journals to
warehouses and subscribers. The term electronic workflow was used to describe the
publishing process, from online delivery of digital manuscripts to the posting of content on
the web for online access.
Quality era

During the 1980s, two aspects of workflow organization drew heavy criticism. First, the
methods pioneered by Taylor modeled humans as simple automata. The classical industrialstyle organization of work was critiqued as being both dehumanizing and suboptimal in its
use of the potential of human beings. Maslow's hierarchy of needs, which describes human
needs for self-actualization and creative engagement in work, became a popular tool in this
critique. This issue was acknowledged, but did not gain much traction otherwise.
The second critique had to do with quality. Workflows optimized for a particular time became
inflexible as work conditions changed. Quality, in both analytic and synthetic manifestations,
transformed the nature of work through a variety of movements ranging from total quality

management to Six Sigma, then to more qualitative notions of business process reengineering (Hammers and Champy, 1991). Under the influence of the quality movement,
workflows became the subject of much scrutiny and optimization efforts. Acknowledgement
of the dynamic and changing nature of the demands on workflows came in the form of
recognition of the phenomena associated with critical paths and moving bottlenecks.[5]
The experiences with the quality movement made it clear that information flows are
fundamentally different from the mass and energy flows; this inspired the first forms of
rational workflows. The low cost and adaptability of information flows were seen as enabling
workflows that were at once highly rational in their organization and highly flexible,
adaptable and responsive. These insights unleashed a whole range of information technology
at workflows in manufacturing, services and pure information work. Flexible manufacturing
systems, just-in-time inventory management, and other highly agile and adaptable systems of
workflow are products of this era.
Workflow management system

A workflow management system is a computer system that manages and defines a series of
tasks within an organization to produce a final outcome or outcomes. Workflow management
systems allow the user to define different workflows for different types of jobs or processes.
For example, in a manufacturing setting, a design document might be automatically routed
from designer to a technical director to the production engineer. At each stage in the
workflow, one individual or group is responsible for a specific task. Once the task is
complete, the workflow software ensures that the individuals responsible for the next task are
notified and receive the data they need to execute their stage of the process. Workflow
management systems also automate redundant tasks and ensure that uncompleted tasks are
followed up.
Workflow management systems may control automated processes in addition to replacing
paper work order transfers. For example, if the above design documents are now available as
AutoCAD but the workflow requires them as Catia, then an automated process would
implement the conversion prior to notifying the individual responsible for the next task. This
is the concept of dependencies. A workflow management system reflects the dependencies
required for the completion of each task, and aims at managing them during the execution of
each task [6]
Workflow management systems also appear in distributed IT environments such as Grid
Computing or Cloud Computing. The aim of such systems are to manage the execution of
various processes that may belong to the same application while in many cases they are used
as a means to guarantee the offered Quality of service (QoS).[7]
Examples

The following examples illustrate the variety of workflows seen in various contexts:

1. In machine shops, particularly job shops and flow shops, the flow of a part
through the various processing stations is a work flow.
2. Insurance claims processing is an example of an information-intensive,
document-driven workflow.
3. Wikipedia editing is an example of a stochastic workflow.
4. The Getting Things Done system is a model of personal workflow
management for information workers.
5. In global software development, the concept of follow-the-sun describes a
process of passing unfinished work across time zones.
6. In Traditional Offset and Digital Printing workflow is the process, people
and usually software technology (RIPs raster image processors or DFE
digital front end) controllers that play a part in pre/post processing of print
related files. e.g. PDF pre-flight checking to make sure fonts are embedded
or that the imaging output to plate or digital press will be able to render
the document intent properly for the image output capabilities of the press
that will print the final image.
7. In Scientific experiments, the overall process (tasks and data flow) can be
described as a Directed Acyclic Graph (DAG). This DAG is referred to as a
workflow, e.g. Brain Imaging workflows.[8][9]
8. In healthcare data analysis, a workflow can be used to represent a
sequence of steps which compose a complex data analysis (data search
and data manipulation steps).[10]
9. In Service-oriented architectures an application can be represented
through an executable workflow, where different, possibly geographically
distributed, service components interact to provide the corresponding
functionality, under the control of a Workflow Management System. [11][12]
Features and phenomenology
1. Modeling: Workflow problems can be modeled and analyzed using graphbased formalisms like Petri nets.
2. Measurement: Many of the concepts used to measure scheduling systems
in operations research are useful for measuring general workflows. These
include throughput, processing time, and other regular metrics.
3. Specialized connotations: The term workflow has specialized connotations
in information technology, document management and imaging. Since
1993, one trade consortium specifically focused on workflow management
and the interoperability of workflow management systems has been the
Workflow Management Coalition.
4. Scientific workflow system: Found wide acceptance in the fields of
bioinformatics and cheminformatics in the early 2000s, where they
successfully met the need for multiple interconnected tools, handling of

multiple data formats and large data quantities. Also, the paradigm of
scientific workflows was close to the well-established tradition of Perl
programming in life-science research organizations, so this adoption
represented a natural step forward towards a more structured
infrastructure setup.
5. Human-machine interaction: Several conceptualizations of mixed-initiative
workflows have been studied, particularly in the military, where
automated agents play roles just as humans do. For innovative, adaptive,
collaborative human work the techniques of human interaction
management are required.
6. Workflow analysis: Workflow systems allow users to develop executable
processes with no familiarity with formal programming concepts.
Automated workflow analysis techniques can help users analyze the
properties of user workflows to conduct verification of certain properties
before executing them, e.g. analyze flow control or data flow. Examples of
tools based on formal analysis frameworks have been developed and used
for the analysis of scientific workflows and can be extended to the analysis
of other types of workflows.[13]
Workflow improvement theories

The key driver to gain benefit from the understanding of the workflow process in a business
context is that the throughput of the workstream path is modelled in such a way as to evaluate
the efficiency of the flow route through internal silos with a view to increasing discrete
control of uniquely identified business attributes and rules and reducing potential low
efficiency drivers. Evaluation of resources, both physical and human is essential to evaluate
hand-off points and potential to create smoother transitions between tasks. Several workflow
improvement theories have been proposed and implemented in the modern workplace. These
include:
1. Six Sigma
2. Total Quality Management
3. Business Process Reengineering
4. Lean systems
5. Theory of Constraints
6. Neural Workflow

As a way of bridging the gap between the two, significant effort is being put into defining
workflow patterns that can be used to compare different workflow engines across both of
these domains.
Workflow components

A workflow can usually be described using formal or informal flow diagramming techniques,
showing directed flows between processing steps. Single processing steps or components of a
workflow can basically be defined by three parameters:
1. input description: the information, material and energy required to
complete the step
2. transformation rules, algorithms, which may be carried out by associated
human roles or machines, or a combination
3. output description: the information, material and energy produced by the
step and provided as input to downstream steps.

Components can only be plugged together if the output of one previous (set of) component(s)
is equal to the mandatory input requirements of the following component. Thus, the essential
description of a component actually comprises only in- and output that are described fully in
terms of data types and their meaning (semantics). The algorithms' or rules' description need
only be included when there are several alternative ways to transform one type of input into
one type of output possibly with different accuracy, speed, etc.
When the components are non-local services that are invoked remotely via a computer
network, such as Web services, additional descriptors (such as QoS and availability) also
must be considered.
Workflow applications
Main article: Workflow application

Many software systems exist to support workflows in particular domains. Such systems
manage tasks such as automatic routing, partially automated processing and integration
between different functional software applications and hardware systems that contribute to
the value-addition process underlying the workflow.
See also

Bioinformatics workflow management systems

Business process automation

Business process management

Business process modeling

Business-driven development

Computer-supported collaboration

Enterprise content management

Process architecture

Process-driven application

Project management

Scientific workflow system

Smart contracts

References
1.

Jump up ^ See e.g., ISO 12052:2006, ISO.org

2.

Jump up ^ See e.g., ISO/TR 16044:2004, ISO.org

3.

Jump up ^ Taylor, 1919

4.

Jump up ^ Pinedo, 2001

5.

Jump up ^ Goldratt, E., 1996

6.

Jump up ^ Li, Xiaorong, et al. "Design and Development of an

Adaptive Workflow-Enabled Spatial-Temporal Analytics Framework."
Parallel and Distributed Systems (ICPADS), 2012 IEEE 18th International
Conference on. IEEE, 2012.

7.

Jump up ^ An innovative workflow mapping mechanism for Grids

in the frame of Quality of Service, Elsevier.com

8.

Jump up ^ Brain Image Registration Analysis Workflow for fMRI

Studies on Global Grids, Computer.org

9.

Jump up ^ A grid workflow environment for brain imaging analysis

on distributed systems, Wiley.com

10.

Jump up ^ Huser, V.; Rasmussen, L. V.; Oberg, R.; Starren, J. B.

(2011). "Implementation of workflow engine technology to deliver basic
clinical decision support functionality". BMC Medical Research
Methodology 11: 43. doi:10.1186/1471-2288-11-43. PMC 3079703.
PMID 21477364. edit

11.

Jump up ^ Service-Oriented Architecture and Business Process

Choreography in an Order Management Scenario: Rationale, Concepts,
Lessons Learned, ACM.org

12.

Jump up ^ Workflow management for soft real-time interactive

applications in virtualized environments, Elsevier.com

13.

Jump up ^ Curcin, V.; Ghanem, M.; Guo, Y. (2010). "The design and
implementation of a workflow analysis tool". Philosophical Transactions of

the Royal Society A: Mathematical, Physical and Engineering Sciences 368

(1926): 4193. doi:10.1098/rsta.2010.0157. edit
Further reading

Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee (2009) Business Process
Management (BPM) Standards: A Survey. In: Business Process
Management Journal, Emerald Group Publishing Limited. Volume 15 Issue
5. ISSN 1463-7154. PDF

Khalid Belhajjame, Christine Collet, Genoveva Vargas-Solar: A Flexible

Workflow Model for Process-Oriented Applications. WISE (1) 2001, IEEE CS,
2001.

Marlon Dumas, Wil van der Aalst, Arthur ter Hofstede: Process-Aware
Information Systems, Wiley, ISBN 0-471-66306-9

Layna Fischer (ed.): 2007 BPM and Workflow Handbook, Future Strategies
Inc., ISBN 978-0-9777527-1-3

Layna Fischer: Workflow Handbook 2005, Future Strategies, ISBN 09703509-8-8

Layna Fischer: Excellence in Practice, Volume V: Innovation and Excellence

in Workflow and Business Process Management, ISBN 0-9703509-5-3

Thomas L. Friedman: The World Is Flat: A Brief History of the Twenty-first

Century, Farrar, Straus and Giroux, ISBN 0-374-29288-4

Keith Harrison-Broninski. Human Interactions: The Heart and Soul of

Business Process Management. ISBN 0-929652-44-4

Holly Yu: Content and Work Flow Management for Library Websites: Case
Studies, Information Science Publishing, ISBN 1-59140-534-3

Wil van der Aalst, Kees van Hee: Workflow Management: Models, Methods,
and Systems, B&T, ISBN 0-262-72046-9

Setrag Khoshafian, Marek Buckiewicz: Introduction to Groupware,

Workflow and Workgroup Computing, John Wiley & Sons, ISBN 0-47102946-7

Rashid N. Kahn: Understanding Workflow Automation: A Guide to

Enhancing Customer Loyalty, Prentice Hall, ISBN 0-13-061918-3

Dan C. Marinescu: Internet-Based Workflow Management: Towards a

Semantic Web, John Wiley & Sons, ISBN 0-471-43962-2

Frank Leymann, Dieter Roller: Production Workflow: Concepts and

Techniques, Prentice Hall, ISBN 0-13-021753-0

Michael Jackson, Graham Twaddle: Business Process Implementation:

Building Workflow Systems, Addison-Wesley, ISBN 0-201-17768-4

Alec Sharp, Patrick McDermott: Workflow Modeling, Artech House

Publishers, ISBN 1-58053-021-4

Toni Hupp: Designing Work Groups, Jobs, and Work Flow, Pfeiffer &
Company, ISBN 0-7879-0063-X

Gary Poyssick, Steve Hannaford: Workflow Reengineering, Adobe, ISBN 156830-265-7

Dave Chaffey: Groupware, Workflow and Intranets: Reengineering the

Enterprise with Collaborative Software, Digital Press, ISBN 1-55558-184-6

Wolfgang Gruber: Modeling and Transformation of Workflows With

Temporal Constraints, IOS Press, ISBN 1-58603-416-2

Andrzej Cichocki, Marek Rusinkiewicz, Darrell Woelk: Workflow and Process

Automation Concepts and Technology, Kluwer Academic Publishers, ISBN
0-7923-8099-1

Alan R. Simon, William Marion: Workgroup Computing: Workflow,

Groupware, and Messaging, McGraw-Hill, ISBN 0-07-057628-9

Penny Ann Dolin: Exploring Digital Workflow, Delmar Thomson Learning,

ISBN 1-4018-9654-5

Gary Poyssick: Managing Digital Workflow, Prentice Hall, ISBN 0-13010911-8

Frank J. Romano: PDF Printing & Workflow, Prentice Hall, ISBN 0-13020837-X

James G. Kobielus: Workflow Strategies, Hungry Minds, ISBN 0-7645-30127

Alan Rickayzen, Jocelyn Dart, Carsten Brennecke: Practical Workflow for

SAP, Galileo, ISBN 1-59229-006-X

Alan Pelz-Sharpe, Angela Ashenden: E-process: Workflow for the Ebusiness, Ovum, ISBN 1-902566-65-3

Stanislaw Wrycza: Systems Development Methods for Databases,

Enterprise Modeling, and Workflow Management, Kluwer Academic/Plenum
Publishers, ISBN 0-306-46299-0

Database Support for Workflow Management, Kluwer Academic Publishers,

ISBN 0-7923-8414-8

Matthew Searle: Developing With Oracle Workflow

V. Curcin and M. Ghanem Scientific workflow systems - can one size fit all?
paper in CIBEC'08 comparing scientific workflow systems.

External links
Look up workflow in Wiktionary, the free dictionary.

Workflow patterns

The State of Workflow May 2004 article by Tom Baeyens

Business Process Modelling vs. Workflow Management

Workflow Management Coalition

Simplifying Design of Complex Workflows

Business Process Model and Notation

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Example of a Business Process Model and Notation for a process with a normal
flow.

Business Process Model and Notation (BPMN) is a graphical representation for specifying
business processes in a business process model. It was previously known as Business Process
Modeling Notation.
Business Process Management Initiative (BPMI) developed BPMN, which has been
maintained by the Object Management Group since the two organizations merged in 2005. As
of March 2011, the current version of BPMN is 2.0.[1]
Contents

1 Overview

2 BPMN topics
o

2.1 Scope

2.2 Elements

2.3 Flow objects and connecting objects

2.4 Swimlanes and artifacts

2.5 Examples of business process diagrams

2.6 BPMN 2.0

3 Comparison of BPMN versions

4 Types of BPMN sub-model

5 Weaknesses of BPMN
o

5.1 BPEL and BPMN

6 See also

7 References

8 Further reading

9 External links

Overview

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 support business 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
Scope

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

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

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

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

Click on small images for full-size version

Discussion cycle

E-mail voting process

Collect votes
BPMN 2.0

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 standalone 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
This section may be too technical for most readers to understand.
Please help improve this section to make it understandable to non-experts,
without removing the technical details. The talk page may contain
suggestions. (December 2012)
Attribu
tes

BPMN 1.0

BPMN 1.1 BPMN 1.2

BPMN 2.0 Beta 1

Consort BPMI
ium

OMG

OMG

OMG

Date of May 2004

release

January
2008

January
2009

August 2009

Models

Collaborative (public) B2B

processes,

collaborative (public)
B2B processes,

internal (private) business

processes.

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.

start

event

start
(none,
message,
timer,
rule, link,
multiple)
intermed
iate
(none,
message,
timer,
error,
cancel,
compensa
tion, rule,
link,
multiple)
end
(none,
message,
error,
cancel,
compensa
tion, link,
terminate
, multiple)

start (none,
message, timer,
conditional,
signal, multiple)
intermediate
(none, message,
timer, error,
cancel,
compensation,
conditional, link,
signal, multiple)

top-level (none,
message, timer,
conditional,
signal, multiple,
parallel multiple)

event subprocess
interrupting
(message, timer,
escalation,
conditional,
error,
compensation,
signal, multiple,
parallel multiple)

event subprocess noninterrupting

(message, timer,
escalation,
conditional,
signal, multiple,
parallel multiple)

end (none,
message, error,
cancel,
compensation,
signal,terminate,
multiple)

intermediate
o

catching
(message, timer,
conditional, link,
signal, multiple,
parallel multiple)

boundary
interrupting
(message, timer,

escalation,
conditional,
error, cancel,
compensation,
signal, multiple,
parallel multiple)
o

boundary noninterrupting
(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)

task (atomic)

process/sub-process
(nonatomic)

choreography task

collapsed sub-process

collapsed
choreography
sub-process

expanded
choreography
sub-process

o expanded sub-process

process/sub-process
(nonatomic)
o

collapsed subprocess

o expanded sub-

process
gatewa
y

XOR
exclusive
decision
and
merging.
both databased and
eventbased.
databased 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.

exclusive decision and

merging. both databased and eventbased. exclusive can
be shown with or
without the "x" marker.

inclusive gateway
decision and merging

inclusive
decision and
merging.

complex gateway
complex conditions and
situations

complex
complex
conditions and
situations.

parallel gateway
forking and joining

parallel forking
and joining.

sequen
ce flow

normal flow
uncontrolled flow
conditional flow
default flow
exception flow

messag
e flow

message flow

associat
ion

association

pool

pool

lane

lane

data
objects

data object

data object
o

collection

data input

o data output
groups

group

annotat
ions

annotations

messag
e
other
element
s

Number

looping

looping

activity looping

activity looping

sequence flow looping

sequence flow
looping

multiple instances

process break

transactions

nested/embedded sub-process

off-page connector

compensation association

48

message

55

55

multiple instances

process break

transactions

nested/embedded subprocess

off-page connector

compensation
association

communication
(subcommunication)

communication link
116

of all
element
s
Major
/
change
s

The BPMN
The 1.2 minor
new
revision
speci
ficati changes
consist of
on
intro editorial
duce corrections
sa
categ and
orizat implementat
ion of ion bug
event fixes.
trigg
Consequentl
ers
into y, these
"catc minor
hing" changes
and
affect
"thro
wing" modeling
event tool vendors
s. I.e. more than
there
modelers
are
[8]
two (users).
kinds
of
inter
medi
ate
mess
age
event
s
now
one
kind
respo
nsibl
e for
recep
tion
of
mess
ages
("cat
ching
")

Choreographies
o

Choreographiesmodel

Conversationmodel

Complete Metamodel

BPMN Core

BPMN Execution
Semantics

BPMN BPEL Mapping

XPDL (BPMN XML

Serialization)

Diagram Interchange

Elements For
Abstraction

Callable Element

Call Activity

Global Task

Gateways (Updated)
o

Exclusive/Parallel
Event-based
Gateway (they
stand at the
beginning of the
process)

Tasks/SubProcesses
(Updated)
o

EventSubprocess
(Used to handle

and
one
kind
respo
nsibl
e for
sendi
ng
mess
ages
("thr
owin
g").

In
additi
on to
the
old
types
, it
intro
duce
sa
new
type,
the
sign
al
even
t.

Start
and
end
link
event
s do
not
exist
any
longe
r in
BPM
N
1.1.

The
old
"rule
event
s"

events in the
bounding
subprocess)

BusinessRule
task

Sequential MultiInstance Activity

Service Task

Artifacts (Updated)

o Data Objects

(Collection, Data
Input, Data
Output)

wher
e
rena
med
to
cond
ition
al
even
ts.
The
sema
ntics
and
appe
aranc
e
have
not
chan
ged.

The
event
base
d
gate
way
in
BPM
N 1.1
looks
slight
ly
differ
ent
to
what
it
looke
d like
in
1.0.
Inste
ad of
the
hexa
gonal
star
it
now

has a
pent
agon
in its
cente
r. The
same
shap
e is
also
used
for
the
multi
ple
event
s
(start
,
inter
medi
ate,
end).

There
is an
additi
onal
line
separ
ating
your
lane'
s
descr
iption
from
its
conte
nt.

Types of BPMN sub-model

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 submodels 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

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

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-trip engineering:
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

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
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-0329.

6.

Jump up ^ OMG. "BPMN Working Draft". Retrieved 2012-05-01.

7.

Jump up ^ OMG. "BPMN 2.0". Retrieved 2011-03-29.

8.

Jump up ^ "BPMN FAQ". Retrieved 2008-11-02.

Further reading

Briol P. (2010 Nov 16). BPMN 2.0 Distilled. LuLu. ISBN 978-1-4461-0406-4.

Allweyer T (2010 Feb 22). BPMN 2.0 Introduction to the Standard for
Business Process Modeling. BoD. ISBN 978-3-8391-4985-0.

White, Stephen A, and Miers, Derek (2008 August 28). BPMN Modeling and
Reference Guide. Future Strategies Inc. ISBN 978-0-9777527-2-0.

Debevoise, Neilson T, et al. (2008 July 4). The MicroGuide to Process

Modeling in BPMN. BookSurge Publishing. ISBN 978-1-4196-9310-6.

Briol P. (2008 April 12). BPMN, the Business Process Modeling Notation
Pocket Handbook. LuLu. ISBN 978-1-4092-0299-8.

Grosskopf, Decker and Weske. (2009 Feb 28). The Process: Business
Process Modeling using BPMN. Meghan Kiffer Press. ISBN 978-0-92965226-9.

Silver B. (2011). Bpmn Method and Style, 2nd Edition, with Bpmn
Implementer's Guide: A Structured Approach for Business Process
Modeling and Implementation Using Bpmn 2. Cody-Cassidy Press.
ISBN 0982368119.

Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee (2009) Business Process
Management (BPM) Standards: A Survey. In: Business Process
Management Journal, Emerald Group Publishing Limited. Volume 15 Issue
5. ISSN 1463-7154. PDF

External links
Wikimedia Commons has media related to Business Process Modeling
Notation.

BPMN Information Home Page OMG information page for BPMN.

Java implementation of BPMN in the jBPT library (see jbpt-bpm module)

Categories:

Diagrams

Process management

Design

Business Process Execution Language

From Wikipedia, the free encyclopedia

(Redirected from BPEL)

Jump to: navigation, search
[hide]This article has multiple issues. Please help improve it or
discuss these issues on the talk page.
This article may require cleanup to meet Wikipedia's quality
standards. The specific problem is: rebase on refs, other issues
tagged. (October 2012)
This article relies on references to primary sources. (October 2012)

Business Process Execution Language (BPEL), short for Web Services Business Process
Execution Language (WS-BPEL) is an OASIS[1] standard executable language for
specifying actions within business processes with web services. Processes in BPEL export
and import information by using web service interfaces exclusively.
Contents

1 Overview

2 History

3 Business Process Execution Language topics

o

3.1 BPEL design goals

3.2 The BPEL language

3.3 Relationship of BPEL to BPMN

3.4 Adding 'programming in the small' support to BPEL

3.5 WS-BPEL 2.0

4 See also

5 References

6 Further reading

7 External links

Overview

One can describe Web-service interactions in two ways: as executable business processes and
as abstract business processes. Executable business processes model is an actual behavior of a
participant in a business interaction. Abstract business processes are partially specified
processes that are not intended to be executed. An Abstract Process may hide some of the

required concrete operational details. Abstract Processes serve a descriptive role, with more
than one possible use case, including observable behavior and/or process template. WS-BPEL
aims to model the behavior of both executable and abstract processes.[2]
WS-BPEL provides a language for the specification of Executable and Abstract business
processes. By doing so, it extends the Web Services interaction model and enables it to
support business transactions. WS-BPEL defines an interoperable integration model that
should facilitate the expansion of automated process integration both within and between
businesses.
The origins of BPEL go back to WSFL and XLANG. It is serialized in XML and aims to
enable programming in the large. The concepts of programming in the large and
programming in the small distinguish between two aspects of writing the type of longrunning asynchronous processes that one typically sees in business processes:
1. Programming in the large generally refers to the high-level state transition
interactions of a processBPEL refers to this concept as an Abstract
Process. A BPEL Abstract Process represents a set of publicly observable
behaviors in a standardized fashion. An Abstract Process includes
information such as when to wait for messages, when to send messages,
when to compensate for failed transactions, etc.
2. Programming in the small, in contrast, deals with short-lived programmatic
behavior, often executed as a single transaction and involving access to
local logic and resources such as files, databases, etcetera. BPEL's
development came out of the notion[citation needed] that programming in the
large and programming in the small required different types of languages.
History
[when?]

IBM and Microsoft had each defined their own, fairly similar, "programming in the
large" languages: WSFL (Web Services Flow Language) and Xlang, respectively. With the
advent and popularity of BPML, and the growing success of BPMI.org and the open BPMS
movement led by JBoss and Intalio Inc., IBM and Microsoft decided to combine these
languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft,
SAP, and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web
Services BPEL Technical Committee.[3] Although BPEL4WS appeared as both a 1.0 and 1.1
version, the OASIS WS-BPEL technical committee voted[4] on 14 September 2004 to name
their spec "WS-BPEL 2.0". (This change in name aligned BPEL with other Web Service
standard naming conventions which start with "WS-" and took account of the significant
enhancements made between BPEL4WS 1.1 and WS-BPEL 2.0.) If not discussing a specific
version, the moniker BPEL is commonly used[citation needed].
In June 2007, Active Endpoints, Adobe Systems, BEA, IBM, Oracle, and SAP published the
BPEL4People and WS-HumanTask specifications, which describe how human interaction in
BPEL processes can be implemented.

Business Process Execution Language topics

BPEL design goals

There were ten original design goals associated with BPEL:

1. Define business processes that interact with external entities through web
service operations defined using WSDL 1.1, and that manifest themselves
as Web services defined using WSDL 1.1. The interactions are abstract in
the sense that the dependence is on portType definitions, not on port
definitions.
2. Define business processes using an XML-based language. Do not define a
graphical representation of processes or provide any particular design
methodology for processes.
3. Define a set of Web service orchestration concepts that are meant to be
used by both the external (abstract) and internal (executable) views of a
business process. Such a business process defines the behavior of a single
autonomous entity, typically operating in interaction with other similar
peer entities. It is recognized that each usage pattern (i.e., abstract view
and executable view) will require a few specialized extensions, but these
extensions are to be kept to a minimum and tested against requirements
such as import/export and conformance checking that link the two usage
patterns.
4. Provide both hierarchical and graph-like control regimes, and allow their
use to be blended as seamlessly as possible. This should reduce the
fragmentation of the process modeling space.
5. Provide data manipulation functions for the simple manipulation of data
needed to define process data and control flow.
6. Support an identification mechanism for process instances that allows the
definition of instance identifiers at the application message level. Instance
identifiers should be defined by partners and may change.
7. Support the implicit creation and termination of process instances as the
basic lifecycle mechanism. Advanced lifecycle operations such as
"suspend" and "resume" may be added in future releases for enhanced
lifecycle management.
8. Define a long-running transaction model that is based on proven
techniques like compensation actions and scoping to support failure
recovery for parts of long-running business processes.
9. Use Web Services as the model for process decomposition and assembly.
10.Build on Web services standards (approved and proposed) as much as
possible in a composable and modular manner.

The BPEL language

BPEL is an orchestration language, and not a choreography language. The primary difference
between orchestration and choreography is executability and control. An orchestration
specifies an executable process that involves message exchanges with other systems, such
that the message exchange sequences are controlled by the orchestration designer. A
choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal
sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a
protocol is not directly executable, as it allows many different realizations (processes that
comply with it). A choreography can be realized by writing an orchestration (e.g., in the form
of a BPEL process) for each peer involved in it. The orchestration and the choreography
distinctions are based on analogies: orchestration refers to the central control (by the
conductor) of the behavior of a distributed system (the orchestra consisting of many players),
while choreography refers to a distributed system (the dancing team) which operates
according to rules (the choreography) but without centralized control.
BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led
BPEL to adopt web services as its external communication mechanism. Thus BPEL's
messaging facilities depend on the use of the Web Services Description Language (WSDL)
1.1 to describe outgoing and incoming messages.
In addition to providing facilities to enable sending and receiving messages, the BPEL
programming language also supports:

A property-based message correlation mechanism

XML and WSDL typed variables

An extensible language plug-in model to allow writing expressions and

queries in multiple languages: BPEL supports XPath 1.0 by default

Structured-programming constructs including if-then-elseif-else, while,

sequence (to enable executing commands in order) and flow (to enable
executing commands in parallel)

A scoping system to allow the encapsulation of logic with local variables,

fault-handlers, compensation-handlers and event-handlers

Serialized scopes to control concurrent access to variables.

Relationship of BPEL to BPMN

There is no standard graphical notation for WS-BPEL, as the OASIS technical committee
decided this was out of scope. Some vendors have invented their own notations. These
notations take advantage of the fact that most constructs in BPEL are block-structured (e.g.,
sequence, while, pick, scope, etcetera.) This feature enables a direct visual representation of
BPEL process descriptions in the form of structograms, in a style reminiscent of a Nassi
Shneiderman diagram.

Others have proposed to use a substantially different business process modeling language,
namely Business Process Model and Notation (BPMN), as a graphical front-end to capture
BPEL process descriptions. As an illustration of the feasibility of this approach, the BPMN
specification includes an informal and partial mapping[5] 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.[6] 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-trip engineering: 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]
Adding 'programming in the small' support to BPEL

BPEL's control structures such as 'if-then-elseif-else' and 'while' as well as its variable
manipulation facilities depend on the use of 'programming in the small' languages to provide
logic. All BPEL implementations must support XPath 1.0 as a default language. But the
design of BPEL envisages extensibility so that systems builders can use other languages as
well. BPELJ[7] is an effort related to JSR 207[8] that may enable Java to function as a
'programming in the small' language within BPEL.
WS-BPEL 2.0

Version 2.0 introduced some changes and new features:

New activity types: repeatUntil, validate, forEach (parallel and sequential),

rethrow, extensionActivity, compensateScope

Renamed activities: switch/case renamed to if/else, terminate renamed to

exit

Termination Handler added to scope activities to provide explicit behavior

for termination

Variable initialization

XSLT for variable transformations (New XPath extension function

bpws:doXslTransform)

XPath access to variable data (XPath variable syntax

$variable[.part]/location)

XML schema variables in Web service activities (for WS-I doc/lit style
service interactions)

Locally declared messageExchange (internal correlation of receive and

reply activities)

Clarification of Abstract Processes (syntax and semantics)

Enable expression language overrides at each activity

See also

BPEL4People

BPELscript

Business Process Modeling

Business Process Model and Notation

Web Services Conversation Language

WS-CDL

Workflow

XML Process Definition Language

Yet Another Workflow Language

Comparison of BPEL engines

References
This article needs additional citations for verification. Please help
improve this article by adding citations to reliable sources. Unsourced
material may be challenged and removed. (October 2008)
1.
2.

Jump up ^ OASIS Standard WS-BPEL 2.0

Jump up ^ Business Process Execution Language for Web Services,
Version 1.1 (PDF) (5 May 2003)

3.

Jump up ^ Web Services BPEL Technical Committee.

4.

Jump up ^ "choreology.com". choreology.com. Retrieved 2013-0417.

5.

Jump up ^
http://www.omg.org/bpmn/Documents/Mapping_BPMN_to_BPEL_Example.p
df

6.

Jump up ^ BPMN2BPEL.

7.

Jump up ^ BPELJ

8.

Jump up ^ JSR 207

Further reading
Books on BPEL 2.0

SOA for the Business Developer: Concepts, BPEL, and SCA. ISBN 978-158347-065-7
This article's use of external links may not follow Wikipedia's
policies or guidelines. Please improve this article by removing excessive
or inappropriate external links, and converting useful links where
appropriate into footnote references. (October 2012)

BPEL articles

[dead link]

"SOA Best Practices: The BPEL Cookbook" - BPEL howto's from Oracle

"Pattern-based Evaluation of Oracle BPEL"[dead link]

"What is BPEL and Why is it so important to my business?" - BPEL Primer

from SoftCare

Description of the upcoming changes from BPEL 1.1 to BPEL 2.0

[dead link]

Webinar replay: BPEL for Java developers: concepts and capabilities

BPEL and Java

Process-centric realization of SOA: BPEL moves into the limelight

Validating BPEL Specifications using OCL

[dead link]

[dead link]

BPEL Primer

[dead link]

WS-BPEL Extension for Sub-processes, BPEL-SPE

Analysis of Web Services Composition Languages: The Case of BPEL4WS

BPEL Begone - How useful is this Standard?

[dead link]

A Close Look at BPEL 2.0 @ SYS-CON Media

BPEL BluePrints: Web Services Orchestration Using BPEL - presented

by the Java BluePrints Solutions Catalog

Oracle Article: Weaving Web Services Together

IBM Article: Business Process Choreography in WebSphere:

Combining the Power of BPEL and J2EE

Pattern-based Evaluation of IBM WebSphere BPEL[dead link]

BPEL in SCA assembly model

[dead link]

BPEL for REST

BPEL, who needs it anyway?

Writing a simple WS-BPEL process for WSO2 BPS and Apache ODE

Why BPEL is not the holy grail for BPM

Goal-oriented Business Processes with WS-BPEL [dead link]

External links
This article's use of external links may not follow Wikipedia's
policies or guidelines. Please improve this article by removing excessive
or inappropriate external links, and converting useful links where
appropriate into footnote references. (August 2010)
Standards

WS-BPEL 2.0

OASIS WSBPEL TC Webpage

OASIS WSBPEL TC Issues List

Latest editor's copies of OASIS WSBPEL TC Specs

The BPEL4WS 1.1 specification

BPEL and business process sites

Business Process Management Initiative Web Site [dead link]

Business Modeling Forum

BPEL Resource Guide[dead link]

Service Interaction Patterns (with BPMN diagrams that match BPEL code
samples)[dead link]

BPEL implementations

ActiveVOS

Open Source Easy BPEL / Petals BPEL Engine

The Eclipse STP BPMN Diagram Editor

Eclipse BPEL project

Orchestra Fully Open source, extensible and flexible BPEL Solution

The Open Source BPMS (Eclipse and Apache-based)

Apache ODE, Open source BPEL server

NetBeans Enterprise Pack

BPEL for Windows Workflow Foundation

BPEL4People
From Wikipedia, the free encyclopedia
Jump to: navigation, search

BPEL4People is the WS-BPEL Extension for People as proposed in a joint white paper by
IBM and SAP in July 2005.
Contents

1 History

2 Status

3 Problem Definition & Motivation

4 Objectives

5 See also
o

5.1 OASIS BPEL4People and WS-HumanTask Standardization

5.2 Specifications

5.2.1 White Paper

6 External links

History

In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle, and SAP published the
BPEL4People and WS-HumanTask specifications as a follow-up to the whitepaper,
describing how human interaction in BPEL processes can be performed.
Status

(Posted February 2009) The OASIS WS-BPEL Extension for People (BPEL4People) TC is
working on standardizing the BPEL4People and WS-HumanTask specifications.

Problem Definition & Motivation

The BPEL language specifies the behavior of business processes as long as the activities of
the processes are Web services. Human interactions are not in its domain. Despite wide
acceptance of Web services in distributed business applications, the absence of human
interactions is a significant gap for many real-world business processes.
To fill this gap, BPEL4People extends BPEL from orchestration of Web services alone to
orchestration of role-based human activities as well.
Objectives

Within the context of a business process BPEL4People

supports role based interaction of people

provides means of assigning users to generic human roles

takes care to delegate ownership of a task to a person only

supports scenario as
o

four eyes scenario

nomination

escalation

chained execution

by extending BPEL with additional independent syntax and semantic.

The WS-HumanTask specification introduces the definition of human tasks and notifications,
including their properties, behavior and a set of operations used to manipulate human tasks. A
coordination protocol is introduced in order to control autonomy and life cycle of serviceenabled human tasks in an interoperable manner.
The BPEL4People specification introduces a WS-BPEL extension to address human
interactions in WS-BPEL as a first-class citizen. It defines a new type of basic activity which
uses human tasks as an implementation, and allows specifying tasks local to a process or use
tasks defined outside of the process definition. This extension is based on the WSHumanTask specification.
See also

Business Process Execution Language

OASIS BPEL4People and WS-HumanTask Standardization

http://www.oasis-open.org/committees/tc_home.php?
wg_abbrev=bpel4people

Specifications

Specification: Web Services for Human Task (WS-HumanTask), version 1.0

Specification: WS-BPEL Extension for People, (BPEL4People), version 1.0

White Paper

WS-BPEL Extensions for PeopleBPEL4People

Human Services: Integrating user interfaces into a service-oriented

architecture (Nov 2006)

External links

BPMN Modeler that fully supports BPEL for People

Visually orchestrate services and people with BPEL and BPEL4People

Download a WS-HumanTask SDK that includes the documentation, JavaDoc

and samples

Apache HISE - open source implementation of WS-HumanTask specification

Categories:

XML-based standards

Specification languages

Web service specifications

Workflow technology

Process management

Web services

BPEL script
From Wikipedia, the free encyclopedia
Jump to: navigation, search

BPELscript[1] is a language to specify BPEL processes.[2] It provides a compact syntax

inspired by scripting languages such as JavaScript and Ruby and a full coverage of all
features provided by BPEL.

Contents

1 History

2 BPELscript Design Goals

3 See also

4 References

5 External links

History
The Business Process Execution Language (BPEL) is an XML-based language to specify
business processes with the intention to "act as the central controller of the business process".
[3]
It provides a standardized way for programming in the large in a service oriented world
(SOA). BPEL is not a programming language at all and does not have a graphical
representation. Mappings from graphical languages such as the Business Process Modeling
Notation (BPMN) to BPEL are available, but programmers familiar to syntax like Java, C, ...
are disregarded. Therefore, especially for prototyping or teaching, it would be nice to have a
programming language which omits the XML-overhead of BPEL but offers the same features
as BPEL. One option is to force the programmers to learn a completely new syntax. The other
option is to introduce a new syntax to BPEL.
Therefore, the "BPEL Simplified Syntax" called SimPEL [4][5] was recommended by the
Apache ODE Group,[6] referring to the a mix of both options. However, SimPEL is not
equivalent to BPEL and its aims of specifying business processes. In order to come up with
an easy scripting syntax, BPELscript is introduced, referring to the second option.
BPELscript forks directly from SimPEL aiming on big closeness to BPEL. In contrast to
SimPEL, BPELscript supports all of BPELs constructs including the correlation.[7]

BPELscript Design Goals

BPELscript provides:[8]
1. a compact syntax inspired by scripting languages such as JavaScript and Ruby
2. the full coverage of all features provided by BPEL
3. a translation from WS-BPEL 2.0
4. a translation to WS-BPEL 2.0

See also

Business Process Execution Language

BPEL4People

Business process management

Business Process Modeling Notation (BPMN)

Web Services Conversation Language

WS-CDL [1]

Workflow

XML Process Definition Language

Yet Another Workflow Language

References
1.

Jump up ^ Bischof, Marc; Kopp, Oliver; van Lessen, Tammo; Leymann,

Frank: BPELscript: A Simplified Script Syntax for WS-BPEL 2.0. In: 2009 35th
Euromicro Conference on Software Engineering and Advanced Applications (SEAA
2009)

2.

Jump up ^ OASIS Standard WS-BPEL 2.0,

3.

Jump up ^ "BPEL, business process management, SOA and you".

4.

Jump up ^ "SimPEL".

5.

Jump up ^ "SimBPEL".

6.

Jump up ^ "Apache ODE (Orchestration Director Engine)".

7.

8.

Jump up ^ Bischof, Marc, Translating WS-BPEL 2.0 to BPELscript and Vice

Versa.-(PDF) University of Stuttgart, Faculty of Computer Science, Electrical
Engineering, and Information Technology, Student Thesis No. 2175 (2008), 109
pages, english.
Jump up ^ "www.BPELscript.org".

External links
BPELscript Website

www.BPELscript.org

Standards

WS-BPEL 2.0

OASIS WSBPEL TC Webpage

Categories:

XML-based standards

Specification languages

Web service specifications

Workflow technology

Process management

ERP Implementation Life Cycle - Process Adopted For Implementing ERP

Posted by

Text
ERP Implementation Life Cycle - Process Adopted For
Implementing ERP

dreaston
Dr Easton Patrick 862 days ago

Quote Report spam

Enterprise resource planning, best known as ERP is a composition of

software modules to enhance the performances of resources in an
organization. Today, it is one of the commonly used software
packages for business administrations. Enhanced management of
resources, better work flow, improved operational efficiency, better
order tracking and human capital management are some key benefits
of using ERP software package. Process of implementation of ERP
software package in an organization depends upon versatile factors.
Business functions, quality of services offered by vendor and size of
package are some of the major factors playing leading roles in ERP
implementing process. Implementation of ERP is done in series of
steps according to business goals of company. This series of process
adopted for implementing ERP software package is known as ERP
implementation life cycle. Let's see the details of versatile steps
involved in ERP implementation life cycle.
Choosing the best ERP package is one among the main processes
involved in ERP implementation life cycle. Different companies will
choose different implementation methods according to their business
functions and package size. Before choosing your ERP outsourcing
provider, it is recommended to do well research on factors like quality
of services, maintenance and support offered by vendor. Business
owners are advised to choose software service from a well reputed
vendor suiting their business functions and strategies.
Affordable cost for implementation, wide range of upgrading options
and user friendly operation of software system are some among the
key factors considered while choosing an ERP software package.
Planning of project infrastructure is the next process involved in ERP
implementation life cycle. It helps in better knowing of resource data
and proper allocation of task according to needs. After designing
project infrastructure, plan has to be tested by a team of experts and
professionals. It is an important process needed for finding out error
and reducing operational failure.
Making project alterations according to the direction of business goals
is an expensive process involved in ERP implementation life cycle.

Posted by

Text

This process of gap analysis by rebuilding the project structure makes

ERP software system more user friendly in operation. In this step,
company can make a project model so as to improve their real time
functions. Training of employees is one among the main processes
involved in ERP implementation life cycle. It reduces error and helps
in proper management of resources according to specific functions. In
the next step of ERP implementation life cycle, checking of
completed project is done so as to ensure proper functioning of
resources.
After completing testing process, project is now put into live by
running the new system. In this step, the old process is removed from
business infrastructure giving way to new system. Post
implementation process including upgrading of software and
maintenance is the next factor coming under the list of ERP
implementation life cycle. It helps in better workflow of process and
improving the efficiency of operation. Easier location of errors and
upgrading software according to real time needs are other benefits of
maintenance in ERP implementation life cycle.
Read Benefits of ERP for SME. Also know Advantages of ERP in an
organization. Read about SAP ERP Course Fees and duration of
course.

Comments: 0 Views: 125

Most important phase in ERP implementation life cycle?

What are the phases of ERP implementation?

What is the phase of the cell cycle in which the cell spends most of its life?
What are the phases in the life cycle of a cell?
What are the phases in project life cycle?
Project life cycle phases?
The phase of the cell cycle that occupies most of an average cell's life is?
Most specialized cells remain in what phase of the cell's life cycle?
What is the most important factor in determining a stars life cycle?
What project life cycle stage is the most important?
What are the importance phases of hydraulic cycle?

What are the phases of ERP implementation?

In: Shopping [Edit categories]
Answer:
Answer

1.

strategy and planning

2.

blue printing and design

3.

software configuration

4.

data migration

5.

system testing

6.

Go Live

What project life cycle stage is the most important?

In: Project Management [Edit categories]
Answer:
I would say the "Planning" phase is the most important in a projects life cycle
because a project that isnt properly planned has around 99% chances of failure.
Project life cycle phases?
In: Project Management [Edit categories]
Answer:

From initiation/authorization to completion/closure, a project goes through a

whole lifecycle that includes defining the project objectives, planning the work to
achieve those objectives, performing the actual work, monitoring and controlling
the progress, and closing the project after receiving the product acceptance or
after cancellation of the project.

What are the phases in project life cycle?

In: Project Management [Edit categories]
Answer:
1. Initiation
2. Planning
3. Execution
4. Monitoring & Controlling
5. Closing

ERP Implementation Life Cycle

Posted by admin in Implementation Strategies, On-premise ERP | 1 comment
The different stages in which implementation of ERP is carried out in any organization is
termed as an ERP Implementation life cycle. Generally, the steps involved are as follows.
1. Pre-evaluation of available packages
2. Evaluation of chosen package
3. Requirement analysis
4. Project planning
5. Business process re-engineering
6. Training the staff & management
7. Testing& Analysis
Lets look at each stage in brief.
1. During the pre-evaluation phase, ERP vendors available in the market are screened
based on business requirements. ERP packages that dont suit the business
requirements are eliminated.

2. During the package evaluation phase, selected package is evaluated against

requirements across departments.
3. A detailed requirement analysis is done, involving different managers from across the
departments. Requirement analysis helps list down all the functionalities required to
ensure efficient processes across the organization.
4. Based on the analysis of requirements and functionalities, a detailed project plan is
laid out. This involves senior management team and ERP experts. Designs are
finalized; key resources to be involved in the project are identified in various
departments; special arrangement is also made to tackle contingencies.
5. Once the planning is done, business process re-engineering takes place. Implementing
ERP will impact the job responsibilities of lot of employees. So, new roles and
responsibilities are to be assigned to employees. Processes are to be re-structured and
integrated with ERP tools.
6. Post implementation and integration, staff and managers are to be trained properly so
that they get good practice. Consultants will help employees to get hands on
experience of the ERP tools.
7. At last, the tools that are implemented are tested rigorously. Issues arising during the
testing phase are fixed and required changes are made.
Thus ERP Implementation process can be explained.

Erp Implementation Life Cycle's Stages

Implementation Life cycle
The ERP implementation life cycle consist of;
Pre evaluation Screening
Package evaluation
Project planning phase
Gap Analysis
Reengineering
Configuration
Implementation team Training
Testing
Going Live
End-User Training
Post Implementation
Pre-evaluation Screenings
In order to develop a new ERP package the available packages should be
evaluated before coming to the solution But this pre evaluation should be done
with a chosen number of packages since there are hundreds of packages and
vendors are available In this stage packages that are not suitable for the
companys business process should be eliminated and only the identified
necessary ERP s should be studied extensively using brochures, product
literature, white papers, web sites, etc
Package Evaluation
This is a most critical phase since the success or the failure of the project
depends upon the package Evaluation and selection and the direction of the
entire implementation as well as the outcome will depend on this.. Since there is
no ERP s which matches 100% with the organizations business requirements,
the objective of this phase is to identify a package that gives a good fit by
satisfying most of the core requirements.
Package evaluation committee should be set up including members such as
functional experts/end-users from affected division, top management (CIO, COO,
CEO, CFO), and external impartial consultants.
Project Planning
At this phase It is necessary to prepare the entire roadmap of implementation
with milestones fixed and resources needed. This purpose of this is to prepare a
detailed plan about the implementation. Setting up implementation teams as
steering up committee, operational committee and task allocation are done in
this phase. The project planning is usually done by a committee with team
leaders of each implementation group. The time schedules as when to begin,
when to be completed is also estimated within