This report examines the implementation of technology from Pegasystems within BAA, the UK s leading airport operator.

Transcription

1 mwd a d v i s o r s Best Practice Insight Case study: BAA Neil Ward-Dutton Premium Advisory Report February 2011 This report examines the implementation of technology from Pegasystems within BAA, the UK s leading airport operator. MWD case study reports are designed to help organisations considering or actively working with BPM technology understand how others have worked to obtain benefits from BPM implementation, and how they have worked to overcome challenges that have arisen along the way. All MWD s case study reports follow a standard model, and are researched using a standard process which is driven by senior MWD analysts. This report is published as part of MWD s premium BPM advisory subscription service. You can find out more about this service at Review this research in context For further insight around the best practices highlighted in this research and to discuss this in the context of your own organisation, you can schedule a private advisory session with our expert analysts by ing clientservices@mwdadvisors.com or call on +44 (0) MWD Advisors is a specialist IT advisory firm which provides practical, independent industry insights that show how leaders create tangible business improvements from IT investments. We use our significant industry experience, acknowledged expertise, and a flexible approach to advise businesses on IT architecture, integration, management, organisation and culture.

2 BPM case study: BAA 2 Case study key facts Organisation Industry Current BPM goals Process scenarios Current approach BAA Travel, construction Continue development of Real-time Heathrow programme to gain end-toend oversight and control of airport operations; use technology to drive greater resource efficiency and improve passenger experiences. Sequential workflow Straight-through processing Case management Content lifecycle management Collaborative process work Value chain participation In 2008 BAA started a major programme to replace a number of ageing, custom-built airport operations systems and comply with forthcoming European Union regulations related to the Single European Sky ATM Research (SESAR) programme. After an initial procurement project led to a dead-end, BAA carried out a business architecture effort which helped the company realise that many of its requirements were not aviation-specific, but could be met with general-purpose software technology. After further analysis it carried out another procurement exercise, this time focused on BPM technology. BAA s Airport Collaborative Decision Management (A-CDM) system is the first fruits of the resulting investment, and forms the first piece in a larger programme to completely replace its operations systems called Real-time Heathrow. The implementation is technically very advanced and revolves around real-time optimisation of airport resources to create and manage schedules for flight turnarounds. Both human participants (from multiple organisational teams and departments) and information systems are brought together in the A-CDM system to enable managers to minimise flight turnaround times and in turn save BAA and airlines money and improve passenger satisfaction. Outcome Following implementation of A-CDM at London s Heathrow T5, on-time departures have increased from 60% to 85%. Improved resource planning enabled by A-CDM has improved passenger throughput in the terminal, and increased the efficiency of overall terminal operations. BPM tools and suppliers used Pegasystems SmartBPM Suite; Pegasystems consulting and implementation services.

3 BPM case study: BAA 3 Company background BAA is the UK s leading airport operator. It owns and operates a number of airports in the UK including London Heathrow, Stansted and Edinburgh. It also has interests in the USA (retail management at Baltimore-Washington, Boston Logan and Pittsburg airports). The company was originally established in 1965 when the UK Government s airports were privatised. BAA became a public company when it floated on the UK stock market in 1987; it delisted in 2006, prior to its acquisition by Spanish company Ferrovial, the world's largest private manager of transportation infrastructure. In 2008 the BAA s UK airports handled a total of nearly 146 million passengers, where it employs around 13,000 staff. Project background According to Eamonn Cheverton, Enterprise Architect at BAA, the airports business is a conservative one when it comes to implementation of new systems: although most systems aren t genuinely safetycritical in nature, the scale of operations at an airport like London s Heathrow means that systems problems can have very significant impacts on local infrastructure as well as on BAA s business for example a major systems failure at Heathrow can quickly lead to gridlock on one of the UK s largest motorways (which feeds the airport). For that reason, airports tend to upgrade their core operational systems only when change is to an extent forced upon them (by changing regulations, security requirements, or airlines requirements). In 2008 two catalysts for change came about, particularly in the area of operations. One was that the existing custom-built systems were rapidly approaching end-of-life; the other was the institution of a new European Union directive to drive greater interoperability of traffic control systems across European airspace (SESAR). BAA started by running a procurement project the scope of which covered operations, staff information systems, flight information systems, billing and airport planning that initially assumed the new operations system would be custom-built, just like its predecessor. Having found that all the bids were difficult to justify in terms of expense based on a comparison with an approach based on continuing to maintain the existing system BAA decided to look again at its requirements. A team of architects, led by Cheverton, carried out a business architecture exercise designed to map the high-level business domains, capabilities, services and processes within the scope of airport operations, and as this exercise unfolded it became apparent that many of BAA s requirements were actually generic demand- and capacity-planning requirements that were applicable across industries, not dissimilar to those typically addressed by some customer relationship management (CRM) implementations. An aviation-specific system was not necessary. With this insight, BAA then re-ran its procurement exercise, but this time it focused on BPM technology as the foundation for its replacement system rather than custom development. Nevertheless, pure BPM technology functionality was only part of the requirement; BAA also needed a platform that could be used to implement core system business logic and rules. Implementation characteristics and status BAA chose to work with Pegasystems as a result of its second procurement exercise, and is working with the supplier on a number of projects that together will form an end-to-end operations system. To date, the most significant application that s been deployed is the Airport Collaborative Decision Making (A-CDM) system, which is focused on managing the turnaround of aircraft from arrival to departure.

4 BPM case study: BAA 4 Managing the turnaround of aircraft is a complicated real-time optimisation exercise that has to be carried out in the context of a number of constraints including security (some airlines aircraft can only be parked in certain locations) and stand sizes (not all stands can accommodate the largest aircraft) and of course the availability of airport resources. Within the system, each aircraft turnaround is handled as a case, and in order for case work to be completed the system drives collaboration between a number of human participants (such as flight crew managers, refuelling and cleaning crews) and systems (such as air traffic control). Using sophisticated sets of Pega rules, the system schedules departures and arrivals to minimise the time each aircraft spends on the ground, stationary or taxiing. Behind the scenes of each turnaround case, the A-CDM system uses the concept of resource plans to co-ordinate the management of resources (stands, gates, security, check-in desks, aircraft, and so on) that need to be available in order to take a flight from arrival to departure. Before the implementation of the A-CDM system, airport resources which all had to be co-ordinated in order to optimise airport operations were all managed by teams that were organised within separate lines of business. A-CDM resource plans create one place where the management of these individual resources is brought together. What s more, resource plans have to be dynamic because the airport s operating environment is dynamic. Passenger volumes spike, security threats come and go, and weather patterns change, and all these things and more have an impact on the availability of resources. A-CDM uses the concept of Defcon levels, each of which represents a certain level of stress on airport resources. Each level is associated with sets of policies that themselves affect resource allocation; a monitoring tool actively manages Defcon levels in order to keep automated resource allocations in line with the overall operational environment. Since the deployment of A-CDM, BAA has also used Pegasystems technology to deliver smaller applications focused on Works Approvals permits management and asset data validation. The approach As mentioned above, when it comes to the implementation of new core operational systems BAA is by necessity conservative. Despite this BAA has embraced Agile methods for software delivery, and it s applied those techniques to the development of -CDM and the current projects underway to deliver the broader Real-time Heathrow operations vision. Strategy BAA doesn t consider BPM in itself as a strategic activity; however Pegasystems BPM technology is absolutely core to the way that BAA is committing to deliver operational improvements to airlines and passengers through A-CDM and, ultimately, the Real-time Heathrow programme. Architecture Architecture work, with a particular focus on business architecture, has been absolutely fundamental to the delivery of A-CDM and the Real-time Heathrow programme so far. Without work on a business capability and service map, Cheverton and his team wouldn t have been able to embark on a systems replacement programme like it has done. The architecture team used the NATO Architecture Framework (NAF) as the initial blueprint for this work, as it was mandated by the European Union for the implementation of SESAR, of which A-CDM is a deliverable. What s more, BAA s business architecture effort continues to inform the development of the Realtime Heathrow initiative primarily by highlighting which functional components need to be shared across multiple business capabilities and services, and should therefore be designed for reuse. At the same time, BAA s SOA effort which has been in place for a number of years and mandates the integration architecture for all systems needing to connect to others, including a canonical data model for integration based on standards specified by OASIS, IATA and others.

5 BPM case study: BAA 5 Organisation and people BAA s risk-averse approach to core operations systems development has led it to commission Pegasystems to carry out all the detailed implementation work, but nevertheless the effort is a collaborative one. BAA provides projects with IT architects, business analysts and project managers (following the Scrum method). All development work is marshalled into 42-day sprints, with no project allowed to have a budget of greater than 75,000. Business stakeholders have regular hands-on involvement in development sprints: at least once a week, they re involved in progress reviews. BAA uses Pegasystems own project management and test management frameworks within sprints, and it uses Pegasystems Direct Capture of Objectives (DCO) application to work collaboratively with business representatives during each inception phase (which kicks off each set of three sprints and is designed to prioritise the work backlog and individual software requirements). Although Pegasystems is responsible for carrying out the detailed implementation work, key BAA staff have taken Pegasystems training specifically so BAA could be confident it was acting as an intelligent client (asking the right questions and making reasonable demands of its supplier). BAA s own people manage the overall delivery of on-site training to internal staff, with BAA providing programmespecific architecture orientation and training, and Pegasystems providing detailed training elements specifically focused on use of DCO. Prior to the start of BAA s relationships with Pegasystems it was already familiar with the use of Scrum, but it s found that in order to consistently deliver results with a mixed in-house / third-party team it s had to weave a lot more formality into its Agile approach. What s more BAA has found that to really get the benefits of the Scrum approach in development, it s had to reengineer the IT management processes that fit around development (for example portfolio management, deployment, testing and so on). Governance Although the wider Real-time Heathrow programme is still under construction, BAA has already had to manage significant change to the released A-CDM system and to the new elements in development. Some of this change comes about through new user requirements, but much of it is due to architectural or technology platform change. At the same time as it has continued releasing functionality, BAA and Pegasystems have upgraded the underlying technology platform twice and overhauled the user look-and-feel once; the team has also had to re-engineer its integration code a number of times due to changing data object structures mandated by its airports integration architecture standards. With all this change in its technology environment, BAA has to have a very structured approach to change management. Changes to new requirements or to released system functionality are managed in a governance layer that wraps around BAA s Agile software delivery method; a formal change control process, with involvement of IT architects and business analysts, prioritises change requests and interleaves them with the Agile backlog to insert their implementations into future development sprints. Reusability is also a key goal of BAA s governance approach. Its business architecture foundation, started in 2008 as part of the initial technology procurement exercise, continues to highlight components that should be designed for reuse. The architecture team manages its business architecture capability and service maps outside Pegasystems tools, using the MEGA Suite. Technology and infrastructure Pegasystems technology forms the core of the A-CDM system, and of the wider TAM implementation programme. The A-CDM user interface combines Pegasystems technology with Microsoft SharePoint, and back-end integration with external systems is managed via Oracle s WebLogic application server and Progress Software s Sonic Enterprise Service Bus (ESB).

6 BPM case study: BAA 6 For Cheverton, standards are important in BAA s efforts but they re not to be followed slavishly the key is fitness for purpose. For example, as we ve mentioned above, BAA has borrowed from the Nato Architecture Framework (NAF), IATA and OASIS in its high-level architecture work; in addition, it makes a lot of use of web services and XML standards in its integration technology layer. But when it comes to modelling, the company is not pursuing BPMN for the sake of being standards-compliant: it s found that business representatives don t find BPMN models easy to understand, so it s using a lightweight cut-down modelling notation that it s derived itself. As far as BAA is concerned, the key is to have a consistent approach to modelling that everyone can buy into. And because development work is being driven by Pegasystems rather than BAA, any potential hiring constraints that might spring from not using BPMN are avoided BAA has ensured that Pegasystems developers are happy to work with the modelling notation it s settled on. There s one other technology-specific note particularly worth taking about BAA s implementation with Pegasystems: BAA has mandated that the Pegasystems developers it contracts must not write external compiled code as workarounds. Rather, they must use generally-available functionality within the Pegasystems platform for implementation of all features. The reason for this is that having made a conscious decision to avoid going down the custom development route for A-CDM, BAA does not want to end up with a system that relies on custom proprietary code. In Cheverton s words: We have a horrible history of complex, expensive package upgrades because we ve used custom code to tailor what we ve bought. We want to avoid this in future wherever possible. The results Since the A-CDM system has gone live at London s Heathrow T5, BAA has managed to increase ontime departures from 60% to 85%. This means BAA pays fewer penalties. Improved resource planning enabled by A-CDM has improved passenger throughput in the terminal, and increased the efficiency of overall terminal operations. Recommendations for BPM adopters In carrying out this case study, we asked representatives from BAA to share any recommendations they d offer to other potential BPM adopters. Eamonn Cheverton offered two points in particular: Firstly, make sure that before you start any BPM effort you have in place a solid set of business architecture reference models (particularly models that capture definitions of business services and business capabilities) together with a well-defined performance framework that identifies stakeholders responsibilities and associates these with business change goals and priorities. By providing a clear context for business changes, these models help to inform business cases and tease out change project benefits, costs and risks as well as clearly identifying those who will have to play a role in project success. Secondly, before you choose a BPM technology provider, you should carry out serious tests to see which providers can support your change needs. Cheverton advocates conducting a two-day cookoff process. In this process a number of vendors are first invited to implement a set of proof-ofconcept requirements, and then, on the second day the requirements are changed without prior warning. The process helps identify which vendors tools are really able to support rapid change.

7 BPM case study: BAA 7 Best practice insights Through the implementation of A-CDM and the ongoing development of the Real-time Heathrow vision, BAA has demonstrated two best practice insights that you should think about in the context of your own implementation: Don t carry out process analysis and design as a standalone exercise; make sure that all the relevant stakeholders have a consistent understanding of the wider goals and context of the initiative. A business architecture exercise like the one carried out by BAA is a great way to not only create shared understanding to frame your BPM programme correctly, but also provide architectural principles that will steer ongoing development work to maximise opportunities for reuse (and therefore drive improved consistency and quality of the implementation). If you re using a third-party supplier to carry out the development work for your BPM implementation, strongly consider mandating an Agile method as the project management structure for delivering functionality and ensure that your key IT and business stakeholders (IT architects, business analysts, business managers) have regular opportunities to participate in priority-setting and reviews of deliverables. An Agile approach by your software delivery partner, with consistent engagement from your people, ensures ongoing recalibration and checking of development efforts which is particularly important in the context of using BPM tools, where new functionality can be delivered very quickly.