Archive for March, 2007
I’m in the process of updating my 2006 BPMS Report series on BPMInstitute.org to the new and improved 2007 version. A major change from last year is a beefed-up evaluation scoring. I’ve discovered that many users (and most vendors) are happy to skip the 25-page walkthrough of the product and go straight to the scorecard at the end. Which product “won”? I haven’t figured out the presentation - it will probably be some 2-dimensional thing like the Forrester Wave or Gartner MQ - but I’m close to having a finished scoring methodology. It’s probably asking for trouble, but I’m publishing it right here so that you can comment upon it.
The basic plan is this. I define 4 process types: Task Routing (basic workflow), Production Workflow, Case Management (emphasizes content, collaboration, and unstructured processes), and Integration-Centric. The characteristics of each type are explained in the report overview, but most of you can imagine what they are. Each BPMS is scored against all 4 process types using 12 sets of criteria, but the weightings of each set may differ from one process type to the next. Also, the capabilities affecting the individual criteria may be process type-specific.
Here are the 12 sets of criteria, things I’m looking for in each (some are process type-specific), and the percentage weighting of the set for each process type:
1. Architecture and Environment (Weightings: task routing 10%, production workflow 10%, case management 8%, integration-centric 10%)
· Unified environment for workflow, integration, rules, BAM
· Minimal programming required
· Scalable
· Clustering, hi availability
· Leverage J2EE or equiv platform services
· Web-hostable/SaaS-compatible runtime
· Support for standards
· RAD/iterative support
· Component discovery and reuse
2. Modeling (Weightings: task routing 10%, production workflow 10%, case management 4%, integration-centric 5%)
· Usable by business process analysts (not developers)
· Support for BPMN (full support)
· Integration of BPA (ARIS, ProForma, MEGA, etc)
· Stay in sync w/design (shared or roundtripping)
· KPI modeling
· Model repository, publishing
· Support for industry models (SCOR, ITIL, etc)
· Team collaboration
· Simulation
3. Human Workflow (design) (Weightings: task routing 10%, production workflow 10%, case management 8%, integration-centric 5%)
· Dynamic task assignment
· Flexible routing
· Form design
· Screenflow design
· Worklist design (columns for business data)
· Internationalization support
4. User Experience (runtime) (Weightings: task routing 15%, production workflow 7%, case management 13%, integration-centric 5%)
· Ajax web forms
· Offline task participation
· Guided task performance
· Portal design and integration
· Reassign/delegate task
· Production workflow support (getNext item)
· User sort/filter/query worklist
· Instance status tracking
5. Content/Collaboration/Case Management (Weightings: task routing 10%, production workflow 7%, case management 13%, integration-centric 5%)
· OOTB attachment support in task UI
· Doc upload, annotate, edit
· Viewers
· Checkin checkout, versioning
· Integ with 3d party ECM
· Archiving
· Retention mgmt
· Team room support
· Discussion, chat, presence detect
· Process knowledge repository
· Case mgmt support
6. Business Rule Management (Weightings: task routing 5%, production workflow 7%, case management 8%, integration-centric 10%)
· Rule repository
· Rule design
· Rule maintenance app
· Rule change impact analysis
· Rule engine
· Rule-process integration
7. Integration (Weightings: task routing 5%, production workflow 7%, case management 8%, integration-centric 10%)
· Adapters – Introspectng/self-generating; packaged - Mainframe, pkg app, b2b, .Net etc
· Async integration, callback, reliable messaging, WS-Addressing, security etc
· Data transformation mapping, XSLT/XQuery engine
· ESB, mediation
· Registry/repository
· Metadata library
· B2B support – trading partner gateway, EDI
8. Events and Exceptions (Weightings: task routing 5%, production workflow 6%, case management 13%, integration-centric 10%)
· Event listeners and adapters
· Full bpmn event support
· Wait for event
· Interrupt by event + exception flow
· Manual suspend/resume instance
· Error propagation, handling without programming
· BAM events and actions
· Transaction rollback and compensation
9. Performance Mgmt/BAM (Weightings: task routing 5%, production workflow 10%, case management 4%, integration-centric 10%)
· Metrics and kpis – OOTB and User-defined
· Dashboard design - Charts, reports, alerts and notifications
· OLAP-style breakdowns
· Bam rules and actions
· Drilldown to root cause
· Instance monitoring
· Optimization actions
· Predictive analytics, e.g. expected finish
10. Governance (Weightings: task routing 5%, production workflow 10%, case management 4%, integration-centric 10%)
· Enterprise repository of models and components
· Link processes to goals and KPIs
· Role based access control and authorization
· Version control of model and implementation components
· Change request, approval, and implementation workflows
· Audit trail on component changes
· Change impact analysis
11. Solutions and Services (Weightings: task routing 5%, production workflow 6%, case management 4%, integration-centric 10%)
· Industry solutions – documented, QA’ed, supported
· Partner industry solutions
· Professional services
12. Installed/reference customers (Weightings: task routing 15%, production workflow 10%, case management 13%, integration-centric 10%)
· Task routing implementations
· Production workflow implementations (volume, industry)
· Case management implementations
· Integration-centric implementations (volume, industry)
Products will be scored in each of the 12 categories from 0-5, as in the Forrester Wave, based on the bullets listed here (as amended); in some cases the scoring will be process type-specific. Then these scores will be weighted as shown here (or as amended) for each category. One or more categories may be split off to form the second axis of the final result, as Gartner and Forrester both do in theirs.
So there you have it. If you see something missing or improperly weighted here, please let me know, either by comment or by private email.
March 27th, 2007
BPMS Watch is now one year old. While my posting schedule remains erratic, readership keeps growing (see Feedburner chart below). Feed readership is up 200% in 6 months and direct pageviews are up 40%, now 35K per month, plus syndication on several other sites. The Technorati ranking peaked several months ago around 60,000, and has since dropped to around 94,000. Since that’s based on trackbacks from other blogs, I attribute the drop to the declining state of BPM blogging in general — the conversation was considerably more vigorous a year ago than today, even though readership is rising. But it’s still fun, so we’ll keep it going.
March 27th, 2007
Just received a note from Phil Gilbert of Lombardi, a key contributor to the BPDM effort in OMG, that says:
[I] wanted to let you know that the OMG Architecture Board voted to approve the BPDM spec today. There are actually 2 more small hurdles instead of 1 more as I told you earlier. But these are 99.9% certain to approve specs that have passed the Architecture Board review. Apparently these take several weeks calendar time as the boards that approve aren’t on the TC calendar, they have their own.
In any event, it appears that a major milestone for the industry has been passed: a specification for a business process metamodel (as opposed to UML-defined process) is poised to achieve standards status and have the backing (and implementation) of process platform and modeling vendors. This will insure a standards-based way in which BPMN models can be exchanged, and both standards are driven by the same organization, allowing for unprecedented alignment. In fact, at this meeting, the next major version of BPMN is being discussed and it is expected that the focus will be on using that effort to merge the BPMN and BPDM specs, so that there will be one modeling spec, and that spec will have it’s explicit notation and its explicit metamodel.
The first step was to define the notation, and now we’ve defined the metamodel.
I think end-user companies are the winners today. There is now clarity around the implementation of process at the business level, and that clarity is in the form of business-based process notions, not IT- and systems-based notions of process.
This message was an update amplifying a previous one that announced BPDM approval by the Domain Task Force:
… this morning in San Diego at the OMG Technical Meeting, the Domain Task Force voted FOR approval of BPDM! This is the second major hurdle of any spec. The first is the RFP which kicks off the submission team… that was done long ago for BPDM. The second is the DTF vote (which occurred today). The third is the review and vote by the Architecture Board, which will happen Friday of this week. Then the OMG Board ratifies the AB decision within the next 30 days or so.
While it is rare, the AB can reject or send back a spec for more work, but in general the vote of the DTF is the more difficult barrier because of the diversity of companies (and interests). The AB is more focused on the technical implementation of the specification and less concerned with the business issues that may be reflected in the votes of all the member companies.
Phil also replied to my questions with some answers from Lombardi and MEGA representatives on the BPDM submission team:
Q. How would you create serialized BPMN from BPDM?
A. We are updating the EMF plugins. This will allow creation of BPDM models using Java. Additionally there will be a very basic editor (not usable by business people) that will allow a developer to create BPDM models and to look at the produced xml. The goal is to have these plugins updated for Monday 26 March. This will also be discussed on Sunday by the submission team. Most likely we’ll do a presentation about the serialization of BPMN using BPDM and we’ll show the actual XML that is produced.
Q. Could xsd be derived from this xmi document?
A. Yes. EMF provides such capability. XSD most likely will not be part of the submission, but a separate document that will be distributed freely.
Q. Do you expect OMG to provide one?
A. Yes. During the meeting we will create and distribute the XSD.
Q. Can standard xml validation be used?
A. Yes. Using the provided XSD.
Q. Can I use XSLT [to transform and validate models]?
A. Yes. However XSLT is not very suitable for performing model transformations. For object models there are better languages that can transform models. One such example is QVT. On the Eclipse.org you can find other languages also.
Q. Is there some example that can be used to understand BPDM?
A. We are working on an example that demonstrates BPDM features. This is incorporated in the html documentation that is generated. Most likely it will need additional explanations, to be provided after the approvals
March 26th, 2007
My comment on Keith Swenson’s XPDL-BPEL apples-and-oranges post and the failure of XPDL to fill the vacuum left by OMG in the BPMN specification stirred up an interesting response from Keith that reinvigorates the discussion and helps clear the air. But he still frames the discussion in terms of portability of executable designs rather than portability of models (i.e. abstracted from implementation details). In the XPDL vs BPEL discussion, this is appropriate, but in the discussion of BPMN portability it misses a fundamental point.
He says:
Bruce has criticized XPDL for inability to take an executable process from one vendor product, and bring it to another vendor product, and guarantee is it understood. He is right. There is no guarantee that a process drawn in one product, saved in XPDL, will be immediately executable in another product. This is not because XPDL fails to capture the semantics, but instead a failure to (1) be able to unambiguously capture those semantics in standard BPMN, as well as (2) a failure of the receiving tool to understand the same semantics that the sending tool transmitted.
In the first sentence above, replace “an executable process” with “a process model.” And there you have the essential problem, because I would say BPMN is able to capture the semantics adequately, but BPMN tools simply do not adhere to the spec, and users don’t know how to create diagrams correctly. The tool vendors’ own sample diagrams violate the spec time after time, something I’ve blogged about repeatedly in the past, and — more important — the tools (the ones I’ve looked at, at least) do not adequately validate the diagrams against the rules defined in the spec.
In trying to prove his point that the semantics required for model portability are missing from BPMN diagrams, Keith unwittingly proves mine instead, that the problem is diagrams often violate the spec and the tools don’t seem to care. He says:
Lets say there was a product called “Vulcan Mind-Meld” which used BPMN to express the diagrams that have meaning to this product. BPMN defines what each of the symbols mean, but the real meaning, the real semantics comes from the way that the symbols are composed together. Mind-Meld would guide you as you draw this diagram, making sure that you do not put anything together in a way that is nonsensical. The author of this diagram is making an expression that has meaning in Mind-Meld. Here is a possible diagram which is consistent with the BPMN specification:
Now, imagine the Vulcans had followed BPMN best practices and applied user-meaningul labels to the various activities, sequence flows, gateways, and events, so it would be clearer the conditions under which the process followed one path versus another. (In BPMN modeling it is actually these labels, not the attributes — those are mostly for BPEL generation — that clarify the process semantics.) That would go a long way toward clarifying what those Vulcans had in their melded minds. To the extent it’s still unclear, it’s because this diagram, which even a guy as smart as Keith says is perfectly good BPMN, contains at least 3 errors.
1. You have 2 sequence flows coming into Casino from potentially concurrent paths. You need an OR-merge there, or else you potentially have 2 tokens going through the Casino activity for one process instance. Not absolutely forbidden by BPMN, but best practice to avoid this. It will break virtually any simulation engine or process engine, and probably not what the user had in mind.
2. Casino, having no sequence flow out, is what the spec calls an end activity. If start events are used in the diagram (they are here), an end activity must have a sequence flow to an end event.
3. Casino has a Compensation intermediate event with a sequence flow coming out of it. That’s invalid. A Compensation intermediate event has an association to a single compensation activity, not a sequence flow.
If I can spot these things easily, why didn’t Keith’s BPMN tool?
For the past few weeks I have been grading exercises submitted by students in my Process Modeling with BPMN training. My decision to include hands-on with a tool and exercises submitted for grading turned out to be a good one — students say the exercises really drive home how to use BPMN in a way that the lecture material simply can’t. And what I’ve learned from the grading is that students frequently make diagram errors that could, in principle, be caught by a BPMN validator. The tool I use, Process Modeler for Visio from itp commerce, has a modest amount of BPMN validation - just enough to make sure the simulation engine can follow the process — and a stricter validation (overly so I think) of diagrams with BPEL export, reflecting more the constraints of BPEL’s block orientation than anything about BPMN. But almost all the errors I find are allowed by the tool. If I can see them, surely a validation routine should be able to spot them as well. This would change the nature of my training, perhaps, but… that’s another subject.
Finally we get to the real reason for this post, which is the long-awaited BPDM — the official metamodel for BPMN from OMG. You can see it, if you want to, at modeldriven.org. I was looking for a schema, but instead it’s this funky XMI thing. It’s not even schema-valid XMI (that’s ironic, isn’t it?). It fails XMI import as published on modeldriven.org, but if you patch it up with the right root elements — thanks to Marlon Dumas for doing that — you can at least import it into a UML tool. Yes that’s right, UML. The schemas that Marlon was able to generate don’t shed much light on what the structure of a BPMN serialization would look like, and that bugged me last week.
But I think Keith’s post here crystalized the thing that is really bothering me. It’s not portability of models between tools. I suppose whether they have to use Eclipse or whatever, the tool vendors will figure out that piece. What I realize I was actually looking for in BPDM was a more precise statement of the rules of BPMN, so they could be reflected in tool-based validation. I had the feeling that those rules were somehow buried in the XMI, which I can’t decode, unlike schema, which I can. But on further consideration, I see that it’s highly unlikely that a schema could possibly represent all the rules, such as if you have this kind of flow object over here, that constrains what is allowed for this other flow object over there. Of course, if you had a schema you could write XSLT that would do the validation based on rules extracted from the narrative of the metamodel. But that’s a story for another day.
March 26th, 2007
Keith Swenson is one of the true superheroes of BPM, and a pioneer in the development of interoperability standards. Known for his stalwart defense of XPDL, he periodically feels called upon to insist that XPDL does not compete with BPEL… then usually adding that XPDL is actually better. But I’ve always felt that Keith obscures the real difference between XPDL and BPEL and their relationships to the “real” BPM standard, which is BPMN.
The latest fracas started a couple days ago when Keith claimed victory in the non-war from the fact that 8 of the 12 vendors in the top 3 quadrants of the Gartner MQ support XPDL. Even though a number of those vendors also support BPEL, at least as an interchange format for automated fragments of the process, it is fair to say that vendor support for XPDL is probably more widespread than vendor support for BPEL. So let’s stipulate that, no problem.
An anonymous commenter to that post said, paraphrasing, “Yeah I work for one of those vendors on your list, and for us XPDL is a checkoff item and actually BPEL is more important as a standard.” Well, that fried one of Keith’s circuit boards and led to yesterday’s apples-and-oranges post, where he once again tries to explain why XPDL is orthogonal to BPEL (but still sort of better).
It’s true that XPDL and BPEL do different things, and Keith does describe the essential difference, but he couches it in language that slants the implications to users. His example is a reasonable one, a BPMN diagram of a simple split and join. Keith describes the BPEL representation, which conveys the process semantics of the concurrency and join, as “lossy” and “one-way” because it does not capture — as XPDL does — the precise shapes of the BPMN activities, gateways, and events, the bends in the arrows, etc.
In other words, XPDL captures the diagram, while BPEL captures the process semantics. Keith dismisses the latter as just the information an “execution engine” would need to know. Technically that’s true of BPEL, I suppose. But which of these best represents the process model? The part that Keith glosses over is a process diagram is not the same as a process model. The argument over whether BPEL or XPDL is more “portable” is based on different interpretations of what portable means. If you mean the same process semantics can be executed on two different engines, then BPEL is more portable. If you mean that the same diagram can be created in two different tools, then XPDL — especially if you allow the target tool to ignore the graphical details that don’t carry over.
Which aspect of portability is more valuable? It depends on what you’re trying to do. If you’re just trying to glue together tool A and tool B, XPDL has more flexibility. The freedom to ignore the parts that don’t map exactly is implicit. Of course, you would need a side agreement between vendor A and vendor B to make the thing work, but let’s not talk about such details.
With BPEL you don’t have the freedom to ignore elements you don’t support. BPEL is BPEL and you have to support everything in the spec. The rest are called proprietary extensions. They live in their own namespaces, and a valid criticism of BPEL 1.1 is that real processes need too many of them. It’s a bit better in BPEL 2.0, but human tasks, subprocesses, and other basics still require extensions in 2.0, such as the nearly mythical BPEL4People.
So let’s get to the real question. BPMN is a modeling notation — more than just a diagram, since each element has defined process semantics, abstracted from implementation details — but BPMN has no official XML schema, i.e. no interchange format. XPDL 2.0 was explicitly created to capture all the elements of BPMN 1.0 for interchange, but — here’s the part that Keith omits — from a diagram portability perspective, not a model portability perspective. That’s because OMG (actually this dates back to BPMI) never defined which BPMN elements and attributes, and their associated process semantics, have to be supported by a “compliant” tool. Intermediate events? Compensation? Workflow engines traditionally didn’t support those, so they are conveniently left out of BPMN tools from many vendors. I’m not sure what they do when they import XPDL that has such elements. Maybe drop them on the floor, with apologies.
My view is that preserving BPMN shapes, colors, and line bends, while ignoring process semantics that don’t fit in the other tool, is not a particularly useful accomplishment. Each tool usually has its own graphical representation of model elements, anyway, so I can’t imagine the graphical details are really preserved in reality.
Bottom line is that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models — not diagrams, models — that is independent of implementation architecture. OMG is supposedly developing that based on BPDM, its formal metamodel for BPMN, now nearing finalization. I said last spring at OMG Think Tank that in BPDM’s absence, XPDL had a window of opportunity to become the de facto serialization standard for BPMN. But by focusing on diagrams not models, and positioning itself versus BPEL not BPDM, XPDL has let that window close. They might argue that adding BPMN compliance rules and semantics to XPDL is not their job but OMG’s. But that was in fact the opportunity, soon to disappear.
Here’s the puzzling part. I’ve actually seen a draft of BPDM, and looked there without success for any sign of a BPMN schema. Actually I found the thing near-incomprehensible; there was something about MOF and XMI but not a schema. It made me wonder whether BPDM would actually include a schema for BPMN, or just some kind of production rules that ensure conformance to the BPDM metamodel. If you know the answer to this question, please comment to this post. If OMG does not publish a BPMN schema, I see more consternation in BPM-Land and a second chance for XPDL to get it right. If BPDM produces a schema and a list of must-support BPMN semantics, then I predict next year Keith will forget about BPEL. He’ll be writing about why XPDL is different from BPMN… but sort of better.
March 21st, 2007
| BPMS Watch invites you to join me at BPMInstitute.org’s Business Process Management Conference, April 10-11 at The Drake Hotel in Chicago.
As part of my participation in the event, I have secured a limited number of Complimentary 1-Day Conference Passes (a $995 value) for BPMS Watch readers. (Note: this is for the conference events, not the BPMN training, and there is some fine print to note at the bottom… but a great deal nonetheless.)
If you are looking to expand your understanding of Business Process Management and engage in a dialogue of how to implement a Business Process Management strategy within your organization - join me in Chicago.
Request your Guest Pass by entering Priority Code BSACHE.
The Business Process Management Conference is one of five dedicated events taking place at BrainStorm Chicago and your registration includes access to all five:
- Business Process Management Conference
- Service-Oriented Architecture Conference
- Business Architecture Conference
- Business Rules Symposium
- Organizational Performance Symposium
Agenda-at-a-Glance
In addition, BrainStorm Chicago also features:
- Process Innovation Workshops for leveraging BPM, BR & SOA including (April 9):
- Collaborative Manufacturing
- Nimble Banking
- Personalized Insurance
- Succeeding at Business Process Management
Conference Brochure
- BPMInstitute.org’s Certificate of Training Programs and Individual Training Courses (April 9-12)
Training Brochure
| special rates available until march 23 |
As part of my participation, I have secured the following discounted rates for you to attend - they are available until March 23 and based upon availability:
| 1-Day Conference Package |
Complimentary* (a $995 value) |
| 2-Day Conference Package |
$495* (a $1,395 value) |
| Individual Training Courses |
$595 (a $100 savings) |
| Workshops |
$149 (a $50 savings) |
Request a 1-Day Pass and the discounted rates above by entering
Priority Code BSACHE when registering
*These offers are for end-user practitioner organizations only. Solution Providers, Consultants, etc. are ineligible but may register for the $2,500 non-sponsor Solution Provider package. Companies interested in sponsoring should contact sponsor@bpminstitute.org. This offer may not be combined with any other offers. We reserve the right to make the final determination on eligibility. This offer is for new registration only - no refunds will be given. |
|
|
 |
premier media partner |
|
 |
|
|
| |
March 13th, 2007
Sandy calls attention to an excellent review of BPEL’s history and current status from Oracle’s Dave Shaffer and Manoj Das in (ironically) WebSphere Journal. Probably the best summary of the differences between the new BPEL 2.0 and the little-lamented BPEL 1.1 standard that I’ve seen yet in print. She also notes the seeming fakeness of BPEL4People, a joint SAP-IBM white paper that appeared 18 months ago that has achieved what I agree is the highest buzz-to-bang ratio in the history of BPM.
My sources tell me that IBM and SAP have been meeting actively to put forth a BPEL4People spec later this spring, an activity that for some reason the companies’ lawyers have shrouded in secrecy. If you recall my original post on this topic, the essence of the BPEL4People white paper is a new BPEL People activity that allows human task management to be integrated more directly with the BPEL logic than is possible with standard Invoke and an external task management service. That means BPEL4People “breaks” BPEL 2.0 engines, except for those with the foresight to implement the People activity. What, you don’t have the specs for that? Oh, that’s right…
What Sandy also doesn’t mention is Devesh Sharma’s claim at ARIS Process World that Oracle has submitted its own approach — standard Invoke plus the external task management service, i.e. compatible with BPEL 2.0 engines — to the BPEL4People “process” at OASIS. If that’s so, it should make for an interesting meeting when IBM and SAP unveil their baby.
Sandy also notes (where does she find the time to read all this stuff?) Dave Chappell’s comments on Microsoft’s token support for BPEL in Windows Workflow Foundation as a “political” expediency. However, she fails to remark on Dave’s real contribution to this discussion, which is that BPMN — not BPEL — will be the real portability standard for BPM. I have come to that conclusion myself, but Dave (as usual) beat me to it by 6 months or so.
And then she kind of ruins it by passing on without comment Burton Group’s conclusion that “BPEL is just a placeholder for WS-CDL until that choreography standard is ready for prime time.” So idiotic I can’t even bring myself to click on the link.
March 13th, 2007
[This is a re-post of something I wrote yesterday on the SAP Business Process Expert megablog, in case you don't follow that site.]
At the recent Gartner BPM Summit, I was shocked to see how high a pedestal the Gartner analysts now place simulation analysis in their gallery of must-have BPM capabilities. Ever obedient, the BPMS and modeling tool vendors now universally throw it into the box. How else to get into that Magic Quadrant?
But have these analysts ever really used these tools, or even scrutinized them closely? I’m not really sure. I haven’t looked at all of them myself, but my sampling to date tells me this is a fake feature if ever there was one.
In my training Process Modeling with BPMN, I wanted to add a big section on how to leverage the cool parts of that notation — events and exception handling, delays and batching patterns, etc — to project process performance using simulation. I know simulation isn’t part of BPMN — the spec not only doesn’t standardize simulation parameters but doesn’t even have the barest concepts of resource pool modeling — but it is a nearly universal feature of modeling tools that use BPMN. So that was my starting point.
Since the simulation tutorials of the tools I looked at — where they existed at all — didn’t address anything close to real problems of process analysis, I had to make up my own methodology and then apply it to the notation. It was in the course of doing that that I concluded that most modeling tools were missing four basic ingredients needed to make simulation real, not fake:
1. the right simulation parameters
2. the right calculation of standard metrics
3. the raw instance data needed to create custom metrics and reports, and
4. a methodology for translating the kind of performance analysis that’s supposedly possible into the parameters and outputs provided.
Let’s go through this, and if you still think your simulation tool isn’t fake, chime in. I should mention that the tool I wound up using in the training, Process Modeler 4 from itp commerce — one I touted here a couple weeks ago — was not only the closest to what I needed, but the vendor was willing to tweak the features in several places to try to get it right. You can’t ask for more than that.
Let’s start with what kind of predictive performance analysis are you expecting from simulation? Two things came immediately to my mind.
The first is the kind of analysis most folks have in mind when they document their as-is processes and sit around looking at the diagrams discussing why it takes so long, costs so much, and is so error-prone. Classic BPM “theory” says that the problem is in the handoffs, typically between roles or departments (swimlanes in BPMN). The improved to-be model has fewer yo-yoing handoffs between swimlanes, less unnecessary rework or pointless reviews and approvals. Thus, simulation use case 1 is to quantify the improvement. How much faster, how much less cost, etc? In this kind of analysis, remember, the problem isn’t about contention for resources — too few widget-tweakers at step 17 — but about inefficiency in the structure of the process itself.
The second is the kind of analysis that most BPMS vendors promote, particularly those focused on workflow automation. There it’s all about “bottlenecks” — too few widget-tweakers at the widget-tweaking step — possibly exacerbated by the fact that the same pool of widget-tweakers is also supposed to handle the widget-flipping task at step 19. We call this “contention for resources.” There the simulation is about creating various what-if scenarios with different numbers of widget-tweakers to see the bottlenecks disappear.
You don’t need to be a rocket scientist — you could even be a widget-tweaker — to know that if you configure enough widget-tweakers the bottleneck at step 17 will go away. So what? The issue is at what cost. So this analysis is about looking at the cost/time tradeoffs.
There is a variation of this type of analysis called activity-based costing. Here the idea is that different classes of work running through the process incur different costs. Simulation analysis by itself only gives you the direct or variable costs of each type. Activity-based costing lets you distribute the fixed overhead and other indirect costs as well in a “fair” way. In the newer forms of the analysis, called time-driven ABC, you can get everything you need from the simulation output, so it’s really an extension of the previous resource utilization use case.
So both of these simulation use cases (or all 3, if you count ABC separately) are important. But they’re different. The way you have to set up the simulation parameters is different, the standard outputs are different, and the custom reports you need are different as well. I worked through all 3 of these in my BPMN training, but my post here is about the simulation tools, not the training.
In the interests of time, here are the features I discovered I wanted in order to do all three. We can get into why later, if there is interest.
1. Activity duration parameters. One parameter is not enough. You need at least two, the active time (consumes resources) and a wait time (does not).
2. Event parameters. If your diagram has BPMN intermediate events, you need to provide parameters describing both the probability that the event occurs and the time it occurs. Ditto for event-based gateways. And if your tool doesn’t support these events and event gateways, I’d say it’s useless anyway.
3. Cost-per-use parameters for certain activities, in addition to the normal cost-per-hour.
4. Shift calendars for all resources, human and machine.
5. Priority and priority aging logic for resource contention. Which activity gets the resource instance? Which process instance gets the resource? This doesn’t affect the mean as much as the distribution of costs and times.
6. Contention for resources across multiple processes. (My tool didn’t have this.)
7. Breakdown of metrics at process, activity, and resource level.
8. Histograms of cost and time. Means are almost useless. It’s the outliers you need to worry about.
9. Resource utilization rate calculation.
10. Raw simulation data at the activity-instance level, ideally dumped into a tool like Excel that you can manipulate easily. Creating Excel named ranges? Even better! You can’t really do simulation analysis without this data. The standard reports are never exactly what you want.
11. Some rudimentary form of instance-level properties used by the simulation engine to identify types of work, and the ability to define simulation parameters as expressions of these properties. My tool doesn’t have this. It’s a slippery slope from instance properties to a full data model and a shift from simulation to emulation and debugging. We don’t want to go down that slope. Well maybe just a little. To do anything with quality metrics (not just cost and time) I think you need instance properties.
And once you have all this stuff, you need to show business process analysts how to use it, cookbook-style, for the three simulation use cases I described, maybe others.
I could go on, but you get the point. You say your simulation tool doesn’t provide many of these things? That’s because it’s a fake feature.
March 8th, 2007
Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN. Since that original post I’ve worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc). As a reminder that our BPMN training is now available from bpmessentials.com, it’s worth reprinting his comment here and showing the solution. He writes:
… I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers’ compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is ” not sure’ whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths….
In this case, it’s not clear whether the “exception” is that the letter has or has not previously been sent. But in this case it doesn’t matter. This is a case of a business exception (not system fault) detected internally by task or process logic (i.e. not signalled by external event). For that, we recommend use a gateway. In fact, here this exception occurs twice, once following the automated check (DB lookup) and again following the human review, if required.
Here the whole subprocess is marked as a multi-instance loop (the parallel bars at the bottom), which BPMN uses to model ForEach looping as in Bruce’s example.
March 6th, 2007
After 3 days of “what is it?” and “where it’s going” and “how great it’s gonna be,” attendees at the Gartner BPM Summit this week finally got to hear “how to do it” on the afternoon of the last day. Normally only a few diehards stick around to the bitter end, and I guess you can’t blame Gartner for giving this slot to the outside consultants. Also, I had to compete with 4 other How-To sessions from topnotch guys like Paul Harmon and Tom Debevoise. But I have to tell you, the room was packed - over 120 people - to hear my mini-version of the Process Modeling with BPMN training course, and there were lots of great questions from the audience.
People get BPM, what it means, what it can do for them. Clearly the need now is training and education on how to do it.
March 2nd, 2007
Previous Posts
