 |
 |
From BPMN.org: “A standard Business Process Modeling Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner". |
|
| With that simple admonition, enterprises can merrily design and deploy their BPM initiatives, assured of mutual understanding between everyone involved on both the technology and business sides, correct? |
 |
From BPMN.org: “A standard Business Process Modeling Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner.”
With that simple admonition, enterprises can merrily design and deploy their BPM initiatives, assured of mutual understanding between everyone involved on both the technology and business sides, correct? This being the real world, things aren’t quite that simple or rosy, but BPMN continues to make strides since its origin as Business Process Management Language within the Business Process Management Initiative a few years back.
Today, there are more than 40 BPMN implementations. Although, as BPM analyst Bruce Silver notes, BPMN “is not perfect…and nobody really loves it,” Silver also points out that “most agree it’s the closest thing we have today in the BPM world to a real multivendor, architecture-neutral standard, and the one standard that addresses the biggest issue in BPM today, which is true business-IT collaboration.”
Note that Silver states BPMN is “the closest thing we have” to an architecture-neutral standard; since BPMN effectively demands that the orchestration engine can respond to events in some fashion, it does favor those vendors whose products offer this capability.
BPMN also has some well-known limitations. It doesn’t describe organizational structures and resources. (Although the view is that that would be covered by a separate specification from the Object Management Group.) It doesn't define the data model for the process itself. It doesn't describe business rules.
And the notation doesn't include a specification for persisting the process definition itself. Although there are a number of initiatives which satisfy that requirement (including XDPL and the emerging Businesss Process Definition Metamodel), BPMN itself is not a data flow diagram.
|
| |
All that said, since BPMN really is targeted at describing a business process, in contrast to other modeling notations that have a wider scope. BPMN is very specific and germane to business process management.
Sandy Kemsley, an independent BPM architect and blogger (www.column2.com) specializing in BPM design, enterprise architecture and business intelligence, recently led a webinar on the topic of BPMN. She provided a number of key (and really cool) insights into the wondrous world of Business Process Management Notation.
“The thing about having a standard format for drawing process maps is that it gives you a way to communicate those processes between people--so now it’s a format that’s understandable by business users because it looks kind of like a flowchart,” she noted. “So you don’t need a lot of training in order to understand how to use it. BPMN is understandable by anybody who might be involved in the process, so both the business users and IT will be able to look at this and have a common and unambiguous view of what the process does.”
Kemsley believes that this capability “reduces translation errors between business and IT, because they have a common understanding of the process, and also because pretty much any modeling environment that supports BPMN will also support some sort of standard interchange format or file format like XPDL.”
Looking beyond the basic technical issues, Kensley urges business-side and IT-side executives to focus on the enterprise, or dare we say Enterprise 2.0? She references some work from the early 90s by business Babson College technology visionary Tom Davenport, who has written extensively about process innovation over the years. “I love to use (a) reference (from Davenport’s 1992 book about process innovation), looking at ways in which you can improve your process,” Kemsley says. “This isn’t about the technology. This is just the different ways in which you look at your processes for improving them.”
Kemsley notes the nine different areas in which Davenport has stated that process innovation can occur. (This list comprises automational, informational, sequential, tracking, analytical, geographical, integrative, intellectual, and disintermediating.) Within this group, Kemsley likes to focus on what she calls “the big three.”
According to Kemsley, “the places where you can get the most bang for your buck” are:
- Automational, “so you’re looking at improving process efficiency through automating
processes”
- Geographical, “so that a process can be done in several different locations. This
includes things like outsourcing parts of your process”
- Disintermediating, “(i.e.), cutting the middle man out of the process so things like
customer self-service.”
In the end, Kemsley notes that “we’re looking at (things) from an ROI standpoint. There are two major things--the first is about reducing costs and the second one is about increasing competitive advantage.”
All this high-level insight flows from the relatively simple notion of inculcating BPMN as a way to for organizations to get a grip on their BPM initiatives, in a spirit of mutual understanding and cooperation among IT-side and business-side executives.
To view the entire webinar featuring Sandra Kemsley, go to [www.tibco.com/xxx]
Tom Davenport’s work can be found, naturally, at www.tomdavenport.com |
 |
| |
| |
 |
|
 |
|
 |
|
|
