In virtually all of the successful implementations of enterprise applications such as a loan origination system, at least one member of upper management has accepted responsibility for getting the system implemented and has taken an active role in the project. At a minimum, this person attends status meetings and keeps project team members accountable for their part of the project.
Change in any routine is inherently difficult. In fact, change normally does not occur unless people are forced to change or if the new way of doing something is ten times better than the previous way right out of the box. Installing a new software application is going to mean some pain; even if the new application is state of the art, it is going to mean learning something new and usually a loss of freedom to some degree. As a result, originators, underwriters, and closers are not going to start using a new application unless they are told to by a superior.
A typical reason (some might call it an excuse) for not pursuing automation is that “commercial deals are too complex and too varied to be automated”. The fact is, if you can automate just 60% of what is currently done manually, the system will still pay for itself in less than a year. There will always be that ‘one-off’ deal that does not fit the standard process, and there should be a procedure for handling that. But, there is always enough commonality to warrant the use of a database to store deal information and an application to process a deal. Again, this is where management must be involved and provide guidance – standardizing the process. The more standardized it is, the more efficient the operation and the more benefit that is going to be realized by a system.
Also typical is capitulation to underwriters who are married to their spreadsheets and refuse to use anything else. Management must appreciate the trade-off’s associated with continued spreadsheet use. The benefits of getting off of spreadsheets more than compensate for the inconvenience of having to learn to use a new system. Spreadsheets haven’t changed since VisiCalc over thirty years ago. Implementing a pipeline database, while still using spreadsheets, is a classic case of taking one step forward and two steps back. You want everything the team uses to capture data to be database driven. When you use a spreadsheet, you are basically offline – disconnected from key changes to the database such as deal status, borrower information, and underwriting guidelines … just to name a few. If totals from a spreadsheet are being keyed into or even electronically fed into a database, you have serious data integrity issues since cell formulas can be changed on the fly in a spreadsheet. Spreadsheets will always have their place – for exception conditions or for general use when a database application is not available or affordable.
An origination system is all about integration, where the right hand always knows what the left hand is doing. If a rent roll is updated, replacement reserve, or management firm costs are being updated, the affect on NOI analysis should be automatic and immediate. The same goes for appraisal information, market info, borrower credit, on and on. If deal participants are still using desktop applications that don’t talk to each other, that’s a huge liability.
Of course, the feasibility of migrating off of desktop tools onto a database-centric application is dependent on that application being able to perform the same functions as the stand-alone tools.
One easy way for management to do their part in driving adoption is to make edicts that certain things have to be done on the system in order for a deal to move forward in the process. A deal won’t be looked at if it is not submitted by the originator online; only loan approval or committee presentation docs that come out of the system will be considered.
Bottom line is you have to want the system to work for you. Users who have a negative attitude and only focus on what the system doesn’t do instead of the benefits it can bring have to be reigned in. They can literally kill a project. Change is always tough, but a ‘half-full’ attitude must be maintained to make it through the transition.
There is always some pride of authorship in a spreadsheet created by an underwriter, or an access database that someone built to do pipeline tracking. Two things have to happen for the greater good – the authors have to acquiesce and they have to be included in the development and implementation of the new system. Upper management should not only see that this happens, but should turn this negative into a positive by empowering the key users by giving them leading roles in the new implementation.
Change is almost always a good thing, but it inevitably comes at a price. If management does not openly mandate the change, the price is going to be high because the process will not be smooth and the transition is going to take too long. This can be the death knell for a project, and then things are really going to hurt because the project will be abandoned and a lot of time, effort, and dollars will have been wasted.
I can’t emphasize enough how much of a factor the bank’s project team is to the success of a project. In addition to the management sponsor, there needs to be a dedicated project manager and semi-dedicated group of lead users or department heads. At least one liaison with the technical staff must be assigned to support the installation, testing, and production environment. Finally, a system administrator must be designated to maintain the system and be the first level of support to users; this could be either one of the team members already mentioned, or another person altogether.
A software application can be the best available and still not get successfully implemented – because the right resources were not dedicated to it and/or lack of management sponsorship. In the end, though, it is usually the software vendor that takes the blame.
-Brian McCracken
