Whom to talk to? A stakeholder perspective on business process development
- First Online:
- Cite this article as:
- Fleischmann, A. & Stary, C. Univ Access Inf Soc (2012) 11: 125. doi:10.1007/s10209-011-0236-x
Although many organizations operate in a process-driven way, few members are skilled in specifying and developing business processes—a skill that has become crucial for organization development, in particular to establish agile enterprises. This paper shows, on the basis of natural language constructs (subject, predicate, object) and communication patterns between actors (subjects), how individual members of an organization could contribute to coherent and intelligible process specifications. A language and tool supporting Subject-oriented Business Process Management (S-BPM) are introduced, allowing organizations to cope with strategic and operational challenges dynamically. As many organizations already work with BPM concepts and technologies, existing approaches to process modelling are also revisited with respect to representing natural language constructs and standard sentence syntax. Since most of them refer either to subjects, predicates, objects or to a respective combination, a roadmap can be developed for enriching existing modelling approaches. In doing so, organizations can benefit from stakeholder inputs for effective business process engineering re-using existing specifications.
KeywordsBusiness process modellingSubject orientationRepresentationProcess prototypingBusiness process executionAgile business developmentOrganization design
Contemporary enterprises have to compete in the business environment by implementing processes and information systems addressing quality, cost, partner/customer relationships and structural flexibility . They need to adapt at the stakeholder level to changing needs albeit increasing their operational efficiency and effectiveness (cf. [6, 18]). In order for flexible operation to be addressed accurately, management and stakeholders have to work on the associated processes . They depend on the particular business objectives set by the enterprise and affect strategic, tactical and operational issues .
Business process specifications have to be tailored by participating parties to the specific situation at hand. Of particular importance are the intuitiveness of the notation and coherence of the modelling language. The first addresses the semantic distance to human understanding. It should be minimal, in the sense that it requires minimal cognitive effort to understand and communicate the represented information—organizational design is a good deal negotiating (cf. ).
When reflecting and redesigning the focus is on business process models and their specification, according to their nature as ‘boundary objects’ : ‘Boundary objects not only help to clarify the attitudes of other communities, they can also make a community’s own presuppositions apparent to itself, encouraging reflection, and second loop learning.’ As such, processes should be not only intelligible to all stakeholders involved in work procedures, but also to organization and technology developers . Coherence of specification addresses the consistent propagation of strategic objectives, e.g., to establish the enterprise as innovation leader, to tactic and operational structures, e.g., reducing the innovation cycle times within the enterprise on the tactic layer and establishing idea loops in production-process definitions on the operation layer (cf. ). As coherence also addresses the adequacy of operational structures, it has to be considered to be relevant for executable representations, either for automating business processes or simulating them (e.g. to anticipate changes). It is a challenge still to be met. According to Strosnider et al. , traditional flow-driven assembly and orchestration of service components are ‘too rigid and static to accommodate complex, real-world business processes’ (p. 415).
Language structures might help to structure the perceived world more accurately than any other form of representation, as recent empirical work in knowledge management reveals, even when information is presented by diagrammatic means (cf.  working with hierarchical networks that contain expression anchors for associations on different levels of abstraction). The work presented in this paper takes on such a structural perspective. The introduced Subject-oriented Business Process Management (S-BPM) approach follows the syntax of natural language syntax for standard sentences. The information is presented in diagrammatic form, focussing on interaction among actors (denoted as subjects). S-BPM also follows the principles of decomposition and hierarchy-specific associations. Conceptually, the subject, predicate and object of concern are of equal importance when modelling the reality as perceived by humans. Using identical formal representations leads to concise models in terms of flow control. Once the interaction patterns among actors (subjects) have been refined in terms of exchange of messages, suitable program code can be generated automatically.
S-BPM triggers a shift of process modelling paradigms centred on functions or activities to business entities to role-specific entities (actors, subjects). Subject orientation incorporates them into the structures of business processes guiding their decomposition for implementation at a service level. Executing process models in this way provides immediate organizational user experience, as it abstracts from implementation details in terms of programming languages or software execution.
This work builds upon the endeavours of enterprise modelling as started by Vernadat , taken up by model-based workflow design , and leading to active knowledge modelling (cf. ). Although recognizing the context of work processes, S-BPM does not claim to map business strategies to operational procedures in a traceable way (cf. ). S-BPM rather re-invents the business in terms of communication and goal-directed work-interactions (cf. ).
Stakeholders need only to be familiar with natural language (in particular, sentence syntax and semantics) to express their work behaviour in terms of (e-)mail communication
Stakeholder specifications can be processed directly without further transformations, and thus, experienced as described.
In this way, non-disruptive and non-distracting roundtrip engineering can be established, reducing development effort through stakeholder specifications and automated execution without any transformation.
The paper is structured as follows. Section 2 reflects on the situation context when process specifications are utilized in organizations and the user requirements to that respect. As the current focus of BPM on functions and function-oriented flows of control does only partially help to meet user requirements, natural language and communication structures are closer to human behaviour and facilitate stakeholder-oriented BPM . In this way, the acceptance of process models and process-based organization development can be increased. Section 3 introduces S-BPM, based on standard sentence semantics—subject–predicate–object, such as ‘I prepare an invoice’, and message exchanges between subjects (systems or stakeholders), such as ‘Sending the invoice to the customer’. This section also demonstrates the coherent refinement procedure and shows behaviour specifications, including their execution.
In order to explore the development potential of existing modelling approaches towards stakeholder-oriented BPM, major modelling concepts need to be reviewed in terms of fundamental natural language constructs and standard sentence semantics. Section 4 starts out discussing predicates (activities), proceeds with objects addressed by activities and focuses on the subject as a starting point of work descriptions, and thus, of modelling and specification. Section 5 re-captures a study set up to observe stakeholders when modelling business processes with minimal structural inputs, confirming the proposed direction of stakeholder-oriented process development. Section 6 concludes the paper summarizing the achievements and sketching upcoming research.
2 Business process models as transformation enablers
This section provides the rationale for the conducted research in terms of current BPM activities. From a hermeneutic perspective, system development is motivated as a natural language-driven transformation process of model descriptions to executable ones.
economical scale: costs, transformation effort
social scale: conflicts, negotiations about the meaning of representations
organizational scale: iterations, social tensions, mutual quality control
These effects are of particular importance when dealing with changes: ‘As human cognition often perceives dynamic phenomena by developing a series of snapshots, capturing the true dynamics inherent on a process is challenging. By mistakenly taking snapshots to represent processes, there is a risk of tinkering with the wrong things, destroying natural controls that already exists, and essentially turning the organization into a jumbled mess of confusion ’ (cited in , p. 15).
The mismatch of notational capabilities with respect to semantics also leads to misconceptions and incoherent transformation of information throughout analysis, design and implementation (cf. http://wwwcs.upb.de/cs/kindler/Forschung/EPCTools/). The semantic gap has recently been addressed in the realm of semantic web development , is well known in user-interface design  and has been elaborated for modelling . Despite those findings, business processes are increasingly used to implement push technologies based on information systems, e.g., pushing tasks to users . As such, the pragmatic quality of business process models is of outstanding importance, as users ground their knowledge on those representations .
The pragmatic quality is of vital importance when interoperability needs to be achieved, both on the level of organizations, and the level of information systems (development), enabling cross-boundary operation . According to the Yankee Group , still a third of the overall costs could be cut when succeeding in achieving business and technical interoperability. This share is likely to increase due to the latest reports on the mismatch between business and technology modelling entities in the realm of the UN/CEFACT standardization efforts: ‘… we find it hard to gain any benefit from the conceptual distinction between Core Components and Business Information Entities.’ (, p. 33).
Business processes: common ones, such as Create Order
Product classifications: Universal Standard Product and Service Specification (UNSPSP), e.g., for packaging machinery, passenger motor vehicles
Industry classifications: International Standard for Industrial Classification (ISIC), e.g., for Automotive, Consumer Products
Geopolitical context: ISO 3166.1 Country Code List
Official constraints, such as Title 20 Restriction (for importing beef)
Business process roles : common ones, such as supplier, carrier, seller
Supporting roles: common ones, such as insurance company, chamber of commerce, certifying party
System capabilities, such as GS1: RosettaNetPIPs:3.0, OASIS:UBL:V2.0, SAP: GDT:2.0
“Regarding the context driver principle, we perceived the definition of the context categories and the corresponding context value list as work in progress, which still needs further elaboration and evaluation.” (, p. 33)
As the key to coherent modelling and representation, one can consider the integration of business context information in development specifications. As models in terms of specification represent the main means of communication between customers, users and developers (analysts, designers, programmers, evaluators), natural language could bridge communication gaps caused by modelling constructs of formal representations. Users and developers should benefit in terms of completeness and accuracy, as already intended by several projects—see for instance, http://web-imtm.iaw.ruhr-uni-bochum.de/iug/projekte/expect/start. Any mapping scheme should allow propagating the information from a value chain perspective to a software-development perspective in a coherent and consistent way, starting with specifications based on natural language. Today’s process modelling notations and languages based on UML or other specification languages neither focus on natural language, nor on a role-specific behaviour specification. They rely on function-oriented flows of control for implementation, e.g., ARIS .
A natural language modelling approach could help to bridge the gap between informal and formal representations, due to its capability to reduce the cognitive workload for specification and to focus on relevant design elements. Although language can only be considered ‘a window’ into thoughts, as Pinker  puts it, language offers the richest source of evidence about perceptual and cognitive processes. And, it is the most natural and comprehensive tool for communication, as people need to communicate for model building and information system development (cf. language-action perspective introduced by Winograd  and applied to information systems development recently by Rittgen ).
As the so-called third wave of Business Process Management let companies and workers create processes on the fly, current process modelling tools are expected to support process responsibilities in managing their process themselves . Just as spreadsheets provide direct manipulation of data, responsible needs direct manipulation of their business processes. For instance, an auto designer does not develop requirements for a new car and hand the specs over to the IT department for rendering; it is done on the designer’s 3-D workstation. This type of end-to-end control is what business stakeholders need to build a process-managed enterprise. Business process management systems (BPMS) should directly execute open, standards-based business process models the way that a DBMS executes a SQL query.
A business process modelling language (BPML),
A process-designer interface called the business process modelling notation (BPMN)
A simulator that can be used to ‘flight test’ new process designs.
Of major importance is the duality of expressiveness of any business process language in that context. It needs to be accurate to describe processes performed by stakeholders, such as of applying for a position, yet also precise enough to describe how computer systems have to communicate, in order to support that processes in dispersed multi-agent settings, in the absence of central control. In such a setting, organizations need not only means to conceive (new) processes, but to actually put them into action. Since operation managers cannot be expected to be process managers, process modelling needs to be done in a natural way and generate not more effort than filing a record to repository.
A corresponding BPMS needs a control flow that is not only sequencing functions, but rather coordinating agent-specific control flows (see www.bpmi.org for details). Processing systems must separate data from procedure and process, since only data could be structured in a predictable, reliable and stable way. A similar technique to the specification of business processes needs to be applied, except that these dynamic business activities are not stable or predictable. Because they are so dynamic, it is difficult to encapsulate them in software.
So far, the BPMI initiative has not been taken up by organizations (cf. www.bptrends.com). According to the analysis provided by Gartner, business process models either have been considered as technical means to proceed with Enterprise Application Integration, or to further develop Enterprise Resource Planning Systems or Workflow Management Systems. The conceptual importance and the natural handling of process models to develop the business in a networked ecosystem has not been recognized or tackled. This development still continues when looking to the standards committees. Neither the OASIS technical committee on BPEL (Business Process Execution Language), nor the W3C and OMG address handling of languages in terms of their usability for people operating their business.
This line of development also holds for recent approaches to stakeholder-oriented modelling, such as BPEL4People ([2, 27]). This kind of extensions still focuses on (web) service hierarchies and related execution issues rather than business roles and organization-centred task accomplishment. Typical stakeholder and task-related concepts are business administrator, or responsibilities of ‘generic human roles’. The latter, however, are descriptors of how persons interact with processes in terms of process ownership and initiators. The ultimate goal of these approaches is process execution powered by services of distributed systems, rather than coherent business operations. The focus on execution has not changed, even when human tasks have been interpreted in terms of services (cf. ).
3 Specification of business processes according to standard sentence semantics
When structuring reality, humans use subjects, predicates and objects—each of them can be mapped to natural language entities.
Natural language supports human communication effectively, both in written and oral form.
As humans use natural language structures as primary means to ensure mutual understanding, model descriptions for formal modelling could make use of it, in order to facilitate understanding models and ease the use of formal representations.
Once formal specifications could be aligned to human concepts in this way, not only the communication between developers, experts and ICT users could be streamlined, but also misunderstandings could be reduced in the course of systems development.
In order to ensure coherence of specifications, the exchange of messages determines the flow of control (in contrast to function-oriented approaches).
3.1 Natural language sentences and modelling
The introduced language for the description of process models captures the constituent elements of natural language sentences. The modelling language Parallel Activity Specification Schema (PASS) is based on the theoretical concepts (process algebra) provided by Milner and Hoare (see Sect. 3.4). It includes subject, predicate and object ([13, 14]). Model descriptions created in this way should be easier understood, and thus, should be usable in a straightforward way, compared to current modelling languages. Still, models described by this language can be transformed to executable code without programming.
Following a functional approach, accidental factors are grouped around functions, e.g., creating control flow diagrams or data flow diagrams according to de Marco .
Using data-oriented modelling, accidental factors are grouped around data, e.g., setting up Entity-Relationship diagrams.
In an object-oriented setting, e.g., using UML, accidental factors are grouped around objects (classes). It has become common in software and data engineering.
In the course of specification, models are described and documented, using representation schemes as those mentioned above. Modelling or analysing means to represent parts of the observed reality in terms of artificial languages. Models formulated in natural language terms allow for universal use, due to the familiarity of natural language in daily communication, and the availability of a standard semantics for sentences, comprising subject, predicate and object.
Here, the term standard semantics of sentences is used to denote level 2 of sentence semantics. According to Schmidt et al. , this level addresses three semantic roles: agent, predication and theme. Expressions, such as ‘Mark enjoys tea time’, are assigned to that level. Level 1 contains expressions like ‘Tea is black’, whereas level 3 allows semantic structures within sentences, such as ‘Mark enjoying tea time reflects his day’.
A subject is the starting point for describing a situation or events,
Activities denoted by predicates, whereas
An object is the target of an activity (denoted by a predicate).
The distinction between essential and supplementary aspects can be kept for the natural language approach. Humans use passive sentences in case they do not reflect or want to ignore who acts or triggers an action in a certain situation. Artificial or formal languages should support complete standard semantics for sentences, in order to prevent from misunderstandings.
The increasing utilization of business process models specifying business-relevant event chains seems to shift the attention to modelling towards subjects, since it denotes the starting point of any activity. So far, existing modelling approaches tend to focus on predicates or objects, adding the subject for natural language explanations of the represented information. However, information systems have to be considered as subject-sensitive (cf. ), i.e., in the context of role-specific activities.
The interplay between roles or employees and activities is specified through business process models, both on the level of individual work tasks, and on the organizational level. Applications are assigned to automated tasks or interactive chains of executions. In business process models acting roles, e.g., the employees are distinguished from predicates defining the activities of acting roles, and objects denoting the purpose of these activities. In the course of accomplishing their tasks, they receive work inputs and pass on results. Hence, interaction and communication, either direct or indirect, are to be considered as an essential activity of acting roles for subject-oriented modelling and specification.
In the following, both approaches will be explained in detail. In sub Sect. 3.2, the stepwise reduction of interaction between actors or acting components is explained. In Sect. 3.3, the stepwise creation of a communication-based process model is detailed. In both cases, actual or envisioned work processes need to be represented in a transparent and traceable way.
3.2 Ensuring coherence restricting communication
The subject-oriented representation scheme focuses on the direct communication between all the parties involved in a process. In order to distinguish concrete persons from roles in a process, the parties in a process are called subjects. Subjects are the acting elements in processes, similarly to sentences of natural languages where the subject is also the acting element.
Each subject starting a message exchange is marked with a small white triangle (subject1).
Each subject can send messages with the name Message to any other subject any time. Figure 3 shows the behaviour of the subject with the name Subject1. Since Subject1 is the subject that starts a process its start state is the state select. The start state is marked with a thick frame. The state ‘start’ and the transitions to the state select will be never executed in the start subject. This state is the start state in all the other subjects. All the other subjects are waiting for a message from all the other subjects.
In this way, all subjects that are not start subjects have to receive at least one message before they can start to send messages. The start subject sends a message to any other subject. The receiving subject can reach now the state select. In that state, any subject can decide upon its next action without restriction. A subject that is in state select can send a message to other subjects that are still in the state start. Now, these subjects can also reach the select state and can send messages. Finally, all subjects are in the state select and can communicate when addressed.
The representation scheme can be easily created for any number of participants, following the same principles as shown for three parties. The behaviour of each subject has to be adapted to the corresponding number of subjects in a process. It is necessary to add the corresponding send and receive transitions between corresponding states. In the send area, transitions must be added to send a message to the new subject, as for the receive area. In the receive state, a corresponding transition has to be added. With that extension schema, the behaviour for each type of multi-party process can be generated automatically.
Whenever a message ‘message’ is sent, such a business object is sent. The values for the components of the business message object correspond to the content of a traditional mail.
Specify a generic template according to the number of parties involved in handling a certain business case (cf. Fig. 2)
Remove message connections between subjects which are not required
Name the subjects according to the application domain
Name messages and introduce message types according to the application domain
Adapt specification to actual subject behaviour.
Refine the structure of the business objects transmitted by the various messages
With each restriction step, the guidance for the subject holders is becoming more stringent to task accomplishment. In this way, a subject-oriented system specification can guide the parties in a process. It can be used to produce an execution protocol recording the sequences messages have been exchanged between the involved parties. Another advantage is that a workflow can be generated automatically (see Sect. 3.4). The only parameter that must be known is the number of involved parties besides the subject starting the process execution.
The persons Max Mustermann, Tobias Heinzinger, Uwe Hofmann und Johannes Luther are assigned to subject ‘employee’. Since these persons are assigned to the start subject, all of them can start the process. For instance, Max Mustermann creates the message Application for vacation and sends it to Nils Meyer. Nils Meyer, who is assigned to the subject manager, can accept that message and can send a message Accepted or Denied back to subject employee—the message is received by Max Mustermann because he is assigned to the subject employee. Max Mustermann receives the message because in his environment or context, the process is started. If another person assigned to subject employee starts a process, this process instance is executed in his or her environment.
3.3 Constructive behaviour specification
The procedure shown in Sect. 3.2 follows a step-by-step instantiation and restriction process ensuring specification coherence due to its generic scheme. As subjects are abstract resources representing the parties involved in a process, the modelling process might start with identifying the involved subjects and after that define the behaviour specifications of acting parties. Such an approach also leads to a coherent representation, as all required exchanges of messages have to be specified for the procedure to be completed. This time, however, each subject can be directly addressed, rather than instantiating a generic process pattern. In the following, this alternative is illustrated.
Finally, the behaviour of the HR department has to be detailed. It receives the approved holiday application and puts it to the employee’s days-off record, without further activities (process completion).
The subjects involved in a process,
The interactions they are part of,
The data they send or receive through each interaction, and
The behaviour of each subject.
A service is assigned to an internal functional node. If this state is reached, the assigned service is triggered and processed. The end conditions correspond to links leaving the internal functional node.
Each result link of a sending node (state) is assigned to a named service. Before sending, this service is triggered to identify the content or parameter of a message. The service determines the values of the message parameters transferred by the message. Analogously, each output link of a receiving node (state) is also assigned to a named service. When accepting a message in this state, that service is triggered to identify the parameter of the received message. The service determines the values of the parameters transferred by the message and provides them for further processing.
3.4 A first approach to processing
In computer science, the introduction of parallel processes has drawn wide attention (see also ). A process in general executes activities or actions in a certain time interval to achieve a certain goal (cf. ). A process description defines the behaviour of a process. As it will be shown below, this concept relates to the introduced understanding of subjects and the process of subject-oriented modelling.
In standard sentence semantics, the subject is the initial point of an activity or action as defined by the predicate. Hence, subjects represent the active elements of the observable reality. Subjects can process defined sequences of activities (predicates). Subjects are mutually independent and might communicate with each other, exchanging information. Given this understanding, subjects, to a great extent, correspond to processes as defined in computer science. The concept of process enables the mapping of subjects into corresponding model constructs.
In the following, two major concepts are introduced, the Calculus of Communicating Systems (CSS), and Communicating Sequential Processes, both dealing with processes as a primary source for modelling. In these approaches, parallel processes synchronize themselves via the exchange of messages, i.e., a process is able to send and receive messages via so-called ports. Sending and receiving are the only possible predicates available. The ports can be considered as objects of the standard sentence semantics, as they are essential for the dynamic aspect of the concept.
3.4.1 Calculus of communicating systems
Calculus of Communicating of system (CCS) is one of Robin Milner’s developed process algebras . Process algebra is used for algebraic modelling of parallel processes. It consists of elementary activities (elementary actions) and operators associating actions. Elementary actions cannot be decomposed to smaller categories of activities. Processes can interact with the neighbour processes (i.e., located at the same level of abstraction) or execute independent actions in parallel. CCS targets towards modelling of communication between processes.
According to Fig. 16, the process Employee initially sends the holiday application. Subsequently, it waits either for the rejection/approval message. Upon receipt, the NIL operation is executed—the process stops. The description of the processes Manager and Management can be interpreted similarly. The last line of Fig. 16 shows the decomposition of the entire process using the respective operator.
The example reveals the actor to be essential in CCS, whereas predicates and objects are considered accidental factors. CCS can be considered as a subject-oriented approach.
3.4.2 Communicating sequential processes
Communicating Sequential Processes (CSP) is also a process algebra introduced by Tony Hoare . Originally, CSP was published as a program-linguistic construct (Hoare, Communicating Sequential Processes ), before being formalized, influenced by Milner. CSP, in contrast to CCS, does not distinguish between sending and receiving. In case operators connect processes, events of the same name of the linked processes are also connected.
In CSP, events might be refined to send and receive sequences, operating on ports and transferring data. In this way, in CSP, the predicates ‘send’ and ‘receive’ can be used, as well as objects (messages) processed by these simple predicates. However, CSP focus on subjects as essentials like CCS. Predicates and objects play a minor role. Both lead to incomplete models with respect to semantic sentence semantics, since natural language supplements for predicates and objects have to be provided to complete model—intelligible naming does not contribute to the completeness of standard sentence semantics.
3.5 Tool support
In principle, the execution of subject-oriented representation schemes can be supported by an appropriate workflow system. As a first choice, a simple mail system can be used, although requiring strong discipline from the involved parties. In the current example, a workflow system is used especially developed for subject-oriented process specifications and workflows (cf. [14, 15]). In case process modelling is started with the generic process pattern, each restriction step can be executed with that workflow system. The following example shows how the workflow system is used for the 3-subject process template. This template is used to execute an application for vacation.
After creating the process instance, Max Mustermann is guided through the process. He is asked by the workflow system which transition he wants to follow. He knows that he has to fill out the business message form with the corresponding data and that form has to be sent to Nils Meyer. Consequently, Max Mustermann follows the transition ‘send’. In the state ‘Prepare Message and select Receiver’ following the transition ‘send’, he fills out the business object with the data required for an application for vacation.
Number 1 in that figure shows the name of the current state: ‘Prepare Message and select Receiver’
Number 2 shows the title of that process instance: ‘Request for vacation’
Number 3 shows the creation date of that process instance
Number 4 shows the form for filling out the business object.
Subject1 started with the select activity, and the send transition was selected. After that the action ‘prepare message and select address’ is executed and in state ‘state2’ the message was sent to subject2. Now subject1 reaches again the state ‘select’. In state ‘Start’, subject2 receives the message. In the following state ‘follow-up action’, the content of the received message is read, and the corresponding action is executed by Nils Meyer who is the owner of subject2. In the case of the vacation application, this follow-up action is Nils Meyer′s decision whether the vacation application is accepted or denied. This decision must be sent to subject1. In state select, subject2 decides to follow the send transition, prepares the message with the result of the decision and sent it to subject1. This swim lane diagram shows which subject executed which actions in which sequence. If a subject sends a message, the sending state is connected with the corresponding receive state in the receiving subject. Subject1 sends a message to subject2 in state ‘state2’. Subject2 receives that message in state ‘Start’.
4 Standard sentence semantics in existing modelling approaches
The following lays the ground for enriching existing paradigms and modelling approaches using the standard/sentence semantics, comprising subjects (actors), predicates (activities, functions), objects and their interplay for complete specifications. The elements represent modelling and design dimensions for organization development: the WHO (subjects), the WHAT and WHEN (predicates and their sequencing) and USING WHAT (objects, data).
4.1 Predicates or activities
As long as modelling is focused on activities, predicates are essential, whereas subjects and objects are considered as accidental factors or supplementary elements. Such a focus is in line with algorithmic thinking, as computer systems have been constructed to solve complex arithmetic problems rather than processing huge amount of data. Consequently, flow diagrams based on algorithmic entities have been designed initially, and later on, extended to represent event-driven activity chains.
4.1.1 Flow diagrams
One of the first models for algorithmic task descriptions has been a flowchart or program structure plans. Flowcharts describe a sequence of operations or activities to solve a task. As such, they can be used to capture work procedures or business processes like the holiday application. In case flowcharts are used to describe arithmetic operations, the role initiating the process is given implicitly. The machine or a human user triggers the activities denoted by the algorithmic elements. Such standard subjects are not mentioned explicitly. In addition, the data requited for executing a flowchart are given rudimentary. Hence, flow charts do not provide complete sentence semantics. They require natural language supplements to describe relevant subjects and objects.
4.1.2 Event-driven process chains
The rectangles represent activities of a process. For clarification, they are inscribed using natural language descriptions. Those inscriptions might contain the addressed objects. Before taking action events (hexagons) have to be specified. They trigger the execution of an activity (also termed function) referring to the previously executed one. Connectors allow different control flows depending on the results of function executions, leading to different events. The function ‘application check’ can either lead to the event ‘Rejected’ or ‘Approved’ using an exclusive or connector (XOR). Beside XOR, OR and AND can be used (cf. ).
4.1.3 Petri nets
Moving the sequence of activities to the centre of modelling, subjects and objects have to be added by respective natural language terms. In the sample case, proper modelling has been achieved by the proper naming of states and transitions. However, most of Petri net approaches deal with concurrent events and situations explicitly, compared to flowcharts.
4.2 Objects or targets of activities
Shifting from arithmetic processing to business data modelling, the structure of data has become more and more essential, leading to dedicated fields, such as content management . As such, the object of sentence semantics becomes an essential aspect of modelling. The modelling approaches to that respect focus on the goal or the results of activities, as the subsequent review of Entity-Relationship Models and Relational Data Models reveals.
4.2.1 Entity-relationship model
The entity-relationship model (ER-model or ERM) serves as a semantic container for data, i.e., elements and relations, stemming from observing human reality. Most ER-models consist of graphic symbols and a description of the used elements. There exist a variety of diagrammatic notations to present ERM contents. The semantics is specified through categories of data elements and their inter-relationships. When specifying an ERM, concrete entities and relations are used. Entities represent objects of the observed reality, being either material or abstract, such as employee ‘Mark’, manager ‘Max’. Semantic relationships denote relations between two objects, such as ‘employee Mark is assigned to manager Max’.
As ERMs focus on objects, predicates and subjects are only indirectly addressed, by naming the relationship. In case a predicate is used for a relationship, a sentence according to natural language semantics can be built. However, modellers do not have to use predicates for naming relationships. It depends on their conventions besides the objectives of modelling whether predicates become part of ERMs. As ERMs also do not provide flow concepts, it is not evident when activities can or have to be executed (predicate). Finally, only conclusive evidence of subjects can be produced, i.e., who is triggering an activity, in case predicates are used for denoting relationships.
4.2.2 Relational data model
In relational data models, only data objects are of interest, like in ERMs. Subjects and predicates are accidental factors (supplementary elements). There is only one type of structural elements for modelling, namely relations. They are expressed using tables. Entries form data records, with each cell corresponding to a data field entry. A data model mostly consists of several tables. Relationships might exist between different tables containing identical content. Data records are accessed via field entries.
The access to relational data models is achieved by logical, set-theoretical queries defined by users (subjects). A traditional relational data model does not contain its users (subjects). The query language, such as SQL, actually contains all possible predicates and is triggered by the users.
In the holiday application example, the manager Meir Max (a user or subject) asks for employees by formulating a suitable query (predicate) addressing the table Employee (objects). The employees assigned to Meir Max are those table elements in Employee containing in column V–No. 1. In a next step, all holiday applications have to be identified, by finding in the column MA- No. denoting an employee of Meir Max (by number). Then, Meir Max has received all holiday applications of his employees and might proceed with his work.
Relational data models have been developed according to implementation capabilities of data engineering technologies. They can be more or less implemented directly by relational data base management systems. In that case, an ERM is used as a modelling language, and the relational model represents program elements. However, in both modelling approaches, subjects are considered to be less important than objects or predicates. Query languages provide predicates, which ERM lacks completely.
4.3 Predicates and objects, or activities and goals
On the one hand, for approaches focusing on predicates, problems with respect to implementation are evident, since object aspects are not covered sufficiently. On the other hand, approaches focusing on objects are dealing with predicates indirectly, as the query language covers them through its use. Moreover, these approaches do not support the specification of control flows, i.e., sequences of predicates.
The holiday application data are filled into the application form.
The holiday application is checked.
The decision upon approval is documented and communicated.
The days-off sheet is updated.
Below two integrative approaches are briefly discussed, namely dataflow diagrams as proposed by de Marco  and object-oriented modelling.
4.3.1 Data flow diagrams/structured analysis 
External interface (external partner, participant, terminator). External interfaces are displayed as rectangles. They represent relations of the observed system to its environment. They send or receive data, but do not process them. External interfaces trigger the system by providing inputs. They can be considered as subjects to a certain extent.
Function (process, task, function). Circles or ovals present functions. They represent the processing of input data to output data. As such, they represent the algorithms required to process the data. The functions correspond in sentence semantics to predicates. Higher order or complex predicates are further refined by the predicates of a control flow diagram.
Data memory (memory, store). Data memories are presented through parallel lines. They form a repository for data, providing time of generation and use. They can be considered as special functions for storing data.
Data flow (flow of information). The data flow is displayed as arrows between functions or data stores. The arrows are named according to the semantics of the transmitted data. A data dictionary contains the structure of the information used in the DFD. The definition of the structure is provided in Backus Naur Form. However, an ERM could be also used for representation. The data correspond to the objects in the standard sentence semantics.
- Context diagram. Fig. 30 shows the context diagram when processing a holiday application. External interfaces are identified, and the system under development is represented as a function. The context diagram shows that the application data are received from an external interface, and the result of processing is delivered to that interface. In this example, the external interface can be considered as a subject. However, the manager has not been modelled explicitly, since being inherent to this system. In case the manager’s part and the update of the holiday sheet would be moved to external systems, an empty model would remain, since all activities occur externally.
Although data flow diagram has been developed quite a while ago (in the 1970s), they cover predicates and objects from the standard sentence semantics. Subjects can be introduced providing auxiliary constructions, which might lead to misinterpretations. Data flow diagrams are not used any more. They have been further developed to object-oriented approaches.
4.3.2 Object-oriented modelling
The main idea of object-oriented programming and application design is to couple functions to the concerned data and to provide an encapsulated structure and external interface. Functions together with data form an object in object-oriented modelling. The data of an object can be accessed only with respective methods. Classes capture similar properties of objects. Based on objects (or classes), hierarchies can be specified to represent complex setting. Object-oriented models use dedicated constructs for representation and operations for processing, such as inheritance, polymorphism, aggregation, associations, etc. (see, e.g., www.omg.org for the Unified Modelling Language, UML). Object-oriented modelling can be considered as one of the de-facto standards for information system development. They allow for implementation-independent design representation as well as for detailed design and implementation. Its major advantage is the encapsulation of structure (properties, attributes) and behaviour items (methods, functions), since it facilitates modelling processes in that way.
Object-oriented modelling captures predicates and objects according to standard sentence semantics. An object consists of data and functions. The functions of the object correspond to predicates, while the data correspond to the object in the standard sentence semantics.
The Holiday Application class allows formulating incomplete sentences, such as ‘fill in holiday application form’ or ‘check holiday application for holidays’. In order to create complete sentences, some original object-oriented methods provide the capability to insert names for subjects in natural language terms. Today, Use Case diagrams, as provided by UML, enable the specification of subjects. For instance, UML provides 13 different categories of diagrams, one of them being the Use Case diagram (see below).
4.4 Subject, predicate and object, or complete sentences
Use Case Diagrams (Use Cases) follow the standard sentence semantics, as the comprise subject, predicate and object. They allow describing a system’s use from the user perspective. A Use Case indicates which user (actor = subject) performs a certain action (predicate) when using a system. A Use Case describes recognizable behaviour by external parties of an observed element (system, class, etc.). It encapsulates a closed collection of actions that are performed in a certain sequence. A use case hides the classes and operations involved for performing actions. Its description is considered complete once the entire behaviour has been specified, either using behaviour modelling constructs of UML or natural language descriptions.
Although UML provides inadequate means for comprehensive modelling, its diagram types allow forming complete sentences using standard sentence grammar. In UML, actors are not part of the model. Consequently, their behaviour cannot be detailed, in particular with respect to communication. As such, actors do not appear in the remaining diagram types of UML, except in Time Sequence diagrams. However, actors are essential in business process specifications, in particular for intra-organizational processes. Standard UML lacks proper elements for complete sentence representations.
5 Creating empirical evidence
Neubauer et al.  have challenged the stakeholder-centeredness of S-BPM. The study intended to identify factors that cause confusion, and thus, cognitive work load in the course of modelling, preventing the alignment of individual perspectives of stakeholders when describing and specifying their work procedures. At the centre of interest were notational constructs that allow generating adequate business process models from a stakeholder perspective, by studying how those constructs are utilized in the course of modelling.
As the study has been intended to find out human-centred constructs and procedures for meaningful modelling, an open language format provided by SeeMe  has been used. In addition, dynamic switching between particular elements or views on models, such as processes, functions, tasks, has been enabled avoiding any bias towards predefined structures when stakeholders were modelling.
In the study, young adult consumers were asked in 52 individual modelling sessions to contribute to a common scenario, namely purchasing a car. According to the theoretical background of SeeMe, namely communication theory, stakeholders were expected not only to communicate apparent details regarding purchasing a car, but also essential hidden or primarily intangible assets. The latter are required for adequate representations, as they provide valuable input for organizational development and corresponding technological artefacts.
After a short introduction to the elementary SeeMe modelling constructs, procedural instructions have been given to the participants. They were asked to (1) collect all relevant basic elements based on the text description of the case, before (2) identifying relations between the selected basic elements relevant them and (3) identifying situations where connectors are needed according to your understanding. They should capture as many aspects of the textual process description as possible in a process model.
Modelling styles and patterns have been investigated. They direct the modelling process. Besides flow orientation, the orientation towards natural language structures was of interest, since stakeholders initially tend to use natural language to describe their view upon business processes. With respect to natural language orientation, it has been evaluated whether stakeholders have utilized SeeMe constructs to express sentence semantics, such as subject–predicate–object.
In the study, all of the stakeholders have used the following constructs: role, activity, entity, associations between elements and vagueness/incompleteness placeholders. Besides nesting representations, connectors have primarily been used to control the flow of activities, e.g., representing optional activities or parallel activities within a process.
With respect to the modelling process, the majority of stakeholders have modelled the process flow from top to bottom, i.e., activities have been arranged from top to bottom. Roles and entities associated with specific activities were placed next to the activities. The modelling results differ significantly in the level of detail, ranging from vague and high-level descriptions to concrete process steps. However, the majority of stakeholders have depicted the concrete process description and have not generated an abstract picture of the process.
The following model categories could be identified: flow- and natural language-oriented, and combined models. Most of the specified processes reflected a clear flow orientation. They also contained connectors, mainly set between activities to control the process flow. Natural language-oriented models covered models based on natural language structures (subject–predicate–object). Overall, ten per cent of the given models have been identified as language-oriented ones. Interestingly, in this category, connectors have been set mainly between entities, only one language-oriented model contained connectors between activities. Relations have been used to form sentences in natural language. Similar to the flow-oriented models, most models show an arrangement of activities from top to bottom, with roles and entities aside.
Combined models (21% of the models) contained aspects from flow-, language- and/or data flow orientation. They partially reflected inconsistent modelling of control flow between activities: roles triggered activities, whereas entities represented the data flow between activities. Connectors have mainly been used to link entities, besides interrelating roles, and connectors to activities.
All 52 specified processes contained standard sentence semantics for purchasing a car, comprising ‘Who’ does ‘What’ ‘Using what kind of data or element’. All participants have used relations, embodiment with respect to structural aspects, and connectors in the majority of cases. Modelling constructs have been used in a natural language style. In these cases, the reflection and reproduction of already specified information could be achieved in complete sentences.
For S-BPM, another major result is the strong orientation towards flow, as it lays ground to think in behavioural terms when describing task accomplishment. It is a prerequisite for communication-based process execution enabling stakeholders to complete process specifications for direct execution. Finally, the observation that the majority of stakeholders were able to provide concrete process models of the given scenario rather than abstractions facilitates experiencing concrete task executions.
6 Conclusive summary
Organizations are increasingly forced to restructure their business processes in a flexible way during operation. It requires stakeholders to take responsibility for organizational developments. Traditionally, only few members are skilled in specifying and developing business processes. Hence, it is proposed to support them with natural language constructs (subject, predicate, object) and e-mail-like communication patterns between actors (subjects) when describing business processes. In this way, individual members of an organization are able to contribute to coherent and intelligible process specifications, as the resulting specifications can be processed without transformation.
… as I say …
Who does what?
Control flow diagrams
What has to be done?
Event-driven process chains
What has to be done?
Extended event-driven process chains
Who does what?
Entity-relationship model (ERM)
Which data are handled?
Unified modelling language
Partially (only in use cases)–yes–yes
Calculus of communicating systems
Yes–partially (only in terms of responsibility)–no
Who runs what?
Who does what?
The tool (see www.metasonic.de) allows generating executable application programs, by implementing complete standard sentence semantics. The next research objective is to examine how knowledge can be processed and managed using standard sentence semantics based on subjects. Such a structure lays ground for organizational learning processes, both at the single and the double loop. Business process specifications do not only encode operational elements (single loop), but also values and cognitive drivers of learning processes (double loop) (cf. ). As learning involves both, organizational development and learning support have to encounter this dichotomy. In this context, simulation is considered helpful to experience realistic process scenarios before changes are implemented (cf. ). The distribution and assignments of various resources might trigger different actor and business behaviour. Its impact needs to be assessed prior to implementation.
This article is distributed under the terms of the Creative Commons Attribution Noncommercial License which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.