[My July column for BPMInstitute.org]
In these tough times, even the most change-resistant organizations are re-examining whether past practice should continue to govern standard operating procedures. Government and airlines, for example, spring to mind. Last week, I saw further evidence of this in delivering a BPMN training class to one of the many Federal agencies involved in financial regulation. I was surprised to find that most in the class were experienced process modelers already. Many had prior BPMN experience, for some including BPMN-based BPM Suites. The processes of greatest interest concerned internal policies and procedures: hiring and employee onboarding, granting security clearances, etc.
On the flight home, another pleasant surprise: wi-fi and AC power at my seat in coach! For about the same price as one of those nasty “snack-paks” they offer, you can get in-flight Internet service coast-to-coast. While other airlines solemnly invoke policies and procedures to ban cell phones, GPS devices, and even powered headphones below 10,000 feet, Virgin America has figured out that giving business travelers an extra full workday might be good for customer satisfaction.
On the flight home, I noticed something familiar in the latest column from my favorite business journalist, Steven Pearlstein of the Washington Post. Headlined “The Productivity Revolution Trickles Into Government,” the column relates how a top government priority, $80 Billion in loan guarantees for clean and renewable energy, did not expect to achieve approval of its first guarantee until the end of 2010, a full five years after Congressional authorization. Lots of rules, you see. Policies and procedures.
Not good enough, said Obama’s new Energy secretary Steven Chu on taking office in early 2009. He challenged his staff with the simple question, “What would it take to get the approvals done in three months?” Well. If you ask it that way… It turned out the secretary had the authority to waive, modify, or expedite half of the procedures – no one had bothered to ask – and the first loan guarantee was issued to a solar panel manufacturer in March 2009.
The real problem was no one was thinking about the end-to-end process. As Pearlstein relates,
[Chu's consultant] assembled staff members from all the offices involved and vested them, collectively, with end-to-end responsibility for the approval process. Up to that point, people had been focused only on their own narrow tasks, and when they were finished they tossed the application over the wall to the next office. Once they started working as a team, however, they found that some of the work… could be done simultaneously rather than sequentially.
While he could not have provided a better summary of BPM, Pearlstein frames the story in the more familiar narrative of “productivity,” government plodding versus the “efficiency” of the private sector. But this is not really about productivity, which measures output of work per unit of labor or capital applied. This is about cycle time, which is more often hampered by the structure of the end-to-end process rather than resource efficiency: unnecessary steps, excessively sequential processing, and no KPIs or governance at the end-to-end, customer-facing level.
Other recent government “productivity” gains Pearlstein cites are similar: DoD civilian security clearances reduced from 440 days to 40 days. IRS new hire process reduced from 120 days to 15. This tells me that while the principles of BPM are taking root in government just as they have in the private sector, the media still does not understand the role of process. They don’t yet get the BPM story.
That story begins with understanding the end-to-end process as a single “thing,” and measuring performance from that end-to-end, customer-facing perspective. That means, in turn, you need to be able to document the process end-to-end in a concise but readily understandable way, so you can clearly visualize the handoffs, exception paths, rework loops, and other sources of delay and stalemate.
Once you can visualize the process in this way, it becomes much easier to tackle process improvement. What would it take to do it faster, with less cost, or with higher quality? Why do we do this step here? In fact, why do we do it at all? Aimed at a process diagram laid out on the table rather than at the responsible person or organization, such questions lose the sting of a personal attack. They put the focus on the process rather than on the resources performing it. That’s a plus. Sure, implementing some of the proposed improvements may involve some office politics, but it no longer requires a miracle.
It all starts with documenting the as-is process, in a clear and sharable way. BPMN, the industry standard for process modeling, is great for that, and government is eagerly adopting it. But using BPMN effectively to create process models that stand on their own, clear from the diagram alone, requires a methodology and a consistent style. You can get that in my new book, BPMN Method and Style. Even better, you can learn it in a two-day class at BPM Institute, in Washington DC September 23-24 or in New York November 3-4. So whether you regulate Wall Street or work on Wall Street, here’s a way to jump-start your organization’s process improvement efforts.
[My June column for BPMInstitute.org]
As BPM begins to expand beyond isolated projects to mainstream programs at the division or enterprise level, there is a need to engage a far greater number of business people in the effort. That’s not easy, and achieving it is going to require significant change in the way BPM is practiced.
The most important role for business is probably documenting current-state business processes and analyzing them for possible improvement. But conventional practices in this area are inefficient and inherently small-scale.
One typical scenario involves a team of business analysts or business architects mapping various processes using Visio or Powerpoint. Doing this requires no special tools or training, but the resulting process maps are not easily shared without elaborate accompanying explanation or documentation. The reason is each modeler makes up his or her own conventions about what the shapes and symbols mean. There is no defined methodology. The sphere of understanding is thus limited to the individual modeler. This scenario doesn’t scale, and you can’t base a BPM program on it.
In another typical scenario, a process improvement consultant comes in and works with a small project team, with the goal of fixing some process problem in the business, or at least mapping out a plan of action. The consultant’s emphasis is typically on a facilitated methodology, not on tools. In fact, the “tools” employed are frequently yellow stickies on the wall and paper-based tables and charts. While this is fine for fixing isolated problems, it does not scale to program-level BPM. Again the sphere of shared understanding of the process, as-is and to-be, is limited, in this case to a small radius around the facilitator. And paper-based tools? Come on, this is the twenty-first century!
At the other end of the spectrum, a small group of business architects or enterprise architects may use repository-based Business Process Analysis suites to model the business at the division or enterprise level. Besides process, these suites model data, strategies and goals, KPIs, policies and rules, organizations and roles, services and systems, and so on. The tools are great for looking at the company’s core end-to-end processes and aligning them for consistency, data integration, and governance at the enterprise level. But they rarely get down into the weeds of the problems affecting process performance and quality at ground level. They are really about architecture, not process improvement. The tools are proprietary, very expensive – over $10K per seat – and require weeks of training in the methodology. For this reason alone, the approach does not scale.
Each of these approaches brings something important to engaging the business on a larger scale: software tools that are easily accessible, business-friendly, and inexpensive; a way to clearly express problem areas, including exceptions, in the process model; a well-defined methodology for translating process understanding into diagrams that can stand on their own; and a repository to facilitate model sharing, cross-referencing, versioning, and reuse. The trick is combining them.
Pieces of the solution are coming into focus. BPMN is one key ingredient, as it provides a business-friendly visual language for process modeling, able to express exception-handling and other process details, with predefined meanings for the shapes and symbols. Thus the diagrams, if created correctly, can stand on their own, shareable across the enterprise without accompanying explanation. BPMN is a standard, and tools are inexpensive, in some cases free.
A model repository is another. This is a database of process models supporting versioning and governance, allowing collaborative editing by team members without sacrificing authorization and access control.
Making these tools easily accessible across the business has been a challenge in the past. Now a number of tool vendors, including IBM, Lombardi, and SoftwareAG, are making repository-based modeling, including BPMN, available through cloud computing. Typically these are vendor-hosted sites that allow users to set up collaborative BPM team spaces on the web for a low monthly subscription. While the previous BPM era emphasized downloadable desktop tools for business users, the new trend is toward browser-based tools hosted on the web by the tool vendor.
With the tools in place, you still have the problem of using them effectively. BPMN proudly has no methodology, and its full palette of shapes and symbols is admittedly overwhelming. Very few people, in fact, either in business or IT, know how to use BPMN effectively. To encourage business engagement, one tool vendor strategy is to reduce the modeling palette to a minimal working set, essentially those carried over from traditional flowcharting, and make up the lost expressiveness through freeform commenting features. The idea here is that to engage business more fully, we need to lower the tooling barriers, making BPM so intuitive that anyone can do it.
I would call that the predominant view right now, but I don’t think it’s the right view. Certainly it’s not the complete answer. The reason is that in order to capture the exceptions at the root of process improvement, and in order to collaborate with IT in the development of improved to-be process implementations, business can’t rely on what it already knows about process modeling, because it doesn’t know enough. It needs to learn to think about process in a more disciplined, structured way – more like IT, but from a non-technical business perspective. It needs to understand what the BPMN shapes and symbols really mean, and how to use them effectively to communicate through the diagram. And it needs a methodology, a step-by-step cookbook for going from an empty page to a complete diagram.
In other words, instead of just dumbing down the tools to the level of untrained users, we could also educate and train business people to use BPMN as it was meant to be used. I’ve been doing that for over two years, and I’ve come to see through that experience what is probably obvious to many of you already: business users are not all the same. They don’t all have the same skills and they are not all trying to do the same thing with process modeling. What is essential detail to one group may be down in the weeds for another.
Consequently, I believe the right approach is to view BPMN as a hierarchy of levels. Level 1, meant for any business person, uses a limited palette and is intuitive to untrained users. Level 2, aimed at business analysts and business architects, uses a wider palette to capture nuances of process behavior, including event and exception handling. Level 2 is that long-sought common process language shared by business and IT, something absolutely needed to truly empower business in BPM. Level 3 is using BPMN to describe executable process implementations, really just for IT.
The hard part is making each level a refinement of the previous one, not a do-over. That means imposing some structure and discipline in the methodology of Level 1, so that the Level 2 modeler doesn’t just throw out the Level 1 effort but instead just tweaks it. The end result is one model, viewable at different levels of detail by different groups of users for different purposes, not separate models for each purpose.
That idea is the basis of my new book, BPMN Method and Style, and my new BPMInstitute class Process Modeling with BPMN, offered September 23-24 in Washington DC. If you want to learn how to effectively engage the business in BPM across your company, come to that event.
I’m trying to decipher Cordys chief strategist Jon Pyke’s post today on the case management proposal at OMG. It’s hard to tell what he’s saying, but I gather things did not go well in Costa Rica. I could have told him that, based on the bmi thread beforehand. He casts as the villain “analysts and consultants [who] do an excellent job of commenting upon products or suggesting ways to take them to market or advising on market trends [but who should not be] vehicles for developing standards.”
I hope he’s not talking about me, but I don’t know of any other analysts who are even thinking about case management or discussing any OMG efforts in that area. If so, I think the blame is misplaced, since if anything I am a supporter of standardizing a notation for case management and integrating it with BPMN. Probably one of the few friends Cordys has in that regard…
I do think the OMG process is an unlikely one for case management. But just because I’ve given up on it before it starts doesn’t mean I am trying to “scupper” it (whatever that is… sounds bad). Anyway, BPM analysts are hardly the ones driving the boat at OMG. I wish! My BPMN 2.0 experience has taught me that the real battle there is between the “architects,” UML/metamodel people stuck in the 20th-century paradigm of models that can be compiled into any programming language, and the “engine vendors,” who want models that roundtrip with metadata-driven (code-less) implementation design. Preferably consistent with their existing engine architecture. I have more sympathy with the latter, but I have to say that neither one is especially concerned with notation per se, i.e., diagrams that are expressive but lack executable detail.
I wish the Cordys guys well in their quixotic OMG adventure, but I think an informal process in which participants share the basic objective and ground rules – notation-centric, non-executable, xsd-not-UML, linked to BPMN 2.0 – is more likely to achieve something than a formal process in which half the participants never liked BPMN in the first place. If Henk and Jon get tired of spinning their wheels in OMG, I would welcome their ideas in another forum.
Lest there be any doubt that OMG is not a market-driven organization, they could not even generate a press release to proclaim BPMN 2.0’s first big step into the world of official standards. So I asked Dave Ings, IBM’s BPMN 2.0 pooh-bah, what actually transpired last month in Costa Rica. Here is what he said (as amended by Oracle’s Jeff Mischinsky):
Our BPMN 2.0 submission passed four key votes and is on track to be an OMG “alpha” specification by the fall. Here’s what happened:
On Monday morning 6/22 the BMI Task Force passed the “vote to vote” motion 23 to 0 (with 1 abstention) thereby waiving the extended review period and setting up an immediate adoption vote. Then the task force voted 23 to 0 (again with 1 abstention) to recommend adoption of our final submission.
On Monday afternoon the OMG Architecture Board reviewed and approved our submission.
On Friday morning, at the OMG Plenary the DTC voted to initiate the general membership approval vote and to charter the Finalization Task Force (FTF). [Mischinsky: Actually the (email/fax) vote is of the DTC members (Contributing and Domain Contributing level members), not the general membership, and it is started (automatically) by... DTC Chair.]
So what’s next?
The general membership vote will take 6-8 weeks (it’s conducted via email). When the vote is done, the OMG Board of Directors will formally adopt our submission as an OMG “alpha spec”. We expect this to happen by September. [Mischinsky: The OMG Board will first require and review Business Committee questionnaires from the submitting companies. If the Bus Comm is satisfied with the answers (they ask about licensing/ipr terms and commercial availability plans), then it will make a recommendation to the Board that the submission be adopted. This is one the reasons why we had all the submitters sign the Participation Agreements -- to ensure upfront that we are all committed to licensing terms which we know will be acceptable to the Board. The Board will then vote on whether to adopt.]
We expect the FTF to take up to a year to complete – see the key dates in the final version of the FTF charter, attached. Mariano Benitez, Ivana Trickovic and Steve White will co-chair the FTF. (For those of you who don’t know – the FTF is a debugging phase during which vendors bring their implementation experience to the table to tweak the spec prior to final standardization.)
Everyone is taking a breather for a couple of weeks and I expect that later this month we’ll hear from the chairs regarding FTF ramp-up.
P.S. OMG terminology note – when the FTF publishes its first draft, our spec will change from “alpha” to “beta”.
The FTF “charter” is just a list of members and deadlines:
Beta Specification Publication: 01 September, 2009
Comments Due: 1 March, 2010
Report Due Date: 24 May, 2010
Report Deadline: 21 June, 2010
So what does this mean in plain English? In the FTF phase, implementers (tool vendors) will point out technical problems, but for the most part, what you see now is what you are going to get. For sure we will see implementations long before June 2010. IBM and Oracle, pretty much for sure, and ITP Commerce, which I use in the BPMessentials training. As I’ve said before, there are just a few changes to the notation, some good – non-interrupting events, Escalation event, event subprocess, XML export – and some you can completely ignore (choreography, conversations…). My book (and training) assumes the good stuff in BPMN 2.0 will stay more or less intact. I would be shocked if it did not.
The vote on BPMN 2.0 is not the only thing on the agenda at next week’s OMG meeting in Costa Rica. There is also the release of an RFP for a new Case Management standard, authored by Henk de Man of Cordys. Response to the announcement of same on OMG’s BMI mailing list has been sometimes thoughtful but mostly the kind of doubting, naysaying, and non-sequiturs you often get on that list. I once learned the hard way the danger of hitting Reply All to a BMI discussion thread, so I choose to post my thoughts here instead.
The RFP asserts that BPMN is inadequate for case management but that case management should leverage BPMN for the “process” part, and I agree with that. It also seeks to tie in to OMG government task force effors on records management for the case folder part. That might be useful as an option but I hope it’s not a requirement.
Of course, a major problem with case management is that there is no common definition for what it is. I would assert you could say the same thing about BPM until BPMN provided a standard vocabulary. Not everyone agrees with BPMN’s conceptualization of process as a centrally-controlled orchestration (the rules guys, the choreography guys…), but for most of us it works, whether you are modeling automated processes or just describing manual ones.
Here is how I see the differences between case management and conventional BPM as described by BPMN 2.0.
- A “case” (instance of a case management process) does not progress from start to completion by following paths on a control-flow diagram like BPMN. The case as a whole has milestones or states, so progress to completion is more like a state diagram than activity flow. But we know that UML state charts are not “business-friendly,” so perhaps that piece needs a makeover like BPMN did for UML activity diagrams.
- Much work on the case is driven by external events, not control flow. Those events, in combination with human activity responding to those events, determine the tasks and conventional processes that need to be completed. So there is an ad-hoc nature to case management processes, in which activities are added to the case at runtime. Usually these activities are not conceived on the fly, but predefined and selected from a menu or catalog.
- In conventional BPM, a task performer is not usually presented with every bit of detail about the instance, just enough to perform the task. In case management, performers interact with a shared case folder containing all the artifacts related to the case… data, documents, tasks, processes, their assignees and deadlines, etc. The notion that such a folder should be managed as a record, while obviously true, seems no more true than for the artifacts of ordinary process instances. Yes you need records management for both, but that is independent of the process aspect.
I think these differences from conventional BPM are not so great that case management needs to start over. An extension to BPMN to handle the case state progression model, in combination with a better solution for the ad-hoc/dynamic activity initiation part – let’s face it, today’s Ad-Hoc Subprocess notation is lame – is not beyond the range of possibility. Because a case will inevitably contain conventional processes modeled in BPMN, a strong connection between the case modeling notation and BPMN would be extremely valuable.
Tags: case management
It came together faster than I thought! BPMN Method and Style is now available on Amazon.com. I had hoped to send out an email blast last night to announce it to all BPMS Watch subscribers from the Mailpress plugin, but I’ve been learning (the hard way) about gmail’s smtp limit… Apologies to those first 100 or so subscribers who probably got 3 or 4 emails. For the rest of you, here is what I was trying to say…
If you’ve been following BPMS Watch lately, you know that I’ve been working on a book that explains how to use BPMN correctly and effectively to create process models that can “stand on their own”… i.e., be clear and understandable to anyone from the diagram alone. The book is called BPMN Method and Style, and it’s available now on Amazon.com. It’s based on the brand new BPMN 2.0 standard, set for approval by OMG later this month.
Creating business process models that can be shared effectively across the business – and between business and IT – demands more than a digest of BPMN shapes and symbols. It requires a step-by-step methodology for going from zero to a complete process model. It also requires consistent application of a modeling style, so that the modeler’s meaning is clear from the diagram itself. I not only explain the meaning and proper usage of the entire BPMN 2.0 palette, but call out the working subset that you really need to know. The book also reveals the hidden assumptions of core concepts left unexplained in the spec, the key to BPMN’s deeper meaning.
The book addresses BPMN at three levels, with primary focus on the first two. Level 1, or descriptive BPMN, uses a restricted palette in combination with some relaxation of BPMN’s rules to meet the needs of business users doing basic process mapping. Level 2, or analytical BPMN, takes advantage of the notation’s exceptional expressiveness for detailing event and exception handling, key to analyzing and improving process performance and quality. Level 3, or executable BPMN, is brand new in BPMN 2.0. Here the XML underneath the diagram shapes can be deployed to a process engine to actually execute the model. The method and style recommended by the book aligns these three levels, facilitating business-IT collaboration throughout the process lifecycle.
Inside the book you’ll find detailed discussions, illustrated with over 100 examples, about:
-
The questions BPMN asks, and does not ask
-
The meaning of basic concepts like starting and completing, sending and receiving, waiting and listening
-
Subprocesses and hierarchical modeling style
-
The five basic steps in creating Level 1 models
-
Event and exception-handling patterns
-
Branching and merging patterns
-
Level 2 modeling method
-
Elements of BPMN style: element usage and diagram composition
If you have an interest in learning how to do process modeling the right way, or just want a heads up on what’s new in BPMN 2.0, I hope you’ll take a look at the book. If you are interested in training based on the new “method and style,” I’m doing a 2-day class in San Francisco on July 1-2, hosted by the BPM Institute. Click here for details.
The book should show up on Amazon in the next couple days, but probably not orderable until Ingram (the distributor) gets it set up, which takes up to 4 weeks. But you can be first in line to get the book, and I’ll give it to you personally… for free! All you need to do is sign up for my 2-day class at BPM Institute in San Francisco July 1-2. Here’s all the info you need on that. Hope to see you there!
I’ve taken an interest in cloud-based modeling tools, so I decided to check out a new one from Signavio. This is a German company related somehow to Gero Decker and colleagues at HPI, the authors of that steamy BPMN “novella,” The Process. A 30-day trial is free. Here’s a quick review.
- You have to sign a click-through agreement in German to get started. Oh well, who reads those things anyway?
- You can invite others to share your online space, which stores models in a repository.
- The BPMN editor requires Firefox 3.0 to run. They don’t tell you that until you actually try to create a diagram. That’s annoying.
- Besides BPMN they also support ARIS EPC. OK, it’s Germany…
- It supports the ful BPMN 1.x palette, and the website says they are adding BPMN 2.0 “soon.” Very nice. Lombardi Blueprint has just a limited subset. For BPMN 2.0 support, they seem fired up about Conversations and Choreography… strange.
- Also, unlike Blueprint you can actually export the diagram info in XML. It’s a proprietary format but easily mapped via xslt to xpdl or BPMN 2.0.
- All the BPMN 1.x attributes can be edited in a popup property sheet. But they don’t seem to change the diagram. For instance, you can set a task type, but there is no icon in the diagram. I suppose that applies to things like loop markers, etc., as well.
- There is no documentation or help. But you can email questions to them for help. Yeah, right. Weak.
- Hovering over a hotspot on a selected node in the diagram, there is a graphical “menu” of connector and node shapes, similar to Lombardi Blueprint except a bit harder to use. If you want to draw a second sequence flow out of a node, you need to draw one to a dummy activity, move the sequence flow to the real target, and then delete the dummy activity. At least that’s the only way I could figure out how to do it. (Blueprint is only slightly better.)
- From a collapsed subprocess, hyperlink to a separate diagram to create the expanded view. The model keeps them together (at least for navigation). That’s pretty nice.
- No label allowed on a gateway. What’s up with that? You need to add it as a text annotation.
- You can save versions in the repository, but it doesn’t have the nice snapshot and revert capabilities of Blueprint.
After the trial period, of course, you have to pay. The price seems high for what you get. It’s EUR 30 per month for the basic edition and EUR 75 per month for the enterprise edition. Not sure if that’s per team or per user… I guess that would make a difference. The enterprise edition has a lot more functionality, like saving to xpdl or bpel (I assume saving to bpmn 2.0 will be enterprise-only too, not sure…)
The thing that I’m not crazy about is that the diagrams just don’t look that good. Mostly the problem is lack of bendpoints in the connectors, and the way labels look. For this kind of money I would expect better. For example, here is a diagram used for the Level 1 (“Descriptive BPMN”) portability work in XPDL, first in Signavio and then in the ITP desktop tool I use in my training.
Others might disagree, but for me there’s no comparison. And if you don’t need to export to xpdl or do simulation or validation, the ITP tool is free. The funny thing is, Signavio is based on a free online BPMN editor called Oryx, available from HPI’s website, and the Oryx diagrams look better.
I’m not sure what Signavio’s value-add is, maybe the online team repository, but in the diagram itself it looks like a value-subtract.
Tags: BPMN
I finally shipped the book off to the printer yesterday! Wow, why does the last 5% take 50% of the time? Not certain how long before it ships, but June almost for sure.
I’ve been using the new levels-based method and style approach in private classroom training for the past couple months. I think it makes learning BPMN much easier, especially for business people. On July 1-2, I’ll be doing a public two-day class in San Francisco, hosted at the Parc 55 Hotel in Union Square by the BPM Institute. Get out of the heat and come to our beautiful city by the bay… and learn some BPMN while you’re at it!
The course info page on the BPMInstitute site still has the old version, so until they update it, this is the info on the new course:
Traditionally, process modeling has relied on proprietary tools and methodologies, raising the cost and limiting shared understanding. Today we have a widely accepted standard for process modeling, the Business Process Modeling Notation (BPMN) from OMG, with near-universal adoption by modeling tools. BPMN looks a lot like traditional swimlane diagrams, but adds powerful new features that allow exception handling – the hidden cost of real-world business processes – to be modeled explicitly in the diagram.
This course shows process modelers how to use BPMN correctly and effectively – to document existing processes, to analyze and improve processes, and even to collaborate with IT in executable process design. Creating “effective” models – those that stand on their own, clear and complete from the diagram alone, without accompanying explanation – depends on more than knowing the catalog of BPMN shapes and symbols. It requires understanding BPMN’s hidden assumptions about basic concepts – What exactly is a process? What do sequence flows and message flows really mean? What does BPMN mean by starting, completing, sending, and receiving? You won’t find the answers in the BPMN spec, but they are critical to using BPMN effectively.
But that alone is not enough. Effective modeling also requires a methodology, starting from a blank page and progressing to a complete diagram. And it requires a style guide, a set of rules and best practices for making diagrams clear from inspection. This course provides those as well.
This course, based on Bruce Silver’s new book BPMN Method and Style, will show you how to use BPMN at two different levels, with a method and style applicable to each level. Level 1, or descriptive BPMN, is intended for business users. It relies on a basic working set of shapes and symbols, familiar from traditional flowcharting, but aligned with the basic structure and meaning of Level 2. Level 2, or analytical BPMN, is intended for business process analysts and architects, as well as developers planning to collaborate with business on process design. Level 2 BPMN represents a common process language shared by business and IT, but achieving that common language demands attention to method and style. Level 2 refines Level 1 models with an emphasis on events and exception handling, the source of problems in most existing processes. We teach specific diagram patterns that signify a particular type of exception and its effect on the process, so that exception behavior is captured explicitly and clearly in the diagram itself.
You can’t learn BPMN from lectures. You need to be hands on. That’s why the training uses a BPMN tool, an add-on to Microsoft Visio. Each student is expected to bring a laptop to the class and will use it to complete exercises, both in class and afterwards. The post-class exercises are optional, but give students the opportunity for individualized feedback and instruction. The price of the training includes 60-day use of the tool, Process Modeler for Visio from ITP Commerce. In addition to certification through BPM Institute, students who satisfactorily complete the post-class exercises are eligible for certification of proficiency in BPMN modeling from BPMessentials.com.
Course Outline:
Day 1
1. Why BPMN?
2. Getting Started: BPMN Level 1
3. The Level 1 Palette
4. Level 1 Method
5. Level 1 Style
Day 2
6. Deeper Meaning: BPMN Level 2
7. Events
8. Branching and Merging Patterns
9. Exception Handling Patterns
10.Repeating Activities and Pools
11.Level 2 Method
12.Level 2 Style
13.Gaining ProficiencyCourse Objectives:
· Understand where BPMN fits in the overall framework of business modeling and its role in business-IT alignment
· Learn a “cookbook” methodology for creating business-oriented Level 1 models
· Learn elements of Level 1 style essential to clear and effective models
· Understand the hidden technical meaning behind BPMN’s shapes and symbols
· Learn a methodology for refining Level 1 models to show the exceptions and variations important to key performance indicators
· Learn the “art” of process modeling, diagram patterns and best practices that allow your diagrams to stand on their own
If you are interested in BPM Suites, I’ll be doing a session on BPMS vendor selection and a vendor panel at the Brainstorm BPM Conference at the same site on the preceding day, June 30. Brainstorm is offering BPMS Watch readers a limited number of Complimentary 1-Day Passes* (a $795 value) to the Conference for that day. Register with Priority Code SILVER when requesting a Complimentary Conference Pass.
To sweeten the deal, if you sign up for the class I’ll also give you an autographed copy of the book. Now how can you resist that?
Tags: BPMN, bpmn 2.0, bpmn book, bpmn training
That’s the title of my new book. I’m planning for release end of June, coinciding with approval of BPMN 2.0 by OMG. The basic idea is that using BPMN effectively requires more than a summary of the spec… especially with BPMN 2.0, on which the book is based. It needs three things besides that.
- First, an understanding of BPMN’s most basic concepts: what is a process? what do sequence flows and message flows really mean? You won’t find this in the spec, but BPMN is built around very specific assumptions on these and similar conceptual foundations.
- Second, a cookbook methodology that takes a modeler from a blank page to a completed diagram that stands on its own, i.e. is understandable by others without further explanation. The book provides a two-level methodology. Level 1 is for non-technical business users. It combines a limited palette of shapes and symbols with a step-by-step approach to constructing a BPMN model. Level 2 is for business process analysts and architects. It focuses on a core set of event and exception-handling patterns that allow BPMN’s expressive power to be understood consistently across the organization, creating that common language shared by business and IT. Of course, the methodologies need to be aligned, so in the end there is one model, not two.
- Third, a manual of style, with sections applicable to Level 1 and Level 2. These are rules and best practices for making diagrams clear, consistent, and true to the modeler’s intent. The BPMN spec gives the modeler wide latitude, enough to create bad models that are technically “valid.” The style sections give prescriptive guidance to avoid that.
I’ve set up a website for the book where you can see the table of contents, read the preface and first chapter, testimonials, etc. The method and style presented in the book also form the basis for new versions of my BPMN training. The full Level 1/Level 2 training based on BPMN 2.0 and Process Modeler for Visio is available in San Francisco July 1-2 through BPM Institute. Also, I am developing a 2-day Level 1-only “live online” class based on Lombardi Blueprint, available through Lombardi University. No dates set for that yet, but probably in late June or July.
Tags: BPMN, bpmn 2.0, bpmn book, bpmn training, process modeling
Recent Comments