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.

Forgotten posts

I was in Windows Live Writer this morning (the offline tool that I use for writing blog posts) and noticed that I had totally forgotten to post the last two from Integration World last week. I’ve published them on the dates that they were written, and you can find Tata’s short presentation on next-generation SOA here, and Bruce Williams’ presentation on process improvement here.

Sorry about the slip; I’m definitely getting conference fatigue, and am currently at what I hope to be the last one for the year (since I have to skip SOA India).

Integration World Day 2: Continuous Process Improvement, Continuous Business Transformation

Bruce Williams, SVP and GM of BPM Solutions for Software AG/webMethods talked about BPM and how it enables business transformation. Bruce, who I had a chance for an in-depth chat with yesterday, comes from a solid Six Sigma background — including writing books on Six Sigma and Lean — which makes his focus on process improvement a natural. He started with a timeline of quality management from the 1950’s PDCA through TQM, BPR and other trends to the current focus on Lean Six Sigma. There are a lot of tools and techniques that can be used to improve processes, including BPMS’ that can be used to handle the automation, monitoring and governance side of things.

He outlined three steps to process performance happiness:

  1. The “B” in BPM – this is about your business. Considering that I give a course called “Making BPM Mean Business”, I’m totally on board with this. Bruce’s points included knowing where value is created, measuring what’s happening in the business processes throughout all stages of improvement, ensuring that the voice of the customer is heard, and allowing the business to determine the goals and drive the agenda of process improvement.
  2. Build to an architecture. In addition to models, methodologies and leveraging existing systems and assets, this also includes developing expertise in process and integration. I find that the process improvement centre of excellence approach works well in a lot of organizations, which typically includes both architecture and the expertise around it.
  3. Implement incrementally, improve continuously. Incremental implementation is something that I always recommend: not only do you get benefits earlier, but the vision of what needs to be implemented will change as soon as your first project goes into production.

This was a pretty short presentation, and they moved on quickly to the customer innovation awards. The winners were Corporate Express in the productivity category, Motorola in the business agility category, Lenders First Choice in the innovation category, DSM in the ROI category, and Satyam in the partner innovation award.

Karl-Heinz Streibich gave a brief closing address; the remainder of the day is breakout sessions and the conference finishes at the end of today, so this was the last general session.

Integration World Day 2: Next Generation SOA

Santosh Mohanty from Tata gave a presentation on SOA, with a bit about the current generation, and how to move on to the next generation. Tata is a pretty major sponsor of the conference: I think that webMethods created a new “diamond” level of sponsorship just for them, which gives them both the opening night reception plus a keynote this morning.

His lessons for achieving next generation SOA:

  • Define agility controls.
  • Create an agile platform.
  • Articulate enterprise value in terms of efficiency, agility and adaptability.
  • Create a performance framework in order to create a performance-driven organization. This ties in strongly with webMethods message about “measure first” and the focus on BAM and analytics.
  • Create business and IT collaboration. Much easier said than done, and I’m not convinced that business needs to be all that involved in SOA since it’s really not relevant to most business people how the services get delivered, just that they are delivered. Of course, I see BPM and SOA and two distinct technologies; those that see BPM as just an extension of SOA will see business-IT collaboration as a necessity, and I think that Tata may fall into this latter camp.
  • Establish the right governance.

Tata was (I believe) one of the first companies to achieve CMM level 5 certification, and it makes sense that Mohanty’s first point is about control. It won’t do much to foster emergent applications, however. I think that all the large systems integrators are in a similar position: although there’s lots of work for them around legacy modernization and creating services, the current generation of BPM tools has to scare them, since it allows organizations to do a lot more of their own codeless development of business processes.

Integration World Day 1: Best Practices in Delivering Results with BPM

Bruce Beeco of Cox Communications told their story of how and why they implemented webMethods BPMS. Their goals:

  • Reusable processes independent of channel
  • Consistent experience independent of channel
  • Visibility into processes
  • Proactive on customer-facing problems
  • Automate manual tasks to reduce cost and errors
  • Improve time-to-market for new products and services

Overall, their goal is to move the processes out of the front-end applications using BPM, leverage existing services and provide monitoring and business health using BAM.

They started a number of BPMS initiatives, including monitoring and alerting around existing applications, modelling new processes, portal interfaces and others; some of these are in production, while others are just getting started. Being a Six Sigma shop, they took on business processes by creating a shadow process to an existing human process: they created a process model, collected data from the real world and correlated events to the model to provide some “visibility” into the process, particularly for the purposes of optimization.

He looked at the link between SOA and BPM, and said that you can’t do services without at least modelling the processes, since otherwise you just don’t create the right services: the models identify the service integration points and required functionality. He also addressed the issue of when to put functionality in a service versus a process in BPM:

  • Use BPM if it maintains state; services are stateless
  • Use BPM if you have variable complex outcomes; services outcomes are fixed and predetermined
  • Use BPM for composite process solutions; services are discrete entities
  • Use BPM for process visibility; services are black boxes

His key lesson learned was that BPM and SOA need to be done together in order to have a holistic view of your operations and business.