A Case Study of Workflow Implementation Success Factors. Alison Parkes Department of Accounting and Business Information Systems University of Melbourne Melbourne, Australia Email:
[email protected]
Abstract This paper explores factors related to the successful implementation of workflow systems. The paper includes a wide ranging literature review which identifies potential success factors. In addition to workflow specific material, literature is drawn from areas as diverse as technology enablement, change management, process reengineering and modelling and political social and organisational aspects. Case study observations related to these success factors are recounted in a semi- structured discourse, and impacts on the workflow project under observation are appraised.
Keywords Workflow; technology; implementation; success factors; case study.
1
Introduction
Workflow systems are systems that support business and information processes (Georgakopolous et al. 1995). At a basic level, a workflow management system is a system that manages workflows. A workflow is “the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. A workflow management system “defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. (Allen 2001). Workflow systems are potentially a valuable technology as they provide a means to automate and support processes in organisations. Integrated technology is required to manage collaborative processes, and technologies such as workflow management systems support this need (Georgakopoulos et al, 1995). Workflow systems can replace current paper-based flows and information stores with an electronic version, whilst allowing future flexibility to support changes in the business environment. While workflow software has the potential to considerably improve the operational efficiency of processes, and the management of those processes (Chaffey 1998; Joosten and Brinkkemper 1995; Kobielus 1997), many of these benefits are not currently being realized (Ader 1998; Trammell 1996). Appropriate use of workflow technology should provide a competitive advantage for organisations, or at the very least provide the ability to remain level with competitors. Workflow has a potential to positively transform the workplace, however the impacts of its use need to be fully explored and considered prior to implementation. Literature relating to success rates for technology projects indicates a high failure rate (Clegg et al. 1997). Workflow systems appear to encounter a slighter higher level of risk than other types of projects, if the high failure rates for process reengineering projects (Hammer and Champy 1993) are also taken into account. As workflow systems always involve some form of process reengineering the risks attached to the implementation of these systems are correspondingly higher. Workflow changes the way organisations and individuals conduct their business. The actual creation of the technology is fairly well understood and documented; the successful implementation of workflow is however a different aspect. The technical task of developing and building workflow systems is usually completed successfully. The problems that arise often occur during implementation, and seem to relate more to human factors than technological factors. Failure to successfully implement workflow systems can not only cause a loss of the resources and time invested, but also limit the ability of organisations to remain competitive. This case study is about understanding the successful implementation of workflow systems; it seeks to create a set of success factors related to workflow implementations. The research is primarily focused on events that occur during the process of implementation using the broader management interpretation of the term implementation, rather than the technical interpretation which is largely concerned with product creation. Contact was established with an organization that was undertaking a trial implementation of a workflow process and the researcher had an opportunity to observe onsite the implementation of a workflow system. This paper identifies a number of potential success factors, and then describes the experience and observations of the researcher related to those factors.
2 2.1
Literature Review Workflow Literature
Proposed workflow success factors include the principles adopted for implementation; top management commitment, proper organisational analysis and role definition, choice of flexible and adaptable technologies and the use of technologies which support an open information architecture (Antonucci 1997). Chaffey (1998) divides workflow implementation into technical and non-technical factors. The technical factors he identifies as important are planning, documentation, training, and systems testing. Non-technical factors are group working and group behaviour, change management, choice of prototyping options and systems development methods. Chaffey identifies five problems likely to occur: forgetting that people are involved, using Rapid Application Development (RAD) techniques inappropriately, having inadequate computer resources, poor project management and lack of top management support. Kobielus (1997) describes the importance of project planning and definition of operational procedures for both administrative and technical staff when implementing workflow, along with human factors such as perceived loss of flexibility and interpersonal give-and-take, fear of ensuing job losses, the need to relearn electronic versions of forms and resistance to an automated process developed by a remote corporate authority. He suggests
that a blend of one part management guru, one part coalition builder, one part business analyst, one part project manager and one part systems integrator is required to successfully implement workflow. Trammel (1996) notes that a unique fact about workflow products is their need to support multiple platforms, locations and applications while eliminating human interaction. The remaining literatures reviewed are single site case studies which help to illustrate the complex nature of workflow implementation. Resistance to change can be quite significant and much of this resistance seems to centre on the replacement of traditional face-to-face interactions with an on-line version (Cummings 1996). The process of designing workflows that take advantage of new capabilities can prove problematic (Lucas et al. 1996), as can the time required for executives to fully understand the systems potential (Harkness et al. 1996). In addition the ability to share information is critical for success of the project (Loebbecke and Jelassi 1997). This literature identifies a range of success factors including resistance to change, design of workflow processes, and acceptance of and support for a process focus. Workflow literature describes workflow implementation as a socio-technical endeavour, with some unique factors creating a higher risk of an unsuccessful implementation. The scope of the literature review was broadened out from the initial workflow focus to include a number of related areas: change management, process reengineering, process modelling, IT enablement, and the social, organisational, and political aspects of technology implementation. The literature reviewed provides support for the idea that implementation of workflow is a complex socio-technical undertaking. The factors identified in this literature review were used to guide the researcher in the observations made on site during the case study data gathering. These factors are discussed in the next section of this paper. 2.2 2.2.1
Related Literature Process Modelling
One of the key requirements for workflow implementation is creation of a process model to specify workflow requirements. An issue that emerges here is the question of which modelling techniques to adopt, and whether there is a suitable model to fit all stakeholder needs. Issues identified include incorporation of domain knowledge (Shaft and Vessey 1998), specification of workflows and business processes (Bajaj and Ram 1996; Conrath and De Antonellis 1992; Datta 1998; Reddy and Tagg 1998; van der Aalst 1998), process delineation (Murphy and Staples 1998) and technology skew (Davenport and Short 1990). 2.2.2
Change Management
One of the factors underlying implementation of workflow is change. By its nature, workflow creates change in the organisational environment, which affects both individuals and the organization itself. It is important to appropriately manage this change, however change management is an area often neglected in IT project management generally. The implications of poor change management in workflow implementation are even more severe, as workflow fundamentally alters the way tasks are conducted and managed. The more radical the change contemplated, the more change management is necessary. A large body of literature relating to change management is in the sub-area of technology related change. The issues examined were chosen either because of their well documented significance i.e. management commitment (Broadbent and Butler 1995; Butler 1996; Clarke and Garside 1997), need for explicit planning (Markus and Benjamin 1997; Orlikowski and Hofman 1997) and communication (Clarke and Garside 1997), or their seeming close alignment with previously identified workflow issues, i.e. mode of change (Cooper and Markus 1995; Scott 1999), level of change (Stoddard and Jarvenpaa 1995) and power redistribution (Buchanan and Huczynski 1997; Thach and Woodman 1994). 2.2.3
Political Aspects
Major change or restructure in an organization like that engendered by a workflow implementation often leads to behaviour that is commonly called ‘political’, or ‘playing politics’. Mintzberg (1985) discusses the organisation as a political arena, and defines a political arena as one that is significantly captured by conflict and politics. He notes that political behaviour is one of many sources of influence in an organisation, albeit an important one. Ferris et al (1996) defines political behaviour as being concerned with behaviour that is self-serving and not sanctioned by the organisation, causing conflict or disharmony between groups or individuals. Christiansen et al (1997) similarly defined political behaviour as an attempt to influence others that is perceived to be self-serving in nature. The importance of political aspects should not be understated (Willcocks & Smith, 1995). The cross boundary implementation of new processes is fraught with political problems, which need to be explicitly managed. Failure to identify and appropriately manage political issues can lead to those issues sidetracking the true purpose of the project. This review examined four issues that relate to workflow implementation: participation (Clegg et al. 1997; Hornby et al. 1992; Mumford 1993), competition for resources (Drory and Romm 1990), group interactions (Chaffey 1998), and feelings of loss of control (Boersma 1994).
2.2.4
Organisational Impacts
Successful introduction of IT often requires redesign of organisational structures (Orman 1999). In the case of workflow systems, this issue is particularly pertinent, due to the propensity of workflow and process reengineering to impact on job design. Primary issues considered relevant are organisational structure re-design (Bhattacherjee and Hirschheim 1997), centralization (Chaffey 1998; Kobielus 1997; Orman 1999), devolution of power (Blackler 1992), and corporate memory retention (Kock and McQueen 1996). 2.2.5
Process reengineering
Many of the process reengineering ideas originate from work by Hammer (1990) which challenged the long held view of appropriate business forms and functions dating back to Taylor’s' efficiency ideas from the early 1900s. Hammers’ argument was that the traditional way of managing business by function was no longer useful, and that in order to survive and prosper a function-oriented focus was required. It was suggested that correctly engineering, or reengineering, these processes, was a key competitive advantage. Process reengineering addresses the issue of how a business should design its processes. In order to create sustainable competitive advantage it is necessary to institutionalize the processes. Until recently business processes were recorded and distributed on paper, often in the form of procedural manuals, or policy guidelines. These are often ignored or misused, or simply not distributed appropriately. To ensure appropriate distribution of process instructions, and compliance with requirements, a technology enabler such as workflow is crucial. Workflow issues relating to process reengineering include the techniques adopted (Butler 1996; Kettinger et al. 1997), the interrelationship between process reengineering and workflow (Hammer and Champy 1993; Marshak 1997; Sillince and Harindranath 1998), and the availability of suitably skilled resources (Grover et al. 1995; Murphy and Staples 1998). 2.2.6
IT enablement
Workflow plays a significant role in implementing process reengineering. The ability to automate, monitor, analyse, and coordinate is crucial. Research conducted by Grover et al (1994) indicate that process reengineering projects appropriately enabled by IT have a far greater chance of success, however they also carry greater risks, they are exposed to risk factors relating to both process reengineering and technology implementation, as well as emergent risks from the combination of these two areas. Workflow requires a technological platform characterised by standardized architecture, extensive communications capabilities and shared database access. An inadequate IT platform will constrain the workflow effort. Martinez (1995) asserts that the failure to engage IS as a true partner, and allow appropriate leadership by IS, is the cause of failure for many process reengineering projects. Martinez notes that failure to involve IS in the process project team increases the risk of overlooking creative technical solutions, and ignoring project management techniques. Migration strategies may be also absent, with non-IS developed solutions being not implemented due to technical flaws. This is not oneway however, Martinez also noted that focus on the technical issues by IS staff could result in technology architectures incapable of supporting and managing the enhanced processes. Martinez concluded that successful process redesign and implementation requires a working partnership between IS and business units. Primary issues identified from this literature are: availability of a suitable IT infrastructure (Butler 1993; Lancaster 1994; Stoddard and Jarvenpaa 1995), process management information availability (Davenport and Beers 1995), and the role of technology as a catalyst/enabler/implementer (Davenport and Stoddard 1994). 2.2.7
Social impact
Clegg (1997) points out that over 80% of IT investments do not meet their performance objectives, largely for non-technical reasons. The failure rate is increasing as technologies become more complex and pervasive, also the scope of change and the speed at which is occurs are increasing. Inability to recognise and appropriately manage the people issues relating to a workflow implementation can spell almost certain failure. A specific point of difference with workflow is that it is similar to a relay race; only one runner holds the baton at any point in time, and the period of greatest risk is during the change over. The better a workflow design is, the less likely that the baton will drop. Hand-overs in workflow occur within the confines of the computer. This can bring about a set of new problems, as interactive discussions at hand-over time may not be supported, with a resulting loss of information (Chaffey, 1998). Other social issues that relate directly to workflow implementation are the impact of job redesign (Broadbent and Butler 1995; Clegg et al. 1997; Mumford 1993) and changing access to information (Antonucci 1997).
3
Background to the case study
The organisation involved is a university located in Australia. The university prides itself on innovative use of technology, being early adopters of such things as staff intranets, on-line enrolment facilities and comprehensive Internet presence. The university financial system, which underpins many of these ventures, has similarly been
kept up-to-date. The university was upgrading their existing financial systems; the intention of the university management was to attain maximum leverage from this upgrade, and to incorporate the usage of any new tools and applications that may accrue to them by virtue of the upgrade. The upgrade project was a complex multi stream project, involving a platform change from AS/400 to a Unix/Oracle platform, a move to full client server architecture, and a business processes review and workflow subproject. As well as this major project, the university was concurrently implementing a new student records system, and a substantial upgrade of the payroll system. The university supports a mixed end-user platform consisting of both PC’s and Macintoshes. The university was in a situation familiar to many organisations in that the current financial systems were starting to lack necessary functionality, however the financial climate generally was not supportive of large-scale expenditure in the IT area. Successive governments were reducing tertiary funding, and the need to support research and teaching activities was seen as more important than that of an administrative systems upgrade. In addition, the University was engaged in a wage and salary round of negotiations at the time when the upgrade was being mooted. The decision to allocate $A1.5 million to the project in such a climate was a stance which was unpopular in areas outside of the finance office. These forces created an environment where it was important to demonstrate some finite return from the investment, or show some “runs on the board”. The university had decided to upgrade their existing financial software to an ERP version of the product and workflow formed part of the toolset provided with the software. Senior management attended a seminar on the use of workflow, and became quite supportive of the idea for a trial of workflow within the upgrade project. The project steering committee felt that a review of business processes along with workflow implementation held the key to demonstrating a positive return on investment. Although there was top-level support for a workflow trial, and the project board was receptive to its inclusion in the project plan, there was difficulty with recruiting suitably skilled team members. It was decided to recruit a Business Analyst who had some knowledge of business processes and some basic technical skills. In addition to the Business Analyst, a staff member was seconded from within the university administration to assist with the task of identifying relevant processes and likely improvement areas. The researcher was known to the university community, and was approached to see if any assistance could be provided. The researcher was cast in the role of project mentor, with the task of providing support and education to the Business Analyst, and overseeing the progress of the project. In addition to this skills transfer role, the researcher was asked to guide the project by ensuring that technical considerations did not dominate project decision-making. The workflow project team achieved a result in the form of a pilot deployment of the cheque requisition process described in this case study. In addition, several other processes have been prepared and deployed, in the areas of Purchasing and Accounts Receivable. During the span of the project the project manager of the team and the composition of the team members altered, however the initial goals and guidelines for the project were adhered to. The project manager indicated that they felt that an acceptable degree of success was attained with the pilot deployment as the end users who processed the majority of invoices were successfully using the workflow version of the process.
4
Case Study Observations
The researcher conducted two site visits during the workflow project. The first visit occurred at the commencement of the project, and was for a duration of two weeks. The second site visit occurred towards the end of the design phase of the project and was for a duration of one week. During these site visits, observations were recorded of events that appeared to relate to factors in the research model created from the literature. A summary of the observations and their relationship to the factors follows. 4.1
Factor 1 - Process Modelling
The project team needed to identify a suitable process with which to trial the workflow tools. Senior management expressed a desire to find a process that had large transaction flows but was currently inefficient, as it was felt that improving this type of process would potentially deliver high benefits. After some initial discussion within the project team, a proposal was made to examine a sub-process within the accounts payable section; that of payment for goods where no purchase orders had been raised. This process was commonly known as a cheque requisition, and accounted for approximately 23,000 transactions per annum. The process problem was described by project team members as “The processing of cheque requisitions is a very slow and time consuming process with much time wasted by the movement of paper through the internal mail”. The proposed solution was described as:
“Create a workflow based tool for on line cheque requisitions incorporating the ability to route requisitions to the appropriate approving officer via email”. The project team had no previous exposure to any formal modelling methods. As a starting point, the researcher introduced a simple trigger model (Joosten 1994). Previous research identified this model as the most complete model for workflow modelling and also easy for end users to understand and create (Reddy and Tagg 1998). The users accepted this model quite readily and were quite keen to utilize and extend the modelling technique. As a result of team discussion and senior management requests, a revised version of the model was created, which included details about activity costing and timing. In addition to the graphic version of the process, a narrative explanation was included. It became apparent fairly quickly that a single style of model would not suit all purposes. The project team finalized a modified version of the trigger model for use within the project team and team management. It was felt that this model was not suitable for either end user discussions, or for technical development of the proposed process. There was a considerable amount of time and effort expended on attempting to resolve the question of whether a multitude of single purpose models would be preferable to a single, complex multi-dimensional model. The project team eventually elected to utilize separate models for each of the stakeholder groups involved. The difficulty of capturing a process accurately was also a problem as there were a number of ways in which the process could be enacted, depending upon the participants and the urgency of the request. Attempts to model these differing activity paths were not totally successful, perhaps limiting the value of the final process model. Although a simplistic process was selected for the trial the project team were unable to confirm that the model accurately represented current practice. The issues raised by the selection of a modelling technique, and the amount of information that should be displayed in the various models impacted on the project. There was some initial dissention as to whether the model was being created for the purpose of informing the users, or defining the technical requirements. The suitability of the proposed models impacted upon the ability of decision makers to select appropriate process choices, and upon technical staff in their deliberations relating to building and implementing the process. In addition to modelling the selected process, there was the issue of selection of a process initially. Before a decision could be taken, it was necessary to be able to show stakeholders models of the various processes they were being asked to select from. Finding an agreed start and end for processes also caused some difficulty for the project team. At one stage, the process was modelled commencing when an order was placed with a supplier; this was subsequently modified to commence when an invoice was received from a supplier. Similarly, the process end point was initially defined as occurring when a transaction was added to a batch to generate a cheque for payment to the supplier, but was later modified to after a cheque was generated for the supplier. 4.2
Factor 2 - Change Management
Senior management were supportive of the project team, the Director of personnel & financial services regularly made informal visits to check on the progress of the project team, and ensure that appropriate resources were available to ensure a good outcome. In addition, the project steering committee regularly received and commented on progress reports, and provided a forum for exploration of ideas and problem resolutions. No formal change management techniques were discussed or utilized during the pilot stage of the project. This is possibly reflective of the fact that end user involvement was limited, and senior management did not wish the early stages of the project to be publicized or promoted to the user population. There was a very clear understanding on the part of the project team leader and the senior managers involved that it would be necessary to ensure that the project objective was released in a sensitive manner, to enable logical discussion and decision making to ensue. The level of change proposed was not radical, the trial process was a small part of many people’s daily work, and the changes undertaken would not impact upon their working style to a large extent. What was more far-reaching was the possibility that a successful trial would trigger a large-scale expansion in the use of workflow processes and result in radical changes to the workplace. The trial process as such was seen as a precursor to radical change. Communication with end-users was extremely limited, most of the university community were unaware of the proposed trial. Communications within the team, and between team members and other project teams, was quite open and exchange of ideas and issues common. Communication between the project team and the university IT operations department was not quite as open as team members may have wished. The need to support existing production applications was primary to the operations department, leading to some tension when requests to provide support for the project team were given low priority. More open communications and discussion may have assisted with resolution of these issues.
Project team members had some difficulty with financial delegations, largely because of the need of the technology to have a pre-defined hierarchy for approval of payments. Within the university, traditionally the HOD or Dean of the department had granted approval, however many of the incumbents had delegated this authority to other suitable people. As a result, the introduction of a system that utilised the formal university delegations would minimise the ability of delegates to work informally as they had become accustomed to. In addition, the pre-planned nature of the escalations process was seen as taking choice relating to acceptable work standards away from individual managers and tying it to a pre-determined level. Although the need for change management was recognized, there was no planning effort or resourcing allocated to deal with this factor. It is difficult to gauge the impact of this; however it appears that the lack of formal change management may have caused some tension around the project implementation. The project plan “…. does not address any organisational issues we have encountered to date, but culturally there have been (and will be) a few”. 4.3
Factor 3 - Political Aspects
The university was in the middle of a round of enterprise bargaining (i.e. salary negotiations). Senior management was concerned that the awareness of a workflow trial may lead people to conclude that job losses would inevitably follow. As a result, the project planning and initial documentation of the selected process was conducted entirely without end-user interaction or knowledge. This not only blocked a potentially valuable source of information for the workflow team, it caused an air of secrecy to appear around the project team. One of the primary changes introduced by the workflow pilot was to devolve tasks currently performed by finance office staff to departmental staff. This particularly related to the keying in and validation of payment data. It was felt that if these consequences became known at an early stage that the workflow trial would be compromised, and possibly unable to proceed. The finance office perspective was that they would be able to provide a higher level of customer service if they concentrated on management of payment processes, rather than initial input and validation of data however the effect of these resource usage changes had not been discussed with departmental staff. During the initial modelling phase, a standard technique was used which involved column headings to indicate departmental responsibility for individual activities within the selected process. A model was drawn of the existing process, and a revised model created to indicate changes to make the process more effective. The revised model was accepted; however a request was made to remove the headings from the columns, as it clearly indicated that a currently centralized workload was to be devolved out to end user departments. It was felt that such a clear indication of intent might not be palatable to all stakeholders at this stage of the project. Some differences were noted between the IT professionals and the finance office staff on the project team. It seemed that the Finance office staff wished to develop a more flexible process model, with a range of paths available to suit different work styles and preferences, whereas the desire of the IT professionals was to minimise complexity in the model. This may have been due to the fact that this was a trial of the technology, and the minimization of complexity would give the technology a better chance of success; however the two viewpoints did not seem to reach a clear reconciliation point. Several other examples of political behaviour were observed: vendor pressure to upgrade the software product; concealment of the project aims and outcomes and reluctance to publicly reveal proposed workload devolution. The effects of this behaviour are not necessarily negative, however they did cause concern to team members and involved stakeholders. A team member commented “I feel that the term workflow, whilst encompassing a great many principles to senior management, is most likely seen as something sinister by general staff and line managers”. 4.4
Factor 4 - Organizational Impact
As the formal hierarchy and financial delegations of the organization were clearly defined it did not seem that workflow would impact the current structure, if anything it would possibly reinforce it. An identified area of impact was the informal organisational structure. Given the nature of a university campus a degree of informality existed in the academic faculties, which was not mirrored in the administration sector. The propensity of workflow to enforce the formal structure by means of the formalisation and definition of processes was more noticeable where the informal structure deviated from the formalised version. The question of whether to design the technology to suit existing informal organisational structures was discussed, but it appeared that the opportunity to redefine some parts of the organisation using workflow as the justification was seen as opportune. The primary problem here seemed to be the dual culture that is evident in most universities – the business culture of administrative staff is very different to the collegiate culture of the academic staff. Although the formal management chart showed a centralised structure with devolved responsibilities to line managers this proved illusory when tested. Informal delegations of power were impacted by the introduction of workflow technology.
A finance office representative noted the common practice of people working around formal lines to gain approvals for various expenditures. As an example, some people with funding delegations were seen as more likely to approve spending within a department than others, and hence they were more frequently sought to provide payment approvals. The introduction of workflow would reduce the power of individuals to select the approver who they felt was most likely to prove sympathetic to their request. 4.5
Factor 5 - Business Process Reengineering
A separate stream of the overall ERP upgrade project was devoted towards revisiting business processes. The intention seemed to be that the process reengineering stream would take place concurrently with workflow process development; however this did not occur with the trial process. This stream had not commenced when the workflow planning was underway, and therefore no standards or methodologies had been defined. The question of revision of the selected process was a vital part of the early workflow team discussions and work. Considerable time and effort was spent on identifying activities and roles within the process. Several detailed suggestions were made relating to possible changes that would benefit the existing process. The project team generally seemed to accept that simply automating an existing dysfunctional process would not result in a positive benefit creation, and therefore it was important to consider process reengineering prior to approaching the workflow tools. This was supported strongly by the vendor material and training provided. The product vendor emphasised repeatedly the importance of correcting process deficiencies prior to workflow automation. Inability to recruit suitable process reengineering resources proved a problem for the project team. A process analyst could not be located so a business analyst was employed who was mentored by the researcher and provided with training in the workflow toolset. Technical resources were also difficult to secure – the product vendor sourced their support from a diverse range of locations and due to this shortage there was not a lot of continuity when vendor representatives worked on-site with the workflow team.. The learning curve to implement and deploy a process was quite steep. This seemed to be due largely to the architecture of the ERP suite, which relied upon a complex three-tier client server architecture using a layer of deployment servers in addition to the standard application and data servers. Technical support in this environment was difficult to engage. It seemed clear that the success or otherwise of the reengineering exercise would affect the acceptance and uptake of the workflow system. 4.6
Factor 6 - IT Enablement.
The software being installed was a version that was becoming obsolete by the time the project went live and the workflow tools were considerably less well developed than the later version of the software. In addition, the vendor was keen to move their client to the later version prior to roll out-of any workflow processes. The vendor provided all training and documentation in the later version, and was quite clear about their reluctance to support development or use of the workflow tools in the earlier version. This caused some tension between members of the workflow team and technical support staff, as the technical staff exhibited considerable resistance to the idea of upgrading an ERP suite that had not yet been fully implemented in the production environment, based on the needs of a small sub-set of the user group. The workflow tools tested were not fully compatible with Macintoshes. The major implication of this was that users on a Macintosh were unable to send or receive attachments to file messages, and were also unable to access the ERP software directly via a workflow message shortcut. Also the ERP software included an internal email system, which was accessible at desktop level only after entering the application suite. In order to optimize the use of workflow, it was desirable to have the workflow-generated messages pushed out to the existing end user email software. The ERP product was able to be integrated with any MAPI compliant messaging system; the vendor preferred third-party email products were Microsoft Outlook and Lotus Notes. The university was utilizing Netscape Communicator as its email client and had no plan to alter this. During initial familiarization with the workflow product, it became clear that the workflow tools were incapable of communicating correctly with the Netscape third-party email client. This left the project team with a choice of either attempting to gain support for a change of email client within the university, or implementing a workflow system which was incapable of messaging directly to the most commonly used email desktop client. The interim decision which was taken for the pilot process was to not use third party messaging, thereby limiting the effectiveness of the workflow process as users had to actively log into the application suite to interact with the workflow. A critical component of workflow software is the ability to generate a message to an appropriate role, or individual, usually for approval of a proposed action or confirmation of a request. In order to do this, a list of appropriate addresses must be maintained. The software utilized a central address book, which was accessed by all applications. The needs of workflow addressing are different to that of a financial system; as the individual their role and often their financial delegation level is required to be recorded in order for the workflow software to make correct choices about addressing of individual process instances. As the ERP software was not inclusive of the university human resources or payroll systems, it seemed likely that information required for workflow
addressing would need to be manually entered and maintained. The solution adopted was to appoint a coordinator to the role of gathering and maintaining address information, with a view towards possible creating an automated version at some future point. One of the features of workflow software is the ability to escalate an instance of a process where an activity has been inactive for a pre-defined period of time. As an example, if a transaction is not acknowledged within a specified time, the message is escalated to the next level of the address hierarchy for approval. Control of the escalation functionality required a hierarchical addressing list to be created and maintained, along with a definition of appropriate timing for escalation. During product familiarization it was found that the ability to set escalation timeframes was definable only in terms of hours – e.g. 48 hours. There was no supplied ability to set a global calendar listing weekends, and other non-working days. As a result, it was thought that the escalation functionality was virtually unusable in the supplied toolset. Without escalation, it would be more difficult to ensure that all initiated instances of processes were completed within a reasonable timeframe, as process cycle times would need to be manually controlled. The IT enablement factor seemed to generate the most observations and discussions of all the proposed factors. Issues of version migration, mixed platform support, third party e-mail support, message addressing and instance escalation potentially covered the most damaging problems within the observed project. Although many of these issues could be resolved, given enough time and money, the inability of the existing IT platform to readily support workflow was seen as a major inhibitor to progress. 4.7
Factor 7 - Social Impacts
The process model revealed several instances where social interaction which currently took place between staff members would be replaced by a workflow generated email message, project team members expressed reservations about the willingness of end users to accept this solution. The project team discussed the wording of these pre-formatted email messages extensively, as they were aware of the possibility of misinterpretation of the messages. While this generated some concern, it was not seen as a major issue, simply one that required some thought when defining and laying out the email message templates. Additionally, it was felt that the process of escalation used might not be compatible with the culture of the end user community given that the technology was designed included a pre-defined hierarchy of escalation. The project team expressed concerns about this formalisation of the escalation process as the current process of escalation was largely informal, and varied between departments. In addition, it was felt that some clerical staffs may see the timing of escalation as a threat to their work style, with failure to promptly attend to messages resulting in a notification to their manager, creating an impression of sub-standard performance. Concern was also expressed at the thought of replacing the current face-to-face handover of tasks with a prescripted email message. The workflow toolset allowed an ad-hoc note to be attached to the scripted email for additional information to be provided, which was thought likely to be sufficiently flexible. The finance department representative felt that some of the tacit information currently conveyed during task handover discussions would be lost. The proposed devolution of tasks would result in job redesign for two groups of people – finance office staff and departmental staff. In the case of the finance office staff the change would result in job enrichment, freeing them from the task of data input and validation and allowing them to spend more time in an analytical or management role. The opposite situation was proposed for departmental staff, they would become responsible for keying in data which they had previously only needed to write down and forward to the finance office for input. It was acknowledged within the project team that this change at departmental level would be difficult politically to sell, and that care should be taken to be sure that discussions were held at a suitable level prior to releasing this information. Due to lack of end user involvement it was not possible to determine if disclosure of process would be a problem. It was quite clear however that information produced from instances of processes would form a pattern that would enable management to assess the workload and work skills of individuals who performed activities within those processes. Additionally, process monitoring would readily identify when and where escalation was necessary, and compare average times for activities to be completed. This all contributed towards a far more indepth picture of work rates and results than was currently possible. There was some concern within the project team that workflow would be seen as a sort of time and motion project, where activity completion within a short timeframe was the goal rather than completion to a satisfactory quality standard.
5
Findings
The study took place over seven months. During this time the researcher was on-site for a total of three weeks, divided into two visits. The remainder of the time correspondence between the researcher and the project team
was conducted via email. The observations made during visits related to those actions that were manifesting at the time of the visit. The researcher was specifically seeking support for the existence of the proposed factors and it may well be that there are additional factors which impact upon workflow implementation that were not noted during the observations. The importance of the proposed success factors is supported by the case study observations recorded. The factors identified from the literature review were observed to manifest during the tome on site with the project team, and those factors did have an impact on the success of the workflow implementation. Based on these observations it appears likely that these proposed factors are a reasonable starting point for creation of a research model.
6
References
Ader, M. (1998) "Implementing Workflow: Mission impossible?" Document World (3:2), pp 7 - 9. Allen, R. (2001) "Workflow: An Introduction," in: WfMC Workflow Handbook 2001, L. Fischer (ed.), Future Strategies Inc, Florida US, pp. 15 - 38. Antonucci, Y.L. (1997) "Using Workflow Technologies to improve Organizational Competitiveness”, International Journal of Management (14:1), pp 117 - 126. Bajaj, A., and Ram, S (1996). "A content specification for business process models”, Australian Journal of Information Systems. (4:1), pp 22 - 31. Bhattacherjee, A., and Hirschheim, R. (1997) "IT and Organizational Change: Lessons From Client/Server Technology Implementation," Journal of General Management (23:2), pp 31 - 46. Blackler, F (1992). "Information system design and planned organization change: applying Unger's theory of social reconstruction," Behavior and Information Technology (11:3), pp 175 - 183. Boersma, P (1994). "Experimental Research into Usability and Organizational Impact of Workflow Software”, in: Information Systems - Design Methodology Research Group, University of Twente, Twente, the Netherlands, p. 67. Broadbent, M., and Butler, C. (1995) "Implementing Business Process Redesign: Early lessons from the Australian Experience," Australian Journal of Information Systems (2:2), pp 63 - 76. Buchanan, H., and Huczynski, A. (1997) Organizational Behavior, (3rd ed.) Prentice Hall. Butler, C. (1993) "The Role of Information Technology in Business Process Redesign: Observations from the Literature," Working paper # 18, University of Melbourne, Melbourne, Australia. Butler, C. (1996) "Critical Success Factors for Business Process Redesign”, in: Information Technology, Royal Melbourne Institute of Technology, Melbourne, Australia. Chaffey, D. (1998) "Workflow Management Systems”, in: Groupware, Workflow and Intranets: Reengineering the Enterprise with Collaborative Software, D. Chaffey (ed.), Digital Press, Boston, pp. 73 - 97. Christiansen, N., Villanova, P., & Mikulay, S. (1997). Political influence compatibility: fitting the person to the climate. Journal of Organizational Behaviour. 18(6), pp709 - 730 Clarke, A., and Garside, J. (1997) "Development of a Best Practice Model for Change Management”, European Management Journal (15:5), pp 537 - 545. Clegg, C., Axtell, C., Damodaran, L., Farbey, B., Hull, R., Lloyd-Jones, R., Nicholls, J., Sell, R., and Tomlinson, C. (1997) "Information technology: a study of performance and the role of human and organizational factors," Ergonomics (40:9), pp 851 - 871. Conrath, D.W., and De Antonellis, V. (1992) "Dynamic Modelling for Office Support Systems Analysis and Design”, in: Dynamic Modelling of information Systems, II, H.G. Sol and R.L. Crosslin (eds.), Elsevier Science Publishers B.V, Amsterdam, The Netherlands. Cooper, R., and Markus, M. (1995) "Human Reengineering”, Sloan Management Review (1995: Summer), pp 39 - 50. Cummings, J.E. (1996) "How the US Court of Appeals reengineered its paperbound voting process”, I/S Analyzer (35:2), pp 7 - 11. Datta, A. (1998) "Automating the discovery of AS-IS Business Process Models: Probabilistic and Algorithmic Approaches," Information Systems Research (9:3) pp 275 - 301.
Davenport, T., and Beers, M. (1995) "Managing Information about Processes”, Journal of Management Information Systems (12:1), pp 57 - 80. Davenport, T., and Short, J. (1990) "The New Industrial Engineering: Information Technology and Business Process Redesign," Sloan Management Review (31:4), pp 11 - 27. Davenport, T., and Stoddard, D. (1994) "Reengineering: Business Change of Mythic Proportions," MIS Quarterly (18:2), pp 121 - 127. Drory, A., and Romm, T. (1990) "The Definition of Organizational Politics: A Review," Human Relations (43:11), pp 1133 - 1154. Ferris, G.R., Frink, D.D., Galang, M.C., Zhou, J., Kacmar, K.M., & Howard, J.L. (1996) Perceptions of Organizational Politics: Prediction, Stress-Related Implications and Outcomes. Human Relations. 49(2), pp233 - 265 Georgakopolous, D., Hornick, M., and Sheth, A. (1995) "An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure," Distributed and Parallel Databases (1995:3), pp 119 - 153. Grover, V., Fiedler, K., & Teng, J. (1994) Exploring the Success of Information Technology Enabled Business Process Reengineering. IEEE Transactions on Engineering Management, 41(3), pp276 - 284. Grover, V., Jeong, S., Kettinger, W., and Teng, J. (1995) "The Implementation of Business Process Reengineering”, Journal of Management Information Systems (12:1), pp 109 - 144. Hammer, M., and Champy, J. (1993) Reengineering the Corporation HarperCollins, New York. Harkness, W., Kettinger, W., and Segars, A. (1996) "Sustaining Process Improvement and Innovation at the Information Services Function: Lesson learned at the Bose Corporation," MIS Quarterly (20:3), pp 349 - 367. Hornby, P., Clegg, C., Robson, J., Maclaren, C., Richardson, S., and O'Brien, P. (1992) "Human and Organisational Issues in Information Systems Development”, Behaviour & Information Technology (11:3), pp 160 - 174. Joosten, S. (1994) "Trigger Modelling for Workflow Analysis", Research Report University of Twente, Twente. Joosten, S., and Brinkkemper, S. (1995) "Fundamental concepts for Workflow Automation in Practice”, ICIC '95, Amsterdam, p. 13. Kettinger, W., Teng, J., and Guha, S. (1997) "Business Process Change: A Study of Methodologies, Techniques and Tools," MIS Quarterly (21:1), pp 55 - 81. Kobielus, J.K. (1997) Workflow Strategies IDG Books Worldwide, California. Kock, N., and McQueen, R. (1996) "Groupware and Business process Improvement: Technology enabled organisational learning," Australian Journal of Information Systems (3:2), pp 36 - 46. Lancaster, J. (1994) "Workflow Re-Engineering Using Spatial Information Systems Technology”, AURISA 94, Sydney, Australia, pp. 151 - 162. Loebbecke, J., and Jelassi, T. (1997) "Business process redesign at Compunet - standardising top-quality service through IT”, The Journal of Strategic Information Systems (6:4), pp 339 - 359. Lucas, H., Berndt, D., and Truman, G. (1996) "A reengineering framework for evaluating a financial imaging system”, Communications of the ACM (39:5), pp 89 - 96. Markus, M., and Benjamin, R. (1997) "The magic bullet theory in IT-enabled transformation”, Sloan Management Review (38:2), pp 55 - 68. Marshak, R. (1997) "Workflow: Applying Automation to Group Processes," in: Groupware: Collaborative Strategies for Corporate LANS and Intranets, D. Coleman (ed.), Prentice Hall, New Jersey, pp. 142 181. Mintzberg, H. (1985) The Organization as Political Arena. Journal of Management Studies. 22(2) pp133 - 154 Mumford, E. (1993) "The ETHICS Approach”, Communications of the ACM (36:6), p 82. Murphy, F., and Staples, S. (1998) "Reengineering in Australia: factors affecting success," Australian Journal of Information Systems (6:1), pp 59 - 69.
Orlikowski, W., and Hofman, J. (1997) "An Improvisation Model for Change Management: The case of Groupware Technologies," Sloan Management Review (38:2), pp 11 - 21. Orman, L. (1999) "A Model Management Approach to Business Process Reengineering”, Research Paper Cornell University. Reddy, S.S., and Tagg, R.M. (1998) "Suitable Process Models for End-User Process Improvement and Workflow Specification”, 1/98, Massey University, Palmerston North. Scott, C. (1999) "A page from the corporate Sector: Re-Engineering the Business of Academia," Research Paper Stanford University. Shaft, T.M., and Vessey, I. (1998) "The Relevance of Application Domain Knowledge: Characterizing the Computer Program Comprehension Process," Journal of Management Information Systems (15:1), pp 51 - 78. Sillince, J., and Harindranath, G. (1998) "Integration of requirements determination and business process reengineering: a case study of an Ambulatory Care and Diagnostic (ACAD) centre," European Journal of Information Systems (1998:7), pp 115 - 122. Stoddard, D., and Jarvenpaa, S. (1995) "Business Process Redesign: Tactics for Managing Radical Change," Journal of Management Information Systems (12:1), pp 81 - 107. Thach, L., and Woodman, R.W. (1994) "Organizational Change and Information Technology: Managing on the Edge of Cyberspace," Organizational Dynamics (23:1), pp 30 - 46. Trammell, K. (1996) "Work Flow Without Fear”, Byte: April. van der Aalst, W.M.P. (1998) "Petri-net-based Workflow Management Software”, Research Paper Eindhoven University of Technology, Eindhoven, The Netherlands. Willcocks, L., & Smith, G. (1995) IT-enable business process reengineering: organizational and human resource dimensions. The Journal of Strategic Information Systems. 4(3), pp 279 – 301 Alison Parkes © 2004. The author assigns to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the author.
