Month: April 2010

Eamonn Cheverton of BAA discussed the recent event-driven implementation of Pega at Heathrow airport for managing aircraft from touchdown to wheels-up at that busiest of airports. In spite of the recent interruption caused by the volcanic eruption in Iceland, Heathrow sees millions of passengers each year, yet had little operational support or information sharing between all of the areas that handle aircraft, resulting in a depressingly low (for those of us who fly through Heathrow occasionally) on-time departure rate of 68%. A Europe-wide initiative to allow for a three-fold increase in capacity while improving safety and reducing environmental effects drove a new business architecture, and had them look at more generic solutions such as BPM rather than expensive airport-specific software.

We’ll be looking more at their operations tomorrow morning in the case management workshop, but in short, they are managing aircraft air-to-air: all activities from the point that an aircraft lands until it takes off again, including fuel, crew, water, cleaning, catering, passengers and baggage handling. Interestingly, the airport has no visibility into the inbound flights until about 10 minutes before they land, which doesn’t provide the ability to plan and manage the on-ground activities very well; the new pan-European initiative will at least allow them to know when planes enter European airspace. For North Americans, this is a bit strange, since the systems across Canada and the US are sufficiently integrated that a short-haul flight doesn’t take off until it has a landing slot already assigned at the destination airport.

Managing the events that might cause a flight departure to be delayed allows for much better management of airline and airport resources, such as reducing fuel spent due to excessive taxi times. By mapping the business processes and doing some capability mapping at the business architecture level, BAA is able to understand the interaction between the activities and events, and therefore understand the impact of a delay in one area on all the others. As part of this, they documented the enterprise objects (such as flights) and their characteristics. Their entire business architecture and set of reference models are created independent of Pega (or any other implementation tool) as an enterprise architecture initiative; to the business and process architects, Pega is a black box that manages the events, rules and processes.

Due in part to this initiative, Heathrow has moved from being consider the world’s worst airport to the 4th best, with the infamous “disastrous” terminal 5 now voted best in the world. They’re saving 90 liters of fuel per flight, have raised their on-time departure rate to 83%, and now involve all stakeholders in the processes as well as sharing information. In the near future, they’re planning for real-time demand capacity balancing through better integration, including coordinating aircraft movement across Europe and not just within Heathrow’s airspace. They’re also looking at physical improvements that will improve movement between terminals, such as underground baggage transport links that allow passengers to check in baggage at any terminal. Their current airport plan is based around plans for each stand, gate, person, vehicle, baggage and check-in resource; in the future, they will have a single integrated plan for the airport based on flights. They’re also adopting ideas from other industries: providing a timed entry ticket to security at the time that you check in, for example, similar to the fast-track system in theme parks. Also (which will raise some security hackles), tracking you on public transit on your way to the airport so that your flight can be rescheduled if your subway is delayed. With some luck, they’ll be able to solve some of the airport turnaround problems such as I experienced in Frankfurt recently.

The tracking and management system, created using Pega, was built in about 180 days: this shows the status of arrivals, departures, turnarounds (the end-to-end process) and a real-time feed of aircraft locations on the airport property, plus historical and predictive reports on departures, arrivals and holdings. Really fascinating case study of using BPM in a non-traditional industry.

Trace Fooshee, VP and Business Process Lead at SunTrust, discussed how they are using Pega to improve account opening in their wealth management area. He’s in a group that acts as internal management consultants for process transformation and related technology implementation: this covers issues ranging from lack of integration to inconsistent front-back office communications to inefficient manual work management. Some of the challenges within their wealth management account opening process were increasing costs due to inefficient and time-consuming manual processes, inconsistent processes, and poor operational and management control.

In order to address the challenges, they set a series of goals: reducing account opening time from 15 to 4 days, improving staff productivity, eliminating client setup inconsistencies, streamlining approvals, and converting 40% of maintenance requests to STP. In addition to these specific targets, they also wanted to develop enterprise account opening services and assets that could be used beyond wealth management. They approached all of this with online intent-driven forms, imaging and automated work management, online reporting and auditing, backend system integration, and standardized case management to share front and back office information.

Having some previous experience with Pega, they looked at how BPM could be applied to these issues, and found advantages in terms of flexibility, costs and other factors compared to both in-house builds and purchase of an account opening application. In considering their architecture, they classified some parts as enterprise assets, such as scanned versions of the executed trust documents that went into their into their FileNet enterprise content repository, versus line-of-business and business unit assets, such as specific process flows for account setup.

Using an iterative waterfall approach, they took a year to put their first pilot into production: it seems like they could have benefited from a more agile approach that would have seen incremental releases sooner, although this was seen as being fast compared to their standard SDLC. Considering that the system just went into production a couple of weeks ago, they don’t really know how many more iterations will be required – or how long each will take – to optimize this for the business. They were unable to use Pega’s Directly Capturing Objectives (DCO) methodology for requirements since it conflicted with their current standard for requirements; as he discussed their SLDC and standard approaches, it appears that they’re caught in the position of many companies, where they know that they should go agile, but just can’t align their current approach to that. The trick is, of course, that they have to get rid of their current approach, but I imagine that they’re still in denial about that.

Some of the lessons that they learned:

• Break down complex processes and implement iteratively.
• Strong business leadership accelerates implementation.
• Track and manage deferred requirements, and have a protocol for making decisions on which to implement and which to defer.
• Get something working and in the hands of the users as soon as possible.

The year that they took for their first release was 3-4 months longer than originally planned: although that doesn’t sound like much, consider it as a 30-40% schedule overrun. Combining that with the lesson that they learned about putting something into the users’ hands early, moving from an iterative waterfall to agile approach could likely help them significantly.

Their next steps include returning to their deferred requirements (I really hope that they re-validate them relative to the actual user experience with the first iteration, rather than just implementing them), expanding into other account opening areas in the bank, and leveraging more of the functionality in their enterprise content management system.

Nancy Mueller, EVP of Operations at Zurich Insurance North American, gave a keynote today on their operational transformation. Zurich has 60,000 employees, 9,500 of them in North America, and serves customers in 170 countries. Due to growth by acquisition, they ended up with five separate legal entities within the US, only one of which was branded as Zurich; this tended to inhibit enterprise-wide transformation. Their business in North America is purely commercial, which tends to result in much more complex policies that require highly-skilled and knowledgeable underwriters.

She admitted that the insurance industry isn’t exactly at the forefront of technology adoption and progressive change, but that they are recognizing that change is necessary: to stay competitive, to adapt to changing economic environments, and to meet customer demands. Their focus for change is the vision of a target operating model with specific success criteria around efficiency, effectiveness and customer satisfaction. They started with process, a significant new idea for Zurich, and managing the metrics around the business processes: getting the right skills doing the right parts of the process. For example, in underwriting, there were a lot of steps being done by the highly-skilled underwriters because it was just easier than handing things off (something that I’ve seen in practice with my insurance clients), although it could be much more effective to have underwriter support people involved that can take on the tasks that don’t need to be done by an underwriter. One of the challenges was managing a paperless process: trying to get people to stop printing out emails and sending them around to drive processes – something that I still see in many financial and insurance organizations.

As they looked into their processes, they found that there were many ways to do the same process, when it should be much more structured, and ended up standardizing their processes using Lean methods in order to reduce waste and streamline processes. The result of just looking at the process was a focus on the things that their current systems didn’t do: many of the process aberrations were due to workarounds for lack of system functionality. Also, they saw the need for electronic underwriting files in order to allow collaboration during the underwriting process: as simple as that sounds, many insurance companies are just not there yet. Moving to an electronic file in turn drives the needs for BPM: you needs something to move that electronic file from one desk to another in order to complete that standardized underwriting process.

Once those two components of technology are in place – electronic underwriting files and BPM – portions of the process can be done by people other than underwriters without decreasing efficiency. They’re just starting to roll this out, but expect to deploy it across the organization later this year. This also provides a base for looking at other ways to be more agile and flexible in their business, not just incremental improvements in their existing processes.

So far, they are seeing improvements in quality that are being noticed by their brokers and customers: policies are being issued right the first time, requiring less return and rework, which is critical for their commercial customer base. They’ve also improved their policy renewal and delivery timeframe, required to meet commercial insurance regulations. They’re looking forward to their full roll-out later this year, and how this can help them to further improve on their major performance metric, customer satisfaction.

Adrian Hopkins from TD’s Visa Systems and Technology group talked about their experiences with Pega, through various major upgrades over the years and now with SmartBPM for multi-channel customer management in their call centers. TD is one of Canada’s “big five” banks, but is also the 6th-largest bank in North American due to its diverse holdings in the US as well as Canada, serving 17 million customers. They’ve been a Pega customer for quite a while; I first wrote about it back in 2006

8-10% of TD’s workforce – 7,000 employees – are in call centers spread across 23 locations in North American and India, handling 47 million calls per year, hence their need to commoditize the agent and provide the ability to route any call to any center and have the customer’s questions answered satisfactorily. The key here is service leveling: providing the same level of service regardless of from where the call is serviced, through training, access to technology and information, and scripting. The goals were to improve service levels, increase capacity, and providing opportunities for up-selling by the agents while they have the customer on the call. TD is using BPM automation to achieve some of this – automating fulfillment and integrating disparate systems – plus providing more intuitive processes that require little training. In one example, they’ve consolidated the content and functionality of 12 different mainframe green screens into a single screen that can be used to handle a majority of the inbound calls; another allows them to process a credit card fraud claim in a single screen and a small number of steps, replacing an overly-complex manual process of 95 steps that involved managing the claim, handling the fraud and replacing the car. In the latter case, they’ve moved to a completely paperless process for handling a fraud claim, and reduced the case handling time from 7 hours down to minutes. Interestingly, they didn’t take away the old green screen methods of doing things when they deployed the new system, since some of the call center old-timers insisted that it was faster for them; however, they gradually removed the access since the new interfaces enforced rules and procedures that were not built into the green screens, generally improving quality of service.

They’re looking at savings and benefits in several areas:

• Reduce training time: at a 10% attrition rate, saving one week of training per new employee means a savings of $750,000/year
• Reduce callback rates, which increases customer satisfaction as well as increasing agent capacity
• Improve compliance, and reduce the cost of achieving and proving compliance
• Increase customer-facing time due to less follow-up paperwork, increasing agent capacity
• Reduce secondary training requirements by guiding agents through complex inquires, allowing less-skilled agents to handle a wider variety of calls, and reducing handoffs
• Increase ability to drive incremental sales from every contact, or “would you like fries with that?”, although they’re not yet actively doing this in their implementation

They’re still using SmartBPM 5.3, but are looking forward to some of the new capabilities in version 6, which should reduce the amount of code that they’re writing and allow them to put more control of the business process rules in the hands of the users.

Based on the screen snapshots that we saw, however, they’re still building fairly large desktop applications; this must be impacting their agility, in spite of their Agile approach, even though it is providing a huge benefit over using the green screens directly.