Usage of business processes models: Theory and Practice

Girts Karnitis, Janis Bicevskis

Problems of Business process modeling

• In most cases models are used once and then become outdated

• Universal modeling languages UML and BPMN are created by IT for IT and not easily understandable by business people

• Model syntax prevails over model’s meaning – semantic

Our approach

• Focus on model semantic according to model usage

• Assign to model objects (activities/tasks/transitions) domain specific information and informal descriptions

Types of models according to model’s usage

• Business process description• Business model determines definition of

process• Business model serves as requirement

specification for IS development• Business model create the base of IS operations’

description

• Automatically test of model consistency

Business model

IS model

Informal information

One model – many applications

Future: Model as enterprise wide knowledge base

• Model serves as process description for human as well as IS (computer)

• Human understandable model can be with different detailing level according to user type

• Changes in business processes (legal acts) establishes changes in IS behavior

Comment:– Models serves as part of enterprise regulating

documentation as well as part of IS

Model as business process description

• Used to understand business process • Business people intuitively understand model

syntax and semantic• Informal

Informal enterprise registration process model created for clients to easily understand model

Model as business process description

Informal enterprise registration process model created for business people to easily understand model

Model as definition of process

• Used as instructions to run process by business people

• High level of formalization and precision (~98%)

• Links to external documents, forms etc.• All necessary information is one click away

Example of document attached to one step of the model

Model as definition of process

Enterprise registration process model precise enough to serve as instruction for process execution by business people

Model serves as requirement specification (IS diagrams)

• Must be precise enough to serve as requirements specifications

• Usually is some type of detailing of previous models

Model step refinement for requirement specification

Model serves as requirement specification (IS diagrams)

• Serve as a basis for development of software functional requirements containing data input, data output, data processing and data verification

• Determine, which business process fragments should be implemented in information system and became fully automated and which should remain manual even after information system is introduced

• Allows to make analysis who use which data• Can serves as a basis for creation of test cases for

software testing

Model serves as basis for IS operation

• Information system understands and interprets defined model

• Model are 100% precise• Parts of model might be hardly

understandable by business people

Model as basis for IS operation

Enterprise registration process model created in modeling language Bilingva

Correctness of Business process models

• Correctness of single step• Correctness of gradual detailing • Properties of Petri nets («Soundness» -

Reachability, Liveness, Boundedness)

Correctness of single step

• Diagram's external process must be described in other diagram as common process

• All documents used in flows must be defined in document list

• All actors must be defined in actors list • All legal acts and their parts must be defined

in legal acts lists

Correctness of gradual detailing

• Consistencies of processes can be checked between different hierarchical levels or inside of the same level– If a document is proceeded in a higher level of

model, it should also be included into the detailed levels

– If an document is sent from one process to another, there should also be a receipt of the item foreseen

Properties of Petri nets

• Option to complete – from every situation reachable during execution, process can proceed to the finish

• Proper completion – process ends in clearly defined state and it guarantees that all messages are processed

• Absence of dead activities – for any activity exists some legal path, during which this activity can be reached

Unsolvable constructions

• OR-joins• Cancel Region

• Theoretically if we use these constructions, we can create process for which Soundness cannot be decided

Petri net property «Weak Soundness»

Weakens «Option to complete» and asks to have at least one path how to complete the process

Wynn T, Verbeek H, van der Aalsts W, etc.; Business Process Verification – Finally a Reality!; 2007

Some results of Petri Nets «Soundness» IBecause of simplicity of business processes, in many cases «soundness» problem can be decided. (Exhaustive search can be done with available resources, exists tools and experiments.)

D. Fahland etc., Analysis on Demand: Instantaneous Soundness Checking of Industrial Business Process Models

735 real life models are checked. Full check of one model on medium strength computer (2 GHz, 3MB RAM) takes less than second. 95% of models where successfully checked.

Some results of Petri Nets «Soundness» II

We think, that «soundness» problem for models of Computing Faculty of University of Latvia can be decided

DSL expressiveness

• DSL can have some constructs, that makes DSL expressiveness as powerful as Turing machine (we call them superrich DSL):

• Information input commands (get(x, ...))• Information output commands (put(x, ...))• Variables:

– numeric– symbolic

• Arithmetic operations• Logical operations

«Soundness» of superrich DSL• In general «soundness» of superrich DSL is unsolved

problem• In special cases «soundness» of superrich DSL is decidable

problem:– Limited use of read/write operations and arithmetic

operations (conclusions of FTS theory)– There are exist some concept of model state, that model

can be reduced to finite state automata (specific state concept can be found for model, that reduces model to finite state automata)

• If model can be reduced to finite state automata, then many «hard» problems can be decided

• Theoretical research and experiments of these problems are in progress

Experience

• It is hard to describe all of the sector specific requirements– For example, hard to access informal model

description stored in enterprise IS• There are very positive attitude of users

towards graphical specifications– More than 95% users prefer graphical model

Experience

• At the beginning business people are able to make only informal models. After some time they started to ask for more precise models– Business people are able to read precise models

after very short learning period– It took 6-12 month for business people to start

develop precise models that can be served as precise work instructions

– Full adoption took 2-4 years

Experience

• DSL allows create single unified model within organization for all four usage scenarios

• Users can easily understand meaning of models and use models if business process semantic is bind to the model objects– Syntax does not matter very much

• DSL building is one of the easiest way to bind semantic of the specific domain to the model

Conclusions

• DSL definition and modeling tool definition platform plays one of mayor role for DSL usage– It is practically impossible to implement in real life

methodology we describe without such platform• Survey shows that end users definitely prefer

graphical diagrams instead of traditional text documents

• Proposed process modeling methodology is examined in workflow type systems– For other types of systems the situation may differ

Problems• Definition of DSL and development of modeling tools

requires involving high qualification specialists• Enterprise specific DSL development and business process

definition is individual as enterprise specific IS development

• DSL defined for needs of one company is hard or impossible use in other company even if the companies’ profiles are very similar– DSL for each enterprise contains nuances specific for each

enterprise– Previously developed DSLs can be used in the very beginning of

modeling and help to recognize specific of new domain• Automatic model correctness check is new idea and is not

clear how to perform it for any specific DSL

Thank You