Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

In effect, all information systems are implemented to support business processes within organizations. A business process management system (BPMS) (Van der Aalst et al. 2003; Weske 2007) makes that relationship explicit by providing direct technology support for process enactment, creating what are known as process-aware information systems (PAIS) (Dumas et al. 2005; Russell 2007). The broad purpose of this chapter is to make progress towards the development of an integrated step-by-step methodology for such process automation.

The potential benefits of process automation through a BPMS have been appreciated for many years (Van der Aalst et al. 2003). So far, however, no general methodology has been offered to guide their introduction and use. Dumas et al. noted this deficiency in 2005 (Dumas et al. 2005) and although various ways of enhancing PAIS development have been examined since then (Weber et al. 2009), a proposal for all-encompassing methodology has still to emerge. Instead, organizations typically piece their own methodology together, taking what can be described as a multimethodology approach. This is defined by Mingers and Gill (1997) as “combining together more than one methodology (in whole or part) within a particular intervention,” which means using a range of available paradigms, methodologies, techniques and tools, as considered appropriate in a specific problem situation (Mingers and Brockelsby 1997).

This chapter considers the research question: do we need an end-to-end methodology for PAIS development or is multimethodology use sufficient? The first section explains the BPMS approach to information system development in more detail, presenting an 8-stage framework for process automation. This is followed by a case study of multimethodology use at KTL, a telecommunications company in Ireland. The general lessons from this experience are then presented, before looking specifically at the research question. Opportunities for further research are also identified.

2 Business Process Management

The field of BPM covers “… the methods, techniques and tools to support the design, enactment, management and analysis of operational business processes” (Van der Aalst et al. 2003). A BPMS is used to automate selected processes, which have the effect of making them explicit, thereby facilitating their enactment and ensuring conformance to their specification. Van der Aalst et al. (2003) define a BPMS succinctly as “a generic software system that is driven by explicit process designs to enact and manage operational business processes.” This survey also describes the rise of BPM in terms of the evolution of information systems from a data to a process perspective in the 1990s, through to the current need to support organic growth in organizations. In practice, this means seeing BPM as an ongoing cycle of process design and refinement to achieve maximum organizational benefit. Indeed, Hammer and Champy (1993) argue that organizations should become “process enterprises,” placing processes at the core of their business operations.

Janelle Hill, research vice president at Gartner, identifies the next stage of evolution as “pushing BPM beyond its traditional focus on routine, predictable, sequential processes towards broader, cross-boundary processes that include more unstructured work” (Pettey 2010). This trend moves development further away from traditional vertical function-led information systems towards the horizontal process-aware systems that are the focus of this chapter.

The activities involved in business process automation can be summarized as an 8-stage framework (Fig. 7.1), as follows:

Fig. 7.1
figure 00071

Business process automation framework

Full size image
  1. 1.

    Understand the Business Context: appreciate the aims and activities of the organization, its current concerns, and constraints imposed by its environment.

  2. 2.

    Identify and Document Business Processes: identify all significant business processes in the organization, describing them in reasonable detail, and determining opportunities for improvement. Relevant improvement techniques include soft systems methodology (Checkland and Scholes 1999; Wilson 2001) and Lean Thinking (Womack and Jones 2003).

  3. 3.

    Select BPMS: based on an appreciation of organizational and process requirements from the first two stages and an awareness of the commercial products on offer, select a suitable business process management system to implement specific (process-aware) information systems. Current leading BPMS vendors include BizAgi, ICCM Solutions, PNMSoft, Questetra, and Whitestein (Cool Vendors in Business Process Management 2010).

  4. 4.

    Identify a Process for Implementation: from an understanding of the business processes present or needed, select a process for implementation.

  5. 5.

    Design PAIS Based on BPMS Facilities: design the PAIS based on a detailed understanding of the infrastructure and features provided by the BPMS, including allowance for any limitations that may be present.

  6. 6.

    Implement PAIS in BPMS: implement the PAIS through the BPMS, testing it to ensure technical correctness.

  7. 7.

    Refine PAIS with End Users: review the PAIS implementation with those who will use it, adjusting the design as necessary (looping back to Stage 5 or 6).

  8. 8.

    Deploy PAIS: put the PAIS into operation, providing whatever training is needed by its end users, and further refine it as necessary.

Stages 4–8 in this framework correspond to the creation of individual information systems built around selected processes. This requires the use of standard production phases for information system development, covering requirements definition, design, implementation, integration and test, installation, and final acceptance (Avison and Fitzgerald 2003). Also, such projects would typically be managed within a specific management methodology, such as PRINCE2, as discussed by Roseman (2010). Further information systems can be created in the same way (from stage 4), with the business context, business processes, and choice of BPMS (stages 1–3) also reviewed periodically.

In principle, more than one BPMS could be used within an organization, selected according to the type of process involved. In practice, however, that is currently impractical in most circumstances, for reasons of cost, and the breadth of expertise needed. So, organizations typically adopt a single BPMS, assuming it to be sufficiently flexible to cover the full range of process activities that may have to be supported. According to Hill et al. at Gartner (2007), a general BPMS must, minimally, support the following ten areas of functionality:

  1. 1.

    Process execution and state management engine: a BPM engine which has the ability to execute end-to-end business processes

  2. 2.

    Model-driven design/development environment: a (drag-and-drop) modeling environment suitable for all aspects of process design

  3. 3.

    Document and content management: the ability to manage all types of documents and records, both inside and outside the context of a process flow

  4. 4.

    User and group collaboration: the provision of design time tools to enable collaboration among development teams and runtime tools to enable collaboration in work activities and processes

  5. 5.

    Process component registry/repository: the provision of a back-end administration repository to store and manage process components

  6. 6.

    System management and administration: the tools set up to maintain system and human access

  7. 7.

    Business rule management: the ability to trigger system actions and responses based on business logic

  8. 8.

    In-line and offline simulation and optimization: the ability to test and improve processes before they go live

  9. 9.

    Business event management, business activity monitoring (BAM), and business intelligence (BI) management: employing reporting tools for governing and monitoring business operation behaviors

  10. 10.

    System connectivity: tools that enable system architects to set up services, enabling bidirectional connections to a variety of back-end business applications

At a higher level, Melenovsky and Sinur identify six critical success factors for business process management (Melenovsky and Sinur 2006): (1) strategic alignment (the linkage of processes to strategic organizational goals), (2) culture and leadership (the collective beliefs that mold process-related activities), (3) people (individuals who enhance and apply their process-related knowledge), (4) governance (transparency and accountability with regard to processes), (5) methods (approaches and techniques used to govern process outcomes), and (6) information technology (the technology utilized to support the management of business processes).

This section has presented a general framework for business process automation. The next section illustrates the framework through its application in practice. The particular research focus is on the use of different methodologies in this work.

3 Case Study

Killarney Telecommunications Ltd. (KTL) is one of Ireland’s leading infrastructure solution providers in Mobile Telecoms and Power Networks. Their core business is to build masts, rigging, and base stations for mobile phone and broadband companies. Much of this work involves projects with similar well-defined stages. For example, building each telecommunications mast follows the same series of steps, covering the following: design, construction, installation, commissioning, quality assurance, and client hand over.

In 2009, KTL had the vision of using business process automation to drive all project-related processes in the company, including integration with existing Human Resource Management and Financial Management systems. This work was undertaken in collaboration with the University of Ulster, funded by the InterTradeIreland FUSION scheme (McCabe et al. 2011). The first named author was originally employed as an Information Systems Analyst on that project.

The main organizational objectives set by the KTL directors were general concerns about process automation:

  1. 1.

    Business process automation must support the business strategy and add business value.

  2. 2.

    The selected BPMS must be able to drive processes without the need to adapt them unduly to suit the technology.

  3. 3.

    Introduction of the BPMS and implementation of each PAIS should involve full consultation with operational staff.

  4. 4.

    The PAIS for projects should handle every stage of a project-related process, including the assignment of tasks to individuals and making available all necessary documentation.

  5. 5.

    The PAIS had to be flexible to handle the variations that occur in practice and allow for staff being based locally in the office or remotely on site.

Many other requirements were also general:

  • Review individual processes to remove unnecessary activity, merge similar processes, and generally improve processes where possible.

  • Consolidate information stored in dispersed locations into a single repository.

  • Implement document management in a way that prevents multiple versions of documents circulating simultaneously.

  • Improve project-related communication and collaboration within the company.

  • Provide management and other decision makers with detailed real-time information on progress with projects.

Given the simplicity and generality of the business process automation framework outlined in Sect. 2, it seemed reasonable to assume that there would be a single overall guide to the activity involved somewhere in the literature. In practice, however, although there was general advice on the introduction and use of a BPMS, no suitable description was found at the level of detail needed to tackle the overall task systematically. Thus, instead, the project team followed common practice and used a multimethodology approach, pooling their expertise to tackle each stage of the work as effectively as possible. Having a single methodology implies integrated guidance, models and tools across every stage of the framework; a multimethodology approach means that the linkage between one or more phases is unspecified.

The activities associated with each stage of the process automation framework (Fig. 7.1), and the methodologies used in pursuing them were as follows:

  1. 1.

    Understand the Business Context: Through a workshop, all aspects of KTL’s business were examined to build an understanding of its long term aspirations, current issues, basic structure, broad need for BPM, and current use of information systems. Soft systems methodology was used to facilitate the workshop, which led to the creation of a high-level rich picture and conceptual model (McCabe et al. 2011).

  2. 2.

    Identify and Document Business Processes: Workshops also drove the process discovery phase. Techniques used included marker boards and sticky notes. After identifying KTL’s business functions, departments, and main activities, workshop participants were asked to map out the main business processes, which were subsequently modeled in MS Visio, using BPMN (business process model and notation) (OMG). Interviews were then held with individual business unit managers to assess the business requirements and expectations for PAIS development, documented as an SSADM Requirements Catalogue (Duncan et al. 1995). The analysis identified a particular need for automated document templates throughout the process path, accumulating both system-generated and user-supplied document content along the way—a feature that is not always present in BPMS platforms.

  3. 3.

    Select BPMS: The selection of the BPMS was approached very carefully (McCabe et al. 2011). Sage CRM was selected, strongly influenced by a decision to upgrade KTL’s financial system with Sage software. This required a SQL Server infrastructure, on which the two systems were subsequently installed. This architecture would later facilitate bidirectional communication between the PAIS and the financial management system.

  4. 4.

    Identify PAIS for Implementation: KTL management selected the building of telecommunications masts as the first process to implement with the BPMS. This was expected to provide most business value, but the choice conflicted with general BPM advice to start with a “low-complexity” process. The mast-building process touched every department in the company, requiring input from project coordinators, account managers, project managers, field engineers, health and safety officers, and quality assurance personnel. To reduce complexity, it was agreed that only the core structure would be supported in Release 1.0, with subprocesses, such as “invoicing,” following later. Requirements for the PAIS were also specified, again in the form of an SSADM Requirements Catalogue.

  5. 5.

    Design PAIS Based on BPMS Facilities: Meetings were held with individual business representatives to identify and document lower-level process detail. This revealed some small process variations between different client-project teams. Also, conflicts emerged. For example, the accounts department wanted tight control over spending capability, but project managers wanted more flexibility. Such issues had to be resolved as it was an essential requirement to use the same process for all projects. Functional specifications were then prepared as use cases (Stevens and Pooley 1999), chosen to support the creation of functional requirement documents. Unfortunately, these proved inaccessible to many of the end users who were expected to approve them. Instead, prototyping was used to explain what was planned. This meant that the PAIS design evolved incrementally after every meeting. One important consequence was a difficulty in keeping the use case documentation aligned with changes. This had a knock-on problem as, without supporting documentation, it was difficult to determine if an underlying workflow path was dependent on the change proposed. On reflection, at minimum, a Data Catalogue (indicating dependencies and specific workflows) and a requirements traceability matrix (ensuring change requests were aligned with original scope) should have been put in place to control the impact and scope of the requested changes.

  6. 6.

    Implement PAIS in BPMS: Implementing process support using the BPMS appeared relatively straightforward initially, aided by graphical modeling tools, online tutorials, and code samples. However, it emerged that customized BPMS concepts introduced for KTL, such as “projects” and “jobs,” were treated differently to built-in concepts. For example, standard documents could be merged but not those developed for KTL. Such issues required regular consultation with the supplier. Some issues could be resolved directly, but others required separate development through a consultancy firm. This effectively extended the development team, thereby creating additional difficulties, particularly in managing distributed changes and in handling the security risks introduced by opening access to KTL’s servers. Overall, these issues led to significant delays, pushing the project delivery timeline out by several months.

  7. 7.

    Refine PAIS: A user acceptance testing team was formed from selected staff members, representing each business function. With minimal guidance, the team followed steps equivalent to their usual manual process. Potential issues, bugs, observations, and suggestions for improvement were noted. Some staff strongly resisted considering an alternative to their current way of working, making it necessary to emphasize the benefits of the new approach and the management decision to implement it across the company. It was also found, however, that not all projects fitted the standard template that had been created, necessitating further development. Additionally, it emerged that finer access control to documents and activities was needed, which likewise required significant additional development.

  8. 8.

    Deploy PAIS: A final test team was created, involving input from the BPMS vendor, the consultancy firm that implemented additional functionality and KTL’s external IT support providers, who maintained the servers involved. Testing was performed on site over a 3-day period, covering ten areas, ranging from standard functionality and bespoke development down to hardware and system infrastructure. The main purpose of the test was to confirm that the system was ready for deployment so, as expected, very few issues emerged. User training was then conducted in-house, with each trainee simulating their daily activities within the new system. This approach proved very successful, judging by the positive feedback received and the relatively small number of queries raised subsequently. The PAIS went live in December 2010.

This section has summarized an experience of introducing and using a BPMS. It identified a range of methodologies, used as necessary, and selected according to the preferences of the development team and the needs of the end users. The next section reflects on some of the lessons learned from this experience, particularly in relation to the use of a mixed range of methodologies and the prospect of progress towards a simpler unified approach.

4 Lessons Learned

The general goal of the work described here was to find the best route between an initial vision of business process automation to having a BPMS in place that supported key processes in a way that realized significant business benefit. The study at KTL illustrated only one development route but is still sufficient to allow a number of general conclusions to be drawn:

  1. 1.

    Having a generic framework for business process automation is helpful. The 8-stage framework presented in this chapter seems general enough to argue that all of its stages need to be present and followed in the order shown. Having this model at the beginning of the KTL project would have been helpful, especially if populated with guidance on common issues that can occur at each stage. For example, in the KTL project the following advice would have been welcome: (1) all BPMS platforms have limitations so it is important to select a platform assuming further interaction and support with the supplier and/or associated BPMS consultants; (2) aim immediately for a fine-grained approach to data/document access control in process design (from server access down to individual permissions); and (3) appreciate that business change is always difficult even when supported strongly by higher level management, so make allowances for end-user resistance at every stage.

  2. 2.

    The BPMS must be selected carefully. In a BPM automation project, there is pressure to select the BPMS platform quickly as management is concerned about the costs involved and any training that is needed. However, the decision cannot be rushed, as there are many factors that need to be weighed up carefully. These include (1) the cultural fit with the BPMS vendor, as an ongoing relationship needs to be developed; (2) the technological fit with vendor as there may be potential for other projects; (3) the BPMS features and facilities available, as these can vary significantly from one product to another; and (4) overall value for money.

  3. 3.

    Start with the “big picture”. Before considering which processes to automate, it is beneficial to appreciate their wider context, and SSM was very helpful in facilitating that analysis (McCabe et al. 2011). The construction of a rich picture at KTL, for example, helped bring out wider system integration issues that had a direct impact on the project, including the identification of the imminent need for replacement of the finance system.

  4. 4.

    Start small. The process selected for initial implementation was too ambitious. It would have been more productive overall to identify something much smaller to build knowledge of the development process and gain user confidence.

  5. 5.

    Addressing end-user needs is essential. This was partially successful in the KTL project in that management and office staff were actively involved in the early-stage workshops. Unfortunately site staff (approximately 80 % of the company) were largely overlooked at that stage, and it emerged later, during acceptance testing, that they felt the system was designed to suit head office preferences. Also, during the design phase, staff had difficulty interpreting BPMN diagrams and use case definitions. Techniques need to be used that achieve the necessary input from end users in their terms but also support the more precise descriptions needed to specify and construct each PAIS around the selected BPMS. Allowance for significant design iteration is also important as many end users can only comment effectively on a working system rather than abstract models. Users also needed to better understand that some constraint over previous behavior was inevitable.

  6. 6.

    A single comprehensive methodology for business process automation is not essential but desirable. A valuable PAIS, built on a cost-effective BPMS, has been implemented successfully at KTL, without guidance from a single methodology. On reflection, however, that can largely be attributed to the combined experience of the development team and the care that was taken at each stage of the work. This meant, for example, that while it was beneficial to use SSM in the first stage of the 8-stage framework, as a way of developing a shared understanding of the business context, it was not necessary to spell out exactly how SSM would be applied and how its models would be used in subsequent phases. Nevertheless, if a full default methodology had been available, it would have raised awareness of the linkage between stages and identified possible tool support to facilitate such connections, thereby further guiding the project.

    In both software engineering and information systems development, many have argued that it is impractical to tackle all projects in the same way (Fitzgerald et al. 2003). The alternate approach, often described as “method engineering” (Bergstra et al. 1985), means tailoring each project according to the range of relevant factors involved, including the novelty of the work, the application area, and the specific experience of the developers. This implies supporting options within the framework. These might be within a single stage but more commonly, would extend across several stages. For example, in the KTL study, SSM was used in the first two stages and the SSADM Requirements Catalogue technique (Duncan et al. 1995) in stages 2 and 4. The availability of such options effectively turns the methodology into a “toolbox,” which ideally would offer as wide a choice as possible. Selected techniques may have to be adapted, however, to ensure a reasonable fit with the wider methodology in which they are used.

  7. 7.

    BPMN is a step towards standardization. The Object Management Group (OMG) defines BPMN as a process modeling notation which “creates a standardized bridge for the gap between the business process design and process implementation” (OMG). If all BPMS platforms end up using this notation, there would be an opportunity to document processes directly within the BPMS.

5 Conclusion

Since all information systems support business processes, it is possible to envisage a future in which business process automation is part of every information system created. One implication of this scenario is that guidance on process automation would then be needed in whatever information systems methodology is used. This chapter has attempted to made progress towards the development of such guidance by proposing a general 8-stage framework to encompass the range of activities involved. This covered the identification of business processes, the selection of a BPMS, and the implementation and refinement of process-aware information systems using that BPMS. It was suggested that it was desirable to integrate the eight stages, where possible, to facilitate progress from one stage to another. Such linkage would also help handle the ripple effect of change across the models produced, as business processes and PAIS systems evolve.

Before integration can be considered across the business process automation framework, however, it is first necessary to have a good understanding of the requirements and issues in implementing each stage. This can be obtained through a multimethodology approach to process automation, which involves a selection of “paradigms, methodologies, techniques, and tools” considered appropriate in each stage (Mingers and Brockelsby 1997). This chapter has described the use of this approach in a study of business process automation in a telecommunications company in Ireland.

Perhaps, the main overall conclusion from the study is that the field is still maturing, as reflected in the variation in facilities across the available BPMS products. Such variation makes it difficult to define a general integrated methodology at this stage of the evolution of the field. The use of the BPMN notation is, however, a clear step towards standardization and gives some opportunity to think about other linkages that might be developed. One possibility, for example, would a tool-supported link between SSM conceptual models (Wilson 2001) and BPMN descriptions, if SSM were used in the first two stages of the framework.

In practical terms, PAIS development is likely to require a multimethodology approach until some BPMS product begins to dominate the market, or there is consensus on the core set of facilities provided by each product. Until then, there are significant opportunities for research into all aspects of the framework, from the technical management of process and other descriptions to the subtle issues in interacting with those affected by process change to ensure that they are supportive of the change and contribute appropriately to what should be an improved way of working for everyone involved.