Published on May 12 2006

Most of the presentations to the inquisitive audience focused on the pure functionality of the various software programs – their capabilities and limitations.

It really did not surprise me that relatively little discussion took place on the myriad of non-functional issues involved in a technology conversion – those that can significantly affect an organization's business processes, people and profitability.

I took it upon myself to fire a warning shot amongst the executives in attendance, imploring them to give such concerns equal attention when evaluating platforms, vendors and making plans for change.

Based on my experience in working with lease and loan companies around the world, it is these very facets of a technology conversion that spell the difference between success and failure when a company migrates to a new software platform.

The bottom line? A well thought out and executed technology conversion simplifies and speeds business processes and empowers people to better address the needs of their customers. Executed poorly, your organization's people, customers and business partners are distracted and frustrated – with lost efficiency and profits.

Taking the Leap

With so much at stake, why do organizations change technology platforms? There are a number of reasons, some driven by choice others by necessity:

Efficiency Gains

Some of today's software systems are very good at helping an organization complete tasks faster and take costs out of the business, mainly by reducing or redeploying full-time employees or making use of increased capacity. But there needs to be a strategic rationale, for there is a limit to how much cost can be taken out of a business.

Effectiveness Gains

The automation of business processes may improve efficiency, but the real payout comes with improving the effectiveness of your team. New technology platforms, such as our ALFA Systems product, combined with necessary process changes can empower team members to do the things they should do, rather than simply complete the same old, ineffective tasks faster.

Freed from mundane tasks, people can now better cross-sell products and services, develop and introduce new financial products to market faster, strengthen remarketing efforts and take proactive control of the customer experience.

Technology Obsolescence

Necessity, rather than choice, can often drive technology conversions, especially when it becomes apparent that outdated, unsupported systems must be replaced. Flexibility is critical in today's dynamic marketplace and also acts as a primary impetus in conversion decisions. It is time to make a change when simple tasks cannot be completed fast enough for customer requirements, legacy systems cannot handle new capabilities or "talk" to other technology applications that can.

Long-term economic feasibility is another concern. Perhaps the old 1960s-era mainframe is stable, but costs a boatload to maintain in hardware and people costs.

Regulatory Requirements

Changing regulatory and reporting requirements in recent years also have thrown a wrench into many companies' technology priorities. The platform must be SarbOx compliant and auditable to comply with changes in tax and banking laws. Or changes to company policies regarding, for instance, income recognition may warrant change.

In all of the above scenarios, a cost-benefit analysis surely takes place and the software vendor must be sensitive to this when integrating the new system. Important questions need to be asked – and answered honestly - when evaluating cost-benefit opportunities. Are they time sensitive, order critical and can these benefits be realistically achieved? During this process, it is best any concerns be raised early. It is far better to manage people's expectations upfront, rather than try to rationalize the situation after the fact when there are delays or performance metrics are not met.

Selecting the Right Vendor

The importance of system functionality is a given, but a software vendor's capability to deliver on its promises is critically important. Never assume anything. In addition to installing the software smoothly, will the vendor be able to coordinate the migration of data from the legacy system to the new platform without any major glitches? This ability cannot be emphasized enough, considering system migration accounts for about a third of the total technology conversion effort.

Other capabilities to consider are the vendor's ability to provide on-site support during the early days after the conversion, coordinate advance training to people at all levels of the organization and help manage the angst brought on by such significant business change – both internally and externally.

Of course, a vendor should be selected based on more than its response to an RFP. On-site demonstrations and conference room pilots are much more effective. They provide a more realistic, projectable view of the system in action running your business and provide a better basis for challenging the vendor.

Defining the System Requirements Upfront

Once a software vendor is selected, working together to define and agree on the system requirements of the new platform is critical. If you decide to ignore this process and the output, your organization is taking a significant risk. This upfront work is about planning the whole business change from start to finish – not just a software drop. Done right, the process produces a dynamic, jointly owned roadmap for the conversion.

However, the plans must be flexible. We once worked with a major European bank to manage a technology conversion, starting with 30,000 lease contracts. During the project, the number of contracts to be converted jumped to 250,000 as a result of acquisitions. Obviously, adjustments to plans and the system requirements had to be made.

Another bit of advice when establishing system requirements is to consider phased data migrations to the new system. For many organizations, technology platform conversions become the single biggest endeavour they ever embark on. Large migrations can take several months, with senior executives fretting at great status reports, but a lack of tangible results. This makes them nervous. Little victories achieved through a phased approach help to quell their anxieties.

Adopting a Configuration Versus Customization Strategy

The first rule when integrating a new technology platform into your business is to fight the urge to complicate the project any more than necessary. Smooth conversions focus on the configuration of a new technology platform, rather than customization that gobbles up time and budget. Software changes should be an absolute last option. Situations do arise where this is a requirement, but the "enhancement" owner must be prepared to make a strong case for the change and be able to explain why it is necessary.

The last thing an organization wants to do is start making changes to a multi-million dollar software package, and then lose some of its functionality that enticed you to purchase the product in the first place. Decisions to make such changes must be well thought out and made on the basis of strengthening the overall business and its competitive advantage. I sometimes wonder why IT people, rather than those running a business, make some of these software decisions.

Conversely, we have recognized through experience that it makes most sense to adjust your organization's business processes to take advantage of the software capabilities. Some businesses consider this an extra, possibly unnecessary, step in the technology conversion – but we do not consider it an option. Nobody should think you could just put software in place and watch business workflow improvements magically appear. Process evaluation must take place alongside any software integration. Six Sigma organizations, such as Textron Financial, naturally understand the need to continually review and refine their business processes – this is a way of life for them. They know technology is simply an enabler for business process improvements. They go hand-in-hand.

Getting Users Involved in the Conversion Process

Most organizations are lean and do not have teams of people waiting to provide their input and assistance in a technology conversion. Everyone is busy with their jobs. Nevertheless, user involvement is critical to effectively migrating to a new technology platform. The sooner a project team is assembled, the better. Textron Financial impressed us by having a fully operational project team in place even before the new technology platform was awarded.

A steering group with decision-making authority, including the software vendor, must also be in place to make tough calls. The team must be ready to change direction quickly during a technology conversion.

To get the most out of this team, you should not expect its members to do two jobs. Do so and they will only give half-effort on each. Nobody can really expect them to spend all day completing their user acceptance testing and then go back to their first job focused on their real responsibilities. They have important roles in the technology conversion and should be treated accordingly. Incentivize them to do their best on this critical project and backfill their positions as necessary, rewarding the replacements as well for stepping up their efforts.

Testing, Testing and More Testing

Practice makes perfect, especially during technology conversions. It is imperative this includes trial migrations, reconciliations and volume testing. Full blown dress rehearsals also should be mandatory prior to any migration. During this time, it is also recommended that data cleansing, de-duplication and other upfront work is completed to assure clean and consistent data.

One of the smoothest migrations we have completed in recent history involved 100,000 leased units for a U.K.-based vehicle management company. Thanks to plenty of testing, practice and a dress rehearsal, the weekend migration was completed without any significant problems. The team even text-messaged senior management to keep them abreast of our progress.

It should be noted that manual migrations are really only practical for up to about 1,000 lease contracts. Any more and the process is simply not manageable and an automated process is needed. With automated migrations, there are exceptions, however. Rather than waste time programming the system to handle the most complicated financial agreements in a portfolio, it makes more sense to manually input these while the others are automatically transferred.

Flipping the Switch

At some point, the team has to flip the switch and go live with the new system. As a general rule, I know we are ready for the migration to take place only when I feel comfortable leaving town on vacation with no worries. I also ascribe to the "hope for the best, plan for the worst" approach for, despite the best-laid plans, there will be challenges. That is why an escape route must be in place to assure business continuity in the event a significant problem arises.

Ideally, nobody throws the switch unless they are 100 percent sure the contingency plan will not be used, but that is virtually impossible. While such a scenario has never materialized for my company, I have friends in the business that have suffered such embarrassment. We have seen organizations lose days of processing time due to a lack of a back-up plan to quickly revert to the old system to keep the business running.

In the end, no software vendor can effectively complete a technology systems conversion by themselves. It must be a true partnership – a team effort – between the vendor and customer. Expectations must be jointly established and managed on an ongoing basis and the lines of communication must flow freely. If an organization in the midst of a technology change simply treats us as a vendor and we simply treat it as a customer, cultural and communications barriers are erected between us. If this happens, the chances of true success are slim – no matter what the platform's functionality.

- Author: Andrew Denton