Why I would always map the existing process in discovery
A few weeks ago(now months when I actually finish this post) there was a really interesting discussion on Twitter prompted by Ben Holliday, it is such a strange situation where I both agree and fundamentally disagree at the same time. There are some assumptions in the discussion that for me are not my experience at all. I want to try and explain why. This post is focussing on a lot of Public Sector use cases but the approach works for any industry or businesses where you are looking to deliver process improvements.
It’s a question of value
A discovery happens because an organization is looking to improve the value chain. They are looking to change and improve services to deliver more value for the customer and the business.
Generally, we are trying to do one or more of these types of things:
Enabling greater efficiency and less resource waste
Enabling better business decisions
Enabling new idea generation
Enabling faster commercial growth
Enabling improved customer service
The aims of discovery are as follows:
Before you commit to building a service, you need to understand the problem that needs to be solved.
That means learning about:
your users and what they’re trying to achieve
any constraints you’d face making changes to how the service is run – for example, because of technology or legislation
the underlying policy intent you’ve been set up to address – this is the thing that government wants to change or make happen
opportunities to improve things – by sharing data with other teams, for example
The current process is an integral part of gaining an understanding of why. Business process mapping helps you discover what is going on right now and why and as such I cannot see how you would run a discovery without understanding the current process through a process discovery exercise. The discovery process is focused on user needs and user research and I believe that can be done more effectively when understanding why the current user experience is what it is.
Why map the current process in discovery?
The Government Digital Service itself highlights the importance of understanding the constraints and highlights 4 specific examples (see below). All of these would be explored and understood in an effective process mapping workshop.
You’ll also need to understand any constraints you’re likely to come up against if you were to move on to the alpha phase. This includes constraints due to things like:
If you look at any generic service/process, I would argue your process has the biggest impact on the current user experience ahead of all the other factors. If discovery is about understanding the problem then you must look at understanding the As-Is process through a process discovery workshop. If you do this right you will understand all the other factors and how they impact the service delivery and as such is one of the critical discovery activities. If there is an existing process I would always want to understand it first. The knowledge this gives you helps inform the wider service design process.
Processes are complex and customer demand moves through many a process step, multiples systems, departments, team members, and priorities before a service is delivered or not. If you do not understand this during discovery when would you do it? This directly impacts on the current user perspective. Why would you not want to do this step when it should only take a couple of days maximum. An added bonus of the process mapping (process discovery) workshop is to engage all stakeholders from across the end to end process in understanding the current delivery and upcoming change.
Let’s not forget that the discovery team is ultimately trying to deliver business process improvement. If we want to improve what we do we are ultimately going to be deploying some sort of process optimization or new service(process) design.
As this is a strategic process I tried to express it via a Wardley Map I am a total novice at this so be kind (but have met Simon and had the pleasure of hosting a webinar with him) (access it here)
The narrative is what’s important with a Wardley Map so I provide my thinking below the image.
If anyone wants to use the tool I used to do the Wardley Map sign up free here many thanks Rainmaker for the brilliant free tool.
Service Access – From a broad perspective a generic value chain for your services starts with a customer, citizen, patient, client, or any other service user needing to access a service, product, or information from you.
Business Process – I would argue the thing that is most visible to your users is your custom-built business process. The user journey is intrinsically linked with the whole process as at each step the process is defining the dynamic steps ‘necessary’ to deliver the user needs. The business process defines every step of this process from the digital right through to delivery.
Systems – There could sometimes be an argument that in some channels the systems could be more visible to the user than the current state process but this is mainly only the digital space and fundamentally overall I feel that the real work is impacted more by process than systems. The systems sit in the product area in the diagram but there may be some custom-built applications deployed in your business operations.
Next in the value chain is Business Rules. It does seem silly to have business processes and business rules as separate entities as it is easy to make the assumption they are aligned. In our experience that is not always the case, there are many reasons for this but a critical one we see regularly is how we often optimize processes in organizational silos. If we do not see the full picture of the end to end process it is hugely likely we do not have an accurate picture of the alignment of each change and that it will have a positive overall impact and take us in the right strategic direction. Business rules are again custom-built in terms of evolution.
Following this is Legislation. The legislation is set by the government and not easy to change I have placed this further down the visible value chain as it is less visible to the users although can become very visual to users at various points in the real-life processes. In many a use case, the discovery map will show that legislation has very little visible impact. The legislation is in the product evolution space.
Next up comes people. By this, we are talking about having the people to fulfill the process itself. We have put this in product as temporary or permanent people can be acquired from the market. With Robotic Process Automation, Artificial Intelligence, and integration of systems, the reliance on manual process inputs is reducing over time.
Resources come next in the visual representation of the value chain. Here we are talking about the physical resources to deliver the products or services like inventory or delivery vehicles. Again this is put in the product area of evolution.
Finally, we have finance. This is rare for this to become visible to users during the process, and again we have put this in product due to the way finances are generally managed with clearly defined rules and regulations.
If an existing process is in place I would always want to capture and understand the process first and it doesn’t take much effort. It is a great way to capture a shared visual design (process diagram) for the current process with stakeholders from the entire value chain. The mapping process itself helps you gain real user insights and process intelligence. This helps to gain an understanding of why the user experience is what it currently is and will give you an accurate view of the starting point. For me running a process discovery in no way is constraining you to a predetermined solution.
If anything the process mapping exercise should in fact give you a great opportunity to engage your business users in your design principles and the discovery techniques you will be using in the discovery phase. So for me, your existing process is critical to users and your business process management. It helps you to identify problem areas, existing ideas, team members, data collection, technical details, and important issues.
There are often implicit assumptions about the way our processes work but we regularly find blind spots and incorrect assumptions when undertaking process analysis initiatives at the right level of detail. A manager’s eye view of the service will often differ from the reality of what an accurate process map will help you to understand about the variations, cycle time, documents, systems, roles, actions, and user experiences of the entire process.
10 reasons to map the existing process in discovery
To get everyone on the same page about how the process currently operates
To engage all process actors in understanding the current process and the purpose of this intervention
To understand the times and costs relating to the delivery of that process or service
To understand why the current process performs the way it does
To understand problems and ideas for improvement related to the service
To understand where customer value is being delivered
Understand who is involved in the process and what systems/resources are being used
Understand legislative and business rules and how they relate to the delivery
Find bottlenecks and waste in the process
To generate ideas or hypotheses to test with users
To engage everyone involved in the change or improvement
I will find some things I can fix right now and make the process better for customers
I have a documented and understood map of the process that has been co-designed and owned by the people currently delivering the process.
Ok so I cheated a bit that’s 13 and to be fair I could add many more. The process map is just a single output and in itself does not give you the majority of these.
All of this does not need to take a lot of time. On average in a 1 day workshop you can get all of this for most processes. Is this information useful to know as part of any discovery?
Why do people not see value in mapping processes?
There are some common reasons I see and coming out from that Twitter thread
Process mapping takes a long time/I don’t see much benefit from the outputs produced after process mapping.
By mapping processes, we constrain ourselves to just improving and not innovating with things like service design or new business models
We should be doing service design, not business analysis or continuous improvement
It’s not discovery if we are mapping the current business process
I cover these reasons in more detail below with my responses.
Process mapping takes a long time/I don’t see much benefit from the outputs produced after process mapping.
I agree with this statement and understand where it comes from but I have a slightly different perspective. The problems with process mapping relate more to whether you are getting value from your individual approach to process mapping. If you get the benefits above in a day then you probably see the value if you don’t then you may well start to question the value. As an example (all too common) I have seen mapping a service take 6 months elapsed time and the outputs are n