This afternoon is all breakout sessions, and I started with Martin Venema of Royal Bank of Canada (the bank is a customer of mine, although it’s so huge that I’ve never dealt with his group) as he discussed improving customer service through rules-driven case management. Unfortunately, the wifi doesn’t extend to the breakout rooms so posting may be delayed, but at least I found a power outlet in this room. Also, he was introduced by someone who knew how to pronounce “Mississauga”, for extra bonus points.
RBC has implemented 3 different Pega applications, although Venema focused on only one of them, for handling client requests.
Their case for change came from problems dealing with client requests: someone in a branch can’t answer a client question, and needs to pass that question along to someone in a back office fulfillment group. However, there were 21 different ways to get to those back office groups — email, e-forms, fax, phone — and since there was no way to track the requests once they’ve been sent off, there was a 20% duplication rate. A new branch employee had to figure out which group to send it to, how to send it and which form to use: a daunting training task.
Their goals were to improve their clients’ experience, but also to make it easy for the front-line staff to manage and route client requests. For the first goal, they wanted to be able to provide clients with a service commitment that allows them to track their request and anticipate the future steps and parameters in the request process. For the second goal, they wanted a tool that could just figure out where the request should go, and provide notifications and tracking of the requests.
What they ended up with was a system that provide a single point of entry for client requests, which then used business rules to automatically route requests to the correct group for resolution. In the fulfillment groups, it provided standardization of processes (woo hoo! someone else who says “proh-cess” instead of “praw-cess”), workload balancing across geographies, and skill-based routing.
Cost reduction, cost avoidance, increase revenue and intangible factors all contributed to their business case; interestingly, the cost factors weren’t enough, and they needed to bring in the increased revenue factors such as enhancing customer loyalty in order to justify the initiative.
Under cost reduction, they considered:
- Reducing staff costs, by reducing manual interventions as well as internal tracking phone calls and emails
- Increasing productivity/improving efficiency by reducing rerouting by sending requests to the right place based on business rules, reducing duplicate requests, and integrating back-end systems to auto-populate information into the request form
- Reducing error handling by removing paper processes, adding validation and coaching tips (to help front-line staff to use the tools and potentially to resolve the problem on the spot), and standardizing the processes across geographic regions
Bill payment investigations, for example, was able to eliminate 4 FTEs; other processes saw similar gains due to cost reduction factors. Due to the high turnover rates in the fulfillment groups, they didn’t need to do any mass layoffs for the first phase, although the subsequent phases may cause deeper cuts.
RBC’s marketing analytics group has some pretty good measures on how customer loyalty translates to revenue increase: a top score on loyalty (willingness to recommend) leads to a 6% increase in client profitability. Furthermore, a top score on problem resolution generated more profit since the customers are less likely to move financial institutions, and may even increase the number of products that they hold with RBC. That means that even if there are problems with a client, if it’s resolved to their satisfaction, then the client loyalty (and therefore profitability) will increase; if not, then the client is much more likely to change banks.
He went through some pointers for how they engaged the business stakeholders, then discussed their incremental implementation approach. Their first implementation of CART (Client Action and Request Tool) was a single e-form that could initiate 18 different processes for personal deposit account problems. This took about eight months to develop, and was rolled out to 30,000 users in the branches and call centers, and impacted two fulfillment groups when it was rolled out in May of this year. The next phase will ramp up to about 500 different processes. He admitted that they had a typical waterfall development methodology in the past, and had a bit of trouble moving to a completely iterative and agile approach right away; he believes that they need more of a hybrid approach to do this successfully, which is the same as I see in many organizations that have a long history of waterfall-style development.
Their early results:
- 20,000 new work objects created each month with no performance issues (I would be incredibly surprised if there were performance issues at this relatively low volume)
- Early adoption rate of >60% of staff with no formal training
- 20% reduction in number of requests reaching the fulfillment centers through elimination of duplicates and some requests being handled by the front-line staff member
They did learn that an iterative approach does work best in terms of selecting small, manageable deliverables. They’ve seen an increased demand for other BPM solutions now that they have something successful in production, and since the infrastructure costs are front-end loaded, subsequent implementations will be lower in cost than the first phase. Venema believes that they waited too long to involve Pega and their partner professional services, and could have accelerated the project further with earlier involvement. He also sees that they were somewhat unprepared for the second phase, and could have started some of that project work during the rollout of the first phase. They’ve created a center of excellence to ensure consistent practices and standards, including user interface standards, to allow for greater reusability.
Eventually, they’ll add in requests for other product lines, and expect to handle 3M work objects per year; simultaneously, there are other Pega projects happening simultaneously within RBC. They are training up some of their own staff for Pega development, and are using Pega professional services as well as a Pega partner. Their biggest staffing challenge, which they’ve had to supplement with external resources, is with finding or training Pega PRPC developers; they’re also finding gathering business requirements to be very time-consuming and want to move to the Pega methodology of directly capturing objectives instead of a more waterfall requirements process. He sees a big challenge going forward on the business side in terms of optimizing the processes so that they’re not just paving the cowpaths as they automate the processes.