Abstract

Purpose – This paper seeks to examine how an electronic records management system has been
used in a Finnish government agency. In particular, it aims to study the relationship between
functional classification scheme and the way users in different organisational units and at
different organisational levels have employed the system. The goal is to examine whether
electronic records management systems were easier to use if the system “knew” what functional
classes the user (or other employees in the user’s organisational unit) typically need in their
work.

Design/methodology/approach – The study is based on two sources. The first source is metadata
in records that were captured in the electronic records management system of the agency. It
reflects actual behaviour of users when they interact with the system and classification of
records. The second source is distribution of functions to organisational units in the light of
policy documents and a survey made in the organisation. The study compares the two sources to
see how the users have employed the electronic records management system in their work and
how this relates to organisational structure and supposed usage of the system.

Findings – In general, individual employees employ only a small part of the classification.
However, this does not apply at a higher level in the organisational hierarchy: the higher the
person’s position in the hierarchy, the more classes he/she is likely to use in the work. Regardless
of the position, the classes are generally those identified as belonging to the employee’s unit.

Research limitations/implications – The study is based on one agency with a functional

organisational structure. The findings may not apply to organisations where job descriptions are
fluid. They should also be tested in more complex organisational settings. One could develop
new methods of automated classification which combine analysis of document content with
contextual reasoning about the likely functional classes.

Practical implications – Access to electronic records management systems could be facilitated by

creating in systems user/unit profiles defining what functional classes the user is most likely to
need in their work. It would also be useful if systems simply remembered what functional classes
the user has needed in the past.
Originality/value – The study offers insight into how an electronic records management system
is used in an organisation. This is valuable for companies developing records management
software and persons trying to gain a deeper understanding of records management in
organisations.

Keywords Records management, Electronic records management, Metadata, Information media,

Classification schemes, Finland

Paper type Research paper

Introduction

One of the challenges in records management is coming to terms with the unprecedented
volumes of electronic data, records and information, in an era when privacy, retention and
security requirements have become stringent. Traditionally, records management processes have
been undertaken by records management staff, but manual application of access and security
rules and retention policies do not keep pace with the volumes. Transferring the work to end-
users is not proving successful either. Employees’ primary responsibilities may leave them little
time to do these administrative tasks. Therefore, even persons with a proper training may fail to
accurately determine how long a file should be retained, to what classification it belongs, or how
long it must be preserved for litigation (Christensen, 2008; Santangelo, 2009). Asking employees
to spend a large amount of time manually classifying data greatly affects productivity
(Santangelo, 2009). Thus, the problem is how to automate records management processes, like
assigning metadata. End-users are highly resistant to capturing metadata that does not relate
directly to their own business processes (Christensen, 2008).

The Finnish approach

Metadata has to be added to records with minimal user intervention. This is achieved in Finland
by a records management tool known as AMS (an abbreviation from the Finnish word
“arkistonmuodostussuunnitelma”). An AMS is a combination of functional classification
scheme, retention schedule and file plan. An AMS identifies records that are created or received
by the organisation and instructs their handling. An AMS works as a guidebook for the
organisation. In an electronic environment it is the source of record metadata values.
A functional classification scheme is the core of an AMS. Classification is defined in ISO 15489-
1 as “systematic identification and arrangement of business activities and/or records into
categories according to logically structured conventions, methods, and procedural rules
represented in classification system” (International Organization for Standardization, 2001). A
functional classification scheme “is based on what an organisation does, its functions and
activities” (Orr, 2005). It describes functions of the record-creating organisation.

Class by class an AMS lists record types that are created in functions. “Decision”,
“memorandum”, and “letter received” are examples of record types. For each record type AMS
defines default metadata values controlling access and retention times. When a record is captured
in an electronic records management system the record’s functional class and type are used to
retrieve from the system AMS default metadata values, which are then assigned to the record.

For instance, an AMS may state that:

 there is a function called “human resources management” with a sub-function of “filling

vacancies”;
 “job application” is a of record type created in the sub-function;
 a job application should be retained for two years; and
 be considered as confidential.

When a record is added to an ERMS default metadata values come from the system AMS. In
some cases the user can change the default value by selecting another value from a pick list. For
instance, the system cannot always determine valid access restrictions: therefore, the user has to
change the default value when necessary. Default metadata values are based on the combination
of sub-function and record type. Still, instead of a sub-function, the user typically selects a
“case” in which the record belongs. A case is an administrative process with a definite beginning
and an end. A number of cases are usually created in a sub-function during a year, one for each
started process. For instance, a case could be created from fulfilling a vacancy in the
organisation. The case is created in the system when the process is initiated and the vacancy is
declared open. When the vacancy is filled, the case is “closed”. Every case belongs to a class in
the classification scheme. Thus, the case provides a link between the record and the functional
classification. The case also links a record to other records created in the same process. The
decision to create a new case is usually done in a registry office.

Hence, a user has to operate both within the functional classification scheme and the case
structure in the electronic records management system (ERMS). Nevertheless, everything is
based on making the right selection: if functional class and record type are not correct, there is a
danger that the record gets wrong metadata values. In a large organisation the AMS classification
scheme may contain hundreds of classes. Users may find the classification scheme and electronic
records management system hard to understand and cumbersome to use. Therefore, there is a
need to find ways to make the selection process easier or even entirely automatic.

In this study we examine possibilities for automatic record classification in the light of the
relationship between functions, organisational structure and records created in the organisation:
if we know what are organisational functions, how responsibility for the functions is divided
between different units, and in which unit an employee works,is it possible to say what
functional classes are used in the work? The goal is also to find out how functional classification
is used in organisations. This may tell whether user or unit profiles describing tasks – and,
indirectly, functional classes that are likely to be needed by users – could make interacting with
an ERMS easier.