An RFI is circulated to several companies. Then an RFP is sent to the select few that seem capable of doing the job of migrating the bank from the, now perceived, old dinosaur to their platform advertised as supporting the latest-and-greatest of technical goodies and being able to drive customer innovation to new unheard-of heights. Committees form to evaluate the responses to the RFP. Vendors drool over the possibility of a new customer, especially if the customer currently uses the arch-enemy's product. Discounts rise to unbelievable heights. The bank negotiates the hell out of the deal.
The bank typically pays attention to the following items:
- Budget. These days, this is one of the most important factors in shaping a decision.
- Vendor capability to execute. Regardless of the value of each product, great attention is being paid at the ability of the vendor to present and execute a good migration plan that minimizes the risks as much as possible.
- Vendor product, customer references, vision and fit. All vendors advertise their product as being the best on the market. But is the product a good fit with the bank? Does the vendor have a product vision? Are there enough positive customer references?
It's a time of change. And a great opportunity for the bank to look hard at some of the existing processes, procedures and infrastructure. I almost always advise against introducing unnecessary changes during a large scale project. Most of the time, changes introduce some level of risk and nobody likes that. However, a radical case such as migrating from a payment system to another offers some opportunities that are simply too great to pass up.
Perhaps the single, most important thing a bank can do at this point is re-evaluate some of the things they do and, most importantly, examine why are they doing them in the way they do. It can be pretty amazing to discover that some things just happen in a certain way because someone was used in doing them that way two systems ago. Or that some manual and/or tedious process can be automated or simply removed because of the architecture of the new system. That's the reason business solution specification cycles tend to focus on the "why" instead of the "how". The question "why is this process in place" is always very important.
Other, more technical, matters can be closely examined during a migration. It is always advisable to try and play by the rules of the new system and not against them. This might necessitate changing a few existing interfaces or alter some existing process to better fit the new system. A good example that comes to mind is the way the host system communicates with the payment system. More often than not, the host uses an application protocol that does not resonate well with the new system designers (especially true for stream protocols with new systems that favor ISO-style protocols). In my experience, re-programming the host to make it understand a modern protocol is always a dreaded exercise. But it's worth it in the long run. Having the new system implement a custom protocol is certainly doable but the repercussions of such a decision will be felt for years - possibly for the duration of the lifetime of the new system. Choosing the modern application-level protocol of choice of the new system that is seamlessly and continuously upgraded to cater for new needs may require an expenditure of a few hundred man-hours of host programmers. But in the years to come no one will have to worry again about protocol translation, mapping and all the related headaches of such maintenance exercises.
Other systems, in production or planned, could also be examined and amended to be as compatible with the new system as possible. As a rule of thumb, new systems tend to offer way more integration options than older systems. It might be a good idea to try and take advantage of this resiliency and avoid ugly hacks that were necessary in order to play with the old system but are now obsolete. Example: channel integration. Older systems usually treated channels very differently according to their capabilities. The result is that newer channels have a hard time communicating with the payment system, making it necessary to resort to weird workarounds. Internet and MOTO channels might use a standard POS interface to send transactions because that was the only way to do it. But if the new system offers a simpler and standardized way to achieve the same result, it's better to bite the bullet now and do the change to use that interface than to suffer from the shortcomings of the old interface forever.
I'm obviously not advocating a complete re-engineering. The norm should be the payment system bending over to cater for the needs of a bank and not backwards. But this rule should not be always be blindly applied to everything. There will be situations where change, especially in existing processes that are not transparent to the end users, could be beneficial to the bank.
