Recently I participated in a podcast with fellow ebizQ bloggers to make some fearless predictions for BPM in 2007. Making predictions, of course, is a dicey affair. There are only two ways to do it. Either you make a firm prediction and hang your hat on it, or you make a fairly general prediction that few can refute and fewer still will bother to do so.

One interesting example that actually achieved both objectives (unintentionally, of course) was this statement of Henry Ellsworth, Commissioner of the U.S. Patent Office, in his 1843 report to Congress: "The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." This is apocryphally misquoted as: "Everything that can be invented has been invented."

Check out our fearless predictions on this podcast. Fellow intrepid gazers at the crystal ball are Keith Harrison-Broninski, James Taylor, Joe McKendrick, Sandy Kemsley, Michael Dortch, and David Kelly (whose article put the said crystal ball temptingly on our bloggers' table). Elizabeth Book, ebizQ's editor-in-chief, moderated the podcast.

Of course, if none of the predictions come true, then we'll borrow a leaf from Yogi Berra and claim that 'the future ain't what it used to be.'

But a large part of where the BPM market goes is really in our collective hands. One of the 'sooths' that I say is that there will be an increasing awareness and adoption of BPM within companies. It is up to us—bloggers and readers— to make sure this comes true, by actively evangelizing the benefits of BPM, educating our colleagues on the concepts of BPM, and boldly going where no ERP ever ventures.

I'll be in Chicago this Thursday, bravely spreading the word along with some of my colleagues through a BPM Master Class. Oh yes, the classes are free. Attendees get a free copy of my book ('The Power of Process'), and get to hear Bruce Williams, co-author of three 'For Dummies' books in Six Sigma and Lean. But most important, attendees get a ton of information and practical tips on BPM, plus a first-hand look at BPM in action through webMethods' Fabric 7.0 platform.

Posted by kirankg in BPM • SOA | Permalink | Comments (0) | TrackBacks (2)

Ignorance can be bliss. Knowledge can be dangerous. You have been warned!

Several years ago, I remember reading about a top business executive who commented on the arrogance of IT. Paraphrasing his statement, “IT is the only function that is so arrogant that IT professionals insist their business clients learn and speak the language of IT.” Of course, IT professionals don’t try to teach programming to the non-IT folks. So where does the arrogance of IT lie?

Consider that the IT-business divide is difficult to bridge precisely because IT keeps thinking of “special technical solutions” for what are essentially ‘end-to-end’ problems in business processes. Rules can’t be managed? Use a BRMS. Data can’t be managed? Use EDM. You don’t know what the data means? Use metadata. You don’t know what happened? Use BI. Need to manage customers and prospects? Use CRM. Can’t find all your documents? Use ECM. Need to comply with SOX? Buy some shrink-wrapped panacea.

But business users don’t think or operate this way. They don’t compartmentalize their minds while running their company. Only IT forces them to do so. Let us say a business executive wakes up one day and says, “I think we have a problem with our loan processing. I hear anecdotes about our competition undercutting us. I have to find out what the data actually shows. Are all our financial products suffering equally? Do we have similar issues in Europe? I wonder how well our underwriting rules perform. In fact, where are our underwriting policy documents? Is everyone using the same policy document? I know we made some changes, so maybe there are different versions floating about. I must solve this problem.”

Unfortunately, the moment this executive encounters an IT manager in the corridor, he says, “We have a problem. We can’t locate the data. We are struggling with dropping loan revenues. Can you get me some reports?”

The IT manager says, “Sure, what you need is a BI solution.”

The executive then encounters an IT program manager. “I am afraid our salespeople are using different rate sheets. In fact, I think even our underwriters are working with different versions of the underwriting policy. Everywhere, it is the same problem. How do we fix this?”

The program manager says, “There are ways to manage our enterprise content. There are software applications called ECM suites. We should buy one of those. I’ll start the evaluation process right away.”

Executives don’t verbalize their internal problem definitions in front of IT, partly because they have been conditioned to ‘simplify’ requirements, partly because they don't think gets it.

A few years later, this company is saddled with a BI application, an ECM suite, a CRM package, and a bunch of other applications. What’s more, there is now a huge IT staff maintaining all those applications. However, the executive is no closer to solving the original problem that brought on all this investment. To crack that problem, this hapless executive (or their equally frustrated employees) must now run to all of the above applications and try to make sense of them. Some IT people don’t understand this, because they never face those problems. Of course, if pushed, they will profess an intellectual appreciation, but it is not part of their emotions or their DNA. Those that do get it are bogged down administering the complexity of the existing systems that were bequeathed to them.

This—the forced segmentation or compartmentalization of requirements that business users employ in talking to IT—is the subtle sense in which IT has indoctrinated their business colleagues into adopting IT-speak. Why else would someone in the business walk up to a developer and ask for one additional field to be programmed into their CRM screen?

If IT professionals actually sit in the hot seat running a non-IT business for a few months, their outlook would change. They might just build a business architecture platform that actually works, even if it runs on paper.

(It’s not too late to stop reading!)

Fortunately, whether through design or happenstance, we do have such a business architecture platform today. It is called BPM. It is the one platform that ties all these functional capabilities together and gives them a complete business context. How it accomplishes all this, and how it should co-exist or coordinate with these compartmentalized solutions and legacy systems (which do have specialized uses), are deeper issues.

In the past, ignorance and lack of technological sophistication were good excuses for proliferating the 'arrogant' attitude. But if you read this far, despite my warning, you now know about BPM. You have no excuse for not adopting it. Sorry!

BPM isn’t just one more application package. It is not BRMS. It is not ECM. It is not BI. It is not CRM. It is not ERP. IT doesn't matter. As Smith and Fingar say, "Business processes do."

And for that, let us be thankful.

(To learn more about what BPM is and what it does, sign up for a BPM Master Class!)

Posted by kirankg in | Permalink | Comments (2) | TrackBacks (0)

Let me expand on the intersection of ECM and BPM from my earlier post.

Enterprise content is basically of two kinds: (a) content that denotes knowledge of the what and the how of business operations (or processes, if you will); and (b) content that denotes the outcome or product of those operations or processes. The former includes price lists, business rules, decisioning rules, policies, organization structures, roles, compliance rules, product categories, business entities, etc. I call these the ‘knowledge artifacts.’ The latter are the actual transactional documents (such as loan applications, orders, and service requests) and several kinds of non-transactional documents (such as website content, email, and presentations). The set of knowledge artifacts is relatively static in size and functions as a Book of Knowledge for the company. In contrast, transactional documents are generated in huge volumes. They must be stored, indexed, searched, imaged, retained, retrieved, destroyed, and reported; these specialized capabilities and associated technologies are the domain of ECM. However, the Book of Knowledge is better served under BPM, because knowledge artifacts must be dealt with in the context of business processes. To take artifacts of knowledge out of the context of business processes and to manage them outside a BPMS makes no sense.

As far as ECM is concerned, Bruce Silver observes that there is considerable investment in content repositories. True, but there is even more investment in paper than in ECM. That doesn't mean companies should continue to proliferate paper, or that BPM doesn't have anything to say about that. ECM looks at the huge mounds of paper and electronic documents, takes that as an immutable fact, and tries to offer a solution for dealing with it. It addresses the symptoms, not the disease. There is nothing wrong with that, since the symptoms need treatment. But, with all the advances in technology, BPM questions (or at least, I do) why there has to be paper in the first place. I do not claim that this problem can be solved right away, which is why ECM and Document Management will continue to exist. Hopefully, after another twenty years, much of this mountain of data will be past its retention period, and will be mercifully incinerated or consigned to be bit bucket.

In the meantime, companies should employ BPM and Continuous Process Improvement to avoid generating unstructured transactional documents (paper & electronic) in the first place, and to store artifacts of process knowledge within process models. I know this is not possible in some areas because paper documents are legally more acceptable than electronic ones, but at least consider the option. Like the fitness mantra says, stop the insanity.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)