Blogs

The ERM system interacts with users in ways determined by the system requirements specified for it.

There are basically two kinds of system features, and therefore system requirements:

Functional requirements:  these requirements mainly specify what the system has to do.  Things like allowing users to add information, protecting information from change, keeping audit trails and so on.  These are well-covered in various publications, such as DoD 5015.2 and MoReq.

The second kind of requirement is Non-functional requirements.  These requirements relate to more abstract features, how the system and it environment operates, such as ease of use, speed and reliability.  They do not define the business functions that the system has to perform, which results in the name ‘non-functional’. 

A key non-functional requirement is the all-important ‘Ease of use’.

Human beings are generally creatures of habit. They are reluctant to embrace change, and will look for reasons why they should not change.  Thus, if users find a new system difficult to use, they will be reluctant to change from their old ways of working. This could cause an ERM initiative to stumble at the system implementation stage, and unless a solution is found, could lead to failure.

When considering this ‘ease of use’ requirement, you first need to identify what makes users think a system is easy to use, and the degree (as in for example - must, should, or nice to have) to which those factors affect their thinking.  You then need to decide how to specify that to a supplier, and how you will assess how well their proposed solution meets your requirement.

The ‘ease of use’ requirement may also vary between the types of user of the system, and the amount of training that can be provided. 

Some examples of ‘ease of use’ requirements are:

The user interface must be familiar to users, and so may need to follow a single set of rules consistent with those of the operating system, or other mainstream applications.  These days, most vendors do follow this good practice, and it is a much lesser issue than it used to be.

Common, frequently used, transactions must be designed so that they can be completed with the smallest possible number of mouse clicks and/or keystrokes.  Having common transactions that require long or complex series of keystrokes and clicks is a common source of serious system implementation.  To head this off, you should think about some of the common transactions, such as declaring a record, finding a folder, or retrieving a record, then set about evaluating how short or long that process can afford to be.  The system should be closely integrated with the e-mail system and other office applications to allow users to send links and files to colleagues without exiting from ERM.

It may be easier for a user if they can set up different screen layouts for the different types of work they have to do.  So, it is required that the system should allow users to customize the graphical user interface, including menu contents, layout of screens, use of function keys, on-screen colours, fonts and font sizes, and audible alerts.  These configuration changes made by the user should be saved in their user-profile.

Other examples include:

When entering repetitive or large volumes of data manually, it is helpful if the system provides defaults for data entry wherever possible, including user-definable values, repeats of the previous item, and values derived from context, such as date, file reference, or user identifier.  This is a general principle to observe when selecting a system; when implementing a system, you need to go through each data entry field to determine which of these features applies to it and how.

The system should support optical character recognition to capture metadata from scanned images of printed documents.  This is not relevant to all implementations of course; but where it can be applied – that is, where the nature of the records being scanned supports the automated extraction of metadata – it is enormously helpful.

The ERM system must be able to display several records simultaneously to make searches or comparisons easier.  Most systems now have this capability.

The system should allow users to define cross-references between related records to support easy navigation between them.  Especially in the early days of using a new system, or, later on, when needing an infrequently used function of the ERM system, it is easier if the system provides context-sensitive online help throughout.

It could also make things easier if the system includes help on use of the organization’s classification scheme.  The quality of on-line contextual help varies greatly from system to system; you may need to devise a way to evaluate this quality.

All the system’s error messages must be meaningful to any user that is likely to see them– and ideally should include explanatory text and an indication of the appropriate actions to take to resolve the problem.

The system should support user-definable macros, to help users partially automate repetitive tasks.

Administrator functions must also be easy to use and intuitive throughout.

‘Ease of use’ can be influenced by a very broad range of features within an ERM system, and is best defined and judged by the different types of user.

From all of this, it is strongly suggested that a panel of users be convened to help identify usability requirements for a new system, assess the various solutions, and to test, and act as ambassadors for, the chosen configuration during implementation.

What is your experience getting acceptance from your users?

Tell us about your change management efforts?