BPM and Business Rules

Still catching up on some webinars that I missed, here’s one from June 30th about BPM and Business Rule Management Systems (BRMS). It’s hosted by Peter Carter of ILOG, and although he’s not the most dynamic speaker that I have heard, there’s some interesting content on the slides for those of you who might be working through the relationship between BPM and business rules:

  • BPMS focus on how people and systems interact
  • BRMS focus on how decisions are made

His point is that BPM can get you to a certain point in process automation, that is, where the only human intervention is for decision-making; BRMS can take you further to automated decision-making so that the only human intervention is for exception-handling. Of course, you can embed rules within a process map in any of the BPMS that I’ve ever worked with, but the rules are typically not explicit and may have to be replicated at a number of points in the process map, depending on the capabilities of the BPMS: most of the systems are really not built for explicit rules management. And, although all the BPMS vendors claim that it’s easy to have a business analyst change the process map at any time, in reality I’ve never seen an organization that would allow that to happen without (justifiable) layers of technical review and testing to ensure that the new process logic doesn’t break something. As I mentioned in this post, you’re pretty unlikely to find someone within the business part of an organization that is sufficiently trained/experienced in systems thinking to be able to make what are essentially programming changes, even if they are using a pretty graphical interface.

Business rules typically interact with a BPMS at a specific point in process, usually to generate a value and/or determine the next action to take based on the current parameters (e.g., pricing, eligibility determination, scoring, case assignment, data validation). That makes it a lot easier, and a lot less dangerous, to allow a business analyst to modify business rules without an undue amount of IT involvement: since the process map is not changed, there is no danger of work becoming orphaned or misdirected through a business rule change as long as the process map was properly designed in the first place.

This is why all industrial-strength BPMS are either OEM’ing a business rules engine into their product these days, or integrating tightly with one: you can’t swing an analyst’s report these days without hitting some new BPMS/BRMS alliance. ILOG’s certainly a driving force here, with alliances with Siebel, FileNet, Oracle, IBM, BEA, Fuego and a host of other major players. There’s one major exception to this alliance trend: Pegasystems’ BPM Suite is natively built on a rules engine, which has given them a leg up on the process+rules craze.

Going back to Mr. Carter’s presentation for a moment, I also like the way that he defines business rules from both a business and IT perspective:

  • From the business perspective, business rules are “formal statements of business policy that define or constrain some aspect of the business”
  • From the IT perspective, business rules are “business logic to be implemented in one or more business applications”

Too often the definition is made from only one of these two perspectives and, like Mars and Venus, someone doesn’t fully understand what was said.

If you want your business rules integrated with your processes, you’re going to have to figure out how your BPM tool and rules engine will integrate, then pull your rules out of the paper procedure manuals, mainframe applications, spreadsheets and all the other places where they live, and get them into that BRMS. Easier said than done, but rest assured that rules engines are here to stay in the world of BPM.

Secrets of Success

I just received an email from a recently-graduated engineer in Germany, looking for advice on how to become a credible resource on BPM projects with only theoretical BPM knowledge and a lack of business knowledge — in other words, how to ramp up from being a newbie with a decent technical degree into an experienced BPM consultant. I didn’t want to send off some flippant answer about long years of hard work, so I spent some time thinking about a few of the key things that I did (and still do) to turn myself from a techie with an engineering degree into a BPM architect who spends as much time thinking about business as I do about technology.

My advice to him:

First, research constantly about BPM, particularly case studies. There are lots of great resources on the web, such as BPMG, that have articles on everything that you would want to know about BPM, including real live case studies. Attend a BPM conference or two, such as ones by BPMG or Gartner, listen to more experienced people talk about what they’ve done, and make some contacts that you might be able to call on when you need some free advice.

Second, do some technical research into a few major BPM products, so that you can become somewhat of an expert on how BPM products work even if you haven’t worked with them. Many BPM vendors are very happy to have you learn more about their products, and if your target customers typically use a specific product (such as FileNet or Tibco), then research the technology behind that product or even attend vendor training so that you can stay one step ahead of your first customer on the technical side.

Third, learn more about your customers’ business. For example, most of my customers are in financial services and insurance, and I have become an expert on the business processes in these organizations through research and observation, even though I have never worked for a financial company (I’ve always worked for — or owned and operated — software or service companies). Even if you don’t have a contract with a potential customer yet, offer to come in and do a brief walk-through and analysis of their operations. Sit down with some of the people while they are working and ask them what they are doing, and why they’re doing it: that’s the best way to learn about the details of a business process. Very often, an outsider can observe something in a business that someone in the company won’t see, so you may be able to tell them something about their business that they don’t know after just a brief walk-through, if you’re observant.

Lastly, focus on the business issues, not the technology. If you are consulting on BPM directly to an IT department rather than a business department, the project has a high probability of failure: remember that the “B” in BPM stands for “Business”, and you have to stay focussed on what value that you are bringing to the business in order to successfully implement BPM.

I finished up my email by telling him that there is no real substitute for experience, but it’s possible to educate yourself about BPM in a way that provides obvious value to prospective customers. Many people in the customer organizations (even in the IT department) don’t have formal systems training, so this is a good opportunity to put to use all those analysis and problem-solving skills that they taught us in engineering, just applied to business instead of technical problems.

Hallucinating about ECM

The thoughts of my previous post on BPM and agility came on the heels of a conversation with a collegue in Australia who was looking for anyone who had implemented a comprehensive “ECM vision”, including BPM, web content management, records management and document management. It appears that most companies are implementing one large ECM-related project and some bits and pieces of the other parts; I have to admit that most of what I see is still at the hallucinatory stage rather than a full-on vision, and is neither cohesive nor comprehensive.

How many cusomter organizations really have an ECM vision, and more importantly, how many have the ability to implement it?

How agile are we?

I’m finally getting caught up on the emails, blogs and webinars that I missed while on vacation. One of the webinars that came up last week was Redefining Human-Centric BPM on eBizq. Sponsored by Adobe so very document-centric, but Beth Gold-Bernstein, the eBizq speaker, nicely categorized the benefits of human-centric BPM: improved quality, improved security, enforcement of business rules, and reduced cycle time. There’s a few others that I would add in, but this is a pretty good list to start with if you’re looking for ROI on human-centric BPM.

She also made a point early in the presentation that BPM is essential to delivering business agility, that is, the ability to change your business processes easily to meet changing conditions. I would have nodded my head right along with that one, except for this piece in Intelligent Enterprise last week about how companies implement one BPM project then consider their process work to be “done” rather than actually getting into that whole agility thing that they were sold by the vendor. It’s clear that agility is a both a key marketing point for BPM vendors and a key driver for the purchase of BPM systems — in other words, the vendors claim and the customers believe that business agility is important, and that BPM will help to deliver it — but the customer organizations may not be following through on the agility promise, and the vendors (having made the sale) have already moved on to the next prospect.

Process/business agility isn’t going to come about just by buying a hot BPM product (or any other product, for that matter): as usual, the technology is an enabler, it’s not the solution. Organizations need to embrace a philosophy of business agility at all levels, and not be squeamish when someone points out that “agility” is just “change” with good PR. Yes, jobs change, and that’s scary for some people. But customers (and their expectations) change, forcing the business to change, which forces the jobs to change. In order for an organization to be agile, the worker bees must also be willing to be agile and learn not just new tools (like BPM) but new ways of doing business. Just tell them that it will look great on their CV.

Inevitably, the vendors start to blog

While wading through a month of email and RSS feeds this week, I came across a BPM blog by CommerceQuest which is actually quite good. You have to skim by the blatant self-promotion (“I am pleased to see the market and industry experts beginning to talk more and more about the overall benefits of what we, at CommerceQuest, call Enterprise BPM”) as well as the more subtle bias towards the CQ way of life, and I could have done without the CEO’s folksy comments in his inaugural blog (“I never dreamt I’d be typing for the blogosphere when I started out more than 40 years ago at IBM” — no kidding?). However, it does contain some good reference entries that point to other blogs/articles of interest such as these ones on BPM at financial institutions, BPM and ERP, and BPM RFPs; there are also some “BPM basics” that I imagine are repurposed from their white papers or other technical marketing material. Worth a browse.

Different strokes

Coming back to the deluge of email, a slightly smaller torrent of postal mail and a soupçon of voice mail after 3-1/2 weeks in southern France and northern Italy is a bit disorienting. I’m still thinking about strolling over to the Rialto market in Venice to buy some fresh fish for dinner…

Travelling (although for vacation this time) always makes me ponder on cultural differences. Although I work primarily in Canada and the US these days, I’ve spent a great deal of time working in other countries in the past, and one of the things that I like most about business travel is seeing how different cultures do business differently. For example, only in France would a prospective client, upon meeting me, bow over my hand while shaking it and murmur “Enchanté, Madame”. And only in the Middle East would I need to wait until a man extended his hand to me before offering to shake hands, since I wouldn’t want to offend someone by suggesting that they violate their religious sanctions against touching a non-related female when I’m on their turf. [When I returned to my office in California and related this latter incident, I was asked “Doesn’t the discrimination bother you?” to which I replied “Well, at least they’re overt about it.” That resulted in a few stony glares.]

Aside from the greetings, there are other differences in how things work: I remember a BPM system that I designed in Germany several years back where the management wanted a supervisor to review each piece of work and decide who it went to, instead of using automated work assignment. With some foresight into how these things work in practice, we implemented a system configuration setting that caused that step to be either visited or bypassed, so that two days into production when the customer’s need for efficiency overcame their need for control, the supervisor review step was removed in about five minutes.

As an outsider coming into organizations and helping them to design their processes, or develop a strategy for application architecture, I’m always a bit of a foreigner, even in my own country: I have to quickly learn a new language and a new culture so that I look like less of a tourist wandering around with my camera and guidebook. In business, as on vacation, I’ve always found it best to just dive in and act like the natives.

Gartner’s BPM trends and forecasts

Another webinar going on right now, Gartner BPM Roundtable: Business Process Management Trends and Forecasts, hosted by Global 360 and featuring Jim Sinur of Gartner (yes, this turned out to be “webinar day”, I have a third one after this if I’m not burned out).

The usual webinar format is the “expert” talks to his slides for 30-40 minutes, then some marketing geek from the vendor talks about their product for 10 minutes. Not this one: it’s a very dynamic conversation between Mr. Sinur and Michael Crosno, President of Global 360, and both of these guys are really smart about BPM. Yes, Mr. Crosno talks about Global 360 product features, but it’s used as a springboard for Mr. Sinur to talk about the importance of specific functionality in the current and future BPM suites marketplace.

A few really great insights. The first one is was that legacy BPM deployments are more likely to have been for the purpose of reducing paper, whereas the new deployments are all about streamlining processes and improving productivity, with a new and increasingly important focus on extending the enterprise. Although this is something that we all know by gut feel, it’s good to see some real numbers behind it:

The second insight is that customer requirements are evolving from enterprise content management (ECM) to enterprise process management: a shift from information lifecycles to process lifecycles. As a “column 2” advocate, I’m really glad to see Gartner recognizing the shift in focus from content to process. Mr. Sinur showed a scale that started with image management and went all the way through to business optimization, with the crossover from ECM to EPM happening between portals and process execution. He puts “workflow” in the ECM space, that is, the subset of BPM that is used for content lifecycle management.

Another point was the trend for CRM vendors to integrate BPM with their products, usually by buying or OEM’ing in a third-party product, because they see it as an essential part of managing the customer relationship. I’ve been seeing this trend lately as well, such as with Onyx’s acquisition of a BPM product and their current push to integrate it into their mainstream CRM product.

By far the best webinar that I’ve listened to in months. The slides and the audio playback will be available tomorrow on Global 360’s site.

BPM in compliance

I’m listening in on a Ziff Davis webinar “The State of Business Integration: An Overview of Patterns and Best Practices”, featuring Ajay Patel, VP of of Server Technology for Oracle. In the course of the webinar, they’ve been doing a few listener polls, and this one was particularly interesting:

In other words, 27% of the webinar listeners consider BPM to be the most important technology for their compliance efforts, second only to corporate reporting/BI at 33%.