In order to have a dialogue with stakeholders about process improvement you will need some form of representation of the process. Process maps are used for:
- Identifying problems with the ‘as is’ state
- Designing the ‘to be’ state
- As a means of evaluating the improvements expected
- As a means of communication/training in new ways of doing things.
The process map can show what controls a process, what it produces, what areas it covers and which elements make up the process. It shows the sequence of activities, flow of information, decision points and the range of possible process outcomes. They are usually presented in the form of a flow diagram.
It can be hard to face other people’s, often surprisingly different, assumptions because this makes us question our own assumptions which can be demanding and unsettling. It can mean throwing away the solutions we thought we had, going back to the beginning and starting afresh but that’s often what’s needed at the start of a systemic enquiry.
The Open University
There are many tried and tested approaches to process mapping and they differ considerably in terms of their levels of complexity and the skills needed both to produce and understand the visual representations. Here we suggest some simple, low-tech approaches that can be undertaken by any organisation and which have been shown to be effective in the education context.
- Use unified modelling notation notation to produce a readily readable flowchart
- Add Swim Lanes as a first step in process analysis
- Try Rich Pictures if the process is complex and/or there is disagreement about how it does/should operate
- Try Responsibility, Authority, Expertise and Work (RAEW) analysis to highlight areas of process dysfunction
- Use a Collaboration diagram to show how people interact with one another
Those using more formalised process review methodologies may undertake mapping using more specialised techniques and software. Process improvement sits well with the application of Enterprise Architecture (EA) thinking across the organisation. EA practitioners use formal modelling techniques and the use of the free Archi tool can offer considerable savings over commercial products.
It should however be noted that, despite the considerable advantages of the EA approach in taking forward organisation-wide change in a structured manner, it is often necessary to produce simplified representations of the type discussed above to facilitate discussion with stakeholders not trained in the formal techniques.
At Cardiff University low-tech collaborative approaches proved highly effective in supporting redesign of the curriculum approval process. Participatory design approaches were used with key stakeholders including mapping the current programme approval process using a length of brown paper and noting key steps on post-it notes. Different colour post-it notes were used to capture issues and bottlenecks, and suggestions for improvement.
Stakeholders then identified aspirations for a new process working in small groups to draw a ‘rich picture’ of an ‘Aspirational Ship‘, that represented what a new programme approval process would look like in an ideal world. Design features included: good manoeuvrability, simple, advanced navigation system, streamlined, future-proofed, supportive crew and horizon-scanning.
These ideas were then used to produce a further ‘brown paper process map’, translating the aspirations into high level process steps that might be included in the ‘future state’ business process. Find out more about the Programme Approval Lean Electronic Toolset (PALET) project.
Unified modelling language (UML) - a recognised international standard for drawing process maps
This is the only recognised international standard for drawing process maps. The basic principles of UML are very simple and the chances are that most of you will have encountered UML diagrams and been able to interpret them easily without knowing anything at all about UML or even recognising that the diagrams were using a formal set of conventions.
The basic elements of UML notation are shown below. This is really all you need to know to get started on drawing process maps. You will probably sketch out your process maps on paper or a white board initially but most software packages with graphics functionality support the use of standard UML symbols. If you are buying a software package especially to support your process mapping you should ensure that it is fully UML compliant. UML is merely a diagramming notation not an analytical method in itself. How you interpret the maps you draw is critical to how well you succeed against your objectives.
The diagram below shows an example of a generic enrolment process at a very high level – the input is the applicant’s acceptance of an offer from an institution. The transformation is the amending of their record to indicate the change in status to expected student and the tasks required in order to facilitate the enrolment of a student and the output is the completion of the enrolment form by the student.
The elements involved in the transformation part of this process can vary in the degree of detail and complexity.
The actual process can involve a host of pre-enrolment and enrolment actions that need to be undertaken to transform the applicant to the stage where they are in a position to complete an enrolment form. Mapping the next level of detail, including some of the administrative, system and other tasks involved can be done by using a UML diagram (see below).
Swim lanes - a basic flow diagram for indicating responsbilities in a given action
A basic flow diagram can be enhanced by the use of ‘Swim Lanes’ to indicate who has responsibility for carrying out a particular action. The diagram below shows the start of a process map for recruiting staff within an institution. At the simplest level a flow diagram can give you a feel for how complex a process is merely by the number of steps involved. The swim lanes add an extra dimension as they indicate where data is flowing backwards and forwards between departments (or people).
This diagram shows only the first few steps in a process but it is evident even from this that there are a lot of steps and a lot of movement back and forth. Already we can see one department checking another’s work and two different departments involved in placing recruitment adverts.
Example diagram: Tea-making swim lanes
The horizontal lines mark the start and end of two parallel but independent lines of activity. The temptation is to say right at the start ‘Why not ask who wants milk and sugar at the same time as asking who wants tea?’ But at this stage you must be non-judgemental.
Resist the urge to ask ‘Why’ or ‘Why not just…’ because the questions imply criticism and if you are critical then people will just give you the procedure manual and tell you what SHOULD happen instead of what DOES.
Another example of a process map using swim lanes deals with the process of creating a new employee record when a member of staff joins the organisation. The example is from an organisation where the HR and payroll systems use different software.
The obvious conclusion is that the process is heavily reliant on paper, there is excessive data transfer and checking and a lot of duplication. A possible solution, given that the example comes from a large organisation, is to implement an integrated HR/Payroll system. An alternative is to revise the process to involve a greater level of trust between departments and cut out much of the cross-checking.
Rich pictures - addressing complex problems with diverse stakeholders
Rich pictures are a simple, but surprisingly powerful, tool for addressing complex problems with diverse stakeholders. It can support process improvement especially in the kind of situation where it is difficult even to get agreement/understanding of what the problem actually is let alone begin to identify ways of solving it.
It recognises the significance of emotions, perceptions and misconceptions in a way that formal process maps do not and allows these to be expressed in a non-confrontational manner.
This short animation by The Open University gives a good introduction by providing a Rich Picture about Rich Pictures.
The University of Greenwich used Rich Pictures very effectively in reviewing its course design and delivery processes and the example below, entitled ‘Computer Says No’ highlights some perceptual issues e.g. computer systems powered by a tortoise and HEFCE/QAA in submarines beneath the real world.
An example that ties more closely to process mapping techniques is shown below whereby the process of making a cup of tea for guests is broken down into steps then drawn as a rich picture. The graphic view highlights more obviously redundant steps and duplication of effort. See another variant of this in the section on Swim Lanes.
Rich pictures can help to identify open loops or redundant checking at an early stage, major issues will show up relatively easily. You should be wary – as with all the tools outlined here – of ‘paralysis by analysis’, don’t get too bogged down in the detail when using this high-level method. It can be a useful tool to compare the differences before and after process review.
Another example on the theme of Rich Pictures is this map produced by Professor Gilly Salmon to help understand the perspectives of different stakeholders involved in implementing an institutional e-learning strategy.
The map does not claim to be complete and is very much of its time (hence the reference to the dot.com marshes and the fact that the Temple of Pedagogy should perhaps be renamed the Temple of Student Learning). It does however provide a useful tool for exploring different perspectives and the drivers behind them. Professor Salmon recognises that most of us probably spend our time on Crafters Plain where the work is hard and the distances are long.
Responsibility, Authority, Expertise and Work (RAEW) analysis - a simple technique for process improvement activity
RAEW is a very simple process review technique, the name stands for Responsibility, Authority, Expertise and Work. It is a tool that is in widespread use but we have been unable to ascertain where or when it was first developed. This is one of the simplest and most revealing techniques to use when undertaking process improvement activity.
The premise of the method is that these elements form the human/managerial components of the process as follows:
- Responsibility – ‘carries the can’ for actions/decisions
- Authority – controls/judges/prohibits the actions of others
- Expertise – Specialist skills/knowledge/judgement
- Work – physical or mental effort directed at doing/making something
Depending on a person’s role in the organisation they will use some combination of these four elements to participate in the process. Different roles have a different balance, some typical distinctions are shown below:
To undertake RAEW analysis you must first have mapped the process in some way. Our recommended approach is to use RAEW in conjunction with a UML Swim Lane diagram. This presents the information in a format that can be readily transferred to a RAEW matrix. The RAEW matrix uses activities as the y axis and ‘actors’ in the process (departments or individual roles) as the x axis. An example is shown below.
|Job/person spec drafted/update||RW|
|Request to fill vacancy completed||W|
|Request to fill vacancy to budget holder||W|
|Budget holder approval||A|
|Job/person spec sent to HR||W|
|HR place advert on HR web pages||W|
|HR duplicate job/person/recruitment information||W|
|Advertisement sent to external relations||W|
|External relations advertise in media||EW|
Having drawn up the matrix – a spreadsheet package provides the most useful format – you then need to decide where the Responsibility, Authority, Expertise and Work for each activity lies. This may not be easy.
Ideally when you review a process:
- Each component should be addressed at least once for each activity
- Each ‘actor’ involved should play some role in the process
This is unlikely to be the case in reality, particularly with processes that have developed incrementally over time. Each component should be addressed for every activity but you are bound to find areas where you are unable to say who has ultimate responsibility or the definitive expertise. Similarly each actor should play a role but the matrix is likely to raise questions about why particular departments are thought to have a role in certain processes.
RAEW warnings to watch out for:
- Authority with no responsibility
- Responsibility with no authority
- Other roles with no expertise
It is not an exact science. There are often no right and wrong answers and you will be bound to have difficulties and disagreements in coming up with some answers – this in itself is interesting and should tell you something about the process. Similarly if you ask each of the actors to fill in the matrix they will most probably come up with different answers – this is equally valuable information.
This example raises major issues about how the institution manages its recruitment process. The HR department clearly does a lot of work but it is basic clerical work. All of the Responsibility and Authority and most of the Expertise lies elsewhere. The process is also complex and time-consuming. Considering how it impacts on the student as a client, it is evident that the institution will have difficulties in filling vacancies sufficiently quickly to avoid disrupting essential services, particularly delivery of teaching.
This is a real-life example and the analysis prompted the institution concerned to rethink its whole approach to recruitment and to devolve the process out to its client departments.
RAEW is a remarkably simple and effective tool for highlighting major process issues. Moriarty and Thompson however raise a note of caution in relation to its use and point out that it can be ‘hazardous to the health of the presenter’. This is a tongue in cheek way of pointing out that senior management can often be embarrassed by such a stark and clear representation of malfunction within their organisation.
Collaboration diagrams - a useful tool in the process review
Collaboration diagrams are a useful tool in process review. They are based on the premise that each of the various stakeholders is an ‘actor’ in the process and a series of scenarios, often termed ‘Use Cases’, reveal the interactions that each actor has with the process. A simple collaboration diagram is shown below.
This one reveals a student engaging with many other ‘actors’ in order to complete the enrolment process. Looked at from the student’s perspective this raises questions about whether the learner provider could operate in a more joined-up way in order to minimise the number of interactions.
We have included one simple example of how a collaboration diagram highlighted the key issues with a business process in a short case study based on Northumbria University’s HR System implementation.
Process improvement – information and data
It is assumed that the driver behind reviewing processes for many institutions will be the replacement of information systems. Whether this is the case or not, you will not be able to successfully change your processes unless you fully understand your organisation’s data requirements, the flow of data within each process and any constraints external to the process.
The table below gives a quick checklist of things to consider when mapping current processes and creating desired future processes.
|Information Check-List for Analysts||Risks|
|Understand the data||If you do not understand the data, you may incorrectly map the current process or, worse still, create a desired future process which does not take mandatory requirements, immovable deadlines or relative effort into account.|
|Why is it collected? What is its use?|
|How is it collected? From source (eg, student) or third party (eg, UCAS)?||If data needs are not satisfied by central systems duplication may occur where users create a copy of the database in order to add their own cutomised fields as a response to the preceived weaknesses of the central systems – this often leads to the ‘My Data’ syndrome, where that user’s data is kept up to date but not the central system.|
|How is it verified?|
|When is it collected, and how often?|
|Where and how is the data input? Who by? Over what timescale?|
|What volumes of data are involved?|
|How long is the data retained?|
|What security rules apply to the data?|
|Are we aware of missing data ie, data required but not currently collected?|
|Understand the constraints||These can be limiting factors for process design|
|Statutory and policy obligations for collection, collection timescales and reporting|
|Specialist requirements within a specific subject area eg, professionally accredited subjects|
|Understand the information flows||Failure to analyse these could lead to inefficiencies or even collapse of associated business processes/systems|
|Once the data has been collected, where does the information flow? What does it feed?|
|Understand how the data/information interacts with other processes and systems, and what their requirements are in terms of content, format and timescales|
|Where data is passed from feeder systems, what are the constraints on those systems that make it easy or hard to supply data sooner or later?|
The need for a sound understanding of information and data issues is becoming abundantly clear to many institutions as they try to develop processes to support their VLE implementations. If there is a problem with data flow or quality within the process this is now very evident to the main client base ie, the students. There are often very fundamental reasons why institutions experience problems.
In higher education there are two very different drivers in course-based admissions/enrolment processes and the need for module level registrations in the VLE.
We have produced a couple of short guides for FE and HE looking at some common problems: