Tag Archive: Information Technology System Assessment Selection and Implementation

  1. System Assessment, Selection & Implementation – Part 2

    Leave a Comment

    Series Overview

     

    In this blog series we will explore the full process that financial institutions face deciding on the best course of action for modernizing their current information technology. As with any complex situation it makes sense to it break down. By doing so we can readily understand the process and with this understanding we are better prepared to properly manage these individually.

    In our last blog, Part 1, we explored the primary driver of a system selection. In this section we will dive deeper into further defining what will be needed. We’ll continue to use same three examples from Part 1 so we can see the progression of each. You’ll also find some helpful examples!

     

     

     

     

     

    Part 2: Assessment

    System/Application Needs

    The term “system” typically implies that there are multiple IT components working together to achieve a goal. Conversely, the term “application” implies that there is one piece of software that is working to achieve its individual goal and it is not dependent upon another piece of software. With that said, a financial institution still must take the steps necessary to determine if the system needs to be replaced, should it be upgraded, does only an individual piece of software need to be replaced or upgraded, or perhaps is there a piece of software that is missing. The net result here is you must determine the actual need.

    Example 1: Convert vs. Upgrade

    In our first example the bank had made the strategic goal of increasing their customer base through enhanced products and services. They have also determined that they have an aged/aging system with an ever-increasing technology debt which in turn increases their technological risk. With these facts it’s now time to determine if their current core processing system will support the products and service they currently offer (aka current state) as well as those products and services they are targeting in the future (aka future state).

     

    The bank should perform a full inventory analysis of all current products and services. These should be broken down further into two separate categories of sustaining and retiring. While the sustained products and services will certainly have an impact on the what direction they ultimately select, upgrade vs. replacement, those that are targeted for retirement may also have an impact. For example, if a product is to no longer be made available the bank may choose or be required to continue the servicing of those products which have already been sold.

    As the bank continues to build upon this inventory analysis, they will also need to focus their attention on any products and services which they may be targeting for development. The analysis should be just as rigorous as with current products and services since their impact can be just as significant. While ability of a core processing system being able to support products and services that are not currently being offered speaks to the scalability of the system it should be noted that typically the more scalable a core processing system the higher the cost.

    For an example of an inventory analysis document click here.

    Example 2: Which Product to Choose

    As you’ll recall in our second example, we have a credit union with a highly outdated internet banking solution which is impacting the retention of the current members as well as negatively impacting the acquisition of new credit union members. The credit union has determined that there is certainly a need for updating this application to increase member satisfaction as well as aiding the marketing department efforts in acquiring new members.

    In my experience I have seen many financial institutions view this simply as a “low hanging fruit” opportunity, engage their current vendor, and implement what can become a substandard solution. This is a waste of time, money and will certainly underwhelms their members. In short, not enough time is spent in making sure that they are selecting the best possible solution for their specific needs. The organization either implements a solution which has way more functionality then they need which equates to a higher price. Or, worse, they implement an application that doesn’t provide all the functionality that they currently need or will need in the future.

    Just as in our first example the credit union needs to perform a full analysis of those products and services which they intend to deliver through their online banking platform. The key difference here is that they will need to focus most of their attention only on those products and services which are delivered to the members through their online banking platform.

    The credit union will also need to pay close attention to the services which are now provided from many vendors that now align with “internet banking”. For example, internet banking typically refers to a member accessing their share, draft and other account types via a home computer. Functionality can vary even in this space and close care should be taken when selecting the right product. An example would be “bill pay” which gives the member the ability to pay their bills (both internal and external to the credit union) electronically.

    Also, within the family of internet banking is mobile banking. This is the ability for a member to access their accounts via a mobile device such as a cell phone or tablet. While those that are less technically savvy will think that it is the same application it is important to understand that it is not. Vendors spend countless hours testing their mobile banking specific applications to ensure the best possible functionality across a plethora of cell phones and their respective operation systems (typically iOS and Android).

    While a project such as this can seem simple on the surface, we’ve only scratched the surface of the complexity that a financial institution can face when upgrading or replacing a mobile banking application. There are many other factors that need to be investigating such as with the bill pay module. Will the credit union offer the service of cutting paper checks for members to those organizations that do not accept electronic payment (yes, these types of place still exist)? Or, how will the credit union communicate and manage member expectations when they must change their login credentials for the new system?

    Along with the right technology vendor having an internal advocate that is experienced in these types of efforts is essential.

    Example 3: New Implementation

    In our third example we have a relatively large bank that is standing up a new commercial division. With the bank having already set their strategic direction and having defined and documented their “wants and needs” for their IT toolset provides us with the necessary building blocks to construct a solid foundation. Since this type of project is not single threaded but rather a woven tapestry it will be necessary to take a planned and deliberate approach to decomposing the IT toolset selection process.

    There will be a tremendous amount of data that will be collected and used in this process. To ensure none of that data is lost, misplaced or forgotten it is best to document each data point as thoroughly as possible. For this purpose, I recommend that a Project Handbook is created. This handbook is extraordinarily useful not only when selecting your IT toolset but will pay dividends when implementing that toolset and measuring the success of the IT effort. This workbook can also serve as the genesis for other documentation that will be needed in standing up a new division within your organization. For example, if constructed properly, the workbook can help to generate full business process flows and SOPs.

    I’ve used this handbook in many projects, and it is a self-contained document that contains many sections ranging from communications and risk management to business requirements. In the selection process the formalized and documented business requirements are invaluable. They allow the team to develop the wants and needs of the project into defined and measurable business requirements. These requirements can then be leveraged to develop RFIs and RFPs (Request For Information and Request For Proposal). Once a vendor is selected the handbook continues to deliver in being able to share this information with vendors to ensure their deliverables are well defined. The handbook also provides the team with a springboard for test cases and success criteria.

    Here is an extract from the table of contents of a handbook. The information contained within is invaluable to the success of any project but especially a project such as the one in this example.

    Conclusion:

    As with our last section you are probably seeing a theme in all the examples. If you only do one thing you must define and document what your organization needs to achieve success in your objectives. What differs slightly with each example is the level of complexity at which it must be accomplished. In our last example we discussed the use of a Project Handbook. What’s important to note here is that the handbook could certainly be used in each example it’s the art of tailoring the handbook complexity to match that of your project.

    Watch for Part 3 of this series when we will discuss assessing strengths and weaknesses and the important roles that they play in the entire process.

  2. System Assessment, Selection & Implementation – Part 1

    Leave a Comment

    Series Overview

     

    In this blog series we will explore the full process that financial institutions face deciding on the best course of action for modernizing their current information technology.  As with any complex situation it makes sense to it break down.  By doing so we can readily understand the process and with this understanding we are better prepared to properly manage these individually.

    While we will explore this process in consumable chunks this is not to say that each and every step, we navigate in this series is sequential.  In fact, many times, the steps can be accomplished in parallel.  It is up to the individual reader to make the determination of what logically must proceed and succeed any given step or what can be accomplished in parallel.  In most cases it is best to engage an experienced individual in helping you to navigate these waters.

     

     

     

     

     

    Part 1:  Assessment

    Organizational Vision

    When an organization undertakes, or even considers undertaking, an effort as complex as system modernization there is usually a driver. These drivers are as varied and include things like software going off vendor support, functionality hindering productivity, inability to support new compliance requirements, support for new products and services, acquisition of other businesses with differing systems to name a few. Instead, we’ll take a couple of examples that could be relatable to your particular situation and go from there. Regardless of the driver it is absolutely necessary that your organization determine your vision as it relates to the capabilities of information technology.When an organization undertakes, or even considers undertaking, an effort as complex as system modernization there is usually a driver.  These drivers are as varied and include things like software going off vendor support, functionality hindering productivity, inability to support new compliance requirements, support for new products and services, acquisition of other businesses with differing systems to name a few.  Instead, we’ll take a couple of examples that could be relatable to your situation and go from there.  Regardless of the driver it is absolutely necessary that your organization determine your vision as it relates to the capabilities of information technology.

    Example 1:  Convert vs. Upgrade

    In our first example we have a moderately sized community bank that is currently running an in-house core processing system that is approaching 10 years old.  Technology debt is piling up on this system and the IT leader has informed the other executives that it may be less expensive to simply convert to a new core processing system.  In addition, by following through on a conversion the organization could reduce its risk with an aged and continually aging system.  Finally, there may be some added value of additional functionality that comes with the system replacement.

    Who wouldn’t want to take advantage of saving money, reduce risk and adding functionality?  All these advantages may well be true, and we’ll talk more about these in “New System Need” section.  However, these advantages, on their own, should not be drivers to a core system replacement.  Instead, an organization must broaden their view on technology.  Technology, while certainly powerful is a tool and should be viewed as such.  Any bank should determine how and when technology will help them achieve their goals.

    Let’s say our bank has made the strategic goal to increase their customer base.  They intend to achieve this goal through increased community outreach, additional product offerings, and enhanced services.  Now this is something that technology, as a tool, can help achieve!  Having the right core processing system that supports the latest, greatest and most in demand products could be key to reaching this goal.  Further, having the right technology and technology partners in place could certainly help in the community outreach arena.  Finally, technologies are tailored made for the service offerings.

    The point here is make sure that the business strategies are driving the tool and the tool isn’t driving the business strategy.

    Example 2:  Which Product to Choose

    For our second example we’ll look at a credit union that has a relatively new core processing system but a highly dated internet banking solution.  This solution only provides their member base with the minimal of functionality.  For example, when a member logs into the application they can review their account balances and see the transactions which have impacted their internal accounts.  Essentially their online banking application is an “electronic checkbook ledger” and it lacks what is now standard functionality.  It is surely impacting their members and they are probably losing members as well as having difficulty in gaining new members.

    There are so many options when it comes to digital banking.  In this case it is imperative that the credit union make the right choice when selecting their new digital banking platform.  The credit union should be looking at the outside drivers to determine the solution which is right for their members.  For example; is their member based geographically disbursed?  Is the credit union considering adding new products in the near future which may impact the type of functionality that will be needed?  Is the credit planning on targeting different types of members (i.e. consumer vs. commercial)?  What type of requirements does our current core processing system have, if any, regarding a digital banking platform?  The list goes on and on, but these are the things that must be considered.

    Example 3:  New Implementation

    In our final example we have a relatively large bank that currently focuses on consumer customers but is starting their expansion into commercial customers as well.  This effort is going to have a huge impact on the organization and making sure that it is successful is on everyone’s mind.  The executive team has already laid the foundation for one of their most important assets in ensuring success and that is the employees which will drive and sustain this new division of the bank.  They have also laid out the products and services they intend to provide to their new client base and have already started the marketing and business development cycles.  The only thing left is making sure that they have the right technology tools in place.

    In this case the bank has already set their strategic direction and has a very well-defined set of needs and probably wants that can be used in the technology toolset selection.  In order to even start the next phase of the selection process it will be important that they address each of these wants and needs in a systematic way to ensure that none are inadvertently left behind.  Since the strategy is set and the needs/wants determined it would be best for this organization to capture each of them in a categorized way.  For example, categorizing these items by the system/application that will support them will help ensure that each is addressed in turn.

     

    On this topic the one thing that people get hung up on is having a single need categorized into multiple categories.  This is normal as the categories are almost never mutually exclusive.  For example, there may be a need which easily fits into the tool categories of core processing and remote deposit.  This natural and it should be noted in each category.

    Conclusion:

    You probably see a theme in all the examples and that is your organizational vision should drive your decisions.  It is illogical to have your tool drive your vision or direction.

    We’ve seen many organizations wrap their organizational direction and business processes around tools.  This is akin to using Microsoft Excel to balance the bank daily simply because they already have the tool in place.  Excel is an extremely helpful tool and I’ll be the first to admit that I’m an Excel junky.  Heck, I’ll also admit that using Excel to balance a bank is better than the ledger books and adding machines of yesteryear.  But wouldn’t it be so much easier to a purpose-built general ledger application that is tied to all your applications?  Sure, it would!

    In our next segment we’ll explore the process of matching our organizational vision and direction to system and application needs.  We’ll even look at how we get a few wants for little to no extra financial burden and even provide some easy to use templates.  Stay tuned!