Business Process
Redesign and Modelling
The Business Process Redesign
the Process Handbook
“the key idea of the Process Handbook approach is that a richly structured online
repository about business processes can significantly enhance the creativity of process
designers by helping them systematically explore many alternatives combinations of
processes elements”
…Generalize and then Specify…
Deep structure vs Surface structure to avoid analysis paralysis
(1) Meaning vs (different) wording
(Few) Goals and Constraints vs (Many possible) specif sequence of activities
Selling cars vs Make to order or Make to inventory
Generalization vs Specialization
…following three basic steps…
Analyze
Identify core activities Identify key dependencies Identify coordination mechanisms
Generate
Alternative specializations Alternative coord. Mechanisms
Alternative sequencing Multicolumn table Distant analogies
1
2 Target
Process Model
3
! pick a similar process
! look left
! and then right
! process rccombinator
! trade-off matriz
…and doing an exception analysis…
Exceptions are deviations to process goals
Exceptions represents violations of goals/committments…
…Undesired states vs Desidered states…
…ex. A delay vs beign on time at a meeting…
…so the first step of exception analysis is identifying the goals of a process…
…looking to what is required to achieve the output of a process…
…ex. Being on time at a meeting requires the plane to land on time, the plane to land on time requires no delay at departure, no delays at departure it means proper maintenance and being allocated correctly in
Exception analysis continued…
• … the second step is to identify exceptions that can occur with a given set of goals…
• …ex. of exceptions are communication failures or delays in accomplishing a task…
• In the process handbook goals and exceptions types are linked
• …and finally identify possible exceptions handlers for each of the most importantu exceptions identified before…
• The handbook contains goals, exceptions and handlers
…to sum up..
A given process is analysed to determine goals
Those goals are then mapped to the ways they can be violated And from there to the ways those violations can be handled
process
goal exception
has exception
achieved by
example
Specializing transformation Refining
transformation
Specialization &
Inheritance
The classification framework
A specific classification framework for organizing knowledge using these concepts;
A ‘verb’ rather than a conventional object-oriented ‘noun’ taxonomy
Groups processes with similar functions to enable cross-disciplinary
fertilization of ideas
A representative set of generic business process templates and
specific case examples to illustrate how the concepts and framework can be used;
Repository of business process knowledge
• A set of software tools to organize and manipulate large amounts of knowledge.
• Web-accessible repository viewer/editor
• Process query language
Software tools
Business Process Modelling
In general Business Process Modelling is used to create an understanding of business processes and to assist the design and implementation of software systems.
Business Modelling can take many forms. The choice to use business modelling, and the choice of the type of modelling to use, require a clear understanding of the objectives of the modelling exercise. Business modelling is an area where excessive effort and cost can be expended for little benefit if those objectives are not properly understood.
Business Process Modelling
A model is an abstract view of something that exists in reality, but it is quite different from what it models because some details are left out, it depends on the level of abstraction that the model contains. In the business domain a model could describe a business or a company itself (or a part of it), it should allow to model business goals, business processes, stakeholders, departments, dependencies between processes and so on.
A business model does not necessarily says anything about the software system used within a company, whenever may (and should) serve as a basis for the information system model, ensuring consistency and accurate requirements being passed on to the software design. Therefore it is also called a Computational Independent Model (CIM) [1]. A CIM is a software independent model used to describe a business system. Certain parts of a CIM may be supported by software systems, but the CIM itself remains software independent.
What is a Model?
Many people talk often about structural models versus dynamic models. In UML, for example, the class diagram is called a structural model and the state diagram a dynamic model, while in reality the class diagram and state diagram are so dependent on each other that they must be regarded as part of the same model. Thus an important feature of models, even of business models, is that they may consist of several views.
Finally, a model must have a purpose, for a business this may be understanding its structure, improving it or re-engineering it. The details of the model will depend on its objectives.
What is a Model?
There are several reasons for using Business Process Models. Mainly they allow a reduction of complexity and a clear understanding of process features through the use of a graphical representation; they also provide a common and shared agreement between stakeholders; they give an unambiguous explanation of interactions between processes and
description of interfaces.
Business Process Models offer also the opportunity to reach the following goals:
• to state how value-creating activities are carried out;
• to create a common approach for work to be carried out;
• to improve incrementally processes;
• to analyse properties of a process.
• to support processes by workflow management systems;
Why a Business Process Model?
More than a method to have a clear understanding of the process that allows to precisely assign task, to underline issues and further
improvement, a business process model could be very useful to define requirements for the workflow management systems (as stated above).
In the last years a big effort has been done by many companies and organizations to define a formal language (a meta-model) to describe business processes in order to achieve the automatic implementation of a business process management system. Results of such work could extremely speed up the building of the organizations’ information
systems, provide a framework to easily and rapidly manage changes in the organization that impact on IT systems and allow a more efficient collaboration between partners. These formal languages are near to
become mature standards that could revolutionise the business process management.
Why a Business Process Model?
Before analyse business process standards characteristics an important distinction has to be made when designing a process model; the modeller has to take into account that business processes can belong to two distinct domains [2]:
Public processes are those that an enterprise shares with its customers, suppliers, or other partners (Business-to-Business integration (B2Bi) domain).
Private processes are those that are internal to the enterprise (Enterprise Application Integration (EAI) domain).
In any enterprise, public and private business processes combine to perform the overall business operations. This fact drives the demand for a single business process standard for modelling processes that encompasses both the B2B and EAI domains. However some important
Type of Business Process
A business process standard should provide the following features [2]:
1) Collaboration-Based Process Models: Experience in both EAI and B2B process modelling has led to the increasing adoption of collaboration- based process models, usually based on UML. In collaboration-based process models, processes are described as a set of collaborations between various participants (including organizations, applications, employees, and other business processes) using different roles. The ability to recursively decompose process models is generally required.
2) Workflow: The workflow defines how the participants in a process work together to execute a process from the beginning to the end, and is also called choreography or orchestration. Workflow descriptions can be
generated from collaboration models, or specified independently. There
The need for Business Process Standards
3) Transaction Management: Transactions are crucial building blocks of any business process and a comprehensive business process standard must provide a means for specifying how transactions are managed. Long-
running transactions that may take hours or weeks to complete must be supported. If an enclosing transaction fails after an enclosed transaction is completed, some compensating actions may be needed. Time
constraints for receiving responses or acknowledgements may also be required.
4)Exception Handling: If an exception is raised during the course of a
business process, then it is important that the model allow appropriate recovery actions to be taken.
5)Service Interfaces: These Interfaces provide a way to describe the loosely coupled services exposed by participants and a basis for passing
The need for Business Process Standards
6) Message Security and Reliability: For mission-critical processes, reliable and secure message delivery is required. Additionally, B2B messages may need to be digitally signed and authenticated. These quality-of- service semantics may vary for different transactions.
7) Audit Trail: It is generally very important for legal purposes in B2B
processes that an audit trail of certain business transactions is kept. This means that a trading partner is unable to claim that a transaction was not accepted when in fact it was; that is, it ensures non repudiation of the transaction by the partner. Digitally signed receipt acknowledgements of messages may be demanded.
8) Agreements: The notion of agreements is specifically for B2B processes.
An agreement represents a contract between two or more partners to
The need for Business Process Standards
9) Execution: Public processes describe only how information should flow between organizations. In order to be able to fully automate the
execution of the business process within an organization, the complete information flow within that organization as well as across its firewalls must be specified. This requires the process models to fully describe the private as well as the public activities of the organization.
The need for Business Process Standards
Fraunhofer Integrated Enterprise Modelling (IEM) [3] is an object-oriented modelling technique, created by the Fraunhofer Institute for Production Systems and Design Technology of Berlin, for modelling business
processes, related organizational structures and required information
systems. It provides a model for planning and optimizing the processes and organizational structures within the enterprise.
Models developed according to the IEM method give a transparent representation of planning information and are therefore the basis for
discussion between project participants. In order to evaluate the variety of planning information and description requirements it allows different views on one consistent model.
IEM models provide the means to precisely assign the value of planning
Integrated Enterprise Modelling (IEM)
The core of the IEM comprises two main views:
• the objects describing data represent the Information Model View;
• the tasks, which are to be executed on objects, and the business
• processes are the focal point of the Process Model View.
Therefore, the core of the enterprise model consists of the data and
process representation of classes of objects. The views are interlinked by referring to the same objects and activities, although they represent them in different ways, levels of detail and context. Any view on the model can be derived from this standardized model core.
Integrated Enterprise Modelling (IEM)
The generic classes ‘Product’, ‘Resource’ and ‘Order’ are the basis of
Integrated Enterprise Modeling for developing models from a user’s point of view.
• Orders control the activities in the enterprise e.g. customer or production orders;
• Products are all objects which an enterprise sells e.g. machines, services or software and product components which may come into the final product;
• Resources are the agents that accomplish or support the actions in the process; to resource belong employees, organizational units, documents and software systems.
These classes of information are represented in rectangular round boxes with different colours, each colour is related to the specific meaning of the class.
The Information Model
They will be specified according to the specifications of an individual enterprise. Each generic class prescribes a specific generic attribute
structure, thus defining a frame for describing the structure and behavior of objects of its subclasses. Real enterprise objects will be modeled as objects of these subclasses.
Required enterprise data and the business processes, i.e. the tasks
referring to objects, are structured in accordance with the object classes (see below). Furthermore, the relations between objects are determined.
The result is a complete description of tasks, business processes,
enterprise data, production equipment and information systems of the enterprise at any level of detail.
The Information Model
The IEM expects that information related to the objects handled by activities in the business process is organized in a structured manner, creating a tree for each class of objects.
The Information Model
The Process Model
Action Function Activity
Everything that happens in a manufacturing enterprise as part of the
manufacturing process can be described by activities. In general, activities process and modify objects which were classified above as Products,
Orders and Resources. The IEM method suggests three levels when describing the essentials of an activity.
• the Action is an object-independent description of any task or business, a verbal description of some task, process step or procedure;
• the Function describes the processing of objects (Orders, Products or Resources) as a transformation from one determined (beginning) state to another determined (ending) state;
• the Activity specifies the Order, which controls the execution of the
function, and the Resource(s), which is (are) in charge of executing the function.
The beginning and ending states are connected with the action rectangle by arrows from left to right. The controlling of the activity is represented by an order state description and a dashed vertical arrow from the top; the
required or actually assigned capability for executing the function is
represented by a resource state description and a dashed vertical arrow from the bottom.
Action
Order Product
Resource
Order Product
Resource
State n State n+1
Order
The Process Model
Using special linking constructs (see Figure 3), actions, functions and activities can be combined to represent business processes. The decomposition and aggregation of processes is also supported.
The Process Model
In general Business Process Modelling is used to create an understanding of business processes and to assist the design and implementation of software systems.
• An example of activity modelling is illustrated in the next slide. In this case the activity operates a transformation on order objects. The model highlights:
• the name of the action (Purchase components);
• resources exploited by the action, that is: who is responsible for the execution of the operation (Leader assembly), the documentation supporting the operation (procedure instructions) and the tool to be used (PPS);
• the order controlling the activity;
• units of information that represents the beginning (components needed) and the ending state (Components are in store).
The Process Model
The Process Model
One of the most important feature of the IEM is the capability to provide different levels of description hiding/showing the details in the model. By exploiting this characteristics, you can have a global view of the business process of a SME and then go deeper in the description of the activities linking a more detailed model (with the same external input-output-order- resource information) to the more abstract one
The Process Model
The IDEF0 method is based on a notation for specifying ICOMs (Input, Control, Output, Mechanism), activities and arrows that represent "data"
associated with the ICOMs.
The position at which the arrow attaches to a box conveys the specific role of the interface. The controls enter the top of the box. Controls are the
standards, policies, guidelines, etc., that guide the process. The inputs, the data or objects acted upon by the operation, enter the box from the left.
Inputs are the typical things such as resources consumed or transformed by a process. The outputs of the operation leave the right-hand side of the box.
Outputs are the typical things created by the transformations of the inputs by the process. Mechanism arrows that provide supporting means for
performing the function join (point up to) the bottom of the box. Mechanisms are the agents (people, manual tools, automated tools, etc.) that
accomplish the actions delineated within the process. Call arrows, a type of mechanism arrow which enables the sharing of detail between models or
IDEF0
IDEF0 notations are combined into diagrams that describe activation of the activities, not flow. IDEF0 allows for Business Modelling to take many
forms. The choice to use business modelling, and the choice of the type of modelling to use, require a clear understanding of the objectives of the
modelling exercise. Business modelling is an area where excessive effort
IDEF0
IDEF0
IDEF3 Process Schematics are the primary means for capturing, managing, and displaying process-centred knowledge. These schematics provide a graphical medium that helps domain experts and analysts from different application areas communicate knowledge about processes. This includes knowledge about events and activities, the objects that participate in those occurrences, and the constraining relations that govern the behaviour of an occurrenc.
IDEF3 Process Flow
The basic IDEF3 syntactic unit is an UOB (Unit of Behaviour). Depending on the surrounding structure, UOBs may become functions, activities,
processes, etc. An UOB may be decomposed in other UOBs and may also be cross-referenced with IDEF0 activities.
UOBs are correlated together by different types of link:
IDEF3 Process Flow
The Eriksson-Penker Business extensions are intended as a basic framework for business modelling. Using these extensions, the business architects may add stereotypes and/or properties to the UML in order to suit their particular situation. The Eriksson-Penker Business extensions actually merge the UML with process modelling, providing a much needed specialized UML extension able to handle business process modelling. The Eriksson-Penker extensions achieve process representation in UML by stereotyping an activity (from a UML activity diagram) to a “process”. In this approach, a process takes input resources from the left-hand side and outputs resources from the right-hand side.
UML: Eriksson-Penker Business extensions
A business process model typically defines the following elements:
• The Goal or reason for the process;
• Specific inputs;
• Specific outputs;
• Resources consumed;
• Activities that are performed in some order;
• Events that drive the process.
The business process:
• May affect more than one organizational unit.
• Have a horizontal organizational impact;
• Creates value of some kind for the customer. Customers may be internal or external
UML: Eriksson-Penker Business extensions
UML: Eriksson-Penker Business extensions
A business process is a set of activities designed to produce a specific output. It implies a strong emphasis on how the work is done within an organization. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs.
The process notation implies a flow of activities from left to right. Typically an event element is placed to the left of the process and the output to the
Business Process
In general Business Process Modelling is used to create an understanding of business processes and to assist the design and implementation of software systems.
Business processes use information to tailor or complete their activities.
Information is used as part of the transformation process. Information may come from external sources, from customers, from internal organizational units and may even be the product of other processes. A resource is an input to a business process, and, unlike information, is typically consumed during the processing. For example, as each daily train service is run and actuals recorded, the service resource is 'used up' as far as the process of recording actual train times is concerned.
Inputs, Resources and Information
linked to the process is not used up in the processing phase. For example, order templates may be used over and over to provide new orders of a certain style - the templates are not altered or exhausted as part of this activity.
An input link indicates that the attached object or resource is consumed in the processing procedure. As an example, as customer orders are processed they are completed and signed off, and typically are used only once per unique resource (order).
Inputs, Resources and Information
In general Business Process Modelling is used to create an understanding of business processes and to assist the design and implementation of software systems.
An event is the receipt of some object, a time or date reached, a notification or some other trigger that initiates the business process. The event may be consumed and transformed (for example a customer order) or simply act as a catalyst (e.g. nightly batch job).
Events
A business process will typically produce one or more outputs of value to the business. An output may be a physical object (such as a report or invoice), a transformation of raw resources into a new arrangement (a daily schedule or roster) or an overall business result such as completing a customer order. An output of one business process may feed into another process, either as a requested item or a trigger to initiate new activities.
Outputs
A business process has some well defined goal. A goal is the business justification for performing the activity, it is the reason the organization does this work A goal link indicates the attached object to the business process describes the goal of the process.
Goals
BPMN is intended to be extensible by modelers and modeling tools. This extensibility allows modelers to add nonstandard elements or Artifacts to satisfy a specific need, such as the unique requirements of a vertical domain. While extensible, BPMN Diagrams should still have the basic look- and-feel so that a Diagram by any modeler should be easily understood by any viewer of the Diagram.
footprint of the basic flow elements (Events, activities, and Gateways) should not be altered. Nor should any new flow elements be added to a BPD, since there is no specification as to how Sequence and Message Flow will connect to any new Flow Object.
In addition, mappings to execution languages may be affected if new flow elements are added. To satisfy additional modeling concepts that are not part of the basic set of flow elements, BPMN provides the concept of
Extensibility of BPMN and Vertical Domains
Since BPMN covers such a wide range of usage, it will map to more than one lower-level specification language:
• BPEL4WS are the primary languages that BPMN will map to, but they only cover a single executable private business process. If a BPMN Diagram depicts more than one internal business process, then there will a separate mapping for each on the internal business processes.
• The abstract sections of a BPMN Diagram will be mapped to Web service interfaces specifications, such as the abstract processes of BPEL4WS.
• The Collaboration model sections of a BPMN may be mapped Collaboration models such as ebXML BPSS, Rosetta- Net, and the W3C Choreography Working Group Specification (when it is completed).
This specification will only cover a mapping to BPEL4WS. Mappings to
