The 3-layer Process Architecture for Business Process Management

Student: Hemkumari Bujary Supervisor: Professor Brian C Warboys Date: May 2 2007

The 3-Layer Process Architecture for Business Process Management

Student: Hemkumari Bujary Supervisor: Professor Brian C Warboys Date: May 2 2007

Abstract
This project consists of evaluating the Riva methodology described in Martyn Oulds book, Business Process Management: A Rigorous Approach, BCS 2005, for understanding a business. In this case being able to develop a business process management system using ProcessWeb is a way of validating the Riva models. A case study, Redmayne-Bentley Stockbrokers which is a stock broking company, was analysed. Its processes were modelled by a process architecture diagram and role activity diagrams, followed by implementation in Process Management Language, and finally an evaluation about the approach suggested was produced. It was concluded that the Riva methodology, if used properly, could be very useful for organisations as the classification of their processes according to the 3-Layer Process Architecture provided a profound understanding of their businesses.

Acknowledgements
I would like to thank my supervisor, Professor Brian C Warboys, and Dr. Mark Greenwood of Informatics Process Group for their support and suggestions. This project would have been a hard task without their help. I am also grateful to my parents, my sister and all those who are close to me for motivating and encouraging me throughout the year.

Table of Contents
Chapter 1 Introduction........................................................................................... ..7
1.1 Business Process Management ............................................................................... 7 1.2 Business Processes ................................................................................................... 7 1.3 Objectives of this Project......................................................................................... 7 1.3.1 Main Objectives ................................................................................................ 7 1.3.2 Secondary Objectives ....................................................................................... 8 1.4 Proposed Model Features ........................................................................................ 8

Chapter 2 Background ............................................................................................. 9

2.1 The 3-Layer Process Architecture .......................................................................... 9 2.1.1 The Case Process ............................................................................................ 11 2.1.2 The Case Management Process ..................................................................... 11 2.1.3 The Relationship between Case Process & Case Management Process ..... 12 2.1.4 The Case Strategy Process ............................................................................. 17

Chapter 3 Business Process Modelling and ProcessWeb ......................... 18

3.1 Business Processes ................................................................................................. 18 3.2 The Core of Business Process Modelling ............................................................. 20 3.2.1 Principles for Process Modelling ................................................................... 20 3.2.2 Building a Process Architecture .................................................................... 21 3.3 ProcessWeb and PML............................................................................................ 22 3.3.1 ProcessWeb ..................................................................................................... 22 3.3.2. Process Management Language (PML) ....................................................... 24

Chapter 4 The Case Study and Process Architecture Diagram ........... 25

4.1 The Case Study: Redmayne-Bentley Stockbrokers ............................................. 25 4.1.1 Background ..................................................................................................... 25 4.1.2 The Textual Model ......................................................................................... 26 4.2 The Process Architecture Diagram ....................................................................... 28 4.2.1 Deriving the Process Architecture Diagram ................................................. 29

Chapter 5 Modelling and Implementation..................................................... 31

5.1 Process Architecture Diagram to RADs. .............................................................. 31 5.2 Converting RADs to PML ..................................................................................... 38 5.3 User Interface of Enactment System .................................................................... 40 5.4 Interesting Aspects ................................................................................................. 42

Chapter 6 Evaluation .............................................................................................. 43

6.1 Phase 1: Evaluation of Process Architecture Diagram ........................................ 43 6.2 Phase 2: Evaluation of Role Activity Diagrams .................................................. 44 6.3 Phase 3: Evaluation of Enactment System ........................................................... 44 6.4 Evaluation of the 3-Layer Process Architecture .................................................. 45

Chapter 7 Conclusion .............................................................................................. 47

7.1 The Modelling and Implementation of Processes ................................................ 47 7.2 Learning Outcomes and Difficulties. .................................................................... 48 7.3 Planning and Progress Management ..................................................................... 49 7.4 Future Work Recommendations. .......................................................................... 50

References..................................................................................................................... 51

List of Figures
2.1 The 3-Layer Process Architecture............................................................................. ..9 2.2 The basic service relationship ...................................................................................13 2.3 The basic service relationship with negotiation .......................................................14 2.4 The general service relationship................................................................................15 2.5 The general task force relationship ...........................................................................16 3.1 The Structure of a Business Process ......................................................................... 19 3.2 Development Service provided by ProcessWeb ....................................................... 23 3.3 ProcessWeb Browser for user Hem and the enactment of process models ............ 23 4.1 The UOW diagram for Redmayne-Bentley .............................................................. 28 4.2 The first-cut process architecture .............................................................................. 29 4.3 The second-cut process architecture ......................................................................... 30 5.1 Role Activity Diagram for Handle a Prospective Client ......................................... 32 5.2 Role Activity Diagram for Handle a Client Account............................................... 33 5.3 Role Activity Diagram for Handle an Error ............................................................ 34 5.4 Role Activity Diagram for Handle New Software Product ..................................... 35 5.5 Role Activity Diagram for part of Carry out Strategy Review process .................. 36 5.6 Role Activity Diagram for part of Carry out Tactical Review process .................. 36 5.7 Role Activity Diagram for Manage Project for New Software Product ................. 37 5.8 The enactment system of Redmayne-Bentley Stockbrokers ................................... 39 5.9 User interface of the Account Role ........................................................................... 40 5.10 User interface of an instance of the Prospective Client Role ................................ 41 5.11 User interface of an instance of the Agent Role .................................................... 41 6.1 Modelling and implementation of Handle a Prospective Client ............................. 47 6.2 Modelling and implementation of Handle a Client Account .................................. 48 7.1 The Project Plan ......................................................................................................... 51

Chapter 1 Introduction
Martyn Oulds book, Business Process Management: A Rigorous Approach describes a 3layer process architecture for business processes. It explains the use of the Riva approach to understand businesses from a process perspective. This project consists of the evaluation of Riva as a methodology for understanding a business. In this case being able to develop a business process management system using ProcessWeb is a way of validating the Riva models.

1.1 Business Process Management

Business Process Management is a new technology that has brought radical changes to the way business processes were viewed in the past. It provides a detailed understanding of business processes and how useful they are when organisations want to change their operational methods and evolve.

1.2 Business Processes

Processes are usually described as things carried out by organisations so that they can reach certain outcomes. Business processes are similar to processes, but differ in the sense that business processes are processes in what the organisation gets up to [1].

1.3 Objectives of this Project

The project has both main and secondary objectives and a summary of these is given below.

1.3.1 Main Objectives

To obtain an understanding and appreciation of the Riva business process modelling method and the 3-layer process architecture which are described in Martyn Oulds book Business Process Management: A Rigorous Approach BCS 2005. To design, implement and produce an evaluation of the business process models according to the methodology and techniques of the 3-layer architecture. Process

Architecture Diagrams and Role Activity Diagrams as described by Riva and an Active Process Model developed using the Process Web toolkit will be the models developed as part of the project. (ProcessWeb is developed and maintained by the Informatics Process Group at the School of Computer Science, University of Manchester - http://processweb.cs.man.ac.uk). Users should be able to interact with the business process models and observe their dynamic behaviour via the Active Process Model system. To compare the evaluation from last years project and that of this project and see the similarities and differences.

1.3.2 Secondary Objectives

To gain sufficient knowledge of the case study to be used for the business process models so that its processes can be modelled properly and accurately. To be able to use Process Management Language of the ProcessWeb toolkit for the implementation of the Active Process Model. To acquire the experience and self-discipline needed to successfully carry out a project.

1.4 Proposed Model Features

The modelled and implemented system should reflect the 3-layer architecture. The project is to apply the architecture mentioned above to an appropriate case study and implement a business process management system in ProcessWeb. In this project, Redmayne-Bentley Stockbrokers will be the case study and the 3-layer process architecture will be applied to its business processes.

Chapter 2 Background
This chapter will provide a detailed description of the 3-Layer Process Architecture, which is central in this project. The three different types of processes, namely the Case Process, the Case Management Process and Case Strategy Process, will be explained, and examples will be given for each one of them.

2.1 The 3-Layer Process Architecture

The 3-layer process architecture from Martyn Oulds book, Business Process Management: A Rigorous Approach, is the main topic of discussion in this chapter. According to Martyn Ould, the activities or processes of any organisation can be classified into three different types. He suggests that any process is part of a Case Process, or a Case Management Process, or a Case Strategy Process. His hypothesis provides the most crucial basis to the architecture to be explored. Business Processes in any organisation are arranged according to three layers in the 3-layer Process Architecture. The three layers are as follows: Case Processes Processes that follow a customary set of procedures, for e.g. handle a client query Case Management Processes Processes that deal with the flow of instances of cases, for e.g. reporting, monitoring requests from case processes instances Case Strategy Processes Processes that collect all strategic views from case processes and case management processes, and ensure that the processes are following appropriate rules and regulations, for e.g. maintain a strategic view of services purchased

Figure 2.1 The 3-Layer Process Architecture

Unit of work (UOW) Handles a single case of the UOW through its lifetime

Case Process

Cases

Case Management Process

Manages the continuing flow of cases of the UOW, monitoring over the medium term, scheduling, and prioritising case process instances

Case Strategy Process

Observes long-term performance and trends, makes predictions, and determines the strategy for the case and case processes in the future

(Martyn Ould Business Process Management: A rigorous approach, BCS 2005)

10

2.1.1 The Case Process

Martyn Ould states that every organisation has units of work. If we look at the software development department of an organisation, we shall see that developers work on various projects for different clients or applications. A particular project is therefore a unit of work for that organisation. Every piece of work, starting from the approval of the contract to the delivery and sign off of the software product to the client, is a case of the unit of work project. Similarly, in a stock broking company, a stock purchase is a unit of work and so is an error reported about a particular service by a client. The organisation will have many cases of units of work at different stages at any one point in its lifecycle. Whenever a case is generated, there exists a standard way to handle it. This illustrates the fact that every case follows a similar procedure or process. This process is known as the case process. This will be the process that looks after, or deals with, or handles a case during its lifetime. [Martyn Ould, Business Process Management: A Rigorous Approach, Chapter 5: The three basic process types, p3, BCS 2005] Martyn Ould proposes a naming convention for the three processes in the architecture to be able to differentiate them from one another. Therefore a case process is referred to by using Handle a or Prepare a. If the unit of work is seen as a trigger or an input to the case process, then Handle a is used. For e.g. handle a stock purchase order. If the unit of work is seen as the output or outcome of the case process, then Prepare a is used. For e.g. prepare a list of errors reported by clients. In situations where the unit of work cannot be classified as an input or an output, Handle a is used. For e.g. handle a marketing campaign for a new service. Cases do not have a minimum or maximum lifetime. Thus the naming convention of case processes is as such to allow other outcomes or possibilities to be open for the cases and also to avoid inaccuracies.

2.1.2 The Case Management Process

There is a corresponding case process for every unit of work. At any one point in the lifecycle of a unit of work, there may be many cases or instances of that case process. The organisation will need a mechanism to be able to manage the flow of cases, which run simultaneously. It will have to be able to address issues like planning, reporting, scheduling, prioritising, task allocation and so on. This is where case management processes come into the equation. There exists a case management process which manages the flow of cases of every unit of work in any organisation. Case management processes are quite complex. Their mechanisms allow them to take accurate action in accordance to various states. Martyn Ould indicates that case management processes have several triggers to respond to different stimuli and they all produce individual result(s).

11

Furthermore, just like with case processes, Martyn Ould proposes a naming convention for case management processes. Case management processes are identified by the words Manage the flow of. For e.g. manage the flow of errors reported. This naming convention is to ensure that it is understood that case management processes are responsible for managing cases.

2.1.3 The Relationship between Case Process & Case Management Process
A unit of work can be regarded as a case process and it needs a case management process to manage it. These are two separate processes, but there exists a relationship between how the work is dealt with (case) and how it is managed (case management).

The Service Relationship Consider the IT department of a stock broking organisation where a unit of work would be a list of projects. A request for a new financial software product arrives and the Handle a request process runs. The order can only be satisfied if the new software product is developed. The IT department may already have other software products that are under current development, so an instance of that process can immediately launch the Prepare a project process. The new software product request will be placed in the list of software development projects. This is where the case management process comes into action, Manage the flow of projects. Thus an instance of Handle a request will interact with Manage the flow of projects to ask for a new project to be added to the list of projects. Manage the flow of projects will instantiate the Prepare a project process when the time scheduled for it arrives. As soon as the project has been created and the software product has been developed, it will be handed over to Handle a request by Prepare a project. Figure 2.1 shows the relationship between processes, which is an example of the service relationship.

12

Figure 2.2 The basic service relationship

Handle a request

requests delivers to

Prepare a project

starts

Manage the flow of projects

Actually there exists a negotiation between Handle a request and Manage the flow of projects. This could consist of rescheduling certain projects and development work so that to meet goals and therefore this requires further negotiation with the projects involved. The negotiation is usually achieved by the interaction between Manage the flow of projects and Manage the flow of requests and all issues that arise are dealt with by the case management process for requests. Figure 2.2 shows the service relationship involving negotiation.

13

Figure 2.3 The basic service relationship with negotiation

Handle a request

Manage the flow of projects

requests delivers to negotiates negotiates

Prepare a project

starts

Manage the flow of projects

There may be other simple management links between the case process and case management process. The case management process will monitor the behaviour of the case process and will intervene if necessary, for e.g. if there are modifications in scheduling or resourcing or even stop the process in critical situations. The case process in turn has to report its status and exceptions and managerial issues that may arise to the case management process. These relationships are shown in Figure 2.3.

14

Figure 2.4 The general service relationship

Handle a request

Manage the flow of projects

requests delivers to negotiates negotiates

starts Prepare a project monitors intervenes stops reports Manage the flow of projects

The relationships shown between Manage the flow of projects and Prepare a project also exist between Manage the flow of requests and Handle a request.

The Task Force Relationship If the service relationship described above is analysed thoroughly, it will be obvious that developing product software is a permanent service offered elsewhere and/or by someone else [1]. This service is used when a new software product is required. Thus it can be concluded that the operation of the service does not depend on the processes that use it. A distinct service to do a specific job is not always required; the job could be done by other means. Those other means are known as a task force. Let us again consider the IT department of a stock broking organisation. The IT department develops financial software products for the organisation. Run a project is one of the case processes in that department. Each single project is organised into various individual software components, which provide the specification, design, implementation, testing of the software product. Since the software component is a unit of work, therefore the IT department will have a Do a software component case process. If a project needs work to be done on a software component, it does not have to interact with a separate Manage the flow of software components process, in other words it does not have to interact with an independent software

15

component service. The project is responsible for managing the flow of software components itself; this process forms part of the Run a project process. There is a task force which follows the required procedure for software components and it also creates every software component. A case management process is still used for the scheduling, prioritisation, resourcing and so on of the software components, but it is not a separate process as it is included in the Run a project process. The service relationship and task force relationship are quite similar; the only difference is that in the case of the service relationship, Handle a request and Manage the flow of projects are independent processes which interact with each other when necessary whereas in the case of the task force, Manage the flow of software components is encapsulated inside Run a project. Figure 2.4 illustrates the general task force relationship and it is worth noting that there is no negotiation ever carried out across projects as the flow of software components is managed inside the running of the specific project which requires it.

Figure 2.5 The general task force relationship

Run a project

requests delivers to negotiates

starts Do a software component monitors intervenes stops reports Manage the flow of software components

16

2.1.4 The Case Strategy Process

Case processes handle one case of a unit of work at a time and case management processes manage the flow of cases. These are the definitions of the activities that have been gathered in any organisation so far, but there is still an unexplored activity which consists of viewing the whole organisation strategically in the long-term. Martyn Ould states that, the case processes are about front-line, coal-face activity; the case management processes are about managing that coal-face activity [1]. Case strategy processes are responsible to analyse units of work from a strategic view and run case processes and case management processes correspondingly. The primary concerns for case strategy processes are their case processes and case management processes. The case strategy process analyses all the factors both inside and outside the organisation which could affect the units of work and any other changes that occur. It ensures that the case processes and case management processes are operating according to the rules and regulations of the organisation. It also assesses the performance of the units of work and how improvements could be made. All these strategies are gathered into the case strategy process for future use. The case strategy process usually has many threads. These can be initiated by events that could happen within or outside the organisation and they need to be resolved. The threads could also be triggered according to a calendar and demand regular strategic reviews due to trends in the organisation or industry. In both situations, the actions taken by the case strategy process will be modifications or sets of instructions to its case processes and case management processes. The case strategy process has its naming convention as well, like the two other processes, case process and case management process respectively. It is commonly identified by the following phrase, Maintain a strategic view of. For e.g. Maintain a strategic view of errors, Maintain a strategic view of clients. The aim here is to concentrate on the precise area of concern of this process and to make it distinctive.

17

Chapter 3 Business Process Modelling and ProcessWeb

This chapter describes business processes and the essence of business process modelling. It also explains the principles of process modelling and how to derive a process architecture. Finally it gives details of what ProcessWeb and Process Management Language are.

3.1 Business Processes

Business processes are defined as the activities that are carried out by organisations which are in a particular business. The outcome of these activities is the achievement of the organisational aims. Therefore it could be said that business processes are collaborative activities that organisations in specific businesses undertake to reach their aims. Detailed understanding of the business that an organisation is in is required to be able to classify the organisational activities into specific processes. For e.g. Redmayne-Bentley Stockbrokers is an organisation which is in the business of providing financial services to clients. It is of vital importance to get the business processes correct as they help the way in which the organisation operates, increase efficiency, profitability and customer service of the organisation and also strategies to be applied in the long run.

Another attempt to define a business process is illustrated in the diagram below. Here a business process is described as a set of collective activities which are performed in a specific order, i.e. it has a starting point and an ending point and it enables organisations to achieve outcomes that they want by means of various inputs and outputs. The primary focus of a business process is how work is carried out in an organisation.

18

Figure 3.1 The Structure of a Business Process

[http://www.sparxsystems.com.au/downloads/whitepapers/The_Business_Process_Model.pdf, Accessed on 15/04/07]

19

3.2 The Core of Business Process Modelling

The notion of process modelling is applied by organisations or software engineers when they are identifying and developing business processes. Martyn Ould introduces this concept in his book, Business Process Management: A Rigorous Approach. He mentions the changes that are occurring in the world of processes and how business processes are evolving. According to him, there are three waves of business processes. Initially, i.e. in the first wave, processes were just considered as a way of doing things or very rarely, they would be in the policy and procedure manuals. Flowcharts would be used to represent processes and this would be done in order to try to understand these processes and make small-scale improvements to them. In the second wave, processes initially became the unwitting victims of the information system developers: information was on top [1]. This means that developers analysed how information was manipulated in information systems and then they created the business processes instead of using business processes to design the information systems. Business processes were often re-engineered to best practice or world class practice and this costs huge sums of money. Thus processes were only regarded and used as a means to reinforce information. However, there is a third wave now which has business process management (BPM), recent technology, as a core basis. Business processes are the deterministic factors about how information should be manipulated and what information needs to be stored. More emphasis is now placed on business processes than on information. Organisations can therefore change the operational methods of their businesses easily how and when they want to. Today processes are distinctive in organisations and they can be executed, modified and monitored on a process enactment engine as businesses evolve in real-time. The management of business processes is the main priority and job of information systems used by organisations as well as managing information. Such systems are known as business process management systems BPMSs and these latest trends in the world of information systems require suitable methods to identify, analyse, design, implement, evaluate and use processes. Therefore, it can be concluded that the main aim of business process management systems is to enact models of business processes.

3.2.1 Principles for Process Modelling

Riva is the approach described in Martyn Oulds book for modelling processes and it is also the methodology used to derive the 3-layer process architecture. For Riva to be applied correctly, crucial principles have to be taken into consideration. These are: If you must have abstractions, make them believable. Any process modelling notation must deal in concepts that people relate to. Otherwise how can they tell if a model is right?

20

The real world is messy. The notation must be able to model mess when necessary. Muddle modelling is the norm, not the exception. A model must mean something and only one good thing. ambiguous, how can you tell what it is telling you? If your model is

Process models are about people, and for people. The notation must make sense to people. If you cannot explain the model in ten minutes, it does not make sense. There is what people actually do. And there is what they effectively do. These are different and we must be able to model both. People do processes, but they work in functions. These two mess each other up. A model must capture both and the conflict. It is what people do, not what they do it to, that counts. A process is about doing, deciding, and cooperating. Not about data.

[Martyn Ould, Business Process Management: A Rigorous Approach, BCS 2005]

3.2.2 Building a Process Architecture

Process architectures are of utmost importance for organisations. They act as visual aids to know the different processes in the organisations and how they interact with each other dynamically. It is therefore primordial to build process architectures accurately to avoid getting entangled with complicated unwanted processes. The main aim of process architectures is to capture the network of concurrent activity in organisations [1]. This implies that intensive knowledge about the business carried out by the organisation is required as only then can a process architecture be derived from it. In this case, the Riva approach will be applied to derive the process architecture of the case study that will be discussed in the next chapter. The first step proposed by Martyn Ould to build a process architecture using the Riva approach is to explore the organisation and classify the business it is in. This is achieved by detailed research into its essential business entities EBEs, which are things that are at the heart of the organisation and determines the business the organisation is in. For e.g. in a stock broking company, there will be entities like Software Product, Client, Services, Shares, Market and many others. The Riva approach then consists of the following phases: Identify the essential business entities of the organisation interested in or part of that organisation by brainstorming.

21

Select more significant units of work from the list of essential business entities and these can be either designed or essential units of work. Create a unit of work diagram to demonstrate the different types of relationships between various units of work. Produce the first-cut process architecture by transforming the unit of work diagram using specific methods. Verify if there are task force relationships, thus some processes can be encapsulated. Test the process architecture by applying it to the real-world to see if the relationships are accurate and lastly build the final architecture with all the necessary changes made to produce the second-cut process architecture.

3.3 ProcessWeb and PML

There are various tools available to model processes and enactment engines. However, in this process, the process model of part of the organisation was implemented in Process Management Language and enacted on ProcessWeb.

3.3.1 ProcessWeb
ProcessWeb is a system built to support process modelling dynamically. It ensures its smooth operation and execution via the World Wide Web. It was created in 1997 and it is being continuously improved as new process models are executed. The ProcessWise Integrator system forms an integral part of ProcessWeb as it provides the environment to run process models. A user ID and password are needed to log into ProcessWeb. There are two services available, Demonstration service and Development service. Demonstration service This service can be used by anyone who is interested in ProcessWeb and wants to use it to see what the environment is like. A Guest User ID is required for this service and can be acquired by clicking on a specific link and following the instructions on the login page.

Development service This service is used to test new developments (either new models, or development work on the ProcessWeb system itself). It may be cleared and rebuilt fairly frequently (this will cause all model instances and guest users to be destroyed) [8].

22

Figure 3.2 Development Service provided by ProcessWeb

Figure 3.3 ProcessWeb Browser for user Hem and the enactment of process models

23

3.3.2 Process Management Language (PML)

Process Management Language PML is an object-oriented language. It allows the implementation of several process models. These processes are very complicated and often have various activities occurring simultaneously, but PML can handle such complexities as it has been created for this purpose in particular. Process Management Language enables programmers to perform several tasks. These are: Describe objects upon which users might carry out some tasks (e.g. a document) Define the tasks that users have to do (e.g. edit and review a design specification) Describe the tools which they use to carry out a task (e.g. a word processor) Define the means of communicating changes to a users working environment, or to the working environment of other users (e.g. a review process) [7]

Features of PML Processes basically consist of a number of activities. Activities which are related to one another are represented as a role in PML. A role in PML is in fact a persons role in real life. Roles are usually created by programmers and they contain actions (code) and resources (data). Roles are active objects which contain data and may execute actions. [8] Roles can communicate with one another and this possible due to the mechanism of interaction. Interactions allow messages to be sent and received among roles or external sources, for e.g. other persons or applications. This is achieved by assigning giveport and takeport to the appropriate roles. PML is a class-oriented language and it supports inheritance. The classes are namely, role, entity and action. The main and most crucial characteristic of PML is that it is a persistent language. This is one of the fundamental reasons for choosing PML to develop process models rather than other languages. Every time a message is received from the user interface, the state of the PML application is committed. This means that in the event of a system failure, the application will restart automatically from the most recent committed state, provided the disk has not been corrupted. The content of any interaction is also retained, so that a PML application may completely ignore failures and still run. [7]

24

Chapter 4 The Case Study and Process Architecture Diagram

This chapter consists of two main parts, the first part is about the case study being analysed in this project and the second part explains how the 3-Layer process architecture is applied to this particular case study and how the process architecture is derived. Since time is limited and the organisation to be analysed is beyond this project, therefore only part of this organisation will be looked at.

4.1 The Case Study: Redmayne-Bentley Stockbrokers

4.1.1 Background
Redmayne-Bentley Stockbrokers is one of the biggest independent stock broking companies in the UK. John Redmayne founded his own company in 1875 and began to carry out business dealings with the Leeds Stock Exchange. The success of the business around this time was due to the boom in the private railway companies. After surviving both world wars and 90 years of business Redmayne & Co merged with neighbouring Leeds firms F W Bentley & Co. and J W Granger & Co. in 1965, to form Redmayne-Bentley. [5] In 1986 the branch network developed as a side effect of the 'Big Bang' reform of the stock broking market. Many small stockbrokers were swallowed up by banks and conglomerates and a gap opened up in the market. Redmayne-Bentley has tried to fill this gap by providing friendly, personal and local service throughout the country. Whilst using new technology to keep pace with the changing market Redmayne-Bentley still holds on to the traditional values and offer the close personal service John Redmayne applied to his business back in 1875. [5] Today Redmayne-Bentley has several branches all over the country. Its motto is Your friend on the Stock Exchange and it aims to simplify the dealings on the stock market and thus attract potential clients as well as retain existing ones. Redmayne-Bentley offers both professional and personal service at three levels: Execution only, Advisory, and Discretionary Portfolio Management. [5]

25

4.1.2 The Textual Model

Redmayne-Bentley provides various services to its clients such as PEP Transfers, ISAs, Child Trust Funds, Nominee Service, CREST Personal Membership, Portfolio Services, Traded Option, Overseas, Online Dealing, SIPPs, Execution-Only Share Dealing, Plan Bee Monthly Investment, Limit Board, Employee Share Dealing, Investment Clubs, Contracts For Difference and Unit Trust [5]. Although there are several services provided by RedmayneBentley, it was decided that all the services would be considered as a general service for the purpose of this project due to time constraints. There are many branches all over the UK where interested clients can meet agents and discuss about the services and prices, and the procedures involved to acquire those services. A series of scenarios based on my work experience with Redmayne-Bentley is provided below to describe the main processes that will be modelled. The case study here is slightly different from those described in Martyn Oulds book because the project in this case is about evaluating modelling using the Riva approach and ProcessWeb, rather than a consultant using Riva to analyse and evaluate the processes of Redmayne-Bentley.

Prospective Client Mr. Smith has heard a lot about Redmayne-Bentley and he is interested in acquiring a service from them. He therefore decides to go to the head office of Redmayne-Bentley in Leeds to get more information. There he meets an agent. The following is the conversation that goes on between them: Jane (Agent): Hello. How may I help you? Mr. Smith (Prospective Client): Hello. I have heard that Redmayne-Bentley provides many services. I would like to know more about them please. Jane accesses the online system and looks up for the required information. She then gives Mr. Smith a detailed account about the different services and the levels that are provided, and also gives him a brochure. She then tells him that he is more than welcome to acquire a service right now or he could do so later on after much consideration. Mr. Smith: Well I have made up my mind and I would like to purchase a Child Trust Fund for my 3-year old daughter for the time being please. Jane then creates a new account for Mr. Smith on the system and inputs all the details. She saves the record and prints out a receipt for Mr. Smith. She also gives him his client account number and service number which have been created for him, so that he can access his account via the Web. Thus Mr. Smith now has an account with Redmayne-Bentley.

26

Client (Existing) All the existing clients of Redmayne-Bentley have an account that they can access via the online system. They can easily access their accounts, view their dealings and carry out transactions such as buying shares, putting in more money or selling their shares. If they encounter errors, they can immediately report them to a member of the help desk support to look into them.

Errors All errors that are reported by existing clients to the help desk support are entered in a bug tracking system. Developers can view those errors and fixed those assigned to them, while the help desk support can amend the status of the errors reported, assign them to developers and close them once they are fixed. If the error is a simple one, it will be solved quickly and the help desk support will be informed and the error-free version of the software product will be made available. However, if the error requires new features or involves a new service, then the project manager will be informed and a board meeting will be held. There will be discussions about whether a new revised version of the software product will be better or a completely new software product will be more appropriate.

Revised Versions of Software Products or New Product When a new software product is released from the IT department of RedmayneBentley, software testers test the product thoroughly to ensure that the required operations are being performed and the correct data is being displayed or output when calculations are carried out. If there are errors, these will be reported to the help desk support and consequently will be entered in the bug tracking system for revision by the developers. Otherwise, if everything is working as it should be, then the software product is released for use by Redmayne-Bentley.

New Software Product for New Service The stock market is always changing, and new rules and regulations are often issued. If the members of the board of Redmayne-Bentley decide to offer a new service, then the appropriate software product will have to be used. A meeting will be held and decisions will be made about the design of the product, the functions that should be provided and the information that should be displayed, entered and output. After that, the project manager and the senior developer will assign a task to each developer. Regular meetings will be held to know about the progress of the software product under development. When the developers have completed and tested their respective tasks, all the components of the software product will be combined and tested as a whole. Intensive testing is carried out on the software product before it is released for use by the agents and thus adding a new service in the portfolio of Redmayne-Bentley Stockbrokers.

27

4.2 The Process Architecture Diagram

The concept of the process architecture was explained in Section 3.2.2 of Chapter 3 Business Process Modelling and ProcessWeb. The Riva approach is applied to this case study, i.e. Redmayne-Bentley Stockbrokers to derive the process architecture diagram. This phase usually requires intensive research about the organisation and business, and is very complex in real life. For this project however, it is based on Section 4.1.2 The Textual Model only and the meetings with Dr Mark Greenwood from the Informatics Process Group, School of Computer Science, The University of Manchester. Figure 4.1 illustrates the UOW diagram of Redmayne-Bentley Stockbrokers. This diagram is obtained after identifying the essential business entities and selecting the main units of work.

Figure 4.1 The UOW diagram for Redmayne-Bentley

Involves Planning

Strategic Planning Generates

Generates

Business Requirement

Generates Change to Business Requirement Generates

Prospective Client

Requires Service Requires

Generates

Requires Software Product

Requires

Change to Service

Requires Client Account Generates

Release of Software Product

Generates

Generates

Generates

Generates Error Encountered Error Reported

Generates

Change to Software Product

28

Figure 4.2 The first-cut process architecture

Handle the Business Requirement Request a change Start Manage the flow of changes to the Business Requirement Handle a change to the Business Requirement

Deliver outcome of request

Manage the flow of Services Start Handle the Service Handle a change to the Software Product Deliver change to Software Product Request a change

Request a change

Request a release

Handle the Prospective Client Manage the flow of releases of Software Products Start Deliver change to Software Product Start Request new Software Product Deliver New Product Request new Software Product Request new Software Product Deliver new Software Product

Deliver new Release

Manage the flow of changes to the Service

Request a change

Start

Manage the flow of Client Accounts

Handle a release of Software Product Manage the flow of Software Products Start

Request a change

Handle a change to the Service Handle a Software Product Deliver new Software Product Request new Software Product

4.2.1 Deriving the Process Architecture Diagram

Start

Notify of Failure

Request a change

Handle the Client Account

Deliver closure of error encountered

Manage the flow of Errors Encountered

Request new Software Product Notify resolution of Error Notify of Error

When the UOW diagram has been produced, the first-cut process architecture is derived by applying the 3-Layer process architecture to the units of work. The diagram below illustrates the first-cut process architecture.

29
Start Handle an Error Encountered

Deliver new Software Product

Manage the flow of changes to the Software Products

Notify of Error

Request a change Start Handle an Error Reported

Manage the flow of Errors Reported

Figure 4.3 The second-cut process architecture

Start Deliver outcome of request Handle a change to the Business Requirement Deliver outcome of request

Handle the Business Requirement

Manage the flow of Services Start Handle the Service Handle a change to the Software Product Start Deliver change to Software Product

Request a change

Handle the Prospective Client Start Deliver New Product Request new Software Product Start Handle a Software Product Request new Software Product Request new Software Product Deliver new Software Product Deliver change to Software Product Start Request a change

Deliver new Release

Request a change

Handle a change to the Service

Manage the flow of Client Accounts Manage the flow of Software Products

Handle a release of Software Product

Deliver new Software Product

Start Notify resolution of Error Request new Software Product

Notify of Failure

Request a change Deliver new Software Product Request new Software Product

Handle the Client Account

Manage the flow of Errors Reported

Service and task force relationships are then identified between case processes and case management processes, and certain case management processes are encapsulated thus producing the second-cut process architecture. The figure below represents the second-cut process architecture.

30
Start

Notify of Error Handle an Error Reported

Deliver new Software Product

Manage the flow of changes to the Software Products Request a change

Chapter 5 Modelling and Implementation

This chapter consists of producing Role Activity Diagrams of the processes from the Process Architecture Diagram. The next section is about using those Role Activity Diagrams to implement the processes of Redmayne-Bentley Stockbrokers in Process Management Language (PML). Finally some interesting aspects of the implementation process are looked at.

5.1 Process Architecture Diagram to Role Activity Diagrams

After having derived the process architecture diagram, the next step is to analyse each process and draw a Role Activity Diagram to represent its model. A Role Activity Diagram (RAD) illustrates the roles that are involved in a process, and their corresponding actions and interactions, as well as external events and deterministic logic of when to carry out specific actions. Usually processes are instantiated when a process architecture runs and they operate concurrently. Therefore, Role Activity Diagrams represent the activities that are performed by roles in processes and their concurrent dynamism since one role can instantiate another and they can all interact simultaneously. They also provide a more detailed view of processes in the organisation as process architecture diagrams do not go into that much depth. Role Activity Diagrams will be provided for this particular case study. These have been designed by following examples in Martyn Oulds book and based on the process architecture diagram and scenarios.

The following diagram is the Role Activity Diagram of a prospective client enquiring about a service to an agent of Redmayne-Bentley; the scenario was described in Section 4.1.2 and the process architecture in Section 4.2.1.

31

Figure 5.1 Role Activity Diagram for Handle a Prospective Client

New Query Start New Agent Make Query

Prospective Client

Agent

Look for information about services Provide information Choose Service Enter details of client and save record Issue receipt to client

Close record

This Role Activity Diagram shows the actions and interactions that take place between a prospective client and agent when the latter enquires about a service till he decides to acquire a service, for e.g., Mr. Smith who acquired a Child Trust Fund service for his daughter. In this Role Activity Diagram, Prospective Client and Agent are the two main roles. The process being looked at here is Handle a prospective client.

32

Figure 5.1 shows the Handle a Client Account process. All the clients of Redmayne-Bentley Stockbrokers have accounts which they can access online. They can carry out transactions and check their details whenever they want. Client can carry out as many transactions as they want and receipts are issued for them to keep as proofs. If they encounter errors, these can be immediately reported to the helpdesk support so that they can be fixed as soon as possible.

Figure 5.2 Role Activity Diagram for Handle a Client Account

Client New Transaction Account

Start New Account

Carry out Transaction Update Account details

Display Transactions

Issue receipt to client Yes No Carry out another Transaction?

Close Record

33

The following Role Activity Diagram represents the process of Handle an error

Figure 5.3 Role Activity Diagram for Handle an error Client New Error Start New Helpdesk Support Report Error Developer Start New Developer Log Error Assign Error Fix? Fix error Notify error has been fixed Notify that error has been fixed Close Error Error fixed Helpdesk Support

Yes

If a Client encounters an error while he is accessing his account online, he will immediately report the error to a member of the Helpdesk Support. Helpdesk Support will assign the error to a Developer to fix. If the error can be fixed, the developer will make amendments, upload the revised version of the software product and notify Helpdesk Support that the error has been fixed. Helpdesk Support will then pass this information to the Client and tell him that the revised version has also been uploaded. The status of the error reported is then set to closed. However, if the error cannot be fixed, i.e. it requires a new version of the software product or a completely different software product, so then this request will be passed to the Project Manager and the Board of Directors. This step has not been shown in the Role Activity Diagram as it involves a different process Handle a new software product.

34

This Role Activity Diagram illustrates the Handle a New Software Product process.

Figure 5.4 Role Activity Diagram for Handle new software product Board of Directors New software product project Project Manager Start New Project Manager Give software product requirements Start New Developer Prepare Plan Give Plan Produce Implementation Carry out tests Software product suitable? Yes No Developer

Notify of completion Produce report Project completed

A meeting involving all the directors of the board is held to discuss about the new service that Redmayne-Bentley Stockbrokers would like to provide and thus an appropriate software product is required. The project manager for this task receives a list of requirements and he prepares a plan to give to the developers. The developers work on the software product and implement it. If the software product is found suitable after testing is done, then the project manager is notified of its completion. The latter will then produce a report and the project will thus be completed.

35

Figure 5.5 Role Activity Diagram for part of the Carry out a Strategic Review process

Board of Directors Project Manager

Start Project Manager in Tactical Review process Provide terms of reference

Tactical review required

Tactical review complete Receive Tactical review results

Tactical review results handed over

Figure 5.6 Role Activity Diagram for part of the Carry out a Tactical Review process

Board of Directors Project Manager

Tactical review required

Receive terms of reference

Tactical review complete

Hand over Tactical Review results

Tactical review results handed over

Figures 5.5 and 5.6 illustrate the processes of parts of Carry out a strategic review and Carry out a tactical review. These are processes which review the strategies employed by the organisation and the level of performance, and devise new strategies for maximum efficiency and profitability.

36

Figure 5.7 Role Activity Diagram for Manage Project for New Software Product
Board of Directors End of month End of week Monthly Review Progress Review Time for task to be started Start New Developer Developer End of month For each open task Find out status Update task status Prepare project report Agree on project report Send project Report to board Board has monthly report Prepare Task Project Manager Senior Developer

Pass Task

Do Task

Notify completion

Figure 5.7 illustrates the role activity diagram for a Manage Project of New Software Product process. When this process starts, there are roles such as Project Manager, Board of Directors, Senior Developer and Developer. In this example, the Project Manager is responsible for managing a project for developing a new software product. He has interactions with the other roles from the start of the project till the latter is completed. This particular process is an example of a case management process.

37

5.2 Role Activity Diagrams to PML

Once the role activity diagrams have been drawn, the enactment system of the process models of Redmayne-Bentley Stockbrokers can now be designed and implemented. The roles and interactions that will be implemented in the enactment system are the same as those in the role activity diagrams. Process Management Language (PML), which was covered in Chapter 3 Section 3.3.2, is used for the implementation. The Role Activity Diagrams have to be analysed thoroughly so that the designs of the roles and interactions can be made. This is done to ensure that the implemented processes are consistent with their corresponding role activity diagrams. For this reason, the enactment system has to be as simple as possible and analogous to how processes will be carried out in an organisation in real life. Therefore the enactment system will have roles like Process User which is a Case Strategy Process; Client CM User, Account CM User, Query CM User and Software CM User which are Case Management Processes and Case Processes like AgentRole User, ProspectiveClientRole User. The structure of the enactment system of the processes has to be thought of in details and designed carefully as it is of utmost importance to capture the notion of the roles, actions, interactions and goals of the processes. The naming convention of the roles identified in the role activity diagrams is based on the understanding of the organisation and by applying the 3-Layer process architecture to the processes. This is to facilitate the understanding of the 3-Layer process architecture and to show the hierarchy of processes and how they are linked to one another. This naming convention is not actually used in Redmayne-Bentley Stockbrokers. The roles and interactions between processes have been generalised and can thus be adapted to any way in which the organisation decides to run its processes. The main aim here is to capture the essence of the 3-Layer process architecture described in Martyn Oulds book and to reflect it in the enactment system of the process models. Figure 5.8 below illustrates the roles that have been implemented in this case study. When the program is executed, the Process User role is created and in turn starts up the Client CM User, Account CM User, Query CM User and Software CM User roles. The other roles are created by their corresponding roles as depicted in Figure 5.8 when and as the need arises. The roles can be bound to users and directly interact with the users of the application. The Client CM User role is the case management process; it starts up the AgentRole User and ProspectiveClientRole User when a prospective client wants to acquire a new service from an agent. The interactions between the agent and prospective client are carried out when that process is enacted. The Account CM User role is the case management process responsible for launching the AccountRole User. The AccountRole User allows a client to check his dealings and carry out transactions online. If an error is encountered, then he clicks on Report Error to report the error. When the Report Error button is clicked, a message is sent to the Query CM User role which creates the roles, HelpDeskRole User and QueryRole User. The Query CM User role is the case management process which creates the two roles: HelpDeskRole User and QueryRole User. It should be noted that the QueryRole User is in fact the AccountRole User. This process allows a client to report errors to the helpdesk support team. All the errors that are reported are logged into a table, which can be

38

viewed by both the helpdesk support team and the software developers. When an error is reported, the HelpDeskRole User sends a message to the Software CM User which is the case management process to start up the roles: SoftwareDeveloperRole User and SoftwareTesterRole User. These two roles are only created if the error reported can be fixed. The error is fixed and the SoftwareDeveloperRole User interacts with the SoftwareTesterRole User to let the software tester know that the revised software is ready and to carry out thorough testing before it can be released to the organisation. After having tested the software, the software tester will send a message to the Software CM User to let him know that the revised software can now be used. The Software CM User then passes this information to the Account CM User so that the clients can be informed that the error has been fixed and a revised version of the software is now running. However, if the error reported requires new features or involves a new service, then the Software CM User will send a message to the Process User which is the case strategy process. The case strategy process will then take appropriate decisions about whether a new software product should be developed or a new service should be provided. The case strategy process, Process User is responsible for monitoring the behaviour of the case processes and case management processes, so feedback about actions should be sent to him as this will help tremendously in the strategy employed by Redmayne-Bentley to operate profitably and efficiently and also for excellent customer satisfaction.

Figure 5.8 The enactment system of Redmayne-Bentley Stockbrokers

39

5.3 User Interface of Enactment System

The enactment system of the process models is executed on ProcessWeb. The main page requires users to enter a valid username and password in order to access the system. After that step, users can view the implemented process models of Redmayne-Bentley Stockbrokers and try them out if they want to know more about the organisation. The user interface of the application is created using HTML templates. Different processes will have different templates as they have to be in line with the activities that are carried out by the roles of those processes. For example, the Client Account user interface will have details about a clients account such as his transactions, whereas the Prospective Client user interface will have interactions that will occur with an instance of an Agent. The user interface has been made as simple and realistic as possible to keep the enactment system of the process models consistent with the role activity diagrams. Thus, any user should be able to use the enactment system and understand how the 3-Layer Process Architecture is being applied to this particular case study.

Figure 5.9 User interface of the Account Role

40

Figure 5.10 User interface of an instance of the Prospective Client Role

Figure 5.11 User interface of an instance of the Agent Role

41

5.4 Interesting Aspects

There are interesting aspects related to the analysis, modelling and implementation of the process models of this case study. The initial plan was to analyse the case study, and then draw the process architecture diagram followed by the role activity diagrams and finally the enactment system of the process models. However, the whole procedure was rather iterative. The analysis of the case study was done and as the process architecture diagram was being derived, role activity diagrams related to that part of the process architecture diagram were being drawn as this provided a better understanding of the case study. The role activity diagrams had to be designed carefully and logically so that they would be similar to real-life interactions. There were several ways to draw the role activity diagrams, so the most realistic procedure was chosen. When the role activity diagrams were completed, the enactment system of the processes was designed. This required minute investigation as Process Management Language was quite low level in terms of the roles and interactions of the processes with no concepts that could easily relate to the 3-layer process architecture or the service and task relationships between processes. This problem was overcome by simplifying the processes and creating a hierarchy of processes where certain processes would launch specific roles and send messages to one another to create relationships among them, for e.g. case managers would be linked to one another by sending messages to one another as they could not be linked directly. The implementation of the process models required a deeper knowledge of the processes involved in Redmayne-Bentley Stockbrokers as well as the role activity diagrams. It was very interesting to see how each model of the processes provided a specific insight to the activities carried out by Redmayne-Bentley Stockbrokers.

42

Chapter 6 Evaluation
This chapter explores the evaluation of the 3-Layer Process Architecture described in Martyn Oulds book, Business Process Management: A Rigorous Approach, when it is applied to the processes of the case study which is Redmayne-Bentley Stockbrokers. The evaluation is done from a developers perspective and from that of a user who works for Redmayne-Bentley Stockbrokers. Modelling from case study to process architecture diagram will be evaluated, followed by modelling from process architecture diagram to role activity diagrams and finally role activity diagrams to the enactment system of the processes.

6.1 Phase 1: Evaluation of the Process Architecture Diagram

From a developers perspective It was fairly easy to identify essential business entities from the different scenarios provided to derive the process architecture diagram. However, further investigation was required to ensure that the most appropriate essential business entities were considered and that time was not being wasted on unnecessary ones. A good background of software engineering and the case study, Redmayne-Bentley Stockbrokers, was required to successfully derive the process architecture diagram. The steps of the Riva approach and the examples provided in Martyn Oulds book were quite easy to follow. For a developer, the process architecture diagram is a very useful visual aid as it provides a general view of all the processes involved in an organisation, and what the activities and outcomes are. From a users perspective A user will comprehend the business activities of an organisation by reading the scenarios, but a process architecture diagram might not make much sense. It would be quite hard for a user to derive a process architecture diagram without some knowledge of software engineering. He might understand certain basic processes although certain terminologies might be quite hard to grasp as the Riva approach is not really known in most organisations. Thus a process architecture diagram might only enable a user to comprehend the processes in an organisation to a certain extent only as the latter can be quite complex.

43

6.2 Phase 2: Evaluation of the Role Activity Diagrams

From a developers perspective Role activity diagrams are widely used by developers as they act as an initial design phase before implementation is done. In this case study, the role activity diagrams aided in choosing the roles to be implemented and the various interactions and concurrency between them. Role activity diagrams are not very simple to draw nevertheless as there is not a unique way to represent processes. Therefore the most consistent and realistic way has to be chosen so that it is clear that role activity diagrams are built from the process architecture diagram. Role activity diagrams usually concentrate on a single process at a time, so they are more detailed. From a users perspective Role activity diagrams are usually easier to read than a process architecture diagram from a users perspective. As they concentrate only on a single process at a time, a user will understand the roles and interactions between them and will find these simpler to follow. However, it has to be ensured that the user does not mistake a role activity diagram for a flowchart. Thus, for e.g. an agent who deals with clients everyday in Redmayne-Bentley Stockbrokers will find the role activity diagram for Handle a Prospective Client more useful than the other role activity diagrams. It can be concluded that users from specific departments will find specific role activity diagrams relevant to the operations that they carry out.

6.3 Phase 3: Evaluation of the Enactment System

From a developers perspective The process models for Redmayne-Bentley Stockbrokers were implemented in Process Management Language and enacted in ProcessWeb. The enactment system was designed in a way such that it follows the role activity diagrams as well as the 3-layer process architecture. The enacted models thus provide a large detailed picture of the parts of Redmayne-Bentley Stockbrokers which are of interest. For a developer, this provides a clear image of the organisational activities, outcomes and what strategies should be employed in the long term. As the system is dynamic, the developer can start up any role and be the user, and view how operations are undertaken and how they could be improved. All the processes are classified into case processes or case management processes or case strategy processes respectively. For a developer, this is clearly discernable; even if the concept of this architecture is new, he will still manage to work around it and grasp its essence.

44

From a users perspective The enacted process models might not mean much to a user, especially if he is not familiar with the concept of the 3-Layer Process Architecture. The enactment system will be useful to the board of directors when they are analysing their organisational operations and looking at strategies in the long-term. It is particularly of tremendous help when decisions about new services and software products have to be taken. It could be useful to the manager of a specific department if he wants to enact the process models in his department and see how things work. Detailed knowledge of the stock broking company is required though to understand how the processes in the organisation are being grouped according to the 3-Layer Process Architecture.

6.4 Evaluation of the 3-Layer Process Architecture

Martyn Ould proposes the Riva methodology to derive the process architecture diagram, role activity diagrams and an enactment system to model processes in organisations which are in specific businesses. According to him, the 3-Layer Process Architecture gives a better understanding of the processes involved in organisations and also the running of the organisations. It is worth mentioning that his suggestion is only one of the many hypotheses available. Till date, not many organisations have heard of those process architectures or those who know about those architectures have not really accepted them. The projects aim was to evaluate Martyn Oulds hypothesis by considering a case study which was Redmayne-Bentley Stockbrokers. Firstly, the process architecture diagram of the case study was derived from scenarios. Role activity diagrams were drawn while the process architecture was being built. For e.g. the role activity diagram for Handle a Client Account was drawn while its counterparts, Handle the Client Account and Manage the flow of Client Accounts were drawn in the process architecture diagram. The process architecture diagram is consistent with the 3-Layer Process Architecture as it consists of case processes and case management processes and how they are related to one another. In the above example, Handle the Client Account is a case process and Manage the flow of Client Accounts is a case management process. The process architecture diagram itself is a case strategy process as it helps to Maintain a strategic view on the business process of Redmayne-Bentley Stockbrokers. Role activity diagrams are built from the process architecture diagram. The role activity diagrams consist of roles and interactions to one another which are instances of processes. Separate role activity diagrams are drawn for case processes, case management processes and case strategy processes. For instance, when the Handle a Prospective Client case process from the process architecture diagram is converted to a role activity diagram, only the roles and interactions of an instance of that case process will be looked at, that is, ProspectiveClientRole User and AgentRole User. Role activity diagrams for the roles and interactions of case management processes and case strategy processes are drawn separately.

45

The process architecture diagram and role activity diagrams are static representations of the business processes. They provide understanding of the processes in an organisation to a certain extent. It is only with the help of a dynamic representation that the functioning of the organisation can be grasped fully. This is where the enactment system implemented in Process Management Language and executed in ProcessWeb comes into place. The enactment system is designed from the role activity diagrams and the 3-Layer Process Architecture is applied to it so that the latter becomes apparent to anyone. As it was discussed in Section 5.2, the case strategy process, Process User launches all the case management processes. The case management processes, in turn, start up instances of the case processes which consist of various roles and interactions. Each case process carries out a distinct activity and a specific outcome is achieved. Therefore the enactment system is consistent with the 3-Layer Process Architecture described in Martyn Oulds book. The Riva methodology proposed by Martyn Ould is indeed very useful and efficient. The process architecture diagram, the role activity diagrams and the enactment system provide a very exhaustive understanding of any organisation. All of them allow an organisation to be viewed from different angles. It is very interesting to see how each representation of the same processes varies, but at the same time how they relate to one another and how one can be derived from another. This relation among those representations is obvious because of the presence of the 3-Layer Process Architecture. This architecture would be most beneficial to organisations if they adopted it as their processes would be classified properly and will follow a specific structure. It would be easier for them to improve organisational processes and to adopt the most suitable strategy. However, the drawbacks would be that since there is not a unique way to model processes, thorough investigation would be required to choose the most realistic and logical representation. Processes would also have to be scrutinised so that the main and most important ones are chosen and modelled and thus minimise wastage of time and effort. There is also the risk of leaving out certain essential business entities, so it would have to be ensured that all the essential business entities in the organisation are considered. So, these issues can be overcome. Overall, the Riva approach is a good methodology and can be applied to organisations in any sector and it helps greatly in showing that an organisation is in a distinct business. This projects case study is in the service sector and last years project case study was in the manufacturing sector, and Riva worked quite well in both case studies. Thus the Riva approach does play a very crucial role in business process management.

46

Figure 6.1 Diagram to illustrate the process Handle a prospective client from the Process Architecture Diagram to Role Activity Diagram to Enactment system on ProcessWeb

47

Figure 6.2 Diagram to illustrate the process Handle a client account from the Process Architecture Diagram to Role Activity Diagram to Enactment system on ProcessWeb

48

Chapter 7 Conclusion
This chapter will cover the conclusion of this project, learning outcomes and the difficulties that were faced. Planning and management will also be discussed as well as future work recommendations.

7.1 The Modelling and Implementation of Processes

The modelling and implementation of the processes in the case study, Redmayne-Bentley Stockbrokers show that Martyn Oulds Riva methodology is very useful and would be advantageous to organisations. A good understanding of the business can be obtained if the 3Layer Process Architecture is applied accurately to the organisational processes.

The 3-Layer Process Architecture The 3-Layer Process Architecture proposed by Martyn Ould is very obvious from the process architecture diagram, role activity diagrams and the implemented system. It can be seen how processes are classified into case processes and case management processes and how the part of the case study being looked at can be considered as the case strategy process. It was also deduced that the architecture can be applied to any organisation in any sector as the evaluations produced from last years project and this years demonstrate how the Riva methodology works well in the manufacturing sector and the services sector respectively.

The Case Study The case study, Redmayne-Bentley Stockbrokers is a very large and complex organisation and profound knowledge about them was required for the modelling and implementation of the processes. Due to time constraints, only part of the case study could be looked at. Nevertheless that was still sufficient to evaluate the 3-Layer Process Architecture.

49

7.2 Learning Outcomes and Difficulties

Understanding of the 3Layer Process Architecture The 3-Layer process architecture is explained explicitly in Martyn Oulds book, Business Process Management: A Rigorous Approach, BCS 2005. The hypothesis is supported by various case studies and examples, and also summaries are provided at the end of each chapter in the book. The 3-Layer Process Architecture is indeed an effective methodology as it presents a clear understanding of an organisation and from different perspectives. It is a completely different way of looking at activities in an organisation. Evaluating the Riva methodology by analysing the Redmayne-Bentley Stockbrokers case study, deriving the process architecture diagram, drawing role activity diagrams and finally implementing an enactment system is a gratifying experience and can prove to be of great use in the future. Nonetheless, it demands intensive knowledge of the case study being probed and a rigorous comprehension of the concept of the 3-Layer Process Architecture as well as its applications.

Process Management Language (PML) Process Management Language (PML) can be understood fairly well as it is an object-oriented programming just like Java which is taught for two years at university. However, it requires time for learning and practising examples. This can be a disadvantage for a joint Honours student, but the project plan helps enormously in allocating time for each task. Process Management Language is a class-oriented language and it is persistent which is why it is used to implement models, but it does not support the 3-Layer Process Architecture very well. This issue can be overcome by thinking properly and implementing models appropriately. ProcessWeb is used to provide an environment to enact the implemented models. It can be quite tricky as there is no compilation error detection mechanism. It supports a diagnostics tool which helps debugging, but it is not easy to comprehend it initially. It can only be understood after repetitive use and experience. Nevertheless, the tool does come in handy to detect errors when the enactment system does not respond as it should.

7.3 Planning and Progress Management

The Project Plan Most of the stages of the project such as background reading and case study research went quite well. The first challenge came when the period of the demonstration of the enactment system kind of clashed with seminars and essays from the Manchester Business School. This hindered the implementation of further detailed processes as new ideas kept coming up and not all the interesting parts of the processes could be implemented although they were modelled. A few minor changes were made to the plan as the project progressed, so there were no adverse effects. All the major milestones, such as the seminar and demonstration, were achieved within the set period.

50

Figure 7.1 The Project Plan

51

7.4 Future Work Recommendations

This project has achieved all its aims and has successfully evaluated the 3-Layer Process Architecture; however there are still certain areas in which further work would be recommended and these are:

Adding additional status information between case processes and case management processes. For example, providing the Query case manager with a view of all the outstanding error cases.

Providing a more detailed mapping between the process architecture and Role Activity Diagrams and the Process Management Language for the ProcessWeb model. This would give some way of checking that the Process Management Language corresponded to the other models. One of the difficulties in doing this is that the Process Management Language has to deal with user input and output at quite a low level, something that is not included in the Role Activity Diagrams.

"Completing the loop" - with a ProcessWeb model it would be possible to model the development of a new service/process (as a set of PML classes). These could then be given to the case management processes, so that new cases followed the new process rather than the old one. This could be implemented by integrating some of the capabilities of the Developer, which is itself implemented in PML, in the appropriate case and case management processes.

Further development of the case strategy processes. Status information would be passed between processes so that a case strategy process would have a long-term view of the number of different cases in the business and how quickly these were being completed. This would also facilitate the task of making decisions about when to make changes to the case processes, and possibly the case management processes too.

There are various methodologies and the 3-Layer Process Architecture is one of them. This approach has been found to be valid. It would be a great idea to evaluate other methodologies and compare them to see the similarities and differences between them.

52

References
1. Martyn Ould, Business Process Management: A Rigorous Approach, BCS 2005 2. http://www.utm.mx/~caff/poo2/Business%20Modeling%20with%20UML.pdf 3. http://www.sparxsystems.com.au/downloads/whitepapers/The_Business_Process _Model.pdf, Accessed on 15/04/07 4. http://www.fairdene.com/contents.html, Accessed on 15/04/07 5. http://www.redmayne.co.uk/main_code/index.htm, Accessed on 16/04/07 6. http://www.minniebusiness.co.uk/minniebusiness.pdf, Accessed on 17/04/07 7. ProcessWise Integrator PML Reference. ICL. 8. http://processweb.cs.man.ac.uk/#documents, Accessed on 20/04/07 9. Business Process Management: The 3-Layer Process Architecture, Kealeboga Ranko (Third Year Project Report 2005/06)

53