Project Delivery Process D850

D850 - Define Live System Support and Administration Function

DEFINITION

Define and agree terms of reference for live user support activities.

SUMMARY

Analyse and agree the requirement and constitution of functional and technical user support for the live system.  This will define how the live system will be managed in organisational terms.

The level of investment to be made may be discretionary, for example, how much resource should be made available to helping the end users through a help desk function?  It may involve policy decisions regarding what should be centralised and what should be devolved.  For example, should there be a central specialised resource for report writing or should all departments have responsibility for their own requirements?

These issues will frequently involve the setting up of a new permanent line section within the organisation, and will inevitably lead to changes in job content.  The organisational impact and the acquisition of the necessary resources need specific attention.

The approach should be defined and agreed.  It will normally be documented in an Implementation Paper (or Brief Implementation Paper) - System Support and Administration.

PATH PLANNING GUIDANCE

Optional - used where post live support will be required.  This process is an alternative to Process D860 which relates to smaller systems where no specialised support functions need to be defined.

DEPENDENCIES

Prerequisites (Finish-Start):

• Delivery Approach Definition (DAD) or equivalent definition of overall business solution.

Prerequisites (Finish-Finish):

• definition of User Procedures

Dependent procedures (Finish-Start):

• live running

RECEIVABLES

• Delivery Approach Definition (DAD)
• various User Procedures and IPs relating to organisational set up, roles and functions
• various IPs relating to functional and technical design

DELIVERABLES

• Implementation Paper - System Support and Administration

TOOLS

• Examples: Terms of Reference for System Administration

DETAILED DESCRIPTION OF TASKS

The System Support and Administration Implementation Paper

The approach to management and support of the live system is considered in an environmental implementation paper - the system support and administration IP.  In a similar fashion to other implementation papers, it will review the requirements and options, then state and justify a recommended approach.

Requirements

All systems require some continuing support and management.  In some small systems, the arrangements are left undefined and informal.  Although this may be practical in very small organisations, it is usually worthwhile agreeing and publicising the details.

Requirements will vary according to:

• the business needs
• the functional design
• the user procedures required
• the user organisation - its structure, and nature
• the desired form of systems management and support
• the amount of investment in support that would be available in terms of people and funding
• the system’s vendors and their style of support.

Where several integrated systems have been implemented, there may be a need for support functions covering each package area, eg finance, logistics and personnel.

Some major types of support or management needs that might be considered include:

• bug reporting by end users and the resolution procedures
• rules and procedures for reporting bugs to the vendor’s support facility
• liaison with the vendor’s support functions (for both functional and technical problems)
• application of corrections and routine amendments from vendor
• liaison with vendor regarding sales, new products and upgrades
• implementation of upgrades (nb any major upgrade should be handled as a separate project)
• vendor user group membership
• run scheduling and instigation
• run controls and system controls, eg system-wide carried forward / brought forward figures, control totals etc
• management and control of interfaces, eg instigation of runs, verification of control totals
• monitoring reported user or data errors and ensuring they are rectified
• update and control of system parameters, eg calendar, reporting periods
• update and control of shared master files
• management of functional security and access controls
• management of technical security and database security
• “ownership” of data types - eg is the purchasing department or the accounts payable department responsible for vendor data
• report and enquiry writing and support
• users’ Help Desk
• update and control of vendors’ manuals
• update and control of own user documentation
• minor functional enhancements
• provision of continuing training programmes or facilities
• archiving of old data
• monitoring of system performance and capacity
• monitoring of backup, recovery and disaster recovery arrangements
• acquisition of minor enhancements to the computer hardware, communications equipment etc
• acquisition of operating resources, eg disks, paper, tapes, cartridges, special stationery, printer ribbons/toner cartridges

Many of the topics listed above may need to be broken down into individual cases.  For example, separate ownership might be defined for each type of master data, or even for sub-sections within the master data - eg ownership of customer details defined according to sales region.

The detailed requirements will need to cover all situations so that there is no misunderstanding amongst the staff involved, and, in particular, so that no significant task is overlooked.  Responsibilities should be unambiguous; they should be held by specified staff or units.  In particular, responsibilities for liaison with external bodies such as the vendor should be well defined and limited to ensure that confusion does not arise in these external relationships.

Options

The various options available should be considered.  These will depend upon the details of the business solution, the structure of the organisation and the technicalities of the system.

The key choices will normally relate to who performs each specific task, and how that task is managed in terms of line responsibility.  Some typical choices are described below.

Centralised system administration function

Where there is a large system involving users from more than one line department, it is often valuable to set up a separate specialist function to manage and control the system.  Typically, this would be led by a user manager with specific experience of the computerised system.  Ideally, this manager would have previously been a member of the project team.

Staffing would vary according to needs, but the unit might typically include:

• user manager responsible for all aspects of management, enhancement and control of the system,
• business analysts per functional area (eg finance, logistics, personnel) to handle severe user problems or queries and to work with report definitions and minor enhancements etc,
• a supervisor to take routine control of the system eg run scheduling, checking controls and error handling,
• clerks to handle routine aspects of the controls, eg maintenance of master data tables, physical report distribution, user Help Desk function,
• secretarial support as required.

To some extent, the staff would need to share experience and roles so that fluctuating demands could be met and minimum standards could be maintained during routine absences.  Additional specialist staff might also be brought in as required, eg trainers, programmers.

In some circumstances, particularly where the computer installation is not shared with other systems, the technical staff supporting the system and operating on a routine basis might also report to the centralised systems administration function.  Such staff might include:

• system operators to monitor and control regular operations of hardware, network, and database as well as handling of batch routines,
• programmers to implement user requests for reports and additional functionality, which cannot be covered by standard system features,
• systems specialists to apply corrections, PUT updates etc.

Decentralised responsibilities

Some tasks and responsibilities may be better performed by individuals in the various business units using the system, e.g. the accounting department could handle user questions on the finance and controlling modules, materials handling could set up a support organisation for the materials handling and procurement modules.  As a general principle, work is performed most efficiently and effectively if it is conducted by the people with a direct interest in the results.

There will normally be at least some of the necessary tasks which cross organisational boundaries.  Where an organisation does not wish to set up a specific centralised unit, these too must be placed into one of the existing business units.

Publicising user access to system support and administration

However the system support and administration function is organised, it is essential for users to have easy access to support functions.  Apart from organising and staffing these support functions, this requires the company to publicise for every user group:

• which user support functions are available for the user:
• If more than one support function is available (e.g. a technical and a functional support unit) their respective responsibilities must be made clear.  In which cases should local support be used and when will central support be the right access point?  Who will handle application / hardware / network problems?
• how the support functions can be accessed:
• Will the normal access be via telephone, an electronic mailing/messaging system, or via a problem reporting database?
• when the support function will be accessible:
• What are normal operation hours?  Will the support function have the same availability during system startup as during normal operations?  Will the availability change during holidays ?
• how problems will be tracked:
• If problems cannot be cleared immediately, how will they be tracked and how will users be informed about the resolution?

User and MIS roles in system management

In most cases, there are elements of both functional skills and technical skills required in the management, control and operation of the system.  An ideal solution would combine these skills in a single operational unit specialised in managing and supporting the live system.  There are, however, many cases where this is not cost effective or not acceptable from an organisational point of view.

Various solutions may be feasible, for example:

• specialist unit with mixed skills reporting to user line structure of organisation,
• specialist unit with mixed skills reporting to MIS department,
• separate user specialist unit and MIS specialists each reporting to own line structure,
• full MIS control of the system,
• no specialist MIS staff; users run system - usually only appropriate for small office-based systems.

Some example organisational structures are shown below.

Recommended approach

The requirements and options should be considered with the key user management, particularly those who will have line responsibility for the system.  An approach should be agreed and documented.

In most cases, the organisational and staffing recommendations will have to be agreed with senior management, the line management directly concerned and with the organisation’s personnel function.

Detail of approach

The details of the approach may be set out in the format of Terms of Reference for the live support functions.  This would set out the detailed approach, responsibilities and tasks.  Once agreed, the full details should be included in user documentation and generally made known to the users and management.

Where new roles are being created and staff are being recruited, transferred or given changed duties, appropriate use must be made of the organisation’s personnel function and other relevant management processes.  It may be necessary to work with the appropriate personnel staff and line management to assist in the definition of job descriptions and to participate in the recruitment or selection process.