Continuous Innovation With A BPM Program Wins Over The Sporadic Tinkering Of Projects

In her presentation at Gartner BPM 2013, Elise Olding addressed an issue that ties in with my presentation last week on BPM maturity and centers of excellence: BPM’s real value is in becoming an enterprise capability, not through occasional BPM projects. From a BPM maturity standpoint, that means getting beyond levels 1 and 2, where you’re just doing isolated projects, and crossing the chasm to enterprise BPM initiatives that permit greater innovation.

She gave the audience a quiz on how BPM is being adopted within their organizations: Is there a 2-year vision for BPM? Is there a link between BPM and strategic vision? Are your projects focused on delivering measurable business benefits? Are you communicating why process is important? Are you constantly tweaking your BPM techniques? Are you innovating and constantly improving? I’m not sure how much of this is just because I’m firmly ensconced in the BPM echo chamber, but I’m really seeing BPM being put forward as a driver for innovation; this is the “big picture” BPM that is really about the methodologies and mindsets, not just the technology, but technology plays an important role. If you’re stuck on projects and technology, then BPM just becomes another silo.

Olding is much less focused on BPM technology and more about organizational change, so she brings an important point of view on the mindset of the individuals and the organizational culture required for change. Her suggestion is to start thinking like a startup (presumably a startup that is not wallowing around in a glut of VC cash), where every effort has to be directly linked to some value to the organization. To ensure that you don’t get trapped in the project mentality, don’t just solve the immediate problem: drill in to find out the motivations behind those problems or desired changes to see the bigger picture. Her technique involves asking “why” several times in succession (which appears to be effective but does remind me of someone’s five year old), moving from a tactical problem such as “we need to reduce costs” to a more strategic “we need a better strategy for integrating our recent acquisitions”. Also, consider that best practices are really standard practices, and you don’t have to slavishly do what your competitors do, especially if you want to differentiate yourself in the market.

She finished with some case studies of companies that have gone beyond BPM projects to full-on programs, such as multi-nationals that were able to leverage locally-created solutions worldwide, and had some final recommendations:

Stop driving efficiency, tinkering, and mapping all processes.

Start enabling effectiveness, innovating, and defining outcomes.

Business Architecture Bridging Strategic Vision And Operational Excellence

I made it to the Gartner BPM Summit 2013 in Washington DC today just in time for the 11am session that Betsy Burton gave on bridging the gap between strategic vision and operational excellence with business architecture (BA). I like her view on this: strategic vision really isn’t much good unless you have a plan (or at least a direction) for how you’re going to do it. She points out that most organizations don’t execute on their vision — only about 10% if you believe the studies by Hammer and others — and you’re not going to get there unless along with vision, you also define implications, constraints, risks and interdependencies. Business strategy, which is a big part of business architecture, requires a diagnosis, guiding policy, coherent actions and target outcomes. I also like her distinction between “deliberate strategy” (that which is foreseen and planned) and “emergent strategy” (that which happens in response to actual conditions, a.k.a., “how we get stuff done”), although I’m not sure that I’d consider the emergent part to be strategy, strictly speaking.

She showed a good example of a business capability model that had been developed for a financial services firm, where capabilities are “things the business does”, not processes or departments. Overlaid with that was color coding showing the level of investment to each capability, and bolding to show the capabilities with strategic importance, plus physical grouping of capabilities related to a specific business goal. This gives a view, on one chart, of how the business vision is aligned with capabilities and spending. For example, in the group “Self and Service Products” were six capabilities. Once of those was “Onboard Customers”, which was bolded to indicate that it’s of strategic importance, but is white to indicate that it is getting only a minimal amount of investment. Then, overlaid on that, she showed how processes intersect with capabilities by adding numbered bubbles to indicate which process impacts each capability. Keep in mind that a process can span multiple capabilities, and a capability may require multiple processes. So that Onboard Customers capability intersects with A1, an account management process, as do 10 other capabilities. Next, she overlaid information sources and consumers and their linkages, that is, which capabilities create or consume information from other capabilities. As you add in the application portfolio, the inconsistencies in the architecture start to emerge, and low-risk, non-strategic capabilities are exposed as targets for cloud or outsourcing.

Gartner provides a classification for applications (their Pace Layering): they’re there for innovation, differentiation. or for record (commodity). Extending this to the capability map allows the processes and capabilities to also be categorized this way. To quote her presentation notes, “processes associated with innovative business capabilities will be more likely to change, will be more complex and potentially high value.” This identifies processes that really drive the business growth and goal achievement. Making the link between capabilities, processes and applications, the impact on people and processes of changing capabilities and swapping out applications becomes obvious.

Since this is a BPM conference, she has to make links to what this means for BP professionals, and ended up with some specific recommendations for BP directors, starting with “work with your EA team to understand the role of business architecture”, and understanding the link between BA and BPM. I’m impressed with the level of integration that she’s made between BPM and BA, and provided some good ideas on how to connect these up as part of the business strategy.

Operational, Transformation and Technical Roles for Successful BPM Projects

My first post from the Gartner BPM conference in Baltimore this week; to be honest, there hasn’t been all that much so far that has inspired me.

Michelle Cantara, who focuses on organizational issues related to BPM, spoke about the roles required for successful BPM projects. She had four main points:

  1. It’s difficult to find BPM-skilled resources: there’s a shortage of skills not just within some organizations, but in the market in general. In many cases, BPM is not a full-time job for someone within an organization, but a set of skills that they need to apply in the context of other work.
  2. Not all projects require the same BPM skills sets. If you look at the Gartner BPM “sweet spot framework”, which is a quadrant with frequency of process change (low to high rate) along the horizontal axis and responsibility for process change (IT to business) along the vertical axis, they show three main usage scenarios for BPM (the lower left quadrant is considered not necessarily a good fit for BPM). In the upper left quadrant, for example, where BPM is used for standardization and manageability, process visualization may be a key skill that is not as important in the other quadrants. In the upper right quadrant, which is the sweet spot for BPM, round-tripping capabilities and sophisticated process governance are important skills. In the lower right quadrant, where BPM is used for IT agility, model-driven development and other technical skills are most important.
  3. Those skills sets are not necessarily what you already have in house for other projects, although if you take a look around, you might find some of the required skills in unexpected places. For example, influential and collaborative people can be leveraged for transformational skills, while technical skills may be coming from the business community. There is a wide variety of skills and skill levels across each of transformational, operational and technical skills.
  4. Transformational and operational capabilities are critically important; too many organizations focus purely on technical skills.

She showed an ideal BPM organization:

  • A business process competency center (aka COE) reporting to an executive steering committee, and containing a business process champion, business process director, business process consultants, business process analysts and business process architects.
  • An enterprise architecture program office, also reporting to the executive steering committee (not IT), working together with the BPCC.
  • The process owner, who is responsible for improving business processes related to the corporate strategy.
  • One or more BPM project teams, informed by the BPCC, and including an executive sponsor (linked to the process owner) and a BPM project manager.

The most critical roles are the process owner (a senior businessperson responsible for the end-to-end process performance), the business process director (business or IT background, but with a blend of all skill types, responsible for leading the BPCC and ensuring its adoption throughout the organization), the business process architect (business or IT background, a transformational role that liaises between EA and BPM, and establishes BPM governance and standards) and the business process analyst (business or IT background, responsible for modeling, designing and documenting processes).

She also defines a business process consultant as a senior person who can fill competency gaps in transformational, operational and technical skills; although I often work in the business process architect role for clients, this is probably a better description of what I do, as much as I dislike the word “consultant”.

She walked through five scenarios for how BPM is used in organizations, outlining some tips and pitfalls for each. For example, in the “visualize and rethink the process” scenario that fits into the category of using BPM for standardization and manageability, she mapped out the key skills required from each of the roles, such as process modeling for the BP analyst.

She finished up with some best practices for hiring and managing BPM resources, including:

  • Overhire, since senior, experienced people can play multiple roles
  • Establish decision guidelines so that it’s clear which types of changes need to be approved by whom
  • Align to key business goals
  • Leverage executive influence to get things done expediently

Overall, some good pointers for any organization implementing BPM.

BPM Success at BlueCross BlueShield of Tennessee

Rodney Woods of Tennessee BCBS started out talking about their 18-month history with Pegasystems SmartBPM by stating that you would have to pry Pega out of his cold, dead hands to get it away from him.

His laws of BPM success:

  1. The most important activity in business is improvement: improvement ensures competitiveness; your job is to drive improvement; if you improve the right things, in the right sequence, your business will take care of itself.
  2. Setbacks are not failures; failure is staying the same. Success requires setbacks; winning daily firefights is not progress.

There are four areas of improvement to consider: profit, product, process and people. His key is to make these sorts of innovation second nature, so that they occur routinely within your organization.

He had some good points about identifying the right BPM project, including:

  • Make sure that it’s related to a key strategic business issue: e.g., not just process efficiency, but tied to more effective customer service
  • Get customer and stakeholder input on the issue
  • State the problem as threat or need, not a solution
  • Define the process owner and key stakeholders
  • Focus on the process that is most critical and/or contributes the most

Most of his comments were about organizational issues, not technical issues: strategy, reporting relationships, continuous improvement, and executive support. Many of these were not specific to BPM projects, but any potentially transformational business-technology project. In fact, except for his initial comment, he didn’t really talk about their Pega solution at all; instead, lots of great advice regardless of your technology selection.

That’s it for me at the Gartner BPM summit 2011 in Baltimore; there’s vendor hospitality suites tonight and a half-day of sessions tomorrow, but I’m headed home after a week on the road.

The Great Case Management Debate

With a title like that, how could I miss this session? Toby Bell (ECM), Kimberly Harris-Ferrante (insurance vertical) and Janelle Hill (BPM) took the stage for what was really a live research session rather than a debate. Is it a process pattern covered by BPM? Is it functionality within ECM? Is it an industry-specific vertical application? Gartner is still evolving their definition of case management (as are many people), and currently publish the following definition:

Case management is the optimization of long-lived collaborative processes that require secure coordination of knowledge, content, correspondence and human resources and require adherence to corporate and regulatory policies/rules to achieve decisions about rights, entitlements or settlements.

The path of execution cannot completely be predefined; human judgment and external events and interactions will alter the flow.

Harris-Ferrante said that we need to first create industry-specific definitions or examples of what a case is, then this definition can be presented in that context in order to make sense.

Bell made the distinction between content-triggered automation (e.g., paper invoice scanning and processing), collaborative content-rich processes (e.g., specific projects such as construction), and case management: there’s a bit of a spectrum here, based on a variety factors including cost, complexity, people involved and time to completion. Case management is distinguished from the others by (human) decisions supported by information: Hill felt that this decision-support nature of case management is a defining feature. Harris-Ferrante talked about the cost and risk factors: case management is used in situations where you have compliance requirements where you need to be able to show how and why you made a particular decision. She also pointed out that rules-based automated decision is really standard BPM, whereas rules-supported human decisioning falls into case management.

They showed a slide that talked about a continuum of business process styles, ranging from unstructured to structured; looks vaguely familiar. Winking smile Okay, they use “continuum” rather than “spectrum”, have five instead of four categories, and put structured on the right instead of the left, but I am a bit flattered. Their continuum includes unstructured, content collaboration, event driven, decision intensive, and structured activities; they went on to discuss how case management is the most common example of an unstructured process style. I found that wording interesting, and aligned with my ideas: case management is a *process* style, not something completely different from process. Business process management, in its most generic form, doesn’t mean structured process management, although that’s how some people choose to define it.

Looking at the issue of products, they showed a slide that looked at overlaps in product spaces, and puts BPM in the structured process/data quadrant, with case management far off in the opposite quadrant. As Hill points out, many of the BPM vendors are extending their capabilities to include case management functionality; Bell stated that this might fit better into the ECM space, but Hill countered (the first real bit of debate) that ECM vendors only think about how changes in content impact the case, which misses all of the rules and events that might impact the case and its outcome. She sees case management being added to ECM as just a way that the relatively small market (really just four or five key vendors) is trying to rejuvenate itself, whereas the case management advances from BPM vendors are much more about bringing the broad range of functionality within a BPMS – including rules and analytics – to unstructured processes.

Hill stated that Gartner doesn’t have an MQ for case management because there are so many different styles of case management: content-heavy, decision-heavy, and industry-specific packaged solutions. Besides, that way they could sell three reports instead of one. Not that they would think that way. Harris-Ferrante discussed the challenges to case management as an industry application, including the lack of shared definitions of both cases and case management, and Bell stated that buyers just don’t understand what case management is, and vendors are rejigging the definition to suit the customer context, so aren’t really helping in this regard.

In spite of stating that they don’t have a case management MQ, they did finish up with a slide showing the critical capabilities that customers are asking for in case management. such as a balance of content, collaboration and process services; and high-configurable case-based user interface. They lay these out against four styles of case management – collaborative forms-based case management, knowledge workers collaborating on internal content, regulated customer-facing file folders and data, and costly processes initiated by customers – and indicate how important each of the factors is for each style. I definitely see the beginnings of an MQ (or four) here. They did state that they would be issuing a research report on the great case management debate; I’ll likely be giving my take on this topic later this year as the industry track chair at the academic BPM 2011 conference.

It’s clear that the definition of case management needs to firm up a bit. As I asked in a tweet during the session: case management: is it a floor wax or a dessert topping? As any old Saturday Night Live fan knows, it’s both, and that could be part of the problem.

Selecting a BPMS

Janelle Hill of Gartner gave a short presentation on selecting a BPMS. Some of her points:

  • The coolest BPMS may not be appropriate. Take advantage of the model-driven development environment that is appropriate for your business people rather than just what’s the most fun for the developers. A typical feature-function evaluation may not be the best way to go about it, since the functionality can vary widely while providing the same business capability.
  • A BPMS is a suite of technologies for supporting the entire lifecycle of process improvement: discovery, modeling, execution, monitoring and optimization. It’s a platform that includes both design-time and runtime. She showed the classic Gartner “gears” diagram showing all the components in a BPMS, and pointed out that you probably don’t need to do a deep dive into some of the components such as business rules, since that’s typically not the deciding factor when selecting a BPMS. A BPMS is a composition environment rather than a full development environment, where the components are used together to graphically assemble pre-existing building blocks from outside the BPMS together with some functionality built within the BPMS to create a process application. As a composition environment, the registry and repository are important for being able to locate and reuse assets, whether created inside or external to the BPMS.
  • A BPMS is not the same as a SOA suite: the latter is used to create services, while the former consumes those services at a higher level and also provides user interaction. As I’ve said (usually in front of my service-oriented friends), a BPMS provides the reason that the SOA layer exists.
  • A BPMS provides visibility, adaptability and accountability particularly well, so you should be considering how a BPMS can help you with these business capabilities.
  • If business (or a combination of business and IT) need to be able to manage process change, or processes change frequently, then a BPMS is a good fit. If process changes are purely under the control of IT and the processes change infrequently, then more traditional development tools (or an ERP system) can be considered. She talked about frequently changing processes as being served by systems that are built to change, whereas those with less frequently changing processes as being built to last, but pointed out that “built to last” often translates to brittle systems that end up requiring a lot of workarounds or expense changes.
  • She presented Gartner’s top four BPMS use cases: a specific process-based solution, continuous process improvement, redesign for a process-based SOA, and business transformation. Their latest MQ on BPMS has more information on each of these use cases; if you’re not a Gartner customer, it’s available through the websites of many of the leading BPMS vendors.

She then moved into some specific evaluation criteria:

  • Know your dominant process patterns: straight-through, long-running with human involvement, dynamically changing processes flows, or collaboration within processes. She categorized these as composite-heavy, workflow-heavy, dynamic-composite-heavy and dynamic-collaborative-heavy, and showed some of the tools that they provide for helping to compare products against these patterns. She stated that you might end up with three different BPMS to match your specific project needs, something that I don’t completely agree with, depending on the size of your organization.
  • Don’t pick a BPMS because it’s a “safe” vendor or enterprise standard, or because of price, or because the developers like it.
  • Do pick a BPMS because it enables business-IT collaboration, because its capabilities match the needs of a defined process, it supports the level of change that you require, and it interoperates well with your other assets.
  • Do an onsite proof of concept (POC), 2-3 days per vendor where your people work side-by-side with the vendor, rather than relying on a prepared demo or proposal. She had a lot of great points here that line up well with what I recommend to my clients; this is really necessary in order to get a true picture of what’s required to build and change a process application.
  • Check for system scalability through reference checks, since you can’t do this during the POC.

She ended with some recommendations that summarize all of this: understand your requirements for change to determine if you need a BPMS; understand your resource interaction patterns to define the features most needed in a BPMS; ensure that your subject matter experts can use the tools; and have a POC to evaluate the authoring environment and the ease of creating process applications.

BPM and ERP at AmerisourceBergen

Gartner BPM always includes sessions for the vendor sponsors, and most of them are smart enough to put one of their customers on stage for those presentations. This afternoon, I listened to Manoj Kumar of AmerisourceBergen, a Metastorm (OpenText) customer discuss how they used BPM as an alternative to customizing their SAP system, as well as to streamline and improve their processes, and enforce compliance. He went through how they built their business case: demonstrating the BPM tool, surveying departments on their business processes and how they might benefit from BPM, and some analysis to wrap it all up. He also covered the business and IT drivers for creating a BPM center of excellence, with a focus on alignment, shared resources and reusability.

Building the execution team was key; with a model-driven tool, he didn’t really want “hard-core developers”, or even people who had used the tool before, but rather those who could adapt quickly to new environments and use model-driven concepts to drive agile development. Having a focus on quick wins was important, rather than getting bogged down in a long development cycle when it’s not necessary.

They also had considerations about their server infrastructure, and since they were using BPM across a wide variety of decentralized and non-integrated groups decided on separate virtual machines that could be taken down without impacting anything beyond the specific departmental process. This seems to indicate that they didn’t do much end-to-end work, but focused on departmental solutions; otherwise, I would have expected more integration and the requirement for shared process engines. When he showed his process stats – 200 different processes across 3000 users – it seemed to reinforce my assumption, although they are doing some end-to-end processes such as Procure To Pay.

He strongly encourages taking advantage of the BPM tool for what it does best, including change management for processes. They’ve obviously done a good job of that, since they’re managing their entire BPM program with 4 people on the implementation team. He recommends not allowing developers to write any code until you’ve prototyped what you can in the BPM tool, or else their tendency will be just to rewrite the BPMS functionality themselves; I am 100% behind this, since I see this happening on many BPM implementation projects and it’s a constant battle.

With an SAP/BPM integration like they’ve done at AmerisourceBergen, you need to be careful that you don’t get too carried away in the BPM tool and rebuild functionality that’s already in SAP (or whatever your ERP system is), but using BPM as a tool for orchestrating atomic ERP functions makes a lot of sense in terms of agility and visibility, and also provides the opportunity to build processes that just don’t exist in the ERP system.

Advancing BPM Maturity

Janelle Hill of Gartner presented on how to advance your BPM maturity, starting with the concept that not only isn’t there one path to get to BPM maturity, but there’s more than one maturity destination. There are many different mind-sets that organizations have about their BPM programs, ranging from simple automation and improvement efforts up to strategic business optimization; how you think about BPM will have an enormous impact on the potential value of BPM within your organization. This is really an excellent point that is rarely explicitly stated: if you think of BPM as a low-level tool to do some automation – more of a developer tool than a business tool – then you can see benefits, but they’ll be limited to that domain. Conversely, if you think of BPM as a tool/methodology for transforming your business, your use of BPM will tend to be more aligned with that. The tricky part is that BPM is both (and everything in between), and you don’t want to lose sight of its use at a variety of levels and for many different sorts of benefits: as fashionable as it is to see BPM as purely a strategic, transformational methodology, there are also a lot of practical BPM tools that are used for automation and optimization at a more tactical level that have huge benefits.

Gartner’s business process maturity model – the same, I think as the OMG BPMM – passes through five levels from process-aware, to coordinated processes, to cross-boundary process management, to goal-driven processes, to optimized processes. In line with this, benefits move from cost and productivity improvements at the low levels; to cycle time reductions, capacity and quality gains at the middle levels; to revenue gains, agility and predictability at the higher levels.

Advancing maturity requires work along six major dimensions:

  • Organization and culture
  • Process competencies
  • Methodologies
  • Technology and architecture
  • Metrics and measures
  • Governance

She then showed a mapping between the maturity levels and these dimensions, with the level of effort required for each, with the critical transition points highlighted. There are some interesting transition points, such as the effort required for organization and culture increasing right up until when you are well-entrenched in level 5 maturity, at which time the organization and culture aspects becomes systemic and mostly self-sustaining, and the explicit effort required to maintain them decreases sharply.

She broke out each of the dimensions in more detail, showing within the organization and culture dimension how the roles and responsibilities must be developed as the maturity level increases through education, establishing a BPCC and becoming goal-aligned.  Some dimensions, such as process competencies, methodologies and technology/architecture, follow fairly logical paths of increased effort as the maturity level increases, although there will be decisions within those such as which particular methodologies to develop within your organization, and your tools may change as your maturity level increases. Metrics and measures tend to be more aligned with the maturity levels, changing from individual lagging indicators to shared real-time metrics tied to strategic objectives and SLAs, and is also heavily supported by technology. Governance is the most difficult of the dimensions, with a collection of very different initiatives, and probably won’t even properly start until you’re transitioning from level 1 to level 2. A lot of what she covered here is centered around the process governance committee, and some level of centralized stewardship for end-to-end processes: otherwise, it’s impossible to fund and push forward with processes that span functional (and budgetary) boundaries. It’s also necessary to create incentives to support this, so that the entire process doesn’t end up sub-optimized when one of the functional subprocesses is optimized.

Gartner’s research has shown the impact of a BPCC on achieving business process maturity, and in turn, delivering more successful BPM projects across the organization; I definitely agree with this, although believe that you need to grow your BPCC more organically on the back of a BPM project rather than making it an independent project of its own. The BPCC should not be part of IT; although it contains some technical people with skills in the tools, it’s really about operational processes and should be under the auspices of the COO or other business leader.

She finished up with a contrast between functionally-driven and process-driven organizations in terms of roles and responsibilities, visibility, hand-offs, cost accounting, risk analysis and other areas, plus a great chart summarizing the linkages between maturity levels and the dimensions.

Excellent talk, and lots of great practical advice on what you need to do to increase your BPM maturity level.

Selling BPM to your Organization

Starting into the breakout sessions here at Gartner BPM 2011 in Baltimore, Elise Olding, with some help from Joel Kiernan of Altera, gave a presentation on selling BPM within your organization. This is about selling that first project internally as well as expanding your BPM initiative beyond the first project: leveraging your success so far and your business-focused BPM definition to see how it can be applied with other opportunities. Like any good sales pitch, you need to have content that is relevant, compelling and repeatable. I wrote about expanding BPM adoption within your organization in a recent article series for Global 360, and covered some of the same issues about generalizing beyond that first project into a BPM program.

Kiernan discussed their own case study at Altera (a semiconductor company), starting with how they had to understand their key business processes and communicate this to the steering committee responsible for the business process projects. They’re early in their journey, but have put together the storyline for how BPM will roll out in their organization: identify the right processes, do some as-is and to-be process analysis including external best practices, implement process/system changes, then move into ongoing process improvement.

As Olding discussed, there will need to be different messages for different internal audiences: senior executives are interested in how BPM will improve performance, competitiveness and operational flexibility; line of business managers are interested in operational goals including reducing errors and rework, and gaining visibility into processes for themselves and their management; front-line workers want to know how it will make their work easier, more interesting and more effective.

As an aside, I get the feeling that Gartner presenters have been coached by someone who really likes complex analogies woven throughout the presentation: in the keynote, Ken McGee used a courtroom analogy throughout the presentation, and here Olding is using a film-making analogy with “trailers”, “setting” and “engaging the cast”. It was also a bit of a strange segue to involve the Altera person for only about two minutes when they were really just starting in their process, although I have to give her credit for sharing the stage with a customer, since that’s pretty rare at any Gartner events that I’ve attended in the past. Would have been great to hear from someone further along in the process, and maybe a bit more from them than just two slides.

She covered some of what you actually want to communicate, as well as the who and how of the communication, stressing that you need to achieve buy-in (or at least understanding) from a lot of different stakeholders in order to reach that tipping point where BPM is seen by your organization as a key enabler for business improvement. She changed the format a bit to get people working on their own process issues, giving everyone time to jot down and discuss their challenges in each of the steps of selling BPM internally, then calling on a couple of audience members to share their thoughts with the room. This format shift caused a bit of loss of focus (and a bit of down time for those of us who aren’t really into this form of audience participation), although she was able to bring the experiences of the audience members in alignment with the material that she was presenting. Not surprisingly, one of the key messages is on the business process competency center (what Gartner calls the center of excellence) and the methodology that they employ with customers to make a BPCC successful within an organization. Success, in that case, is measured completely by how well you can sell BPM inside the organization.

Gartner BPM 2011 Kicking Off

I’m at my first Gartner BPM show in a while: a couple of years ago, I noticed a lot of repeated information from one summit to the next and decided to sit a few out, but decided that there was enough refresh by now and a good chance to catch up with a lot of people who I only ever see at these conferences.

The show kicked off with Michele Cantera, joined by Elise Olding, giving some opening remarks and introducing the winners of the Gartner BPM Excellence awards: Lincoln Trust, UPS, Carphone Warehouse, NY State Taxation, and Maximus.

The keynote was delivered by Ken McGee, Gartner fellow, opened with the statement that this is the time for the business process professional. He backed this up with a look at the economic growth forecast, including some optimistic survey numbers from businesses stating that their revenues and IT spending are going to increase this year. This was a fairly general presentation on the impact of the economy on business environments and the need to seize new opportunities; not at all specific to BPM, except for one slide of the APQC process framework that didn’t really seem to fit with much else.

Gartner has obviously released a report on the Money-Making CIO recently, and that’s what he spent part of his presentation on: looking at the six styles of money-making CIOS (entrepreneur, cost optimization, revenue searching, innovation, business development, and public serving). He mentioned other Gartner research, such as pattern-based strategy, and told us that social networking and cloud computing are important (duh); this seemed like a a bit of a grab-bag of concepts that could have been given to any IT audience at any conference.

I understand that it’s important to have presentations that show the larger context at a tightly-focused event like this BPM summit, but this didn’t have the cohesiveness or inspiration required to elevate it beyond just a summary of this year’s Gartner research.