Column 2 by Sandy Kemsley

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.

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.

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.

Yvonne Genovese opened the day with a discussion on business applications through 2010 and the major changes impacting process environments. Her main focus is on enterprise applications, not BPM, but these applications have a huge impact on process management in any organization.

Her first strategic planning assumption: “By 2009, all leading application platforms will support design and deployment of events, complex events and services in a common, integrated context enabling users to create their own BPP [business process platform].” She followed this up later in the session to discuss how the enterprise application vendors will tend to try to increase the footprint of their application with customer organizations by expanding out to use their own middleware and other platform pieces.

No surprise, she also sees enabling process innovation and agility plus incorporating information into the processes will be a key for success: this is the intersection of BI and BPM that’s starting to occur more often today.

She discussed the problems today with fulfilling the dream of using services to build business applications: in reality, many of the services don’t match up all the well, and it’s not just plug and play as the application vendors might have you believe but still requires some amount of integration. However, by 2010, she sees the application environment becoming more service oriented such that services can be more universally used with less concern about the specific architecture of the services. That allows some parts of packaged applications to be more easily replaced by composite applications or outsourcing with much less custom integration work than is now required. For a process environment, this means more flexibility in sourcing processes or portions of processes, and the packaging and pricing will reorient towards operational processes.

As this happens, control will start to shift from vendors — from the environment of a primary vendor ecosystem — to the customers, who create their own ecosystem by selecting middleware, process components, SaaS, outsourcing and other building blocks. Many of these decisions also shift the control from IT to business within an organization, but it’s very necessary to distinguish between the processes that provide an organization with their competitive differentiation when selecting what to outsource or even move to SaaS. For example, SAP is announcing this week that they’ll have an entire SaaS platform for customers to use, but it’s not as functional as the full on-premise suite that you would buy from them directly, nor will it be integrated or customized for your environment to the same degree.

Getting back to the recurring theme of people within the process that I’m seeing this week, she also stated that the focus will move from process efficiency to arming the information worker. In fact, she states that by 2010, more than 50% of collaboration and user productivity interactions will be integrated with process technologies such as BPM — this addresses not just the transactional human interactions that occur in many automated processes now, but also all those messy, event-driven, less structured human interactions that are almost purely manual now.

Genovese went through three different process governance models — safe and steady control, cautiously dynamic, and aggressively predictive — and discussed the pros and cons of each as well as their basic characteristics.

We then arrived at this week’s first explicit definition of what Gartner means by a business process platform:

The business process platform is a combined IT and business model that enables enterprises to accommodate rapid but controlled business process change through the use of integrated process composition technologies and the delivery of reusable business process components and their management.

Whereas at the conference in February, they were saying that the large vendors would be creating BPPs and organizations would be buying them, it now sounds like they think that customers will be rolling their own BPP from best-of-breed components that best fit their environment and business needs, and assembling a virtual business services repository. In this context, it’s especially important to build or buy services with reuse in mind.

Genovese finished with a review of some of the large vendor’s BPP architectures, including a view of their BPP stack, and a summary of their strategies, strengths and challenges: Oracle, SAP, Microsoft and IBM. Her final recommendation for end-user organizations brought home why it’s important to understand what these vendors offer:

This era of change will require many users to re-platform all or some of their process environments; therefore, understand how the current business applications changes affect your environment now.

Good advice.

Another of the vendor sessions, and I’m sitting in on the BEA session, at least for Jesper’s half of the talk (I’m still torn on whether to stick around for the second half or scoot over to the Savvion user panel).

BEA is really realigning their message to put equal weight on their Enterprise 2.0 platform (which I covered extensively at their conference earlier this year) along with BPM and SOA.

Jesper started with a bit of a BPM market review, somewhat unnecessary given the information from Gartner that we’ve seen so far today, but quickly moved on to the most common challenges that they’ve determined based on a recent survey with their customers: inflated expectations (which relates directly to the position of BPMS as shown on the BPM hype cycle that Janelle Hill showed in the previous talk), organizational barriers, deployment complexity, user acceptance, and lack of skilled business analysts (to which Hill also referred).

He covered some best practices such as building a centre of excellence and using an iterative/agile methods, and discussed a matrix for prioritizing BPM implementation projects based on the cross product of their complexity and their process impact: start with the simplest process that has the least impact, then move along the direction of increasing process impact, then return to low-impact, high-complexity processes before finishing with high complexity and process impact. He showed a sample of a prioritization matrix with various processes for an organization plotted out by complexity and impact, which would offer a good guideline for planning the implementation of BPM projects.

In their lifecycle assessment survey (I believe that this is the one that they have online on their website), they’ve seen that there’s a measurable impact of SOA on the success and speed of BPM projects. This isn’t surprising, but it’s good to see some empirical data to back it up.

As a follow-on from some of the earlier comments from today, Jesper also sees that the future of BPM will move beyond the standard type of transactional flows that are common today and into more collaborative interactions and decision-making that involve ambiguity and require tacit knowledge, often as part of the same processes. That goes back to the same message that the people in the process are becoming more of the focus for BPM; it’s my opinion that we’ve done so much in automating tasks and streamlining transactional processes that a lot of the heavy lifting has been done here, and the new and interesting stuff is going to be turning back to look at the messy human-facing processes that haven’t been touched by BPM yet.

I did drop over for the Savvion panel in the second half of this session, but it was fairly unstructured questions from the audience so difficult to blog although interesting to attend.

The lunchtime address is always a tough one: the speaker has to talk over the sound of clashing cutlery, and half of the audience has to twist around in their chairs to see the speaker and slides, but Gartner tends to keep these short and painless, and features entertaining speakers such as Alan Trefler of Pegasystems.

I was chatting with the others at my lunch table before the talk began, and the person beside me asked my views on some of the vendors. We talked about the pros and cons of product convergence, and I used business rules as an example of something that is sometimes baked right into a BPM product — as with Pega, which is based on a rules engine — but may be more versatile if available as a separate platform. I made a comment along the lines of “just wait, Trefler will tell us why it’s necessary to have rules as part of your BPM”.

Trefler’s focus was on the rhythm of business, the things that can kill that rhythm, and how to fix them:

• Rhythm killer #1: the specification gap, where there’s a huge gap in time and understanding between the business developing requirements, IT developing specifications, then the business signing off on these specifications with the full knowledge that any changes are going to require an equally arduous change order process. The solution: directly capture objectives in the execution environment, that is, use tools that allow the business to create their own models, and have those translate directly to execution.
• Rhythm killer #2: exporting models, which causes the models to be ripped out of the hands of the business and tossed over to IT to import into the execution environment, with no round-tripping. The solution: automate the programming, that is, use a zero-code environment that generates the executable model from that created by the business, either in a shared model environment or in a fully round-trippable environment.
• Rhythm killer #3: no reuse of components or models. The solution: think about enterprise sharing and reuse upfront and design it into the system from the start. Trefler considers the secret of this to be using a declarative rules-based paradigm, of course, proving my earlier comment in his final sentence.

This analyst panel was moderated by Daryl Plummer, and included Shafqat Azim, Eric Deitert, Janelle Hill and Michael Smith. Azim is with the consulting arm of Gartner and focusses on IT process improvement, whereas the other three are from the research side, and Plummer asked them about three key issues:

• What is the value of a process-rich strategy?
• How hard is it to align a vision for process with a business strategy?
• What are the important topics one needs to master when creating a process-rich strategy?

The first issue was defining “process-rich strategy” as the operationalization of a business strategy, such that the causes and effects of individual parts of the process are well-understood by the process participants. As the discussion continued, it became clear that “process-rich strategy” is just the current relabeling of having a process-centric view of your organization, with a strong focus on dissolving some of the boundaries between functional silos in order to perform end-to-end process optimization.

One value of a process-rich strategy is to put individual business users in the context of the overall business strategy so that, for example, a call centre operator understands his position as a key customer touchpoint and how his actions impact the end-to-end business process; this, in turn, encourages the individual workers to look for ways to improve the overall process. By putting individual functions in the larger context, and providing visibility into the end-to-end process, improvements tend to address the entire process rather than focus on local optimization. Hill pointed out that team sports are a great analogy for business process visibility: everyone on the playing field can see what everyone else is doing, and understand exactly how their actions contribute to the overall team success. Athletes are motivated by their own personal success, but are also strongly motivated by their team’s performance since it’s great from a career standpoint to be on the winning team and to be seen as team players, not just to score all the points themselves. In some sports, team play is rewarded explicitly, such as tracking assists for hockey players as well as goals, since the game just doesn’t work without it. Similarly, the key to motivating business users to look for ways to improve the overall business process is to provide some reward for them. Sometimes, that’s financial (bonuses and overall corporate profitability resulting in increased wages); sometimes, it’s merely public recognition of the contribution; sometimes, it’s recognition of an individual’s ability that improves their overall career path.

There was a big focus on agility in this panel, and how both management and technology agility must be embedded within the business strategy. Management agility is the facility to think about new ways to do something or even a completely new business function, whereas technology agility provides the ability to make those thoughts a reality. Cause and effect within processes must be well understood in order to remain agile.

Process metrics and how they contribute to visibility was also a major area of discussion: if you don’t identify specific metrics for your business processes and start capturing that data, then you can’t analyze that into the higher-level process measurements that are required to see how well the business processes are performing and therefore optimize the processes. Smith will be doing a session tomorrow on how performance metrics help to align business processes with strategy for more detail in this area.

At the end of it, it comes down to the ability to execute business strategy: a process-rich strategy combined with the appropriate technology are more likely to see success in making business strategy a reality.