BEAParticipate: BPM 101 for Portals

For the first breakout session, I attended BPM 101 for Portals to hear Jesper Joergensen of BEA’s product marketing group and Bob O’Connor of Pratt & Whitney. Jesper started out by giving a brief review of BPM (the usual model/execute/analyze/optimize cycle), since this session is in the portals track and most of the audience is likely much more familiar with portals than with BPM. However, since the description claims that he’s also going to discuss how process and portals can work together, I want to hear their message on this since I’ll be speaking about BPM at a portals conference in two weeks.

O’Connor then told us about how Pratt & Whitney is using portal technology and — soon — ALBPM. They’ve had a customer portal since 2001, but had a lot of business processes that didn’t mesh together very well. In 2002, they added SOA functionality that allowed data to be pulled from multiple systems and presented to the customer, such as all maintenance information for a specific engine based on the serial number. In spite of their advances in their customer portal, however, they still had a number of disparate departments with their own business processes, and no real end-to-end enterprise view of processes. That means that lag time between the separate processes wasn’t necessarily logged as part of the end-to-end cycle time for an engine overhaul, for example, but definitely impacted the customer. Since it was between processes, that time was no one’s responsibility until they started looking at business processes as they span the enterprise, not just within functional silos.Today, they’re doing “manual BPM” for collaboration around engine overhauls, where 1000’s of process steps and approvals are logged and uploaded so that customers have a near-real-time view of the overhaul process.

For the past year, they’ve been working with ALBPM (although they’re just starting to roll out BPM applications), and see great potential value from combining ALUI and ALBPM to automate the processes using BPM and provide the necessary visibility into those processes via portals. Their initial processes include line maintenance order-to-cash (where any delays in the process severely impact the customer), quality process clinic management, help center routing, overhaul records coordination, employee awards, engine events management, engine wash, and shop processes. Some of these smaller processes took only a day or two to create in ALBPM, while their internal IT had quoted several months and several hundreds of thousands of dollars to do the same thing. They’re pulling data from SAP and other enterprise applications into ALBPM at the start of the process, then feeding back any updates at the end; I would have thought that they’d use web services for at least SAP in order to do interactive updates rather than have to deal with the potential for mis-synchronization between BPM and the back-end systems.

They’re doing some pretty innovative combinations of technologies to shorten maintenance cycle times, for example, RFID and other sensors to detect any engine problems while a plane is still in the air allow dispatching of maintenance personnel to be at the site when the plane lands. The time to service the engine may be the same, but the down-time for the aircraft is greatly reduced, which shows a commitment to their customers’ concerns.

O’Connor, as a BPM department of one person, is part evangelist and part BPM developer (without having much of an IT background), helping to figure out how BPM can be used across Pratt & Whitney and help implement the solutions.

Although this presentation was really about BPM, I can understand why it’s in the portals track: since Pratt & Whitney was a big portals customer first, this shows how you can successfully add BPM to a portal environment.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.