Terry Bourne explains why systems re-engineering is the key to mastering the year 2000 and euro challenge.
"Systems re-engineering" isn't exactly one of those expressions which sets the pulse racing, but what will set the pulse racing for all insurers is the unpleasant notion that their computer systems cannot deal with the year 2000. Systems re-engineering is the key to solving this problem, so if you want a normal pulse-rate, and a peaceful, agreeable life within a profitable and prosperous insurer, read on.
For about the past two years, although it seems longer, national newspapers and the insurance press have been stuffed full of features about what is frequently known as the millennium problem.
Unfortunately, I think a great deal of published coverage of the problem has actually been unhelpful.
For one thing, the coverage tends to belong to the school of journalism which might be described as "horror for horror's sake", in other words, it sets out to frighten and even shock the reader rather than provide much in the way of helpful advice.
Another problem is that what has been written so far usually focuses attention on the millennium problem rather than the problem of the euro, which in reality is equally important, especially for insurance companies, which are so heavily involved in cross-border investment involving continental Europe.
There has also been far too much waffle written about the year 2000 and euro problems, so let us cut straight to the heart of the matter. The simple fact is that after 1 January 1999 (yes, now it is less than a year away), you are going to need euro functionality if you want to stay in business. Similarly, after 1 January 2000 you are going to need year 2000 compliance. Ideally, you will have both of these already. The matter really is as simple as that.
Even if you are running packages, you cannot assume your packages will contain these functionalities as a matter of course. Many do, and it is fair to say that over the past year vendors have been working very hard to produce new versions of existing packages which do fit the bill from the millennium and euro standpoint, or else supplying customers with enhancements that can be connected to existing software.
Even so, if you are running a package, you need to be very tough indeed with the vendor and insist that year 2000 and euro functionality are either added to the package within the shortest possible time-frame, or that you are given - or can buy for a reasonable price - a new version of the package before long which does indeed contain the requisite functionalities.
Moving on now to address the problem of an in-house system which does not contain the requisite functionalities, this is, clearly, a much more complex issue.
As always in business, it is important to start out by focusing on where you want to arrive. In this case, you want to end up with a computer system which contains the millennium and euro functionalities you need but which goes beyond that and becomes a powerful tool for the development of your organisation in the future. Generally, the features of your new computer system - we will leave for the moment the question of whether this should be a completely new system or a modification of your existing one - should, as a minimum, include all of the following:
* Facilitates maximum speed of product development and maximum speed to market of new products. This means that the system helps with the design of new products, including all relevant parameters, and is able to adapt to include the new product in all its accounting and administrative functions.
* Can handle the crucial year 2000 and years beyond this.
* Contains an inbuilt multi-currency facility and is able to adapt to the Euro.
* Is easy for end-users to operate.
Note that I am only proposing these as a minimum; you may want to include other features that you regard as crucial for your future success.
The next step - and this is a point it really is impossible to overstate - is not to plunge ahead with working out how you can translate your objectives into technology that works accurately and reliably, but rather to use this crucially important time when you are planning your upgrade from a legacy system as an opportunity to analyse and think about your entire way of doing business.
This part of all the methodology is known as systems re-engineering.
What does the term really mean? It means that there is no sense whatsoever in an insurance company making modifications to its current legacy system (ie an old, obsolete system which does not feature year 2000 and euro compliance) or enhancing this system without first taking a long, hard look at its current business activity. The purpose of doing so is to try to identify ways in which the insurance company's operation can be made more efficient, cost-effective and more likely to result in the creation and marketing of products - and services, where applicable - which are attractive to customers. So, the term systems re-engineering first requires the re-engineering process to be extended to the way your insurance company does business, and only then for the actual computer system to be re-engineered.
Once you are satisfied with your efforts in the re-engineering direction, it is time to look at the general options for modifying a legacy system.
There are basically three such options. They are as follows:
1. To upgrade your existing software but keep that software in place (given that it has been upgraded) and keep it running on the same hardware as before.
2. To add desired new functionality to your current system by connecting it to new applications, with these applications being designed in-house or bought in as packages.
3. To dispose of your current legacy system and replace it with something else entirely.
Option 1: Upgrading existing software
In practical terms, this particular option is more of an emergency measure than a reliable long-term solution. It does solve the basic problems of a lack of year 2000 and euro functionality, or at least it should do, but it is unlikely to provide much in the way of additional functionality to provide a competitive edge. As such, it delays the need to provide a more radical solution to the legacy system problem rather than removes it.
The option involves rewriting or modifying existing software in order to provide year 2000 and euro functionality.
Option 2: Adding new functionality
This is a kind of intermediate solution between the emergency measure of rewriting or modifying existing software and the most radical measure of all of replacing the current legacy system entirely. Even though this option is an intermediate measure, it is often popular, because it has the big advantage of allowing the additional functionality to be added while keeping the current system intact and allowing it to get on with the company's day-to-day activity.
Option 3: Replacing the current legacy system entirely
In this case what is happening is that the legacy system is being thrown out completely and the new system is replacing it.
Legacy systems contain data which is almost invariably both good and bad data: that is, it is typically a combination of useful data stored in a useful format, useful data stored in an outdated format and data which is obsolete in some way. The latter type of data should be distinguished from archive data which may be obsolete but which you still wish to retain, so that - for example - you can handle a contract, transaction or security initiated some time ago.
An important task of the migration process when a package or bespoke new system is being used is only to migrate quality data, which means useful and accurate data that you are likely to need again in the future.
How do you make the migration process happen?
Clearly, you need to draw up a detailed, systematic and methodical project plan with realistic time-frames and budgets. In most cases it is also best to face the need for bringing in some external technical assistance with the process of migration. It is very important to devote care and thought to selecting that technical assistance, because decisions made now in relation to the computer system will have an impact on the business for at least a decade and probably longer.
I do, however, think that insurance companies need to keep firmly in mind that they should retain control of the project management process and to maintain all external parties on a tight leash. That way, they can oversee the whole thing from start to finish and minimise the danger of being involved in cost and time overruns. In few other areas of the financial sector is careful central control so important as in the project management of the migration of an obsolete legacy system to a truly powerful modern computer system which, all being well, will be winning a competitive edge for you for many years to come.
Terry Bourne is chairman of Total Systems plc, one of the UK's leading information technology consultancies and one of the few listed on the London Stock Exchange. An engineer by profession, Mr Bourne has worked in computing for more than thirty years and is a member of the British Computer Society. He has recently published, with James Essinger, a major new Financial Times Management Report entitled: Legacy Systems - Upgrading and Enhancing Outdated Computer Systems in Financial Institutions.