Upcoming Forums:

BSA-Fraud

  • Oct 17 - 18, 24 - TBD,
    [Register]

  • Apr 10 - 11, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Business Banking

  • Jun 6 - 7, 24 - Charleston, SC
    [Register] [Agenda]

  • Dec 9 - 10, 24 - TBD,
    [Register]

  • More Forums and Site Info:

Call Center

  • Sep 19 - 20, 24 - TBD,
    [Register]

  • Mar 27 - 28, 25 - TBD,
    [Register]

  • More Forums and Site Info:

CCO

  • Apr 29 - 30, 24 - Scottsdale, AZ
    [Register] [Agenda]

  • Oct 21 - 22, 24 - TBD,
    [Register]

  • More Forums and Site Info:

CEO

  • Jun 2 - 4, 24 - Charleston, SC
    [Register] [Agenda]

  • Sep 8 - 10, 24 - TBD,
    [Register]

  • More Forums and Site Info:

CFO

  • Sep 5 - 6, 24 - Denver, CO
    [Register] [Agenda]

  • Jan 30 - 31, 25 - TBD,
    [Register]

  • More Forums and Site Info:

CIO

  • May 30 - 31, 24 - Scottsdale, AZ
    [Register] [Agenda]

  • Dec 12 - 13, 24 - TBD,
    [Register]

  • More Forums and Site Info:

Commercial Banking

  • May 6 - 7, 24 - Boston, MA
    [Register] [Agenda]

  • Oct 31 - 1, 24 - TBD,
    [Register]

  • More Forums and Site Info:

Digital

  • Sep 26 - 27, 24 - TBD,
    [Register]

  • Apr 3 - 4, 25 - TBD,
    [Register]

  • More Forums and Site Info:

ERM

  • May 23 - 24, 24 - Denver, CO
    [Register] [Agenda]

  • Nov 18 - 19, 24 - TBD,
    [Register]

  • More Forums and Site Info:

HR Director

  • Sep 30 - 1, 24 - TBD,
    [Register]

  • Apr 7 - 7, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Marketing

  • Sep 18 - 18, 24 - TBD,
    [Register] [Agenda]

  • Mar 26 - 26, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Operations

  • Sep 23 - 24, 24 - TBD,
    [Register]

  • Mar 31 - 1, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Payments - Forums

  • Jun 10 - 11, 24 - TBD,
    [Register] [Agenda]

  • Jan 27 - 28, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Retail Banking

  • Sep 16 - 17, 24 - TBD,
    [Register]

  • Mar 24 - 25, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Third Party Risk

  • Jan 23 - 24, 25 - TBD,
    [Register]

  • More Forums and Site Info:

Treasury Management

  • May 2 - 3, 24 - Scottsdale, AZ
    [Register] [Agenda]

  • Oct 28 - 29, 24 - TBD,
    [Register]

  • More Forums and Site Info:

Wealth Management

  • Sep 12 - 13, 24 - Santa Fe, NM
    [Register] [Agenda]

  • Feb 3 - 4, 25 - TBD,
    [Register]

  • More Forums and Site Info:

BirdsEye View

loan automation system implementation best practices

 Producing loans, from application to disbursement, has been a gnarly process in our industry for generations.  Many banks have realized that, and are determined to fix the problem: streamline and automate the process, preferably cradle-to-grave.  Improving the process will yield not only efficiencies and better accuracy, but will also increase a bank’s competitive position due to faster decisioning and funding.

The idea sounds great.  There are also a few vendors which developed acceptable LAS solutions.  The problem is, I am yet to hear of a single positive comment about implementation.  Many other excellent systems, such as Actimize or Salesforce, entail major implementation pains.  None rises to the level of these systems. 

Examining the root causes for such painful implementation is a worthwhile effort that bears fruit not only with respect to LAS but other system implementations as well.

In response to these challenges, we recently started a new Forum which focuses on process automation best and worst practices, with special emphasis on Commercial Banking and Treasury Management.

The information exchange and lessons learned at the meeting were remarkable.  The conversation was anything but a complaint session.  Attendees were sincere in their sharing of excellent ideas as well as dismal failures, none of which had to do with the system itself.

Some of the lessons learned are shared below, but truly there is no substitute for the open exchange at the meeting itself.

When initiating a process automation program, followed by transitioning from planning to implementation execution, certain themes and guiding principles have proven to be critical to the overall success of the program.

1. Project initiation.

Lack of vision.  From the project onset, the definition of success is not clear.  This isn’t simply about scope creep; it is about what we want to accomplish with this massive investment of time, mindshare and money.  Efficiencies typically come to mind first, but, in reality, the goal is much broader, and always includes customer experience aspects, employee experience components, process rationalization and streamlining, error reduction, as well as creating momentum for change management.

Lack of specificity in goal setting.  A natural follower to the first point, project success depends on clarity of goals.  For example:

o If shortening turnaround time is the goal, where are you at today and what is your turnaround time goal?

o If the process has 200 steps today, hot many should you have at process-end?

o Are you contemplating a self-service component for the customers?  If so, what are the key elements in that vision?

Unrealistic investment expectations.  The cost of the system goes well beyond the software and licensing costs.  Budget for system administrators, PMO staffing, IT experts, data stewards and other system support investments necessary to ensure effective execution and full system utilization.

Scalability.  Some feel that scalability is more important than efficiency.  Establishing one way of doing things, reporting and accounting for activities and transactions, a single source of information, is immensely valuable to growing companies, and should not be underestimated or compromised.

2. Preparation.

Do your homework before implementation begins.  Gain deep understanding of your current state (people process, technology, data).  Knowing your own limitations will help you develop realistic expectations of what the new solution can do for you and will help you shape the target future state.

Form program infrastructure early, focusing on project management, legacy systems knowledge and change management competencies.

Establish strong implementation and program governance to facilitate transparent, timely and effective decision making.  Identify the four key roles:

o Executive sponsor – the person in charge of the entire project and is responsible for its success but not necessarily its execution

o Project manager – the person who is responsible for effectively executing implementation and system integration

o Advisors – those who should be consulted through implementation

o Audience – those who should be informed of progress and key developments but do not have decision making authority.

Vested business and IT partnership is critical for a well-functioning team.  Co-location is advantageous and should be planned for.

Also, role clarity is key.  RMs and underwriters should not handle the system much; dedicated staff should take the laboring oar.

Data governance.  Data is an asset, and should be treated as one.  Develop data governance guidelines to create consistency and fix data defects.  Seek process elements that might lead to data issues and address those upfront.

3.  Leadership.

Demonstrate executive commitment by clearly communicating the program’s strategic vision and goals through the executive sponsor’s communication mantle.  Be crystal clear on the definition of success and desired outcomes and outputs (those are two different things).

Establish key day-to-day decision-makers that will have authority to determine priorities and make decision across business and technology processes without having to consult with a large group of people about every decision.  Consensus building is important; however, decisions made my committee will hinder the process and slow it down considerably.

Have an effective Process Management Office (PMO).  The right team can make all the difference in effective planning and execution.  Do not skimp on that aspect of project staffing – it can be extremely helpful in successful execution.

4. Target solution.

Simplification. We often over-complicate critical processes for not marginal benefit and significant negative implications.  For example, standardize key requirements across LOBs has huge benefits, ranging from efficiencies and cross-training to compliance and risk mitigation benefits.  Eliminate disparate processes and only allow exceptions if simplified alternatives are truly not feasible.  The primary goal isn’t automation but efficiency; hence, automating a bad process will not be helpful.

Continuous progress vs. perfection.  Don’t sacrifice an opportunity to get a working product in the hands of early adopters and continue to learn and improve thereafter instead of chasing perfection.  Perfection takes longer and is far more expensive.  In general, effective development implies an evolution and countless iterations, not one-and-done.

Establish a backlog prioritization process for additional wishes and requirements that are not mission-critical but will slow implementation significantly.  A program cannot succeed until it crosses the finish line.  Only then can you start adding the bells and whistles every user has in mind.

Continuously realign expectations.  The executive sponsor should get frequent updates and share with others.  You need a cheerleader to make this successful, and a steady drumbeat.  The more senior the drummer, the better.  Also, bring all project stakeholders together frequently – weekly if possible – to ensure on-going alignment.  

5. Execution.

Embrace the journey. Taking full advantage of any system installation comes down to continuous improvement.  This means establishing repeatable processes to stay on current releases (keeping the toolkit current) and innovating using those tools.  This is as different from our traditional development process as you can get.  So is the acceptance of imperfections.  Nevertheless, these are integral to any process automation effort, and are at the core of outpacing your competitors in timeliness and effectiveness.

Start planning for business as usual as early as possible.  For example, start identifying the future system administrators and/or Center of excellence early on so they can be involved through implementation.  This will give them the opportunity to build the skills necessary to continuously improve while obtaining the necessary historical knowledge which will help understand the root causes of some puzzling decisions.

Explicitly plan for knowledge transfer throughout implementation, not just at the end of it.  Weekly project updates and demos of work-in-process are excellent ways to socialize the change and get early feedback.  Massive unveiling at the end of the project is less likely to succeed, if no other reason simply because the audience hasn’t seen the work being developed, deal with snags and develop a better understanding of why the end product looks the way it does.

Avoid the risk of turning underwriters into administrators.  Let the underwriters do what they do best, and invest in system administration staffing to ensure full utilization of the system, resident expertise etc.

Expect resistance.  Certain job functions will be less amenable to change than others.  Do not be surprised; expect the problem and handle it before it becomes a destructive force in execution.

6.  Embracing change.

Own change management.  Change is hard.  Be prepared for resistance, anger, aggravation and grieving for the old way of doing things.  Support your teams throughout the process, which will yield faster adoption and greater success.  Understand the impact of change on different roles, jobs and departments, then change your communications and training to support the disruption.

Promote broad awareness and endorsement of the new system.  Iterative build showcases help key stakeholders understand progress and improve collaboration.  It is our job to “sell” the new way of doing things to the troops.  We should anticipate resistance, identify objections and handle in advance through a concerted campaign for adoption.  Most bankers know that the fastest way to adoption is mandatory use of the system as the “only version of the truth” (i.e. if it’s not in the system it doesn’t exist).  I consider that the final step in a set of positive reinforcement tools, with special focus on those we know in advance will struggle with the change the most.  An example of such a move: give the RMs tablets pre-loaded with the system and put the credit memo on it to couple compelling usage with an attractive new device.

Facilitate adoption among change-resistant groups. Be intentional about including those who will find the change the hardest, offering more hand-holding and provide positive inducements to adoption.  

Enable subject matter experts to develop into system champions.  Their knowledge and enthusiasm will facilitate adoption and help the team tackle problems along the way using their expertise.