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.
Literature review
Classification is an essential tool in records management. It is used to provide links between
records that originate from the same activity or from related activities; to determine where a
record should be placed in a larger aggregation of records; to assist users in retrieving and
interpreting records; and to assign and control retention periods, access rights and security
markings (Schellenberg, 1975; Smith, 2007) Because of this, classification is often discussed in
records management and archival text books and guides (Smith, 2007; Williams, 2006; Shephard
and Yeo, 2003; Todd, 2003; National Archives of Australia, 2003a, b, Tough, 2006, Findlay,
2008) and in professional literature (del Olmo, 2006; Morelli, 2007; Milne, 2007; Bedford and
Morelli, 2006; Robinson, 1997; McKenna, 2009; Sabourin, 2001). The role of classification in
information retrieval has been studied by Singh et al. (2007). Seitsonen (2009) examines the
relationship between organisational structure and functional classification in her master’s thesis.
       Campbell (1941) had already advocated functional classification. Campbell believed that
functional classification would be more understandable and easier for a researcher to use and for
an arranger to create than a classification based on administrative units.
Nevertheless, before the 1990s, records were commonly classified in creating organisations by
subject and in archival institutions by organisational provenance. Today, classification schemes
are usually functional and based on what an organisation does. Since the 1990s functional
classification has been strongly promoted. Recent records management textbooks in the UK and
Australia promote functional classification as the only or main means of classifying records (Orr,
2005). A classification scheme lies at the heart of any electronic records management system
since it defines the way in which electronic records are grouped together (aggregated) and linked
to the business context in which they were created or transmitted. Specifications for electronic
records management systems (Archives New Zealand, 2005; Arkistolaitos, 2008; International
Council on Archives and Australasian Digital Records Initiative, 2008; DLM-Forum, 2008) and
international records management standard (International Organization for Standardization,
2001) advocate functional classification as the best practice for records management. Records
management metadata standard ISO 23081 notes that metadata can be inherited from a higher
records aggregate to a lower one. For example, metadata about a folder can be inherited by all
the items placed within the folder (International Organization for Standardization, 2006).
Classification scheme is one possible source for inherited metadata.
Terminology is wavering: functional classification, functions-based classification, and business
classification are used as synonyms (Orr, 2005). Sabourin (2001) notes that the term “functional
filing” is used even though a record series in the model may not display actual functions
performed. There seems to be no full agreement on how “function”, “sub-function”, “activity”,
“transaction”, “task” and “process” relate to each other and to levels of classification. Shephard
and Yeo (2003) have made perhaps the most rigorous analysis of their relationship. The
terminological ambiguity is not limited to records and archives management: in business re-
engineering literature there is no consensus about the definition of “business process” or a formal
definition of “process” that is sufficient for use by process engineers and system builders
(Maddison and Darnton, 1996). There are different ways to create a functional classification:
both a top-down approach and an approach based on process analysis is possible (Orr, 2005;
Tough, 2006). Functional classification schemes are usually hierarchical and enumerative.
Functions thesauri can be created from a hierarchical classification. An example of functions
thesauri is Australian Keyword AAA, which has been also used in the UK Parliament (Gibbons
and Shenton, 2003; Robinson, 1997, 1999; NSW Department of Commerce. State Records,
2008). Xie (2007) compares and contrasts two types of functional classification, one described in
Australian DIRKS manual (Designing and Implementing Record-Keeping Systems: Manual for
Commonwealth Agencies) and the other defined in Canadian BASCS methodology (Business
Activity Structure Classification System). In Northern Ireland a common file plan based on
functional classification has been developed for the Civil Service, first to common functions and
later to other areas (Smyth, 2005).
The functional approach has multiple benefits. For instance, a retention schedule based on
functions and related activities supports the organisation’s mission, facilitates access, and helps
to identify vital and archival records (Farneth and Nye, 2005). Man (2005) has written about
functional approach from the perspective of archival appraisal. She claims that functional
appraisal and surveying techniques are particularly effective for establishing the business context
of records and identifying legal and organisational requirements governing their retention.
Automatic classification has been a challenging research issue for decades. A major motivation
has been the high cost of manual classification. By now there are several possible approaches
(Golub, 2006). However, it is not sure how well subject-based methods of automatic
classification can be applied in records classification: terms used in a record may not bear direct
relationship to the function in which the record is created or received. Also, the relationship
between record, access rights and retention times is not purely subject-based. In Finnish system
access rights and retention times are defined record by record, hence, they should also be
assigned automatically. A combination of manual and automated classification might provide
good results (Santangelo, 2009).
Problem statement
We need more information about how electronic records management systems are used in
organisations to understand the role of ERMS and the processes behind record creation.
In this article we study one government agency to search for answers to the mfollowing
questions:
   1. How many functional classes are used by organisational units and persons nworking in
       the organisation? Does the usage concentrate on some classes or is it distributed more
       equally?
   2. How does the person’s position in the organisational hierarchy affect the use?
   3. Are the classes used by individuals those that one could expect on the basis of analysis of
       relationship between organisational functions and units?
Methodology
The study is part of a two year of Semantic Web 2.0 (FinnONTO2) –project lead by the Helsinki
University of Technology. The general goal of the FinnONTO2 was to combine benefits and
synergy of Web 2.0 and semantic web technologies and demonstrate the results in various
semantic web portals and applications (see www. seco.tkk.fi/). Whereas the research group at the
Helsinki University of Technology examined ways to apply traditional semantic web
technologies to electronic records (see Nyberg et al., 2010), our research group tried to find other
ways to create more “intelligent” and easy-to-use electronic management systems. The data used
in the study is a compilation of two sources. The first source is metadata and records of a Finnish
government agency. The second source is information about the functions and organisational
structure of the agency.
Records management metadata
The first source for the study was records and metadata in an ERMS of a Finnish government
agency. Records management metadata describes not only record creation, but also processes in
which records participate. The metadata used in the study complies with the SAHKE metadata
model. SAHKE is a Finnish specification defining requirements for ERMS functionality and
metadata (Arkistolaitos, 2005a, b, c).
Metadata in SAHKE gives information about records and also describes cases and actions to
which records are linked. An example of an “action” is sending a record for approval to another
employee. Altogether the data used in the study gives a good overall picture of the ERMS usage
in the organisation. Nevertheless, the picture is not complete because reading records without
modifying them was not recorded in metadata.
The same metadata has been used in Kettunen and Henttonen (2010). The agency delivering the
records had an interest in developing electronic records management and making ERMS more
user-friendly. Thus, it was willing to give records and their metadata to our research project.
Unfortunately, the agency does not want its name to be revealed.
There was little possibility for selecting the agency whose records are used in the study. In our
experience, agencies are usually reluctant to give their records to research. Legal responsibility
remains at the agency even when the records are outside its control. It is not certain that
confidential or classified information can be entirely screened out from the records. Another
reason for reluctance to deliver records for research is technical obstacles. At the moment, many
Finnish electronic records management systems do not have tools for exporting records with
their metadata.
Except for records in two functional classes – which were excluded because they contained
sensitive or classified information – the set included all the records received or created by the
agency and captured in its ERMS in cases opened during the time period of 30.9.2005-
31.12.2007. Altogether, the original set included 7,252 records of permanent or non-permanent
value in 67 functional classes. Besides records, the metadata described 3,469 cases and 14,532
actions.
The agency is small and has about 130 employees. It ranks relatively high in the government
hierarchy. Because the agency does not want its identity to be known, its functions cannot be
described here in detail. They are typical for a government organisation. There are facilitative
functions,   which    include    general    administration,   personnel    management,      financial
administration, and real estate management. In substantive functions the agency interacts with
other agencies and citizens, makes decisions and gives guidance in matters within its mandate.
The records metadata contained information about agents and roles in which they were involved
in a process (for instance, about initiator who starts the process by sending a letter to the agency),
actions which have taken place in cases (like sending a letter forward for an internal comment)
and other events related to records (for instance, modifying, signing or saving a document).
Altogether, over 40 different roles, actions or events were identified in the metadata. From here
on they are collectively referred to here as “events”. Metadata describing an event contain three
parts:
    1) date;
    2) information identifying the agent and the unit involved; and
    3) a string describing what happened or what was the agent’s role in the event.
For instance, information identifying an agent combined with date and event description string
reveals when, and by whom the document was signed. Some events were filtered out. For the
most part, filtered events are about actions that have taken place in the registry office of the
agency. The registry office handles incoming and outgoing letters of all units regardless of their
functional context.
Therefore, we excluded from the data all events involving a person who was known to have
sometimes worked in the registry office. Also events in which the agent was not identified as an
agency employee or the date was outside the time range examined were excluded. Finally, a
small number of events were left out because the person was listed in two units simultaneously
and the unit in which the person was working when the event took place could not be established
with certainty. However, employees who at different times worked in more than one unit and/or
position were included in the data.
The final dataset used in the study contained metadata of 43,113 events, which is about 38 per
cent of the original set. The metadata used in the study was about 5,259 records, 11,520 actions
and 2,801 cases. If not otherwise stated, findings in this study are based on the filtered dataset.
Information describing organisational context
The second source was information describing the organisational context in which records were
created. For this purpose, we collected information about the agency personnel, functions,
organisational structure and division of functions to different organisational units during the time
period examined. The information was gathered from various literary sources; policy documents,
organisation charts, and personnel lists.
In the analysis, classes in the functional classification were mapped to the unit structure. Some
functions proved to be common to several units, and a few to all units in the organisation. Only
one functional class could not be linked to any particular unit. This class was for records
generated in a minor function, which did not belong to the organisation’s main tasks and was not
reflected in its structure.
The organisational structure was changed in the middle of the time period examined; thus, the
analysis was done for both organisational structures. In reshuffle the organisation’s functions and
functional classification scheme remained the same, but some persons and responsibilities were
transferred between units and one unit was merged with other units.
At the last stage unit managers were asked to check whether the list of current and past unit
functions was complete and accurate. In the case of the merged unit, the information was
checked by its last manager, who was still working in the agency. All the time there were four
levels in the organisational structure: director general, director, unit manager and employee.
Because there seemed to be a clear difference between how managers and ordinary employees
had used the ERMS, executive staff and managers were for the most part analysed separately.
Although some persons worked in more than one position during the time period examined,
everyone stayed at the same organisational level (no employee was promoted or demoted).
The relationship between functions and units was roughly the same in both organisational
structures. Functional classification remained the same despite the changes in the organisation.
One of the eight main classes was reserved for general administration and three for other
supportive functions. A unit was responsible for all four, but also other units took part in the
general administration. Four main classes were dedicated to main business functions. In every
main class most sub-classes were mapped to one unit, but units (except for the supportive unit)
had responsibilities across main class boundaries.
Combining events and information about organisational context
The final step was to merge information about events in metadata (the first dataset) with
information about persons and functions (the second dataset). Information in the resulting new
dataset was as follows:
      name of the agent;
      description of the event or the role of the person in the event;
      date of the event;
      entity involved in the event (a record, a case, or an action taken in a case);
      name of the organisational unit (or position in the organisational hierarchy if the person
       was a director above unit level);
      identifier of the functional class;
      level of the functional class in the three-level classification hierarchy; and
      whether the functional class was one of those identified as belonging to the unit/manager
       (yes/no).
This dataset was used in the statistical analysis. In addition, a simple random sample of 500
records was examined to understand some details of record creation and ERMS usage.
Findings
General remarks about the ERMS usage
The delivering agency had made a decision to use its ERMS broadly in its functions.
Nevertheless, about one-third of the classification was unused. The functional classification
scheme had eight main classes and 97 second or third-level classes that could be used for
classifying cases and, thus, indirectly records. A total of 67 classes (69 per cent) of them had
been actually used to classify cases and records in the original unfiltered dataset.
The analysis of the organisational context showed that about 77-80 per cent of the functional
classes were at the responsibility of one unit only. The responsibility for the rest of the classes
was divided to more than one unit at the same time.
The ERMS was employed unevenly in functions (see Figure 1). About 13 per cent of events,
were generated in supportive functions (first four main classes). About 72 per cent of all events
were related to 7th main class in which answers to inquiries and other correspondence in one of
the organisation’s main functions was classified. Other main business functions (three main
classes in the classification) covered the rest, with a share of about 15 per cent of events.
Filtering process did not change this: distribution of events is practically identical in the original
and filtered dataset. The proportion of filtered events is roughly the same in all functional
classes.
The e-mail system was not integrated with the ERMS. Users had to manually import e-mail
messages by creating a new text document, copying e-mail content to it via clipboard and finally
capturing the document to the ERMS. A random sample of 500 records showed that e-mail
messages comprise about 21.4 per cent of records in the system (^3.1 per cent with 95 per cent
confidence interval). The manual process is fairly laborious. It cannot be said how much e-mail
was not captured because of this.
However, it is easy to assume that the number of e-mail messages in the system would be
significantly higher if the capture process had been automatic. In the light of the ERMS, the
organisation is effectively a “black box”. Only incoming and outgoing messages were captured
in the system. The above-mentioned random sample of 500 records was used to examine whether
internal interaction was documented in the ERMS. In less than two percent of records (1.4 per
cent ^1 per cent) both the record sender and the receiver were inside the organisation. Even then
the message content was typically a redirected e-mail message, which had been originated
outside the organisation
Usage of functional classification in the organisation
Functional classification and units. Metadata showed that organisational units employed the
ERMS very unevenly in their work. During the time period examined there were altogether 13
units in two organisational structures. All the units had events registered in the metadata, but one
unit had so few that obviously the system had been employed only once or twice in its
operations. Naturally, this tells only about ERMS usage. Actions that are done outside the ERMS
– for instance, printing out a document in the registry office and sending it on paper to be
processed in the unit – cannot be seen in metadata.
In both organisational structures one unit was responsible for the main function generating most
events. The share of this unit was about 65-70 per cent of events. Also, supportive functions
were concentrated to one unit and its share was 8-14 per cent of events.
Units generally participated in a wide range of processes. There was no one-to-one relationship
between a unit and a main class. On average each organisational unit had events in more than
half of the eight main classes.
Usually, one of the main classes was more heavily used than the others (see Table I). On
average, 73 per cent of the events of a unit were in its most used main class, even though the
percentage could be as low as 36 per cent. The three most used main classes covered about 95
per cent of the events of a unit.
On average, each unit used about 12 per cent of the classification. A total of 97 sub-classes in the
functional classification could be used to classify cases (and records)
A unit in charge of supportive functions had the broadest range: it had participated in processes
in 27 functional classes (about 28 per cent of the classification). Units in charge of supportive
functions – like general administration, finance, and personnel – had twice as many functional
classes identified as belonging to them than units on average. It may be a sign that the functional
classification was more developed in these areas than the others.
Functional classification and individual employees. Less than half (68) of the 148 persons
employed by the agency during the time period had used the ERMS at least once. On average, an
employee had more than 600 events registered in the ERMS, but the distribution is strongly
right-skewed: the median was only 69 events. About 48 per cent of all events were related to
three employees using the system most actively.
Of the 68 persons, 11 belong to one of the three managerial levels. Others (57) were part of the
executive staff. More than half of the 57 persons in the executive staff had events only in one
main class. Thus, using more than one functional main class was untypical for low-level
employees, but it was nonetheless common (see Figure 2).
Figure 2 also suggests that managers typically used the ERMS more broadly than executive staff.
On average, ordinary employees used two main classes and managers more than four. The
difference is statistically significant ( p , 0.001, two-tailed, Mann-Whitney test). The director
general was the only person having events in all eight main classes.
This is confirmed when we look at the distribution of events to the whole classification (and not
to the main classes only): persons higher in the organisational hierarchy used the ERMS more
widely than persons working at a lower level. Figure 3 shows a box plot describing the
distribution of events to classes at different organisational levels. The difference in usage
between persons working at different levels is obvious. The bottom and the top of the box are the
25th and 75th percentile (the lower and upper quartiles, respectively) and the band near the
middle of the box is the 50th percentile (the median). The whiskers (the lines that extend out the
top and bottom of the box) represent the highest and lowest values that are not outliers or
extreme values. Outliers (values that are between 1.5 and 3 times the interquartile range) are
represented by circles beyond the whiskers. For instance, the box plot shows that the median of
classes used by the executive staff (57 persons) is only three. A total of 75 per cent had events in
no more than six classes. Two workers had events in 14 and 15 classes, but they are so far from
the main group that they should be considered outliers. Possibly, they had worked in the registry
office for a short time and their events actually should have been filtered out from the data set.
However, we cannot be sure about this.
On average, employees in the executive staff had events in four and managers (unit managers and
directors) in 13 classes (the median being three and six classes, respectively). This is 4-13 per cent of the
classification. The director general (not shown in Figure 3) used more functional classes (36) than
anyone else in the organisation. This again shows how position in the organisational hierarchy changes
the ERMS usage.
Like units, employees used some functional classes more than the others. This is especially true for the
executive staff. Figure 4 shows how the events were distributed to the 67 sub-classes that were used to
classify cases and records. The y-axis shows the cumulative percentage and the x-axis how many classes
are taken into consideration. The classes are in descending order. The figure shows that in the case of
the executive staff (solid areas) the class containing most events had 30 per cent of events at minimum
and 74 per cent on average. For the executive staff the three most used classes covered 66 per cent of
the events at minimum and 95 per cent on average. Managers used ERMS more extensively. In their
case (lines in Figure 4), the most used class had only 20 per cent of events at minimum and 54 per cent
on average.
Predictability of usage. Next we compared the event metadata with how the ERMS should have been
used in the organisation in the light of what we knew about distribution of work between the
organisational units. How predictable was the behaviour of persons? Were events generated in those
classes for which the unit was responsible? Table II shows the answer.
About nine times out of ten the function was identified to be one of those under the responsibility of
the unit. This was true both for executive staff and unit managers. Unit managers participated slightly
more to processes that were not identified as belonging to the unit. We assumed that directors above
the unit level were responsible for all functions in sub-ordinate units. Therefore, a director controlling
multiple units had 34-72 functional classes in his area. No director operated outside this domain
according to the metadata.
Figures 5 and 6 show by unit how well mappings between organisational units and functional classes
matched the events in the metadata. The number following the unit name shows the absolute number
of events. Generally, it seems possible to predict quite well how functional classification is used in units.
Only about 8 per cent of events are misplaced. Description of unit functions in the second organisational
structure (Figure 6) seems more accurate.
There are several ways to explain the mismatch between events in the metadata and supposed usage of
the ERMS in the units. One explanation might be that the mapping process failed: we did not correctly
identify all the functions belonging to a unit. Mapping for the second organisation may have been more
successful, because details of the older organisation perhaps were partly forgotten. An alternative
explanation is misclassification. All the events of some units were in a “wrong” class. In these cases the
unit generally did not have many events registered in the system. Obviously the system was not used in
the unit’s daily activities. Misclassification may be due to user inexperience or difficulties in mapping the
unit’s functions to functional classification. A third explanation is that there is no error: events in a
wrong class reflect (perhaps unofficial) cross-unit process participation, which was not recorded in policy
documents or recognised by unit managers
Discussion
The findings of our case study suggest that only a part of the functional classification is used by
organisational units in its daily activities. It also seems possible to determine in advance what classes will
be used by a unit. At the same time the findings confirm Seitsonen’s (2009) conclusion that there is no
one-to-one relationship between organisational units and functional main classes: both supportive units
and units in charge of business processes employ a large number of main classes and sub-classes in the
classification. Hence, from the unit alone one cannot deduce what classes in the classification the
employee is likely to need in his work. Knowing the unit does not even reduce significantly the range of
possibilities. Automation based on units alone is not likely to work very well: also the person interacting
with the system has to be taken into account.
In general, individual employees employ only a small part of the classification. However, this does not
apply when we go higher up in the organisation’s hierarchy: the higher the person’s position in the
hierarchy, the more classes the person is likely to use in the work. This is natural, because managers
have to deal with all issues of their subordinates.
Regardless of the position, an employee generally uses classes related to functions of his/her unit.
Among the functions of a unit, some functions are more likely to be used than the others. A user
generally employs in his work some functional classes more than in others. If past behaviour is known, it
is possible to say with great likelihood what functional classes a user is likely to employ when (s)he
interacts with the ERMS. This is true especially if the user has a low position in the hierarchy. Hence, it
seems possible to create unit/user profiles, which could help both in automatic creation of metadata,
and user interaction with a system. Unit and user profiles could be created automatically by gathering
information about the ERMS usage. One could also create them manually by analysing functions of units
and users.
User and unit profiles are likely to work best in an organisation with a rigid and clear division of work. An
organisation where job descriptions are fluid may not benefit from the creation of profiles. Further
research is needed to see how this would work in a larger, more complex organisation. As the functional
span of an organisation and its number of users grow, the ability to use the model presented may
become more limited.
The study has some limitations. The findings are based on records metadata and examination of one
government agency only. Inside the agency, some units and employees used the ERMS more than the
others, which may skew the results. It is also possible that some records were misclassified and this has
effect on the results. However, there is no reason to assume that the number of misclassified records
would be high. Instead of misclassification, seeming anomalies in the metadata may reflect
organisational work that does not comply with official descriptions of organisational processes. Another
limitation in the study is that the agency ERMS was not used to capture the organisation’s internal
communication. The records in the ERMS show the formal decision making process and the agency’s
interaction with the outside world. They tell less about what happens inside the organisation when
“inputs” are turned to “outputs”. There may have been free flowing internal e-mail discussions, which –
had they been captured in the ERMS – would make the picture of the organisational behaviour different.
Archival theorists have been concerned about how some groups are marginalised in records and
archives (Schwartz and Cook, 2002). The paucity of information about discussions inside the agency
shows that there may be reason for concern.
Although one case study cannot give a comprehensive and reliable view on how electronic records
management systems are generally used in organisations, the findings are indicative.
Conclusions
Access to electronic records management systems could be facilitated by building systems that guide
users interacting with the system. This could be accomplished by creating unit profiles which link units
to organisational functions described in the classification scheme. In the case of executive staff it would
be helpful to create user profiles that are either based on previous usage history of the ERMS or a
person’s tasks in the unit. Although this does not allow us to fully automate record classification process,
combined with content-based classification methods it might produce good results. This is an area
where we need further studies. Also, the findings of this study should be tested in other organisational
environments. People at different organisational levels used an electronic management system
differently. This should be taken into consideration when systems are planned. The same solution may
not be optimal for both managerial and executive work in an organisation.