Category Archives: Business Process Modeling

Tutorials on business process modeling notation (BPMN) or other articles related to process modeling.

Requirements for Enterprise Architecture: First Look

the hague
Traditional requirements happen after a multi-system architecture has been defined.

But what about the requirements that feed into that architecture? The requirements that drive the enterprise architecture decisions in the first place? We haven’t talked about those before.

Continue reading Requirements for Enterprise Architecture: First Look

Global Processes and Business Rules

people around a globe

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently – and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.
Continue reading Global Processes and Business Rules

Elicitation Techniques for Processes, Rules, and Requirements

hammer and egg

Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

Continue reading Elicitation Techniques for Processes, Rules, and Requirements

Use Case vs. Process Flow – Failure Handling

football fight
Should you use use cases or process flow diagrams to document business requirements? At some level, they both document the same thing, they just document it differently. The best requirements will come from doing both – but what if you are forced to choose one? What are the tradeoffs between use cases and process flows? In this article we look at the documentation of failure handling.

Documenting Failure Modes or Error Handling

Failure handling is something that software has to do. In every process or use case, there are going to be non-trivial failures or other unanticipated events. The exercise of identifying those failure modes is relatively straightforward. Deciding what to do in each situation is harder. Documenting and communicating those requirements can be harder still.

A Simple Use Case Example of Failure
Alistair Cockburn uses a simple example in Writing Effective Use Cases, to describe how to handle this situation with a use case extension. We’re paraphrasing his example here:

1. User requests to update her billing information.

2. System requests authentication of user identity.

3. User enters authentication information.

4. System authenticates user.

5. System presents billing information for editing.

6. User edits her billing information.

7. User indicates that edits are complete.

8. System updates billing information.

9. System acknowledges update of billing information.

What happens if the user authentication fails?

Cockburn suggests using a use case extension to deal with this situation. His suggestion applied to our example would read:

4a. Failed authentication

4a1. System notifies user of failed authentication and re-requests authentication.

4a2. User re-enters authentication information.

4a3. System authenticates user.

One thing you will notice is that this is a linear representation of the use case. It includes the anticipated failure condition – failed authentication.

Process Flow Example of Failure

You can create the equivalent example of the Edit Billing Information use case as a process flow.

process flow example

[larger image]

The process flow diagram provides two immediate benefits relative to the sample use case. First, by using swim-lanes, there is a visual reinforcement of the roles of the user and the system. The use case identifies the actor for each step as well – as text. Second, the decision box highlights the possibility of failure, and makes it obvious that there is a desired way to address failed user authentication. The use case shows this information, but only at the end of the prose, because of the linear structure of the text.

These benefits come from the spatial representation of the process. By laying out a diagram in two dimensions, you increase the information density of the artifact. The need for, and execution of authentication failure handling is more clear in this example.

More Complex Examples

Reviewing this simple example could lead you to conclude that there is near parity between the two documentation approaches. Consider a process with more failure modes, or even failures within failures. What if the system is required to lock out the user account after three failed authentication attempts? This is a straightforward extension to either example – but the use case form begins to get “clunky” with nesting extensions. The process flow diagram scales better to complexity.

Generalized Conditional Branching

This example can be generalized for any if…then situation.

When writing a use case, there is the often overlooked step of replacing “if…then” with “if…then…else.” It can be easy to overlook a missing branch to a decision tree. One of the goals of writing requirements is to write complete requirements. You want to avoid anything that makes it easy to write an incomplete requirement.

As a justification for making sure that you identify failure conditions and failure handling when writing use cases, Cockburn points out the completeness benefits. He says that you may even identify new actors, processes, and business rules while defining the failure handling extension of a use case step. We feel this is a weakness of the use case format, not a benefit of failure handling.

Other Factors

As with almost every element of requirements management, there are many factors to consider. Process flows are not universally better than use cases, or vice versa. This article focuses only on the need to deal with conditional branching.

For communicating the requirements associated with conditional branching in a process, a process flow diagram is better than a use case.

2007 – The Year of the Business Analyst


Outsourcing is gaining momentum not only as a way to reduce costs, but as a way to create global teams. This trend is driving an increase in demand for business analysts. The change in perspective is driving companies to think about how they manage their business in new ways, and driving interest in new tools for business analysts to achieve these goals.

Hat tip to Ryan for his article on the year of the BA. The source that Ryan found is this yahoo article on 7 trends for 2007.


The role of the business analyst has emerged as a focal point for enterprises trying to wring more out of their automation-technology investments.[…] Ironically, outsourcing is feeding a frenzy to bring aboard more analysts. The experience of outsourcing IT has taught firms their technology-project specifications were in much worse shape than they believed. When companies would deliver specs to outside firms and individuals who didn’t have deep experience with their existing automation solutions, the knowledge gaps became painfully apparent.

Neal McWhorter, in the Yahoo article (emphasis ours)

We’ve all talked about outsourcing, and many of us have designed teams with different collaboration models to address the communication challenges.

This Computerworld article suggests that business analysts are one of 5 top areas for hiring, and business process management is one of 5 top technologies being explored.

How Business Analysts Adapt

Neal suggests that BAs will evolve their role and responsibilities to be something analogous to a product manager. We’ve been treating the roles similarly here – with the primary distinction being a single-customer focus for business analysts.

Neal mentions the IIBA and their new certification program as a likely means of setting expectations of and for business analysts. Barbara writes about the upcoming certification schedule for 2007.


We can’t overemphasize the need to be good at writing requirements first, and then using tools to become more efficient second. With that said, the increasing importance of business analysts drives the increasing importance of helping BAs be more effective.

Two areas where there are huge opportunities for improvement are business process modeling and requirements gathering/management.


There are tools and vendors for BPMN solutions, and it looks like training is finally going to be more available in 2007. Bruce Silver is developing training that uses ITP Commerce as a tool provider. We’re currently designing a training course as well, built by extending the tutorial series we wrote last year, using visio stencils and a vendor-agnostic approach.

Requirements Management Software

Today, the space can be characterized as having the following solutions available:

  • Spend a lot on an enterprise package, and mandate that all your projects use it, in order to recover the costs.
  • Build your own solution, using spreadsheets, documents, email and other tools.

We expect this to change in 2007 too. Both of the approaches above can be cost ineffective for single-projects within a large company, SMBs looking to become more effective, and small consulting shops providing services to other firms. There’s a lot of opportunity here for the right solution.


Is it the year of the business analyst? The need is indisputable. Will the C-level execs act on it?

Business Rules And Requirements

No parking sign

What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

A Simple Example

We’ll set the stage for discussion by showing a requirement, a rule, and a design and implementation.

  • Requirement – The building will provide a measure of protection against fire damage.
  • Rule – Firefighters will be assured access to the building to enable extinguishing of any fires.
  • Design – The street near the fire hydrant and main entry of the building will be reserved for exclusive use of firefighters.
  • Implementation – A sign will be posted in a visible location, instructing people not to park in the reserved location.


The debate about requirements versus design, and the level of detail of specification has been an active one over the past year. We’ve written about how you can imagine software as an onion, where implementation is wrapped in design, which is wrapped in requirements. When we include awareness of business processes as part of what we’re doing, we can add another layer – business rules.

One point of confusion may be that many contracts are described as “gather requirements” when in reality, the work is “define rules appropriate to a set of predefined requirements.” This inconsistency leads to many debates that include arguments like “that isn’t a requirement, therefore it must be design” with the response of “that isn’t design.”


Moving from each layer to the next involves ideation, and exhibits concreteness. For a given requirement, an approach can be defined for meeting that goal, and with that approach comes rules. For each rule, a design can be selected, and for each design, an implementation is created.

Each step involves ideation – making inventive choices about how to achieve that next step. Consider our example. We have the requirement of providing protection against fire damage. We could choose to achieve this requirement by mandating that only non-flammable materials be used in the construction of the building, or by integrating fire suppression equipment in the building, or by optimizing the access for firefighters to the building. Once we make that choice – an ideation step – we define the rules that express how we will achieve our goal with the selected approach. Our rule is assured access in this example. The design approach is to reserve the street near the main entry to the building. The implementation of this “reservation” is a sign. It could be special barricades that block access to anyone who isn’t a firefighter.

The point is that there are choices at each step of the way.

Each step becomes more concrete, more focused, and more narrowly applicable.

Product Managers Are Market-Centric

As a product manager, when interacting with customers to better define the needs of the market, we need to recognize that the rules are not the requirements. In the example, access for firefighters isn’t the requirement, protection against fire damage is the requirement. This is the level of abstraction that can be used to describe market needs.

Business Analysts Are Customer-Centric

A business analyst needs to understand the requirement (protection), but only in so much as it affects her company. This allows her to explore alternative rules (access, suppression, prevention, etc.) that will achieve the requirement.

Requirements Elicitation Can Fall Short
When we interview people to gather requirements, they will usually talk about implementation, design, and rules. Rarely will they describe requirements. Users and subject matter experts (SMEs) generally talk about implementation and design (“We have a sign, because the street needs to be reserved.”). Our elicitation techniques and listening methods help us identify rules by asking Why? (“To assure access to the building for the firefighters.”). Without those techniques, we will only uncover implementation and design.

Getting to Requirements From Rules

To get to the requirements, we need to keep asking why. (“To provide protection against fire damage.”) If we keep asking “Why?” we will eventually get to a useless “primary goal.” And by useless, we mean that it is a goal that is too nebulous to drive anything actionable. Consider these possible chains of why questions and answers for our example:

  • Why provide protection against fire damage? To allow us to meet city codes. Why does that matter? So that we can legally rent out space in the building. Why does that matter? Because we need to rent the space to make a profit. Why does that matter? Because our shareholders demand it.
  • Why provide protection against fire damage? To allow us to charge higher rent to tenants. Why does that matter? Because we need to maximize our profits. Why? Shareholders.

Part of the art of product management is knowing when to stop. “Protection” is actionable. “Satisfying shareholders” and “Profit”, while laudable goals, do not provide the needed direction and detail to be actionable.


The line between requirements and design is broad, and is more of a region than a line. Rules live in that region – from one perspective they embody a design approach to achieving a requirement. From the other perspective, they represent the business requirement, in more detail. Use elicitation techniques and ask why to uncover the rules and requirements.

Free BPMN Stencils for Visio 2003 and Visio 2002

bpmn template screenshot

In support of our series of BPMN Tutorial posts, we’ve created a series of Visio 2003 stencils (*.vss) and a template (BPMN_Template.vst) of BPMN symbols. Anthony Britton has created a Visio 2002 version of the free stencils – thanks Anthony!

Download this free resource today courtesy of Tyner Blain!

Continue reading Free BPMN Stencils for Visio 2003 and Visio 2002

Cost Reduction Potential

roulette wheel

All process improvements are not created equal. How should we select which processes (or process steps) to improve? How do we approach this for a really large migration project? Start with understanding the potential for improvement and then narrow it down from there.

The Basic Concept

When re-engineering a business process, ultimately we want to maximize the ROI of our improvements. That means understanding the costs of today’s process, the costs of tomorrow’s process, and the costs of creating and transitioning to the new process. On a large project, this can be a herculean task. We don’t have enough time to do all the math. We don’t want to get paralyzed with analysis activities. Where should we start?

We should start with the processes that have the highest potential for improvement. Since profit can be simplified to a simple equation of savings minus deployment costs, we should start by finding the processes (or process steps) with the highest initial costs (and therefore the highest potential savings).

A Simplification

To simplify the presentation of this idea, we will ignore probabilistic costs (risks, errors, modeling) – not because they aren’t relevant, but because the cloud the issue. Imagine for the rest of this article that the only costs in a process are operating costs. The same approach can be extended and refined to include other very real costs.

We will also use an example that depicts process steps – it could easily depict processes. The only difference is the level of detail. On really large projects, use this technique to identify high potential processes, then drill down into them to identify high potential process steps.


To calculate potential, we calculate the costs of existing process steps. Consider the following simple (existing) process:

simple process

The process has five steps, A through E. Step B is a decision, meaning that some times we execute step C, and other times we execute steps D and E.

We want to know which step of the process to focus on improving – so we have to identify the step with the greatest potential for savings.

There is a simple formula for defining the cost of any step in the process.

Frequency x Effort x Burden x Period

  • Frequency (number of occurences per unit of time)
  • Effort (units of time spent in the task)
  • Burden (money per unit of time)
  • Period (unit of time for the analysis)

We can represent this with a simple template of a spreadsheet.


Sample Data

By creating sample data for each input, and calculating the cost, we can compare the potential for each step in the process.

sample data

If we were to ignore frequency information, then step C would appear to have the most potential, because it has the highest “per occurence-cost (with an effort of 5 hrs at $20 / hr). However, by recognizing that step C is only executed 10% of the time, we see that the cost of step D is actually the highest (at $36,000 per year).

real data


Our interpretation is that step D has the greatest potential for savings, because it has the highest cost. Steps A and E come are next, followed by step C. Step B is so cheap that it isn’t likely to be worth evaluating.

Next Step

The next step is to propose a replacement for the highest potential step (D). Alternately, we may look for a way to combine steps D and E with a single replacement (as mentioned in this article about process improvement). After exploring this solution approach, we would look at steps A and E as candidates for replacement. Estimating the costs of replacing these steps is the next thing we do. The costs of performing the steps today, minus the costs of performing the new steps in the future (plus the development and transition costs) determine if we should consider this as a step for replacement.

We will only consider those steps where the profitability of change exceeds our hurdle rate for investment.

Once we have profit data for each proposed step change, we can prioritize these changes, and then schedule them in conjunction with the skills of our development team.

Strategic Change Loophole

Executives like loopholes. Perhaps because their accountants find so many for them. We have a loophole here too – a process step may need to get replaced because of internal office politics, or for “strategic” reasons. We need to make sure our stakeholders have a way to include financially excluded choices.


Identify the most expensive processes to run. Determine ways to replace them. Calculate ROI and use it to drive prioritization.

Process 2006 – Day 1 by Sandy Kemsley

Sandy Kemsley, of Column 2 fame, is blogging the Process 2006 convention “live” as it goes. Subscribe to her blog to stay on top of things. For now, here are the articles she’s posted from day 1.

Some choice quotes from Sandy’s posts:

“One thing that I really liked was his analogy about BPM: buying MS-Word doesn’t make you a novelist, and buying a BPMS doesn’t make you a process-oriented company.The technology is an important enabler, but there’s much more to it than that.”

“[OMG, we just hit a slide with 249 words — the print is getting smaller and smaller. Keith, you’re killing me!]”

“This is definitely the first presentation that I have ever seen, anywhere, that quotes Winnie the Pooh, and gives an example of strategic objectives as illustrated by Christopher Robin and Edward Bear. By the time he got to his main case study, which was the hospital administration process around having a vasectomy, I was wishing that he had been my prof at university.”

“Surprisingly, he then went on to talk about the emotional aspect of decision-making as it relates to customer centricity: how some decisions are almost purely emotional (like buying a convertible or having plastic surgery) and the financial practicalities of those decisions become less important. Not the argument that I expected from a reason-driven German banking COO, but he posits that being a customer-centric organization is understanding the balance between reason and emotion.”

I won’t tell you which quotes are from what articles – you’ll just have to check them out to find out more about the stuff you like. :)

Thanks Sandy for the blow-by-blow.