Customisation
Implementing a system requires it to be configured correctly and, possibly, customised to meet local requirements. Unfortunately, there is often great confusion between 'configuration' and 'customisation'. Those of you who skipped over the configuration section take heed now!
As has been described in the System Configuration section of this infoKit, configuration is the essential process of setting up the hardware devices, software programs, operating systems, system security controls, user access rights and responsibilities and technical system resources that make up the system, so that the whole works together without problems. The key word in this respect is "essential". The system must have certain switches or parameters configured to work correctly. Customisation, on the other hand, is not essential.
Suppliers will not always agree to requests for enhancements from their customers and, whilst they will not make their software programs available for local development by the customer to meet their own needs, they will sometimes allow in-house written software to replace specific programs within the system. Suppliers may require sight of the proposed customisations before approving their inclusion within the software and will almost certainly only allow them in circumstances where data is extracted from the system for a different presentation on screens and/or reports. It is very unusual for approval to be given to customised software that writes modified data to the database because such a process would alter the integrity of the system, something for which the supplier is entirely responsible.
Examples of customisations all too often viewed as being necessary for modern systems in the education sector are:
the alteration of American spellings for words such as "enrollment" and "inquiry" to the English "enrolment" and "enquiry";
a profusion of customised reports that are simply requests for the same information to be displayed in a different format to that of the equivalent report within the standard software; and
small and insignificant changes in the software's functionality to do things in a slightly different way (e.g. approval of purchase orders by a different number of people to that allowed by the standard software).
Too many customisations are detrimental because each one has to be documented, reviewed and possibly re-written, perhaps re-submitted for approval and certainly re-compiled and re-applied every time an upgrade of the software comes along, all of which can prove to be very costly exercises.
An option for the institution to reduce costs in this regard appears to be not to upgrade to the latest release of the software, but suppliers usually demand that customers operate the latest or immediately previous version so that they can keep the costs of their support facilities to a minimum. The outcome of an organisation refusing to upgrade or violating the arrangements for customisations is usually that their licence to use the system will become invalid and the software will become unsupported.
When the requirements for a new system are first specified, users will be asked why their business processes work in a particular way and the answer usually will be "because that's the way we've always done it". However, the implementation of a new system is a good opportunity to examine the existing business processes to spot areas that can be improved. It is vital to define and agree the business processes to be supported by the new software in the signed-off specification of requirements.
Undoubtedly, you will hear suppliers emphasise the very features of the system (e.g. ease of customising the product to match current business practices) that will lead to serious problems during the implementation and after go-live. They know that an organisation wants to hear that it really does not have to change its ways to use their software.
However, despite any assurances to the contrary, the potential benefits of a complex software package will only be realised by reducing the number of customisations made to an absolute minimum. The basic 'out of the box' or plain 'vanilla' version of the software should be used whenever possible. The full range of benefits, such as easier initial installation and future upgrades, remote supplier support, low-cost maintenance and economical acquisition of features, disappear when software is tailored to fit the so called 'unique' requirements of the institution.
Nevertheless, we all live in the real world and few people will accept a given software package's functionality and resist its flexibility to be changed. As soon as users see what the software really offers, the pressures mount exponentially to make "just a few important changes". Many organisations are unable to resist the temptation to customise the software to fit the "special" needs of highly vocal, independent departments or important users. However, agreeing to these requests is a very slippery slope that leads directly downhill to a highly customised, difficult to maintain, and very expensive solution.
The cost of choosing a customised path is very high and often not well understood by the senior management. Customisation requests must become formal proposals, be treated with scepticism and always escalated to a high level within the decision-making framework. If you find you require a high level of customisation in your e-Learning applications you may wish to keep an eye on the output of the e-Learning Framework (elF) under the JISC e-Learning programme, which will provide advice and glueware code freely available to institutions to enable them to knit together various e-Learning components based on sound pedagogic practice.
