I am back from a hectic round of travel: conferences, BPM Master Classes, client meetings, and vacation. I attended both the SharedInsights BPM conference in Ft. Lauderdale, FL, and the ISSSP conference in Scottsdale, AZ (yes, we evangelists live a tough life!)

At the SharedInsights’ conference, Roger Burlton, the conference chair, opened the proceedings with his keynote, “Business Process and Beyond.” One of his standard slides is his ROI graph. When I saw it a few years ago, I grew enamored with it. I think it is a really neat way to communicate the key drivers of ROI. The traditional MBA approach is to focus on the Y-axis, the money: reducing costs, improving productivity, increasing market channels, product innovation, and so on. For many companies, this is approaching the point of diminishing returns. Roger highlights the X-axis, the time. The competition is now in time-to-market, time-to-profit, and time-in-profit. This is nothing new, of course, expect for the increased focus that BPM brings to the X-axis. BPM’s role in improving the ROI from time, the “Return on Time (ROT)” if you will, is leading to ‘aha’ moments for people when presented this way.

At our BPM Master Classes, I introduce two other levers of profitability: the probability of delivery, and the probability of profit. The first highlights the very high failure rate of projects (60-70%), and the second highlights the challenge with delivering what the customer really wants (and is willing to pay for).

Just when I thought I had finally absorbed Roger’s ROI model, he comes up with another. This one is NICE (of course, it is nice, but that’s the acronym). Picture a 2 X 2 matrix. The X-axis represents ‘Understanding’ of the problem domain (values are: ‘little,’ and ‘lots’). The Y-axis represents ‘Detail’ of information about the problem domain (values are: ‘little,’ and ‘lots’).

When we have little detail and little understanding of the problem domain, our analysis of the problem is going to be ‘Naïve.’ The usual reaction to this is to acquire lots of data, i.e., a data warehouse or data mart project. However, lots of data with little understanding makes the whole problem domain incomprehensible (the 'I' of the model). This is congruent with my own experience, as I covered in my article ‘Re-Energizing BI with BPM’ in Data Management Review, April 2007.

It is possible to gain a understanding from an ocean of data, thus moving into the third cell of Roger’s NICE model. In this cell, the world is a complex (‘C’) entity, demanding tremendous amount of work trying to keep up with change. In my opinion, this is a terrible spot to be in, with data and information overload. More BI (as in the traditional approach) is guaranteed to take you here. The issue isn’t simply more understanding, but more understanding at a reasonable price.

The ROI for understanding comes in cell 4, ‘Elegant.’ Here, only the right information is delivered in a way that is intuitive, actionable, and relevant for solving critical business problems. This is the cell that is the result of applying Occam’s Razor diligently to a Complex model of the problem domain. Since it is impractical to insist that a company always reside in the ‘Elegant’ cell, ideally it should be able to quickly move through the first three steps (Naïve, Incomprehensible, and Complex) to come and rest in an elegant state. Those three phases should be no more than short-term perturbations in the system, while ‘Elegant’ should be the homeostatic condition that a company must aspire to.

The NICE model is the high bar that BPM must vault over to be truly useful.

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

...especially given that I live in Milwaukee?

I just got back from a hectic tour in France and Germany. We held a BPM MasterClass in Frankfurt and Paris. This is the second time I have been in both cities; the first time I stayed at Sofitel within a stone’s throw from Versailles, and did not get a chance to visit it! This time, I did not get a chance to look around Frankfurt, but Paris offered a respite. We did a quick tour of Notre Dame (awesome!), swung by the Eiffel Tower (both during day and night), and plenty of walking through the streets. webMethods has an office next to the Arc de Triomphe. Paris in April – one cannot complain! Frankfurt ist auch eine schöne Stadt (Frankfurt is also a lovely city). 90 mph in a Mercedes Benz cab on the autobahn in Frankfurt is an experience!

There were a couple of interesting differences between audiences in Europe versus the US. For one, over 90% of those who registered showed up for the class; we had to scramble around to find extra chairs! Second, they all spoke at least two languages, more often three and even four. We English speakers were cautioned to stay away from idiomatic expressions and jokes based on the American context; apart from that, their fluency in English is astonishing. I wrongly assumed that the language barrier would prevent participation, but there was plenty of dialog; just as much as in a US class (and perhaps a tad more than the interaction we got at a couple of US locations).

The European attendees seemed less exposed to Six Sigma and Lean compared to their US counterparts; however, they showed greater appreciation for the concept of discipline. One favorite question I pose attendees is “Does their company have a Project Management Office, and if so, what is the attitude of the rest of the company towards the PMO?” I get the classic roll of the eyes: PMO is viewed as unnecessary bureaucracy (except by the PMO folks, of course). In an environment that demands agility and rapid execution, any hint of oversight, process, or tollgates is viewed negatively.

Not so in Europe. They seemed to appreciate the need for discipline. They do not make the mistake of confusing discipline for bureaucracy. Discipline means being responsible, having a plan, and sticking to it. Good financial traders know this. It turns out that the key to superior financial performance is to pick a decent trading strategy and stick to it without second-guessing it. Research shows that changing horses midstream is a sure way to get wet and miserable.

The best companies speak of “responsible growth,” meaning, how to grow shareholder value without compromising on ethics or taking on irresponsible risk. For public companies, governance has additional regulatory implications. But the concern remains, how do we take the concept of discipline and make it an enabler of agility and execution? How do we take out bureaucracy? One, by making discipline an integral part of what we do, so we make the time to do it. For example, no one complains about having to brush teeth every day. Two, by making space for it. Traditional project methodologies waste a lot of time discovering the current state of the business and by documenting requirements in different formats to suit different audiences.

When process governance is an integral part of BPM, it enforces this discipline. Governance becomes a seamless part of how projects are done and business operations are conducted. By eliminating the need for endless documentation and translation between various models of requirements, BPM also makes space for responsible behaviors in project execution and business operations.

Does lack of a formal Six Sigma or Lean methodology seriously hamper the quest for continuous process improvement? Hardly. While the formal methodologies are extremely useful, we are now seeing a move away from overly relying on the heavy frameworks towards a lighter approach. The caveat here is to adhere to the spirit of Six Sigma and Lean, and not to slide into bad techniques. Richard Douglass, webMethods’ VP of Global Industry Solutions, and an expert on Supply Chain, Manufacturing, and Six Sigma, spoke of continuous process improvement by using the principles of the formal methodologies even when not using the whole toolkit. The specific ‘get started’ strategy we advocate is to measure the state of your business first, and use real data and metrics to drive the discussion around process improvement.

These are some of the key messages that we will be delivering in Toronto next Tuesday. Joining us will be Yvon Berube, President of Logimethods, Inc., our systems integration partner in Canada. Neale Partington of SaskTel, our joint customer, will be sharing their experience implementing webMethods’ BPM. If you are in the general area of Toronto, we’d love to see you at this event.

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

At Gartner’s BPM Summit last month in San Diego, everything went fine until the last Gartner analyst left a lasting impression at the last session of the last day. Simon Hayward, VP and Gartner Fellow, who helped kick off the BPM Summit, has the dubious honor of also sounding its death knell. His bombshell? The prediction that, to paraphrase, “By the year 2012, BPM will be subsumed into major applications.” I forget the exact probability he assigned to this scenario, but it was precisely between 0.7 and 0.8 (both inclusive).

Predictably (i.e., with probably 1.0), there was violent disagreement from the audience. Their cries of “No!” reverberated in the auditorium. There was applause for attendees who spoke in protest. I am sure there was concern among the participants about the discipline of BPM itself vanishing (and with it, boondoggles to sunny climes), and among the vendors on the implied demise of their own companies. If Simon’s intention was to end the conference on a vigorous and memorable note of controversy, he definitely succeeded.

Now, I can’t predict the future as accurately as Gartner. I don’t know if BPM functionality will indeed be subsumed under applications from the largest app vendors. What I do know is that if it does happen, it will happen only if one of the following conditions is met:

one, a major app vendor will take over all the applications and supply one huge ERP that covers all businesses end-to-end for all the companies (regardless of size) on the entire planet and the space station;

two, app vendors will package BPM-like functionality without truly understanding what it means, thereby fooling themselves and all of their customers all the time.

Your guess is as good as mine (or Gartner’s) on the likelihood of these scenarios happening.

Conceptually, though, suggesting that BPM functionality will reside in apps is like saying operating system algorithms will be subsumed by applications (i.e., that OS functionality like system resource management, job scheduling, load management, memory management, etc. will be built into each and every application). Talk to your app vendor and ask them if they’d be willing to develop OS functionality (as in Unix and Windows) directly into their apps. Also, ask them if they’d be willing to create their own database engine rather than connect to an existing, independent DB engine. How about their own reporting solution?

BPM is to business processes what the OS is to IT programs: BPM is a process operating system. Just as an OS provides a ‘system process space’ context for pieces of running code, BPM provides a ‘business process space’ context for applications. What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance (the analogy to the OS should be clear: an OS collects and displays system metrics, such as memory utilization, resource handles, CPU utilization etc.; for the design of applications, it provides an API to applications for accessing system level resources; it defines the system semantics through such APIs and through the use of semaphores, threads, handles, sockets, pipes, devices, etc.; it ‘responsibly’ manages the use of system resources to eliminate contention, resolve deadlock, terminate hanging processes, implement prioritized scheduling, etc.) Imagine an app vendor having to build this entire infrastructure (whether OS or BPM) into each application!

BPM provides the abstraction layer that is common to all applications that must function as responsible citizens in the corporate world, just as an OS provides an abstraction layer to all applications that must reside and play nicely together on a computer.

People attend BPM conferences because they see problems that are not (and cannot) be solved by their current stack of applications (CRM, ERP, G/L, etc.) These apps are in a terrible mess in their own right today because they are not designed according to SOA principles (some would question if they were designed in any way at all). App vendors have their work cut out in trying to fix application level problems. Why would anyone egg them on to take on functionality that is an order of magnitude more sophisticated and more abstract?

Let us hope that this is one Gartner prediction that will never come to pass.

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

"Understanding Business Process Management & the 'People' Factor of Process Change"

This is the first of three e-seminars on business process management sponsored by Talisen Technologies. I have been invited to join Howard Webb (Principal, the BPM Group) in this first e-seminar to discuss the “people aspect” of BPM and how change leaders are enabled by BPM adoption. The next two sessions will feature a discussion of process and technology aspects of BPM.

Change management and people issues are a neglected aspect of BPM adoption. In the BPM Master Classes that webMethods conducts, I frequently quiz the audience on their change management practices. Most technologists don't realize the importance of this. They assume that the cool technology of the day will win the hearts and minds of the business folks. In reality, business executives are besieged by change: from customers, competitors, and economic conditions. Many of them are barely coping with it. Asking them to deal with another change—a pretty radical one at that—is rather risky without employing some change management techniques.

While Howard will cover how to get support for BPM and link it with other process improvement efforts, I'll focus on the implications on an organization of implementing BPM.

Register here to attend this webinar on March 16, 2007, at 10:00 am CST.

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

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)