1. Usage of business processes
models: Theory and Practice
Girts Karnitis, Janis Bicevskis

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

3. Our approach
• Focus on model semantic according to model
usage
• Assign to model objects
(activities/tasks/transitions) domain specific
information and informal descriptions

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

5. One model – many applications
Business model
Informal
information
IS model

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

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

8. Model as business process description
Informal enterprise registration process model created for business
people to easily understand model

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

10. Model as definition of process
Enterprise registration
process model precise
enough to serve as
instruction for process
execution by business
people

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

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

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

14. Model as basis for IS operation
Enterprise registration process model created in modeling language Bilingva

15. Correctness of Business process models
• Correctness of single step
• Correctness of gradual detailing
• Properties of Petri nets («Soundness» Reachability, Liveness, Boundedness)

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

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

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

19. Unsolvable constructions
• OR-joins
• Cancel Region
• Theoretically if we use these constructions, we
can create process for which Soundness cannot
be decided

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

21. Some results of Petri Nets «Soundness» I
Because 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.

22. Some results of Petri Nets «Soundness» II
We think, that «soundness» problem for models of Computing Faculty of University of Latvia
can be decided

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

24. «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

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

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

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

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

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

30. Thank You