Towards Human-Executable Business Process Modeling

Janis Barzdins, Edgars Rencis, Agris Sostaks

Institute of Mathematics and Computer Science, University of Latvia

____________________________________________________________Tenth International Baltic Conference on Databases and Information Systems, July 9, 2012, Vilnius, Lithuania

Organizations are process-oriented• Processes = tasks to be performed

▫simple case – sequenced list of processes natural or graphical language

▫real case – processes have become much more complex branching conditions terms parrallelism etc.

• Who will execute thoes processes?▫Who will perform the tasks?

Processes can be executed by...• ... a machine

▫everything needs to be fully automated▫not a realistic scenario

what if some unforeseen exception occurs?• ... a human

▫human needs to understand the process completely What have to be done? When does it have to be done? How does it have to be done?

▫machine can still help a lot what software options do we have?

So what do we have to choose from?

http://www.column2.com/2005/05/bpm-momentum http://msdn.microsoft.com/en-us/library/cc168592.aspx

- expensive,- complicated,- contains a lot of

unnecessary features

- needs to be built from scratch

- needs to be redesigned for every new system

http://www.silverbearcafe.com/chasm.html

good base for domain-specific process modeling languages

appropriate tooling

Problems• What kind of instructions can be understood

and executed by a human?▫ textual vs graphical language

one page of good graphics can supersede ten pages of text

▫ is there a good graphical notation for decribing processes? what exactly is good?

• How a support tool can be implemented for the language▫assuming we have a good language...▫ the implementation should be easy and

convenient

The definition of good(in terms of language and tool support)• Language must be simple enough

▫performers are not IT professionals▫more on this later...

• Language must include the organization specifics▫it must be domain-specific▫tool must offer possibility to extend the language

easily• Tool must alleviate executing the language

▫connection to organization's information system▫all features accessible "by one click"

The language base• We can develop new domain-specific process

description languages upon it▫no need to build from scratch▫languages for similar domains usually contain

some common part• The base is supported by a tool

▫additions to tooling must be made only to support additions to the base

• Performers can understand the process completely▫language provides 95%▫tool provides remaining 5% "by one click"

Good graphical language•Human being can perceive information

easier, if it is structured in natural language sentences

•James Rumbaugh, 1991:▫class diagrams should be readable as

natural language text•Same can be applied to process diagrams

▫good process should be readable as natural language text

▫after all, processes were initially described in textual form

Graphics Text

•Subset of UML Activity diagrams▫slightly modified semantics

•The Golden Mean▫simple enough

regular person can understand it natural language generator can be built for it

▫expressive enough sufficiently wide class or processes can be

described

Elements of language base

Action Start Process Header

Time Condition

General Condition

Decision

Guard Conditions

Exception

Fork

Join

Merge

End

Reference

ObjectDetailed Action

Text generationConcept of process language base

Natural language construct

Performer of Action Subject

Name of Action Predicate + Object + Verb Phrase

Description of Action Sentence(s) in parenthesis

Reference “See details in ” + name of Reference

Time Condition Time Adjunct

General Condition, Guard Condition

Subordinate Clause starting with “If”

Some agreements about how to develop process diagrams (using correct verb forms, etc.)

Diagram to MS Word

Description of process steps

Description of process steps

Case study• Process modeling language for the University of Latvia

(UL)• Several tasks

▫ to create a BPM language notation for UL language base supplemented with UL-specific

▫ to create a supporting tool done by using the GRAF platform

▫ to perform initial modeling of UL processes including traces to regulations, laws and features of LUIS (IS of

LU) made reachable "by one click" from the process description

several significant areas have been covered▫ to publish process descriptions in graphical form

published in intranet of UL keeping keeping all connections to document sources and LUIS alive

▫ to generate textual description of processes in UL-specific form done by using the MS Word engine built in the GRAF platform

Lessons learned• Human-executable systems are very widespread

▫ universities, hospitals, government institutions, etc.▫ banks require higher level of precision (workflow)

• Language base – very simple and easily perceptible▫ users can be easy easily and rapidly trained

very important feature of any language connection to natural language increases the understanding

▫ clear separation between semantics and syntax of elements• Modeling can discover deficiencies and incompleteness in

documents• Technology behind the GRAF platform is very good

▫ language development process differs entirely from the one of heavy-weight modeling tools

• Diagrams are more suitable to human usage than textual process description▫ users had not read the regulations because information was not easily

obtainable▫ in graphical form every piece of information can be located more

quickly

The conclusion

Process model may (and should) serve as an information backbone, which helps the end-user to easily access the services and

tools needed to complete his/her tasks