A formal framework for business process modelling and design☆
Introduction
The problem of representing, analysing and managing knowledge about an enterprise and its processes has always been very important. Recently, management and computer science researchers have debated the use of information technology for tackling this complex problem [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]. Ultimately, this research community is interested in improving the understanding of organisations and their processes, facilitating process design and analysis and supporting process management (i.e., process enactment, execution and monitoring). The topic is also of great practical importance to industry as an aid to designing organisational structures, processes and IT infrastructure that achieve business goals in an efficient and flexible way.
An enterprise model is a description of the main constituents, purpose, processes, etc. of an organisation and how they relate to each other. It is essentially a representation (on paper or on a computer) of the organisation's knowledge about itself or what it would like to become. Here “organisation” can mean anything from a large corporation or government department to a small team or a one-man company. Similarly, the level of detail represented in the model can vary depending on its purpose.
Creating an enterprise model can be instructive in itself, revealing anomalies, inconsistencies, inefficiencies and opportunities for improvement. Once it exists (particularly in computerised form) it is a valuable means of sharing knowledge within the enterprise. It can also be used to formulate and evaluate changes, for example introducing a new product and associated business processes. The knowledge sharing role also extends to the enterprise's IT infrastructure. It is in principle possible, for example, to extract process definitions to be input to a workflow management system. Furthermore, it would be possible for business process support software to query the enterprise model, for example to find out who is fulfilling a given role in a given process.
In this paper, we advocate a formal approach to enterprise and business process modelling. Formal enterprise models, such as ours, are ones in which concepts are defined rigorously and precisely, so that mathematics can be used to analyse, extract knowledge from and reason about them. An advantage of formal models is that they can be verified mathematically, can be proved that they are self-consistent, and have or lack certain properties.
In summary, the original contributions of this paper are the following:
- •
We present a formal approach to enterprise and business process modelling. Our approach is built on the situation calculus (a knowledge representation formalism used in AI [12], [13]) and the established tradition of projects F3 [14], [15] and EKD [16], [17]. An important feature of our model is how the use of situation calculus is combined with use of the concurrent logic programming language ConGolog [18]. ConGolog is used to capture operational knowledge about how actors behave when playing roles (e.g., when an actor in role “Postgraduate Secretary” is notified of an event of type “request for information”, it performs action “reply to request”).
- •
We sketch the basic steps of a methodology which can be used by an enterprise for analysing and redesigning an existing business process, or developing a new one. The methodology starts with the objectives of the enterprise and produces a detailed formal specification of a business process which achieves these objectives. The formal specification is developed as a set of submodels that capture the business process from various viewpoints.
Our methodology has a distinguishing powerful feature when compared with similar methodologies developed in other enterprise modelling projects, e.g. EKD [17], [16]. In our framework, a business analyst is able to verify formally that each role responsibility is fulfilled and each constraint is maintained as a result of process execution.
We stress here that our verification techniques can be used as they are in similar methodologies such as EKD [17], [16] once formal models like ours are adopted. We view this as an important contribution of our work.
The rest of this paper is structured as follows. Section 2 introduces our approach to enterprise modelling and gives details of the formalism we will use. 3 The organisational submodel, 4 The objectives and goals submodel, 5 The process submodel, 6 The concepts and constraints submodels present the various parts of our enterprise model. Section 7 sketches the basic steps of our methodology while Section 8 concentrates on our process verification techniques. Finally, Section 9 discusses related work and Section 10 presents our conclusions.
Section snippets
Formal enterprise modelling
Our approach to enterprise modelling follows the lead of F3 [14], [15] and EKD [16], [17]. An enterprise model consists of five interconnected submodels that are used to describe formally different aspects of an organisation:
- •
organisational submodel, describing the actors in the enterprise, their roles, their responsibilities and their capabilities,
- •
objectives and goals submodel, describing what the enterprise and its actors try to achieve,
- •
process submodel, describing how it (intends to) achieves
The organisational submodel
The main concepts of the organisational submodel are actor and role. An actor is an intentional entity, that is it has some idea of purpose that guides its actions. The concept of actor will be used to model people or groups of people or software/hardware systems in the context of the organisation we are modelling (e.g., an employee, a customer, a committee, an automated work-scheduling system, etc.). Actors are distinguished into human and automated ones. Actors are capable of executing
The objectives and goals submodel
An enterprise goal is a desired state of affairs [25], [26], [27], [21], [15], [6], [10], [16]. Examples of enterprise goals are the following: “all customer enquiries are answered within one day”, “profits are maximised” and so on.
In our framework goals are associated with the following components of other submodels:
- •
Roles and actors (organisational submodel). Goals are assigned to roles as a matter of policy by the organisation. Organisational goals become responsibilities of roles and the
The process submodel
A good process model should allow representation of “what is going to be done, who is going to do it, when and where it will be done, how and why it will be done, and who is dependent on its being done” [35]. The process model presented in this section allows one to answer five of these seven questions. We do not include a spatial attribute for processes and we do not consider dependencies [21] explicitly.
The main concepts of the process submodel are: action, process, role, actor and goal. The
The concepts and constraints submodels
The concepts submodel contains information about non-intentional aspects of enterprise entities, their relationships and attributes. Information in this submodel is formally expressed by sentences of using appropriate predicate and function symbols (e.g., for our enterprise a predicate Has(a,app) might be used to denote that actor a has application app). Enterprise data are part of this submodel.
The constraints submodel is used to encode restrictions imposed on the enterprise. Constraints can
A goal-oriented methodology for business process design
This section and the next one outline the basic steps of a methodology which is based on the enterprise modelling framework developed in the previous sections. The methodology is intended to guide an enterprise wishing to develop a new business process. The methodology starts with the objectives of the enterprise concerning this new development and produces a detailed formal specification of a business process which should be implemented to achieve these objectives. The formal specification is
Formal verification
The final step in our methodology is to verify formally that each role responsibility is fulfilled and each constraint is maintained by the ConGolog procedures defined for each role. To perform verification we utilise the techniques reported in [46], [42], which are based on a systematic solution to the frame and ramification problems [13]. Specifically, we are interested in determining whether: (i) responsibilities of roles can be fulfilled, and (ii) constraints are preserved or violated as a
Discussion
The first paper to propose situation calculus and ConGolog (more precisely its earlier version Golog) for business process modelling was [46]. Since then similar ideas have appeared in [42], [10], [38]. But so far, ConGolog has not been used in conjunction with a more general framework like ours that offers intentional concepts like actors, roles and goals.
Situation calculus is also the formalism of choice for the TOVE enterprise modelling project [51]. However, TOVE concentrates mostly on
Conclusions
We presented a formalism that can be used to represent knowledge about organisations and their business processes. We also discussed a methodology that enables business analysts to go from high-level enterprise objectives, to detailed and formal specifications of business processes for realising these objectives. The methodology can be used by an enterprise that wishes to develop a new business process, or alternatively model, document and analyse formally an existing process.
The main
Acknowledgements
The work of the first author was partially supported by BT Labs, Ipswich, UK through a Short Term Research Fellowship. The first author would like to thank Paul Kearney, Paul O'Brien, Mark Weigand and Nader Azarmi for support and encouragement during his collaboration with BT Labs. Paul Kearney in particular provided many comments on previous versions of this paper; these comments have all found their way into this paper.
The work of the second author was partially supported by the University of
References (53)
- et al.
ConGolog, a concurrent programming language based on the situation calculus
Artif. Intell.
(2000) - et al.
STRIPS: A new approach to the application of theorem proving to problem solving
Artif. Intell.
(1971) - et al.
Goal-directed requirements acquisition
Sci. Comput. Programming
(1993) - et al.
Reengineering the Corporation: A Manifesto for Business Revolution
(1993) Process Innovation: Re-Engineering Work Through Information Technology
(1993)- ...
- ...
- ...
- M. Ould, Modelling business processes for understanding, improvement and enactment, Tutorial Notes, 13th International...
- et al.
An overview of workflow management: from process modelling to workflow automation infrastructure
Distrib. Parallel Databases
(1995)
Managing business processes as an information resource
IBM Systems J.
AI models for business process reengineering
IEEE Expert
Cooperative Knowledge Processing: The Key Technology for Intelligent Organisations
Some philosophical problems from the standpoint of artificial intelligence
Enterprise modelling
Ing. Systems Inf.
Enterprise modelling and the teleological approach to requirements engineering
Int. J. Intell. Cooperative Inf. Systems
A Mathematical Introduction to Logic
Business Processes: Modelling and Analysis for Re-engineering and Improvement
The ORDIT Approach to organisational requirements
Cited by (87)
A complete approach for CIM modelling and model formalising
2015, Information and Software TechnologyCitation Excerpt :Because the CIM level model has no uniform standard and it is subjective, many proposals do not consider the model correctness. Although some formal business modelling approaches such as TFM4MDA [40] and mathematical approaches [26] can check the completeness of the functional requirements, these approaches require business analyst with a mathematical expertise, and thus it suffers from a lack of practicality. In contrast, our approach uses well-known and easy to use modelling languages such as GRL, UCM and BPMN via stepwise refinement and builds a complete and consistent CIM level model.
A novel secure business process modeling approach and its impact on business performance
2014, Information SciencesCitation Excerpt :The late requirements stage focuses on modeling the “to-be” security model by adding and analyzing security requirements and constraints. In the architectural design stage, the existing actors are divided into sub-actors and the security goals are delegated as the second level in this stage [50]. The detail design stage focuses on defining the architecture elements that have been defined in the previous stages in more detail in inputs, outputs, controls and security aspects by using the UML sequence diagram for the agent interaction diagram [68].
Implementation of the Digital Twin of Educational Business Processes on the ELMA BPMS Platform
2022, AIP Conference ProceedingsConsistency requirements in business process modeling: a thorough overview
2019, Software and Systems ModelingIntegration of Business Process Architectures within Enterprise Architecture Approaches: A Literature Review
2019, EMJ - Engineering Management JournalASP and ontologies for reasoning on business processes
2019, CEUR Workshop Proceedings
- ☆
An earlier version of this paper appeared in the Proceedings of Caise*00, Stockholm, Sweden, June 5–9, 2000.