I attended a breakout presented by TD Bank (there was also a TCS presenter, since they’ve done the implementation) on their workflow system for customer maintenance requests – it’s a bit of a signal about the customer, and possibly the SI, that this is called “workflow” – and how they have implemented this using Pega. They started with PRPC 6.3 and there was no indication that they’ve upgraded to Pega 7, which would give them a whole raft of new functionality.
Customer maintenance requests include any non-financial transaction that a customer may request, such as an address change, which may be fulfilled either manually, semi-automatically, or automated based on Pega business rules. They’re measuring the ROI primarily in terms of improving efficiency (increased throughput, reduced processing time, reduced paper) and improving quality and regulatory compliance (reconciliation of work received and processed, data capture validation, identification of trends, better reporting to compliance). He did mention the improved customer experience, although mostly in terms of the call center/branch staff rather than the actual customer, but turned that back to branch efficiency and productivity. There was a mention that this would result in lower wait times for customers while they were in the branch making the request, but this is so far out of touch with the realities of customer experience these days, as evidenced by the keynote that we saw this morning with AIG and RBS. This was (I think) a technical presenter from TCS going through this part, but depressing in the lack of awareness of how far they are from understanding the customer journey. This is one of the dangers in treating internal stakeholders as the customer rather than having an awareness of the actual customer and their requirements: the internal operations customer is mostly motivated by improving efficiency and compliance, not making sure that their real customer isn’t walking out the door and goes to a bank that pays attention to their needs. We can’t throw away the concepts of efficiency and compliance, but I find in dealing with my banks (yes, more than one, because none of them give me everything that I need) that there are still too many processes that require my presence in a branch, a physical signed document or a call to a call center, when they have already authenticated me in so many ways online already.
They talked about their development process and some of the best practices and lessons learned: allowing time for visual screen mockups during inception in order to reduce rework later (they seriously didn’t know that?), participation from other groups such as application integration (?!), and including a Pega deployment architect to make sure that things get into production the right way. TD Bank has been using Pega for about eight years, and they seem to be rooted in older versions and older development methodologies. Definitely in need of some digital transformation.
I didn’t attend this session with the goal of poking fun at TD or TCS, but this is really an example of old-school (probably waterfall) development methods that is not going to give them big wins in the long run. It’s clear that there is very deep integration with their other systems, and a lot of use of the Pega CPM framework and rules, but also that there has been a lot of custom work here: PRPC used as an application development tool. This is pretty typical of what I have seen with Pega customers in the past, although their recent shift to providing applications rather than frameworks is an obvious strategy to move to less-customized solutions that can be deployed faster. For the customers still plugging away on 6.x, that might be more of a dream than reality.