About 15 years ago I was involved with the world of Total Quality Management. As Quality & Technical Director at software house Praxis, I found myself sitting at the same table as the Quality Directors of BT, ICL, and three other major companies who founded the UK arm of the European Foundation for Quality Management. I soon came to discover the logic and power in the work of W Edwards Deming and had the privilege of hearing him talk. If you haven’t read ‘Out of the crisis’ it’s the first book I recommend here. First published in 1982 it described in vivid terms what needed to be done to concentrate on quality first and foremost and how many of the ‘standard’ management techniques were misguided and even counter-productive. With the increasing interest in ‘process’ over the last decade, his thinking has found new application.
Following the theme, in particular in manufacturing, Womack, Jones and Roos’s book ‘The machine that changed the world’ describes how Taiichi Ohno revolutionised the Toyota production lines in Japan again by breaking the mould in process design and management.
More recently, service industries, and especially government bureaucracies, have been given the treatment by John Seddon, firstly in ‘Freedom from command and control’ and most recently in ‘Systems thinking in the public sector’. I highly recommend the latter. Seddon would probably refer to me as a ‘tool head’, but I have been encouraged by the degree to which (I believe) Riva can be used to support the approach Seddon advocates and have been bringing a greater TQM bias into the method. In particular, he stresses the distinction between value demand and failure demand: a value demand is when you call to place an order; a failure demand is when you call to chase your order. You get more efficient not by improving the efficiency with which you handle people chasing orders but by reducing the level of or (better)removing that sort of failure demand altogether. Similarly, batching does not add value. All this ties in of course with the distinction in Riva between essential and designed units of work.
I’d welcome comments on this.
Many vendors are now suggesting that there modelling tools, and close links to IT and project implementaion now mean that processes can be modelled and executed within there BPM suites aligning process and IT.
I was wondering where RIVA sits in realtion to BPM and vendor driven products that propose to encompass the full BPM lifecycle including process automation? (model, simulate, implement, execute, montior, optimise).
What are your thoughts around this and where does RIVA fit in?
We find the Tutor and Pupil at the water-cooler and eavesdrop on their conversation. The Pupil and a group of colleagues have been trying out the Riva method for constructing a process architecture and have met with a few challenges, in particular in getting the Essential Business Entities out of workshop attendees.
Pupil: We’ve been applying the method to the government department we’re working with. I can’t say it was easy, in fact we had a few tricky moments I’d like to take up with you.
Tutor: Sure – but I never said it was easy!
Pupil: Well, we started by writing the subject area on the board in the format you suggested last time we met: ‘The business of subsidy claim management in the Ministry of Administrative Affairs (MAA)’.
Tutor: Sounds like a good start. Did they suggest that?
Pupil: Pretty much. They wanted to include all the contributions to the management of subsidy claims across the whole of MAA. In fact, to start with they thought about all claims in just one department of the MAA, but after some discussion – which I think they actually found really useful – they realised that it was subsidy claims that were the troublesome area in particular and that if they were going to avoid taking a narrow, stove-pipe view they needed to open it up to the entire Ministry. I was a bit worried by the amount of time they spent on discussing this, but I realise now that it was time well spent, even if all we seemed to get out of it was twelve words.
Tutor: Good start.
Pupil: So we then told them about the idea of an essential business entity . . .
Tutor: How did you describe an EBE?
Pupil: ‘A thing that is the essence of the business’, ‘some thing that characterises the business, that you can’t get away from if you’re in that business’ and so on . . .
Tutor: And how did they take to that?
Pupil: Well, slowly, as you said they would. There was a bit of a silence, so I suggested ‘a Subsidy’ to get the ball rolling. Then someone suggested ‘a Subsidy Claim’ . . . that was good and so we had two on the flipchart. But then someone suggested ‘management’.
Tutor: Right, there will always be a first suggestion that is not the sort of entity you want and in your workshop it came out pretty early. What happened?
Pupil: Well, I remembered the method and said that the one rule was that we had to be able to put the word ‘a’ or ‘an’ in front of it, as a check that it was a thing and moreover the sort of thing that can be separated from another one. And ‘a Management’ doesn’t work. So I said I wouldn’t let them have that and then the trouble started – ‘Since we’re in the business of managing subsidy claims it’s a bit odd that an important topic like management isn’t on the list’. How should I have handled that?
Tutor: Firstly, that’s a perfectly normal thing to happen. It can take a while for people to see the sort of thing you are looking for and it sometimes needs some pushing to get them to come up with those sorts of thing and no others. A useful test for the sort of entity we are looking for is ‘can I list the examples of this entity that we have at the moment?’ The answer is clearly ‘yes’ for something like ‘employee’, or ‘job application’, or ‘complaint’. The answer is clearly ‘no’ for things like ‘management’, ‘safety’, and ‘quality’. Secondly, you need to be very strict with the people in the room about letting them have only the things that meet the rules. It’s your workshop and you know what is needed to get a result. The workshop isn’t there for them to have all their thoughts dutifully recorded: you might need to remind them occasionally that the exercise has a very specific purpose (to get to the process architecture for the business concerned) and that the steps are carefully designed to achieve that purpose. Just because something is left off the board (or bracketed) doesn’t mean we don’t do it – simply that it’s not useful for this exercise. Being strict is hard if the group you’re working with is The People At The Top as I suggested last time we met. But you have to do it or they will derail your workshop! So, given that you aren’t going to let them have ‘management’ per se, you need to get behind the topic to find the entities – what sort of things do they manage? My guess would be ‘an Application for a Subsidy’, ‘a Change to a Subsidy’, . . . am I getting close?
Pupil: Yes, that’s in fact the sort of thing we managed to get out.
Tutor: You see, when you get what you think is the list of EBEs that ‘characterise the business concerned’, the test is to ask ‘if we concerned ourselves with all these things, would we be doing that business?’ Of course, if they were thinking about management in the sense of ‘managing the work’, then you can rightly say ‘the MAA is not in the business of managing work – it’s in the business of managing subsidies’. Now we both know that ‘managing the work’ in the sense of resource scheduling and allocation will be covered by the case management process later on, so we’ll cover that angle as well in fact, but at this stage in the method we concentrate single-mindedly on the entities that characterise the business we are in. A similar problem you might get is when people suggest things like ‘safety’ or ‘profit’ or ‘transparency’ . . .
Pupil: . . . exactly – we had ‘transparency’ – they were very keen that the way they dealt with things was transparent and it was with a little reluctance that ‘a Transparency’ didn’t go on the flipchart! . . .
Tutor: . . . right – transparent is how we want our processes to be, but it’s not what we are in business for. So you were right to steer them away from that one. Similarly, if you do get something like ‘security’, push them to find the EBEs behind it – how about ‘security risk’, ‘security measure’, and security breach’? These all satisfy the rules. Of course, many processes will have a security aspect or security content, but that’s a fact about those processes and doesn’t mean that ‘security’ generates processes itself unless we can find entities like ‘security measure’. People will also suggest things like ‘cash’, ‘quality’, ‘recruitment’ – none of these are EBEs – they don’t satisfy the ‘a’/’an’ test. Someone once called me to say that he was surprised that ‘profit’ wasn’t an automatic EBE for every business. I had to point out that, firstly, it’s not an entity in the sense that I want it (it fails the ‘can I list them?’ test), and secondly not every organisation is in business to make a profit – try your local police force for instance, or scout troop. Moreover, you and I could be in the same business – dealing with the same things – yet I could want to make a profit and you could be in a not-for-profit organisation. Schools are an obvious example. Profit is a goal of the organisation, not something that characterises its business.
Pupil: Thanks! I’m comforted to hear that although we had to push them we pushed them in the right way! In the end we actually ended up with 35 items . . . which I think surprised them.
Tutor: You know, there’s really no rule about how many you should have. I once worked with a local authority – they do so many things we ended up with about 250! At the other end of the spectrum I’ve worked with a small group with a very narrow remit and got just ten. Whatever number you get is OK! Anyway – good start – next time we meet I’ll give you some more guidance on this.
Best wishes, Martyn Ould
In my previous posting I effectively started a sequence on the Riva method for building a process architecture for your organisation. I stressed that the central purpose of the process architecture is to tell us what processes we need in order to be in the business we are in. (By the bye, this makes it a very useful approach for getting started when you have an entirely new organisation do an entirely new job – it’s hard to know where to start without something like a Riva process architecture.)
In my book Business Process Management – A Rigorous Approach I introduced a couple of useful characters: a Tutor and Pupil. They had some valuable discussions next to the water-cooler and it feels like a good moment to bring them back onto the stage. I’ll pass the baton to them . . .
Pupil: Well, I know you like to be both economical and clear in your use of terms so I should point out that you’ve already used two words without saying what you mean by them: organisation and business. I’ve heard you talking about ‘the business of the organisation’, and ‘the organisation doing its business’, and ‘the organisation being in business to . . .’ – just what do these mean?
Tutor: When I talk about an ‘organisation’ don’t assume I’m only talking about some corporate identity such as Venice Consulting, or the Ministry of Defence, or a department in the Ministry of Defence, or a particular bank, or a scout troop, or a church hall committee. Those certainly count as organisations, but an organisation can also be any grouping of people and/or corporate bodies. How about a service company and its clients, a manufacturing company and its immediate suppliers, or a manufacturing company and its entire supply chain? Or a police force, or a police force and the justice system together, or the justice system and the social welfare system together.
Pupil: I think you’re saying it’s really whatever grouping of people we want to talk about.
Tutor: I knew you wouldn’t like that but it’s true. And it’s important to feel the freedom to think about these more complex gatherings if we are to avoid the silo trap. The other thing I want to point out is that one organisation can have many businesses, or many aspects to its business.
Pupil: But surely one organisation is in one business?
Tutor: At some level of abstraction that might be true for some organisations. But take a Local Authority they are a gathering of many different overlapping ‘businesses’ – a real A-Z organisation, from aliens to zoos – they deal with all human life. So we might want to concentrate on the ‘business of traffic management in a local authority’.
Pupil: I like the idea of characterising both the business and the organisation in the one phrase. I can imagine things like ‘the business of crime prevention in a local authority’ or ‘the business of street safety in a local authority’ – I guess that we might want to investigate the processes of these ‘businesses’ and to do that we will want a process architecture for them.
Tutor: Exactly – and I can go a step further because we might have a very focused organisation yet identify particular aspects to its business: ‘the business of asset management in the Ministry of Administrative Affairs’ or ‘the business of retaining staff in our retail arm’. We can think of these as supra-departmental practice areas or disciplines. Here are some more for you: ‘the business of emergency surgery in a hospital’, ‘the business of research and development in a pharmaceutical company’, ‘the business of customer care in a retail chain’. Can you push the idea a bit further?
Pupil: Well I guess I could generalise it to think in terms of any sort of ‘venture’? How about raising money for a charity?
Tutor: Perfect. Any method worth its salt should allow us to construct a process architecture for ‘the business of raising money at a charity’. And I’ll give you a nice example I came across recently: ‘the business of getting innovations into the National Health Service’. It’s a big complex affair involving many organisations operating as one large virtual one: governments departments, venture capitalists, health authorities, regulatory bodies, and so on. How do you get your arms round that one? With a Riva process architecture – it’s been done. So, right at the start of the exercise to prepare a process architecture it’s good practice to focus minds by deciding what business and what organisation. Next time we meet we’ll talk through some of the problems you’ve been having with the concepts of essential business entities and units of work. They’re central to getting to that process architecture and the clearer you are about them the easier it becomes.
Pupil: It’s a deal!
Best wishes, Martyn Ould
I often see pictures of supposed process architectures for organisations that classify processes into three types: ‘core’, ‘support’, and ‘management’. I’ve learnt to be suspicious of taxonomies like this. In particular, I’ve learnt to ask the question ‘what good will it do us to have this classification?’ I have been at meetings where people have argued about whether Process A is ‘core’ or ‘support’, or ‘support’ or ‘management’. The discussion/argument/row got nobody anywhere. In worse cases, time has then been spent on arguing about the definitions of the three classes as a step to being able to decide which class Process A is in. Even if a definition results and all can agree that Process A is a ‘support’ process, where has that got us?
Nineteenth-century botanists were classifiers. Defining complex taxonomies was the order of the day. Debating where a newly-found plant fell in the taxonomy was an important test of the taxonomy. But BPMers are not botanists.
I could go one step further. How much time is spent trying to define a ‘process’? Again, where does such a definition get us? How will we use the definition? Will we take a lump of organisational activity and put it against the definition to see if that lump qualifies for the title ‘process’? I don’t think so. Put another way, how would any definition help us find the processes in the organisational activity? That, after all, is what is important.
This is all leading up to pointing out that Riva prefers to provide a method that delivers processes, rather than providing definitions and taxonomies that don’t. Yes, I do give a definition of the word ‘process’ in my training courses and in my book. But I don’t use it. Definitions don’t do anything. Yes, I do have a taxonomy of processes into case processes, case management processes, and case strategy processes. And I give examples of them. But you don’t have firstly to decide on your processes and then secondly to classify them: by following the method you find out what processes you have, under the three headings. The method leads you to the processes – you do not have to magic them out of the air.
So next time someone says ‘There are three sorts of processes: core, support, and management’, just ask them ‘How will that help us move forward?’ and save a lot of wasted time.
Best wishes, Martyn Ould
I’m really pleased that this blog dedicated to the Riva method is under way, and my thanks must go to Luis Bender for providing the impetus.
To my embarrassment, over the years many people have pointed out the need for a forum where Riva practitioners can discuss the method and share insights – now at last we have it. Personally I plan to post items at two levels. The first will consist of larger and broader articles, taking a view of the method at a high level – for instance, I’m planning to post an article on the value of working with abstract roles, and another on why ‘kebab’ architectures are evil. The second will be smaller, more focused pieces, looking at typical situations and how Riva can help address them, or highlighting a point of methodology – I expect to find myself writing these as a result of my own day-to-day use of the method. I keep a day-book and frequently find myself making a ‘methodological note’ to myself – such notes represent my own learning and I plan to share them. I hope others will post about their own experiences but this blog can also be the place to pose questions to me and the community. If there is someone whom you think should be contributing, do let me have a name and email address. Pitch in!
Best wishes, Martyn Ould