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 Source J.Tidd, 2000
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 2 1 Target Process Model! pick a similar process! look left! and then right! process rccombinator! trade-off matriz 3 Select Process attributes and values Bundles and trade of tables
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 the time slot and so on. All of that are committments
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 achieved by has exception goal process exception requires is handled by
example Refining transformation Specializing 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
Repository of business process knowledge A representative set of generic business process templates and specific case examples to illustrate how the concepts and framework can be used;
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
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.
What is a Model? 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.
Why a Business Process 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.
Type of Business Process 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 differences between the two domains have to be considered, in example security and legal aspects.
The need for Business Process Standards 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 collaborationbased 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 are two complementary parts to workflow: the control flow and the data flow. The control flow defines the sequencing of different activities in the process. The data flow defines how information flows between activities.
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. Longrunning 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 messages between participants in collaboration-based processes.
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-ofservice 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 carry out specific functions (identified by roles) in a public business process.
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.
Integrated Enterprise Modelling (IEM) 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 goals, such as improvements in time, costs, or quality, to each business process and resource and, therefore, to optimise the process organization.
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.
The Information Model 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 Process Model 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. Action Function Activity Action Action Action
The Process Model 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. Order State n State n+1 Order Product Resource Action Order Product Resource Resource
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). Each element in the model has its own attributes describing objects features.
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-orderresource information) to the more abstract one
IDEF0 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 between portions of the same model, connect to the bottom of the box and point downward. Figure 6 is an abstract view of IDEF0 notation.
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 and cost can be expended for little benefit if those objectives are not properly understood. Business Process Modelling is used to create an understanding of business processes and to assist in their the design and implementation.
IDEF0
IDEF3 Process Flow 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 semantic provides also junctions to connect process activities in parallel way:
UML: Eriksson-Penker Business extensions 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
Business Process 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 right. To specifically notate the internal activities, UML activity elements may be placed inside the process element.
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. 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).
Events 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).
Outputs 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.
Goals 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.
Extensibility of BPMN and Vertical Domains 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 lookand-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 Artifacts that can be linked to the existing Flow Objects through Associations.
BPMN Mapping 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 other specifications will have to be a separate effort, or perhaps a future direction of BPMN (beyond Version 1.0 of the BPMN specification).
Core Modelling Elements
Core Element Set
Core Element Set