Available online at www.sciencedirect.com
ScienceDirect Procedia Computer Science 77 (2015) 72 – 79
ICTE in Regional Development
Business Process Models and Information System Usability Janis Bicevskisa*, Zane Bicevskab a
University of Latvia, Riga, Latvia b DIVI Grupa Ltd, Riga, Latvia
Abstract The paper describes the use of business process models for effective managing of information system execution processes and transparent representation of execution statuses. Contrary to traditional approaches where business process models are used only in the initial stages of information system development, the proposed approach suggests direct utilization of business process models during the use of information systems. Information system usability can be improved by using new means of representation, and business process models can serve as an efficient way to visualize execution processes in information systems. © Published by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license © 2015 2016The TheAuthors. Authors. Published by Elsevier (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Sociotechnical Systems Engineering Institute of Vidzeme University of Applied Sciences. Peer-review under responsibility of the Sociotechnical Systems Engineering Institute of Vidzeme University of Applied Sciences Keywords: Business process modeling; Domain-specific languages; Business process execution; Usability
1. Introduction Information systems usability issues have been widely studied in the last decade. Various papers, books, technologies are devoted to finding an answer to the crucial question of how to make information systems more easy and effective to use? Usability has been a topical issue, especially in human-guided systems. Many hardware improvements, for instance, keyboard with function keys, mouse, touchscreen etc. enhance usability of humanguided systems. The use of business process models is one of the research areas that could potentially generate new ideas for improvement of information systems’ usability.
* Corresponding author. E-mail address:
[email protected]
1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Sociotechnical Systems Engineering Institute of Vidzeme University of Applied Sciences doi:10.1016/j.procs.2015.12.361
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
Process models have already been used in complex engineering systems long ago. For instance, dispatchers of electricity supply networks use monitoring screens with grid patterns representing electricity suppliers and customers as well as power lines between them. The dispatchers use graphical process models to get information about voltage, frequencies and other parameters needed to monitor processes. The representation allows managing of normal process execution by accessing singular objects of the process model directly. Additional electricity production capacity can be initiated directly by a click on the particular power producing entity. Could similar business process execution i.e. direct access to entities of the business process model be useful in information systems? The business process model is described with graphical diagrams1 which can be arranged hierarchically thus representing gradual detailing. Each diagram in the hierarchy describes one object or activity of a higher level. Diagrams are composed of graphical symbols representing activities necessary for execution of business processes as well as data objects, control and data flows, time constraints and other artefacts. Is it possible to work with graphical elements of diagrams directly, as it was done in the previously considered example? What requirements should a business process model fulfil to be suitable for direct execution of information processes? The first chapter deals with the problem statement. The second chapter describes the essence of the problem solution. The third chapter analyses related researches. The fourth chapter describes the prototype used to approbate the concept of direct execution and discusses visualization issues. The fifth chapter is dedicated to the formalization and implementation issues of the direct business process execution. The conclusions summarize experience gathered during the research and prototype approbation. 2. Main idea and the essence of the solution Authors of this research propose an original solution to business process execution management and visualization. Unlike traditional information systems where business process execution is carried out using interface controls (windows, screen forms, menus), the proposed approach is to manage business process execution directly using graphical diagrams that describe business processes. Respectively, the user can initiate process execution activities directly – by clicking on the desired element of the business process diagram. In this way all relevant activities can be initiated: start process execution, choose execution path, open data objects / documents, finish process execution etc. The executed activities may be visually depicted in the business process diagrams, for example, by colouring already executed business process steps. The proposed business process execution mechanism allows to significantly improve the usability of information systems. The setup of traditional information systems assumes that users know by heart the sequence of activities to be performed and are able to initiate activities in the right order using menus and/ or buttons on screen forms. The traditional way of business process execution requires more elementary operations (open/close screen forms, open menus, select elements etc.) from users than the approach of direct execution. In the author’s opinion the proposed approach is more effective from an ergonomic standpoint than the traditional business process execution. The direct business process execution could be implemented according to the following schema (see Fig.1). First the business process model is designed, and it consists of graphical diagrams. The diagrams contain elements needed for direct execution of business processes – activities, data objects, control and data flows etc. The modelling language and the tool for creating/editing of business process descriptions can be chosen rather freely. But one important requirement should still be taken into account: the process model stored in the repository of the supporting tool must be open for external usage, i.e., the elements should be accessible via API, and developers should be familiar with the internal structure of model. Linking executable routines to particular model elements allows initiating execution of the routines by clicking on the next element in the model that should be executed. This implementation differs from the traditional information system development approach where the implementation of specific activities is tied to user interface elements. Users of the systems implemented in the aforementioned way can initiate execution of processes directly from graphical diagrams, not just using the traditional interface controls (windows, menus etc.). The direct execution approach is usable if and only if: (1) the model precisely and definitely describes all artefacts essential for execution, (2) model is executable (either manually or by computer). Users can execute business process steps manually (without a computer), or semi-automatic (a part of the activities is executed manually by users, and the other part by an information system), or fully automatic (all activities are executed by the
73
74
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
system without any intervention from the user’s side). The execution issues make the difference between the proposed solution and the cases when the model serves for better understanding of processes and it cannot be used in an automated way.
Fig. 1. Business process execution (overview).
The hypothesis of this research: the proposed approach of direct business process execution improves the usability of the information system in comparison to traditional information system implementation techniques. 3. Related research and solutions There are information systems already running in the interpretative mode according to the business process model. The most popular of them are workflow management systems. According to the Workflow Management Coalition2, a workflow represents “the automation of a business process during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules”. In the comparison of workflow management systems3 the JIRA is recognized as the most popular4: “JIRA is the workflow management tool for teams planning and building great products.” The second most popular workflow management system is KiSSFLOW5. Workflow systems are characterised by ten features, the most important are: graphical workflow representation, data object representation in screen forms, generated reports, role-based accessibility. The workflow systems do partially support the ideas of direct business process execution described in this paper. But the main focus in commercial workflow solutions is on the transferring of tasks among different users. The executed tasks and entered date are visualized but the tools do not offer direct business process execution. Theoretical researches use an axiomatic approach6 that can hardly be used for practical application. Concurrent processes are sometimes described using Petri networks7 where the main focus is on the correctness of processes. The theoretical researches are out of the scope of this paper. 4. Prototype This chapter describes a prototype of an information system that was used to demonstrate the ideas of direct business process execution. The next chapter generalizes the ideas. A working time tracking system has been chosen as a pilot. Working time tracking systems are widely used in many enterprises, so the functionality issues will not be discussed in detail. One process was selected to demonstrate the direct process execution – the process of employee’s working time registration. 4.1. Working time tracking system The prototype was developed to approbate ideas of direct business process execution, and a working time tracking system WTTS was chosen as a pilot. Let us concentrate on just two objects/classes: x Project – contains an information about projects executed in the enterprise; one project is an instance of the class Project x Time - contains an information about the time work of employees; a timeframe spent for a specific type of work by concrete employee is an instance of the class Time
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
The system WTTS covers five business processes, we will inspect one of them – WorkingTime – in detail (see Fig. 2.). The business process steps are shown in the upper part of the diagram, the data objects, which are updated during the processes, are shown in the lower part of the diagram. The process WorkingTime provides the possibility to input all information about employee working time (data object Time), to control and to correct it if necessary. Let us assume that the employee has already identified himself during the sign-in process. The process WorkingTime is started by clicking with the mouse on the diagram’s symbol that represents the process WorkingTime (this diagram is not included because of space limitations). As a result the diagram shown in Fig 2 is opened.
Fig. 2. Direct execution of the process WorkingTime
The process execution starts with a semi-automatic step to-Do which is initiated by a mouse click on the according step (element) in the graphical diagram. All actual Projects are selected and shown in the screen form data-Objects. User specifies the desired project the working time will be tracked for and presses the OK button. Therefore the first step is done. If the user does not like to continue, he/she chooses the Cancel button. During of next process step (time-Input) the screen form spent-Time is opened and the user can input the spent time for the project that was specified in the previous step. The process steps to-Do and time-Input can be repeated several times. By clicking on the step syntactic-Control the automatic step is executed that checks the syntactic correctness of the entered information. It can result with a notification about necessary changes or it can lead to the termination of the process. If the process is terminated, it means the user has finished his/her part of the process and the next step is assigned to the relevant project manager. In the next step accept-Time-sheet the project manager gets the diagram of the active business process with coloured steps that were executed by the employee. This step is executed manually – again the screen form spentTime is opened, and the project manager can examine the entered information on the substance. If necessary the project manager lets an employee correct the information entered (step time-Input), or he/she can save the information examined (step Save). The step Save is executed automatically, and it saves the by user reported and by project manager accepted time in the data base. 4.2. Usability metrics and evaluation ISO defines usability as "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.” The ISO/IEC 9126-4 Metrics8 recommends that usability metrics should include: x Effectiveness – the accuracy and completeness with which users achieve specified goals. It can be measured as Percent of tasks completed, Ratio of successes to failures, Number of features or commands used and others. x Efficiency – the accuracy and completeness of goals achieved in relation to resources. It can be measured as Time to complete a task, Time to learn, Frequency of help or documentation use, Percent or number of errors and others.
75
76
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
x Satisfaction – freedom from discomfort, and positive attitudes towards the use of the system. It can be measured as rating scale for satisfaction with functions and features, rating scale for user versus technological control of task and others. From the effectiveness perspective the benefit of direct business process execution is the transparency of the business process as it is represented in the form of a graphical diagram. It is assumed in the traditional solutions that the users know the processes by heart. It leads to many mistakes as users are forced to remember semantics of all user interface elements. The criterion of satisfaction is fulfilled because the entire business process is available in the appropriate context of the activities. It provides a number of positive aspects – the executed process steps are visible without extra actions, data objects are directly accessible for editing, reports are directly usable etc. The proposed direct business process execution approach is still in the experimental phase. The benefits and disadvantages can be detected during practical use. However, already in the initial phase of modeling the users clearly (95%) preferred the graphical diagrams9. The user survey showed that one graphical diagram can substitute 8 to 10 pages of textual instructions. Further benefits can be expected from the direct business process execution in later stages of research. 5. Formalization of direct business process execution 5.1. Memory of process execution Let us define the semantics of process execution by using a “hypothetical” machine (see Fig. 3). It consists of (1) a memory that stores instances of data objects and processes, and (2) an engine that is able to execute particular process steps/ statements consecutively. Data object instances are stored in the data objects part of the memory, and process instances – in the processes part of the memory. The data objects part contains: x data objects - the data objects should be processed, but processing has not been started yet x active data objects - the data objects are in processing and are not finished yet; the active data objects have corresponding active process instances x processed data objects - the processing is finished, but the data objects can be used by other processes x archived data objects - the processing is finished, and the data objects can’t be used by other processes anymore The processes part of the memory stores instances of processes that were created by copying the process diagrams and by linking them to the data objects to be processed. There are two kinds of process instances: x active process instances – the process instances are in processing and are not finished yet; the active processes have corresponding active data objects instances x passive process instances - the processing is finished; nevertheless it is advisable to save the passive process instances for repeated processing if such a need would be found 5.2. Process initiation and execution The process execution starts with user login into the information system. Let us assume user identification is implemented in a traditional way, i.e., by entering a login name and password. It is important only that the information system, as a result of electronical identification (authentication and authorization), has granted the particular user the rights to execute certain business processes and access certain data objects. The first step of the business process execution is to let the user choose the business process that should be executed and link the process to the desired data object. There are two different cases possible: a) an initiating of a new process, and b) a continuation to execute an already initiated process. If a new process is initiated, a new process instance is created by copying the process description. During the execution the recently created process instance will be linked to the data object that should be processed.
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
77
Technically the execution of the process instance is activated when the user clicks on the process to be executed in the process model.
Fig. 3. Direct business process execution
To continue the execution of a process that has already been initiated before, the engine finds the process instance in the active process part of the memory, and the process execution is started/ continued from the point in the process model where it was interrupted in the previous execution session. In addition, the user can see the executed steps in the process diagram. Technically it is implemented as an individual user’s activity that is prepared and acts according to the to-do-list principle– the user can choose between all active (unfinished) process instances that are attributable to him/her. Processes are executed step by step. The steps can be processed manually, semi-automatic, or automatic. Manual steps are initiated by the user clicking on the step that should be executed, and the next steps are initiated in the same manner as the execution of such steps is not related to the information system’s operation. Semi-automatic steps are also initiated by the user but, contrary to manual steps, the execution is completed by certain user activities. For example, within the step a screen form is opened with editable fields, the user fills in the necessary data and presses the OK button. Automatic execution is performed without user interaction. For example data object saving in the database is an automatic operation as it is done completely by the software. 5.3. Visualization of data objects and process execution Data objects are represented in screen forms, and one screen form describes one or several data objects. A screen form can contain many fields to be added/ edited/ deleted. It can also serve for selecting of data objects. There are some improvements practiced for easier identifying and specifying of data objects: (1) show attribute values in screen forms to let users recognize the necessary objects, (2) allow filter data objects in screen forms to narrow the set of object instances, (3) colour fields in screen forms according to the data objects instance status (for instance, the corrigible fields could be shown in a different colour). Furthermore, some data columns or fields could be disabled (not displayed at all) if the user does not have rights to access the data objects. Development of screen forms is relatively simple, and it can be done using traditional methods (programming). Business process diagrams are suitable for the visualization of process execution. Process execution can be represented by colouring the already executed activities and control flows in a different colour. In the general case only those elements of business process diagrams will be coloured which have been involved in the processing of the concrete data object. The shaded track allows identifying the executed steps and continue process execution from the point in the process model where the execution was interrupted in the previous session. In case of asynchronous process execution (for example, the data object information can be entered by several people in different time frames) the execution can be continued from the point in the process model that is accessible for the specific user after the interruption in the previous session. In this case the user points to the element in the diagram and initiates the continuation with a mouse click or other activity (for instance, it could be a special button Next).
78
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
5.4. Business process modeling environment DIMOD The development of information systems with built-in direct business process execution differs significantly from the development of ordinary information systems. Instead of developing windows with popup menus, control buttons and other interface elements for process managing, graphical diagrams with process descriptions/ definitions should be available to users to ensure the possibility of managing processes directly, without usage of menus. Process execution must be visualized in the process diagram so the performed actions can be seen. Therefore traditional application development has been replaced by creating diagrams describing business processes. Business processes should be made executable by linking diagram elements to related software routines. This chapter describes one possible solution that is based on the features of the modeling tool DIMOD. The tool DIMOD is a modeling platform for creating and editing business process diagrams in a domain specific language (DSL), publishing the diagrams to the web, checking the business process models’ internal consistency and performing other modeling functions. The DSL is defined as a set of parameters stored in the internal tables of the tool’s repository. Values to the DSL defining parameters can be assigned using the separate configuration component Configurator10. Once the DSL is defined (the DSL definition is stored in the repository), the corresponding modeling platform can be created for the concrete DSL. The modeling platform DIMOD, used in this research, was derived from the graphical editor building platform GrTP11. Nevertheless both GrTP and DIMOD include a feature to call APIs in predefined points for implementation of DSL specific semantics. 5.5. Implementation of direct business process execution Business process modeling is usually carried out by a small number of users, so-called "modelers". It means the modeling tolls must not compulsory be web applications. The modeling tool DIMOD is currently implemented as a desktop-application that is available at modeler workplaces. DIMOD solves it by exporting business process diagrams to the html/SVG format (SVG - Scalable Vector Graphic). As a result, a logical copy of the model’s repository is obtained that is accessible from an internet browser, and all navigation functions in diagrams and their elements are still there. The appearance of process diagram’s elements can be easily changed in html/SVG. For instance, the colour of an element can be switched by editing element’s parameters in the html/SVG statements. It can be done by a special routine that finds an element by its SVG-identifier and updates the corresponding html/SVG statement. After refreshing of the diagram element appearance will change. There is also an external identifier necessary to maintain the connection between events of graphical element processing and the corresponding software routines that should be developed in some programming language, for instance, Java. The external identifier ensures the activation of separate business process steps, for example, by a mouse double-click. 6. Conclusion The approach of direct business process execution is analysed and the usability advantages are outlined in this research. A system consists of data objects and execution processes that are mutually connected. Data objects are represented using traditional interface means (screen forms, reports), but processes are represented as graphical diagrams in the DSL chosen by the user. The proposed approach offers an original way of business process execution and visualisation – to use business process diagrams directly for managing and visualisation of business process execution. The proposed approach provides users with means to control process execution by mouse clicks on graphical diagrams that represent executable business processes. The execution mechanism opens new ways to follow-up on the executed business processes. The new approach is particularly beneficial in terms of usability as the entire business process is visible to the users in graphical form.
Janis Bicevskis and Zane Bicevska / Procedia Computer Science 77 (2015) 72 – 79
The proposed original approach sets new challenges for the development of information systems. The functionality of an information system can be implemented by relating software routines to the corresponding elements of graphical diagrams representing business processes.
Acknowledgments The research leading to these results has received funding from the research project "IT Competence Centre" of EU Structural funds, contract nr. L-KC-11-0003 research No. 1.5 “Platform for business process description and modelling in event-oriented systems".
References 1.
Karnitis, G., Bicevska, Z., Cerina-Berzina, J., Bicevskis, J. Practitioners approach to business processes modelling. In: Selected papers from the 11th International Baltic Conference DB&IS 2014, IOS Press, 2014, pp. 343-356. 2. Workflow Management Coalition homepage, retrieved: 16.11.2015, URL: http://www.wfmc.org 3. Top Workflow Management Software Products, retrieved: 16.11.2015, URL: http://www.capterra.com/workflow-management-software/ 4. JIRA homepage, retrieved: 16.11.2015, URL: https://www.atlassian.com/software/jira 5. KiSSFLOW, retrieved: 16.11.2015, URL: https://kissflow.com/process_playbook/workflow-management-system-10-must-have-features/ 6. Cicekli, N. K., Yildirim, Y. Formalizing Workflows Using the Event Calculus. Springer, LNCS, Vol. 1873, 2001, pp. 222-231 7. Mateo, J., Srba, J., Sorensen, G. Soundness of Timed-Arc Workflow Nets Springer, LNCS, Vol. 8489, 2014, pp. 51-70. 8. Usability Metrics, retrieved: 16.11.2015, URL: http://usabilitygeek.com/usability-metrics-a-guide-to-quantify-system-usability/ 9. Cerina-Berzina, J., Bicevskis, J., Karnitis, G. Information systems development based on visual Domain Specific Language BiLingva. In: Selected Papers from the 4th Conference CEE-SET 2009, Krakow, Poland, Springer, LNCS 7054, 2011, pp. 124-135. 10. Sprogis, A., Barzdins, J. Specification, Configuration and Implementation of DSL Tool, Frontiers in Artificial Intelligence and Applications, vol. 249, IOS Press, p. 330-343, 2013 11. A.Sproģis, R.Liepiņš, J. Bārzdiņš, K. Čerāns, S. Kozlovičs, L. Lāce, E. Rencis, A. Zariņš, GRAF: a Graphical Tool Building Framework, Proc. of ECMFA 2010, Paris, France
Janis Bicevskis, born in 1944, Doctor of Computer Science since 1992, Professor since 2002, has published more than 100 scientific papers and has participated in many software development projects (design, implementation, programming, testing, management) since 1968. He led the Department of Computer Science at University of Latvia, he was co-author of national program “Informatics”, a project manager of Latvia Education Information system in 1999 and he was manager of “Integration of National information systems (Megasystem)” project in 1998. His main current scientific interests are software engineering and software testing. Zane Bicevska, born in 1971, earned her Master’s degree in Computer Science from the University of Latvia in 1995 and in Economics from the Johann Wolfgang GoetheUniversität Frankfurt am Main in 2001. In 2006 she earned Doctorate degree in Computer Science. She has published more than 10 scientific papers and managed many software development projects. Since 2006 Zane Bicevska is Assistant Professor of Project management in the Computing Faculty of the University of Latvia. Her main scientific interests include project management, business process modelling and smart technologies.
79