Category: process

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.

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:

1. Secure technically capable staff; in Verizon’s situation, the processes were so complex and involved the integration of so many legacy systems that some very sharp IT people were required.
2. Understand the business process
3. Secure business buy-in
4. Be prepared to model early in the lifecycle, and modify the models iteratively throughout the project.
5. Understand your development model

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:

1. IT embraces BPM enterprise-wide, which broadens the scope for BPM beyond the existing departmental systems, and centralizes the practices around BPM. In general, this is occurring because of the ability of BPM to connect applications into improved business processes; more than half already are or will be connecting BPM and SOA in their environment.
2. BPM is becoming event-driven, in order to support the event-driven nature of business today. This will result in much more agile processes that can respond to both expected and unexpected events.
3. Increased focus on knowledge-intensive processes, and using collaborative BPM to enable ad hoc processes both on their own or as an offshoot from a structured process. That includes a variety of collaborative activities, including producing documents, sharing collaborative workspaces, and discussion forums. Over 90% of BEA customers indicated that they have some sort of collaborative processes.
4. Enterprise social computing (Enterprise 2.0) as it starts to impact BPM, which I’ve been writing about for a couple of years: introducing tagging, wiki, social connectedness and the like with more traditional process management in order to add context and more easily collaborate.
5. Moving towards dynamic business applications, and how BPM holds a central role in that. Yvonne Genovese spoke in the keynote this morning about the move towards dynamic/composite applications in order to free organizations from the pre-canned logic in packaged enterprise applications, but BPM (together with services exposed in an SOA layer) allows for the fast assembly of applications that are more suited to current business needs.

I just saw a nice demo of Vitria’s new M₃O release — just hit beta yesterday — that brings an incredible amount of richness and Web 2.0-ness to the interface: monitoring through RSS feeds, very dynamic drilling down and up in process maps, etc. The demo occurred in the context of a short presentation on the convergence of BPM, Web 2.0 and event processing. The process modeler is now browser-based (or so it appeared; we were looking at a screen capture, not the live product), and has evolved into something that could be used by a business analyst. In the past, Vitria has always been pretty focused on the system-centric end of BPM, but it looks like they’re trying to push both the ability to handle human-centric BPM as well as opening up the modeling environment beyond IT.

Thye’ve done some really interesting things in monitoring, particularly through the use of RSS feeds, allowing mashups, and tying data feeds to maps. Creating dashboards and linkages between the dashboard objects is done graphically.

I’m definitely looking forward to seeing more of M₃O: it looks like they’ve done some really nice UI innovations that will definitely push more control into the hands of the business (although their claim that they’re the first vendor to bring together human-centric and integration-centric BPM — and, in fact, that Vitria is the originator of BPM — is a bit of an exaggeration).

I stayed around for the 2nd half of the Microsoft session to hear about their BPM customer success story with Mario Cataldo, CIO of FirstAgain, an online lender.

They are doing loan origination, funding and loan servicing processes in support of their online lending operations, including credit modeling and underwriting, but also administrative processes such as invoice generation and email templates.

They’ve made heavy use of business rules within their business processes, looking for ways to minimize IT involvement when business rules change by identifying the areas of frequent change. Since their applications are essentially built in code (rather than, I am assuming, a graphical model), this is an essential contributor to their agility, and he spent quite a bit of his presentation discussing how business rules improve their processes and their selection methodology, which led to their selection of InRule.

They initially started with an unnamed third-party workflow product, but after Microsoft released .Net 3.0 and Workflow Foundation (and after they had already deployed the other product), they switched away from their selected workflow product to Microsoft WF. Since they were already in production with the other tool since 2006, they’ve been stripping that out and replacing it, and plan to go into production soon with the Microsoft WF solution. They converted to the Microsoft product because it gave them better extensibility, performance and scalability, and reduced their costs since WF is included in .Net 3.0.

This is a much more code-intensive type of implementation than what you would see with most BPM suites, since it’s really a workflow extension to a development environment rather than anything like a BPM suite. Having to build your own workflow administration, for example, puts off a lot of people.

There are some good use cases for this mode of implementation, however: one is small software shops with a group of highly capable developers and a limited budget who are more likely to spend money on talent than someone else’s code, such as a startup; this is exactly FirstAgain’s situation. Although they tried out a more full-featured workflow product, it didn’t have the scalability that they needed, and ultimately they preferred to build it themselves. Coming from a software development background, I understand this mindset: if you have a talented team, you can likely build something better for your specific needs right now. The problems come as your requirements shift, or as the BPM market changes, and new functionality offered by full-featured vendors isn’t available to you since you’d have to build it yourself. Realistically, there are many parts of a full BPM suite that you’re just not going to build if you do it yourself on the shoestring budget model; you need to consider if those are important to you or not.

Yes, there is really an exclamation point at the end of the presentation title in the published agenda: it looks like Microsoft is as surprised as the rest of us that they can achieve people-ready processes. This is the second of the vendor sessions of the day, and I’m listening to Burley Kawasaki talk about Microsoft’s BPM offerings and vision.

Kawasaki starts by talking about recent changes in enterprises, and how agility is the new competence for the enterprise. He believes that companies are sold on BPM as the right vision, but that cost, complexity and risk limit its adoption so far: placing them far down on the business process maturity curve. I’m not sure that most companies are even sold on BPM as the right vision, although I definitely agree that cost, complexity and risk are inhibiting technology implementations.

And to be People_Ready (as he puts it — obviously, I’m missing some joke in the syntax), he sees some key principles:

• Routes of adoption: each initiative is focused on a specific incremental goal, specifically awareness, repeatability, automation or optimization. This totally didn’t make sense until he started mapping each of these routes to a Microsoft product: Visio, SharePoint Designer, Visual Studio/BizTalk and SharePoint Performance.
• Collaborative design tools for allowing sharing of models between different roles, although in the Microsoft world this often doesn’t include literally sharing models, but rather import/export of models between environments.
• Relevant to the information worker, through integration with desktop environments such as Microsoft Office. Office integration, especially the integration of processes with Outlook, is definitely a hot topic for many of my customers.
• Ubiquitous process platform, wherein composite applications are created through the integration of a number of distinct pieces in the platform, whether the pieces themselves are well integrated or not.

It’s this last definition of a process platform that I most object to: Gartner and the large vendors are moving towards this “business process platform” idea rather than a BPM suite, wherein anything with a single vendor’s logo on it can be considered part of the platform, regardless of how it fits together with other components. I just don’t buy it.

Kawasaki finished up talking about the Business Process Alliance, and the growth that its seen with both customers and partners, with over 100 templates and solutions offered for 11 vertical industry.

I came in late for Jim Boots’ presentation on how grassroots efforts catalyzed BPM at Chevron, so didn’t take any formal notes. He had a lot of great information on challenges that they overcame and those still to overcome, key roles, and how they created an empowered employee vision.

My favorite bit, however, was how he presented his key points and subpoints: he used a mindmap type of structure to show them.

I really wish that his presentation was up on the Gartner site; I think that I missed a lot of good points here.

The second half of Lomardi’s vendor session is a presentation by Tim Rolfing, IT Director of Allianz of America Shared Services on how they use (Lombardi’s) BPM. Allianz Life is a 3000-person life insurance organization that’s part of the huge Allianz group of companies.

Their initial drivers for BPM date from 2005:

• The ability to scale efficiently, based on projected increases in premiums and employees.
• Leveraging common processes, since they had a number of duplicate functions due in part to their growth through acquisitions. They also had 500-700 systems that were in use throughout their organization that needed to be rationalized.
• Need for transparency into operations, both to have a view of the end-to-end processes in order to look for areas of process improvement, and for real-time operational process monitoring.
• Employee job enrichment, by automating some of the routine tasks done by people, thereby allowing people to focus on customer-centric activities. This also allowed the human-facing tasks to be done anywhere in the world, certainly a bonus for a company that’s part of a global organization.

They’ve implemented an impressive number of processes in a short time:

• Securities application processing
• Money processing for applying premiums
• Life insurance underwriting
• Survey response tracking
• New (insurance) product implementation, which improved the cycle time to implement a new product from over 50 days to 12 days, and removes IT from the critical path
• Application document search, sort and prioritization within specialty queues to allow SLAs for specific applications to be met; failure to meet the SLAs can result in financial penalities
• Service recovery and customer complaint handling, including some historical analytics to determine if these have detectable patterns, such as product or broker

They have a number of other ones lined up for implementation in 2008

He ended with some lessons for success:

• Look for small processes with significant impact
• Plan for a deployment time frame of no more than 60-90 days
• Keep the first pilot project simple
• Follow an iterative methodology rather than trying to boil the ocean in the first version

They keep the BPM project teams small, and have found a great deal of improved efficiency through their implementations. They have a BPM center of excellence that they use to train the business side. The technical teams have done the Lombardi technical training, and found that the week-long training was adequate for their needs. He wouldn’t talk openly about their vendor selection process, but stated that there were significant differences between BPM products. The business owns the process and maps it down to a specific level of detail (in Blueprint, I believe) before turning it over to IT who “move it over to the BPM tool” — presumably, they’re using Blueprint for modeling by the business, which still requires export/import to get to Lombardi’s TeamWorks execution environment, so round-tripping would definitely be impacted.

As an aside, I really wish that Gartner did a better job of publishing presentation on their website, since there’s material from this (and other) presentations that I’d like to review in the future. They don’t seem to publish any of the presentations from the vendor sessions, even those by customers, and half of the regular session presentations are also missing from the site (and presumably the CD in our conference pack) as of today.

Although Gartner really only invites their own analysts and customers to speak in the conference sessions, sponsoring vendors can buy a spot in the vendor session tracks, which breaks down into two 30-minutes sessions: usually one by the vendor themselves, and one by one of their customers. I’m sitting in on Lombardi’s double session, the first part of which is with Toby Cappello, Lombardi’s VP of Professional Services; this will be followed by a session with Allianz that I’ll also stick around for.

Cappello is focused on the cycle of define, deliver and improve, with three components:

• Setting direction (motivation, organization)
• Directing work (process, rules)
• Improving performance (analytics)

He walked through typical parts of each of the define, deliver and improve milestones; nothing earth-shattering here, but he’s really stressing the need for agility in this cycle.

He’s a big fan of hands-on involvement by the business in BPM projects, and feels that business and IT aren’t really collaborating if they’re not sharing the process models. Luckily, that’s something that Lombardi’s products allow you to do reasonably well, and will improve further with their expected mid-year product release that will combine the process model repositories for their software-as-a-service product discovery tool, Blueprint, and their core BPM environment, TeamWorks. There’s delineation of responsibilities between business and IT — basically along the line between processes and services — but they need to be working together on the same model for true collaboration.