A few months ago I wrote a blog about how process models were over-used in analyses. Yes, mapping in BPMN seems like a reasonable way to start improving processes. But my point was that it shouldn’t be the only way (nor should it be the final result).
Now as I go off on my latest and greatest improvement journey, I find myself going through my mental cycle to select the right tool for the job. I think about the client requirement, the level of detail and my past experiences to formulate an analysis strategy. But perhaps others don’t have enough experience to think of anything other than process modeling to begin with?
So to fill a potential gap in my first post, I wanted to supplement my thoughts on BPM with some of my favorite alternatives, how to use them and when they work best. I hope you can use this quick cheat sheet to build up your own mental cycle and diversify your tactics moving forward.
Functional Modelling
I’ll start with function mapping as it’s probably my favorite. In fact, many times I create a functional model just to inform how to approach my eventual BPM.
What is it?
Think value chain but not necessarily in a sequence. It involves categorizing the main chunks of work your team performs.
For example, a doctor’s visit may entail patient registration, nurse examination and doctor evaluation. These would be at a “function” level and define the full scope of a certain part of the business.
The “map” can consist of the function headers at the top and can be enriched with key details such as activities, owners and systems involved. It creates a nice overview of everything going on at a higher level than a process model.
Why do I like it?
Taking the doctor example, aligning to functions immediately helps organize the rest of my analysis. I can associate metrics per function and then dive into different processes underneath each to uncover pain points. So if patient registration is the key complaint, I’ve already narrowed down my focus in an effective way.
In addition, if I had started at the process level, I may not realize the full scope of a certain service, and therefore may get stuck in local optimization land.
And finally, aligning by function helps standardize how your different stakeholders describe and define how value is delivered to the client. It’s always nice when we are speaking the same language, right?
When to use it?
I would say always but to varying degrees. If the analysis requires deep investigation into a specific topic, I would do a quick function map just for my own sanity check. But if there is great disparity in the overall way the business operates, a stakeholder facing functional model is much more affective than a seemingly unorganized set of BPMs.
Also note that picking the right level of detail is a bit of an art. Try starting with function groupings based on key milestones, assets created or specific value delivered to the client and adjust from there.
Inputs and Outputs
A modified version of SIPOC, and a very bland name to go with it! My analyses lean on simplicity and this approach applies that principle.
What is it?
A simple diagram that treats a certain team, function or process as a black box. All of the different “inputs” are then attached to that black box. Things like data, team hand-offs, incoming requests or anything else relevant to the analysis. The same is then done on the output side to show what the black box creates and where it goes.
For example, a team is inundated with numerous ad-hoc requests, calls, emails etc from many different sources. An input and output diagram can summarize all the different ways the team is interacted with in a single succinct visual.
Why do I like it?
It’s an awesome visual that creates a repository for the chaos.
The above example allows for someone to look at all the inputs/outputs and group interactions, find duplication and anything else that might help. Maybe the team is creating similar reports for two requesting teams? That is immediately evident in the diagram and can be an immediate improvement focal point.
When to use it?
When it’s less about the process steps and more about scaling the overall function. Or when you identify that lots of separate activities are happening and you need a quick way to document them all.
If however, the client is looking to understand exactly what the “black box” is doing, then this isn’t the best approach.
Story Mapping
Similar to functional modeling, but with some cool enhancements that help connect your analysis to tech requirements.
What is it?
A single view that organizes potential feature enhancements by function goals and user personas. Analyses using story mapping first define their goals and personas, and then survey those groups for pain points and requirements. The resulting information is summarized in the map view to facilitate epic creation and prioritization.
Its important to note that this is a different type of methodology that focuses on solution requirements rather than the initial pain points that necessitate them.
Why I like it?
Although a bit more solution focused, it requires the analyzer to anchor all data to specific users and goals. Sometimes when documenting a process, we lose sight of that key interaction between the different personas and requirements for each. Story mapping helps reinforce the importance of those nuances, creating forums for each unique set of stakeholders.
When to use it?
Engagements that have pain points and process details more well known, and the solution is heavily supported by technology. Bonus points if the teams you are working with are prepping sprints and planning delivery in an agile manner.
But as always, if you are still figuring out pain points to tackle, start with a process model.
Other Options and Final Thoughts
The above 3 options are my most frequent alternates but there are of course many other options to explore outside of process modeling. A quick flow chart is a great way to document a sequence if speed is of the essence (or if you don’t have an easy to use modelling software). Anecdotal collections of pain points paired with objectives is an amazing asset to have if the process is not the focal point. And user stories are another standard way to document requirements outside of story maps.
And take these options with a grain of salt. I’ve modified these to fit my own purposes from some of the standard methods out there. I hope this list at least gives some perspective and helps you find your own list that works just as well.
Remember, the goal of an analysis is to help your client or team move forward with a decision. Stay focused and strive to find the right set of details for any mission.
Happy alternating!