Keywords

1 Introduction

Business process (BP) agility is defined as the organisation’s ability to swiftly alter their BPs in response to changes in the market [1], and is important for competitiveness. Yet, BP agility is challenged by rapidly evolving technologies and business environments [2, 3]. To achieve BP agility, BP management software, also referred to as BP Management Suites (BPMS) is often combined with various information technology (IT) architectures, such as service oriented architecture (SOA) [4, 5].

BPMS solutions, packaged as a single solution, are collections of software such as graphical modelling tools, process analysis tools, orchestration engines and integration platforms [6]. Software tools earlier described as workflow, business intelligence, rules engines, or enterprise application integration tools are now integrated into BPMS products. BPMS and SOA are seen as two sides of the same coin [7]. In 2012, Gartner defined the BPMS market as one of the most rapid growing markets within the IT industry [8]. BPMS growth accelerated in 2018, attributed to cloud-native capabilities and robotic process automation [9].

Agile BPs have become important in financial services due to regulations relating to financial institutions being extremely dynamic [10], and lessons from the financial crisis of 2008. In this crisis many financial service organisations were unable to react swiftly [11]. Banks changed quickly from having sufficient cash reserves to being desperately in need of financial support from their governments [11].

While achieving BP agility is the primary goal of implementing and using a BPMS, achieving agile BPs is not guaranteed. In certain instances, organisations struggle to attain the level of agility they set out to achieve. It is for this reason that the adoption and use of BPMS needs to be better understood. Recker and Reijers at the BPM 2019 conference noted that there is a lack of empirical qualitative BP case studies and they stated that “we need to identify issues organizations are facing” [12]. The BPM literature has also been labelled as theoretically weak [13]. This study hoped to address these concerns and set out to answer the research question “How do organisational factors affect successful adoption and usage of a BPMS in a South African financial service organisation?” To answer the question, this paper first reviews the relevant literature on BPMS adoption and use. The case study research approach is described and the financial services organization and its BPMS project is then described. The factors which were found to affect successful BPMS adoption and use in the case are described and discussed, and an explanatory model is presented before the paper concludes.

2 Literature Review

Innovation adoption is defined as the decision of an individual or organization to use an innovation. Hence, organisational adoption of a technology, includes but is much broader than individual technology adoption [14]. Usage of the technology follows the adoption decision. There has been a call from researchers for a more holistic approach to studying adoption which is shown in the call for papers of the ECIS 2019 IS innovation and adoption track [15]. The predominant research approach focuses on variables that contribute to individual adoption and is said to distance researchers from practitioners [15]. A more holistic approach is the Alter systems theory of IT innovation, adoption and adaption [16], referred to as the work system approach.

A work system is seen as a natural unit of analyzing the adoption of socio-technical systems in organisations [15] and comprises four elements: processes and activities; participants; information; and technology. Furthermore, the work system needs to be considered in terms of the products and services it produces; the customers it serves; the organizational environment, strategies and infrastructure. Alter notes that often organizational IT is mandated, but there are post-adoption environments where employees might not comply with prescribed business processes and/or IT usage patterns. It is also noted that this area of research although highly relevant is under-researched. A systems approach sees the entity being adopted as not the technology but the information system or work system which comprises the people, processes and information, in addition to the technology [15, 16]. Hence when looking at successful BPMS adoption and use, one needs to look more broader, in terms of adoption and use of the relevant BP management (BPM) practices and processes that support adoption and use of the BPMS technology.

BPM is defined as management practice integrating technology and BP knowledge and harnessing BPs as exploitable assets [17]. BPM practice incorporates many prior approaches to BP change [7]. Earlier BPM research in South African financial services categorised the enablers of BPM as strategic, cultural, people, IT and methodological [18]. More recently, the six core elements of BPM have been identified as strategic alignment, governance, methods, IT, people, and culture [19].

Another relevant model in this context is the Lyytinen and Newman, socio-technical change model which is used to describe when a new technical system is designed, adopted and modified. The socio-technical model has four components: technology, which includes development tools and the technical platform; structure, which includes the project organization and institutional arrangements; actors, including users, managers and designers; and tasks [20]. The alignment of the elements from these three models is shown in Table 1. We chose the Core BPM element model as a classification framework for this study’s findings. Firstly, as it is more comprehensive than the socio-technical change model, secondly, because we didn’t believe information, products and services will dominate in BPMS adoption, and finally because it is specialized for the BPM context. Hence, we argue that the core BPM elements are important not only for BPM but also for BPMS adoption and use.

Table 1. Mapping Core BPM, work system framework and socio-technical change elements.
Full size table

The core BPM elements have been confirmed in some empirical studies. For example, one study noted that to achieve effective BPM solution implementation, the following needs to be achieved: the organisation should have adequate IT infrastructure to support a process orientated architecture; individuals within the organisation should have a comprehensive understanding of process orientated frameworks; and the organisation should have an effective change management process regarding software changes [21]. Successful BPM has been found to depend on employees’ attitudes towards embracing BP change [22], people change management can be extremely challenging [23] and BPM projects frequently fail due to cultural issues [24]. It is also suggested that IT capabilities need to ensure BP efficiency as opposed to rudimentary BP automation [25]. Ensuring that the appropriate tools and IT infrastructure is in place for BPM has also been seen to be critical [17, 26]. While adopting a BPMS is intended to produce agile BPs, it needs to be acknowledged that IT can be both an enabler and a disabler for business agility [3]. Factors that contribute to inflexible IT solutions include: insufficient capacity and project priorities of IT staff members, traditional architectures and the complexity of integrating with legacy applications within the organization, and poor interfacing capabilities of legacy applications [3].

3 Research Method and Case Description

This study presents an interpretive descriptive case study. The unit of analysis was the adoption and usage of a BPMS by a BPM team within the IT cluster of a financial institution, which we will refer to as BigFin. The team is responsible for providing support for the BPMS and engaging in IT projects that involve enhancements to the tool. Prior to collecting data, organizational permission was secured as well as ethics approval from the University’s ethics committee. One of the researchers was working for the BigFin IT cluster at the time of the study but not in the BPM team. The interview protocol developed asked open ended questions loosely based on the different elements of a work system, namely strategy, infrastructure, environment, processes, participants, information and technology.

Eight semi structured interviews, each approximately forty-five minutes long, were conducted, and three BigFin documents (D1–D3) were secured. A judgement sample strategy, where the most knowledgeable individuals that can add the most value are chosen to be interviewed [27], was employed. The interviewees were from the BPM IT team (coded as I1–I4) as well as IT architecture teams (coded as A1–A4). The interviews were transcribed, and then thematic analysis was performed on the documents and interview data using NVivo. Table 2 lists all 11 data sources. To ensure anonymity of BigFin and interviewees, the relevant codes are not listed in the table and the BPMS software is simply referred to as the BPMS.

Table 2. List of interviews and documents analysed.
Full size table

Data was analysed using as soon as collected and prior to conducting further interviews. This allowed questions to be amended based on the themes that emerged. As data was iteratively analysed, new themes emerged. The Attride-Stirling [28] six step inductive method of thematic analysis was followed: 1) Coding the text; 2) Identifying themes; 3) Developing the thematic network; 4) Describing and exploring the network; 5) Summarising the network; 6) Interpreting patterns emerging from the data. The core BPM element framework was used during thematic analysis as a lens to classify the themes that emerged from the case study. The thematic network and themes are presented in the findings section.

BigFin is a well-established organisation operating in the investment and insurance industry, listed on various stock exchanges and a constituent of the Financial Times Stock Exchange (FTSE) 100 index. BigFin was selected as it has an established BPM IT team supporting a BPMS. As BigFin was established many decades ago it has a very large legacy IT estate. BigFin consists of various business units with their own strategies, budgets and visions and has multiple projects that run concurrently. The BPMS was first implemented during 2014 with the assistance of the vendor, and was implemented on Microsoft .NET and Microsoft SQL platforms using the native interfaces of the BPMS tool. This allows multiple integration points to other applications within BigFin via the SOA layer. An architectural review noted that the BPMS has the capabilities to be used as a strategic solution within BigFin to improve BP agility, scale their infrastructure and accommodate high user concurrency (D3). Management believed that the BPMS is a vital enabler for attaining a more client centric and process-oriented approach to business (D2). Improved reporting, segregation of duties and a clear audit trail were also cited benefits (D2). The main purpose of the BPMS was to model business processes, automate process steps, integrate with applications and manage workflow, mainly for enterprise wide processes (D3). The BPMS was also expected to improve BigFin’s BPM maturity.

4 Findings and Discussion

The main aim of this research is to explain factors that affect the successful adoption and use of the BPMS by the IT team. As the intent of the BPMS implementation was to improve BP agility, we defined successful adoption and use as achieving BP agility. However, it became apparent that agile BPs were not achieved at BigFin. The relevant themes will now be discussed and this will be followed by the thematic network and explanatory model.

4.1 Strategic Alignment

Strategy can apply to the organisation, the department and the work system itself. The work system framework stresses the importance of these being aligned [29]. The work system strategies should support departmental strategies and ultimately organisational strategies. Three strategic alignment themes emerged.

BPM and Business as Usual are not Strategic Priorities.

Strategic priorities of BigFin were impacting budget allocation. I1 highlighted that legislative requirements in BigFin take the highest priority, followed by strategic projects and then business as usual and other BPM IT projects. D1 and D2 noted that key resources are utilised by strategic projects, leaving few resources available for BPM migration projects. I4 noted that the current strategic priority is delivering a new product into the market which is at the expense of setting up a BPM centre of excellence that would govern processes implemented on the BPMS. I2 reiterated this as he stated, “One of the challenges is when we have these strategic initiatives the business as usual improvements and agility fall by the wayside.”

Legacy System Strategy Misaligned with BPM Strategy.

It was noted that the strategy for legacy systems was misaligned with the BPM strategy. A2 noted that the strategy clearly defines the core IT architectures that BigFin requires to become an agile enterprise. This entails defining where the enterprise is now, what the roadmap is to their desired strategy outcome and what the potential hurdles are from achieving the desired outcome. These hurdles come in the form of licences for software products the BPMS integrates with which have been bought for a defined period. As a result, decisions have been made by senior management to utilize these software products until the licences expire as they have already been paid for. This creates obstacles to achieving agility within business processes as alternative solutions cannot be implemented until software licences have expired.

Lack of BPM Strategic Vision.

Lack of BPM strategic vision was identified by three of the interviewees as a factor contributing to the lack of BP agility. I3 noted that there was no central directive within BigFin regarding the BPM strategy although a BPM centre of excellence would assist in formalising the BPM vision within BigFin to provide efficient and effective BPM which would support BP agility. Organisations that implement a BPM centre of excellence offer consistent and cost-effective BPM services and can adopt a project portfolio management approach to BPM enabling IT teams to implement agile BPs [30].

4.2 Governance and Culture

Governance and Culture concerns impacting BPM include support obtained from top management, the culture that exists within the organisation and various complexities at different levels of management [31]. BPM Governance elements include BP standards, BP roles and responsibility, BP objectives, control methods, assessment methods, governance structures, architecture, and infrastructure [32] and BPM culture has been defined as collective values and beliefs that shape BP attitudes and behaviour to improve BPs [19]. Four governance and culture themes emerged.

Legacy and Standardization Decisions Made by Management.

These decisions refer to organisational decisions made by top management regarding the BPMS, two types of decisions were hampering the use of the BPMS; firstly, choosing to retain legacy applications, and secondly, choosing niche processes. Decisions regarding the decommissioning of legacy workflow applications by BigFin was found to impact the rate of change of BPM solutions as they had too many applications. I1 stated “This is the problem with this organisation, we don’t decommission old legacy stuff and we keep incurring the respective costs.” Literature notes that organisations are unclear regarding the correct time to implement a solution, modify it or stop using it altogether [33]. With respect to niche processes, A4 explained that one business unit had five different product lines but seventy-eight different implementations on the BPMS because every time a new line of business or a new type of customer came on board, they developed niche for that scenario. These decisions were seen to be driven by a lack of alignment between the BPM and legacy system strategies.

Misalignment Between Business and BPM IT Teams.

The participants of the interview process addressed issues such as overdesign of solutions, silos within BigFin that operate in isolation and business units not willing to change the way they conduct their business processes. Alter highlights that all components within a work system should be aligned [29]. A1 noted that there was misalignment between the different development teams and business in terms of what they were expected to deliver. Change on the business unit side of the process resulted in IT staff having to work differently and think differently and, in this case, there was a lack of process thinking in the IT teams. I2 reiterated this by stating, “Arguably the biggest challenge is the business change in thinking. Don’t just own your users’ tasks, own a process end to end.” Not having a BPM centre of excellence or process architects that govern process design and implementation was another factor that contributed to the misalignment between business teams and BPM IT teams. It seemed that this lack of alignment was being driven by the lack of a central BPM strategy and BPM not being a strategic priority.

Budget Allocation for BPM Business As Usual Initiatives.

While BigFin appeared to support strategic projects well, it was noted that as soon as a project shifts from the build phase into the support or business as usual phase after implementation, the funding for that solution is no longer available. A2 note that, “The problem within BigFin is when a project is in a project phase there is money available but as soon as it flips over to the BAU phase there’s no money. What that means is that just enough money is supplied to the project to keep it running. There is no additional funding supplied to grow it. So that is probably the single biggest challenge that we have.” As no additional funding is suppled for continuous process improvement, agility within business processes are sacrificed. Hence while the BPM IT team sees the potential benefits that solution changes will provide, they cannot implement them as no funds are available. The budget allocation was clearly being impacted by the lack of a central BPM strategy and BPM not being a strategic priority.

Business is Resistant to Change.

A4 noted that a core impediment to BP agility is individuals’ attitudes towards change. This can be summarised by the culture that exists within BigFin. D2 validated this by reporting that the lack of a change mind-set in business units is an inhibiting factor for process change. A4 further highlighted that as individuals become familiar with BPs, they become resistant to change within those processes. Resistance to change can be overcome strategically and an organisational culture can be developed to be supportive of BPM [34]. In the absence of a BPM strategic vision this culture of change resistance persisted.

4.3 Information Technology

Under IT impacts one dominant theme emerged and that was the lack of agility due to integrating with legacy and external software applications. Integration is the predominant theme that emerged as it was addressed by seven of the eight interviewees. Integration complexities range from interactions with legacy applications which can’t be changed or have incomplete data, the tightly coupled nature of the legacy application integration and complexities regarding integration outside BigFin’s secure network. Changes to applications or web services that are consumed by the BPMS impact the time to deliver a process implemented on the BPMS. D3 confirmed that the BPMS solution has multiple integration points via BigFin’s web service integration layer. If a change is required for a web service that is consumed by several other applications, extensive impact analysis needs to be performed in order to determine if the required change for the BPM project poses a risk to the other applications. I4 referred to the increase in required analysis, design, governance and testing when altering processes integrated with other applications. A3 stated that a problem with integrating with legacy applications is that some of them do not have REST and SOAP capabilities. They only offer point to point tight integration which creates tightly coupled solutions. The literature confirms that with tightly coupled IT solutions that integrate business processes across various disparate software applications even the smallest of changes become time consuming with a degree of risk [35]. “Being so highly integrated sometimes I worry it is not necessarily enabling us to change quickly” (I4).

Integration is also impacted by data incompleteness and an inability to change legacy applications and security concerns with external applications. A1 highlighted that data governance was limited when many legacy applications were developed which impacts the accuracy and completeness of the data. This has agility implications if certain data validations need to be introduced within a process. I2 noted BigFin’s resistance to invest funds in aging legacy applications which the BPMS integrated with impacted use of the BPMS and diminished process agility as legacy solutions will not be changed. A3 noted that when integrating with applications outside of BigFin’s secure network, various considerations need to be made in terms of establishing secure communication channels and if an external party changes the application, the process of implementing secure integration channels needs to be repeated.

4.4 People

The BP people category refers to the individuals and groups that improve BPs [19]. The dominant theme was found to be resourcing constraints for BPM initiatives. Resourcing constraints in this study refers to the limited time that IT staff from application teams, the BPM IT team and architecture teams can spend on the BPM projects and the inability to staff the BPM IT team. This is an area of concern within BigFin as five out of the eight interviewees raised staff resourcing as a challenge for the BPM IT team.

The BigFin BPM IT team appeared to be constantly understaffed. I2 confirmed that finding high calibre resources that are technically capable and who possess the business understanding proved to be a challenge for the BPM IT team. A2 noted that developers do not find BPM development appealing as the skill is perceived to be a niche technology skill not broadly utilized. These developers would rather work on pure object orientated languages like java or C#.

Key resources within the BPM IT team face similar situations in terms of resource constraints. Training and on-boarding of new staff is fundamental to ensure knowledge sharing and continuity when key resources leave. I4 stated that senior staff members are responsible for all new staff on-boarding within the BPM IT team and are also responsible for all BPMS design documentation and their review. because of high staff turnover, they have very little time to maintain existing processes to ensure agility is retained.

A3 also indicated that it is extremely difficult to deliver BPM processes in an integrated environment without constant interaction with the various application teams. These interactions involve consulting with the various teams to ensure they are aware of how to integrate with the BPMS. These consultations are not just from a technical perspective but also relate to standards and governance. This is a further resource drain on the IT resources within the BPM IT team. The resource constraints of other teams ultimately affect delivery for the BPM IT team. I4 highlighted that project and hence resourcing priorities of the IT teams that support applications that integrate with the BPMS may not be aligned and therefore BP change cannot be implemented until resources are allocated.

People are known to be assigned to roles and project teams based on manager’s experience of people, their availability and the required skills [36]. Often projects tend to draw on a common resource pool within the organisation [37]. As large organisations run multiple projects concurrently, obtaining time from the most valuable resources is challenging. A2 noted that he is often one of the resources whose time is debated over. He is allocated to BigFin’s number one strategic project where he needs to provide input in terms of the overall program architecture. However, there are also other strategic projects that require his attention. As a result, he does not have much time to spend with the BPM IT team or on continuous process improvement hence BPMS usage suffers.

4.5 Methods

The BPM method category refers to methods specific to the BP lifecycle [19]. Two themes emerged under the method category.

Lengthy Project Initiation Processes.

Five of the eight interviewees referred to lengthy project initiation procedures for BPM projects. A2 referred to business architecture and enterprise architecture documentation required prior to project sign-off and the involvement of business analysts and solution architects for requirements gathering and solution design. Project initiation documentation ensures that the BP change is appropriately scoped and that resource availability is considered. Literature highlights the importance of the project initiation phase to define the problem and opportunities and reduce the risk of project failure and acknowledges that this can be lengthy [38].

Bypassing Design and Code Approval Procedures.

In addition to the pre-project initiation processes, approval is needed for the artefacts that are produced. It appeared that these approval procedures were being bypassed and this concern was referred to the most by interviewees (14 mentions). I1 stated that problems arise when developers or project managers try and rush projects into the production environments by trying to bypass sign-off procedures resulting in inflexible and niche BPs. It seemed that the desire for niche BPs in many cases was driven by the culture which was resistant to change. Sign-off processes could also have been implemented more efficiently if proper governance had been completed. Pre-production approval processes come in the form of security sign-off and code review sign-off and ensure that final approval is obtained from a design, technology, quality assurance, architecture, risk and security perspective. Although these processes are necessary for implementing efficient and agile BPs in the long term, the interviewees noted that these processes also hamper quick delivery of BP changes in the short term.

4.6 Model of Factors Impacting Successful BPMS Adoption and Use

This research aimed to identify factors that affect the successful adoption and use of the BPMS by the IT team and success was defined as achieving BP agility. While the BPMS was adopted and in use, agile BPs were not achieved at BigFin. Hence as the interviews progressed, it was noted that the major factors identified were all negatively impacting success. The eleven dominant factors are presented in Table 3 and the interlinked factors are shown in Fig. 1.

Table 3. BPM themes with Sources (S) and References (R).
Full size table
Fig. 1.
figure 1

Explanatory model of factors negatively impacting successful BPMS adoption and use.

Full size image

The sources column represents the number of interviewees that made statements related to each theme and the references column represents the numbers of statements made by the interviewees. While the respondents referred to concerns with the BPMS work system itself (its methods, technology and participants), these concerns were being driven by governance and cultural concerns and these in turn were driven by strategic alignment concerns. Together these factors negatively impacted successful BPMS adoption and use and BP agility.

While the organisation wanted to improve their BPM maturity, they did not have a BPM strategic vision and the “business as usual” nature of process improvement and BPM were not seen as strategic priorities. This resulted in misalignment between business and IT teams and insufficient budget allocation for BPM. Both factors drove resourcing constraints for BPM initiatives.

The organisation had a large legacy estate and this impacted the lack of agility because of technical integration implications and because of governance decisions made regarding changing legacy applications. These in turn were driven by their legacy system strategy being misaligned with the BPM strategy for agility. Software development methods had been put in place to ensure long term BP agility but these resulted in slowing software development in the short term. This and the reluctance of business to change and standardise resulted in bypassing some of these methods. Without a BPM strategic vision, the culture of the organisation could not be changed.

Considering the factors negatively impacting BPMS adoption and use at BigFin allowed us to propose a tentative explanatory model which the organisation could follow to improve BPMS adoption and use. This more generalisable model is presented as a framework in Fig. 2. While the Rosemann and vom Brocke core BPM model lists the components needed for BPM success this model provides an explanatory contribution to understanding improved BPMS success. The model notes that a clear BPM vision is needed and it needs to be aligned with the organisation’s legacy application strategy. This is needed to enable better budget and resource alignment for BPM; a BPM culture [19]; appropriate BPM governance structures and BPM aligned legacy and standardization decisions. These four factors, in turn, will influence an improved BPMS work system.

Fig. 2.
figure 2

Framework for successful BPMS adoption and use.

Full size image

5 Conclusion

While organisations adopt BPMS and SOA technology primarily to achieve BP agility, in many cases this agility is not achieved. There has been a call by BP researchers for studies highlighting issues organisations are facing. Hence this research took a systems approach to looking at the adoption and use of a BPMS in a South African financial services organisation that was struggling to achieve BP agility. The systems approach to technology adoption sees technology adoption as a work system change. Hence a BPMS is seen as merely a technology in the BPMS work system trying to achieve agile business processes for the organisation’s customers. Researchers Rosemann and vom Brocke have identified the six core elements of BPM and their framework was used as a lens in classifying the factors found impacting successful BPMS adoption and use in the organisation studied.

This case study described the frustrations the IT team was facing using the BPMS solution. While standalone applications can be implemented quickly, as soon as integration with other applications increases, the level of agility within those process was found to decrease. The inherent integrative nature of the BPMS solution and rigid nature of integration with legacy applications made changing applications very time consuming. Having insufficient resources and a user base that did not want to standardise or change processes increased their frustrations. A work system’s view of the factors impacting this frustration is shown in Fig. 2 and these also pointed to a generic explanatory model. Implementing a BPMS without considering the strategic priorities and alignment as well as governance and culture will result in frustration and a lack of agility. Hence the usefulness of this framework to practitioners considering implementing a BPMS.

While this framework offers an explanatory model of how some factors negatively impact successful BPMS adoption and use, it does have limitations. Firstly, the model is not complete, interviewees were working in the IT function and a richer picture and more factors could have been obtained if employees from business functions were interviewed. Secondly, the study was cross sectional and a longitudinal study looking at the stages the organisation went through would be much richer. Thirdly, in terms of context generalisation, the case organisation was in financial services and therefore was risk averse and had a large legacy estate. Hence the framework has a focus on considering legacy applications and their strategy and a younger or more risk tolerant organisation with more modern applications will experience less frustration and hence parts of the model might not be relevant. Also, this model might not include factors important to an organisation which has other complexities or contextual factors.

Therefore, we note that this model is incomplete and contextual and further studies, particularly longitudinal studies, with other organisations and a broader user base will be able to further refine it. The framework could also be tested quantitatively to confirm the importance of the relevant factors.