When analyzing and implementing processes, I found out that we (ok, that includes me...) often focus too much on the core "content" process at hand. We dive into the main "named" processes that are in our scope, focus on the participants, activities, rules, etc. - model them, design improved processes and implement them. But due to this focus on "named content" we tend to forget that every process actually turns out to be three processes (and maybe even 3 more, more on this later).
If we only explore the main one, the other's are either implicitely covered, or completely forgotten, with all negative (change) consequences.
As an example: suppose our scope is "provide quote", in, say, a credit lending bank area. As analysts we dive into the process, find and model all activities - receive quote request, determine credit worthiness, calculate proposed interest rate, create quote, send quote, etc.
And if we are lucky, some analyst might even ask - what are KPI's or what is the management information that is required for the people steering this process? That person felt possibly intuitively that there are other processes floating around.
We might end up with a great "provide quote" process, and yet we might face issues around change management and reinforcement of improvements.
Let's get to the point:
The three processes that "hide in every process" in my opinion are:
- The "content process" - e.g. the main process, aimed at fullfilling the specific customer request, activities leading to the transformation of input to output
- The "operational management process" - the proces (usually plan-do-check-act) of making sure that the "content process" keeps performing.
- The "improve and (re)align process" - the process of "sharpening the saw", making sure that the content process (and operational management process) are improved, and when strategy changes of the company occur, that these processes are adapted to the new strategy .
1. As said, most of analyst's attention typically is spend on the "content process". That's ok, since in the end, if that does not run well, we end up with nothing. But let's not forget the other processes....
2. If we look at the operational management process, we might have analysts remembering that we need "management information". That's a step, but not the complete one. Steering requires a number of "process items":
- Who is steering?
- What process is followed for the steering?
- What possibilities are there for interventions ("act"), if process performance is not acceptable? According to what policies and rules?
- What information is required to steer (for planning, for checking), with what frequencies, in what form?
If we only focus on management information, we forget to focus on understanding and implementing the operational management process. Something I earlier wrote about in
"driving 50 MPH without a steer".
3. Interestly, whenever I start talking about operational management, process participants start to look "upward" to a management level. That's a choice, and usually determined by company culture.
My point is: many of the operational management activities you can also place at the process participants level. Many principles ("when is our process functioning fine, and in what situations should we act to correct issues) can better be done by the process participants themselves - they have the knowledge and see things happening. Instead of thinking "I should focus on the process and not the issue, my manager should fix this", we can make them responsible for steering as well. "When I see someone in my team having too much work, I will jump in and help", "When I see an error, I fix it, and make sure we don't make the same error again"...
4. You might object, and say "operational management" and possibly even more "improve and (re)align" should be part of a top-down scope in which we create a BPM framework for management. Sure, that's fine - if it's there. But in many situations that might take a long time. Don't wait for it - start bottom-up/middle out, learn and evaluate.
Conclusion: focus on content is fine, but don't forget to implement operational management and improve/(re)align.
As a PS:
I talked about possibly three more. These are:
- Your supplier and customer processes. What steps do they need to take to deliver and get their need fulfillled? If we forget to look at these processes, then we also miss out on possibly great opportunities for improvement in their and our own processes.
- Supporting processes. I remember working on an improvement project, where we just could not figure out why a certain process step (content level) was taking 2 - 3 days. When diving deeper, we found a supporting process (deliver physical mail) where moving a certain paper-folder took 2 days. Ah.