Given the cost and complexity associated with implementing an end to end lease management system, leasing companies are reluctant to pull the plug on old legacy systems even if an upgrade to newer technology is long overdue. This is an even bigger challenge for those companies with highly customized legacy applications, naturally making them gun-shy about interrupting day-to-day operations to put new systems in place and retool key business processes. To the extent that the legacy applications are truly getting the job done, there is probably not much of a business case to be made for replacement. But at what point are legacy applications no longer suitable for the business? One key barometer is the amount of work being done within the legacy applications, in comparison to the amount of work being done outside the system.
Often times, the existing legacy system never had certain functionality or was limiting in what the business required. Or the business model and its requirements might have changed over time necessitating adjustments to how the leasing system was used in a given business process. An unfriendly interface that is too time-consuming to utilize might have required other forms of workaround, especially if the “front end” and “back end” are stand alone systems and are not seamlessly integrated.
In any case, for many leasing companies with older legacy systems, devising workarounds, or how to do something outside the system, is a normal part of everyday business. In fact, some of the most valuable resources in the company are those people expert at designing workarounds. These enterprising individuals – when unable to perform a process or obtain needed data from existing systems – compensate by creating idiosyncratic solutions to overcome the obstacles placed in front of them. Every time we undertake a new conversion we find many interesting workarounds requiring automation.
In one recent example, due to the inability of their existing lease management system to track amortization of non-recourse notes associated with the lease transactions, users were forced to track the amortization of each non-recourse loan in an excel spreadsheet. Obviously this meant that they were managing this process outside of their core system. Users, therefore, had to manually book journal entries every month to reflect the proper interest accrual and expense in the general ledger. Additionally, from a servicing standpoint, invoices sent to the customer were required to have different “remit to” details for the portion of the lease payment due to the lessor and the respective non-recourse debt holder. Since the system could not automatically generate an invoice with two remittance addresses, the users had to manually create invoices every month, for every one of these transactions.