Month: February 2008

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:

• Process orientation complements functional organization, along the lines of what Rummler was discussing yesterday: processes overlay functional silos, which drives matrix management so that processes can be managed end to end.
• Processes must be effective and transparent, not just efficient.
• Processes must be adjustable (sometimes by process participants), not perfect, in order to adjust to changing customer requirements.
• Small incremental improvements must be harmonized with larger transformative change.

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:

• Strong focus on coordinating multiple resources to create successful work outcomes, including people, systems, information and policies.
• The process crosses a large number of boundaries.
• The process is poorly understood.
• The process is customer-facing or partner-facing.
• The process is more susceptible to external or internal disruption.
• Business will be responsible for change management, not IT.

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:

• Doing the right things (business)
• Understand the right things (business/IT)
• Doing things right (IT)

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.

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.