Tag: iirbpm

IIR BPM: Michael zur Muehlen on integrating business processes and business rules

I finished the day listening to Michael zur Muehlen discuss business processes and rules, a topic that I spoke about a few weeks ago at the Business Rules Forum. Michael, who I know from the BPM Think Tanks, is responsible for BPM courses at Stevens Institute of Technology. You can see his presentation slides online here.

He started out with the bottom line on why you want to integrate process and rules:

  • Simpler processes
  • Higher agility
  • Better risk management

Who wouldn’t want this? However, he points out that users don’t like processes, since they find them abstract (or possibly requiring a more analytic view of the organization) and restrictive (that is, not able to capture all the actual business cases). He also points out the obvious problem with Eclipse-based process modelling tools: they’re not friendly to business types. Became of that, we end up with technical people maintaining business processes, which usually results in a lot of code and the next generation of legacy systems.

He went though an example of an insurance company with 12 process steps and 5000 business rules, and it became obvious why rules change faster than processes. He highlighted three places where rules and processes come together: control flow, work assignment, and cross-process policy enforcement. I still think that the key issue is the boundary: when is something done as a decision tree in a rules system, and when it is done as control flow directly in the BPMS. Michael suggests that you might want to first model the rules in the BPMS, then extract the rules, although I don’t think that the rules experts would consider that a best practice. The challenge, then, comes with the modelling that’s done by the business analysts: how much do they need to know about rules, and what does their modelling environment need to look like in order to support that?

He had some good suggestions about mining rule criteria from previously executed processes, determining what the automated rules should be based on prior manual processes. From an insurance standpoint, this can result in auto-underwriting on standard cases.

He talked about the links between process management, business rules and compliance: whereas BPMS can enforce process compliance, rules are used to enforce contextual compliance for all the things around the business processes that aren’t really part of process compliance.

Michael and a colleague did a fascinating study of which BPMN symbols are actually used, and found that there’s 6 or 7 symbols that are used in most of the diagrams — the rest are strictly long-tail usage. See page 39 of the slide deck that I link to above for the chart.

He had some practical advice on how business rules and business processes interact:

  • Business objectives (rules) govern and prioritize business activities (processes)
  • Process objectives (rules) govern and define core processes (processes)
  • Process objectives break down to business rules and core processes break down to business processes, where business rules govern the business processes, and bsiness processes use the business rules.
  • This can be taken to a further level of granularity with operational rules.

He also had a chart for classifying change, and showing where it made more sense to use business rules or business process for a particular decision/activity; for example, use rules if it’s rapidly changing, company-wide and less predictable.

My flight home leaves tomorrow mid-day, so this is likely the end of my IIR/Shared Insights BPM conference coverage. Next year, maybe they’ll spring for more than 2 nights of hotel…

IIR BPM: Me and the role of standards in BPM

I’m up now, and here’s what I’ll be presenting:

I know, it’s long, but I’ll breeze past a number of the slides that I put in there just for reference. If this isn’t enough on standards for you, I highly recommend Michael zur Muehlen’s BPM standards tutorial. I liked it so much, I stole a couple of his slides, although he’ll probably sit in on my session to keep me honest.

IIR BPM: Pat Morrissey keynote

I attended Pat Morrissey’s (of Savvion) keynote session after lunch, but didn’t take a lot of notes since I’m up next. Pat’s a great speaker, very funny with lots of good real world examples, from nuclear weapons to Guitar Hero.

He pointed out four key requirements of a BPM solution which, not surprisingly, line up with their product offering:

  • Process modelling
  • Process repository for capture and reuse
  • A deployment and management suite, such as their BPM Studio, to enrich the model by connecting it up to data sources and web services, and manage processes
  • Optimization to manage change, particularly the optimization that happens after the system goes live

He also talked about a process adoption curve, which is a bit like a BPM maturity model, and covered some keys to process solution success:

  • Start with modeling process as it exists today
  • Business and IT involvement early
  • Optimization happens after you turn on the solution
  • BPM is for business, SOA is for IT
  • Plan for the end state

He finished up with some ways to use process to move business to the next level:

  • Demonstrate success first then get executive commitment
  • Start big, start small, just start
  • Everyone can be a model — it’s about the people
  • Winners share
  • Process in the voice of the customer

I’ll just ignore how he said that BPM standards don’t really matter: way to lead into my presentation, Pat!

IIR BPM: Facilitated session on standards

Alec Sharp led a facilitated session on standards that we love, hate, or wish were there (or don’t care about). This is a bit similar to the BPM Think Tank roundtables, but we’re at about six small tables so had a chance for some mini-break-out sessions to discuss ideas, then gather them together.

The notes that came out of this:

  • One group had some general comments about standards, stating that a common language can simplify, but that the alphabet soup of standards is too complicated and IT driven.
  • Another group hates BPMN because they feel that a 200-page specification isn’t understandable by business users, and that BPMN is really for specifying automated process execution but is not for business consumption. It’s stifling and constrains what can be modelled.
  • Standards aren’t written in plain English. There are two sets of standards: methodology standards and tool standards, and we often confuse the two. Once is focussed on human-driven processes, and the other on technology-driven processes. A great analogy: the people coming up with the tools have never baked the cake, or even eaten one.
  • Standards are often misunderstood, both in terms of who they’re for and what they’re for: they’re misinterpreted by marketing types. [I see this a lot with BPEL having become a standard “check box” on BPM RFPs rather than a real requirement.]
  • Standards can seem inflexible.
  • Interchange standards are either insufficient or improperly used by the tools, making it near-impossible to do round-tripping between different tools. They’re intended to use for translation between business and technology domains, but notational standards are possibly becoming less understandable because they are targetted at flowing into interchange standards. [I’m not sure that I agree with this: IT may require that business model in specific forms rather than just allow business to use BPMN in the way that they best fits the organization.]
  • Standards should be discovered, not invented [Vint Cerf, via Michael zur Muehlen], and BPM standards have been mostly invented.
  • In defense of standards, one person noted that the form of a sonnet is one of the most constrained/standardized forms of writing, but that Shakespeare wrote some of his most beautiful works as sonnets.
  • I got in a few comments about the importance of interchange standards, and how round-tripping is one of the primary problems with these standards — or rather their implementation within the BPA and BPM tools.
  • There’s an issue with the priority when adopting standards: is it to empower the business users, or to support IT implementation? If the former, then it will likely work out, but if it’s for the latter, then the business is not going to totally buy in to the standards.
  • The relationship with the business has changed: it used to be treated as a black box, but now has to be more integrated with IT, which means that they have to bite the bullet and start using some of these standards rather than abdicate responsibility for process modelling.

I don’t necessarily agree with all of these points, since this turned into mostly a standards-bashing session, but it was an interesting debate.

IIR BPM: Roger Burlton keynote

Amazingly, there’s open (although weak) wifi in the Hotel Del Coronado’s conference hall, so I’ll be able to post as I write.

The day started with an opening keynote by the conference chair, Roger Burlton of the Process Renewal Consulting Group, on “BPM at the Tipping Point”. This was mostly a review of a few high-level generic BPM case studies, some of the reasons that companies adopt BPM (compliance, boomers about to retire, competition, agility), and a lengthy anecdote about a computer manufacturer’s broken RMA process that Roger ran into when he tried to get his laptop fixed a few years ago. He’s a good speaker, I’ve just heard variations on these same themes too many times at recent conferences. I’m assuming that most of the attendees don’t attend as many BPM conferences as I do. 🙂

He spent some time talking about the importance of considering your end-to-end supply chain processes, and how attempts to maximize internal efficiency (e.g., on time, on budget) can be in complete conflict with the overall effectiveness of the core processes (e.g., customer retention, revenue). He returned to this theme near the end of the presentation, stating that enterprise BPM requires full lifecycles and value chains, and highlighting some of the frameworks, such as SCOR, that can help get started with process management. He also pointed out that you need to focussing on improving the processes where you have most to gain from an end-to-end process view, not those that don’t impact the effectiveness of the core processes, no matter how broken they are.

He also had a great case study from a tomato packing plant that has no organizational chart, and the non-core-process workers believe that they report to the core process workers, that is, they’re only there to support the core processes. This is a brilliant concept: I’ve often railed against organizations where IT or purchasing or some other non-core functions loses sight of the fact that they’re only there to support the core business. This is more of an organizational maturity case study than anything to do with BPM, although obviously processes are managed as part of the whole. This obviously wouldn’t work in most organizations, but there’s some great lessons to be learned about focussing on the effectiveness of core processes rather than attempting to maximize local efficiencies within functional silos.

His conclusions:

  • Process is the only useful mechanism to translate strategic intent into capability — it’s what we do to get what we want
  • Process and other capabilities must be aligned — they all have to go in the same direction
  • We must put in place new strategic frameworks that use processes at the heart of the management system — we have to manage what we do

Watching him use his tablet computer does remind me, however, that it was he and a few others presenting on their tablets at the BPMG conference in London a few years ago that inspired me to buy one, which allows me to write on slides as I’m presenting and greatly enhances the experience (at least for me).

The roundtable idea that we’ve seen at the BPM Think Tank for a couple of years is starting to spread, and following this session are three “facilitated sessions”, which I assume are similar in format to the roundtables. I’m going to drop in on the one on standards, since I’m speaking on the same subject later today and will likely pick up some interesting thoughts. The unconference idea is gradually creeping into the mainstream, although I still don’t think that we’re ready for BPM Camp.