BPMN Business Process Modeling Notation Business Process Modeling Notation Model and notation business of processes

Aspects of compliance of the BPMN specification

1. Appearance of the graphic BPMN elements. The crucial element of BPMN is the choice of the forms and icons used in the graphic elements specified in this specification. The purpose – creation of standard visual language which will be recognizable and clear for all developers of processes, regardless of a scheme source. Any tool used for creation of the scheme BPMN should correspond to the forms and markers specified in this specification. There is a possibility of size variation, color, line style and arrangement of the text of graphic elements. During creation business of process the following changes are allowed:

• Changes of circuit elements can be performed by means of the new markers or indicators relating to these graphic elements. These markers and indicators can be used for selection of specific sign of activity or, for example, for creation of new type of the Event. Besides, changes can also consist in change of color or line style of an object provided that change should not enter the conflict with any line style provided in BPMN.
• Changes should not influence the general form of graphic elements and markers (for example, transformation of a square into a triangle or change of the rounded-off corners on right angles, etc.).
• On the scheme any quantity of artifacts of various forms can be added provided that the form of an artifact should not enter the conflict with a form of this object or a marker.

Description of BPMN

In BPMN only the concepts of modeling applicable to business to processes are considered. It means that other types of the modeling executed in the organizations within business activity will not be considered in BPMN. For example, BPMN will not join the following types of modeling:

• Organization structures and resources
• Functional diagrams
• Data models and information models
• Strategy
• Business rules

As these types of high-level modeling directly or indirectly correspond about business by processes, the relations between BPMN and other types of business simulation of the high level will be defined more formally as BPMN, and other specifications will appear. Besides, though BPMN reflects a data stream (messages) and interrelation of artifacts of data with actions, it is not the scheme of a data stream.

Semantics of the BPMN elements

This specification also defines a method of interaction of graphic elements with each other, including the conditional interactions based on the attributes creating behavioural changes of elements. The tool of compliance should correspond to these semantic descriptions.

• Throughout all document specific semantic descriptions of BPMN will be selected in the form of paragraphs with bullets of a special form, as shown in the following example:
• Consecutive flows can enter a task; it can have a set of the entering flows. The entering flow can go from an alternative route, and/or from parallel routes.

Exchange of the schemes BPMN between compliance tools. This draft of the specification does not contain the standard mechanism of exchange of schemes. The nature of this mechanism is not defined yet. Development of the XML scheme which is one level above BPEL4WS XML scheme or use of the standard interchange formats schemes, for example, of XMI could be necessary for its studying. When the exchange mechanism is defined, the tool of compliance should have capability to import and export the schemes BPMN in a certain format. Introduction of correspondence rules does not assume processing of any substandard change of elements or attributes or any document BPMN which contains these changes.

Visible advantages

• BPMN allows to monitor influence of a surrounding business environment on process: the message is received, there was an exclusive situation, the client refused the order, failure of the equipment. Emergence of any situations requires processing, they force process to go differently, and to everything it is necessary to be ready for an exception of the maximum number of failures in the process course. Failures are understood as situations when it is unknown that to do at anyway current situation, but it is necessary to do something (events: messages, timers, signals, errors, compensations and away).

• BPMN allows not only to select contractors for each action, but to integrate contractors in groups that allows to control and monitor their hierarchy (pools and leyna). The instructions of contractors in leyna, in addition, allow to concentrate the actions put to one contractor in one place that it was possible further when reading the scheme accurately to select a role which in this process is played by the contractor.

• BPMN allows to model interaction with outer objects: call as contractors of clients, suppliers and other roles which are involved in process indirectly.

• BPMN allows to provide process so in details as far as it is necessary. Extent of detailing is limited only to competence of the employee.

• The binding to certain actions of objects of a system which are applied or created during the course of performance this or that action is available, i.e. it is possible to describe not only workflow, but also document flow.

• Broad classification of subprocesses of BPMN helps, in a case when at the description of one business process it becomes clear that one enters it or n of times some other process. Then it is possible to leave on the scheme of one process only the link to other process which, in turn, to describe on other scheme, and it is possible in the same scheme within the unrolled subprocess. And if subprocess cycling, then and it it is very simple to simulate.

Notation of BPMN: visible restrictions

• In it there are a lot of types of blocks. It is possible to describe same, but by different methods: it is possible to simulate sending the message the corresponding event or action with the Sending type. The scheme of uniform process at different modeling will look differently, but semantics will be identical.

• When modeling linear processes with a great number of contractors in whom each contractor performs one-two operations it is possible to receive difficult readable scheme spread in vertical direction.

• The notation does not allow to specify the cost of accomplishment of this or that action in terms of money.

BPMN 2.0

BPMN 2.0 – the international standard Object Management Group (OMG) which in a graphic type displays a status and modeling of business process. Using intuitive characters and text information everyone the participant can monitor development of process through its graphic display.

One of main goals of BPMN – creation of standard model clear to all users who are involved in the general project: to sales managers, analysts, technical developers and personnel. Using BPMN 2.0 the head of sales department, for example, can plan and record all processing of the order: obtaining the request from the client, formation of the offer, editing and sending the ready offer to the client, receiving and processing of the order at the positive solution of the client. Thus, the module BPMN acts as a link between a creation phase business of process and a phase of its implementation and also allows to control work of sales managers.

Goal: The fixed sequence of tasks

• Reduce choice reaction time the contractor
• Provide transparency, control, monitoring and a uniform execution order of process
• Exclude data entry errors in other information systems participating in decision making process, and the additional checks connected with it
• Accomplishment of problems of process in the sequence approved by managers and methodologists

Examples

• Work of the operator in bank, on commission of client transactions
• The accounting processes regulated by rules and regulators
• Mass order processing, requests, customer appeals, etc.
• HR processes on a design of needs of employees
• Holding medical procedures on doctor's orders in clinic

Classification of scopes of process notations

1. "Architectural pictures"

How does our company make money? How does the matrix processes-functions-resources look? By what information systems what business processes are serviced? If you want to draw a small square, to write in it the name of the company to unroll it in a value creation chain, and then to show interrelation of key processes, then the best IDEF for this purpose did not invent anything yet. As option, DFD. But definitely not BPMN.

2. "Process pictures"

If you want to understand and regulate work of employees within separate processes for yourself and/or for certification on ISO, then the choice of process tools at you is broadest: beginning from poorly formalized flowcharts and workflow-charts to EPC. BPMN copes with these tasks not worse, but perhaps and not better.

3. Automation

If on the first place for you development of the program, and process - only one of aspects of this program, then the natural choice for you is UML. If it is not about development, and about implementation and the accompanying customization of ERP then excellent positions at EPC as you will be able to stranslirovat process charts, for example, in settings of SAP.

4. Direct execution

Broadcast of process charts in a program code perfectly works provided that it is about single automation: analysts worked, drew process charts - programmers worked, implemented them in a system - implemented, we use. Question only in as far as such problem definition is realistic?

In recent years more and more widespread is an opinion that for a wide class of processes, namely business processes, and in particular business processes cross-functional (i.e. the involving more than several divisions of the top level) and end-to-end (beginning and coming to an end on the client) this key assumption of the concept of process automation is not executed.

Business processes change, and change rather often - in the range, conditionally, from weekly to quarterly. And here arises well-known (though, perhaps, in narrow circles) -

Round-Trip Problem

There is it as follows:

• Step 1. Business analysts extorted from experts in data domain everything that could, and displayed the gained knowledge of business process in the process chart.
• Step 2. Programmers turned charts into a program code.
• Step 3. A system is implemented and began to be operated.
• Step 4. Business process changes. The state changes rules of the game, competitors raise a level, customer requirements grow - process should be changed as stagnation is death.

Or what is even more often, our idea of business process changes - only on the basis of operating experience we begin to understand how actually we work.

Anyway, comes it is time to review process, and the analyst takes its scheme from archive to change (to optimize, bring into accord with reality - necessary to emphasize). But here two unpleasant moments are detected:

• 1. When implementing the scheme of process drawn originally programmers departed from it - at first slightly, and then, during debugging and implementation, further and further.
• 2. If it is possible to transform the process chart to a program code at the first pass automatically, then broadcast of changes of the process chart in changes of a program code is already executed manually, and its complexity varies in the range from "high" to "forget!".

• Step 5. Came: programmers take business process in hand and more do not release it any more. For all changes of business process to address them, and they implement your wishes moderately of the understanding. About any transparency of business processes which was promised by a graphic process notation, the speech does not go any more - process "is buried" in a program code. So, business analysts and, indirectly, do not control business, process any more.

And a situation this uncomfortable not only for business, but also for programmers as this burden for them is very heavy. As a result we receive a bouquet of the contradictions known as a gap between business and IT:

• "all because some do not know what is honut"
• "no, all this because at some hands grow not from that place"

Links

• Why BPMN matters
• BPMN: Practice of use

See Also

• Business process
• BPEL
• SOA