Should we use flow charts, swim lanes, value stream mapping, proprietary software notation, or BPMN? Yes, there a number of notations you could use, and you want to pick the right one for your organization.
The first question to ask is what is the purpose of the process diagramming notation? Since there are several purposes for process diagramming at different stages of a BPM/ process improvement project, you may switch to one type of notation or another at different times.
Purpose 1: A high level map to scope the project and as part of the charter. Here I suggest using a simple flow chart with 6-10 steps using rectangle for activities/steps, diamond shaped decision diamonds and directional arrows. You could actually create it in PowerPoint, but I usually do it in Visio. The purpose of this map is to get people understanding what a process looks like.
A high level process map is:
Purpose 2: Transition to BPMN at the Top Level
After the high level map is completed (which is part of the charter—another critical element to get a BPM project off to the right start), I suggest taking the high level map and use BPMN to develop a top level model. There are many similarities to the high level map you have already done, but three critical differences:
Purpose 3: Detailed As Is Process Diagrams. Here you want to model process diagrams that show actors and the tasks they perform or are automated in their area of responsibility.
Now I suggest using a combination of methods:
I like the butcher paper because it engages the full BPM team the best. The facilitator runs the session and captures one instance of process. Capturing one instance of a real completed process makes it easy to document the model in 90 minutes or less, and it won’t have the spaghetti diagram like a process model showing all the exceptions. It will show what happened in that one instance.
More instances? Yes, you may need to model some other instances beyond the original one. You need to capture instances that include each of the exception end states. You also may want to capture additional instances for different levels of complexity, different customer groups, or variations in process at different locations. Carefully decide which additional instances are useful. Don’t make this an exercise in creating multiple models. Often after doing a few models the team begins to see what sections of the process are consistent and sections where they are not. I then create a consolidated model and use that for analysis. The consolidated model can be the first step in standardizing the process.
Creating the As Is Instance using stickies on the butcher paper is a light touch way of documenting a current state model. The team has fun, gets the model done, and identifies issues, data, and improvement ideas quickly. I set it up with the black box customer lane at the top, and the internal pool underneath. It is very easy to make changes – just throw out and rewrite the stickies.
I find the best approach is to have a BPMN recorder simultaneously capture the process model on his/her laptop. That way the BPMN model is done real time and there is no time delay. This method avoids a few of the problems with going straight to the laptop, such as
Now there are a few things to finish up these BPMN models.
Modeling in BPMN provides a standard that can be communicated and shared. It uses an explicit language and method. I can’t tell you how often clients tell me. “ We have already modeled our current state processes.” I always say, “Great. We will build off that work.” Later when I look at these models, I often don’t understand them. The person who documented them used flow chart symbols and other symbols in a ‘creative’ way and only s/he can read the model.
So create As Is models flowing the process on the wall and capture it in BPMN simultaneously. Then go back and review the BPMN process diagram with the team. The team will soon be able to read the BPMN diagram easily but they may not have been able to build it initially. And the BPMN process model conveys the logic of the process unambiguously from the diagram. That means its executable as well.
As Is process models represent how the process is currently performed. They are the baseline model, just like baseline metrics. You need to know where the process is today, but don’t worry about getting the diagram perfect. The current state diagram is used for analysis. You will learn what is working, identify the current problems, see who does what, find out how many hand offs there are, and identify the many layers of approval. The current state map is the first technique for analysis.
Two sources to learn more about BPMN:
Business Analyst Training Courses and Reading Recommendations
What is BPM Anyway? Business Process Management Explained
Becoming A Process-Focused Organization
Your BPM Implementation is Bound to Fail
Building a Process Catalog: The Journey Begins
Ten Tips for Effective Process Modeling
Which BPM Modeling Notation Should We Use?
View other Business Process Management articles, webcasts and whitepapers
There are no products in your shopping cart.
0 Items |
Read more about Business Process Management.
View more Business Process Management articles, webcasts and whitepapers
BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page.
BPM 101OpEx Tools of the TradeMethodologies and Approaches for BPMOpEx 101Process Modeling, Analysis and Design: As Is, To BeView the Learning Path for more courses »
Steve, I have always felt
I have always felt that industry process reference models are a good idea, and have looked at them, but never used them in my method. How do you use them? Shelley
Hi Frederic I appreciate your
I appreciate your thoughtful comment. I have talked about when to use BPMN with Bruce on several cases, and know his book. I agree with your steps 1, 2, and 3 above and use them. I often use Visio with #4. But I feel it is useful to get the business user to see and understand BPMN, and Bruce feels this is best using OMG level one symbols and structure. So I would say that your #5 is where I would involve more technical people. It is fine with me to wait until the design phase to use BPMN. Bruce has been encouraging me to use it earlier. I am not always sure we get it exactly right, but we do a much better job of thinking. For me the analysis phase is best looking at a graphical model and then doing the data analysis, root cause, standardization etc off of that vs. narrative use cases. Thank you for your comment. Shelley
From my own experience, I
Recently, I've been involved as a BPM expert in two already started projects which were in a bad situation. One of the main issue was precisely that analysts tried to use BPMN and Visio before having a vision on their user and business requirements. They drew BPMN and Visio diagram, but having not a precise idea of the sense of the drawn items and how to use it in the next phases of the project. Diagrams mixed diffent concepts (objectives, user requirements, business requirements, design requirements). They were also many and many inconsistencies between the diagrams. They were also sometimes too much detailed, and sometimes not detailed enough.
'Some colleagues use the BPMN notation level 1' Why not if it's for giving an idea of the processus. But it's a short term diagram and must not be maintained. However, using a wording description is certainly much more efficient.
'I prefer to start with BPMN in the next phase, as described in Purpose 2.' (Shelley)
By the way, from my own experience, and with all your respect, this is one of the biggest possible mistakes on a BPM project.
It's always pleasant to start describing a project using BPMN (and I'm a BPMN expert !). However, it's becoming hard to update the process using BPMN for being consistent with the moving business requirements. Quickly, the analysis phase is being sclerosed. Why ? Because updating a BPMN model requires much more time than updating a wording scenario. Business people can be involved more easily in writing a narrative scenario than a BPMN business process.
From my 10 years of BPM experience, it's almost impossible to use BPMN during the analysis phase.
Why ? Writing a business process requires to move/add tasks, add alternatives and extensions, to delete it, to add again etc ...
Trying to be agile in the analysis phase keeping the consistency with the BPMN is almost not possible in an actual project, mostly because of time constraints.
Try it using BPMN and try it using words ! Quickly, you'll understand the difficulty of maintening the BPMN model and the business process solution.
Shelley, I know you known Bruce Silver. Bruce is by far, my favorite BPMN writer. His book (which I very strongly recommand it : BPMN Method & Style) shows perfectly what naive modeling is. Using BPMN for the analysis phase (level 2) often involves the design of a naive model which can not be executable, or at least not optimized.
What is my method for leading a BPM project ?
The first step is to instantiate the business architecture (example : the OMG Motivation Model or the Togaf Business Architecture).
From the goals and objectives, how to identify process and business rules ? But this thread is not relative to this topic.
The second step is to draw use cases, actors and their relationships using a UML modeler or Visio or even Powerpoint. This part provides a high level vision of the business processes and often allows the identification of other processes.
For each UML use case relative to a business process, I write a narrative use case (using the method of Allistair Cockburn : Writting effective use cases). This is very efficient, really much more than modeling an analysis BPMN model.
Updating the BPMN process from a well written narrative use case is becoming not only easier but also more natural. However, writting good narrative use cases is probably one of the most difficult part of a project.
It's also easier to think about alternatives and extensions using a narrative use case. For helping me, I wrote an efficient Microsoft Word macro. I'm also developping a powerful Eclipse plugin for replacing this macro (not yet available).
There is another great advantage using a narrative use case. A use case is a business requirement ... that I can use as the core input of the functional testing phase. The narrative use case can be easily inserted in the requirements table of a testing tool, example : Mercury testing tools ... the BPMN model can not !
How to operate a narrative use case ?
For improving the organisation model and business rules, identifying business rules, business entities and services candidats. It's also of course the main input for the BPMN modeling.
The relation between the narrative use case and BPMN ?
I use heuritics for writing the each step of the narrative use case :
1) Each step is testable.
2) I'm able to model the step in BPMN ... if not, the step is probably not well written, and I have to re-write it !
3) Each nominal step can have alternative and extension scenarii. Once the narrative use case is approved (after having been modified, approved, disapproved, again modified, again approved etc ...), then the business requirements are now much more stable. Then, it's relativly easy to translate it into a BPMN executable model. As I said, I strongly recommand to follow the Bruce Silver advices for avoiding many traps and for optimizing the model.
'Modeling in BPMN provides a standard that can be communicated and shared.'
This was the primary goal of BPMN ...From my own experience, business people often don't want to read BPMN. For the rare people ready for that, how do you maintain the consistency between the model level 1 or 2 and the model level 3 ? In an actual project, it's almost impossible. Anyway, using the BPMN level 1 or 2 involves so many lackings that I prefer not to use it.
Using BPM at level 1 or 2 and level 3 ? (level 1 = descriptive model, level 2 = analytical model, level 3 = executable model).
BPMN is efficient for creating executable models and than, in the project lifecycle, it MUST be used at least at level 3. And, because I don't want to maintain consistency between Level 1 or 2 and Level 3, then I use only the level 3.
'Why don't I use first the model level 1, then level 2, then level 3 '
I know that I have to use the level 3. Because, I work with a method using iterative and incremental phases, I can not work on a executable model and then, cycling back on the analysis phase and submitting the model to the business people. An executable model contains events, transactions, signals, compensentions, gateways and so on that business people don't have to know. The execution of a BPMN model uses the Pi-Calculus theory. Even for BPM designers it's difficult to understand (Cf. workflowpatterns.org), than let's imagine for business people !
'Consistency between a use case and a BPMN diagram'
Of course, this consistency must be managed, but it has a lower cost than maintening consistency between the levels 1 or 2 and 3.
Summary, for a BPM project :
BPMN has to be used for the design phase, not for the analysis phase.
Steps :
1) Identify goals and objectives (then relative indicators).
2) Identify business process and business rules.
3) Draw use case diagrams showing business processes, actors and relationships.
4) Write narrative use cases.
5) Operate each narrative use case : extend business rules, identify business entities, organization model and service candidates (for SOA).
6) Create your SOA contracts (WSDL) and Schemas (XSD) which will be used in BPMN).
7) Then model the processes using BPMN. There is only ONE level of BPMN modeling : the executable level.
8) Cycle back on the previous phases.
Best regards
Frederic Fontanet (Business senior architect, OMG UML & BPM certified, also SOA and J2EE Web Services certified)
Good advice on the use on