I’m in the first breakout session of PegaWORLD day 1, and decided to hear Colleen Dugan and Jeff Gallimore of Zurich Financial Services talk about their underwriting solution implemented on Pega. Their original Pega pilot implementation in 2008 was rolled out in 74 days, which is pretty amazing: I know that all the BPMS vendors claim that you can do this, but few large companies can even get the contract executed in 74 days, much less the first production solution. That was just the beginning, of course: they’ve implemented a number of initiatives across their North American organization since then, and a lot of their success has been due to business change management rather than just the technology.
They initially selected BPM as a technology for their organization for a number of reasons:
- Consistent workflows across the business.
- Realign work with roles, allowing centralization and offshoring; a big part of this was offloading administrative and support tasks from underwriters, allowing them to be more customer-facing.
- Transparency in transactions for improved customer service, which is especially important when the underwriter no longer does all of the work on a specific account or transaction; this allows anyone with an interest in the account or transaction being able to have visibility into it.
- Management tools for measuring and monitoring performance, including SLAs, cycle time, and individual/team productivity metrics; this also allows for doing some tasks based on predictions, such as doing the administrative preparation for an account before the underwriter quotes the work, based on the past history with the account.
There was some resistance from the underwriters who perceived this as losing control and gaining Big Brother, but eventually they saw it as a way to offload the work to which they didn’t add value, allowing them to focus on serving their accounts better. That transition took a lot of change management work: everything from having the right leadership through ensuring that the proper roles are defined.
They identified a number of critical success factors, most of which are related to their organizational change management:
- Fully defined and documented processes, both current and future state, allowing them to understand what is required for process improvement and transformation. In early cases where they plugged in BPMS before they did this, they just put structure around a process that didn’t necessarily work very well, or what we refer to as “paving the cow paths”. This also allows for identification of common processes across business units, which can significantly accelerate a technology implementation through reuse.
- Clearly stated objectives that are communicated across impacted areas, so that all business units and users understand why this is being foisted on them, how they’re going to benefit, and why this isn’t just another piece of useless technology that they have to learn. (I’m paraphrasing here).
- Engagement and buy-in of managers responsible for impacted areas, so that they understand both the higher-level organizational benefits as well as the individual team member benefits, and can be advocates for the new processes and technology.
- Front line user subject matter experts to participate in design: these are the actual business users, not business analysts (who often report to IT and have never actually processed a transaction themselves), allowing the technical design team to see how the new designs will actually be used.
- Fully defined change management strategy, more than just a communications plan.
They have developed a change readiness framework, focused on not implementing until they were “ready”, which is defined as the impacted audience being ready for change, having the support model in place, and sufficient confidence levels that benefits will be achieved. They consider seven areas of readiness on their checklist: process, people, product, market, benefits, training and technology.
In response to questions (but not as part of their presentation), they discussed a bit about the solution: a listener detects new email-based requests for renewals, endorsements and other transactions and creates a case in Pega, after which a person has to determine which work basket to assign each transaction – sounds like they could use some intelligent automated routing based on analysis of the email content. Once that initial intake has been done, however, BPM really shines in allowing them to split the work by role, send certain tasks offshore for cost reduction, and monitor everything that’s happening in order to ensure that work is being done effectively and within SLAs. Pega Professional Services did their first pilot implementation, but Cognizant is now their main Pega implementation partner.
Any user-facing BPM implementation changes the way that people work, and requires attention to change management. This was a great presentation on the change management factors that are often left unsaid in discussing BPM implementations, but can cause even a technically perfect project to fail.