Process Innovation and Improvement Using Business Object-Oriented Process Modelling (BOOPM) Framework

Abstract

In the past decades, a number of methodologies have been proposed to innovate and improve business processes that play an important role in enhancing the operational efficiency of an organisation in order to attain business competitiveness. Traditional business process modelling (BPM) approaches are process-centric and focus on the workflow, ignoring the data modelling aspects that are essential for today’s data-centric landscape of modern businesses. Hence, a majority of BPM initiatives have failed in several organisations due to the lack of data-driven insights into their business performance. On the other hand, the information systems of today focus more on dataflows using object-oriented modelling (OOM) approaches. Even standard OOM approaches, such as unified modelling language (UML) methods, exhibit inherent weaknesses due to their lack of formalized innovation with business objects and the dynamic control-flows of complex business processes. In addition to these issues, both BPM and OOM approaches have been augmented with an array of complex software tools and techniques which have confused businesses. There is a lack of a common generalized framework that integrates the well-formalised control-flow based BPM approach and the dataflow based OOM approach that is suitable for today’s enterprise systems in order to support organisations to achieve successful business process improvements. This paper takes a modest step to fill this gap. We propose a framework using a structured six-step business process modelling (BPM) guideline combined with a business object-oriented methodology (BOOM) in a unique and practical way that could be adopted for improving an organisation’s process efficiency and business performance in contemporary enterprise systems. Our proposed business object-oriented process modelling (BOOPM) framework is applied to a business case study in order to demonstrate the practical implementation and process efficiency improvements that can be achieved in enterprise systems using such a structured and integrated approach.

1. Introduction

The concept of ‘process’ has evolved over the past few decades and is defined as a collection of activities taking at least one input to produce an output of value to customers [1,2]. Recently, the term ‘business process’ has become quite popular as organisations have come to consider a more process-orientated view of their business operations in enterprise systems [3]. In today’s digital context, a business process is considered to be the composition of different activities involving information technologies (IT) and people working together to achieve an organizational goal. Organisations are rigorously redesigning business processes using several best practices with the aim of improving their operations in terms of time, quality, cost, and flexibility [4]. Researchers have emphasized the need for business process innovation/improvement (BPI) and studies in this direction have resulted in several approaches such as continuous process improvement (CPI), business process reengineering (BPR), business process benchmarking (BPB), and process innovation (PI) [1,2,5,6,7]. There are not only differences in terminologies, but also in structure and the primary focus. These business process modelling (BPM) methodologies are process-driven rather than data-driven and do not suit today’s competitive marketplace, where enterprise systems make use of the object-oriented methodology (OOM) to model data objects for achieving data analytics and business insights [8,9,10]. BPM approaches have also been modified by practitioners and consultants to suit themselves in coming up with an implementation framework using IT [11,12,13]. International surveys conducted indicate that about 60%–80% of BPM initiatives have failed despite the increasing amount of BPM software, which has led to much confusion and many obstacles [14,15,16]. This is due to the inadequate alignment of BPM with OOM based enterprise systems and industrial engineers not having taken full advantage of the latest information system strategies for embarking upon business performance improvements.

Industries have come to realise that standard techniques used in OOM, such as unified modelling language (UML) tools, suffer from several weaknesses [17]. They are more technology-oriented, focusing on data objects with complex static architectures, rather than flexible enough to incorporate business objects and the dynamic business process flows [18,19]. More recently, a business object-oriented modelling (BOOM) approach has been adopted by business analysts to integrate business objectives with information systems from traditional OOM paradigms [20,21,22]. Though the BOOM approach uses activity diagrams to model processes, it lacks the advantages of a formalized BPI using value-added analysis available in the BPM approach aiding in value-added workflows mapping into efficient process execution. BPM and OOM paradigms are each endowed with their own body of mature methods and tools that are loosely integrated [23,24]. Overall, the integration between BPM and IT management essential in today’s enterprise systems is missing [8]. This void forms the main motivation for this research to fill a gap in the literature by proposing a business object-oriented process modelling (BOOPM) framework with the aim to support the BPM of an organization with a BOOM oriented design of their enterprise system in order to drive process innovation and business performance improvements.

Overall, the aim of the research is to propose a generalized framework for achieving BPI using the best practices of BPM and BOOM approaches in order to be well-suited for today’s enterprise systems. The methodology will be successful if it is flexible towards incorporating the requirements of the business problem with a good graphical representation of the business processes that can be practically implemented by organisations [3,9]. Existing research has identified several drawbacks while performing a comprehensive evaluation of several process modeling languages with respect to the role of data [25]. Some existing studies have discussed paradigms to address the shortcomings of the data and process engineering divide [23,24]. They have adopted artifact-centric process management paradigms using either service-oriented architectures (SOA) or business object driven processes for achieving higher levels of integration. However, to the best knowledge of the authors, this research is the first of its kind to undertake a BPM approach integrated with BOOM for modeling business processes within enterprise systems with the aim of achieving process innovation and improvements. The key contribution is in developing the proposed BOOPM framework with a step-wise set of practical guidelines based on the existing well-accepted BPM technique and BOOM approach, and with the aim to provide an easy-to-use implementation scaffolding for designing enterprise systems to achieve BPI.

A non-experimental research methodology based on action research is adopted to demonstrate how the improvement in process efficiency can be achieved by applying the proposed BOOPM framework for a generic business situation of a case study. A generic help-desk process discussed in the literature which is applicable for any industry and has been considered for this purpose [14]. Such a process has been adapted for a fuel retailing business due to the complexity of operations involved with different stakeholders and a variety of customer service processes that are typically semi-automated within its enterprise system. The BPM approach has the advantage of modeling complex workflows as it is process-centric. However, the main limitation of a process-centric model is its inability to model from data-centric approaches that are being used in software tools. The workflows do not have all the data dependencies included in BPM tools. BOOM approach can be adopted to include the dataflows but has the inherent drawback of not able to map into process innovation and execution. Hence, a typical semi-automated fuel retail business case study is well-suited for our BOOPM framework. A help-desk business process is considered to simulate the customer complaint process of the business in order to apply the proposed BOOPM framework. By following through the BOOPM practical guidelines for the business case study, the paper aims to illustrate the proposed BPI methodology with a measurable impact for the working team of the organisation. Due to the limitations of the paper to primarily focus on the theoretical concepts of both BPM and BOOM for proposing a new BOOPM framework, only the key artefacts are developed for the help-desk process of the fuel retail case study in order to serve as an illustration for achieving BPI using BOOPM. Among the various BPM tools available, we adopt business process model and notation (BPMN) as it is found to have demonstrated higher data awareness with rich modelling constructs that have led to larger uptake by industry [23,25]. However, while the life cycle of a data object can only be implicitly derived from the data object states, there is no explicit data model life cycle modeling supported by BPMN. Similarly, relationships between data objects such as “is-a” or “part-of” that can be modelled in UML are not supported with BPMN [25]. Hence, for the case study, we adopt UML artefacts as well as BPMN in order to model the help-desk component of their enterprise system. The business use case and class diagrams are developed using UML. The existing process flow (called the “as-is” model) and the proposed improved process flow (called the “to-be” model) are developed using BPMN with variations to include data dependencies in order to integrate with the data object life cycle of BOOM. A performance comparison is done to establish the business process efficiency of the improved business process for the case study.

The rest of the paper is organized as follows. Section 2 describes the related work and the need for a BOOPM approach to improve business process efficiency in enterprise systems. A step-wise implementation guideline of the proposed BOOPM framework is presented in Section 3. A business case study is provided and the implementation of the BOOPM framework illustrating improvements in the process efficiency is presented in Section 4. Finally, conclusions and future work are given in Section 5.

2. Related Work

The need for a business process focus was established more than two decades ago for achieving effective business improvements in enterprises [26,27]. Several tools including benchmarking were adopted, and the underlying success factor was in integrating those into a business process-based approach effectively [6,28,29]. Hence, some researchers have emphasised that it is not sufficient to merely adopt a methodology to incorporate process innovation and improvements as the critical success factor lies in employing the right model of process improvement to be effective for business performance and in adding value to the customer [29,30,31,32,33]. In today’s digitization of business processes, there is a need to revisit the system model in order to embrace both the traditional business process-based approach and software object-oriented approach successfully.

A model is defined as “an abstract representation of real processes, constructed to aid understanding and prediction about the real system” [34,35]. Several models have been proposed in the literature for improving business processes and for analyzing process activities by using flow diagrams, process maps, role activity diagrams, etc. [26,36,37,38]. However, the key to success is in adopting the right modelling approach to design and improve a process with a positive impact on its stakeholders and the resulting overall business performance. Hence, the model should have the capability of representing all the processes correctly with appropriate communication to the internal and external stakeholders, by using a practical and participative approach. The model’s graphical representation should enhance the understanding for modern organizations embarking on business intelligent enterprise systems. Some models, such as six sigma, ISO-9000, and balanced scorecard, that have less graphical representations are considered to be comparatively weakly designed for business process improvement within enterprise systems [39,40]. Despite having best practices handbooks for these internationally acclaimed standard methods, there is a lack of understanding with respect to the process specifications, product specifications, and job descriptions in a work environment that embraces semi-automated systems. To address this, the term “workflow” was introduced. Business process modelling, which was originally termed as “workflow” provides good graphical representation of the processes, events, communication, flows, roles and many attributes that an organization is looking for in their BPI pursuit. Over a period of time, it has been realized that BPM is beyond workflow and the term “workflow” is now considered outdated [41,42]. Today, with increasing global competition, more organisations are adopting BPI initiatives to be integrated with their enterprise systems, and therefore the need for the BPM approach to be revisited is escalating [43,44].

BPM has the advantage of depicting a cross-functional team environment with tasks, sub-processes and activities of each business process defined clearly. These can be examined to identify those activities that add value to the overall process. The structured sharing of process knowledge among the working teams and the community of practice is important [45,46]. In addition, several parameters and drivers such as non-value-added activities and alternate processes can be determined for process innovation and improvement. BPM facilitates communication among all the internal and external stakeholders of the business functions, and thereby, a mutual understanding of the process can be facilitated using IT. This forms another advantage for the team members of the organization to embrace change with a process mindset while developing an enterprise system [47,48]. These are some of the key essential factors for the success of any BPI initiative. Despite the benefits of a formalised modelling of process-driven business operations, identifying process improvements, collecting data for performance measurements using Key Performance Indicators (KPI), the practical implementation of a BPM approach is still very weak due to inadequate support for the designer of enterprise systems in handling structural information during the modelling stage [45,49]. Contemporary information system design techniques involve Object-Oriented (OO) design methodologies [20,21,22]. About 60%–80% of BPI initiatives have failed due to having all the focus devoted towards process modelling, as well as in spending too much time in implementing major organisational and infrastructure changes [49,50]. While several methodologies have been developed for process innovation and improvement, each methodology has a different emphasis on a unique aspect of business process for improvement such as process cycle time, process efficiency, on-time delivery of products or services, quality and error rates [49,50,51]. Further, there is an array of business improvement options presented using varied process innovation approaches within different implementation tools and techniques, and these have resulted in a major confusion among business managers [36,52].

So far, research studies have been primarily reporting on the benefits of business process approach for improving business performance, and on sharing successful improvement strategies adopted by specific businesses as case studies [4,36,53]. Such academic research works have only presented a specific solution focusing on a particular case study and these studies do not lead to a generalised framework suitable for today’s agile enterprise systems. Some generalised software frameworks proposed in literature serve as guidelines for the design of software solutions and services that are more suitable for intelligent business decision making in enterprises [54,55]. Overall, there exists a lack of generalised guidelines that can form a practical implementation framework for designing an enterprise system with an aim of enhancing process efficiency, in particular towards achieving BPI and offering value-added services to the customers of an organistion.

BPM implementation methods need to be reconceived in order to incorporate the dataflow dependencies of workflows to be part of the design process of an enterprise system. Majority of the information systems adopt an OOM approach with dataflow-oriented modelling tools dedicated mainly to process mining, and lack the capability of process innovation [8,9]. Businesses are investing in such tools assuming that they could implement their BPM strategy before arriving at any positive outcomes [12,13]. However, both BPM and OOM lack the integration of workflow and dataflow dependencies, which is vital for BPI in today’s data-centric business process management [15,16,17]. Contemporary information systems engineering exhibits a divide between data and process leading to various drawbacks such a business rule redundancy as well as process-related and function-related data redundancies [23]. This is because fundamentally different modelling approaches are adopted separately to analyse, design, implement, and test data entities and business processes. Recent emphasis on business analytics has driven business object modelling techniques such as BOOM that can bridge the gap between business requirements and data requirements of enterprise system modelling [10,20,49,54]. Organsations are faced with a challenge of choosing from these wide range of methods and tools in their pursuit to provide a step-wise practical guide for facilitating improvements in their business operations. Hence, we adopt a BPM approach combined with BOOM for the implementation of an effective BPI in enterprise systems for achieving process efficiency in improving business performance as well as customer satisfaction.

This research aims to develop a generalised framework consisting of a step-wise set of practical implementation guidelines for achieving business process improvement and innovation using a business object-oriented process modelling (BOOPM). While some studies have adopted a business object (BO) perspective in proposing a new business process modeling approach, they have not considered the well-structured BPM approach [8,9,10]. On the other hand, a new paradigm was proposed to integrate data and process engineering using BPM and SOA [23]. Another generic framework for integrating processes, data, and users was discussed to enable a comprehensive support of data-driven and object-aware processes [24]. While hybrid approaches are emerging, comprehensive surveys to evaluate the existing approaches are found in literature [25]. However, this research undertakes a BPM approach integrated with BOOM for the first time. In addition, this paper also includes a unique illustration of how the improvement in process efficiency can be achieved by adopting the proposed framework for a generic business process within a complex fuel retailing case study. The efficacy of the proposed BOOPM approach lies in the fact that a BPI initiative using our approach can seamlessly incorporate a practical change-management for an improved design of an enterprise system. We can be assured that by embarking on such a well-structured BOOPM approach for BPI, we would be avoiding the high risks associated with the adoption of a weak systems model. The next section describes the proposed BOOPM framework.

3. Proposed Business Object Oriented Process Modelling (BOOPM) Framework

The purpose of proposing a BOOPM framework for improving the business process is to formulate a practical implementation model to enhance business performance and add value to the customer service. To achieve this, our proposed framework will adopt system modelling techniques to identify the business entities, activities and their interconnections. The framework has been adapted from existing methods (BPM and BOOM) and developed with a structured approach for users to facilitate process innovation and improvement [43,56].

The typical BOOM steps followed by a business analyst in the software development life cycle (SDLC) of an enterprise system are as follows:

Step 1:

initiation: a business case is made for the software project;

Step 2:

discovery: eliciting, analysis, and documentation of detailed requirements are done. Testing activities also occur during this step;

Step 3:

construction: the software solution is built and if an iterative lifecycle approach is being used on the project, requirements, elicitation, analysis, and documentation continue;

Step 4:

final verification and validation (V&V): the business analyst supports final testing before the completed solution is deployed, reviewing test plans and results and ensuring that all requirements are tested;

Step 5:

closeout: the business analyst supports the deployment process, reviewing transition plans and participating in a post-implementation review (PIR) to evaluate the success of change management.

In BOOPM, we propose a six-step implementation guideline that combines the above five-step BOOM within the six phases of BPM life cycle (Figure 1). The BOOPM consists of activities and techniques of the above standard BOOM approach. When they are carried out in each step, several artefacts with many graphical representations would be created that can be easily understood by the internal and external stakeholders. An overview of the six-step BOOPM framework for process improvement adapted from [20] and [43] is given in Figure 1, and the details of the activities and artefacts determined in each step are described in this section.

Table 1. Key artefacts development of BOOPM framework integrating BPM and BOOM models.

BOOPM Framework	BPM Approach	BOOM Approach	BOOPM: Key Artefacts
Step 1: Business Problem and Requirements Identification	Phase 1: Process Identification	Step 1: Initiation	Business Problem: SWOT analysis, Goals, Stakeholders, Business Use Cases, Processes
Step 2: Business Process Discovery	Phase 2: Process Discovery	Step 2: Discovery	System Use Cases (BOOM), As-Is Process Model (BPM)
Step 3: Business Process Analysis	Phase 3: Process Analysis		Class Diagrams (BOOM), Value-Added Activities (BPM)
Step 4: Business Process Redesign	Phase 4: Process Redesign	Step 3: Construction	Component Diagrams (BOOM) To-Be Process Model (BPM)
Step 5: Redesigned Business Process Implementation	Phase 5: Process Implementation	Step 4: Final Verification and Validation	Quality Test Cases (BOOM) Redesigned System Register, Cycle Time Efficiency (BPM)
Step 6: Business Process Monitoring and Evaluation	Phase 6: Process Monitoring and Controlling	Step 5: Closeout	Post Implementation Review (BOOM), KPI Performance Metrics (BPM)

provides an overview of the key artefacts developed in BOOPM framework by integrating the strengths of BPM lifecycle of workflow modelling to include the dataflow dependencies with the salient business object designs of BOOM lifecycle.

Step 1: Business Problem and Requirements Identification

This step forms the initiation or preparation phase where the process innovation team (which consists of business analysts, systems analysts and process engineers) is determined and the processes to improve are identified, defining the goals, objectives, and stakeholder expectations of their BPI initiative. The activities undertaken are:

(i)

strength-weakness-opportunity-strength (SWOT) analysis: this activity involves analysing the internal strengths and weaknesses of a business process and the external opportunities and threats that may affect the business function. The SWOT analysis provides a quick examination of a business function’s current state that can help the organisation to develop an improvement strategy for the future.

(ii)

business function requirements identification: this activity is important for determining a high-level statement of goals, objectives and needs of the business function, identifying both functional and non-functional requirements.

(iii)

developing artefacts: organisation chart, stakeholder maps, context diagram and business use case diagrams depicting the functional scenarios form the key artefacts that will be useful in this step [20]. Organisational charts can be used to identify the functional areas, roles of people and stakeholders involved, their reporting hierarchy, and the new BPI work group required to be created. A stakeholder map depicts the relationship of the stakeholders showing who is responsible for what and how different artefacts get reviewed, approved, and ready for implementation. A context diagram is a useful tool for confirming the overall scope of the business function and the system integration requirements for process analysis. Business use case diagrams can be used to establish the context to confirm the functional scope of each business process.

Step 2: Business Process Discovery

In this step, the target business process to be improved is identified. It involves defining and establishing the boundary and interfaces, as well as dependencies with other processes. A process model is developed to provide a visual picture of the process with a break-down of sub-processes. Typically, a business process consists of a number of events and activities with each task defined as a single unit of work when the activity involved is simple. In addition, decision points that affect how the process gets executed are included in the process model. A process also involves a number of actors, physical and non-physical objects. Finally, one or more outcomes of the process on execution are included in the process model. Among some of the standards used for modelling business processes, our proposed modelling framework adopts business process modelling notation (BPMN) for pictorially depicting the details of a business process flow and execution. The key elements of such a workflow modelling diagram using BPMN are objects and connections between objects that form sequence flows. Objects could be events, tasks, or gateways. Where events are used to depict the beginning or ending of a process, tasks are used to represent activities that need to be executed, and finally, gateways are used to control the sequence flows [43,57,58]. The main BPMN elements fall under the following four categories:

• flow objects, which include events, tasks and gateways (basic elements of a BPM diagram);
• connecting objects, which are mainly different types of arcs that connect various flow objects;
• swim lanes, which groups roles or organisational departments that are related; and
• artefacts, which provide information related to diagrams.

The purpose of this workflow diagram using BPMN is to form an “as-is” process model that provides a common understanding and communication among the stakeholders. In particular, it assists the business analysts, systems engineers and process engineers to collectively consider the structural data objects and their dependencies to review the different process components and reengineer them for process innovation to achieve business improvements.

Step 3: Business Process Analysis

The primary aim of this step is to review and propose changes in the functional scope of the business process and to recommend changes. The behavioural and structural analysis of the business process is conducted in this step to review the interfaces, data dependencies and boundaries of the “as-is” process model [59,60]. The stakeholder requirements are analysed using object-oriented analysis techniques and this is facilitated by developing system use cases, object diagrams and value indicators for the As-Is process model. These diagrams, including class diagrams showing classes and their associations, are used to illustrate the current situation of the process within an enterprise system. The purpose of a system use case diagram is to support the automation of business use cases. Process value analysis of the “as-is” BPMN diagram should indicate if the outcomes have actually delivered any value to the actors involved in the process. The actors in the use case diagrams should include all the internal and external stakeholders including customers and suppliers of the business process. A Value-Added Analysis is performed on how the outputs of each activity are consumed by the actors in meeting the stakeholder ‘s requirements and expectations. Those activities that satisfy the business requirements are important for the internal operations and are classified as business value-added activities. If an activity directly contributes in meeting customer expectations effectively, it is considered as a value-added activity. On the other hand, if an activity does not support the business process and does not have any effect on the outcome of the process when it is removed from the workflow, then it is considered as a non-value-added activity. In a nutshell, such a value-added analysis will result in classifying an activity into one of the three categories, namely business value-added (BVA), value-added (VA), or non-value-added (NVA) activity. Overall, this step helps to identify areas of improvement and detects inconsistencies such as invalid goals, non-conformant policies and regulations.

Step 4: Business Process Redesign

In this step, business process redesign activities include making changes to the As-Is process model to arrive at a “to-be” process model in order to facilitate the successful implementation of a process innovation program [43,61]. To enable this, the value-added analysis performed in Step 3 will help in focussing on reviewing each activity by answering questions on what is done, how it is done, where it is done and whom does it affect in formulating the business process redesign. All the NVA activities that are considered dysfunctional for the business are removed by considering the data dependencies affecting the component diagrams with the emphasis placed mainly on the process activities that are important to the business. All the issues observed in the “as-is” process model are systematically recorded in a register that forms an input towards deriving the To-Be process model. All proposed changes to the workflow of the end-to-end business processes are then depicted in the “to-be” process model diagram using BPMN [62]. If the model is large, sub-processes or call activities can be effectively used for reducing the size of a process as well as for reusability. More importantly, a sub-process can be innovated or re-designed independently when business requirements change. Therefore, by identifying all the sub-processes, the model becomes more adaptable to future changes in the system. The performance of each sub-process and the overall performance of the entire process is measured using metrics such as cycle time efficiency (CTE) that can be used to perform business process re-design. Calculating the CTE of a process requires calculating the theoretical cycle time (TCT) and the actual cycle time (CT) [50,61]. The formula for CTE is given below:

CTE = TCT/CT.

While calculating TCT, only the time spent in VA and BVA activities are considered, and NVA activities and waiting times are excluded. However, the CT includes cycle time of all activities including NVA activities and waiting time. This step facilitates a comparison of the CTE between the “as-is” process model and the “to-be” process model for justifying the change, and in proceeding with the implementation of the resigned business process model in the next step.

Step 5: Redesigned Business Process Implementation

During the innovation or re-engineering of a process, certain components or activities may stay unchanged in the redesigned “to-be” model, which implies that the implementation of those process components does not require any change. However, certain parts of the “to-be” process model require appropriate translation or adaptation in the execution of those activities. This step aims to provide organisations with key tips to enable process change implementation of the improved “to-be” process model. An implementation team is required to plan and reflect all changes according to the new system requirements. This team will develop an action plan for the implementation, including specifying roles, responsibilities, timeframes, dependencies, quality testing and performance measurements/metrics such as CTE. To facilitate this change management, appropriate communication within the organisation and customers should be developed. A number of strategies for both formal and informal communication could be adopted for implementing the redesigned enterprise system [28,37]. These changes will result in developing new policies, procedures, staffing to meet the requirements of the business process redesign to achieve operational effectiveness [50]. Much preparation including the necessary training and awareness to show how the BPI aligns with the goals and business strategy of the enterprise system is required before the actual change implementation. It is recommended to develop a set of quality test plans for launching a pilot test of the implementation of the redesigned business process in a small scale. The purpose of testing a system prototype is to perform verification and validation of the expected performance improvements. Such an action plan would give an opportunity for fine-tuning the “to-be” process model that could lead to changes in the modelling of data objects before undertaking the final implementation of the renewed enterprise system. For instance, the class diagram developed could be remodelled to incorporate the required changes.

Step 6: Business Process Monitoring and Evaluation

After the implementation of a redesigned business process, it is important to perform a post implementation review of the innovated process for continuous improvements. This step involves monitoring the performance measures calculated for the redesigned process. The purpose of performance monitoring and evaluation is to provide feedback that would help the internal and external stakeholders to learn from the actual implementation of the redesigned process. The findings gained through the monitoring and evaluation of the renewed enterprise system should be shared within the organisation to serve as a feedback into the iterative BOOPM improvement lifecycle. Performance monitoring and evaluation of a business process is an ongoing exercise to be practiced by every organisation that would aid in continuous improvement cycle for achieving process excellence. Deming’s plan, do, check, and act (PDCA) cycle could provide a well-tested practical guide in this quality-centric BPI pursuit [63,64,65].

There are several advantages of our proposed BOOPM framework as it combines the best practices of both BPM with BOOM. It can detect bottleneck activities, process incoherence and ways of improvement leading to process innovation that form the core features of BPM. It can depict business semantics as well as the data landscape of BOOM, catering to meta-data attributes such as type, width, multiplicity, default values, uniqueness, range of values, accuracy, and dependencies on other attributes. Hence, the artefacts developed using our BOOPM framework will be well understood by the business analysts, process engineers, and systems engineers so as to collectively incorporate innovative process choices while designing future enterprise systems. Hence, BOOPM can assist to bridge the gap in linguistic expressions between process-driven and data-driven modelling approaches in the BPI pursuit of an organisation.

4. Case Study- Business Process Innovation and Improvement

For the purpose of illustrating the application of BOOPM for remodeling a business process to achieve BPI, let us consider a common process found in many industries, namely the help desk customer support service, which is typically a semi-automated job tracking module of an enterprise system.

4.1. Case Study Overview

The case study considered here deals with a typical business process handled by a help desk department based on the case scenario from literature [14]. The purpose of the help-desk process is to take requests that may be problems, service, or computer access requests, and to satisfy them according to their type and priority. For the case study, the help-desk process has been adapted for a fuel retailing business such as a petrol service station company, where the customer service operations are becoming increasingly complex and rely on IT to enhance business performance [66,67]. The service stations of the company could be franchised with different owners operating different stations. However, all of them are required to follow through the same procedures with the company’s semi-automated processes and systems. For the convenience of its customers, these service stations are increasingly selling other products such as fresh food, and grocery items in addition to petroleum products. They also provide additional auto services such as car wash. Hence, there are different kinds of equipment used to provide all their services, which vary from one service station to the other. Some of the typical equipment used are petrol pumps, refrigerators, coffee-making machines, point of sale (POS) system, computers and other IT peripherals and systems. Any incident that occurs at a service station are reported to the 24/7 help-desk over phone. The help-desk process is required to address the service requests received from these clients (customers), who could be a service station employee (internal customer) or any other stakeholder of the company (external customer). The help-desk is responsible for restoring the service as quickly as possible.

4.2. Help-Desk Process

The help-desk process for our petrol service station case study has been adapted from the literature due to the similarity of the case scenario [14]. A service request could be related to an incident such as a fault in the petrol service station equipment, customers’ after-sales issues or an IT-related problem that requires the help desk department to process the incident and resolve it. Service requests need to be handled according to their type and their priority that comes with three priority levels: “critical”, “urgent” or “normal”. In the current process, a client (customer) calls the help desk or sends an e-mail in order to make a service request. The help desk is staffed with “Level-1” support staff who typically possess a junior role with less than 12 months’ experience but are capable of resolving known problems and simple requests. When the Level-1 staff does not know the resolution to a request, the request is forwarded to a more experienced “Level-2” support staff. When a Level-2 staff receives a request, he/she evaluates it and assigns a priority level to it. The job tracking system assigns the request to the same or another Level-2 staff depending on the assigned priority level and the backlog of requests. Once the request is assigned to a Level-2 staff, the request is investigated by the staff and a resolution is developed, which is sent back to the Level-1 staff. Eventually, the Level-1 staff forwards the resolution to the client who verifies the resolution. The client notifies the outcome after verifying the resolution to the Level-1 employee via an e-mail. If the client states that the request is fixed, it is marked as complete and the process ends. If the request is not fixed, it is then resent to Level-2 support for further action and goes through the process again. Requests are registered in a job tracking system, which allows the help desk staff to record the details of the request, the priority level and the name of the client who generated the request. When a request is registered, the status of the job is marked as “open”. When it is moved to Level-2 staff, it is marked as “forwarded to Level-2” and when the resolution is sent back to “Level-1”, the request is marked as “returned to Level-1”. When a service request cannot be resolved by the help desk staff, a third-party solution is sought from an outside company which serves as a contractor to complete the job. Finally, when a request is resolved, it is marked as “closed”. Every request has a unique identifier (ID) assigned by the job tracking system when it is registered, and an e-mail is sent to the client. The e-mail includes a “request reference number” (job ID), which the customer needs to quote for all queries about the request.

4.3. Problem Resolution Steps Adopted

Currently, there are four main steps followed by the help-desk process of the fuel retailing company with their semi-automatic job tracking system. When an incident is reported by a customer from a petrol service station, the following steps are undertaken by the help desk department:

• Level-1 staff manually logs the complaint and checks the request. Common problems are resolved by Level-1 staff who will guide the customer over phone to troubleshoot and close the job.
• If the problem is not resolved, Level-1 staff creates a problem ticket in the job tracking system, assigning a priority and the system automatically allocates it to an available Level-2 staff.
• Level-2 Staff assigned to the problem tries to resolve it and sends the resolution to level-1 staff. However, if the problem requires a technician to fix the problem, an external contractor is hired.
• The contractor assigned to the job visits the station to fix the problem and sets the job status when the problem is solved and the Level-2 staff forwards the resolution to Level-1 staff, who communicates it via email to the customer and closes the job.

The help desk department of the petrol service station company consists of five Level-1 and three Level-2 staff. The hourly rate of level-1 staff is $40, and level-2 staff is $60. Whenever the incident is a common problem that could be fixed remotely, such as troubleshooting with POS system, computer login or software issues, the help desk staff are able to resolve the service request successfully. However, certain problems that require a domain expert are channeled to a technician, who is hired as an external contractor, to visit the service station to diagnose and resolve the problem. Overall, the company wishes to improve their processes and enhance their efficiency in terms of customer service and optimise on the costs involved.

In many countries, petrol service stations are moving towards running most of their operations in an unmanned basis 24/7 and are required to ensure customer safety and support. Hence, a systematic approach for a business process re-engineering is warranted. The steps given in the proposed BPM framework were applied for the abovementioned case study in order to illustrate how it can lead to BPI.

4.4. Business Process Requirements and Modelling Existing Business Process: BOOPM Steps 1 & 2

The key artefacts produced in Steps 1 (business use case) and Step 2 (As-Is process model) are given in Figure 2 and Figure 3 respectively. The business use case for the service request process in a typical help desk department is developed for the case study as shown in Figure 2. The main activities are identified in the existing business process of resolving any complaint raised by customers in the case study and the “as-is” process model as a BPMN diagram is developed as given in Figure 3.

4.5. Business Process Analysis and Re-engineered Business Process Modelling: BOOPM Steps 3 & 4

In order to arrive at an improved business process, Step 3 in the proposed BPM framework was used in order perform a critical review of the “as-is” process model. The key artefacts obtained using the structural analysis (class diagram) and behavioural analysis (process value analysis) are given in Figure 4 and

Table 2. Value-added analysis of the help desk process (BOOPM Steps 3 key artefact).

Activity	Classification	Time (in minutes)
Log the service request	VA	5
Waiting to be checked	NVA	60
Check the request	BVA	10
Send resolution to customer for simple jobs	VA	5
Waiting to be evaluated	NVA	120
Evaluate the request	NVA	20
Prioritise the request	BVA	5
Find the resolution	VA	120
Write the resolution to the Level-1staff	NVA	20
Hire a contractor	VA	5
Waiting to be picked by Level-1 staff	NVA	1200
Resolution sent to customer	VA	20
Resolution verified	VA	1200
Forwarding unresolved problem	VA	2
Total cycle time = 2792 and Cycle time efficiency (CTE) = 39%

, respectively. By following the guidelines for value-added analysis given in Step 3, we classify all the activities in the help-desk process of the case study into three categories: VA, BVA and NVA as shown in Table 2. The time taken for each activity is taken as the average time as observed in reality.

For the purpose of illustration, we have made certain assumptions on the processing time and waiting time for each activity, event and task given in Table 2, and these values are based on the data provided by a real-life petrol service station company. Normally, this data would comprise of average values based on the practical real-life observations of the business process over a certain time period. For instance, suppose it is observed that for 20% of the incidents reported by customers, the complaint does not get resolved. In this situation, the incident needs to be forwarded to Level-2 again and the previous assigned priority could be reinstated. Due to this quick assignment of priority, it would only take two minutes as an average time for the Level-1 staff to forward the request to the Level-2 staff. Such data are important for calculating the overall performance of the process. Based on the guideline given in Step 4, we can now calculate the cycle time efficiency (CTE) as follows:

Cycle time efficiency (CTE) = [(VA cycle time) + (BVA cycle time)]/(Actual cycle time) = 39%.

This indicates that only 39% of the activities of the existing process are considered as value-added to the customer. Such data can help the organisation to increase their value-added percent to the customer by eliminating NVA activities or reducing waiting time present in their process and re- designed business process (“To-Be” process) is developed.

4.6. Redesigned Business Process Implementation and Monitoring: BOOPM Steps 5 & 6

As indicated in Step 5, the NVA activities are removed and a “to-be” process model developed as shown in Figure 5 is implemented and a redesigned system register is maintained. As shown in

Table 3. Redesigned System Register (BOOPM Step 5 key artefact).

Process Issues/Bottlenecks	Redesigned Process	Process Changes	Justification
High waiting time and delay in processing common incidents / client requests	Customer submits the job. is guided to choose from the list of problem types and is given online tutorials (video) to troubleshoot and fix common problems immediately	Removal of NVA. Customers submit the job via a portal that connects to the job tracking system. Only unresolved problems are automatically allocated priority based on job type and forwarded to the Help-Desk staff	Proposed changes will not require Level-1 staff and the help desk will have only Level-2 staff to investigate the incident and allocate a contractor if necessary. The waiting time will be reduced, and process efficiency will be improved
Error-prone manual tasks	Emails are not sent by staff, but the system generates messages automatically	The job tracking system automatically notifies all stakeholders of the job status	When the technician has fixed the job, the system prompts the customer to close it and all party agrees saving any ambiguity/error
Manual tasks lead to poor communication of job status	If a contractor allocation changes, the system can send reminders and update status	Staff can be notified if technicians are delayed or there is a change of allocation	Staff need not waste time in following up operations as the system can list pending jobs and all queries can be processed by the system

, the System Register keeps track of the quality testing outcomes as well as any implementation issues. Based on the changes recommended through the “to-be” model, the class diagram in Figure 2 would require remodeling to include the ‘Allot Job’ data object that was identified through the process redesign. This is an illustration of how our BOOPM framework helps the reengineered modelling to interlink both data and process, rather than deal with them separately.

Finally, by following Step 6, feedback is gained, which indicates that the waiting time required for each customer’s job request to be picked up by Level-1 and Level-2 staff was very much reduced. Similarly, certain NVA activities were removed resulting in sufficient process innovation and improvement. For instance, by removing the activity of Level-2 staff required to send the resolution back to Level-1 staff so as to communicate to the customer on the job status, there was a considerable improvement in CTE. Many such manual tasks were automated by having the job tracking system to update the status and to send email notifications automatically. By comparing the time, resources and the resulting monetary gain and service efficiency between the “as-is” process model and “to-be” process model, the organisation could make a decision in allocating more resources and enhanced enterprise systems that could lead to the desired BPI.

Table 4. Comparison between As-Is and To-Be process models (BOOPM Step 6 key artefact).

Key Criteria for BPI/KPI/Metrics	As-Is Process Model	To-Be Process Model
Requests handled by staff/day	50	40
Total cycle time/job	46.5 hours	4.23 hours
Staff pay/hour	$380 [(40 × 5) + (60 × 3)]	$300 [60 × 5]
Customer satisfaction impact	Manual and prone to errors	Automated and error free

gives a comparison of certain key criteria between “as-is” process model and “to-be” process model. Let us assume that on an average 50 new job requests are made every day, and there are five Level-1 staff, each paid $40 per hour, and three Level-2 staff, each paid $60 an hour. In the “to-be” model, it is proposed to exclude Level-1 staff since the online job-tracking system is introduced to log in a job by the customer directly from their computer connected via Internet to the enterprise system. This not only saves the processing time for Level-1 staff to get the job that is manually entered into the job tracking system, it saves money and time for the organisation.

Table 4 illustrates how the key criteria for BPI and business performance measurements/metrics could be compared before taking up the change management for adopting such a re-designed process model. Metrics such as number of requests handled by helpdesk staff per day, TCT for each job, the total staff pay per hour required to commit, etc. could help in decision making. The customer satisfaction is also impacted by how automated the processes are, level of errors encountered or waiting times experienced in the helpdesk job process. For the case study, by eliminating Level-1 staff and hiring two extra Level-2 staff in the “to-be” model, the waiting time was decreased by one-third. In addition, due to a saving of $80 in staff pay per hour, the organisation saves $120,000 ($80 × 8 hours × 5 days × 50 weeks) per year, assuming 50 working weeks per year and 8 hours per day with 5-day working weeks. The savings mentioned is based on various data including processing time, waiting time for each activity, event and task that were provided by a real-life petrol service station company for the purpose of illustration. The closer the data values are to the actual observed data from real-life, the more accurate will be the calculated savings. Since the steps in our proposed BOOPM framework are generalised, the model can be adapted to different real-life situations. In particular, it would help the management in decision making by adopting scenario analysis with best-case, average-case and worst-case data values.

Apart from increasing the products and services, petrol stations are envisaged to run on an unmanned basis 24/7. They are required to comply with health and safety requirements ensuring safety and support of all its stakeholders. Their processes need to be efficiently and continually redesigned to achieve operational success in this digital world with strong competition. Lack of process efficiency and innovation can result in business failure. Our BOOPM framework has provided a methodological and practical approach to modeling their help-desk business process and for effectively addressing the bottlenecks and issues for achieving process efficiency. Since major re-engineering of business processes may lead to organisational instability and failure, by adopting our BOOPM system lifecycle, that promotes an iterative PDCA continuous improvement methodology, organisations would benefit in their BPI initiatives from having a significantly efficient measurable business performance.

5. Conclusions and Future Work

This paper proposed a structured six-step business object-oriented process modelling framework for process innovation and improvement in enterprise systems. By combining the best practices of BPM and BOOM approaches, the proposed BOOPM framework has taken advantage of both process-centric modelling and data-centric object-oriented modelling for achieving performance improvements in an organisation’s business processes. While some existing studies have discussed generic frameworks to integrate data and process with the aid of SOA or business-driven approaches, the approach adopted in this paper is the first research of its kind exploring the integration of business object life cycle of BOOM and the BPM. The key feature of such an integrated stepwise BOOPM framework is that, firstly, an existing business process within an enterprise system could be visualised from the perspectives of business analysts, process engineers and systems engineers while developing the artefacts. The business and system use cases, the “as-is” process model, class diagrams and other artefacts generated with BPMN and UML techniques aid in achieving a common language and a better understanding of the activities, events and tasks that are in the current workflow and dataflow practice. Secondly, it helps to critically analyse these process components of the enterprise system for identifying future improvements using a systematic approach, resulting in the development of a reengineered “to-be” process model that incorporates the data dependencies as well. Thirdly, such techniques when adopted within a working team environment would facilitate in evaluating the business workflow along with dataflow considerations while integrating design principles with a focus on process innovation and continuous improvements within an enterprise system.

The adoption of the proposed BOOPM framework for a case study was demonstrated to illustrate the implementation of the six steps of the framework for achieving process innovation and improvement. A typical help-desk job process that is semi-automated within an enterprise system was adapted as the case study for a complex fuel retail business case scenario. The details of developing key artefacts of BOOPM were provided for the case study and their process efficiencies were measured and compared. The inter-dependencies of process and data were also realized while going through the BOOPM implementation steps. Overall, the adoption of the proposed BOOPM framework for BPI had clearly resulted in process efficiency, staff productivity and monetary gains for the help-desk department.

Future work entails the investigation of the iterative cycle of BOOPM in achieving continuous improvements of quality in the customer service of the organisation. Some variations in the BPMN were adopted while developing the artefacts due the interlinking of data flow and process flow, and standardisation in modelling artefacts of BOOPM could be taken up as future research. Several business performance metrics would be considered in measuring the process efficiency and a comparative study will be conducted through various iterations of the BOOPM lifecycle of the enterprise system.