Column 2

At the last BPM summit, I had to duck out before the open research meeting at the end, so I was looking forward to this panel moderated by Daryl Plummer and including a number of the Gartner analysts here this week, primarily Diane Morello, Yvonne Genovese and Michele Cantara.

The format is that they put forward three strategic planning assumptions from the list of six put forward on Monday, then open them up for discussion amongst the analysts and with the audience:

Business people will become adept more quickly at business-IT alignment than will IT professionals, causing many It professionals to be shut out of BPM leadership. This is based on the assumption that business professionals speak the language of business, risk and money, whereas the overly technical perspective of IT reduces their credibility; Gartner thinks that job opportunities for IT professionals lacking business expertise will shrink by 30%. There were completely different reactions from different members of the audience: some felt that IT people are essential because of the complexity of the projects and the culture within organizations; others are seeing business people already taking ownership of BPM leadership; and one forward-thinking person said that there’s convergence between business and IT, and it will be necessary for people to have both business experience and IT skills, not one or the other, in order to be successful (based on the reaction from the Gartner analysts to this last comment, expect to see this on their predictions by next year, with 80% probability. 🙂 )

Through 2010, SOA, SaaS, BPO, open source, business application implementation projects that don?t make process integrity an integral part of the implementation will fail. Genovese went through some slides here rather than the less structured (and more interesting) conversation on the previous prediction. Funnily, she asked for the audience opinion on one point (if you place an order online, can you easily cancel it), then disagreed with our opinion since she felt that she needed us to agree with her in order to prove a point about lack of process integrity — not a great presentation tactic. She believes that process integrity comprises interaction integrity, transaction integrity and data/information integrity, but it’s not clear what is implied by the process integrity wrapper around the other three. As the argument between she and Plummer continued about how hard or easy it was to cancel an order online, the audience started to trickle out. Including me.

By 2009, less than 10% of BPM project revenue will flow to offshore services vendors. I ended up having to leave for a meeting before the discussion on this point started, but I would have been very interested to hear the justification for this. This is, of course, a very American perspective; those of us who live in other countries and work internationally have a different definition of what “offshore” means.

That’s it for this conference, except for a few meetings with vendors that I’ll blog about separately. Although there was likely quite a bit of overlap in the session material from the BPM summit back in February, there were enough concurrent sessions that I was able to attend many that were new to me. A few people — mostly vendors — commented to me that the content was a bit lightweight from a technical standpoint, but that might be a reaction to the higher proportion of business people in attendance.

We had two Gartner analysts for the price of one in this session on crafting a process vision and execution plan. My main interest here is how they’re advancing the business process maturity model (BPMM), but they started out with a more generic set of elements to create any strategic plan, including a BPM plan.

As Rosser pointed out, most organizations are still at level 0 (acknowledge operational inefficiencies), level 1 (process aware) with a bit of overlap into level 2 (intraprocess automation and control), with three more levels to go after that: interprocess automation and control, enterprise valuation control, and agile business structure. He went through a classification scheme for determining critical processes — typically those that impact the organization’s customers — then covered a business strategy framework for selecting strategic goals, mapping that through the drivers and strategy and on to how that can be accomplished with the appropriate business processes.

Olding took over at this point to discuss the specifics of a BPM plan and what it does for you: a process to achieve results, a message to the stakeholders, a plan for action, and measures for determining success. She then went through each of these four roles of the plan, first identifying a number of steps to take in creating the plan, starting with creating the vision (but an understandable and specific vision, not a buzzword-enabled sweeping statement), through the identification of goals, resources, measurements and other factors need to have a complete and detailed plan. She also emphasized the importance of the BPM plan being a living document that is updated as work progresses and factors change. Next is identifying the stakeholders (business, IT, executives and even vendors) and including the appropriate message for each of those stakeholder groups in the plan, which in turn defines the outline of the plan to be presented to the stakeholders. She then discussed the details of how to determine a specific timetable and resource allocation for the plan, and how to set the project objectives and metrics. Governance should be baked into the strategic planning process; for example, part of the BPM plan should be an independent post-implementation review that audits how well the objectives were met.

Strategic planning is an essential activity that needs the right people and some time to do the planning, but it shouldn’t stretch beyond about six weeks, and definitely shouldn’t happen in a vacuum apart from the business area affected. Olding laid out the critical success factors for strategic planning — strategic alignment, methodology, people, feedback, access, results evaluation, and time — and covered each of these in some detail from her practical experience in industry.

They finished up with some future predictions for BPM planning. First, closer links with enterprise architecture, especially business architecture; I completely agree with this, and have been pushing the link between EA and BPM since the beginning of my writings here (in fact, the name of this blog is based on the rather obscure and geeky reference to column 2 of Zachman’s EA framework, which defines process). Second, they see wider use of user-friendly process modelling tools; again, this trend has been advancing for the past couple of years, accelerated by many of the free downloadable process modelling tools from the BPM vendors as well as even simpler process discovery tools. Third is the greater use of repositories in order to facilitate reuse; I’m seeing this being enabled by some of the BPA and BPM tools now, although it’s slow to catch on in most end-user organizations. Lastly, leverage the benefits of SOA; again, this is enabled in the current tools, but the actual usage is lagging because of the immaturity of many organizations’ SOA implementations.

Aside from the one standard BPMM slide, there wasn’t anything about the maturity model; I was expecting to see Gartner starting to incorporate more BPMM concepts into BPM planning by this time. In fact, most of this was not specific to BPM at all except the final predictions: I think that Rosser and Olding are not specifically BPM experts, but more strategic IT planning experts, so they’re just putting a faint BPM spin on the research from their area.

Michael Smith of Gartner had a session on using performance metrics to align business processes with strategy. His area of expertise is performance management, and he’s found lately that business process improvement is a growing theme in that sector.

He started out by quashing the notion of best practice business processes: processes are so different between different types of companies that there isn’t a single best practice. [I think that there are best practices within industry verticals, but he didn’t seem to consider that.] He went on to say that business strategies are, in general, poorly defined, poorly understood and poorly executed, then went on to outline a process for developing a business strategy:

• Define strategic intent
• Define strategic objectives
• Identify performance metrics
• IT strategy and objectives
• Measures of IT performance

He thinks that the tough parts are the strategic objectives and performance metrics, and that these often end up being skipped over during strategic planning. However, there are some best practices around developing business metrics.

He organizes metrics into three levels: accounting metrics at the highest level, which are often regulated and audited; performance metrics, which are non-regulated but are key performance indicators for that industry; and analytical metrics, which are specific to the company but explain the performance metrics. It’s important to differentiate between performance metrics and analytical metrics, and not jump straight down to the fine-grained detail of the latter without considering the industry KPIs.

In order to determine the contributing factors to the financial metrics, it’s necessary to map the main business processes to line items on the financial statements; for example, the sales process maps to the revenue line, whereas the manufacturing process maps to the cost of goods sold line.

When developing metrics, it’s important to be both collectively exhaustive and mutually exclusive: have metrics that cover all areas of the business, with no overlap between metrics. Smith gave us some examples of metrics that they’ve developed that meet these criteria, showing how a business aspect (e.g., supply management) maps to a set of aggregate KPIs (e.g., operational efficiency), then each of those maps to one or more prime measures (e.g., cash-to-cash cycle time). He then went through some examples of high-level strategies and how to map them to the aggregate and prime KPIs, where each of these strategies may rely on KPIs from different business aspects. The key is to measure performance at the convergence of function and process: although most organizations establish metrics at the functional level and achieve great local optimization, it’s important to have metrics at the hand-off points between functions within a process, and on the end-to-end processes. Metrics can still be rolled up to a functional level to view departmental performance, but all can be rolled up orthogonally to a process level.

The whole process of developing these performance metrics is to recognize the relationship between strategic planning and business process management, and build the process taxonomy and performance management framework required to support that. With that, you can make a clear link between strategies and the actions required to execute the strategic plan. Gartner has some models to help get started with this, but Smith doesn’t feel that you need any complex tools to work this out.

I missed Justin Brunt’s webinar a couple of weeks ago on BPMN, so I stopped by his session today to see it in person. There’s a lot about BPMN elsewhere on my blog, including my recent BPM Think Tank coverage and the BPMN category, so I’m not going to go into too much detail about what BPMN actually is; in short, BPMN is the business process modelling notation, namely the graphical representation of process maps and some of the associated metadata, intended to be used by both business and technical users as a common vocabulary for describing processes.

Justin walked through all the BPMN object types and how they’re used, plus some multi-step examples to show how they all fit together.

Although there’s a lot more complexity that can be explored, he only had 30 minutes so this was a quick overview. Bruce Silver has a 90-minute workshop on BPMN tomorrow morning that will go into considerably more detail.

Michele Cantara is holding the session on the BPMS market, including key players and trends. I can tell that the straw poll that Daryl Plummer did yesterday is correct in terms of there being more business than IT people at the conference, since this session seems to be shockingly poorly attended. Maybe it’s just that this is the first session after lunch.

Gartner is now pushing the idea of integrated composition environments (ICE) as an expansion on a BPM suite: they position BPMS as one step on the way to an ICE.

Cantara shows the current Gartner representation of BPMS as a set of functionality that is available as a “single product experience”: process component registry/repository in the middle, surrounded by process execution and state management engine, model drive development environment, document and content mgt, user and group collaboration, system connectivity, business event BI and activity management, inline and offline simulation and optimization, business rules management, and systems management and administration.

She sees the BPMS market as having started in 2005, since prior to that, no vendor had all of this required functionality; in 2006, there were 19 of them (including a few that I have never thought of in this space or have never heard of, such as Graham Technology), and there’s another 5 as candidates for the 2007 BPMS market share analysis. The prediction is that 4 or more of these will be acquired by platform or application vendors within the next two years, so will drop out of the BPMS market — a bit of a weird statement considering that IBM and Oracle, which are clearly platform vendors, are still here and are considered the two largest BPMS vendors: why wouldn’t the acquiring vendors just be added to this list if they acquire the BPMS vendor?

There’s some pretty interesting conclusions to be drawn from a chart that she showed of the top 10 BPMS vendors and their comparative 2005 and 2006 market share: many of the vendors had their market share stay the same or even reduce, even though they increased their revenues, since the size of the market grew. Since IBM and Oracle, shown as the top two vendors for 2006 and non-existent for 2005, really skew the numbers: I suspect that they didn’t build that business in one year, but that Gartner reclassified a big chunk of what they do as BPMS and therefore “increased” the market size without it actually increasing all that much. This comes back in a later slide that shows a projection of the market size based on the 2006 numbers: since the market “grew” by 69% between 2005 and 2006, which I think is based primarily on Gartner reclassifying existing business rather than actual growth, another 40% is expected for 2007, then 20% year-over-year until 2011. Short of a whole new bunch of recategorization, I just can’t see the BPMS market tripling from $1.7B to $5.1B (which is the effect of those growth rates compounded over time) over that five year period. The overarching category of “middleware” (PPMW = portals, process and middleware) that includes BPMS is predicted to only double during that time, which looks conservative in comparison.

She showed another interesting chart that plotted business user-driven versus IT driven control against infrequent versus continuous change. BPMS’ fit best in business user-driven, continuously-changing processes, but may also be applied to any business user-driven process and any continuously-changing processes even though less integrated pure-play BPM products may also fit in these latter situations. For IT-driven processes that change infrequently, a BPMS is likely overkill.

She also looked at the four main BPMS buying patterns: automating a specific process, continuous process improvement, moving to SOA, and business transformation. Each of these has different types of buyers and different goals, which can mean quite different requirements for a BPMS depending on what’s driving the original purchase. Market drivers (e.g., compliance) and inhibitors (e.g., market share consolidation) also impact purchasing patterns.

Vendors that can’t play the entire BPMS functionality game that Gartner has defined can take a few different routes. They could concentrate on some best-of-breed functionality that they offer, and partner for the remaining functionality (which as recently as a year ago, was Gartner’s definition of a BPMS). They could focus on specific process-based applications for a small number of verticals rather than a cross-industry horizontal suite. They could focus on an integrated service environment (ISE) with service assembly and some degree of development in a model-driven approach. Lastly, they could focus on a business process platform (BPP) approach.  Cantara discussed the different situations in which you might choose one of these types rather than a full BPMS, and showed some indicators for telling whether a BPM vendors is moving in one (or more) of these directions; in some cases, the distinction between these four routes are pretty vague.

Her final recommendations really position BPMS as a development platform, which is more accurate than not, but not necessarily the message that the BPMS vendors give to the market. She also pointed out the critical role of round-tripping capabilities between modelling and execution environments.

I thought that they’d have a new BPMS magic quadrant out by now, but apparently it’s due next month, so stay tuned to Gartner for that.

The next session was on measuring processes in real time, namely business activity monitoring (BAM), and how it needs to be considered up front as processes are being design and implemented.

Gassman started off with a few definitions — BAM, real-time BI, operational BI, and process-driven BI — with some pretty fuzzy distinctions between some of these, especially in these days of converging functionality in the BI products. He then defined the goals of BAM: to monitor key objectives, anticipate operational risks, and reduce latency between events and actions. From an implementation standpoint, BAM is typically a real-time dashboard that’s integrated with BPM in some way and provides alerts in the context of the processes within the BPMS, but also links to more traditional BI functionality such as predictive and historical reporting. He also makes a distinction between more passive data displays that require someone to be looking at a dashboard in order to detect the condition, and sending an alert when a specific threshold condition is reached.

He talked about a number of different real-time analytic techniques, including process monitoring, logistics optimization, situational awareness, complex event processing, track and trace, and anticipate and react. Of all of these, CEP is the up-and-coming new technique (to be covered in the Event Processing summit that follows on after this BPM summit for the remainder of this week) that uses pattern recognition and matching, whereas the others are based on pre-defined metrics. Looking at it along another dimension, anticipate and react is a predictive technique that uses past and current data to predict the future state, whereas the others primarily display data or events that have already occurred.

Without monitoring, it’s difficult to detect when something has gone wrong in a business process; with BAM, not only can specific business questions be answered based on measurements, but analytical techniques can be applied to detect correlations, report on impacts, detect root causes, and make some predictions. This, in turn, feeds into the broader scope of corporate performance management.

He went on to discuss the synergy between BAM and BPM, and how BI (which he considers to be a different type of functionality) can be tossed into the mix to provide operational decision-making and even trigger new processes, on top of the “awareness” that comes from BAM. Although BAM and BPM are a natural fit, BAM doesn’t just come from the BPM vendors and isn’t just for BPM: some BAM tools are focussed on or part of business/enterprise software and BI suites. Having BAM integrated into the BPMS has some advantages however; the monitoring can be modelled right along side the processes, and drill-downs from the dashboards can go directly back to executing processes. However, many of the BAM products that are part of a BPMS are less functional than their general-purpose counterparts, and may be limited to monitoring just the business processes and not the larger business context. Because of that, Gassman’s final recommendation is to look for a BAM product that can be integrated with a BPMS but can also run standalone.