« Democracy: AKA Collaborative BPM | Home | Is there a governing body for lifecycle development/management of BPM solutions? »
Process Discovery Done Right (R5)
By Jim Sinur | December 4, 2007
Managing process workout sessions is the secret sauce in process discovery.
There is a direct relationship between the success of process discovery and the amount/duration of benefits that are derived from BPM efforts.
To that end, I have indentified the five right things (R5) to concentrate on in order to ensure success with process discovery going forward.
Right Focus:
In an ideal situation, your organization would have identified the most important processes and put the full weight of management commitment behind the highest priority process for your organization to tackle. If you are not blessed with that kind of situation, it is important to try to focus on the highest level of resources you can garner at the time of the discovery effort.
Quite often you will discover links to other areas that may require additional participants. If you can show early benefits because of potentially duplicated steps, errors, waste or unnecessary wait times, you can justify the additional participants to decision makers. The bigger the picture you can start with, the bigger the potential for benefits and the riskier it is to complete. Once you have a simple big picture, it would be wise to take low hanging benefits or make simple manual changes to show a quick time to benefit.
Right Facilitator:
Having the right facilitator is another important ingredient for success. The ideal facilitator should be independent from the outcome of the discovery process. Sometimes this is an experienced outside facilitator in organizations that are new to BPM.
Over time, organizations can grow their own facilitators and/or import talent that has a track record. More mature organizations have a process center of excellence that is committed to teach others about process disciplines until an organization becomes process centric with proper agility leverage points instrumented in the resulting processes.
Right Participants:
It is imperative that the involved business professionals have knowledge of the existing process tributaries, have some vision and can carry out actions that will help the implementation of process change. It is very difficult to find all those factors in each person participating unless you are extremely fortunate, so crafting a team that puts these three factors in balance is important.
I would also add a practitioner from IT to participate in an answer-only mode to anticipate the ramifications of down stream decision changes and system impacts. This person would be a great recorder and would be able to leverage tools to help the process.
Right Methodology:
Methodologies are great, but methodologists are dangerous. It’s important to have a methodology that the group can be comfortable with. Quite often they come with the facilitator or the facilitator could tell the participants the trade offs.
Quite often the one that is given with process analysis training will do well as a starting point. Make sure you have one because it gives guidance for milestones and deliverables.
Right Mindset:
It’s important to understand that having a consensus will avoid the creation of shadow processes. Shadow processes are alternatives to the “official” process and spring up because there are issues that are unresolved.
These can include having a process that is not clearly defined nor communicated, a process that does not have a perceived benefit to the participant, the new process takes longer than the old, the new process is more complex, the culture is too rigid for the process and people are just unwilling to adapt.
It is important to anticipate these issues during the discovery process and recognize the danger of creating shadow processes inadvertently.
Caveats:
One of the phenomena of a successful process discovery effort is that all participants will declare that they received new insights from the process discovery effort and might even suggest that the sum knowledge of the participants was less than the resulting process.
Most organizations can benefit from multiple iterations and fast communication and modification cycles around the evolving process model. Modeling tools can really supercharge these efforts.
Bottom Line:
Process Discovery is Critical for BPM Success.
How successful you are on initial process discovery and the upgrading of a process once it is running will be critical to the overall success of BPM in your organization. Live well and prosper with good process discovery.
Topics: BPM |
December 5th, 2007 at 3:19 pm
[...] Process Discovery Done Right (R5) (tags: bpm processdiscovery) [...]
December 30th, 2007 at 8:04 pm
Jim
I would like to say that the points raised are all efficient, but it may be that such efficiency is what contributes to the sheer time taken to do BPD. One of your old G—— docs said as much as 40% of the time to automate a process was invested in the AS IS discovery phace with another 11% tied up in the documentation phase - no wonder BPMS sales are slow in relation to the actual market oppertunity for such vendors.
Hap hazzard and incidental can work just as well, if not better than governed and heavily managed. I go around proposing “30 in 30″, capture thirty processes in thirty days - and so far it is working. I have one client who has a recent grad doing 30 a week - she has six colleagues in that BPO with the lowest on 5 a week - I do not have an agile framework for it, less control is yielding better results.
If I go into a new prospect company to write our, model and produce appropriate documentation on one of their business processs then speed and credibility are everything to a good meeting. If I have not done it in less than half an hour, then we walk away and make our appologies. I only ever had to do that once, and that was because they could not agree on how they did things, it was not actually down to us in reality.
OK, I am not talking about the end to end manufacturing process of DELL or IBM, but I would regularly do a NEW HIRE or SALES process in that time. We then get a group to follow what we did for what they do - so in a few days we can end up with 30 processes and spend the rest of the month on clarification, defining the best practice, and looking for points of automation or general improvement. I say we- they usually do it themselves.
Have a great 2008.
Cheers from a fan,
Alan Crean
January 3rd, 2008 at 8:52 am
Alan,
You bring up two great points on time boxing and iteration. A successful facilitator will bring both of these tactics to the process discovery effort. A good methodology will have iteration built into it by design. It is always important to get a high level starting process to test out the major process flow quickly and the devilish details can be added in as you go. This is consistent with the “80/20″ rule where you get 80% of the benefit with 20% of the effort.
Your suggestion to do many processes (30) in a short time (30 days) to build an overall process inventory is an intersting one that I would like to talk to you about. Thanks for your comments.
Regards,
Jim Sinur
January 18th, 2008 at 7:08 pm
I’ve started with a list of processes to automate but I’m quickly finding that the list isn’t exactly written in stone. Sometimes the “process” to be automated is actually an outcome of another process. For example: I have a process called “Rejected Order”. This is really the end result of the “Order Process” workflow. That is a little simplified but you get the idea.
Sometimes it’s not too easy to tell what comes first - kind of like the chicken and the egg so I’m doing the following and it seems to be working well:
1. A quick flow chart of the process in question. I do this very quick and dirty because the objective is to find where the work item is really coming from. So my start point should tell me if this is a process unto itself.
2. After I draw it I write a short text description of what’s supposed to go on from my drawing. I make myself explain each step that I’ve drawn in a sentence. When I do this I begin to see where things don’t make sense or where I need to ask more questions. It’s a good way to question my design with little pain. It’s also good because I’ve shut off the thinking process and am only describing the action behind each step in my process so I’m approaching it from a functional vs. analytical sense and that’s when gaps and holes start to show up.
3. After I get through the text description I make myself list the objective of the process. You may ask why I don’t do this up front - it’s because I want to first determine that I’m actually dealing with a process vs. something else. So I list the objectives, advantages and reasons why the process should exist. If I can’t justify that the process should exist within five minutes I flag it to go back to the line of business for discussion and go on to the next one.
January 21st, 2008 at 8:37 am
This is a nice approach to help scope a process.
I like the realistic approach of leveraging the functional descriptions to test your “quick start” model.
I also appreciate the “net summary” test to verify that you landed a real process.
This is the kind of practical set of comments I was hopiing to see on the blog to extend the discussion. Thanks for the tips
Jim
May 21st, 2008 at 11:47 am
Hi Jim
You mentioned in your reply that we could have a chat - which I would very much appreciate.
I am alan.crean@processmaster.com if you could give me a number and suggested time, I would love to have a chat.
Cheers
Alan