We convene a group of industry executives a few times each year to talk about changes in their marketplace and the implications for their businesses. In a recent meeting, there was concern about the environment, but there was also a conversation about positive ways to deal with the changes. One particularly promising discussion had to do with emerging “situations” that some of the executives were seeing as opportunities.
For one, it was the sudden appearance of atypical transactions that fit their basic operating model (right kind of assets, right kind of customer) but had one unusual characteristic — the deals were much larger than those they were used to handling. For another, it was unexpected growth in an emerging geographic market that suggested that the company’s timetable for entering new markets needed to be revised to find a way to enter this unexpectedly growing market sooner than planned. In both cases, the executives involved described the situation as “an opportunity that our company is ready for, but our system may not be.” In each case where there was a question in their minds about their system, the concern was the same: Could their system to be as flexible as their business?
One of the most important system capabilities today may be the ability for a company to change its system on its own, rapidly and inexpensively.
System change and speed have traditionally been uncomfortable bedfellows. For good reasons, CIOs and programmers have not encouraged companies to make changes to systems rapidly. Some aspects of technology have changed, and more advanced systems have been developed with methodologies that enable rapid change — even by the business itself — while still holding the line on absolute reliability and consistency in performance.
Most systems in our industry originally dealt with change through customization. This approach is still prevalent among proprietary systems that companies develop for their own use. Customization means that a programmer writes new code to enable the system to work in a new way. Financial systems are complex, and when new code is written, the potential exists for those new instructions to impact existing code in unexpected ways. Careful research of the code and extensive testing are the only ways to mitigate that risk. Of course, designing the change, analyzing the possible impacts on the system, writing code and testing the changes all take time and money. Thus, the sad reality: CIOs are skeptical of assertions that a system can be changed quickly or inexpensively.
More advanced systems offered by software companies today take a different approach — they have built the core system code to accommodate alternative settings. In this approach, the system has within it code that has been written to provide alternative functions, with some type of switching capability to engage one set of code or another. This approach is feasible because even though different companies may handle functions in different ways, there are usually a limited number of alternatives in use. If the system offers several alternative ways, the company using the system can choose from among the pre-programmed methods.
Most systems using this vendor-configured approach still require an expert, usually from the company that provides the software, to “throw the switch,” so that the approach doesn’t necessarily decrease the cost of changing the system. But if the alternative instructions have already been built, researched and tested, this approach can save some time, and mitigate some of the risk of changing the system.
The most powerful and advanced systems go the rest of the way toward providing rapid and inexpensive flexibility without jeopardizing the need for system reliability and consistency. This approach is embodied in the concept of “customer-configurable” systems. In essence, the customer has access to an administrative tool for “configuring” the system extensively. Code has already been written to enable a wide range of alternatives, and code has also been written to give the customer access to those choices without requiring programming experience.
This approach gives the company using the system the ability to adapt rapidly to a wide variety of business needs. System flexibility becomes a function that can be safely and agilely handled by the business. Regardless of the configuration, the company using the system can still rely on the third-party provider for support and for new releases, as opposed to holding an “island” of customized code, or being dependent on the provider for every tactical system change.
The advantages of customer-configurable systems are even greater when looked at from the standpoint of total cost of ownership. The costs of implementing and maintaining these systems tend to be predictable over the life of the product, primarily because all of the companies implementing the system go through similar processes — evaluating their business processes, configuring the system, formally accepting and deploying the configuration, and upgrading to new releases. Theoretically, the only way to hold costs down further would be to implement a standard system, “out-of-box,” and never change it. Granted that some companies do this — the question would be how efficient, let alone effective, that kind of approach turns out to be.
The diagram on the right illustrates how the three approaches to handling new business requirements compare, in terms of total cost of ownership over the life of the system. For a system in which change and variation are handled by customization — literally, writing new code to the customer’s specifications — the initial writing of the code may be the smallest part of the cost. The real cost comes when that custom code needs to be maintained, causes a problem with some new feature in the system or prevents an easy upgrade to a new system release. For these reasons, systems with custom code tend to be the most expensive over time.
Vendor-configured systems may be as inexpensive as customer-configurable systems in the short run, if only because the vendor tends to be involved in the initial implementation in both cases. Over time, though, these systems become more expensive to maintain as well. The vendor must be called whenever the need for change arises, and an outside provider expects to earn a margin on the services provided.
The equipment finance sector has seen extensive change many times in the past. Some would argue that leasing itself grew specifically as an adaptation to take advantage of change. In today’s marketplace, adapting to change almost always requires system adaptation. Today’s most powerful systems can help equipment finance companies achieve the necessary flexibility more rapidly, and at much lower expense, through customer configurability.
No tags available
