This post is for all you business people, and maybe some IT people, who are a confused about how BPM and maybe afraid to ask those really dumb questions, like what's the point and what's it got to do with integration.
First, a confession: I have a business process management blind spot. Maybe my brain just has one too many TLAs (three letter acronyms) or maybe it's because BPM lives in this netherworld-touted for its business benefits, used by the business, but technically it's often considered middleware and it's connected to tech-heavy issues like integration and SOA. Whatever the reason, BPM has always been a source of confusion for me.
I think I've finally sorted it out, thanks largely to BPM expert and consultant Sandy Kemsley, who kindly answered all my "stupid reporter questions" (my term) about BPM, and, to a lesser extent, a recent article by Margaret Dawson of Hubspan.
My first stupid reporter question for Kemsley: What does the BPM do and specifically, why are you sitting down to use it?
I had images of someone sitting there, doing flow charts. I couldn't imagine how that would be especially helpful.
Kemsley explained that, yes, there is a modeling component to BPM, and you can use that to find inefficiencies and fix your manual processes. The idea here is that you might see the same step in two different places.
But, realistically, there are other ways you can do that, like Vizio or Aris, she added. A full BPM system goes beyond that to actually automate steps.
Now I've got an image of some poor worker dude, on a conveyer belt, being automated. "I think that's the part that confuses me, because it involves people and I'm not sure how you automate that," I said.
Yeah, well, sometimes, you can automate what people do, Kemsley responded. You can also rework what people do or even eliminate steps by making the computer systems involved more efficient, say, through integration.
"I've seen all kinds of cases in the past where there wasn't integration between systems and so you would get a document in, somebody would key some information off a document into one system and then they would re-key it into another system and if you look at what that process looks like, that's a horribly inefficient piece," she said. "Now, there are other ways to do it, but BPM systems can, for example, take data out of one system and push it into another system without human intervention. So if both of those systems have interfaces that the BPM system can talk to, it acts like a bridge between different systems."
Ah. That explains why it's considered middleware, which is how IBM and some others, in fact, categorize their BPM systems.
But there's more, Kemsley continued. It can also automate some of the decisions people have to make-in other words, it enforces the rules of the business-and even bring a consistency to rule enforcement that you might not get with people.
"You can make sure that the same steps get followed and that the same rules get executed the same way every time and take out some of the human steps," she explained, adding that this feature made people uneasy back in the early days of BPM, because this sort of business process re-engineering lead to the elimination of jobs.
"Yes, it can eliminate jobs, but it eliminates jobs that are all about the kind of grunt work of, well, let's transcribe some data from this system to another system, or, you know, the kind of non-value added stuff, and really sort of frees up people for doing more the knowledge work, which is probably more interesting for them and definitely where they bring more value to whoever they work for rather than the transactional type stuff," she said.
That function can also support more modern needs, like routing information across a global enterprise or creating an audit trail of who does what and when it's done. These rules can be embedded in the BPM system, she explained, but ideally, you'll have the rules in a separate rules engine that the BPM tool and other systems can reference.
"I prefer to see them externalized because you might want to use the same rules in other systems-like you might want to call a business rule from your CRM system and call the same rule from your BPM system because a business rule is a business rule independent of where it comes from," Kemlsey said. "You'd like that rule to be in one place so that if your parameters change about what constitutes a gold customer, you'd do it in one place and it effects everything."
To sum up and see if I understood, I ventured a simile: "So BPM is sort of like a traffic cop, but with really good memory."
"Exactly," said Kemsley. "And the traffic can include both human participants and system participants."
Kemsley and I actually had a long discussion, with more intelligent-sounding questions from me and her always-intelligent answers, about how master data management supports BPM. In the first part of our Q&A, we discussed this trend and how it supports data integration. In the second part, she explained what combining the two would mean for MDM's business case and ROI.
If you'd like to learn more about BPM and how it relates to business integration in general and SOA in particular, you should also read this recent eZine article by Dawson. I actually saw this article republished on several blogs recently, and it traced back to eZine, but don't hold that against it. It's actually a really good article, with a great example of how these three areas are converging.