By Kay Winkler

 From the book:

 BPM in Financial Services th large






Having played an active role in the evolution of BPM as a methodology since 2004 in Panama, Central to South America and the Caribbean, most of our team members at NSI Soluciones (NSI) have had the unique opportunity of being able to observe and to even be part of most BPM implementations in the local and regional banking cluster.

As of 2013 there are 92 different banks in Panama alone. (Superintendencia de Bancos de Panamá, 2013)


Figure 1 - Banks in Panama; Winkler 2013
After more than 150 process optimizations and implementations within about 8 years, there has been a clear "to-be" process outline and repeating methodology pattern that we have detected and that we are sharing with the reader during the following paragraphs and succeeding posts, specifically for process implementation in the retail banking sector.
Rather than trying to establish "best BPM practices" the intent is to share designs and practices that have proven to work well for us (so they may do as well for the reader), and to provide an initial step from where the community is invited to contribute further improvements, alternatives and components to the processes in question (or to propose new processes altogether).

Methodology Summary

Based on practices such as the ABPMP (Association of Business Process Management Professionals, 2013) CBOK, PMBOK (Project Management Institute, 2013) and Prince2 (Prince2, 2013), NSI defines a BPM project as a compound consisting of up to 7 different project phases that typically covers 1 rotation of business process management cycle (Winkler, BPM Leader, 2013), starting at "model" for new implementations or at "optimization" for continued BPM improvements.
Figure 2 - Continued process goals, Winkler 2013
The BPM project phases are as follows:

1. Project Discovery Workshop (PDWS)
During the PDWS we map out the broader macro process inventory (as-is), covering part of the end user's operation or the whole process infrastructure.

2. Operational Analysis
During this phase, now with a specific and a single process for each project in mind (several parallel projects can be executed at the same time in case multiple processes have to be automated), a detailed operational analysis of the situation as-is and to-be is being executed.

3. Technical Analysis
This phase is dedicated to detail the previously documented operational aspects of the process to-be on a technical level.

4. Execution
During the execution, the BPM solution itself gets assembled, using the operational and technical design documentation as inputs and the test matrixes as pre-UAT quality control.

5. UAT and Coaching
The already existing and approved testing matrixes will now be executed by teams from the end user in typically 3 cycles - UAT, SIT and OAT.

6. Roll Out
This last phase for implementing the process solution usually consists of very few activities and typically does not take more than 5 workdays.

7. Continued Process Improvements
After go-live, which usually occurs on a monthly basis, the process indicators will be measured together with the process owners. As result of these indicators, the process will be continuously enhanced, adapting the process flow sequence, rules, policies or forms.


Process Components

As almost all human-centric business processes, retail banking processes too, abide to the following simplified process activity step structure:
- Request – Review – Approval – Execution – Closure (incl. QA)
For mission critical retail banking processes (normally sales processes for consumer loan products), it typically looks like this:
Figure 3 – generic retail banking process, Winkler 2013
Banks usually decide on including a dedicated step for the first "touch point" with the customer, capturing only the most crucial and basic information that is needed to emit an initial quote, and thus interesting/capturing the prospect customer. Once the prospect is apt and interested, a formal request takes place where all the KYC, credit bureau and blacklist validations are being executed. Depending on the validation results, the initial quote and obligations for the prospect may change – the approval step in that relation is meant to be a negotiation point where both parties, the bank and its prospect, agree on the terms and figures of the requested credit instrument. Post decision, most retail banking processes encompass a series of physical logistical tasks, depending on the approved product and bank type that range from the delivery of legal documents such as contracts to the capturing of signatures among others.

Also, depending on the product the bank's customer has acquired, there are follow up activities that assure the continuity of the customer's initial "credit profile" (especially for products with a long lifecycle like mortgages). Formalities also include the loan payments themselves.

The process closure steps are normally intended to provide a balance for personalized customer contact (since most of the initial steps where communication in manual processes occurs, will now have been automated) and perceived quality measure points.

Since it is recommended (whenever possible) to break a BPM process solution down into fast but feasible deliverables, borrowing programming and testing sprints from SCRUM (SRUM.ORG, 2013) concepts, retail banking processes are generally implemented as 2 main components.


Time-to-Yes (TTY - simplification) 

Figure 4 – TTY, Winkler 2013
Time-to-Cash (TTC - simplification)


Figure 5 – TTC, Winkler 2013 


A scaled (2-fold in this case) go-live with the TTY and TTC process components has shown that associated BPM project times can be maintained at 8 to 12 working weeks per process component, even for complex retail banking processes that are both policy and integration-intense. 

It has to be taken into account and planned for, however, that each go-live will require a repetition of project phases 4 to 7. Project phases 1 to 3 can be executed for all process components at once.

Process Policies


By far, the most complex pieces to the "retail banking process puzzle" are the process policies that will have to be automated to an important degree. Some of these automations will take place within credit scoring systems (integrated to, but independent from the BPM implementation) while some of them will reside on the very process flow and process form level.


Figure 6 – Policy evaluation, Winkler 2013


As the figure above shows, the evaluation of retail banking policies doesn't only take place within different layers of the solution (within forms, process flow and third party applications like credit scoring systems such as Experían) but also among different process steps with gradually increasing levels of severity and rigor the further the process progresses, being the payment steps over the point of no return.

Vertically, the (simplified) policy validation of a retail banking process distributes as follows:

Figure 7 – Vertical policy evaluation, Winkler 2013
The most complete, complex and thorough policy validation of those processes usually occur in the first 2 process steps:
Figure 8 – Quick Quote policy evaluation, Winkler 2013
Figure 9 – Request policy evaluation, Winkler 2013
How the BPM methodology, process components and policies translate into actual retail banking process designs, and which considerations have to be made will be shown in the following posts, starting with Credit Card Request & Approval processes.