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? -expensive, -complicated, -contains a lot of unnecessary features -needs to be built from scratch -needs to be redesigned for every new system  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 StartProcess Header Time Condition General Condition Decision Guard Conditions Exception Fork Join Merge End Reference Object Detailed Action

Text generation Concept of process language baseNatural language construct Performer of ActionSubject Name of ActionPredicate + Object + Verb Phrase Description of ActionSentence(s) in parenthesis Reference“See details in ” + name of Reference Time ConditionTime Adjunct General Condition, Guard ConditionSubordinate 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

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