Last week and this week saw some very difficult choices for conference attending: I went to the International BPM conference in Milan last week, but missed Office 2.0; this week, I’m attending Appian’s user conference and Gartner’s BPM summit in Washington DC, but missing SAP’s TechEd and all my Enterprise Irregulars peeps (although I won’t at all miss going to Las Vegas).
Watch for my coverage of the Appian user conference tomorrow, then Gartner starting on Wednesday.
I’ve been sticking close to home for the summer, but my fall lineup is about to begin. So far, I’m definitely attending the following:
Given that I fly everywhere on Star Alliance, this will bump me over the 35,000 miles for the year that gives me Aeroplan Elite status for 2009, without which I really don’t want to fly.
From a disclosure standpoint, my expenses are being paid for the Appian conference, the Business Rules Forum, and two SAP events; for the latter SAP event, I’m also being paid to deliver the half-day training session.
I feel like I’m on the last mile of a marathon: it’s the closing keynote of the conference, and it seems like it’s been going on a long time. Gartner may have jumped the shark by moving to two North American BPM summits per year; a lot of the material is heavily recycled, making it much less valuable to repeat attendees (although still very good for first-timers), and I’m sure that the vendors are completely fatigued — both in terms of time and money — from attending two of these each year, plus the one in London. Attendance feels lower than last spring, although more than last fall’s dismal attendance, and at some point the vendors will find that it’s just not worth their time and money to attend both North American BPM summits each year; that in turn will impact the quality of the experience for the end-customer attendees since they’ll see less of the vendors’ customer presentations, and less vendors at the trade show.
I’m hearing Daryl Plummer for the first time this week — not sure how I missed him earlier — as he moderates the open research meeting, joined by Janelle Hill, Matt Hotle, Elise Olding and Jeff Woods. I’ve never managed to attend one of these before, since I always seem to have been heading out of town during the last session. The format is that they put forward a series of strategic planning assumptions, then they are debated by the analysts on the stage and anyone from the audience who wants to participate.
The first strategic planning assumption is that business application vendors that do not deliver model-driven applications by 2012 will be marginalized as application providers. The dominant players — SAP, Microsoft and Oracle — are already moving in the direction of model-driven architecture, but there are still a lot of other ERP applications out there that are not heading that way, and there seems to be a strong argument that four years is just too aggressive of a timeline, especially in vertical industries where there might only be one dominant layer for a vertical-specific application. When it does come, it will likely be driven by the business, since model-driven architecture provides a world of difference to business (although it still has significant benefit to IT).
The second strategic planning assumption is that by 2012, more than half of new mission-critical business functions will be delivered by teams outside of IT through model-driven and agile techniques. Related to the previous SPA, this means that not only will the vendors be providing the model-driven applications, but that the business area will be delivering the functionality based on them, and on inherently model-driven platforms such as BPMS. This, of course, presupposes that the business even wants to lead these initiatives, which isn’t at all obvious since it isn’t happening in a majority of companies now. An interesting debate rose out of this that resulted in one of the analysts stating that “it might happen, but it might not work”, and pointing out that if their strategic planning assumptions don’t have some risk of being wrong, then they’re just tactical planning points.
The third strategic planning assumption is that enterprises that modernize their applications portfolio without a model-driven application focus will spend an equivalent amount of money by 2012 on a second round of modernization to get to model-driven applications. This highlights that not only will it be necessary to move to model-driven applications, but that it’s expensive; there was also discussion that if it’s not model-driven, then it’s not modernization, which seems to be a bit of a stretch.
All in all, I found this session interesting and am glad that I stuck around for it. I think that Gartner is very bullish on model-driven applications, and are overly optimistic about the timelines for how this technology will roll out. I don’t think that there’s any question that these things will occur, but 2012 is only four years away.
Janelle Hill addressed the issues of what’s really new in BPM and how it can change how you do business. She starts off by discussing how BPM is different from older business process reengineering techniques:
Gartner defines an explicit process as one that it visible and independent from its implementation; namely, the process has been modeled separate from context manual or automated context. This type of modeling and the management of the explicit processes is essential for effectiveness and innovation; it allows for the establishment of process KPIs and allows you to model potential changes to the process. These process models provide a view of work in progress; as these models are implemented in BPMS, they become the visual metaphor for the work for monitoring and management purposes. They also provide a method of communicating about the process, both between business team members as well as between business and IT.
This also leads to new management techniques. Management becomes more real-time as the process monitoring tools allow for view of what’s happening right now in the business process, instead of managing through the rear-view mirror via historical reports. Typically, a process-centric view encourages collaboration among team members, and also encourages participation by the process workers. Both business and IT workers have different roles: the business user may be assembling their own solutions, while the IT person is designing and building components to be assembled.
She looks at a number of key factors for determining when a BPMS might be used:
If these factors aren’t present, then a more traditional coding approach might be used.
Hill went through some of the process design patterns — I saw this at the previous summit and really liked it, since I use something quite similar with customers — in order to map process characteristics onto different styles of processes, and therefore onto a subset of the BPMS products that might best suit those needs. The three most common patterns that they see with BPMS are case management, form-driven workflow, and participant-driven workflow.
She finished up with the BPMS magic quadrant, and explained that there are so many vendors in the leaders quadrant because they’ve changed the definition of what’s included in BPMS; I see that as a reason why there’s more vendors in the magic quadrant overall, but not why it’s so heavily weighted to the upper-right quadrant. She believes that consolidation for the purposes of acquiring technology functionality has already mostly occurred. She also sees that the larger platform vendors such as Microsoft are focused on software development as the primary method for BPMS rather than model-driven approaches that limit the amount of code.
She believes that this is not the time (yet) to pick the enterprise-standard composition platform, because no one tool handles all of the six process styles that she showed earlier. This is still not a mature market, in spite of the purchasing activity going on.
Elise Olding moderated a panel on weaving BPM into the enterprise, with Eric Abecassis, Architecture and Integration Manager with Schlumberger, Jim Boots, Enterprise Architect at Chevron, and Kevin Morgan, Program Manager at Dolby.
Abecassis started with the process-related problems that they had at Schlumberger: processes had to be standardized in order to effectively manage growth and improve execution, reduce the administrative burden on the field people, and improve alignment between business and IT. Their approach was to focus on three main types of activities:
It appears that their BPM projects are primarily driven by IT (although with heavy involvement by the business), in contrast to Chevron, where grassroots business actions drove the BPM efforts. In their case, a business unit had some amount of success, then a few individuals worked at selling the ideas across the company until it was accepted as a broader platform that can be used elsewhere. They’re still somewhat in stealth mode inside their own organization
At Chevron, they learned how to use the tool, then started to play around with how it could be used: looking for emergent applications of the technology. They showed off BPM to anyone who would listen, particularly trying to link it to existing initiatives, and continued to develop their BPM approach as it become popular in other areas. Overall, the grassroots efforts within the business delivered a proof of concept and a core set of advocates, but eventually key management endorsements and dedicated resources were required to make the transition to an enterprise-wide effort.
Dolby is a sort of 40-year-old startup that just went public two years ago, and is going through some major cultural changes to adapt to the changing world of entertainment technology. A management consulting firm provided them with recommendations for reorganization, then when they started to implement that internally, they discovered that this reorganization — a common issue — actually broke a lot of their business processes. He found an interesting effect: internal audit people have great insight into where problems might exist in business processes, and typically have the attention of management to a greater degree than a BPM team, so he worked closely with them.
It’s good to hear some success stories about how organizations are starting to become more process-centric: these stories aren’t just about how a specific implementation worked, but how the organization started to embrace the benefits that BPM could bring.
It’s a bit distracting that the panel members have obviously been told not to mention their BPM vendor by name; they dance around it by describing the tool, how they selected it and how they use it, but never say what it is.
This morning, I attended with David Norton’s session on integrating BPM and Agile software development methods. In BPM, we always talk about how BPM brings agility to business processes, but what facilitates that agility? Although a lot of this talk is about Agile, it’s definitely valid to look at how to apply Agile methods to BPM projects, since there’s still some amount of software development in almost every BPM project.
He started with a review of software development methods: architected model-driven (including BPM, where you draw an executable process model rather than writing code to handle work routing), architected RAD, and Agile. He then drilled in on Gartner’s 10 principles of NeoRAD (an example of Agile), such as close involvement of the customer, peer review and an iterative approach.
BPM needs to be a mix of agility and discipline, but not a waterfall methodology that we so often see used by old-style development teams when they take on a BPM project; BPM is predominantly architected model-driven because of the executable process models, but also uses some aspects of architected RAD and Agile since there are integration and UI components that require development beyond just the process modeling stage.
He described the principles of Extreme Programming as a coding methodology, and Scrum as a way to manage agile development projects; Scrum, in particular, has a lot of useful concepts that could be applied to BPM projects. He also covered Dynamic Systems Development Method, a type of RAD framework that includes the concept of turning an operational prototype into the end product to reduce waste and time in the development cycle, and Lean Software Development, focused on reducing waste and defects in the same sort of way as Lean works in the manufacturing sector.
He then looked at how BPM release cycles — continuous cycle of design and optimization, iterations of under six weeks, new policies and rules in a day — and how they are much more aligned with Agile methodologies than the traditional waterfall approach, which typically sees the first release in 4-6 months (in the best possible case). Unfortunately, most development teams inside organizations are still stuck in waterfall methodologies, and third-party professional services firms are more motivated to suggest long development cycles with large development teams. That means that even though the process model might be done as zero-code architected model-driven, the (often excessive) customization that happens in the component/service layer and the user interface drags down the project schedule.
This presentation was really much more about Agile than BPM — sometimes Gartner makes a bit of a stretch when bringing in their analysts from other areas and trying to make them BPM-ish — but if you’re not already looking at Agile development for any BPM-related project, you definitely should be.
Today’s sessions closed with a presentation by Dr. Geary Rummler of the Performance Design Lab on the nature of process and the value of shifting an organization to process centricity. I saw him speak at the 2006 Proforma user conference, and enjoyed it; how can you not like listening to the guy who invented swimlanes?
He started with a historical perspective on process, starting in the 1982-92 timeframe with his highly-successful process-related work at Motorola that resulted a lot of useful process management/improvement tools, followed by the somewhat disastrous 1992-97 re-engineering phase that resulted in the split between business management and process management. When re-engineering became a prominent feature in Dilbert cartoons, Rummler decided to retire.
It didn’t take, and four years later (in 2001), he came out of retirement to find a confusing landscape of acronyms, an unnatural focus on technology, low-level process improvement techniques masquerading as methodologies, and subprocesses being implemented in silos. A majority of process activities was in the weeds, and had little linkage to business results. All of this brought him to today, where he asks the questions “why are we doing this ‘process’ stuff anyway?”
He moved on to a business perspective on process, where we’ve perverted the order of things such that budgets are allocated along the lines of the organizational chart, and therefore the work systems — including applications, data and networks — to which those resources are applied end up (naturally) siloed. Making improvements within a silo, as we all know, can only have limited impact on end-to-end process improvement and particularly in the interfaces to customers. The work system becomes invisible, and it’s managed only indirectly through management of resources: reorganizations and down-sizing as action items instead of considering how the underlying work systems themselves need fixing.
What we need to do is change our focus on work and resources, and focus on the business as a system for creating value, manifested in the products and services delivered to the customers. The value creation system — effectively, the customer-facing business processes — and the resources must both be managed directly and in concert. BPM, therefore, isn’t just about modeling, improvement and management, it’s about creating the value creation dimension of the business.
He then looked at a future perspective, with the Performance Design Labs’ framework for value creation, which provides a model of a business, its customers and external impacts. Inside the business in the first level of the model, we see the value creation system, enabling processes and management systems; driving down to the second level shows the three primary process systems in any value creation system (product/service launched, sold, deliverer); then the third level of detail shows the high-level business processing systems; the fourth level is the processes and subprocesses; and the fifth level is the tasks and subtasks that actually connect to the (human or system) performers of the tasks. This five-level hierarchy maps to a set of business architectures: supersystem maps, cross-functional maps, business process architecture, then down to the process and task maps, all of which become a management-friendly schematic of the business.
Within the hierarchy, the first three levels represent the strategic application of process work, and the lower parts of the third level through all of levels four and five represent the tactical side. Unfortunately, much of BPM is focused on levels four and five, which is disconnected from the value that’s outlined in the first level and from business leadership.
The implication of all this is that businesses need to be managed on two dimensions: the functional silos (buckets of resources), and the business processes that cut orthogonally across them (the value creation). And, just as there are problems in things disappearing into the vertical white spaces between functional silos, they can also get lost in the horizontal white space between business processes.
BPM must drive the articulation of the value dimension, thereby making it possible to link from level one down through to level four of the value creation hierarchy.
Rummler is a delightfully funny and informative speaker, and I enjoyed this even more than the last time that I saw him speak.
Michele Cantera and Ben Pring talked about the compatibility of BPM and SaaS, especially in the key issue of whether process agility can be achieved with SaaS delivery models, or if that’s only suitable for standardized applications and processes.
Pring’s area of expertise is SaaS, and the first part of the presentation was on the SaaS trends in the next five years, and the areas where it will have the most impact. He spent some amount of time defining SaaS (which I won’t reproduce here), how it is confused with outsourcing and hosting, and its benefits. It is useful to consider, however, some of the reasons why companies are moving to SaaS, since these are true for BPM as it becomes available in a SaaS environment:
SaaS is almost always used to reduce costs, both the up-front costs of the systems themselves and the infrastructure required to support them. However, many organizations have security concerns (which may or may not be unfounded), and there is often a real or perceived reduction in functionality (particularly related to integration) compared to an on-premise system. SaaS is no longer seen as a crazy idea any more — Salesforce.com proved that organizations would put confidential business-critical data in a remote system — and many enterprise application vendors are looking for ways to capitalize on this growing market.
Cantera took over to talk about BPMS and SaaS, starting with the range of different service delivery models from on-premise shared services (which she refers to as “not really SaaS” — you think?), to business process outsourcing (again, not SaaS since the end-customer doesn’t provide the people in the process and/or it’s not purchased on a subscription basis), to SaaS delivery of process-based applications (e.g., Enkata, based on Lombardi TeamWorks, or L@W, based on Metastorm), to an actual SaaS BPMS platform (e.g., Appian Anywhere, or Fujitsu Interstage). In most cases, the process-based applications are fairly rigid to the end consumers; unlike the platforms, which expose pretty much the entire functionality of the equivalent on-premise BPMS, the applications may not allow any process changes, or only limited changes.
She said that she doesn’t see a push to using a BPMS platform via SaaS, but I think that’s a chicken-and-egg problem: Appian’s product isn’t even released yet, and Fujitsu’s seems to be under the radar, so customers either don’t even know that this capability exists or think (correctly) that it’s not available yet.
There are a number of architectural patterns for implementing multi-tenancy BPMS on a single SaaS server:
Cantera and Pring spoke together on what degree of process agility can be expected in a SaaS BPMS environment. They started by discussing — separately — how to determine if SaaS is right for you, and if BPMS is right for you, then looked at the process agility characteristics of BPMS in the various service delivery environments. If we look just at the characteristics for BPMS platforms via SaaS, they indicate a moderate operational cost, high degree of customization possible and therefore high process agility with a low to moderate cost associated with that process agility. The problem, of course, is that the vendors just aren’t quite there yet.
David Landry, Verizon’s Executive Director of Sales Support and Billing Systems, spoke about how they used BPM to simplify and improve Verizon’s billing process. They started with a pretty serious spaghetti mess of contract-to-billing processes: 120 different processes, disjointed legacy systems, manual processes, local variations, and a number of other factors making everything from contracts to billing painful for both customers and employees. Due to growth via acquisitions, they also had a number of overlapping systems and processes.
What they needed was a standardized, simplified and automated process for capturing customer contracts, and mapping that into the billing system so that customers’ bills would accurately reflect the terms of their signed contract. Using BEA’s AquaLogic BPM and Service Bus, plus WebLogic Portal, they were able to streamline the process, reduce staff requirements for manual processing and reduce errors in manual data entry (and re-entry), resulting in $9M in savings from staff redeployment and billing credits, as well as greater customer satisfaction due to the quicker, more efficient and more accurate billing processes.
They had a number of drivers behind deploying a reliable, BPM-based solution: SOX compliance was the biggest one, since they now have better auditing of their processes and other controls, but they also considered flexibility of the process with respect to design and incident escalation, self-documenting processes, real-time process monitoring, automation of some manual tasks, and the ability to integrate multiple systems into the processes.
He ended up with five tips for implementing BPM:
In their case, the project was very IT-led (including the modeling activities), although it was a collaboration between the CFO’s office and IT. They started the project in May last year, and delivered their first version in December — pretty fast for something of this complexity. They’ll be doing an incremental next version within the next couple of months, and see this as an ongoing process, not a one-shot implementation.
Jay Simons, VP of Marketing for BEA, presented the results of their recent research into the state of the BPM market, including a survey of 200+ BEA customers, mostly IT people but spread across vertical markets and geographies. They’ve also gathered information through their online BPM Lifecycle Assessment. I had the pleasure of collaborating with BEA on the resulting white paper, which they’re distributing a sneak preview version here at the show and will have more widely available on their website in about two weeks; consider as this disclosure that BEA is my client in case you haven’t checked my disclosure page lately.
The results show a number of interesting trends indicating that CIOs and business leaders are focused on improving their processes. Existing customers described how they expect to get their ROI from their BPM implementations, and most expect to see ROI over the next three years.
The top five trends:
