A PROCESS ARCHITECTURE APPROACH TO MANAGE HEALTHPROCESS REFORMS

Abstract Business Process Management (BPM) is often perceived as a toppriority concern in organisations; both in public and privatesectors. This has been clearly noticed in the Australianhealth care sector, evidenced by the Australian Government’scommittment to pursuing a reform agenda that reflects a newapproach to improving health and aged care services. Theadoption of a business process management approach can be akey tool to facilitate health reform in the public and privatesectors. This approach provides a structured and hencerigorous approach to ensure that health processes arereviewed, improved and implemented consistently throughout theorganisation, especially where public health services areprovided from multiple service points. Process modeling is an embedded component of most BPMinitiatives, yet a resource intensive task. How process modelscan be derived efficiently (i.e. with less resources and time)and effectively (at a high quality to meet the specific needs)is an integral element of interest to most organisations,however, this area of research is still in its infancy. Thispaper aims to address this gap by proposing a ‘process-pattern’ based approach to process modeling where models arecreated and managed within a ‘process architecture’. Theprocess pattern approach is explained with evidence from alarge state based health organisation using an integrated riskmanagement process for health care service management as anexample. The study employed an action research approach andthe chapter unfolds its findings around the main phases of theresearch method. The contributions from this work are twofold. From theperspective of practice, it offers a validated high levelexample of a process pattern for an Integrated Risk ManagementProgram for health. From an academic perspective: it presentsa validated Risk Management process pattern for deliveringhealth services which can be used as best practice or abenchmark in further research.

[Type text]

IntroductionAustralia’s growing health demands are creating new challengesfor governments at the national, state, territory and locallevels (Minister of Ageing, 2008). The Australian FederalHealth Department intends to spend $51.8 Billion dollars onNational Health initiatives in 2008-2009 through the NationalHealth and Hospitals Reform Plan. The aim is to improve thecapacity of the states and territories to deliver healthservices when and where the citizens (in particular, workingfamilies) need them. The current Australian Health CareAgreements will be extended for 12 months with an extra $1billion in provided funding. New agreements will be finalisedby the end of 2007, with opportunities for major reform(Department of Health and Ageing, 2007). One of the majorchallenges to implement the intended reforms relates to howHospitals are currently organized using logical groupings(functions) of clinical specialties instead of being groupedaccording to process groupings. Taking a process-orientedapproach to improving processes can be challenging as theseprocesses need to cross the traditional functional boundariesin order to realize process efficiencies (Vera, A. & Kuntz, L.2007).The adoption of a Business Process Management (BPM) approachcan be a key tool to facilitate health reform in the publicand private sectors. Business Process Management (BPM)provides a structured and consequently a rigorous approach toensure that health processes are reviewed, improved andimplemented consistently throughout the organisation,especially where public health services are provided frommultiple service points. BPM in general, includes methods, techniques, and tools tosupport the design, enactment, management and analysis ofbusiness processes (van der Aalst et al., 2003). One of thekey concerns and challenges when applying BPM is the lack ofaccepted methodologies, and resources to guide theseinitiatives (Larsen and Myers, 1998; Murphy and Staples 1998;Amoroso, 1998; Indulska et al., 2006). A common BPMmethodology that can be utilised and catered for all specificcontexts is yet to be derived; and may not be feasible due tothe complexities that each individual context brings in.However, a common aspect of all BPM approaches is theorientation towards understanding the current-processes andaim towards an improved better-process. Business processarticulation in the form of high-level and detailed process

[Type text]

models is a common component of most process improvementprojects (Indulska et al., 2006; Bandara 2005). ProcessModeling provides a structured and consequently a rigorousapproach to ensure that all required aspects of processes arereviewed, improved and implemented consistently. However,detailed process modelling can be an expensive exercise(Becker et al, 2003), and also complex in terms of managingall the different types and levels of processes (and theirmodels), their relationships and interdependencies. WhileProcess Architectures are highly recommended for this (Davisand Bradander, 2007), there is a dearth of examples andinformation on how to implement such an approach. Addressingthis gap is the main aim of this chapter.In this chapter, we propose a Process Architecture approachwhere Process Patterns are used at different levels to captureand deploy best practices for health processes. A riskmanagement process in the health arena is selected todemonstrate the design and application of the proposed ProcessArchitecture concept. This research combines diverse conceptsin the area of risk management, business process analysis andhealth treatments services. The remainder of the chaptercommences by first briefly introducing these concepts. Thechapter then introduces the Organisation in which thisresearch was designed and implemented at. The paper thenproceeds to provide a detailed example which demonstrates howa Process Architecture is designed and implemented (by usingprocess patterns). The details are presented in the form ofempirical evidence gathered through an action researchapproach Finally, the chapter concludes with a discussion ofthe limitations, of this work as well as a preview of futureactivities.

Introducing key concepts This section is dedicated to describing the many terms andconcepts used later in the chapter during the overall researchprocess and findings discussions that are followed.

Best PracticeThe term ‘Best Practice’ is used to describe the process ofdeveloping and following a standard way of doing things thatcan be used (i.e. for management, policy, and especiallysoftware systems development) multiple times. Even though theterm ‘best practice’ has now become a buzz word withinorganizations, it is not a new notion. For example, FrederickTaylor (1911) stated that “Among the various methods and implements

[Type text]

used in each element of each trade there is always one method and one implementwhich is quicker and better than any of the rest” (Taylor, 1911). Bestpractice is ideally, defining ways that can be used to getthings done based on past experience. Organizations benefit byadapting these, as they assure quality results and consistencywhen the process is followed. Today, ‘best practices’ aredocumented in various forms, such as in reference models andinformation libraries (i.e. SCOR, ITIL, PMBOK, ETOM etc) andare accepted more as ‘better-practice’ that can assistorganizations to define, design, implement and monitorbusiness process improvement initiatives. These documentedbest practices often use graphical models to illustrate themethods to follow.

Process ModelingProcess modeling is an approach for visually depicting howbusinesses conduct their operations by defining the entities,activities, enablers and further relationships along controlflows (Curtis et al., 1988; Gill, 1999). It is widely used toincrease awareness and knowledge of business processes, and todeconstruct organizational complexity (Davenport, 1993; Hammerand Champy 1993; Smith and Fingar 2003). The visualization ofbusiness processes in the form of process models has increasedin popularity and importance (Bandara et al., 2005). Processmodeling is an embedded component of most BPM initiatives, yeta resource intensive task (Becker et al., 2003). “The importanceof business processes has been amplified by being in the centre of late technologicalinputs in the form of ERP and workflow systems that aim at increasing productivityand functional interconnectivity by automating internal and external transactions”(Adamides and Karacapilidis, 2006). Thus, how process modelscan be derived efficiently (i.e. with less resources and time)and effectively (at a high quality to meet the specific needs)is an integral element of interest to most organisations. Thisarea of research is still in its infancy, with only a fewstudies conducted on critical success factors of processmodeling (e.g. Bandara et al, 2005). Even these, (while theydepict what the critical success factors are with empiricalevidence) do not provide procedural guidelines on how toachieve these success factors, to improve the efficiency andeffectiveness of process modeling initiatives.

Process Pattern

[Type text]

A pattern in general is “an abstraction from a concrete form which keepsrecurring in specific non-arbitary contexts” (Riehle and Zullighoven,1995). Patterns have been usefully applied across differentdisciplines in the past. Alexander et al., (1977) describeshow patterns can be used for building architectural designs.Patterns have been widely applied in the Software developmentarena since the “Gang of Four” (GoF) patterns were introducedby Gamma et al., (1995), they have also been widely applied inthe workflow management arena1. Recent research (i.e. Van derAalst et al, 2003) has proposed the use of patterns for thedescription and evaluation of workflow managementtechnologies. Forster (2006) describes potential businessprocess improvement options across different layers of anorganisation using a pattern approach. Literature predicts thehigh proliferation of patterns within the BPM arena (Harmon,2003). The basic benefit of a pattern is that the fundamentalelements can be reused and hence better knowledge management,efficiency and effectiveness reached, when they are appliedwithin projects. Patterns can be seen as building blocks, whichwhen put together form a meaningful entity with minimaleffort. However, the knowledge (held by the person applyingthe patterns) of how to, and when to bring them together,plays a critical role for its success. Patterns can also beperceived as standard recipes, where the basic fundamentalconcepts can be adapted and catered for to meet specificneeds. Within a BPM context, a pattern is “an idea that has been useful in onepractical context and will probably be useful in others” (adopted from Fowler,1997, p.8). Hence patterns are not invented, rather discoveredby observing its success over a number of applications. Inother words, a process-pattern is a common approach to solveproblems that are proven to work in practice (adapted fromAmbler, 2000). Process patterns are different to referencemodels (such as SCOR, ITIL, PMBOK etc) – which have beenapplied widely for process improvement projects. “A referencemodel is an abstracted depiction of reality that serves as a standardised orsuggestive conceptual basis for the design of enterprise specific models, usuallywithin a like domain” (Taylor, 2003, p. ii). A pattern has a muchsmaller focus, and can be a part of a reference model. Whileprocess patterns may inherent some features of referencemodels, they do not provide ‘enterprise’ solutions, ratherprovide process specific solutions, which are much smaller in

1 See http://workflowpatterns.com for further details. Last accessed, 14th of July, 2008.

[Type text]

scope. Process patterns can be usefully applied across thevarious phases of a BPM project.

Enterprise Business Architecture and Process ArchitectureAn Architecture illustrates the relationships between partsthat create a whole; however, they do not illustrate flow,sequence or timing of events (Whittle and Myrick, 2005).Therefore, an Enterprise Business Architecture provides theguiding framework that describes the relationship between allthe parts of the organisation from the strategy toimplementation2. The Enterprise Business Architecture is madeof a number of facets of the organisation as shown in Figure1.

2 See The Business Analysis Body of Knowledge www.theiiba.org. Last accessedon 14th of July, 2008.

[Type text]

Services People GovernanceLocationFinance

Business Rules

PolicyProceduresW ork Instructions

VisionM ission

Goals

Objectives

StrategiesRolesResponsibilitiesSkillsCapabilities

BudgetForecastCash flowBalance sheet

GeographicPhysical structuresService points

Custom er InternalSupplier

Level ABusiness Activities

Level BProcess Groupings

Level CCore Processes

Level DBusiness Process Flow s

Level FDetailed Process Flows

Business Activities O bjectives

Process Groupings ServicesOwnership

Delivery UnitsCore Processes Products

ProcessesDelivery Team s

Sub Processes

Delivery Processes

Level EOperational Process Flows

Roles

Detailed Roles Transactions

System Functions

System s

Scorecard

Section A

Section B

PROCESS ARCHITECTURE FRAMEWORK

Figure 1: Facets of Enterprise Business ArchitectureThe Zachman framework for Enterprise Architecture developed byJohn Zachman, provides a guide for how information about anEnterprise should be organised. The purpose of Zachman’sframework was to provide a simple structure that supports theenterprise to access, interpret, develop, manage and changedescriptions of the organisation (The Open Group, 2007). Theframework proposed above in Figure 1 aligns well with theZachman approach by providing multiple perspectives ofthe organization from the contextual, conceptual, logical

[Type text]

and physical layers of the enterprise (Figure 1- sectionA) which also describes the what, how, where, who, whenand why in the Zachman model (Figure 1- section B) foreach perspective outlined in the figure above.The process architecture is one of the facets of theEnterprise Business Architecture, where it provides theframework by which the organisation’s processes can bestructured.The process architecture more importantly provides therelationship between the processes to the other facets of theEnterprise Business architecture such as the People, Finance,Location, Governance etc. In general terms, processarchitecture is the structural design of general processsystems. “A business process architecture is a hierarchical structure of process descriptionlevels and directly related views covering the whole organisation from a businessprocess point of view. It starts with high-level process maps representing aconceptual business view down to the detailed process flow descriptions describingspecific tasks and their relation to roles, organisation, data and IT systems.” (Davisand Brabander, 2007, p.50). This process architecture definesa framework for organising, deriving, managing and maintainingthe process pattern. A process architecture organises the processes so that staffcan easily adopt a pattern based approach to their work asthis provides them with a structure to manage their businessanalysis and improvement projects. The process architecturemodel adopted in this study is shown in Figure 1 Section A.This is the architectural process modeling approach proposedby Davis (2006) which is also applied across British Telecom.This model provides a top down approach using six layers fromA to F (see Figure 1 section A and Table 1 for details on eachlayer) where the level of detail represented by the processmodels increases from top to bottom. Process patterns can beidentified at each level of the model which is actually the‘design’ of the organisation and how it is meant to operate.

PROCESSARCHITECTUREFRAMEWORKLEVELS

DEFINITIONS

Level A :EnterpriseMap

This may be represented as three fundamental activitiesthat are carried out to run the organisation’s business:

Direct the Business; Manage the Business; and Operate the Business.

It distinguishes operational customer oriented processes

[Type text]

from management and strategic processes.Level B:ProcessGroupings

The level defines different views of how the processesare structured to deliver the three business activitiesat Level A, which are to Direct, Manage and Operate theBusiness.These Processes may be structured from: A process execution perspective showing standard end-

to-end processes (e.g. Service Fulfilment); or A functional perspective (e.g. Value Domains such as

Emergency Services, Health Services).Level C:Coreprocesses

These are recognisable sub-processes of end-to-endProcesses. They can generally be carried out by aBusiness Unit or a Line of Business functional area.These types of models define those activities thatdeliver services that are unique to an organisation andthat no other organisation delivers, as distinct fromsupporting processes. Level C Process Models arenormally modelled as Value Chains and are comprised oftasks that are defined in detail in the Business ProcessFlows at Level D.

Level D:BusinessProcessFlows

This level defines the process flows of the coreprocesses defined at Level C and are comprised of tasks.They are normally defined generically (i.e. not specificto a particular product, service, customer, geographicaloperation, etc). It often will only show the ‘HappyCase’ (the most common) scenario and exclude the detailof alternative actions, failures and error recovery.Tasks can be decomposed into more detail if required inLevel E Operational Process Flows.

Level E:OperationalProcessFlows

These process models define in more detail the BusinessProcess Flows defined at Level D. It is comprised ofsteps, normally specific to an operational environmentand will be characterised by the Application Systems andOrganisational Units or Positions that support andexecute them. These types of models typically willinclude the ‘Sad Case’ scenario showing the detail ofalternative actions, failures and error recovery. The‘Happy Case’ and ‘Sad Case’ scenarios comprise theBusiness Rules of the organisation. These steps can bedecomposed into more detail if required in Level F;Detailed Process Flows.

Level F:DetailedProcessFlows

This level defines in more detail the Operational Process Flows defined at Level E. It is comprised of operations and may be used to generate workflows or be used as detailed requirements for systems development. An example of an operation is to describe program logic using pseudo code which can then be coded in the specific programming language. This is embedding the operation logic into the software.

[Type text]

Table 1: Process Architecture Hierarchy descriptions (adaptedfrom Davis and Brabander, 2007)

The Case OrganizationA major Australian Health organization3 provides public healthtreatment services to a geographically dispersed population ofnearly 4 million people. These services are provided througha number of tertiary hospitals, clinics, aged care facilitiesand community health centers in metropolitan, rural and remoteregions. Table 2 provides a brief overview of the caseorganization under investigation.Population Serviced 3.9 Million4

Annual Budget (as of2007)

Approximately $8.3 Billion

Hospitals 38Number of Public HealthService Centers includinghospitals

Approximately 160

Number of Beds Approximately 10,000Key Stakeholders Members of the Public – Health

Service Consumers Primary Health Care Providers Specialists Non-Government Organizations Health Service Industry Partners

such as Diagnostic ServiceProviders

Number of employees(including full-time,part-time andcontractors)

Approximately 75, 000

Types of servicesprovided

Public Health Services In-Patient and Outpatient

Clinical and Non-Clinical HealthServices

Aged Care Community Health

Number of IT Systems Approximately 45 Statewide systemswith over 25, 000 localized systems

Number of IT Staff, full- Approximately 900

3 Please note that the organisation is kept anonymous in this paper for confidentiality purposes.4 Office of Economic and Statistical Research Information Brief, released 24March 2005. Australian Demographic Statistics September Quarter 2004

[Type text]

time, part-time andcontractorsTable 2: Brief overview of the of the case organization

This large state-wide Health Services organization hasintroduced a major program of improvement and transformationwhich is supported by funding provided under the AustralianHealth Care Agreement 2003 – 2008 (Department of Health andAgeing, 2008). As a result of this initiative, a business unitwas established – its focus being on innovation and reform inthe workplace. The objective of the new business unit was todevelop a culture of safety and standardize systems andclinical practice to ensure best practice. These goals alignwell with the concept of using a pattern-based approach toachieve best practice. The Integrated Risk Management (IRM)program was identified as a key strategic initiative thatwould ensure that a best practice approach was taken to ensurepatient safety and support a culture of risk management wherestaff are encouraged to report clinical incidents and ensurethat risk management strategies are implemented to minimizerisk. The overarching goal of the Integrated Risk Managementprogram was to document a set of Business Requirements toreview the current business processes and define a set ofFunctional Requirements for an ICT solution to facilitate thecapture and management of risk information.

A number of projects commenced as a result of this IRM programwhich was to define an enterprise-wide Risk Management policy,standards, guidelines and the implementation of an IT systemwithin all Health Service Centers from hospitals to clinicsand other health facilities. The IRM Program consisted ofthree major projects; (i) to define an IRM Framework for theenterprise, (ii) define business requirements for a ComplaintsManagement system, and (iii) define business requirements fora Clinical Incident Management system. Each of the threeprojects required a detailed review of the current (As-Is)business processes where workshops were conducted with keystakeholders.

Projects DescriptionClinical IncidentManagement

The proactive identification andtreatment of hazards before they canlead to patient harm. This alsoincludes the minimization of harm whenit does occur and corrective action tominimise the risk of the incident

[Type text]

occurring again.Complaints Management The management of complaints made by

members of the public. This processidentifies the incident(s) which leadto the complaint and ensures that aninvestigation is conducted ending infeedback being provided to thecomplainant on the corrective actiontaken.

Integrated RiskManagement

The integration of risk managementat each level of management into allbusiness activities includingstrategic planning and decision-making processes

Table 3: Brief descriptions of the three Risk ManagementProjects

The Clinical Incident Management project commenced first dueto critical strategic and political pressure resulting fromnegative press reports in the local paper reporting stories ofnegligence by clinical staff. The objective of the projectwas to improve the management of clinical incident reportingat health service centers and restore confidence in thepublic. The Complaints Management project commenced shortlyafter, followed by the Integrated Risk Management frameworkwhich was meant to integrate the risk areas across theEnterprise.

These three projects, in the Integrated Risk ManagementProgram, were implemented sequentially where the intention wasto incrementally build on the lessons learnt from eachimplementation phase. At the time of commencement,similarities between each project were not clear and theobjective was to leverage any synergies identified betweenthem.

Project Design and FindingsAn action research method was chosen for this project,which was conducted as a combined consulting and researchproject, with the goal of producing immediate practicaland academic outcomes. Action research is proposed as auseful methodology when the goal is the inquiry into aparticular situation and the development of a solution toa problem. It is a form of research that is not a[Type text]

separate, specialised technical activity but one which isclosely linked to practice and which can be comfortablyundertaken by practitioners. This is particularly validfor the nature of research conducted in the healthservices sector (Winter and Munn-Giddings, 2001).The principal researcher led the proposed Process Architecturedesign and pattern design and played an integral role withinthe project settings. “Action research aims to contribute both to thepractical concerns of people in an immediate problematic situation and to the goalsof social science by joint collaboration within a mutually acceptable ethicalframework” (Rapoport, 1970, p.499). It also assists to “developself-help competencies of people facing problems” (Susman, and Evered,1978, p.588). It is a scientific research method that has itsroots and methods well established since Kurt Lewin (1946)first introduced the term ‘action research’ as the pioneeringapproach towards social research (cited in Susman, and Evered,1978, p. 586).While different studies classify action research in variousways, most action research follows the traditional ‘plan-do-check’ approach (Chein et al., 1948). We have adapted theSusman, and Evered (1978) five phased action research model,following an ‘experimental action research’ approach (Chein etal, 1948; Susman, and Evered, 1978). The five core phases are;(i) diagnosing, (ii) action planning, (iii) action taking,(iv) evaluating, and (v) specifying learning. The nextsections will describe each of these phases in detail.

Diagnosing

This phase primarily identifies and defines and problem.Health administrations are increasingly experiencing the needfor disclosing their processes and proving the efficiency oftheir occupation. Process modeling methods have proven to bean adequate mechanism in order to achieve transparency, butprocess modeling projects can be very expensive and timeconsuming, often with many external consultants involved(Becker et al, 2003). Thus, a high level framework (pattern)

[Type text]

to depict the major process tasks and flows is proposed as auseful way to get started (Davis and Bradander, 2007).Aligning organisation strategy and the implementation of thestrategy is a challenge faced by all organisations (Smith,2007). The public sector in Australia is faced with anincrease in demand for health services, combined with anageing population and an acute skills shortage5. Overseastrained specialist skills are being sourced to fill this gap,but with such a strategy come complications in terms ofculture, language etc6. It is critical that processes are putin place to ensure that health services are delivered safelyand patient care is optimal. In order to implement anIntegrated Risk Management strategy, it is therefore importantto ensure the implementation of the strategy is structured andclosely aligned to achieving the right outcome.Many organisations in Australia and New Zealand adopt theASNZS4360:2004 standard as the framework to manage risk whichcan be applied to a wide variety and wide range of activitiesfrom the public, private or community organisations and bygroups and individuals (ASNZS4360:2004). The risk managementframework consists of a number of steps which is shown insummary through Figure 2. Appendix 1 provides an overview ofthe standard and its core steps. This framework has beenadopted by the case study organisation as the standardapproach to managing risk in clinical and non-clinical areas.Subsequent policies, procedures and governance processes havebeen implemented by hospitals, clinics and other healthtreatment service centres to ensure compliance.

It is expected that the implementation of the Risk ManagementFramework would provide a systematic process to ensure thatall internal systems promote evidence-based strategies tominimizing risk across the entire organization increasingpatient safety and reducing the risk of harm.

5 See http://www.anu.edu.au/aphcri/Domain/Workforce/Thistlethwaite_3_FINAL.pdf , for further details on the Health related skills shortage in Australia. Last accessed July 14th, 2008.6 See http://www.humanresourcesmagazine.com.au/articles/59/0c028f59.asp for further details on issues with filling the gap with overseas employees. Lastaccessed July 14th, 2008.

[Type text]

Step 1Establish the Context

Step 5Treat the Risks

Step 4Evaluate the Risks

Step 3Analyse Risks

Step 2Identify Risks

Step 7 Com m unicate and

ConsultStep 6

M onitor and Review

Figure 2: Risk Management Framework (Adopted from theAustralian and New Zealand Standard on Risk Management ASNZS

4360:2004)

Action planning

Alternative courses of action for solving a problem areconsidered in this phase. The Program Manager provided theProgram Management Steering Committee, as the GovernanceAuthority, with two alternative approaches to implement theIntegrated Risk Management Program. The alternatives endorsedby the Steering Committee were two fold:Approach 1: Establish a Risk Management policy and allow each business unit toimplement the policy independently.

This would be a typical approach adopted in a large federatedorganisation where the head of each federated unit isaccountable for implementing the policy. Such an approachwould require each jurisdiction to report their alignment withthe policy but manage risk independently within their area.The problem with such an approach is that it becomes difficultto manage risk consistently across the organisation withvarying levels of maturity, budget pressures, skills etc. The

[Type text]

policy is open to interpretation and hence implementationbecomes inconsistent.This approach has been used in the past in the Case Studyorganisation and was the current approach before the IRMProgram was proposed. During the development of the BusinessCase for the IRM Program a significant issue observed was theinconsistent interpretation of the current State-wide policyacross the Health Service Centres.

Approach 2: Implement a process architecture approach

A process architecture approach will provide the structurerequired to ensure that there is clear alignment between thepolicy, procedures, work instructions, business and systemrequirements definition. This approach will use processpatterns to facilitate the implementation of the IRM frameworkindependent of business context areas of Clinical Incidents,Complaints Management and Risk Management.The contexts for each of the three projects was observed bythe business to be very different processes and not related toeach other. Clinical Incident staff such as Nurses andDoctors believed that they were responsible for ensuring thatclinical incidents did not occur while treating patients.Patient Liaison staff responsible for managing complaints madeby members of the public (including patients), felt theirobjective was to investigate complaints and provide feedbackin a timely manner. The only similarities observed by thesestaff were when it came to assessing the risk of each clinicalincident or customer complaint, the investigator identifiedprocess patterns for each business context area to demonstratethat by using a process pattern approach, it was possible toidentify other areas of process synergy and view all threecontexts from the same process pattern. These demonstrationslead to an increased understanding of all the stakeholders ofhow the overarching Risk Management Policy applied equally toClinical Incident, Complaints and Risk Management.

Action taking

This phase deals with the selection of some form of action andthe actual implementation of it. Reforming and aligning theorganisation’s services, processes, people, budgets, locationto the new Integrated Risk Management Policy required aProcess Architecture approach to ensure alignment from theConceptual to the Physical Implementation level in theorganisation.

[Type text]

Given that it is challenging to align policy and outcomes, theprocess pattern approach taken will allow for the effectiveimplementation of strategic policy and operational outcomes.This approach involved a detailed review of the differentbusiness context areas within the organisation and a top-downapproach was designed for this purpose. Figure 3 (accompaniedwith Table 4) depicts the overall approach taken in graphicalform.

Figure 3: Applied six level process hierarchy (adopted fromDavis and Bradander, 2007)

MODELTYPE7

PURPOSE ALIGNMENTATTRIBUTE

TYPE

DESCRIPTION

Contextual

Provides adescriptionof the goalor purpose ofthe process

GoalRequirements

Consists of the BusinessVision, Mission, Goals,Objectives etc. thatdescribe the motivationof the organisation

Conceptual

Describeswhat theprocess mustachieve inorder tosatisfy the

ObjectivesConstructs

The way the organisationis structured to supportthe strategic objectives

7 This also relates to the levels of abstraction of the Process Architecture.

[Type text]

Strategic business objective

An enterprise integrated risk m anagem ent system is im plem entedin all Health Service districts by 200X

Level ABusiness ActivitiesLevel BProcess GroupingsLevel CCore Processes

M eta Data

Level EOperational Process Flows

Operation

al Levels

Level DBusiness Process Flows

Process

Levels

Busin

ess

Levels

Logical Levels

Physical Levels

Level FDetailed Process Flows

Functionally Decom posed as:- Clinical (Clinical Incident, Consum er Feedback etc) - Non-Clinical (OH&S, Security, ICT Risk etc)

Intergrated Risk M gt

EstablishContext

Treat Risk

AnalyseRisk

IdentifyRisk

Value Chain Policy

Business Function

Procedure Business

Requirem ent Spec

End to End process m odel

W ork Instruction Functional

Requirem ent Spec

Steps Solution Design

Spec

Use Case

Program Logic

Logical

Physical

Contextual

Conceptual

Evaluate Risk

Prioritise Risk Categorise Risk Analyse Risk

Prioritise Risk

Investigator

Select Issue

Review Issue

Set Priority

If Risk is Extrem e then set Risk-Lvl to 1 else If Risk is M oderate then set Risk-Lvl to 2… ..… ..

Each level describes business objects within the organisation

Business Objective

high levelgoal

Logical Describes theimplementation criteriafor theprocess - thelogic forimplementingthe processesin aparticularmanner

DesignprinciplesandassertionsLogicalcomponentsandimplementationcriteria

The Policies andProcedures provide theguiding logic for who isresponsible for enactinga process and how itshould be enacted.

Physical An exactdescriptionof what is tobeimplemented

MeasuresPhysicalcomponents

The instantiation of theprocesses which areguided by the workinstructions. Detailedbusiness rules provideguidance on what shouldbe done to complete aprocess.

Table 4: Levels of Abstraction of the Process Architecture(Aitken, 2007).

The researcher reviewed the Health organisation’s strategicinformation to firstly understand how the organisationcurrently implemented Risk Management Policy. Standards,procedures, work instructions, information system solutionsrelevant to risk management were examined to get anunderstanding of how the staff within the organisation enactedthe processes which manage risk within the organisationconstraints (business rules). It soon became apparent thatmanaging risk was a high level corporate goal to provide safeand quality health services to the public. Each federatedhealth service centre was responsible for interpreting theenterprise risk management policy to define internal riskmanagement standards, policies, procedures and workinstruction. Federated information systems were also builtwithin each area to support the capture of incident data foranalysis and reporting. Appendix 2 depicts in detail thebusiness objects that were looked at each main level of theProcess Architecture, demonstrating the artefacts that werereviewed and the model types that were use to depict these(within the Process Architecture). Appendices 3 to 88 contain

8

[Type text]

example models used to document each of the ProcessArchitecture levels.

The levels depicted above in the Process Architecturehierarchy in Figure 3, provides levels of abstraction (theability to decompose a concept, in a structured way to managethe complexity more effectively) in this case within the RiskManagement pattern. Enterprise Architects frequently usethese levels of abstraction to develop and use models of theorganization (Aitken, 2007). In this case study, businessprocess models have been used to provide these levels ofabstraction within the Clinical Incident, Complaints andIntegrated Risk Management business context areas. Each ofthese levels of abstraction are described in the Table 4.

The Risk Management process pattern is embedded from thestrategy, policy and procedure levels right down through tothe lowest program logic level to transparently align theorganization from the top to the bottom. The statewide IRMpolicy (Level C in Figure 3) and procedures (Level D in Figure3) are issued as corporate governance documents to everyHealth Service Centre. Alignment with the policy is monitoredthrough planned audits of each Health Service Centre’simplementation of the corporate policy. The IRM policy isalso used to articulate a set of business requirements for ICTsolutions to support Clinical and Non-Clinical Risk Managementareas. The business processes are embedded in these businessrequirement specifications to communicate how the RiskManagement policy and procedures are to be implemented by

Appendix 3- Level A: Sample Contextual Model of the Integrated Risk ManagementfunctionAppendix 4- Level B: Sample Conceptual Model of the Complaints Management functionAppendix 5- Level C: Sample Process Models (related to Integrated Risk Management) which shows the application of the ASNZS4360:2004 Risk Management framework in the case study organization. Appendix 6- Level D: Sample Business Process Flow Model which shows how risks are treated Appendix 7- Level E: Sample UML Use Case description that was used to document how Risks are assessed.Appendix 8- Level F: Sample Operational Process Flow Model (in BPMN) that depicts the recording of potential and actual incident and intervention information

These clearly demonstrate the funnel like decomposition of complex concepts within each level of abstraction.

[Type text]

other business solutions providers such as trainers, changemanagers etc.Based on the preliminary research conducted at the earlystages of this phase (refer to Appendix 2 for details), aprocess pattern was documented, that described the ‘IntegratedRisk Management Framework’ that describes the essential stepsinvolved in managing risk in the organisation (see Appendix 5). Although the research was a time consuming exercise, thedevelopment of the pattern was relatively quick as a RiskManagement expert was approached to support the documentationand validation of the pattern. As mentioned earlier, Appendix2 provides a list of documents that were provided by the RiskManagement expert and reviewed through out the exercise. Thepattern was then tested during the phased implementation ofthe Clinical Incident and Complaints Management projectsassigned to the researcher with the various stakeholder groupsidentified in the process pattern, who came from an a varietyof service areas within the business.It was important to ensure that this process architecture andpattern approach could be applied independent of the contextof the risk being managed. The areas reviewed as part of theexercise were from within hospital administration, clinicalservice, occupational health and safety, fire safety andbuilding management.Instead of drawing separate process models for each of thethree areas reviewed, the risk management process pattern wasused to validate the process within each risk context area.Typically such projects take life between three to six months(as evidence from archived past project documentation),however, the process pattern approach enabled the researchercomplete the project in one month. Adopting a pattern-basedapproach allowed one model (pattern) to be used to validatethe process at each area with the analysis focusing on thesimilarities and differences between them.

EvaluatingThis phase is dedicated to studying the consequences of theaction(s) taken. As discussed earlier, the pattern basedapproach was very effective to meet with accelerated timeframes and provide quality process models. Figure 4 (together with Table 5) below describes the highlevel approach taken to implement and evaluate the threeprojects. Things were implemented in 6 core role-out phases,

[Type text]

each phase having an evaluation and feedback loop (asdescribed in column 3 of Table 5).

Figure 4: Project Implementation Steps

Step Description of each step EvaluationTechnique(s) used

ProjectScope

Project scope was definedwith key stakeholderssuch as the ProjectSponsor, SteeringCommittee and SubjectMatter Experts. Threehealth service centreswere identified asrepresentative sites fromwhich to gather data.

Face-to-face meetingsScoping WorkshopsReview of StrategicDocuments, standards,external legislation

DefineBusinessBaseline

The As-Is businessprocesses were definedand issues identifiedbased on input fromsubject matter experts ateach of the three sites.Process Pattern for Risk

WorkshopsInterviews withfrontline staffOn the JobobservationsReview of Policies,

[Type text]

Management Documented. Procedures and WorkInstructionsReview of currentInformation Systemsused

AnalyseProcessSynergies

The As-Is processes ateach site were comparedagainst the ProcessPattern to identifyprocess synergies.

Workshops withSubject MatterExperts.

DocumentTargetBusinessProcesses

Target business processeswere defined for eachbusiness context areahighlighting theprocesses that were incommon – RiskIdentification, RiskAnalysis, RiskEvaluation, RiskTreatment and Monitoringand Review

Workshops withSubject MatterExperts

Design NewBusinessSolution

The Target businessprocesses provided thefunctional businessrequirements which weredescribed using Use Casesand the SolutionRequirement Specificationwhich used UML models todescribe the interactionsof the user with thesoftware system

Workshops anddocumentation of thefunctionalrequirements by thebusiness analystJoint ApplicationDevelopment workshopswith the Super User,Business Analyst andSystems AnalystDevelopment and UserAcceptance testing ofthe software system

Implementthe NewBusinessSolution

The new system was rolledout across theorganisation and iscurrent in use today.Change managementtechniques were used totrain staff to use thenew system.

State wide Trainingsessions Communication of theupdated policy,procedures and workinstructions throughthe Intranet websiteLink to the web-

[Type text]

enabled softwaresystem with a UserManual

Table 5: The Project Implementation ApproachHowever, this is not to say that the approach is without itslimitations. Some of the limitations identified throughreflection and observation were as follows: Low level of process architecture maturity. The non existence of a process architecture meant that theresearcher had to develop the process architecture as theproject evolved. The process of discovering and developingpatterns would have been more efficient if an architecture andhence, a structure, defined for discovering and developingpatterns was already in place. Organizational cultural hindrances Typically in large organisations, stakeholders believe thattheir process is ‘different’ or unique and thus, do not lenditself to things that may seem ‘generic’. Patterns on theother hand are generic forms of information (derived throughthe extraction on what keeps on recurring within certaincontexts). A process pattern is a successful tool to initiallyfocus on the similarities in the process (and not thedifferences). When the pattern based approach was applied witheach risk context areas stakeholders, the idea of being toounique hindered its acceptability and created resistance.However, once it was shown that only the terms used todescribe incidents and risk were different, but the processwas essentially the same, the pattern based approach wasaccepted and adapted. In addition to self reflection and observations, evaluativedata were gathered through formal feedback through a series ofinterviews. Clients were asked to provide feedback on theapproach taken during the project and post-project. Clinicaland non-clinical staff positively commented on the reductionin time taken to complete workshops without the need toconsume significant amounts of Subject Matter Expert time.Remarks were made on the quality of the business analysisartefacts, mainly due to the fact that the researcher couldspend more time on reviewing the process models, conductingdetailed analysis and providing recommendations for improvingthe business. A range of specific organisational benefits ofusing a pattern approach were stated during these interviews.They are briefly summarised below.

[Type text]

- Better control on how things are done: An organisation canreduce overhead costs by analysing the most efficient andeffective way to implement a business process to ensurealignment of the business with the strategic objectives.This process pattern can then be implemented right acrossthe organisation to conduct business in a consistent way.- Clearer requirements definitions for Enterprise solutions: Anorganisation should first document the current businessprocess for the ideal scenario (in a pattern) and usethis model (the pattern) to examine the differencesbetween business areas to the pattern/ ideal scenario.Significant differences can then be analysed anddecisions made to standardise the processes (to-bepattern) and define requirements for the Enterprisesolution.-Audit for Compliance: Quality management systems typicallyuse policy, procedures and work instructions to conductaudits. Audits consist of checks to see if a process hasbeen implemented the way it is supposed to. A patternrepository can enable the organisation to assignbenchmarks to the pattern and assist audit the businessarea based on the benchmark.- Communication and transparency on how things are done: Trainingstaff consistently to do the same thing the same way canbe challenging, especially in large organisations. Apattern based approach can be adopted where the processpattern is used to develop training material.

Specifying learningThe goal of this phase is to use a process architecture toimplement process patterns so that these patterns may be usedas a solution to realise an organisation’s strategicobjectives using a structured top-down approach. Eight mainissues were identified as major areas to be addressed whenapplying a pattern based approach. They were classified asProcess Architecture requirements and high and low levelproject requirements. Process Architecture requirements related to (i)Defining a process architecture framework, (ii) establishingstandard terms and definitions. High level project requirementsrelated to the elements that were important at a project levelwhen implementing a pattern based approach and included (iii)the creation of a pattern repository, and (iv) thedocumentation of pattern governance and ownership. The low levelproject requirements were those elements that related to the

[Type text]

individual patterns and consisted of; (v) having differentlevels of abstraction, (vi) fragmentation, (vii) embeddedflexibility and (viii) context specification.Process Architecture requirements

- Defining a process architecture framework

In the absence of literature or empirical evidence, thereis very little guidance on what a good processarchitecture framework looks like, leave alone what aprocess architecture framework should be. It is criticalhowever to define such a framework in order to representthe different levels of abstraction in the organizationand the relationships between the variety of processperspectives.

- Establishing standard terms and definitions

There is a significant amount of ambiguity in theBusiness Process Management domain where terms anddefinitions are confusing. It is important therefore,for an organization to establish a standard set of termsand definitions to reduce ambiguity and establish acommon language prior to proceeding with projects asthese.

High level project requirements

- The creation of a pattern repository

The processes and the frameworks have to be storedsomewhere in order for people to access them. Theserepositories should store the pattern models, the metamodels and the processes on how to use the meta models.

- Pattern governance and ownership

Governance processes should dictate who the patternowners are and ensure that the patterns are reviewedregularly, so that they don’t end up becoming shelfware.Changes in the business environments are inevitable, theimpact of these changes on the process patterns should beevaluated periodically to ensure the pattens continue tobe ’best practice’.

Low level project requirements

- Maintain different levels of abstractions

Every process pattern has to fit with the processarchitecture, otherwise its applicability within the

[Type text]

organisation becomes vague. Thus, each pattern must bewithin the layers of the process architecture, with clearmeta-data on which perspectives it captures and thedegree of detail it entails.

- Maintain fragmentation (for reuse)

Large scale process modelling projects are oftenconducted in a piece mental manner (Green and Ould,2004). End to end processes can be broken down tofragments, where each fragment can be depicted by aprocess pattern , which can be adapted separately. Whilefragmentation, and structured layering of processpatterns is important, an overarching structure (a highlevel pattern) to depict how these fragments fit togetheris very important.

- Allow flexibility and context specificationFlexibility has to be maintained within the patterns toallow minor changes to fit the process/ context . Issuesrelated to flexibility has to be integrated into theguidelines on how to use the patterns (i.e. ’how can oneexpand and edit the models?’ has to be described within thepattern deployment guidelines). What is a detailedpattern within a certain context can be extracted at ahigher level, which can be then used as a pattern at ahigher level across any context (e.g. delivering atreatment in health vs a generic delivery of service).The higher the pattern sits in the Process Architecture(refer to figure 2, Level (i.e. A, B C) compared to lowerlevels (i.e. D, E, F), the more context free it is andhence the more flexible it should be.

Future TrendsThere are numerous opportunities for organizations toadopt a business process management approach thatincludes process architecture to enable the successfulimplementation of organization strategy that is alignedfrom the top level to the implementation level.Organizations using a process architecture approach tolink the various facets of the business to processes willprovide the linkage required to align strategy withoutcomes. This approach can also be used to provide acommon platform to lead valuable discussions betweenvarious functional areas of the organisation and to

[Type text]

identify how each functional area relates and theircontribution to the common goals and objectives.

Further research could be conducted to populate processrepositories consisting of process models at each levelin the organization where these patterns could thenbecome ‘free ware’ and re-usable in the truest sense of apattern in any organization. The identification of theseprocess patterns is worthy of research as businesscontext patterns such as health, manufacturing, researchetc could be shared amongst organizations especially inareas where there is a high degree of commonality inbusiness processes (e.g. Governance, HR, Finance, QualityManagement etc).

ConclusionThis chapter proposed a pattern based modelling approach forhealth services to enhance related business processes. Itdepicted an example of deploying an Integrated Risk ManagementProgram within a large health organisation. The study followedan action research approach within a reputed public heathorganisation, in Australia. It first presented an introductionto the research context, with an overview on the key conceptsapplied and a brief introduction to the case organization. Theresearch design and findings within each phase were thenpresented unfolding the story of how the research conclusionswere obtained. The study’s findings are of benefit to both the research andpracticing communities. In particular, the paper depicted howprocess patterns can be implemented using Process Architectureframework to (i) align organisations strategies to the actualimplementation of these strategies, and (ii) derive a‘standard’ to the services across federated organizationalunits.The study is not without its limitations. Process patterns arepresented here as ‘best practice’ (or ‘better practice’); as apossible ‘standard’ that can be followed within a particularsetting or context. Past evidence has shown that the adoptionof such standards is hindered by lack of stakeholder awarenessand lack of perceived usefulness. Furthermore, processpatterns are relevant only to document a certain limited high-level process flow, and there is a fair amount of skill thatis required by the adoptee of the patterns to usefully apply

[Type text]

it in a given context. Process patterns can have embeddedconstraints based on organisational policies, legislations,culture and varying structures. The notion of 'bestpractices' does not commit people or companies to oneinflexible, unchanging practice, instead, best practices is aphilosophical approach based around continuous learning andcontinual improvement, hence the process patterns need to becontinuously reviewed and updated.The results reported in this paper are the first steps towardsdepicting the value of a pattern based approach for betterprocess management and reform within the health context, andfurther improvements to the reported findings are underway.Means of increasing the awareness of the benefits and buy-infor process patterns (to increase their adoption andproliferation) has to be conducted. More empirical data can tobe collected for triangulation purposes in the evaluationphase of the study design. ‘Usability’ testing (in the form ofextended empirical tests) to identify what further details canbe provided to support the adoption of these patterns withinspecific contexts needs to be addressed. In particular, theintegration of context specific information within the processpatterns (Rosemann, 2006) will be useful to support theadoption of these high-level process patterns within thespecific, detailed processes of an organization. While theprocess patterns provide a useful body of knowledge, thisshould be owned and managed by a process-pattern-owner inorder to sustain its currency and usefulness in this ever -changing environment.

For Health Reform Managers, there is an opportunity to take aholistic approach to reform by identifying process patternsbefore embarking on a reform project. Process patterns canhelp manage behavior and enforce compliance by demonstratingsimilarities between seemingly disparate groups to encouragethe organisation and staff adopt the process pattern as atried and tested best practice method to achieve an objective.Managers can sell their business case for reform moreeffectively by being able to identify areas of synergy throughthe use of the pattern and demonstrating the costeffectiveness of using a uniform approach to manage thereform. The added advantage, of course, is being able todemonstrate the linkage between reform in practice to theoverall organisation goals and objectives.

[Type text]

Key Terms and Their DefinitionsTERM DEFINITION

Best practice The term ‘Best Practice’ is used to describe the process of developing and following a standard way of doing things that can be used (i.e. for management, policy, and especially software systemsdevelopment) by multiple times.

Business Process A business process is a collection of tasks that produce something of value to the organisation, itsstakeholders or its customers.

Business processarchitecture

A business process architecture is a hierarchical structure of process descriptions levels and directly related views covering the whole organization from a business process point of view.It starts with high-level process maps representinga conceptual business view down to the detailed process flow descriptions describing specific tasksand their relation to roles, organization, data andIT systems. (Davis and Brabander, 2007).

Business ProcessManagement

Refers to aligning processes with the organization's strategic goals, designing and implementing process architectures, establishing process measurement systems that align with organizational goals, and educating and organizing managers so that they will manage processes effectively. (http://www.bptrends.com/resources_glossary) last accessed 9/7/2008

Business ProcessModelling

Business process modelling includes techniques and activities used as part of the larger business process management discipline. Business process modelling is an activity performedby business analysts within an organisation. Analysts use modeling tools to depict both the current state of the business and the desired future state.

Business Requirement

A method of describing in business terms of what anorganisation does and how it does it in order to achieve a business objective.

Enterprise Business Architecture

Enterprise Business Architecture provides the guiding framework that describes the relationship between all the parts of the organisation from the strategy to implementation9.

Pattern A pattern in general is “an abstraction from a [Type text]

concrete form which keeps recurring in specific non-arbitrary contexts” (Riehle and Zullighoven, 1995).

Policy A policy is a deliberate plan of action to guide decisions in order to achieve an organisation’s objective.

Process Architecture

The process architecture is one of the facets of the Enterprise Business Architecture, where it provides the framework by which the organisation’s processes are structured. The process architecturemore importantly provides the relationship between the processes to the other facets of the EnterpriseBusiness architecture such as the People, Finance, Location, Governance etc.

Process Modeling Process modeling is an approach for visually depicting how businesses conduct their operations by defining the entities, activities, enablers and further relationships along control flows (Curtis et al., 1988; Gill, 1999).

Risk Management Is the culture, processes and structures that are directed towards realizing potential opportunities whilst managing adverse effects.

Work Instruction The detailed description of the steps person, robotor a computer system must complete in order to fulfill a task.

Value Chain A value chain is a sequence of activities that is initiated by a firm’s customer and ends when that customer receives an outcome (service or product).

Task A task is an atomic activity that is included within a process.

Business Rules Business rules describe how an organisation operates and the constraints under which the operations are performed.

Operations Operations are ongoing recurring activity that a business is involved in. Business operations deliver direct or indirect value to the organisations customers.

9 See The Business Analysis Body of Knowledge www.theiiba.org. Last accessedon 28 Jan 2008

[Type text]

ReferencesAdamides E., D., and Karacapilidis, N. (2006). “A knowledge centred

framework for collaborative business process modeling”, Business Process Management Journal, Vol:12 (5), pp. 557 – 575.

Aitken C., J. (2007). “Design integrity and EA governance”. In P. Saha (Ed) Advances in Government Enterprise Architecture.  Hershey,PA: Idea Group

Alexander, C., Ishikawa, S. and Silverstein, M., (1977). "A Pattern Language: Towns, Buidlings, Construction“, New York: Oxford University Press.

Ambler, S. (2000) "Reuse patterns and antipatterns“. Software development.

Amoroso, D. L. (1998). "Developing a model to understand Reengineering project success", IEEE.

Bandara, W., Gable, G. G., and Rosemann, M. (2005). "Factors and measures of business process modeling: Model building through a multiple case study". European Journal of Information Systems, 14, 347-360.

Becker, J., Kugeler, M., and Rosemann, M. (2003). "Process Managament - a guide for the design of business processes" , springer, Berlin et al.

Chein, I., Cook, S., W., and Harding, J. (1948). "The field of action research" American Psychologist, 3:pp 43-50.

Curtis, B., Krasner, H., and Iscoe, N. (1988). "A field study of the software design process for large systems". Communications of the ACM, 31(11).

Davenport, T. (1993). "Process innovation: Reengineering work through information technology": Harvard Business School press.

Davis. R. (2006). "British Telecom - Six-Level Process Hierarchy", in proceedings of the Process days conference , Sydney, August 22-24, 2006.

Davis R., and Bradander, E., (2007) “Aris Design Platform: Getting Started with BPM”, Springer-Verlag.

Department of Health and Ageing (2007) “Budget statements for 2008-09”,available at http://www.health.gov.au/internet/budget/publishing.nsf/Content/2008-2009_Health_PBS/$File/Department_Overview.pdf, last accessed July 7th 2008.

Department of Health and Ageing (2007) “2003-08 Australian Health Care Agreements - Information sheet number 1 - April 2007”, available at http://www.health.gov.au/internet/main/publishing.nsf/Content/ahca0308-infosheet1.htm, last accessed July 2008.

Forster, F. (2006). "The idea Behind Business Process Improvement: Towards aBusiness Process Improvement Pattern Framework". Business Process TrendAdvisor; 04-06.

[Type text]

Fowler, M. (1997). "Analysis Patterns: Reusable Object Models", (Vol. Reading), Addison- Wesley.

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995). "Design Patterns: Elements of Re-usable Object- Oriented Software", Addison – Wesley.

Gill, P., J. (1999). "Application Development: Business Snapshot -Business Modeling Tools Help Companies Align Their Business and Technology Goals". Information Week.

Green, S., and Ould, M. (2006). "The primacy of process architecture", available at http://www.csm.uwe.ac.uk/~sjgreen/paper2.pdf, last accessed Nov 22nd.

Hammer, M., and Champy, J., M. (1993). "Reengineering the corporation: amanifesto for business revolution". London: Nicholas Brealey Publishing, Allen and Urwin.

Harmon, P. (2003). "Business Process Change: A Manager’s guide to improving redesigning, and automating processes". Amsterdam, Boston: Morgan Kaufmann.

Indulska, M., Chong, S., Bandara, W., Sadiq, S. (2006). “Major Issues in Business Process Management: An Australian Perspective”, to be presented at the Australian Conference on Information Systems (ACIS 2006).

Larsen, M., A., and Myers, M., D. (1998). "BPR Success or failure? A business Process reengineering project in the financial services industry". Communications of ACM, 367-381.

Murphy, F., and Staples, S. (1998). "Reengineering in Australia: Factors affecting success". In proceedinsg of the Australasian Conference of Information systems, Sydney, Australia.

Minister of Ageing, “Historic meeting of ministers for ageing/seniors – responding to Australia’s changing demographics”, Media release, June 12th 2008. Available at http://www.health.gov.au/internet/ministers/publishing.nsf/Content/A58A5B08571D0BDDCA2574650024A4C1/$File/JE082.pdf, last accessed July 7th 2008.

Rapoport, R., N. (1970). "Three dilemas of action research". Human Relations, 23, 499-513.

Reihle, D., and Zullighoven, H. (1995). "A pattern Language for tool construction and integration based on the tools and materials metaphor", In J.O Coplian and D.C Schmindt (Eds.), Pattern Languages of Program Design, Addison Wesley Professional.

Rosemann, M., (2006). "Understanding Context-awareness in buisness process design", to be presented at the Australasian Conference on Information Systems, Dec 6-8 Adelaide.

Smith, H., and Fingar, P. (2003). "Business Process Management. The Third Wave". Tampa: Meghan-Kiffer Press.

Smith, R. (2007), “Business Process Management and the Balanced Scorecard: Using Processes as Strategic Drivers” , John-Wiley and Sons.

[Type text]

Susman, G., and Evered, R. (1978). "An assessment of scientific merits of action research", Vol 25, p 582-603

Taylor, C. (2003). "Reference Models for IT service Provision", Masters dissertation, Queensland University of Technology

Taylor, W., F. (1911). “Modern History Sourcebook: The Principles of ScientificManagement”, available online at http://www.fordham.edu/halsall/mod/1911taylor.html, last accessed, November 22nd, 2006.

The Open Group (2007) “The Open Group Architecture Framework (TOGAF 8.1.1)”, Available at, http://www.opengroup.org/bookstore/catalog/g063v.htm, last accessed July 14th 2008

Van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M. (2003). "Business Process Management: A Survey" in proceedings of the International conference of Business Process Management, Eidhoven, The Netherlands, June 26-27.

Vera, A. and L. Kuntz (2007). Health Care Management Review 32(1): 55-65.

Whittle, R. and Myrick, C (2005), “Enterprise Business Architecture: The formal results between strategy and results”, Auerbach Publications.

Winter R., Munn-Giddings, C., (2001) “A handbook for action research in health and social care”, London ; New York : Routledge.

[Type text]

Appendix 1 – Extract from the ASNZS:4360:2004 Risk Management StandardRisk management involves managing to achieve an appropriatebalance between realizing opportunities for gains whileminimizing losses. It is an integral part of good managementpractice and an essential element of good corporategovernance. It is an iterative process consisting of stepsthat, when undertaken in sequence, enable continuousimprovement in decision-making and facilitate continuousimprovement in performance.Risk management involves establishing an appropriateinfrastructure and culture and applying a logical andsystematic method of establishing the context, identifying,analysing, evaluating, treating, monitoring and communicatingrisks associated with any activity, function or process in away that will enable organizations to minimize losses andmaximize gains. To be most effective, risk management should become part of anorganization's culture. It should be embedded into theorganization's philosophy, practices and business processesrather than be viewed or practiced as separate activity. Whenthis is achieved, everyone in the organization becomesinvolved in the management of risk. Although the concept of risk is often interpreted in terms ofhazards or negative impacts, this Standard is concerned withrisk as exposure to the consequences of uncertainty, orpotential deviations from what is planned or expected. Theprocess described here applies to the management of bothpotential gains and potential losses. Organizations that manage risk effectively and efficiently aremore likely to achieve their objectives and do so at loweroverall cost.The Main Elements of Risk Management are as follows:

Establish the context - Establish the external, internaland risk management context in which the rest of theprocess will take place. Criteria against which risk willbe evaluated should be established and the structure ofthe analysis defined.

Identify Risks - Identify where, when, why and how eventscould prevent, degrade, delay or enhance the achievementof the objectives.

[Type text]

Analyse Risks - Identify and evaluate existing controls.Determine consequences and likelihood and hence the levelof risk. This analysis should consider the range ofpotential consequences and how these could occur.

Evaluate Risks - Compare estimated levels of risk againstthe pre-established criteria and consider the balancebetween potential benefits and adverse outcomes. Thisenables decisions to be made about the extent and natureof treatments required and about priorities.

Treat Risks - Develop and implement specific cost-effective strategies and action plans for increasingpotential benefits and reducing potential costs.

Monitor and Review - It is necessary to monitor theeffectiveness of all steps of the risk managementprocess. This is important for continuous improvement.Risks and the effectiveness of treatment measures need tobe monitored to ensure changing circumstances do notalter priorities.

Communicate and Consult - Communicate and consult withinternal and external stakeholders as appropriate at eachstage of the risk management process and concerning theprocess as a whole.

The Risk Management Standard provides a generic guide formanaging risk in any organisation context whether it ispublic, private, community, enterprise or individual. It isthus a scalable framework that can be applied quitesuccessfully independent of industry or economic sector.

[Type text]

Appendix 2 – Case Study Sample DocumentsThe table below catalogs the documents that were reviewed as part of the research project. Whenconducting a document review, each document was categorized into the relevant Process Architecture Levels to identify what type of business object needed to be identified and reviewed. The principal researcher then selected the appropriate model type to be used to capture the relevant information about the business object. Adopting this approach provided a structured method for gathering and analysing information that is relevant to the exercise and supports the implementation of a Process Architecture approach.

Process Architecture Levels

Business Objects Artifact Reviews – Content Extracted Model Type

A Business Objective

Strategic Plan - Provide safe and sustainable services

Contextual Model drawn using blocks, arrows, triangles

Organisation function chart

B Business Functions

Function Groupings from Organisation Charts:Clinical Incident ManagementComplaints ManagementIntegrated Risk Management

Service groupings Functional perspective Conceptual models

C Policy Review of Policy Document to extract Value Value Chains End-to-end processes using

[Type text]

Chains and IDEF0 models:Clinical Governance PolicyConsumer Complaints Management Policy Integrated Risk Management Policy

BPMN or IDEF0 Logical models

D ProcedureBusiness Requirement Specifications

For each Business Context Area IDEF0 models weredrawn:

- Implementation Standards and Procedures e.g. Management of Clinical Adverse EventsProcedure, Consumer Feedback Management Procedure

- Business Requirements Specification consisting of AS-IS process models

BPMN Process Model, IDEF0 or IDEF3, UML Workflow

E Work Instructions

For each Business Context Area at each Health Service Centre an example of the Work Instruction artifacts observed to define Use Cases:

- Incident Reporting using the Central Information System Database

- Receiving a Complaint Work Instruction- Pressure Area Care Work Instruction

As part of the Business Analysis activities,

BPMN Activity Model, Use Cases

[Type text]

Functional Requirements Specifications were created for each of the three Business Context Areas.

F Steps UML Workflow models were used to depict workflow:The Corporate Integrated Risk Management Solution was built based on detailed Solution Requirement Specifications defined for each of the three Business Context Areas.

Flowcharts, System Flow Chart, Data Flow Diagram

[Type text]

Appendix 3 - Level A Contextual Model – Integrated Risk ManagementThe Model below was used to show conceptually how the Integrated Risk Management function collectively supports the achievement of the case study organisation’s strategic objective. Themodel also shows how the Integrated Risk Management function is structured within the organisation.

Integrated Risk M anagem ent

Nam eTitle

Nam eTitle

Com plaints M anagem ent

Risk M anagem entClinical Incident

Provide Safe and Sustainable Services

Supports the Strategic Objective

[Type text]

Appendix 4 Level B – Conceptual Model – Complaints ManagementThe IDEF0 High-Level A0 model was used to define the scope of the Complaints Management function. The same approach was taken to identify the scope of the Clinical Incident and Integrated Risk Management functions.

[Type text]

NO DE: TITLE: NO.:Com plaints M anagem ent 1A-0

0A0

M anage Consum er Feedback

Q H StaffBranch/District M anager

Com plaints Coordinator

Industrial Relations M anual

Feedback ReportsFeedback Acknowledgem ent

Consum er Feedback

ICFDBeethoven

Com plaints PolicyGuidance Docum ent

Feedback ResponseOrganisation Im provem ent

InitiativeIdentified Risks

External Parties

[Type text]

Appendix 5: Level C Process Models – Integrated Risk ManagementIDEF0 was used as the notation to document the end-to-end process (value chain) for all three projects. Below is an example of the IDEF0 model which shows the application of the ASNZS4360:2004 Risk Management framework as it is implemented in the case study organisation. The same pattern was used to document the Clinical Incident and Complaint Management Processes.

[Type text]

Nam es have been blocked to m aintain anonym ity

[Type text]

Appendix 6 – Level D Business Process Flow Model – Treat RisksThe following IDEF0 business process flow model was used to document how Risk is treated within the case study organisation. This pattern was used to validate that risk is treated the same way in Clinical Incident, Complaints and Risk Management.

[Type text]

1

Identify Treatm ent Options

3

Develop Treatm ent Plan

4

Im plem ent Treatm ent Plan

2

Assess Treatm ent Options

Risk Treatm ent PlanUpdated Risk Register

Identified Treatm ent Options

Feasible Cost Effective Treatm ent Options

Risk Treatm ent Plan

Risk Register

Risk Register

Cost benefit analysis

Identified Accountable Person

Accountable Person

Risk M anagem ent Co-ordinator Risk treatm ent plans

Risk treatm ent plans

Risk treatm ent plans

Risk M anagem ent Co-ordinator

Risk M anagem ent Co-ordinator

Evaluated Risk

Organisation Im provem ent Initiative

Local Procedures and W ork Instructions

[Type text]

Appendix 7 – Level E Use Case – Complaints Management – Assessing RiskThis is an example of the UML Use Case that was used to document how Risks are assessed. This Use Case is meant to show how business rules are applied and cause branchesin logical flow. Use Case provided the Solution Requirement specifications to the IT software developmentgroup on how a solution is required to interact with the User/Actor.

Use Case ID: UC-04 Process Num ber A44 Output Update Complaints Risk Register Use Case Name: Update Com plaints Risk Register – Assess Risk

Actors: Executive Officer Description: Add an actual or potential consequence to the Com plaints Risk Register.

Preconditions: 1. Open complaint issues have not been risk assessed Postconditions: 1. Issues are added to the Risk Register Norm al Flow: 1. The Executive Officer selects to update the Complaints Risk Register

2. System displays a list of Feedback Forms and open com plaint issues sorted in Date Received order (m ost recent last) – see Appendix O.

3. The Executive Officer selects to view one of the listed Complaint Issues. 4. The Executive Officer requests a new consequence type be added to the

Com plaint Issue 5. The Executive Officer selects a consequence type 6. The Executive Officer selects a degree of severity 7. The Executive Officer repeats steps 4 to 5 until all consequence types are

entered. 8. The Executive Officer selects a likelihood 9. The system generates an overall risk rating 10. The system records the details of the person updating the risk register

Alternative Flows:

10a The Executive Officer wants to add comments for the risk assessm ent 1. The Executive Officer selects to add comments to the risk register 2. The Executive Officer enters in comments for the risk register

Business Rules: Every complaint issue m ust be risk assessed The history of risk rating changes will be stored.

Data Elements: Entered (Represented in the order entered by the actor)

Accessed by system

UC-04.1 Risk Consequence Type UC-04.2 Likelihood UC-04.3 Degree of Severity UC-04.4 Risk Assessment

Com ments

F eedback Number Issue Number

System Generated Risk Assessment Date Overall Risk Rating Issue Status Risk Recorded by F irst Name Risk Recorded by Surname Risk Recorded by Position

[Type text]

Appendix 8 – Level F Operational Process Flow ModelThis is an example of a detailed Operational Process Flow Model. Typically, Systems Analysts use these types of model to document how a software developer will convert the business logic and business rule into software syntax. The human-computer interaction is also depicted in these models to clearly demonstrate when the user is required to interact with the software system. Recording Potential and Actual Incident and Intervention Inform ation

First P

erson

Line Manager

An incident occursTake

im m ediate action

Detect the incident

Assess incident for severity (risk

rating)

Assess incident for severity (risk

rating)

Classify by typeRecord details of incident

Classify by typePartially

com pleted clinical incident form

[Type text]