Prague University of Economics and Business
Faculty of Informatics and Statistics
TRANSFORMATION OF BUSINESS PROCESSES INTO EXECUTABLE PROCESSES
MASTER THESIS
Study programme: Applied Informatics Field of study: Information Technologies
Author: Bc. Milan Pavelčák Supervisor: Ing. Oleg Svatoš, Ph.D.
Prague, May 2021
Declaration
I hereby declare that I am the sole author of the thesis entitled “Transformation Of Business Processes Into Executable Processes”. I duly marked out all quotations. The used literature and sources are stated in the attached list of the references.
In Prague on May 3, 2021 ...
Bc. Milan Pavelčák
Acknowledgement
I hereby wish to express my appreciation and gratitude to the supervisor of my thesis, Ing. Oleg Svatoš, Ph.D. for his effort, guidance, and recommendations. I also wish to thank
Abstract
The master thesis describes the transformation of the business process from the business system model, which represents the business description of the process, to the implementation of the process into the selected workflow system. The main goal of the master thesis is to analyze and define steps needed to transform the business process described by the business system model into the executable process. The thesis consists of two parts, theoretical and practical. In the first part, theoretical background for business processes, business process modeling, workflow systems, MMABP methodology, and software development life cycle is provided. The second, practical part of the thesis describes the proposed procedure for the transformation of the business process from a business system model to a technological process model and how to proceed in the implementation of the business process in TeamAssistant. This guide is verified in the practical part using the example of the business process of creating a bank account remotely.
The sections of the practical part represent the objectives defined to fulfill the main goal.
Keywords
Business process, BPM, MMABP, process automation, workflow, workflow systems.
Content
Introduction ... 13
Goals ... 13
Expected Benefits ... 13
Thesis Structure ... 13
1 Methodology of Work and Research ...14
1.1 Design Science Research Methodology ...14
1.2 Literature Review ...14
2 Business Processes ...16
2.1 Definitions of a Business Process ...16
2.2 Classification of Business Processes ... 17
2.2.1 Organizational vs. Operational ... 17
2.2.2 Intraorganizational Processes vs. Process Choreographies ... 18
2.2.3 Degree of Automation, Repetition, and Structuring ... 18
3 Modeling ...19
3.1 Principle of Modeling ...19
3.2 Principle of Different Process Architectures ...19
3.2.1 Conceptual Architecture ...19
3.2.2 Technological Architecture ... 20
3.2.3 Implementation Architecture ... 20
3.3 Principle of Abstraction ...21
3.3.1 Hierarchical Abstraction ...21
3.4 BPM ...21
3.5 Workflow ... 23
3.5.1 Workflow Models ... 23
3.5.2 Workflow Systems ... 24
4 MMABP ... 26
4.1 Goal of the Methodology ... 26
4.2 Basis of Process Formulation ... 26
4.3 Two Parts of the Real World Business Model ... 27
4.4 Three Principles of MMABP ... 28
4.5 Three Phases of Process Analysis ... 29
4.5.1 Analysis of Business Processes ... 29
4.5.3 Specification of Support Processes ... 29
5 Methods for BPM ... 31
5.1 TOGAF ... 31
5.1.1 TOGAF - Event Diagram ... 31
5.2 UML ... 33
5.2.1 Class Diagram ... 34
5.2.2 Lifecycle Diagram ... 35
5.3 BPMN ... 35
5.3.1 Elements of the BPMN ... 36
5.3.2 Detailed Process Diagram ... 39
5.4 Data Flow Diagram ... 40
6 Software Development Life Cycle Models ...41
6.1 Categorization of Software Development Life Cycle Models ...41
6.2 Waterfall Model ... 42
6.2.1 Stages of the Waterfall Model ... 42
6.2.2 Advantages and Disadvantages of the Model ... 43
7 Transformation of the Business Process from Business System Model to the Model of Implementation Using Technological Process Model ... 44
7.1 Business System Model ... 44
7.1.1 Global Process Map (Event Diagram) ... 45
7.1.2 Class Diagram ... 46
7.1.3 Detailed Process Diagrams ... 47
7.1.4 Object Life Cycle Diagrams ... 58
7.2 Technological Process Model ... 62
7.2.1 General Methodical Procedure for Transformation from Business System to Technological Process Model ... 62
7.2.2 Application of Methodical Procedure for the Process of Processing a Request to Create an Account Remotely ... 73
7.2.3 Class Diagram ... 90
7.2.4 Process Diagrams ...91
7.3 Implementation Model ... 97
7.3.1 TeamAssistant ... 97
7.3.2 General Methodical Procedure for Transformation from Technological Process Model to the Implementation in TeamAssistant ... 97
7.3.3 Application of Methodical Procedure for the Process of Processing a Request to Create an Account Remotely ...132
Conclusions ... 157
Goal and Objectives ... 157
Benefits ... 158
Possible Future Extension ... 158
List of references ... 159 Annexes ... I Annex A: Templates created for the process of Processing a request to create an account remotely ... I
List of Figures
Figure 1 - Three architectures principle (Řepa, 1995) ... 20
Figure 2 - Ingredients of the business process (Dumas, 2013) ... 23
Figure 3 - Build time versus run time of a workflow model (Weske, 2013, p. 306) ... 23
Figure 4 - Architecture of workflow management system (Weske, 2015, p. 308) ... 24
Figure 5 - Two parts of the Real World Business Model (Řepa, 2014, p. 18) ... 27
Figure 6 - Two views on two dimensions of a Business system (Řepa, 2014, p. 20) ... 28
Figure 7 - TOGAF Event diagram - UML/BPMN Extension (Togaf Modelling, 2021) ... 32
Figure 8 - Example of Process map – MMABP (Řepa, Svatoš, 2021, p. 205) ... 33
Figure 9 - Example of Class diagram - MMABP (Řepa, Svatoš, 2021, p. 207) ... 34
Figure 10 - Example of Object life cycle – MMABP (Řepa, Svatoš., 2021, p. 211) ... 35
Figure 11 - BPMN Flow objects (White, 2004) ... 37
Figure 12 – BPMN Connecting objects (White, 2004) ... 38
Figure 13 - BPMN Swimlanes (White, 2004) ... 38
Figure 14 - BPMN Artifacts (White, 2004) ... 39
Figure 15 - Data flow diagram (DFD) - Example (Řepa, Svatoš, 2021, p. 215) ... 40
Figure 16 - Phases of the Waterfall model (SDLC - Waterfall Model - Tutorialspoint, n.d.) ... 43
Figure 17 - Event diagram – Business system model (Author) ... 45
Figure 18 - Class diagram – Business system model (Author) ... 46
Figure 19 - Key process - Processing a request to create an account remotely - Process step level (Author) ... 48
Figure 20 - Key process – Input control of applicant’s data – Task level (Author) ... 49
Figure 21 - Key process – Forwarding the request to the support team – Task level (Author) ... 49
Figure 22 - Key process – Request cancellation – Task level (Author) ... 50
Figure 23 - Key process – Failure record analysis – Task level (Author) ... 51
Figure 24 Key process – Sending the necessary documentation to the applicant – Task level (Author) ... 52
Figure 25 - Key process – Account cancellation – Task level (Author) ... 53
Figure 26 - Key process – Mark request as fulfilled – Task level (Author) ... 54
Figure 27 - Support process - Account creation - Process step level (Author) ... 55
Figure 28 - Support process – Creating an account – Task level (Author) ... 56
Figure 29 - Support process – Failure report creation – Task level (Author) ... 56
Figure 30 - Support process – Marking account as not activated – Task level (Author) ... 57
Figure 31 - Support process – Closing account creation – Task level (Author) ... 57
Figure 32 - Lifecycle - Account - Business system model (Author) ... 58
Figure 33 - Lifecycle - Account documentation- Business system model (Author) ... 59
Figure 34 - Lifecycle - Failure - Business system model (Author) ... 60
Figure 35 - Lifecycle - Notification - Business system model (Author) ...61
Figure 36 - Lifecycle - Request - Business system model (Author) ...61
Figure 37 - Class diagram - Technological process model (Author) ... 90
Figure 38 - Processing a request to create an account remotely - E-mail - Technological process model - part 1 (Author) ... 92
Figure 39 - Processing a request to create an account remotely - E-mail - Technological process model - part 2 (Author) ... 93
Figure 40 - Processing a request to create an account remotely - Web form - Technological process model - part 1 (Author) ... 94
Figure 41 - Processing a request to create an account remotely - Web form - Technological process model - part 2 (Author) ... 95
Figure 42 - Account creation - Technological process model (Author) ... 96
Figure 43 - Adding a template in TeamAssistant - Implementation model (TeamAssistant) ... 99
Figure 44 - Adding a task in TeamAssistant - Implementation model (TeamAssistant) . 100 Figure 45 - Editing a task in TeamAssistant - Implementation model (TeamAssistant) . 100 Figure 46 - Editing a task in TeamAssistant - Required fields- Implementation model (TeamAssistant) ... 101
Figure 47 - Selecting a task type in TeamAssistant - Implementation model (TeamAssistant) ... 101
Figure 48 - To be assigned to solver task in TeamAssistant - Implementation model (TeamAssistant) ... 102
Figure 49 - Implemented by a support process task in TeamAssistant - Activity - Implementation model (TeamAssistant) ... 103
Figure 50 - Implemented by a support process task in TeamAssistant - Solver/Variable - Implementation model (TeamAssistant) ... 104
Figure 51 - E-mail notification task in TeamAssistant - Implementation model (TeamAssistant) ... 105
Figure 52 - Triggers an event task in TeamAssistant – Activity - Implementation model (TeamAssistant) ... 106
Figure 53 - Triggers an event task in TeamAssistant – Solver/Variables - Implementation model (TeamAssistant) ... 107
Figure 54 - Waits for an event task in TeamAssistant – Activity - Implementation model (TeamAssistant) ... 108
Figure 55 - Waits for an event task in TeamAssistant – Solver/Variable/Completion -
Implementation model (TeamAssistant) ... 108
Figure 56 - Invitation task in TeamAssistant – Implementation model (TeamAssistant) 109 Figure 57 - Starting and ending events - Implementation model (TeamAssistant) ... 110
Figure 58 - Add variables to the template 1 - Implementation model (TeamAssistant) ... 111
Figure 59 - Add variables to the template 2 - Implementation model (TeamAssistant) ... 112
Figure 60 - Variable type - Text - Implementation model (TeamAssistant) ... 113
Figure 61 - Variable type - Multiline text - Implementation model (TeamAssistant) ... 114
Figure 62 - Variable type - Date - Implementation model (TeamAssistant) ... 115
Figure 63 - Variable type - Number - Implementation model (TeamAssistant) ... 116
Figure 64 - Variable type - Code list of texts - Implementation model (TeamAssistant) .. 117
Figure 65 - Variable type - Code list of dates - Implementation model (TeamAssistant) . 118 Figure 66 - Variable type - Code list of numbers - Implementation model (TeamAssistant) ... 119
Figure 67 - Variable type - Sequence - Implementation model (TeamAssistant) ... 120
Figure 68 - Adding created variable to the tasks 1 - Implementation model (TeamAssistant) ... 121
Figure 69 - Adding created variables to the tasks 2 - Implementation model (TeamAssistant) ... 122
Figure 70 - Add events 1 - Implementation model (TeamAssistant) ...123
Figure 71 - Add events 2 - Implementation model ...123
Figure 72 - Add a connection between the tasks - Implementation model (TeamAssistant) ... 124
Figure 73 - Edit task or connection - Implementation model (TeamAssistant) ... 124
Figure 74 - Set the condition - Implementation model (TeamAssistant) ... 125
Figure 75 - Add roles 1 - Implementation model (TeamAssistant) ... 126
Figure 76 - Add roles 2 - Implementation model (TeamAssistant) ... 127
Figure 77 - Assign the task - A solver that is automatically selected by the computer - Implementation model (TeamAssistant) ... 128
Figure 78 - Assign the task - No one will be assigned, task will be offered to a defined group of users - Implementation model (TeamAssistant) ... 128
Figure 79 - Assign the task - The last solver of the task - Implementation model (TeamAssistant) ... 129
Figure 80 - Assign the roles to the events 1 - Implementation model (TeamAssistant) ... 130
Figure 81 - Assign the roles to the events 2 - Implementation model (TeamAssistant) .... 131
Figure 82 - Deploy the template to the production 1 - Implementation model (TeamAssistant) ...132
Figure 83 - Deploy the template to the production 2 - Implementation model
(TeamAssistant) ...132
Figure 84 - Added templates - Implementation model (Author) ...133
Figure 85 - Additionally created tasks 1 - Implementation model (Author)... 134
Figure 86 - Additionally created tasks 2 - Implementation model (Author) ... 134
Figure 87 - Additionally created tasks 3 - Implementation model (Author) ... 135
Figure 88 - Merged tasks 1 - Implementation model (Author) ... 135
Figure 89 - Merged tasks 2 - Implementation model (Author) ... 136
Figure 90 - Key process events and tasks implementation - Implementation model (Author) ... 137
Figure 91 - Key process -Task Cancellation – info from key process to the support process settings - Implementation model (Author) ... 137
Figure 92 - Support process events and tasks implementation - Implementation model (Author) ... 137
Figure 93 - Support process – Task Cancellation - information from KP to the SP settings - Implementation model (Author) ... 138
Figure 94 - Representation of implementation for the event, that can be triggered only once - Implementation model (Author) ... 138
Figure 95 - Representation of implementation for the event, that can be triggered more than once - Implementation model (Author) ... 139
Figure 96 - Merged tasks used for ending the template - Implementation model (Author) ... 139
Figure 97 - Text variable First name (Author) ... 141
Figure 98 - Multiline text variable Failure description (Author) ... 142
Figure 99 - Date variable Date (Author) ... 143
Figure 100 - Number variable Age (Author) ... 144
Figure 101 - Checkbox (Number) variable Payment confirmation (Author) ... 145
Figure 102 - Code list of texts variable Account activation (Author) ... 146
Figure 103 - Sequence type variable ID (Author) ... 147
Figure 104 - Variables added to the task Failure analysis ... 148
Figure 105 - Added events - Implementation model (Author) ... 148
Figure 106 - Condition for the connection from Create account based on received data task to Create RPN task ... 149
Figure 107 - Processing a request to create an account remotely - E-mail - Implementation model (Author) ... 151
Figure 108 - Processing a request to create an account remotely - Web form - Implementation model (Author) ... 152
Figure 109 - Account creation - Implementation model (Author) ... 153
Figure 110 - Added roles - Implementation model (Author) ... 153 Figure 111 - Example of setting a A solver that is automatically selected by the computer to Create IFAN task - Implementation model (Author) ... 154 Figure 112 - Setting a No one will be assigned, task will be offered to a defined group of users for Create account based on received data task - Implementation model (Author) 154 Figure 113 - Example of setting a The last solver of the task to Create RP task -
Implementation model (Author) ... 155 Figure 114 - Users added - Implementation model (Author) ... 155
Introduction
Goals
The main goal of the master thesis is to analyze and define steps needed to transform the business process from the business system model into the executable process. To fulfill the main goal of the thesis four objectives are set:
• According to the MMABP methodology create business system model which will describe the process of remote account creation in a bank from business perspective.
• From the business system model create a technological process model based on which implementation will be performed.
• Implement the process of remote account creation in the TeamAssistant environment, test the implementation and deploy the created implementation.
• Create a guide describing recommended steps needed to transform the process from the business process model into the executable process in TeamAssistant.
Expected Benefits
The main goal of the diploma thesis is to analyze and define steps needed to transform the business process from the business system model into the implementation using the technological model to link between the two aforementioned models. These steps will form a guide that can be used in the future for those who find themselves struggling to execute the transformation. By following the steps from the guide one can transform business processes from the business system model, created according to MMABP methodology, into executable processes. Another partial benefit is the verification of the guide and the creation of an example that can be used as a reference example for problems with business process transformation. A created guide will be also beneficial for the students in the future.
Thesis Structure
The master thesis is divided into two main parts. The first one presents the theoretical part of the thesis. In these chapters business processes, modeling, MMABP methodology, and workflow systems are described. Methodologies and notations described in the theoretical part are used when fulfilling the main goal and objectives of the thesis set in the introduction chapter.
The second part is devoted to the creation of three models, business system model, technological process model, and implementation model. For the transformation between individual models recommended steps forming the guide are presented. The transformation from technological process model to implementation is supplemented by a detailed
1 Methodology of Work and Research
In this chapter description of the Design Science Research methodology is provided along with an outline of how the mentioned methodology was used for the master thesis. The second part aims to present the literature review of the various publications used in the master thesis to describe the theoretical background.
1.1 Design Science Research Methodology
The main goal of Design Science Research is to create knowledge that can be later used by the specialists of the discipline to design their solutions for the problems within the field of discipline. (Van Aken, 2005)
According to Peffers et. al. (2008) Design Science Research methodology consists of 6 following activities:
• Problem identification and motivation – specific research problem with justification for the value of the solution is outlined in the first activity.
• Define the objectives for a solution – qualitative or quantitative objectives are deduced from the already identified problem.
• Design and development – artifacts are created in this activity. An artifact can be any object that is designed during the research. Models or methods are perfect examples of such artifacts.
• Demonstration – in this activity, created artifacts are used to solve the problem for demonstration purposes.
• Evaluation – after the demonstration activity is performed, a solution to the problem provided by the artifact is evaluated.
• Communication – last activity aims to present the outcomes of the research to the relevant audience.
All aforementioned activities were followed to organize the procedure needed to achieve the goal and objectives of the thesis. Outcomes of the thesis are described in the Conclusion.
1.2 Literature Review
For the literature review of the master thesis, numerous resources were selected. A complete list of the resources used can be found at the end of this thesis. The main resources on which the theoretical part of the thesis is based are:
Řepa. Podnikové procesy: procesní řízení a modelování. Praha. 2007. This publication by professor Řepa from the Prague University of Economics and Business describes business processes and their management in the company. The chapters in the book are devoted to
issues such as business processes, methods of process reengineering, business process modeling, and various standards, techniques, and methodologies of process modeling, such as Methodology for Modeling and Analysis of Business Processes.
Řepa. Procesně řízená organizace. Praha. 2012. Another book by professor Řepa is considered a follow-up publication of the previous title. However, this book focuses on the description of the process management of the organization and contains chapters describing various concepts of process management of the organization, information modeling of the organization, ways to introduce process management into the organization, description of the information system of process-managed organization and others.
Dumas et. al. Fundamentals of business process management. Berlin. 2013. This publication describes the entire Business Process Management Lifecycle and besides parts of the book explaining the relevant conceptual background examples and exercises are provides as well. Chapters from the book address issues such as process identification, essential and advanced process modeling, process discovery, qualitative and quantitative process analysis, process redesign, process automation, and process intelligence.
Weske. Business process management. Berlin. 2015. This book offers an understanding of the different aspects of business process management for everyone being involved in the field. The publication consists of three parts, foundation, business process modeling, and architectures and methodologies. In the first part, the introduction and evolution of enterprise systems architectures are outlined. This is followed by business process modeling foundation, process orchestrations, process choreographies, and properties of business processes described in the second part. The last part of the publication illustrates business process management architectures and business process methodology.
2 Business Processes
In the first part of this chapter, the term business process is defined according to multiple definitions. The second part is devoted to the classification of business processes from two perspectives and a division of support processes is provided in this chapter as well.
2.1 Definitions of a Business Process
In this section, the terms process and business process are defined in order to make it clear for a reader what exactly those terms stand for. Before presenting the definitions of the business process it makes sense to outline the definition of the process generally. Simply said process can be defined as any kind of activity or group of activities. At the beginning of these activities, there are some inputs that are gradually transformed into outputs.
Mathias Weske (2015, p. 5) in his book called Business Process Modelling defines that “the business process consists of a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal.
Each business process is enacted by a single organization, but it may interact with business processes performed by other organizations. “
Another business process definition from Cumberlidge (2007, p. 10) defines the term as “a collection of business activities that takes one or more kinds of input and creates an output that is of value to the business. “
Professor Řepa (2017, p. 15) from Prague University of Economics and Business specifies the process as a set of activities that transforms a set of inputs into a set of outputs (either goods or services) for other people or other processes that use people and tools to do so.
Interpretation of the process from Davenport (1993, p. 5) is that the process is a specific ordering of work activities across time and place, with a beginning, and end, and identified inputs and outputs.
To sum it all up, from the aforementioned definitions, the following points about business processes can be concluded:
• Business process is a set or collection of activities.
• Business process transforms inputs into outputs with some additional value.
• Business process uses or consumes different resources when transforming inputs to outputs.
2.2 Classification of Business Processes
Gála et. al. (2009, p. 25) divides the business processes in terms of the importance of the process for meeting the goals of organizations as follows:
• Operational processes – these business processes are crucial for the organization as they create and deliver value for the customer.
• Management processes – are often used for managing both operational and support processes in organizations.
• Support processes – have a supportive purpose for the operational processes in organizations.
Řepa (2007, p. 207) in his book Podnikové procesy categorizes support processes in general into two subcategories:
• Based on the method of support:
o Disposable – process provides a service to another process on demand.
o Parallel – process is executed repeatedly and independently opposing to other processes and generates outputs consumed by other processes in an independent way.
• Based on the specificity of the service:
o Universal – a type of support process that is relatively general in nature, as it generates outputs for a wide range of other processes through parameterization.
o Local - the type of support process whose generated output is consumed by one specific process.
Weske (2015, p. 17) classifies business processes into five following subcategories:
• organizational vs. operational,
• intraorganizational processes vs. process choreographies,
• degree of automation,
• degree of repetition,
• degree of structuring.
2.2.1 Organizational vs. Operational
Organizational business processes are generally described by their inputs, outputs, expected results, and dependencies on other organizational business processes in textual form on high-level. Such processes in the company act as consumer or supplier processes.
On the other hand, operational business processes form the very basis for developing implemented business processes and are being specified by business process models. The relationship between above-mentioned business processes can be described by the fact that mostly more than one operational business process is needed to contribute to the one organizational business process. (Weske, 2015, p. 17)
2.2.2 Intraorganizational Processes vs. Process Choreographies
By the definition from Weske (2015, p. 18-19) intraorganizational business processes are found in the company if the business processes are implemented and executed by one company and there is no cooperation with business processes from other companies.
However, such processes exist basically in every company, there are process choreographies that represent the business processes that cooperate and communicate with business processes from other companies.
2.2.3 Degree of Automation, Repetition, and Structuring
The business process can be classified based on other aspects such as the degree of automation. In this group of business processes, there are fully automated processes, a combination of automated tasks and manual ones, or business processes executed manually.
The degree of repetition is closely linked to the degree of automation as it is one of the criteria on which company decides whether to automate task (even the whole business process) or not.
Degree of structuring defines the business process from the structural aspect. Highly structured business processes which prescribe the activities and their execution constraints in a complete fashion can exist in the company. On the other hand, there are less structured business processes. Compared to highly structured processes these business processes rely on the knowledge of experienced workers and incorporate ad hoc activities and case handling. (Weske, 2015, p. 19-21)
3 Modeling
The third chapter of the thesis outlines Three principles of modeling, including detailed description of the principle of different process architectures. First part is then followed by general introduction to the BPM – Business Process Modeling.
3.1 Principle of Modeling
Professor Řepa (2012, p. 70) in his book called Procesně řízená organizace defines the model as:
• A formal expression of the studied phenomenon (system), the purpose of which is to describe and express reality.
• Simplified representation of a specific phenomenon (system) using appropriate displaying instruments, focusing only on those features that are considered essential to meet the goal that is pursued in the construction of the model.
• Recreation of the characteristics of one object on another object, which is specially constructed with the study purposes.
The principle of modeling is the fundamental principle of system design methods. The basic principle of the system design methods and their methodological procedures and the properties of the tools and techniques associated with it have their origin in the idea that the information system is a model of the real world.
3.2 Principle of Different Process Architectures
The principle of three architectures describes and defines how to develop an information system gradually, layer by layer. Each of the three layers addresses different aspects of the developed system such as the content of the system, technology and implementation or implementation specifics. (Řepa, 2012, p. 76)
3.2.1 Conceptual Architecture
The output of the conceptual architecture is a conceptual model that describes only the content of the system and answers the question of WHAT is the content of the studied system. The created conceptual model is not created concerning technological nor implementation specifications. (Řepa, 2012, p. 76)
3.2.2 Technological Architecture
This architecture creates a model describing the system concerning the technical concept of the solution. The created technological model should not contain implementation specifications, from which it should be abstracted at this level. The same applies to the content of the system that should be addressed in the previous model. The technological model provides an answer to the question HOW. (Řepa, 2012, p. 76)
3.2.3 Implementation Architecture
The output of the implementation architecture is an implementation model describing a specific development environment. In this final layer, all possible implementation requirements are taken into account and no specifics of the solution are abstracted. (Řepa, 2012, p. 76)
All three described models of tripartite architecture use the principle of abstraction, which is used to eliminate inappropriate aspects in the creation of the system. (Řepa, 2012, p. 76) Since each of the described layers is focused on a different specific subject of interest and has a specific logic, it is necessary to:
• Have a specific language and different design techniques for each design level defined.
• Have techniques describing the transitions between the individual layers defined.
Figure 1 - Three architectures principle (Řepa, 1995)
Figure 1 displays a whole system formed by all three mentioned architectures. In addition, from Figure 1 it can be seen that abstraction is inevitable for the layer-by-layer creation of the individual models.
3.3 Principle of Abstraction
Abstraction can be seen as:
• Process of separating differences and peculiarities and identifying the general and crucial properties of objects and phenomena of reality and the relationships between them.
• Intentional conscious discretion meaning not being specific and omitting some characteristics on purpose.
The main reason why the principle of abstraction is used in various modeling methods is the effort to break down the studied problem into smaller, easier-to-process pieces. (Řepa, 2012, p. 73)
3.3.1 Hierarchical Abstraction
Hierarchical abstraction represents the breakdown of the studied system into smaller elements (parts), which form the whole studied system. Such disintegration creates levels of the system at which the individual elements and their connections are described. A relatively significant advantage of hierarchical abstraction is the ability to examine the most elementary elements of the system in much greater detail. On the other hand, the hierarchy comes with a disadvantage, namely that by disintegration the context of other parts of the system, as well as the superior entity is missing. (Řepa, 2012, p. 74)
Řepa (2012, p. 74-75) defines two general types of hierarchical abstraction:
• Aggregation - hierarchical division of elements, when, for example, in process modeling, activities are grouped into processes, which then makes smaller units more complex entities. The superior concept is only formed by the subordinated entities or smaller units and has no other significance.
• Generalization – subordinated entity in this type of abstraction can be described as a special type of the superior concept. The main difference opposing the Aggregation type of abstraction is that superior entity in Generalization abstraction is described by common characteristics from subordinated entities.
3.4 BPM
The business process model defines what specifically happens in a business system that describes the real world. The process model aims to describe the intentions and their subsequent implementation in business processes. Also, all actions that are performed within the business system environment represent the implementation of certain of its intentions. The description of business processes serves precisely to document the mentioned intentions and the corresponding solutions. (Řepa, 2012, p. 104-105)
Elements of the business process:
• process,
• activity,
• stimulus, and
• link – continuity.
The model of the process is created as a structure of interconnected activities. For such process, the principle of semantic relativity is applied. Meaning that each activity of the process must be described as a separate process. Processes are not initiated chaotically or randomly but there is always either an external or internal stimulus leading to the start of the process. In general, external stimuli can be named as events and internal as a process state. Process activities, through links, form a process structure that represents a managed chain of activities. (Řepa, 2007, p. 71)
Marlon Dumas (2013, p. 3-5) in the book called Fundamentals of Business Process Management describes elements of the business process as ingredients formed by:
• Events – happen automatically and can trigger the execution of the set of activities.
• Activities – in most cases activity is a simple and single unit of work mostly performed by humans it can be called a task.
• Decision points – point in the process in which, based on various conditions and decisions process, execution of the process is affected.
• Outcome - at the end of the process, when all activities (tasks) are finished a result is generated. This result called outcome can be either positive, meaning that the value is delivered to the customer, or negative. A negative outcome is created when no or only partial value is created and delivered to the customer.
• Actors and objects – business processes interact with a wide range of actors from the internal or external environment of the process. A special type of actor is a consumer.
Figure 2 describes essential elements of the business process. From the graphic description of the business process, it is clear that the business process involves zero or many objects and actors, for example, a customer who is delivered positive outcome from the process. On the other hand, if the business process delivers a negative outcome, in such case customer does not receive any value. Other elements that form business processes are zero or many events and decision points and at least one activity.
Figure 2 - Ingredients of the business process (Dumas, 2013)
3.5 Workflow
In this section workflow models and workflow systems are described. For both workflow models and workflow systems, individual parts which form them are outlined using figures.
3.5.1 Workflow Models
Weske (2015, p. 306) defines the workflow model as “the blueprint for implemented business processes in workflow management system.”
Dumas et. al. (2013, p. 298) characterizes workflow also referred to as automated business process as “a process that is automated in whole or in part by a software system, which passes information from one participant to another for action, according to the temporal and logical dependencies set in the underlying process model.”
Figure 3 - Build time versus run time of a workflow model (Weske, 2013, p. 306)
Figure 3 illustrates the separation of build and run time in the workflow model. During the build time, the workflow model is specified and created which means that the requirements set by a business process are met. Workflow models are created using graphical workflow modeling tools and most of the time stored in the workflow model repository. After the build time is finished, a new instance of the workflow model is initiated and that is represented by run time. All instances created during the run time are stored in the workflow engine which is in charge of controlling the execution of mentioned instances. The workflow engine is also responsible for deciding which task of the instance can be started and controls the communication with the applicants of the workflow. (Weske, 2015, p. 306)
3.5.2 Workflow Systems
The purpose of business process management systems, which according to Dumas et. al.
(2013, p. 298) is a synonymous term for workflow systems, is to coordinate an automated business process so that all the necessary resources are used at the right time to fulfill the defined work.
Figure 4 - Architecture of workflow management system (Weske, 2015, p. 308)
Figure 4 illustrates detailed subsystems and roles of workflow management systems and to explain how these systems work, these individual subsystems with roles are described.
Weske (2015, p. 307) defines the following subsystems for workflow management systems:
• Workflow Modelling – this subsystem provides the means and ways to implement business processes with respect to technical requirements.
• Workflow Model Repository – stores all workflow models of a specific company.
• Workflow Engine – launches and manages instances for company workflow processes. An example is creating a new instance of a process when an event occurs that acts as a trigger.
• Graphical User Interface – in case a human action is required to perform and complete the activity, then this requirement is solved through the graphical user interface, through which the user performs the required action.
• Invoked applications – if the running instance of the business process communicates with another system, then this system is integrated into the overall architecture.
In Figure 4, two roles participating in workflow management system are described by Weske (2015, p. 309):
• Process designer – role, which is responsible for creating a workflow model in the workflow management system.
• Process participant – knowledge workers of the process are essential for the execution of the business process in the workflow management system, especially because they are often responsible for performing activities that cannot be done by automation of an activity.
4 MMABP
“MMABP (Methodology for Modeling and Analysis of Business Processes) is a ‘language independent’ methodology based on the set of meta-models which define the basic concepts and express the basic principles of the methodology, and completed with the set of techniques, consistency rules, and patterns.” (Řepa, 2017)
Methodology for Modeling and Analysis of Business processes was created at the Department of Information Technology at Prague University of Economics and Business under the leadership of professor Řepa.
4.1 Goal of the Methodology
The main goal of the methodology is to identify key processes within the organization using the analysis of events which then helps with the analysis of activities. (Řepa, 2007, p. 198) MMABP methodology is designed to form a model of system processes which (Řepa, 2007, p. 198):
• Respects the goals, status, and characteristics of the organization.
• Respects objective needs that may have a significant impact on the company's operations (these needs originate from the external environment of the company).
• Is optimal in terms of economic (efficient) and factual (striving for the maximum possible simplicity while maintaining full functionality).
• Enables the optimization, implementation of a system of processes that are presumed to respect the previously mentioned characteristics.
4.2 Basis of Process Formulation
Aspects that need to be available to formulate the processes of the company (Řepa, 2007, p. 199):
• Basic activities are identified.
• A concept of the basic events of interests and expected reactions once they are triggered.
• A concept of the basic objects of interest and life cycles describing them.
4.3 Two Parts of the Real World Business Model
Two basic dimensions describing the real world business model from the perspective of Methodology for Modeling and Analysis of Business Processes. The first dimension or view is the Business substance model which “represents objects and their mutual relationships consisting of attributes and methods.” (Řepa, 2014, p. 18)
This view is also called a static view of real world business model because the element it describes, such as objects and relationships between them, are constant elements of the real world. (Řepa, 2007, p. 195)
The second dimension, the business processes model represents business processes consisting of events and actions. (Řepa, 2014, p. 18)
This model is also called a dynamic model. That is mainly because the business processes model assumes that there has to be a superior reason for the real world behavior that is not dependent on the object life rules. Practically it means that for each business process there should be a goal representing the mentioned reason, external input event, and objective describing the dynamics of the business activities. Compared to the static model, a dynamic model is a collection of the actions that influence the objects and are ordered by time rather than just an unstructured collection of actions. (Řepa, 2014, p. 19)
Figure 5 - Two parts of the Real World Business Model (Řepa, 2014, p. 18)
Figure 5 illustrates what both Business Substance Model and Business Processes Model have in common. The intersection between the two models describes the Events/Methods, States/Attributes, Data Dictionary, and most importantly State Transition Diagram which is created using information from both models.
Using abstraction, a two-dimensional model can be complemented by additional two basic views:
• Global view – focusing on the whole system and is created using abstraction from the details.
• Detailed view – focusing only on the part of the system and abstraction for this view is used to separate from the whole.
Figure 6 - Two views on two dimensions of a Business system (Řepa, 2014, p. 20)
Figure 6 indicates that by a combination of two dimensions and two views using abstraction four basic kinds of system model according to Řepa (2014, p. 21) can be retrieved:
• Global model of objects – a conceptual model.
• Detailed model of one object – object life cycle.
• Global model of processes – a model of the system of processes.
• Detailed model of one process – model of the process run.
All four diagrams described in Figure 6 (Eriksson-Penker Notation or Process map, Class Diagram, BPMN and State Chart) are described in Chapter 5 – Methods for BPM in detail.
4.4 Three Principles of MMABP
MMABP is defined by three principles that are interconnected between each other:
• The Principle of Modelling.
• The Principle of Abstraction.
• The Principle of Three Architectures.
4.5 Three Phases of Process Analysis
Analysis of the business processes according to the MMABP is divided into three following phases:
1. Analysis of business processes 2. Specification of key processes 3. Specification of support processes
4.5.1 Analysis of Business Processes
The goal of this phase is to identify all basic processes within the organization. Such identification can be achieved through the analysis of events. (Řepa, 2007, p. 201)
The outcome of the analysis of business processes is a system of the elementary processes used in the following phase of the methodology.
Steps needed to achieve the output (Řepa, 2007, p. 201-204):
1. Identification of basic elementary processes
2. Analysis and design of links or connections of elementary processes 3. Detailed analysis of elementary processes
4. Analysis and adjustment of consistency of elementary processes
4.5.2 Specification of Key Processes
The goal of the second phase of the MMABP methodology is to identify key processes in the organization. The outcome of the previous chapter, the system of the elementary processes, is used to identify key processes by the object analysis of the organization’s products. (Řepa, 2007, p. 204)
The outcome of the Specification of business processes is a system of the conceptual key processes, which is then used to form the process model of the organization.
Steps needed to achieve the output (Řepa, 2007, p. 204-206):
1. Object analysis of the products
2. Identification, analysis, and creation of key processes 3. Analysis and adjustment of key processes
4.5.3 Specification of Support Processes
The goal of the third and last phase of the MMABP methodology is to identify support processes in the organization. The outcome of the previous chapter, the system of conceptual key processes, is used to identify support processes within the organization.
(Řepa, 2007, p. 206)
The outcome of the Specification of business processes is a system of the conceptual key processes, which is then used to form the process model of the organization.
Steps needed to achieve the output (Řepa, 2007, p. 206-208):
1. Object analysis of the organization
2. Identification, analysis, and design of support processes
3. Consistency analysis and adjustment of the system of processes
5 Methods for BPM
This chapter describes the methodologies, notations, or modeling languages that are used to create individual models and diagrams describing the overall model of an organization's processes according to the MMABP methodology and the procedure described in the phases in the previous chapter. A detailed description of diagrams and models is provided in this chapter. The last part of this chapter is dedicated to the Data flow diagram (DFD).
5.1 TOGAF
The Open Group Architecture Framework (TOGAF) is an architecture framework used for assisting in the acceptance, production, use and maintenance of enterprise architectures. It is supported by a re-usable set of assets that already exist and that have proven to be well working best practices. The Open Group Architecture Forum is responsible for improving, developing, and maintaining TOGAF. The most recent version is TOGAF 9.2. (Harrison, 2010, p. 11)
5.1.1 TOGAF - Event Diagram
An Event diagram, also called a Process diagram describes the relationships between processes and events. Business events are considered to be triggers in the Event diagram and are responsible for initiating a process in which certain actions need to be taken within the organization. Such events might come from outside of the organization, for example, information from customer arrives or can happen at a certain point in time. (Togaf Modelling, 2021)
The purpose of the Event diagram is to provide an overview of business processes, which might be useful during the mapping of processes. (Togaf Modelling, 2021)
This overview, however, is object-oriented meaning that the processes are seen as objects rather than some dynamic parts of the system. (Řepa. 2014, p. 31)
Figure 7 illustrates elements of the Event diagram, which are following (Togaf Modelling, 2021):
• processes,
• trigger events
• sent events,
• participating roles, and
• organization units.
Figure 7 - TOGAF Event diagram - UML/BPMN Extension (Togaf Modelling, 2021)
Řepa and Svatoš (2021) describe an example of Process map illustrated by Figure 8 and opposing to the Event diagram illustrated in Figure 7 they separate business processes into two categories:
• Key processes – process that is directly linked to the customer and describes the whole process execution, from its beginning when it is initiated until the values are delivered to the customer.
• Support processes – process that is responsible for supporting other processes with its output that is crucial for the fulfilling of customer needs by the key process.
Figure 8 - Example of Process map – MMABP (Řepa, Svatoš, 2021, p. 205)
5.2 UML
UML – Unified modeling language is a modeling language originally created to provide tools for the development of software applications, meaning to describe a standardized way how to visualize the design of a system. The unified modeling language is based on the principle of multi-layer architecture and the latest version is 2.5.1. (Object Management Group, 2015) Miles and Hamilton (2006) define six main advantages that UML offers:
• It is a formal language – each element of the language is well defined and thus a guarantee of understanding of the created model is ensured.
• It is concise – language notation is simple and straightforward.
• It is comprehensive – all crucial features of a system are described.
• It is scalable – when needed, UML can be used in a formal way, for example, massive system modeling projects, but on the other hand, UML can be scaled down and used for the needs of small projects.
• It is built on lessons learned – past 15 years of culmination of best practices in the object-oriented community ensure that only the well-working practices are implemented.
• It is the standard – open standards group is in charge of UML control and with the contribution from academics and vendors from all around the world, the vendor lock-in is eliminated.
UML 2.0 defines 13 types of diagrams divided into three following categories (OMG, 2015):
• Structure diagrams
o Class diagram, Object diagram, Component diagram, Composite structure diagram, Package diagram and Deployment diagram
• Behavior diagrams
o Use case diagram, Activity diagram and State machine diagram
• Interaction diagrams
o Sequence diagram, Communication diagram, Timing, and Interaction overview diagram.
5.2.1 Class Diagram
“The Class Diagram is a model of a structure of the business system that describes the modeled business system at the object class level, including their properties (attributes and operations) and relations between them.” (Řepa, Svatoš, 2021, p. 206-207)
The Class diagram used for the purposes of the MMABP does not focus on technological nor implementation specifications, but the subject of interest of this diagram is to capture the structure of reality with a focus on its substance. In addition, the Class diagram can be interpreted as a so-called business dictionary from a more formal perspective.
Figure 9 illustrates the example of the Class diagram from (Řepa, Svatoš, 2021) in which a generalization, an aggregation and association roles are used to model the abstraction.
Furthermore, as the Class diagram is made on a conceptual level it must be created in an object-oriented way to capture the objects of reality. Even though, the Class diagram is created in the object-oriented way it still must be created according to the UML Class diagram standard.
5.2.2 Lifecycle Diagram
“An object’s life cycle is a description of a system of business rules capturing essential states of an object for the particular business and reasons for transitions among them.”
(Řepa, Svatoš, 2021, p. 211)
Lifecycle diagrams should only be created for the important classes that are crucial for the modeled business system and are defined in the Class diagram. When creating Lifecycle diagram, consisting of starting point, states and transitions that are formed by conditions and operations, must include all states of the object life cycle, from the very beginning of the lifecycle to its very end. Regarding the states of the diagram, apart from the so-called regular states, there is another special state, the final state in which the life of the object is supposed to end. (Řepa, Svatoš, 2021, p. 211-212)
Figure 10 - Example of Object life cycle – MMABP (Řepa, Svatoš., 2021, p. 211)
5.3 BPMN
“The primary goal of the BPMN effort was to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.” (White, 2004)
Another benefit, according to White (2004), is linking business process design and process implementation using Business Process Modeling Notation and filling the gap that has long been perceived as problematic between the two areas. The BPMN defines Business Process
Diagram - BPD, which is essentially a network of graphical objects, such as activities and progress controls, that determine the progress in which activities will be performed.
The actual version of BPMN 2.0 was released in 2013. (The History of BPMN, 2018) According to (Fiorini, Gopalakrishnan, 2015) BPMN consists of elements that can be divided into five following categories:
• flow objects,
• data,
• connecting objects,
• swimlanes, and
• artifacts.
5.3.1 Elements of the BPMN
In this subsection, all five categories created to classify each group of BPMN elements are described along with the visual representation of the elements.
Flow Objects
Flow objects are essential for the BPMN, as they are used to define the expected behavior of the business process.
Flow objects are represented by 3 major types (Fiorini, Gopalakrishnan, 2015):
• Events – are used to express the moment when something happens during the execution of a process. They are usually used as triggers and typical examples of events are Start, Stop, and Error.
• Activities – used to represent the actions within the business process. Activities can be either atomic (task) or compound (sub-process). Typical examples are User tasks, Service tasks or Script tasks.
• Gateways – are critical to the execution of the process and are used as controllers for the branching, forking, joining, and merging of execution paths. Typical examples of gateways are Parallel gateways, Exclusive gateways, or Inclusive gateways.
Figure 11 - BPMN Flow objects (White, 2004)
Data
Various data are created as a result of the business process execution. Data elements in the BPMN are represented by (Fiorini, Gopalakrishnan, 2015):
• Data object – used to express that specific activity of the business process creates a data object.
• Data input – used to display that specific activity requires data input for the execution.
• Data output – used to display that there are data created because of activity which must be mapped to a subsequent activity or to a global process variable.
• Data store – used to describe the mechanism of storing and retrieving data or information.
Connecting Objects
In BPMN Connecting objects are used to connect Flow objects together and can be represented by these types (Fiorini, Gopalakrishnan, 2015):
• Sequence flows – used to specify the order in which activities of the process are executed.
• Message flows – used to interpret the message flow of information.
• Associations – used to represent the connection between flow objects and artifacts or data.
Figure 12 – BPMN Connecting objects (White, 2004)
Swimlanes
Represent the graphical way of organizing and categorizing the activities within the business process. BPMN defines two types of Swimlanes that can be used (Fiorini, Gopalakrishnan, 2015):
• Pools – used to represent the higher level of categorization.
• Lanes – used to represent the categorization within the Pool.
An example of such categorization could be different organization departments represented by lanes within one organization represented in the business process by the pool.
Figure 13 - BPMN Swimlanes (White, 2004)
Artifacts
Artifacts are used to add supporting information about the process itself or elements for the process. BPMN specifies two following types of artifacts (Fiorini, Gopalakrishnan, 2015):
• Group - is used to visually separate a group of flow objects from others provided that this group shares a common feature linking them together
• Text annotation – used to add additional documentation for any element within the business process.
Figure 14 - BPMN Artifacts (White, 2004)
5.3.2 Detailed Process Diagram
Another diagram from the MMABP methodology is a Detailed process diagram which should be created for all processes from the Process map. For each process there should be two levels of detail created (Řepa, Svatoš, 2021, p. 208):
• Process steps – this level of process description provides a view of how the process is synchronized with the environment of the process. All process states of the process at which it is waiting for the information from the external source are described at this level.
• Process tasks – this level provides the detail of process steps and focuses on the execution paths of tasks within the process.
Detailed process diagram should also contain steps that the organization must take even after the customer need is fulfilled. (Řepa, Svatoš, 2021, p. 208)
5.4 Data Flow Diagram
A data flow diagram (DFD) maps out the flow of information for any process or system.
(What is a Data Flow Diagram, 2021)
The main benefit of DFD is the ability to address operations that process information in the form of functions. When creating a DFD, it is necessary to follow its predefined rules. For each task, in addition to high-level functions, information flow executing the functions, sources and targets of the flows, and data stores used to store or retrieve information are also included and described. In addition, if the Data flow diagram is used correctly, it is assumed that a check will take place during the creation of the DFD to ensure that all information is included in the end-to-end information flow. (Řepa, Svatoš, 2021, p. 218)
Figure 15 - Data flow diagram (DFD) - Example (Řepa, Svatoš, 2021, p. 215)
6 Software Development Life Cycle Models
In this chapter of the thesis Software development lifecycles models are described and divided according to the types. In the last section, a detailed characterization of the Waterfall model is provided.
6.1 Categorization of Software Development Life Cycle Models
Morten Korsaa, Robert Olesen, and Otto Vinter (2002, p. 12) define the software development lifecycle as some sort of guidelines providing instructions on the order of the major tasks which should be realized during the project execution. Apart from the order of major tasks, the software development lifecycle model should also include instructions for the conditions when progressing from one stage to another.
Dave Swersky (2018) defines software development lifecycle as “terminology used to explain how software is delivered to a customer in a series of steps. These steps take software from the ideation phase to delivery.”
Morten Korsaa, Robert Olesen, and Otto Vinter (2002, p. 12–18) offer an idea that each model for software development created in the industry can be grouped according to two models:
• waterfall models, and
• evolutionary models.
The majority of the models can be categorized according to this division. However, there is another group of models representing all models created by combining models both aforementioned models.
Apart from mentioned models Morten Korsaa, Robert Olesen, and Otto Vinter (2002, p. 12- 18) describe other models:
• the Spiral model,
• the RAD model,
• agile models, and
• iterative model.
6.2 Waterfall Model
“The by far most popular model is the waterfall model, which is characterized by confining feedback loops to successive stages in order to avoid expensive rework over many stages.”
(Korsaa et al., 2002, p. 12)
The waterfall model was first described in 1970 by Winston W. Royce and to this day is extensively implemented by many organizations. (Van Casteren, 2017)
This model is specific and requires that in the initial stages of the project, the customer knows exactly what he or she wants. This is because the Waterfall model defines requirements as frozen during the course of the project which cannot be changed except in extreme cases.
In order for a project using the Waterfall model to be successful these criteria should be met (Korsaa et al., 2002, p. 12-13):
• stable requirements,
• stable environments,
• focus is on the big picture, and
• one, monolithic delivery.
6.2.1 Stages of the Waterfall Model
Waterfall software development life cycles consist of 6 phases which are closely connected and for each phase input and output criteria should be defined. When progressing from one phase to another all tasks and activities of the previous phase must be closed, which means that the whole phase is frozen. Only when this is fulfilled is it possible to start the next phase.
Figure 16 illustrates simplified Waterfall model with its following sequential phases (Zulqadar, 2019):
• Requirement analysis – in this phase all requirements are identified, documented, and approved.
• System design – based on the defined requirements from the previous phase system design is created. System design consists of system and hardware requirements (user interface, network infrastructure, programming language, or data layers).
• Implementation – based on the design of the system small parts of the system per requirement are developed. After the requirements are covered by the developed code, it is then integrated and handed over to be tested.
• Testing – all kinds of tests are executed within this phase. Often the customer is involved, to test the software and be sure that all requirements are met.
• Deployment – after all tests are completed, the software is released to the market or deployed in the customer environment.
• Maintenance – possible fix of bugs and issue in the client environment are done in this phase along with possible changes based on the customer’s requests.
Figure 16 - Phases of the Waterfall model (SDLC - Waterfall Model - Tutorialspoint, n.d.)
6.2.2 Advantages and Disadvantages of the Model
Balaji and Murugaiyan (2012) in their article define the following advantages of the Waterfall model:
• Requirements are clearly defined before the development phase.
• New phase starts after the previous phase was completed within the defined time schedule.
• Resources required to implement the Waterfall model are minimal.
• For each phase, documentation is created.
• It is easy to implement.
As for the disadvantages:
• Problems occur after the phase is ended which is caused by a poorly structured system.
• Change of the requirements is not possible once the Requirements phase was closed.
According to Morten Korsaa, Robert Olesen, and Otto Vinter (2002, p. 13) it is important to differentiate between various classes of software. The Waterfall model might be an appropriate model to follow for some classes such as safety-critical systems or fixed priced contracts. However, implementing the Waterfall model is not recommended for interactive end-user software for which requirements are tailored to the customer’s needs.
7 Transformation of the Business Process from Business System Model to the Model of Implementation Using Technological Process Model
As mentioned in the theoretical part of the thesis, transformation of business process into executable processes was done following the principle of three architectures, and consists of three models:
• business system model,
• technological process model, and
• model of the implementation.
This chapter is divided into three sections according to the models (business system, technological process, implementation) and for each part, there is a guideline on how to transform the business process from one model into another one. This guideline includes recommended steps defined to transform the business process seamlessly.
For the purposes of the master thesis, a process called Processing a request to create an account remotely was created and used as an example. Process of Processing a request to create an account remotely is presented in detail in the following chapter using MMABP methodology alongside detailed commentary.
The basic software development lifecycle model - Waterfall was used to transform the process of Processing a request to create an account remotely from a business system model to an implementation model based on the proposed steps in the second part of the master thesis. This model was chosen mainly for its simplicity regarding the use of the model, which, due to the complexity of the process implementation, covered all the necessary phases. Another factor that led to the choice of this model was the fact that all requirements were specified in advance and changed only minimally during the transformation.
7.1 Business System Model
The business system model also referred to as business documentation was created according to the MMABP methodology - Methodology for Modelling and Analysis of Business Process. The business system model served as an initial business baseline, from which the next model, was created. Therefore, all diagrams were supplemented by a detailed commentary, which is needed to create a complete description of the business process from the business perspective.
