Part of the planning process for any new computer systems should be to identify its on-going maintenance requirements and the person or group within the organisation that will be responsible this upkeep.

Without this support commitment, even the best system will gradually drift from their original design goals. Configurations rot, data quality degrades and processes get subverted, leading to a system that may still 'work', but fails to meet the business requirements that justified the deployment.

This maintenance requirement is particularly important for 'core' business systems, but applies generally although with less intensity for smaller, niche systems.

Some of the areas to consider when planning the support and maintenance requirements are:

Training and support

Of course you've remembered to plan for user training, but that might only cover the initial deployment.

What about people you hire in a few months? Is your HR department even aware that you're deploying a new system? What about access control - setting up new users and permissions - this is often part of the new employee induction process but if the HR people don't know about your new system, you might have new hires sitting around waiting for access to a system they don't know how to use.

What about support requests/queries? If you have a worthwhile help-desk or ticket tracking system, you may be able to integrate the new system fairly easily (if you don't have a worthwhile ticket tracking system, get one).

Regular monitoring

How much general monitoring will you need?

You should consider regular monitoring of error logs (to see if anything is going horribly wrong) and activity/audit logs (to see if people are actually using the system). You might want to start with more frequent checks (daily or weekly) and reduce the frequency (say monthly) as your deployment matures. Data quality scans can identify potential process failures or training gaps.

Problems are much easier to fix and bad habits easier to break if detected early.

Business Case reporting

If the system deployment was justified with a measurable business case, you might be able to derive activity reports which support the return on equity calculations used.

Configuration management

IT environments evolve.

Different elements of your system infrastructure may have competing or incompatible requirements (that old accounting package only works on Windows XP not Vista or Windows 7; the new database reporting engine uses the latest 64-bit drivers and needs Windows 7). These sort of problems usually get identified early in any evaluation process; a more common problem is ensuring that the requirements of all system are included in any change control/impact analysis process.

Imagine installing an intranet web-based system that talks to a database and sends email. What happens if you upgrade the mail server? If the mail server group doesn't know that a new system is dependent on their servers, it is easy for a configuration change to break the integration. This case is a pretty simple problem and solution - once you know about it, but what if there is a change which is incompatible with your new system? The first thing you might know is when every user you have can't log in. You can fill in the rest - it's unlikely to be nice.

Other things

Other sadly common configuration management holes include:

• Users. Are user logins synchronised across all your systems? Not necessarily single sign-on, but unified add/change/delete processes.
• Software maintenance. How do you install software components required on individual computers? What about updates - both to end-user and server software?
• Database requirements. Does/can this system use that same database engine as your other systems? If so can you integrate the admin tasks? If not, how will you implement the requisite administration processes?
• Backups. Please, please make sure you have regular, reliable backups.

It may not be a whole job

Just because someone should be the owner of a system doesn't mean that "{x} System Owner" is an entire job description. Some systems might only need a half-person or less. Some of these support processes may be best integrated with existing departments within your organisation or absorbed by existing positions.

The point is that you should think about these longer-term requirement before you begin, rather than waiting until after your gone live and have no-one to answer the calls for help.