0
Electronic Document
Management in Installation
Projects
Designing a
requirements
system
to
support
user
Master’s Thesis
Simo Riutta
22 March 2016
Information and Service
Economy
Approved in the Department of Information and Service Economy
__ / __ / 20__ and awarded the grade
_______________________________________________________
Aalto University, P.O. BOX 11000, 00076 AALTO
www.aalto.fi
Abstract of master’s thesis
Author Simo Riutta
Title of thesis Electronic Document Management in Installation Projects: Designing a system to
support user needs
Degree Master of Science in Economics and Business Administration
Degree programme Information and Service Economy
Thesis advisor(s) Advisors
Year of approval yyyy
Number of pages 86
Language English
Abstract
This thesis studies how to develop a structural design for an Electronic Document Management
System (EDMS) based on user requirements. The user requirements have been collected in
multiple interviews from various stakeholders in the case company using requirements elicitation
and engineering practices. The requirements have been then analyzed together with Electronic
Document Management (EDM) theory to build up a structural framework that would enable the
implementation of a system that supports and fulfils the initial user requirements.
The case company KONE operates in an elevator and escalator business that is very projectoriented and this creates distinctive characteristics and challenges to the document management.
The imbalance between document creators and document users as well the involvement of many
document users during the projet’s lifetime are two of these main challenges.
This thesis approaches the EDMS design by first clarifying the users of project documentation.
That is the first research question. After that these end users and other relevant stakeholders are
interviewed to find out what are the current problem areas in document management and what
kind of capabilities should the EDMS have to support and enable more efficient working practices.
Once these two preliminary research questions have been answered comes the analysis and
conclusions on the structural design.
There are two general ways of structuring documents in an EDMS: hierarchical model and
metadata model. Hierarchical model is the one that is traditionally been used in companies and so
in KONE, also. The empirical findings in this thesis make a clear case that the new system has to
be metadata based model, where documents are located based on “what they are” instead of
“where they are”. This is also backed up by literature and academic studies conducted in
construction industry that faces the same project-oriented characteristics as the case company.
Keywords electronic document management, requirements engineering, installation project,
metadata structure, system design
i
Table of Contents
1
Introduction ............................................................................................................................. 1
1.1
Topic................................................................................................................................................. 1
1.2
Research problem ....................................................................................................................... 3
1.2.1
Research Questions ............................................................................................................................... 3
1.2.2
The General Problem of Project Document Management ..................................................... 4
1.2.3
Objectives of the thesis ........................................................................................................................ 5
1.3
1.3.1
Requirements Engineering ................................................................................................................ 6
1.3.2
Interviews ................................................................................................................................................. 8
1.4
2
3
Scope and point of view ...........................................................................................................10
1.4.1
Scope of thesis ...................................................................................................................................... 10
1.4.2
Point-of-view......................................................................................................................................... 11
Motivation ............................................................................................................................... 13
2.1
What drives KONE to change? ...............................................................................................13
2.2
Why is electronic document management important?................................................14
Theory Part ............................................................................................................................. 16
3.1
Requirements engineering theory ......................................................................................16
3.1.1
Functional and non-functional requirements ......................................................................... 19
3.1.2
Requirements elicitation .................................................................................................................. 20
3.1.3
Requirement elicitation techniques ............................................................................................ 23
3.1.4
Requirements analysis ...................................................................................................................... 25
3.2
Electronic Document Management theory .......................................................................27
3.2.1
Structure of EDM systems ............................................................................................................... 27
3.2.2
Functionalities of Electronic Document Management Systems ....................................... 30
3.2.3
Benefits of Electronic Document Management....................................................................... 32
3.3
3.3.1
3.4
4
Methods used ................................................................................................................................ 6
Empirical results from literature ........................................................................................34
Previous studies of EDM systems in construction industry .............................................. 37
Intellectual history of the research.....................................................................................39
3.4.1
History of Requirement Engineering research ....................................................................... 39
3.4.2
History of Electronic Document Management research ..................................................... 40
Empirical part ........................................................................................................................ 42
4.1
The Case Company ....................................................................................................................42
ii
4.2
4.2.1
Users of project documentation .................................................................................................... 43
4.2.2
EDM requirements from stakeholders ....................................................................................... 45
4.3
4.3.1
4.4
5
Presentation of Empirical Data ............................................................................................42
Explanation of the Empirical Results .................................................................................47
Requirements explained in detail................................................................................................. 48
Analysis of the Results .............................................................................................................55
4.4.1
Classifying the requirements.......................................................................................................... 56
4.4.2
Validity of the results ......................................................................................................................... 58
4.4.3
Comparison of the results with theory and literature ......................................................... 59
Conclusions ............................................................................................................................. 63
5.1
Recommendations for EDM structure................................................................................63
5.2
Discussion ....................................................................................................................................66
5.3
Recommendations for further research ...........................................................................70
Appendix A: Interview support questions ........................................................................... 71
Appendix B: Requirement collection template .................................................................. 71
Appendix C: List of requirements ............................................................................................ 72
Appendix D: Business roles of the interviewees ................................................................ 75
References ....................................................................................................................................... 76
Books and reports............................................................................................................................................... 76
Articles..................................................................................................................................................................... 76
Conference proceedings, reports, and parts of collections ................................................................ 77
Interviews .............................................................................................................................................................. 79
Internet-references ............................................................................................................................................ 79
iii
List of Figures
Figure 1: Requirements engineering process ............................................................................ X
Figure 2: Model for requirements elicitation technique selection ............................................ X
Figure 3: Example of a hierarchical tree structure .................................................................... X
Figure 4: Overview of typical EDM system using metadata .................................................... X
iv
List of Tables
Table 1: User roles in Customer and Fulfill processes ............................................................. X
Table 2: Elicited requirements from KONE frontlines and functions ...................................... X
Table 3: Classes of the requirements ........................................................................................ X
v
Glossary
ECM = Electronic Content Management
EDM = Electronic Document Management
EDMS = Electronic Document Management System
EPF = Electronic Project Folders. EPF is the name of the electronic document management
project inside KONE.
Frontline = KONE branch in a country or an area.
DM = Document Management
IMT2 = Installation Management Tool 2. Custom mobile application created for Installation
supervisors.
KTOC = KONE Tendering and Ordering Configuration tool
Metadata = Information about the document that is used to identify it, e.g. customer name or
sales order number.
PDM = Product Data Management
Project document = Document related to the installation project. Created, used, edited, or
referenced during the project.
Stakeholder = People in the organization directly or indirectly affected by the EDM system.
TSS = Technical Sales Support. Support function inside KONE.
vi
Introduction
1 Introduction
1.1 Topic
Electronic document management (EDM) is a field that has been under continuous
development since its origin in the introduction of digital documents in the 1970s. The
amount of computer-created documents has been increasing exponentially through the years
with large companies creating millions of documents per year that need to be stored
somewhere. In this “somewhere” the documents have to be first of all accessible, secondly
found, and once found retrieved or edited.
It is no longer possible to work using local network drives and to collaborate with email
attachments. Customers and employees alike are expecting faster response times and
seamless collaboration in which emails are just too inefficient. In today’s mobile and
evolving global business environment employees are not fixed to their office posts and flow
of information is a necessity to keep the wheels of the company spinning.
The global elevator and escalator company KONE has faced these challenges of transformed
business and information environment. Internal feedback from every level in the company
was indicating that something had to be done to the documentation practices. Especially the
installation project documentation created during elevator and escalator installations was
critical area of improvement in order to improve quality and customer satisfaction as well as
cut fixed costs and free up time from documentation to more profitable tasks.
This thesis inspects the project documentation at the case company KONE and looks for a
design that would enable better usability and sharing of information. The problem is
approached from the ground level up. For this thesis 42 KONE employees were interviewed
and their opinions about current documentation problem areas and desired future
improvements were recorded. The empirical data of EDM solution requirements would later
on work as a guideline in the designing and implementation of a new EDM ecosystem in the
case company. EDM research, theories, and literature are used to reflect and discuss the
empirical findings received from the interviews with the stakeholders.
The stakeholder requirements for EDM were collected using requirements engineering
method. Requirements engineering is often used when creating new computer software to
learn what kind of qualities, services, and functionalities the software should have. Acquiring
1
Introduction
requirements for a computer system is generally understood as a process of elicitation rather
than just capturing or collecting requirements. (Zowghi and Coulin 2005). Requirements are
not just lying around waiting to be collected. Requirement elicitation is a process of learning,
uncovering, extracting, surfacing and discovering the needs of customers, users, and other
potential stakeholders (Hickey and Davis 2003). This means that the system requirements
cannot be understood without interaction with the end-users.
Requirements engineering is not only elicitation but also analysis of the discovered
requirements and documenting them. The research in this thesis identifies the main problem
areas experienced by the users and key stakeholders and proposes a structure how to
overcome them. In other words, the thesis’ intention is not to cover a full range of
requirements of the system, from performance to access rights, from user interface to system
integrations, but to give a structural and architectural framework for the EDM system.
Though, also other areas apart from structure are being raised to discussion during the
requirements elicitation interviews and appear in the findings. Even though not directly
related to structure they implicate what kind of features and capabilities the system should
have. Learning what are the main issues restraining efficient working practices in the
company will guide on how to develop the project documentation the best. The performance
constraints, access right management, choice of system provider, and all other important but
more detailed tasks of IT specialists and management, would be covered later in the KONE’s
EDM project, titled Electronic Project Folders (EPF).
When thinking about project documents one has to also think about the purpose the project
documents are serving. Their main goal is to transfer and store information. Some of this
information is communication to the customer, some is communication inside the company,
and some of it is to third parties, like governments. There are many ways to share information
but due to established practices and binding regulations it is stored and shared inside
documents. The faster and easier the sharing of information is, the more efficient the
company becomes. Efficient information management is one of the key factors of successful
project management (Gabrielaitis and Bausys 2009).
The project nature of the business is typical to construction industry as whole (Björk 2006).
This thesis refers to practices in the construction industry because elevators and escalators
projects, in essence, construction projects. Information management in construction industry
has undergone a big change in the last decade induced by email, World Wide Web, and
2
Introduction
mobile data connections (Gabrielaitis and Bausys 2009). These changes have been
incorporated inside KONE to some extent but when it comes to project documentation the
practices are quite rudimentary for the most parts. Email and email attachments are the
primary way of communication and it is way congregated by the flood of other emails,
slowed down to halt by response time delays.
With the increase of IT applications and the explosion of digital data it has become difficult
for companies – and for the users within – to effectively capture, manage, and control
information in traditional manners (Gabrielaitis and Bausys 2009). For this reason, the EDM
systems have been developed. Their aim is to have all the stored documents available to the
users whenever they might need them and to automate the management of documents so that
the users are not serving the documents or the system but the documents and the system are
serving the user.
A good definition of EDM is presented by Ralph Sprague (1995) to give an idea of its nature:
• Electronic: the use of modern information technologies.
• Document: a set of information pertaining to a topic, structured for human comprehension,
represented by a variety of symbols, stored and handled as a unit.
• Management: creation, storage, organization, transmission, retrieval, manipulation, update,
and eventual disposition of documents to fulfill an organizational purpose.
1.2 Research problem
1.2.1
Research Questions
The goal of this thesis to answer the three research questions related to project documentation
in general and at the case company. The answers and conclusions to these questions are based
on empirical data collected from the case company.
The three research questions are:
Q1: Who are the users of installation project documentation?
Q2: What issues are perceived as key requirements in project documentation by
stakeholders?
3
Introduction
Q3: How should the documentation system be designed to answer the stakeholder
requirements?
To understand what the key requirement areas are and how to answer them, we need to start
by identifying the different user roles in installation projects. Who are creating the documents
and when? Who need to access and use these documents? By answering these questions we
have the fundaments for understanding the project documentation process.
With the fundaments in place, it is possible to start finding out what issues are limiting
efficiency and causing problems in project documentation by interviewing the relevant
stakeholders. The second question is answered in the empirical interview data that is
combined and given points according to perceived priorities by the users.
Once we know the users and their needs, the third questions can be answered. The third tries
to find common denominators behind the system requirements and current problem areas.
The first two research questions serve as prerequisites to answer this third question, the most
important question from the company’s viewpoint and the one that has to be answered before
any EDM system can be implemented.
1.2.2
The General Problem of Project Document Management
In a large company there are typically many people involved in a single project and they need
to share information between each other efficiently. One person creates a document and
others need to access the information inside the document. The storing, finding, and
retrieving of the document should be easy and fast. Inefficiencies arise when the sharing or
the retrieval of information takes too long or is complex. It is not viable for Person A to
contact Person B by email and ask for a document and then wait for a reply and hope to have
it in time and with the correct content.
An example of this could be a Customer asking for a copy of the elevator drawings.
Customer contacts an Installation Supervisor but the Installation Supervisor does not have the
document available. He then needs to contact Engineering department or Installation
administrator to ask them to email the document. Once the Installation Supervisor has
received the email attachment he can send it forward to the Customer. This process of
sending emails back and forth and explaining the situation to new people can cause a delay of
days before the customer query has been successfully answered. This could be damaging for
the company as the customers of today are expecting reliable information in a timely manner
4
Introduction
(Asprey and Middleton, 2003, 30). It also causes frustration in the employees when they are
constrained to these inefficient procedures.
To counter the problem of paper documents and email floods the EDM systems were created.
They were intended for collaboration and content sharing. A common characteristic of an
EDM system has been that all documents are stored in a single storage area. When not done
properly, this results into slow searching and retrieval of documents (Alberto et al. 2009).
Consider a huge storage where all content is mixed up and not indexed. Finding and
retrieving entities (i.e. documents) will take time, and this time is multiplied by every user
and by every search the users do. This combines to millions of wasted minutes a year in a
large company like KONE is, which, when transformed to monetary terms, means millions of
euros.
Another general problem related to documentation is the persisting need of physical paper
documents. One person might be managing dozen projects at a time which all have their own
drawings, contracts, installation manuals, customer correspondence, and so forth. It is simply
impossible to carry around thousands of documents from installation site to installation site.
The documentation has to be stored in an electronic format so that the users are able to access
them. This digitalization from paper to electronic format has largely happened in all the
companies by now, but still these electronic documents are being printed back out on paper
because it is not possible to have the electronic documents available everywhere, or they may
have to be signed on paper format.
Social and organizational factors are always present when a system is being developed in a
company, in the requirements engineering part especially, as different stakeholders may have
different individual and organisational goals that they want to include in the new system
(Kotonya and Sommerville 1998, 56). These sociological issues have to be taken into account
(O’Brien 2000) or otherwise they will become problems at the implementation stage. The
requirements have to be given an even and fair ranking so that one opinion does not trump
another. This makes the requirements engineering a complex process that defines lot of the
end-products success and user acceptance.
1.2.3
Objectives of the thesis
The ultimate objective of this thesis is to present a framework for an effective document
management system for KONE’s purposes. A fitting and solid framework will save time and
5
Introduction
money in the implementation of the system. It also helps to create a system that actually
corresponds to the user needs and enables new and more efficient ways of working. To fulfill
this ultimate objective this study answers to few questions on the way. This means
identifying the different user groups that are using the project documents, what are the special
needs of these user groups, and learning what requirements they have for the future system.
These objectives are to be achieved by analysing the empirical data collected from globally
conducted interviews in the case company with subject matter experts. Analysis of the
interviews and the lists of requirements given by the interviewees are used in building the
framework and structure for a new KONE EDM system. The findings of the thesis will be
eventually used by KONE in the larger EDM project Electronic Project Folders that aims to
redesign the documentation practices also in maintenance and supply line, which are
excluded from the scope of this thesis.
Even though this research focuses on one company and their user requirements, the objective
of this thesis is also to give guidelines to EDM structures and implementation more generally.
The nature and challenges of project documentation in an environment with multiple users
and varying complexity of the projects is the same for everybody.
1.3 Methods used
Live semi-structured interviews and requirements engineering practices have been the
methods for collecting and analysing the empirical data in this thesis. Literature review has
been used to reflect document management theory and previous EDM studies with the
empirical findings of this thesis. Literature review has also been used to create a theoretical
background for requirements engineering with emphasis on requirements engineering
techniques and experiences in as similar projects as possible. The interview method for
requirements elicitation is based on recommendations of requirements engineering theory.
1.3.1
Requirements Engineering
In requirement engineering there is no single technique to conduct the process of
requirements engineering but appropriate techniques depend of the application (Kotonya and
Sommerville 1998, 9). The main application of requirements engineering used in this thesis is
requirements elicitation. It means uncovering, extracting and surfacing the needs and wants
of the potential stakeholders (Zowghi and Coulin 2005). The stakeholders might not be
6
Introduction
consciously aware of all of their requirements or might not realize what requirements are
actually related to the system and what are not. The requirement engineering, and especially
requirements elicitation, is generally accepted as one of the most critical parts of software
development projects. (Zowghi and Coulin 2005). This, uncovering and surfacing of all the
relevant requirements, is where the challenge lies and which can determine the success or
failure of the whole system.
Requirements often have a multidisciplinary nature which increases the complexity of the
process (Zowghi and Coulin 2005). The requirements engineering activities used in this
thesis are requirement elicitation and requirements analysis. Requirements elicitation can also
be conducted in many ways. Chosen in this case study is the interview method, which is
considered to be the most conventional and commonly used (Zowghi and Coulin 2005). It
enables interactive communication and discussion with the stakeholders and is more flexible
than a questionnaire and can be more easily organized and conducted than a workshop.
During their case studies of Swiss and German companies which had successfully done data
warehouse projects, Winter and Strauch (2004) write that is it important to create a picture of
the As-is state and of the To-be state. This helps in the engineering of requirements and in the
designing of the system. The elicited requirements have been used in this thesis to create the
as-is state. The requirements are then compared to EDM system theory, empirical results
from literature, and stakeholder recommendations from interviews to build the to-be state.
To understand the importance of requirement engineering it is important to understand
selection process of an enterprise system. Lech (2012) has collected from enterprise system
literature a list of a general way of how enterprise system selection is done:
1) Define organisational needs
2) Gather information on required system functionality
3) Evaluate available alternatives
4) Select the most suitable system
5) Negotiate a contract
This thesis focuses on the first two steps of the selection. They are very critical, because if
done incorrectly, the evaluation of available systems and the selection of the most suitable
system are based on wrong needs and requirements. To perform these first two tasks, one has
7
Introduction
to discover and collect the organisational requirements for the new system (Lech 2012). In
this, requirements engineering method and its techniques, especially requirements elicitation,
are useful.
1.3.2
Interviews
Interviews are often separated in different archetypes. Kotonya and Sommerville (1998, 62)
group them into two categories: (1) closed interviews and (2) open interviews. Closed
interview consists of predefined questions that the interviewees answer. In an open interview
there is no predefined set of questions and subject at hand is discussed in open-ended manner.
Zowghi and Coulin (2005) group interview archetypes into three categories: (1) unstructured,
(2) structured, and (3) semi-structured, the last representing a combination of the former two.
Open interviews give the stakeholders the possibility to freely express their views but it has
the risk of the conversation drifting to a side track or important aspects never surfacing. In
structured interviews, the success depends on knowing what questions to ask, when should
they be asked, and who should answer them (Zwoghi and Coulin 2005). When the correct
questions are known the results are good. Semi-structured can be both of these worlds, in
good and in bad.
The interviews done for this thesis were semi-structured as they were combination of both
unstructured (open) and structured (closed) interviews. There was a set of questions as a
support (see Appendix i.) to help the interviewees to think of the different aspects of project
documentation and to include the same sort of framework and content in all the interviews,
but the interviewees also had a chance to bring to discussion other aspects they felt important
in project documentation. Therefore the interviews had both a structural and unstructured
parts. The guideline questions used were same for all the interviews.
Interviews for this thesis were mostly conducted on a teleconference call. This was due to the
fact that the stakeholders interviewed worked around the globe and travelling to meet them
face-to-face was not feasible. The stakeholders located in Finland were interviewed face-toface. The interviewees chosen consisted of the end-users and of middle management
personnel who had a good understanding of the installation and delivery process and had
experiences the wide range of current difficulties. Most of the stakeholders had background
in various different positions inside KONE from the entry-level positions up which added to
their value as subject matter experts. The target was to get subject matter experts from
8
Introduction
different fields and cover the whole delivery process from the early steps in Sales process to
the end of Installation process where the installed equipment is handed over to the customer.
The interviews were conducted in two parts: (1) an introductory interview and (2) a followup interview. In the introductory interview the stakeholders were introduced to the subject
and to the business goals of the new EDM system. They were also asked for initial thoughts
and opinions on project documentation and document management practices in their own
work and in their frontline. After the first session they were given a requirements collection
template (see Appendix ii.) and a set of questions (see Appendix i.) to help in thinking about
the requirements before the follow-up interview session. In the second interview discussion,
the follow-up interview, collected requirements from the stakeholders were discussed
together to form a common understanding of them. It is important to be able to make further
clarifications to the written requirements document to avoid misunderstanding on both sides.
If it proved to be necessary, another follow-up discussion was arranged to a later date. This
was sometimes needed because not all the frontlines had a ready set of requirements for the
first follow-up session or things came up during the first follow-up discussion that needed
further clarification.
Winter and Strauch (2004) write that, based on multiple case studies in UBS (Union Bank of
Switzerland), questionnaires are not sufficient method for requirements elicitation and have
to be supplemented by interviews. In their study Winter and Strauch also made a finding that
the interviewees have to be able to prepare before the interview by analysing their current and
possible future processes. The preparation should not be over-guided, though, as it could
limit the creativity of the users interviewed. Another remark from Winter and Strauch’s
(2004) requirement elicitation study on data warehouse systems was that creating a complete
compilation of requirements from everybody is too expensive and only results in too much
irrelevant information. It is better to target interactive surveys to certain user groups and
experts. These findings from Winter and Strauch have also been applied to the requirements
elicitation interviews used in this thesis: A certain group of subject matter experts were
targeted, they were given guidelines what kind of a system was to be developed, and they
were given time to prepare and collect requirements from their frontline before the follow-up
discussion where their requirements would be documented for analysis.
The author had previous experience in the case company so there were existing contacts to
point out the right persons to interview in different frontlines and functions. The interviews
9
Introduction
were arranged according to the schedules of the interviewees. The 13 frontlines interviewed
were very eager to participate; some even contacted the author proactively before they were
contacted. Only one frontline refused from the requirements collection process due to their
busy schedule.
1.4 Scope and point of view
The approach used in the design of the new EDM system was chosen to be bottom-up: the
end-users express what the current pain points are that disable them to perform their tasks as
they would like to and how could the collaboration with others be improved, and then the
system is designed based on these requirements. This approach has been chosen because the
system ought to serve the users, and not the other way around. End-users are the ones who
truly know what qualities are needed to perform their work. The technical requirements
would be engineered only later on once the functional requirements were known.
1.4.1
Scope of thesis
To overcome the enormous and exhausting task of full-scale implementation of a companywide EDM system it has to be cut into smaller pieces. The first pieces where everything has
to begin are research, planning, and design. This thesis focuses on the designing a EDM
structure that answers to the user needs and enables the features and functionalities that the
system should have.
This thesis is not covering all (or even the most) the aspects related to creation and
implementation of a full-scale document management system. Left outside of the scope are
technical performance requirements, access rights determination, supplier selection process,
change-over from old system and piloting of the new system, to mention a few EDM project
steps that are important even though not covered here. The aforementioned areas are critical
to the success of an EDM system but are not in the focus area of this study. Results and
findings of this thesis can be used as a solid foundation when moving on to these next steps
in the EDM implementation process.
Also left out of the scope are all the change management issues that arise in large and
fundamental projects as enterprise system development. Change management has been taken
into consideration in the requirements collection by giving the end-users and frontlines the
10
Introduction
chance to have their voices and to actually make a difference in their everyday work. The
bottom-up development model of EPF aims to provide a system that the actual users have
been creating instead of force feeding a solution from the top.
The focus is solely on project documentation and project documentation system structure.
Project documentation can be any kind of documentation that relates to or is created during
the installation project of an escalator or an elevator: emails, text documents, spreadsheets,
audio files that play in the elevator, CAD drawings, and so on. Other kind of Electronic
Content Management (ECM), not related to installation projects and documentation, is left
outside of the scope.
Project, in the sense that is being used in this thesis, starts from the very beginning of an
elevator or escalator construction project, where the first contacts are being done between
KONE and the customer. Scope of this thesis follows the construction project all the way
from the first sales lead to the stage where the equipment (elevator or escalator) is been
handed over to the customer. After the handover to the customer, there is likely to be future
communication between KONE and the customer, related to maintenance of the equipment or
possible later refurbishment to the equipment, but this thesis’ scope ends at the handover to
the customer. Maintenance stakeholders has been interviewed, though, for this thesis to get
their documentation insight listed in the requirements (Table 2), but due to their different
processes, business models, IT systems, and user groups, they are otherwise excluded.
1.4.2
Point-of-view
The interviews’ point-of-view is to find out what are the current problems and challenges that
KONE employees in different roles are facing related to project documentation and what kind
of improvements and features are the end-users looking for. The goal was to get a holistic
view from many different stakeholder groups, functions, and frontlines to be able to actually
create a current state diagnosis that shows both the major issues as well as the minor ones.
The results of this problem-centric analysis will be then used in creating an optimal To-be
state design for the new system.
Project documentation can be seen as sub-part of project management, so the big picture of
project management should be kept in mind when talking about project documentation. The
information stored in documents is critical to efficient collaboration and to success of the
installation that determine the successful project management, but this thesis does not study
11
Introduction
project management other than the parts related to documentation. What will become
apparent in this thesis is that the point-of-view in EDM system development has to be in the
business goals and needs that the system has been set to achieve.
12
Motivation
2 Motivation
2.1 What drives KONE to change?
The need for a company-wide solution for document management has been present at KONE
for a long time. Documents have been stored in multiple locations depending on the local
practices around the world. Some documents have been kept on computer hard drives, some
have been stored in the email inbox, some have been uploaded to an online database which
has only been accessible through the KONE intranet. To access this intranet, the users had to
be at the office or set up a VPN connection from outside the office (this VPN connection was
not been possible with mobile devices and everybody did not have credentials to use it). In
some frontlines a huge chunk of the information was still been stored in paper documents.
These documents were printed out, manually edited, scanned back in, electronically edited,
sent to a printing company on a USB stick by mail, printed back out and sent back to KONE
by mail. This kind of manual printing and scanning frenzy had been day-to-day work for
back office staff.
Most sophisticated documentation solutions in KONE are the ones that have been developed
specially for the electronic document management purpose by the frontlines themselves.
These local EDM solutions have functionalities that lack from the globally offered EDM
tools. The limitations of the local systems, though, have been scarce resources for system
development and maintenance, and the structure that has been, quite understandably,
developed based on their specific local needs. The same system might not be sufficient for
the neighbouring frontline and all of these local solutions were designed to solve some
particular EDM problem instead of being full-scale EDM solutions that help all the user
groups involve. The resource limitations and the lack of integrations to global enterprise
systems were problems mentioned by every frontline with a local EDM solution.
A business development manager of one of these frontlines with a local EDM told that they
(as a frontline) no longer have resources to maintain their existing system and they were
anxiously waiting for a global solution. At the moment their local EDM was being updated
and maintained by an ex-employee of KONE, who was the only person who really knew how
the system worked. Some of the frontlines who did not yet have a local solution were
investigating their options and some even already piloting an EDM software. But the
13
Motivation
feedback from all of these frontlines was uniform: They would rather have a system created,
maintained, and funded by the global parent company.
The reason why the different solutions existed in the first place was that KONE had grown
through acquisitions into new areas throughout its history. The countries in these areas had
mainly continued their existing documentation practices and which resulted in a situation
where there are many overlapping systems in use. There exists no “KONE Way” of doing
document management. There was a clear strategic goal and push from the high up that a
KONE Way for doing things was required throughout the company.
Due to the aforementioned reasons, it had become apparent in KONE that project
documentation is a critical area for improvement. It would not only save time of the
employees and cut costs, but would also enable leveraging the benefits of modern mobile
devices. Tablets and smart phones had already been given to some user groups to enable
them to spend more time on the site and in the customer interface instead of at the office.
With users already having the devices to work mobile they now needed the systems and
software to support them.
The reason why the project of Electronic Project Folders in KONE has not been started
earlier is the fact that the magnitude of this project was overwhelming. It includes all the
countries of operation, almost every user group and business function in the company, and
many different IT systems that have their own special features and inflexibilities when it
comes to integrating them to other systems. The incremental build-up of IT systems and the
involvement of many organizational units often make the design and implementation of data
warehouse systems (which EDM system also partly is) difficult (Winter and Strauch 2004).
Due to these reasons, it has been too complex of a project to fall under any one function to
take over the responsibility of running it.
2.2 Why is electronic document management important?
Electronic documents have proliferated rapidly and continue to do so. Individuals and
companies are creating so many documents that it is impossible to manage them manually
anymore. Documents are typically supporting enterprise’s key business processes and are not
the core of the business itself (Asprey and Middleton 2003, 43). Focusing on a support role
like document management may seem insignificant, but actually documentation is a process
that lurks everywhere in companies. It is the small cog that rotates together and between the
14
Motivation
larger cogs that are the main processes of the company. If not structured and built correctly,
the small part of documentation may become a large part that is sucking excessive time,
money, and resources from the company.
EDM system’s purpose should be providing all the project members with the same
information in a reliable and efficient manner (O’Brien 2000). Accurate and reliable
information enables easier decision making and improves overall quality. When everybody
has access to the same information collaboration becomes smoother which is integral part in
companies of any size.
Centrally storing and managing documents also gives the company secondary benefits. The
information in the documents can be analyzed to create knowledge that has potentially
significant impact on the company’s performance. Business analytics and modern big data
applications offer companies competitive advantage and opportunities for serious
performance improvements (see Chen et al. 2012 or Malhotra 2005 for more information
about leveraging enterprise knowledge). EDM systems can be fundamental building blocks in
knowledge management in companies (Asprey and Middleton 2003, 154)
Companies are also setting themselves at risk when the document management is not on a
firm foundation. Uncontrolled storing and sharing of documents exposes the company to loss
of vital business information, hurts customer and employee satisfaction, and confidential
information may leek outside the enterprise boundaries. These risks should not be taken
lightly by any company, especially not by large publicly listed enterprises.
15
Theory Part
3 Theory Part
Theoretic background of this thesis consists of requirements engineering theory and
electronic document management theory. First is introduced the requirements engineering
theory and the parts of it that apply to this case study. Requirements engineering can be done
for very different kind of applications and systems. Therefore it is often very generic. In this
thesis the more generic requirements engineering and elicitation theories are viewed from the
particular viewpoint of EDM and what can be seen relevant for the case company.
Second is introduced the EDM theory. EDM is a field of study newer and more specific than
requirements engineering. Focus is on theories of design and structure of EDM architecture.
The theory and lessons learned in previous EDM studies are reflected on the empirical
findings to form a structural framework of an efficient and user-friendly system that fits the
requirements of the case company.
3.1 Requirements engineering theory
Requirement engineering is the act of eliciting, analyzing, documenting, and validating
requirements for software or a computer system (Sommerville and Savyer 1997; Kotonya and
Sommerville 1998, 8). The process begins by requirements elicitation. Requirements
elicitation means discovering of the requirements from the stakeholders. Requirements
elicitation is explained in more detail in the chapter 3.1.2. After elicitation comes analysis of
the elicited requirements. Analysis is important to truly understand what the requirements are
about, to compare requirements of different stakeholders, and to be able to make correct
choices in possible trade-off situations that may occur among the requirements. Requirements
analysis is discussed in the chapter 3.1.4.
Requirements engineering process is often long and is done in stages to better organize it.
Presented below is a model of requirements engineering process by Kotonya and
Sommerville (1998, 32) with four stages: requirements elicitation, requirements analysis and
negotiation, requirements documentation, and requirements validation.
16
Theory Part
Figure 1: Requirements engineering process (Kotonya and Sommerville 1998)
As can be seen from this model, the process does not actually begin with requirements
elicitation but from the domain understanding. A substantial part of the requirements
engineering involves exploring the problem domain and the requirements that are situated in
that domain (Zowghi and Coulin 2005). This means understanding what kind of problem(s)
should the new system solve and who are the stakeholders of this new system. If the new
system is created to manage sourcing contracts, then main stakeholders are the employees in
sourcing as well as the suppliers from whom the sourcing is buying from (also other
functions might be involved, e.g. legal department). Another important part to understand
from the domain is to understand the current IT architecture of the company and how are
things done at the moment. Knowing this so called “as-is” situation enables the requirements
engineer to understand the root of the requirements and it also is vital part to be able to
analyze the requirements later on.
In practice, the schedule and budget have significant effect on a software development
projects and the way in which it is performed (Zowghi and Coulin 2005, Lech 2012).
Schedule and budget also set limitations to the scale and techniques how requirements
engineering can be conducted. In large enterprises it does not make sense to elicit
requirements from every potential user, but instead include a set of users from each different
user group to the requirements elicitation (Winter and Strauch 2004)
Collecting requirements as statements of what the system should do is considered too
simplistic in practice and it is advised that requirements should rather be statements of how
the system should do it (Kotonya and Sommerville 1998). If it is only known what the system
17
Theory Part
should do, it can be implemented in many ways. The requirement will be fulfilled as it was
recorded but the end-user might not be happy with the result: the system is able to do the
required task but it has become more difficult than it was previously. It is needless to say
what kind of impact this will have on the user satisfaction and system acceptance. EXPLAIN
HOW TAKEN INTO CONSIDERATION.
Requirements and design are intertwined activities and should not and cannot be viewed in
separation (Kotonya and Sommerville 1998, 10). Reasons behind this are that there are other
systems in the existing environment that the new system has to communicate with. These
existing systems create constraints to the design of the new system and therefore have to be
considered as important requirements. The system environment may also have existing
functionalities and services that can solve some of the user requirements, when used together
with the new system, so these functionalities do not have to be created again into the new
system. These available functionalities and their synergies have to be also considered when
the requirements are being analyzed and the system design is being drafted.
User participation in requirements engineering process is widely recommended by those
concerned with socio-technical design (Macaulay 1996). The users are usually the
stakeholders who have the best knowledge what is important quality of the system and what
is not. It is important to remember that different user groups will likely have different kind of
views and requirements. The ability of users to participate effectively is determined by the
structure of the requirements engineering process and by suitable elicitation techniques for
allowing their views to be incorporated. Most participatory techniques are interviews and
interactive workshops.
Understanding the users, their needs and how they operate in the context of the new proposed
system and as part of a wider organisational setting, can greatly increase the likelihood of
successful projects particularly in terms of user-acceptance and increased accuracy
(Coughlan and Macredie 2002). The degree of understanding, however, depends on how well
are the requirements communicated between the users and the requirements engineers.
Coughlan and Macredie (2002) state that based on their findings user-involved approaches
entail richer, and often better, results of requirements engineering.
Jiang et al. (2005) highlight the importance of understanding the suitable techniques for
requirements engineering for a given project to enhance the quality of the requirements,
which, in turn, will result in higher customer satisfaction and improved efficiency of the
18
Theory Part
requirement engineering process. The most used requirement elicitation techniques are
presented in the chapter 3.1.3. The interview requirements elicitation method used in this
case study was based on best suitability practice.
To be able to manage a set of requirements, the individual statements from stakeholders need
to be identified, classified and traced (Hull et al. 2011, 77). This means creating requirements
documentation where the requirement and its nature, as well as the original source of the
requirement, become clear. Requirement documentation is used to communicate the
requirements between stakeholders in the system development project. Requirements should
be recorded so that they can be understood by also other people than just the original
requirements
engineer
that
elicited
them.
Otherwise
miscommunication
and
misunderstanding can happen which cause unsatisfactory end results.
3.1.1
Functional and non-functional requirements
Requirements are often divided into different categories. The two main categories are
functional and non-functional requirements which can have sub-categories under them
(Sommerville and Sawyer 1997; Kotonya and Sommerville 1998; Tsadimas et al. 2009).
Functional requirements describe a certain process that the system has to be capable of: a safe
authentication of the user, as an example. Non-functional requirement describes how the
system should do it. If following the previous example of authentication, that the
authentication has to be done using the same user access rights as the existing IT systems of
the company.
Robertson and Robertson (2006) characterize non-functional requirements to be properties
such as usability, security, and legal restrictions. In turn, Kotonya and Sommerville (1998,
187) characterize non-functional requirements as “the overall qualities or attributes of the
resulting system”. Tsadimas et al. (2009) suggest performance, constraint and specific
quality as sub-categories for non-functional requirements. The distinction between the two
requirement categories (functional and non-functional) can sometimes be blurred and a
requirement could belong to both the functional and non-functional categories (Sommerville
and Sawyer 1997, 8).
Non-functional requirements are often of such critical importance that, in case of conflict,
they trump over of some functional requirements which then have to be sacrificed (Kotonya
and Sommerville 1998, 187). Example of such critical non-functional requirement could be
19
Theory Part
reliability. If the system is unavailable often or loses stored information, it is of no matter
how many functions it has. Robertson and Robertson (2006) write that non-functional
requirements usually derive from the functional requirements. Once a functionality
requirement emerges then also emerges the non-functional requirement of how this
functionality should be executed.
3.1.2
Requirements elicitation
Currently in requirements engineering research and practice, there is very little uniformity of
standard definition of requirements elicitation (Zowghi and Coulin 2005). It is most
commonly understood as a process of learning, uncovering, surfacing and discovering the
needs of users (Somerville and Savyer 1997; Kotonya and Sommerville 1998; Hickey and
Davis 2003). Even though the definitions may vary a little the core idea of elicitation remains
the same: discovering the needs of the users and documenting it down for further analysis.
What makes the elicitation of requirements difficult from the end-users, is that they rarely
have a clear idea of what their actual requirements are or should be (Kotonya and
Sommerville 1998, 54). Different parts of the organization may have conflicting requirements
that creates a trade-off situation. In addition, very likely technical and budget limitations exist
that prevent the fulfilment of all the user requirements. Nevertheless, all of the requirements
should be discovered and recorded in the elicitation phase. Only after the elicitation can
analysis start on whether the requirements are feasible or not. Though, especially in open
interviews, elicitation and analysis are very connected activities as during the discussions
some analysis is inevitably carried out (Kotonya and Sommerville 1998, 57).
Often the requirements engineering involves typical aspects of project management (Zwoghi
and Coulin 2005). Requirements engineers do not only have to manage the process of
elicitation, but they also have to communicate it effectively to the stakeholders related to the
system development project. This involves prioritization, negotiation, and decision-making,
among other things. When eliciting requirements in group work sessions, requirement
engineers are responsible for asking questions and recording the answers but also for guiding
and assisting the participants in addressing all the relevant issues in order to obtain correct
and complete requirements information (Zwoghi and Coulin 2005). It is also important that
the participants feel comfortable and confident with the process so that they actually
contribute to the requirements of the new system.
20
Theory Part
In reality the completion of requirements elicitation is often determined by time and cost
constraints rather than achieving a high level of requirements quality and completeness.
Typically the result of this process is a detailed set of requirements in written text and simple
representations of the requirements in diagrams or tables with additional information
including descriptions of the sources, priorities, and rationales (Zwoghi and Coulin 2005).
The Process of Requirements Elicitation according to Zwoghi and Coulin (2005):
(1) Understanding the application domain
Understanding the world where the completed system will eventually reside. What
also has to be understood is the current state and any possible constraints for the
future system that may be caused by the organizational, social, or technical
environment.
(2) Identifying the sources of requirements
Stakeholders are the most obvious source of requirements information for a system
but there can be also other sources. Users and subject matter experts are usually the
people with the most detailed information about current problems. Current and old
systems can also be used to gather requirements and learnings for the new system.
(3) Analysing the stakeholders
For different projects there can be different stakeholders. It can be the customer, the
project sponsor, or the user. It is important to analyse who are the most important
stakeholders in the particular project. If partners or people involved with work process
standards are affected, they should be included as stakeholders, too.
(4) Selecting the techniques, approaches, and tools to use
It is generally accepted that an individual requirements elicitation approach cannot be
suitable for all projects. In most cases, several requirement elicitation methods are
employed during and at different stages in the software development lifecycle and
often in cooperation, where complementary.
(5) Eliciting the requirements from stakeholders and other sources
When stakeholders and sources of requirements information have been identified and
analyzed, the elicitation of requirement can begin with the selected techniques,
21
Theory Part
approaches and tools. At this stage it is important to establish the scope of the system
that is being developed. The needs and requirements are to be collected and
investigated in detail from the stakeholders, especially the users. It is also important to
determine how the new system will affect business operations and how it can also
support major business goals and address its key problems.
Zwoghi and Coulin’s model emphasizes understanding. The requirements engineers need to
understand the application domain, understand who the actual stakeholders of the system are
and what other sources of requirements there might be. Only once these first three steps are
analyzed and understood, can appropriate elicitation technique be selected and the elicitation
may begin.
There is also another model that is keen on the understanding of the domain and the business
goals the system is set to achieve. It is a model by Kotonya and Sommerville (1998, 54) that
presents four dimensions of requirements elicitation. Similarities between these two models
can be seen and the more recent Zwoghi and Coulin’s (2005) model could be considered as
an advanced and developed version of the Kotonya and Sommerville (1998) model.
Requirements Elicitation Dimensions by Kotonya and Sommerville (1998):
1) Application domain understanding
Knowledge of the field where the new system will be applied to. In this case study
this would mean understanding of the elevator and escalator construction project
process and the related documentation.
2) Problem understanding
Understanding what is the problem that the new system is trying to solve. In this case
study this would mean understanding the underlying problems in the existing
document management systems and why they exist.
3) Business understanding
Ability to understand different parts of the business that the new system is connected
to, how does the new system interacts with them, and how can the new system
contribute to the overall business goals.
4) Understanding the needs and constraints of system stakeholders
22
Theory Part
There can be various stakeholders that have different needs. Understanding how the
system affects their work and work processes, also in detail level, is crucial.
Kotonya and Sommerville’s dimensions are all about understanding. They state that methods
and techniques do have their place in the elicitation process, but what is the real key to
success and always has to supplement the methods and techniques, is the general
understanding of the problem domain and system stakeholders. Not having established
business objectives and goals for the system development project will result in significant
problems in the analysis phase (Kotonya and Sommerville 1998). The existence of business
objectives and goals is paramount to be able to reflect them against the requirements and to
be able to prioritise the requirements.
This same emphasis of domain and stakeholder understanding was also present in Zowghi
and Coulin’s (2005) five-step process of requirements elicitation. The small difference is that
Zwoghi and Coulin determine the domain knowledge and understanding to be part of
elicitation process, whereas Kotonya and Sommerville (1998) regard it as a separate
prerequisite step that should take place before elicitation (see Figure 1: Requirements
engineering process).
The type and purpose of the developed system significantly affect the way in which
requirements elicitation is conducted (Zowghi and Coulin 2005). For example, it can be said
that the method used for a custom built system for a single company is likely to be
substantially different to that of a commercially available off-the-shelf system that tries to
attract many companies.
3.1.3 Requirement elicitation techniques
Requirements elicitation is intensely communicative activity that involves diverse range of
people with different backgrounds, skills, and knowledge (Coughlan and Macredie 2002). As
in any communication, one has to consider different cultures, languages, and semantic
differences in requirements elicitation in order to engage in meaningful dialogue that creates
valid and valuable set of requirements (Zowghi and Coulin 2005). To perform this interactive
task there exist various techniques. Presented here are the most popular of these techniques,
of which one, interview, have been used to collect the empirical data for this thesis. In each
requirement engineering project the used elicitation technique should be justified. One way of
justifying is a technique selection model.
23
Theory Part
Hickey and Davis (2003) provide one of the most comprehensive ones. They have created a
visual model of elicitation technique selection. This model is presented below.
Figure 2: Model for requirements elicitation technique selection (Hickey and Davis 2003)
In Hickey and Davis’ (2003) model the correct technique to apply in a given situation must
be a function of what requirements are already known and what requirements still need to be
known. Different techniques can be good at uncovering different kinds of requirements. The
model of Hickey and Davis’ uses project and problem domains as the starting points of
technique selection. To this domain understanding is added the already known requirements,
because some requirements are often already known before the actual elicitation process
begins. With these aspects known, can the elicitation technique be selected and the elicitation
from user, customers, and other stakeholders may begin. According to Hickey and Davis the
elicitation technique should change during the elicitation process if the characteristics of the
domain or the system change.
Based on the experiences of Hickey and Davis (2003) requirements engineers select a
particular elicitation technique for any combination of the following four reasons: (1) It is the
only technique that the engineer knows, (2) it is the engineer’s favorite technique for all
situations, (3) the engineer is following some explicit methodology, and that methodology
prescribes a particular technique at the current time, and (4) the engineer understands
intuitively that the technique is effective in the current circumstance. Hickey and Davis note
that the fourth reason leads to higher understanding of the needs and therefore a higher
24
Theory Part
likelihood of a successful system, and should therefore be the core reason for choosing an
elicitation technique.
The requirements elicitation from the users is usually achieved through the use of interviews,
questionnaires or by observation (Macaulay 1996). Interviews are the most commonly used
technique and it should be part of all requirements elicitation processes (Kotonya and
Sommerville 1998, 63). In interview technique the requirements engineer discusses with the
stakeholders to discover and understand the requirements. Asprey and Middleton (2003, 5)
feel that no other technique can ever replace the effectiveness of face-to-face discussions
between the requirements engineer and the stakeholder. Also Davis et al. (2006) have come
to the conclusion that interviews appear to be the most effective elicitation technique in a
wide range of domains and situations. Due to the nature of the requirements engineering task
at the case company and the aforementioned recommendations from requirements
engineering research, interview method has been the technique of choice in this study.
“Interviews, preferentially structured, appear to be one of the most effective elicitation
techniques in a wide range of domains and situations.”
For interview technique to be effective it requires the knowledge of application domain from
the requirements engineer. Otherwise the requirements can be misunderstood or falsely
recorded, and this will create difficulties in the analysis phase. Application domain often
includes terminology that is required to be familiar with to understand the stakeholder’s
requests and challenges. Not knowing the terminology used can also cause hurt the
confidence the interviewees have in the process as well as waste the allocated time.
In elicitation discussions the stakeholders usually share gladly information about their work
and are excited to have a say in the future of their work (Kotonya and Sommerville 1998, 63).
Requirements elicitation can reveal best practices within a company that are not in wide use.
These best practices discovered by someone in their daily work can be implemented into the
new system and made available for all the employees in the company.
3.1.4
Requirements analysis
Once the requirements have been elicited and collected comes the requirements analysis.
Important part of the requirements analysis is to recognise interactions between requirements
and to notice possible conflicts that they create. Creating a map or a matrix of the interactions
can help in identifying conflicts or overlaps in the system architecture (Kotonya and
25
Theory Part
Sommerville 1998, 79). With a large number of requirements, the interaction map or matrix
can become very difficult to comprehend. Kotonya and Sommerville (1998, 80) suggest an
upper limit of 200 requirements for using a requirements matrix.
In this thesis though, the requirement interaction matrix is not used, even the amount of
elicited requirements would be appropriate (57 requirements). The matrix would provide too
unclear results due to the requirements being very variable in their character: one wants an
easy-to-use interface, while other demands a certain particular functionality. There could
exist a conflict between the two, but it would be hard to know just from looking at these two
requirements.
Prioritisation is a vital when requirements are analyzed. Only with prioritisation we are able
to solve possible trade-off situations and to focus limited resources to the right place.
Conflicts in priorities of different stakeholders will inevitably arise (Kotonya and
Sommerville 1998, 80) which means that compromises have to be found. The business
requirements should always come first, but budget and time constraints may limit which of
the requirements can be validated for the final system and which cannot. Reliability, security,
and usability of the new system could also conflict with some of the requirements, in which
case the greater good has to win. What makes everything difficult is that the greater good can
be very subjective.
According to Winter and Strauch (2004) the requirements analysis for data warehouse
systems significantly differs from the requirements analysis for conventional information
systems. EDM system is much more like a data warehouse system than a conventional IT
system. Winter and Strauch’s (2004) findings are, based on their interviews with project
managers and information systems managers, that a methodological support for data
warehouse system requirement analysis is required. They built a method engineering
approach to that combines user activities, user roles and responsibilities, document creation
tools, information models in use, and document types to offer this methodological support to
data warehouse requirements analysis. This means that all the aforementioned aspects are to
be observed when analyzing the requirements.
The method engineering approach of Winter and Strauch (2004) gives a good panorama view
to the requirements. It takes into consideration the different user roles and activities they
would perform with the new system, the current existing tools that create documents, how
information flows and should flow inside the company, and what kind of document types are
26
Theory Part
there. The data warehouse system cannot be built only from the user role point-of-view or
only from the documentation tool point-of-view. This panoramic mindset has been the basis
of requirement analysis conducted in this thesis.
3.2 Electronic Document Management theory
Electronic Document Management (EDM) is often considered as a part of Electronic Content
Management (ECM). ECM is responsible for all the digital content of the company such as
websites, intranets, portals, videos, pictures, data warehouses, and so on. This thesis focuses
on the EDM theory but also ECM theories could be applied to document management. ECM
theories are not discussed in this thesis due to their too general nature to the specific subject
of electronic document management in installation projects.
3.2.1
Structure of EDM systems
There are generally two ways of managing electronic documentation: hierarchical tree or
metadata structure (Hjelt and Björk 2006). Hierarchical tree structure means folders inside
folders, which spread out like a tree. In Figure 3 is shown an example of a traditional
hierarchical tree structure. It is the traditional structure how files are organized on personal
computers. Metadata structure means that the documentation is stored in one or many
repositories and the documents are presented to the user based on metadata attributes entered.
This requires the user to know what kind of file he or she is looking for, but the user does not
have to know if which file path or actual folder it has been stored in.
27
Theory Part
Figure 3: Example of a hierarchical tree structure
The strict hierarchical structure of folders can map poorly to user needs. The use of the
document’s location as a fundamental organizing principle forces the users to know how to
categorize each document and the other users to understand this categorization when
retrieving the documents. Studies of document management practices suggest that this kind
of structure interferes with user needs (Dourish et al. 2000). A hierarchical organization of
documents that makes sense to one person might not reflect the how another relevant person
would group them or think about them (Dourish et al. 2000).
The other structural option is metadata based structure. There documents are identified based
on metadata that is tagged to the document. The document itself may reside in any physical
location with a network connection and it is retrieved based on metadata search. User enters
metadata attributes, such as document type and date of creation, and the system shows
documents with matching attributes. Hawking et al. (2000) state that document retrieval from
digital repositories is best served by metadata and content searching. Sumalatha et al. (2013)
consider metadata search as one of the main components of cloud-based entities. Metadata
helps the machines to understand the meaning of the content that enables also more
sophisticated exploitation of the documents and their content, such as Big Data applications
and analysis.
28
Theory Part
The problem with metadata is that it takes time to give the documents metadata attributes.
The problem of manual metadata entries has also been noted in EDM research before. Hjelt
and Björk (2006, 116) mention that many users dislike having to fill in metadata forms
despite the obvious advantages it would bring for the later users wanting to retrieve
documents. Therefore users often like the hierarchical structure over the metadata structure.
Hjelt and Björk (2006, 116) see that one way to avoid the problem of filling metadata could
be solved by automating the metadata creation somehow.
There can also exist a hybrid version of hierarchical and metadata structure. In a hybrid
model there exists a hierarchical structure that the users can navigate to find their files but the
users can also choose to search the files based on metadata if they find it more convenient.
This structure is able to bring the best of both worlds, but can be more complex and
expensive to implement.
Figure 4: Overview of typical EDM system using metadata (Weers and Vrancken 2010)
Still, in 2010, EDM systems were immature for document management due to lack of predefined management structures, even though EDM systems were considered as interesting
option for improving document retrieval through a web-based central repository (Weers and
Vrancken 2010). The lack of pre-defined management structure means that too often
documents are just dumped into a repository: no retention periods are set for the documents,
no proper metadata management exists, and it is up to the users to make order to the chaos.
29
Theory Part
EDM system should be web-based and used as the primary channel for document storage to
avoid the scattering of project documents (Weers and Vrancken 2010). The system should
also take into account system and document security. This means managing user access rights
and preventing unauthorized access and confidentiality breaches. The document management
structure should be simple to make the EDM system easier to learn and use as well as to
reduce the change resistance from the users (Weers and Vrancken 2010).
3.2.2
Functionalities of Electronic Document Management Systems
Traditional functionalities of an EDM system include the following (Asprey and Middleton
2003, 92):

Search and retrieval

Viewing

Version control

Metadata management

Archives and disposal

Document security

Interfaces with other systems

Classification
Often the primary motivator for acquiring an EDM system is to reduce the time that user
spends in locating and retrieving documents (Asprey and Middleton 2003, 98). The EDM
search capabilities should be intuitive and easy-to-use for the users. User friendliness can be
achieved by integrating shortcuts to other applications to access the documents from EDM
system. Asprey and Middleton (2003, 98) list that the users should be able to search
documents based on metadata attributes, on combinations of these attributes, on text in the
documents, and the combination of metadata and text in the documents.
Version control means, that when an electronic document has been edited and the new
version uploaded, the system tracks what is the newest version and does not destroy the
original document. Version numbers are used to make distinction between different versions
of the same document and it is possible to retrieve an older version in case it is needed. By
default the system should only show the most recent version of the document to the users to
avoid confusion.
30
Theory Part
Metadata and its management is one of the most crucial parts of any EDM architecture today.
The individual metadata requirements in organizations vary (Asprey and Middleton 2003, 95)
so each organization has to define their metadata attributes based on their needs. What is
common is that the metadata should be populated to the documents automatically to ensure
effective and accurate metadata information (Asprey and Middleton 2003, 95). This
automatic metadata can be populated from the existing registers and systems of the
organization. Manually entering metadata to documents is a humongous task and has much
room for human error. One erroneously entered character in metadata may link the document
to totally different project on the other side of the world.
Document security is an EDM area with several aspects to it. Access rights management is
one of them. It controls who are able to view, edit, and administrate the documents. This can
be done on an individual user level or by grouping the users together into access right groups.
The user right groups can be based on the existing roles inside the organization, so that
installers have a preset access rights template based on their needs, managers have their own
preset template, administrators theirs, and so on. Another aspect of security is to ensure that
the access and authorization is monitored. This is traditionally done with username and
password. Access and authorization monitoring also means, that once the user leaves the
company they are no longer able to access the system. More developed safety measures
include the detecting possible fraudulent activities, such as users downloading exceptional
amounts of documents or deleting information from the system. These can be set to trigger an
alarm to the administrators that can then take action if needed.
Archiving of documents is needed to prevent loss of information, making retrieval of active
files easier, and to comply with laws and regulations. When a document or a set of
documents is archived it is often given a retention period of how long should it be kept stored.
(Asprey and Middleton 2003, 100). Archival of documents can be done manually, set to
happen after a certain time period the document has remained inactive or from a predefined
trigger in the workflow. An EDM system provides means for managing records in line with
retention guidelines and ensures that correct documents are saved and documents due for
destruction are deleted (Johnston and Bowen 2005). Deleting obsolete documents saves
storage space and makes finding valuable documents easier.
A lot of the functionalities of EDM system are going on in the background and not visible to
the typical user. The functionality and touchpoint to the user is the interface, which should be
31
Theory Part
intuitive for both casual and power users (Asprey and Middleton 2003, 132). The general aim
with interfaces with other systems should be that the users are able to access the EDM system
from their common office applications, such as word processor, spreadsheet, and email
(Asprey and Middleton 2003, 92). This will eliminate the step of first saving the document
locally and then storing it to EDM. This is one part of system integrations in EDM
architecture that improve the usability of the system. Integrated user interface exists in most
out-of-the-box EDM solutions (e.g. Microsoft, M-Files, IBM, and EMC).
3.2.3
Benefits of Electronic Document Management
Document management is a support function for most companies, but it is one that can
greatly impact the performance of the company. It affects the performance of a company in
three ways (Sprague 1995):
1) Improved communication. Major value comes from EDM’s capability of efficiently
capture, store, and communicate information in the form of documents. The benefits
increase with the size, heterogeneity, and geographical distribution of the company.
2) Upgraded business process. The transformation from paper to electronic allows the
companies to upgrade their business processes that were previously tied to the flow of
the physical paper document. Shared electronic documents can be accessed by
everyone at the very moment the document is shared. With the EDM capabilities of
21st century, it is possible to re-engineer the business processes ever further. Such
enabling capabilities could be simultaneous editing of a document or modular
document creation.
3) Leveraging organizational memory. For a small group of people documents serve
as a reference and way of communicating information, but organisations can leverage
the mass of information that is being stored in their databases. When documents are
stored in EDM system they can be accessed and analyzed to improve performance
and to create business value. Especially Big Data tools can give companies new kind
of possibilities to analyse their performance and the market development and create
added value to customers. Finding the hidden patterns from documents is impossible
without a central repository.
The improved communication is ubiquitous but hard to quantify. It can be improvements in
the quality of the communication (accuracy and reliability), in the effectiveness of the
32
Theory Part
communication (speed and coherency), and in the reach of the communication (accessibility
and visibility). The upgraded business process and leveraging of organizational memory
benefits are possible because of the electronic document format that turns the information to
the language of computers. These two latter performance improvements depend significantly
on how well the EDM system is embedded in to the business processes and core systems of
the enterprise. The more heterogenic and dispersed the enterprise is, the greater the benefits
will be compared to plain and local document management practices (Sprague 1995).
Johnston and Bowen (2005) approach the benefits of EDM from a different angle and define
benefactor groups for an EDM system. Benefactors are divided to three groups: individual
users, the organization, and the society as a whole. Society as a whole means all the
individuals within the company and in the boundaries of the company (customers, suppliers,
partners) as well as the company itself as an organization.
Benefits of an EDM system according to Johnston and Bowen (2005):
1) Individual user benefits:

Information available when required

Better quality, efficiency, and effectiveness of work

Less blame and dissention when looking for lost information

Evidence available of what has been asked to do and what has been done
2) Organizational benefits:

Work is done more quickly

Completing tasks requires less effort

Quality of processes and their outcomes is improved

Cash flow is improved

Better compliance with laws and regulations
3) Benefits for the society as a whole:

Organizational processes are transparent and can be better understood and
monitored
33
Theory Part

Organization complies with laws and regulations

Quality of life is improved

Historical records are accessible and reliable
When thinking about the benefits and the effect an EDM system can have on the company, it
is important to remember that the benefits of a new system depend on the starting point. The
benefits will be of totally different magnitude if the company does not have any existing
document management architecture or if the company is upgrading to a new system from an
existing one.
3.3 Empirical results from literature
In the previous chapter 3.2.3 the benefits mentioned were all qualitative and did not provide
any insight to the scale of these benefits to a company. In this chapter is represented some of
the quantitative benefits and results that have been achieved with EDM system. The results
and numbers presented here are based on previously published case studies and reports from
companies.
Most of the reported figures of EDM or ECM system implementations are from public
organizations that more openly report their investments. Johnston and Bowen (2005) have
collected data of EDM implementations in these kind of organizations. One of these was
Orange County, California, who report savings over $1,000,000 per annum from their
enterprise content management system implementation, with additional savings of floor space
(over 800 square meters) due to physical documents transformed to electronic (Johnston and
Bowen 2005). They also report improved satisfaction among their customers. The cost of the
project was not reported but it is likely to have been around $650,000 (an estimation of
Johnston and Bowen, 2005).
Another reported result is from Transport Canada, who reported a 86 per cent return on their
EDM investment with a 1.17 year payback time (Johnston and Bowen 2005). Their EDM
project lasted over three years and involved 5 200 end-users. These numbers give the ballpark
figures of how long might EDM project take in larger enterprises.
Johnston and Bowen (2005) report one case study where the remote access to records by the
employees had a significant benefit to the company. Salford City Council implemented a
34
Theory Part
system where records were accessible outside the office, which provided several tangible and
intangible benefits. There was a 15-20 per cent improvement in productivity in Council’s Tax
and Benefits processing and a 48 percent improvement of productivity in Overpayments.
Salford City Council also recognized significant improvements in staff satisfaction and
motivation, with an overwhelming 75 per cent reduction in absence due to sickness. Though,
the relation of sick leaves to better document management can be debatable.
Johnston and Bowen (2005) remind that these kinds of benefits from EDM projects are not
assured. They depend on well planned and executed implementation. They also depend on
attention being paid to the human aspects of the EDM systems: user acceptance, user training,
and on-going user support. These need to be in place to achieve real benefits.
Maguire (2005) studied the implementation of EDM system in the Estates Department of the
British Library. The Estates Department had new requirements for finding and sharing
information quickly and therefore needed to update their EDM architecture. A supplier was
selected and the British Library department worked together with them to develop a system
that would fit the scope and needs. During the implementation, the management decided
upon business rules that would “nudge people into the right behaviours” (Maguire 2005, 153)
in case it would not naturally happen. These consisted of email filing policies on how to file
email attachments and email chains, and having the files stored with correct author
information and a standardized timestamp (dd/mm/yyyy).
Two years after the implementation only one third of the potential users was using the EDM
system. From a staff survey the pain points were discovered: (1) Filing of email documents. It
was difficult to know on whose responsibility it was to file the email if many had received it
or if the email was to be filed at all. (2) Filing. 10% complained that the filing was too timeconsuming. Some also complained that it was hard to know in which folder to file the
document. (3) Folder structure. It was difficult to see the big picture of the folder structure.
Also there was disagreement on the folder naming principles. (4) IT-related. Some found the
system hard to use on a laptop. (5) Searching. Staff had trouble finding even their own
records afterwards. (6) Many of the staff found the interface unintuitive and hard to use. (7)
Working practices. Staff would have wanted more guidance on what to store in the system.
People did not want to store everything as they knew it was unnecessary and would only
waste their time.
35
Theory Part
Based on the survey’s findings Maguire (2005) concludes the following from the EDMS
implementation at the British Library:
1) Choose a user-friendly system that is as easy to use as possible. The system should do
automatically as much of the procedures as possible (e.g. creating the timestamps)
and users should not have to understand the mechanics behind the user interface.
2) Focus on good document management behavior first. No system can change the
policies, attitudes, and ways of working of the staff. This can only be done by
promoting the right principles of document management and embedding them into the
corporate culture. Sorting out what is required from the system first would have
helped to get more out of the system instead of being led by it.
3) There cannot be too much training. When people were facing difficulties with the
system and stopped using it, they should been offered refresher training. There was
only the initial training available during the launch of the system.
The main lesson of the study is to put most weight on the user-friendliness of the system and
to the training of the users. Classifying clearly what is to be stored and where will elevate the
user experience. It does not matter how good the system otherwise is, if no one is willing to
use it. O’Brien (2000, 35) puts it quite well by saying that skeptics will always find a way to
avoid using the tool.
Managing user expectations is important to avoid big disappointments or even the whole
rejection of the system. This was one of the key lessons that Winter and Strauch (2004)
learned in their study of the UBS bank in Switzerland. Acceptance and satisfaction with the
system is likely to vary depending on the stakeholder group. As stakeholders have different
requirements, they also have different expectations of the final system. In their EDM system
projects, companies have found out that the central challenges in the introduction of these
systems are behavioral rather than technical (Björk 2006).
Another list of recommendations can be found in the research done by Alberto et al. (2009)
on CReED (Compiling Remote Electronic Documents) document management architecture.
Alberto et al. arrived to the following conclusions on the properties of a good Electronic
Document Management System (EDMS):
36
Theory Part
1) Security needs to be firmly integrated to the system. There needs to be different levels
of access permissions that enable secure possibilities for viewing, uploading, and
editing the documents.
2) EDMS solution should provide at least three possibilities for searching documents.
These three are i) visual search by folder location, ii) search by index fields describing
the document (i.e. metadata), and iii) search by word or phrase in the documents.
3) Reliable storage that allows easy retrieval of documents. EDMS should support both
scanning of paper documents and uploading of electronic files. The system should
also support log history for archiving purposes.
4) The document management system needs to store the records and documents in an
electronic format in a central repository. This electronic repository should support
active, inactive, and obsolete documents.
Lack of policies, procedures, guidelines, and training may lead to a culture where the EDM
system is used as a dumping ground of documents (Johnston and Bowen 2005). With clear
policies and guidelines combined with appropriate training the EDM system can perform as it
is meant to and the user experience and satisfaction will be higher. The EDM system is a tool
that helps the users and it can include some enforced restrictions so that the users cannot use
it any way the like, but as the system also has to have some flexibility due to the vast amount
of different documents and projects, there is responsibility also in the users to use the system
correctly.
The costs of EDM implementation can vary a lot depending on the complexity of the system.
If readily available out-of-the-box application matches the company needs it will obviously
be significantly less expensive than a custom-built application or than an out-of-the-box
application with custom-built elements. Björk and Hjelt (2003, 113) report, that EDM has
often been achieved with very low investment since the emergence of commercial cloud
storage providers. This is encouraging news for companies pondering whether they are
willing to invest in good document management.
3.3.1
Previous studies of EDM systems in construction industry
In construction industry the use of ICT systems have remained low compared to other
industries all the way to present years (Hjelt and Björk 2003, 113). The cause for this has
been weak IT skills, scattered project information from various channels, poor
37
Theory Part
interoperability between different IT systems, and the worries of confidentiality and
unauthorized access (Weers and Vrancken 2010). Despite of the low ICT penetration in the
industry as a whole, the large players have been using more developed ICT systems already
for a while and EDM has been the fastest growing application in the industry (Hjelt and
Björk 2006, 113).
Gabrielaitis and Bausys (2009) have studied construction industry and the document
management practices characteristic for construction projects. They observe the following to
be typical characteristics in construction project documentation:
1) Large amount of documentation is generated.
2) Information flows are numerous, unstructured and complex.
3) Project teams cannot perform effectively without adequate, accurate and timely flow
of information.
Gabrielaitis and Bausys (2009) state, that due to these facts, effective document management
can significantly reduce costs and improve the quality of the construction projects.
The research conducted by Weers and Vrancken (2010) in urban development projects
recommends the adaptation of a web-based centrally available document management system
to manage project documentation. This system should be kept simple to lower the barriers of
user-acceptance while ensuring the security of the system and the confidentiality of the
information within. When documents are stored, they should be given proper attributes
(Weers and Vrancken 2010). These attributes, also known as metadata, can then be used to
retrieve the documents and to browse the content in the system.
An EDM system should be used as widely as possible inside the company and in its
interfaces to maximize the benefits of improved communication (Bäckblom et al. 2003).
Bäckblom et al. (2003) underline, that any communication by-passing the EDM system will
diminish the effect and the benefits of the system. Therefore the use rate of the system in
projects is important and it can be measured to find out how well the system collects project
documents and communication. Weers and Vrancken (2010) also identify the use rate and
coverage of the EDM system as a key factor in the effectiveness of the system. They say that
the use of different channels for sharing documents scatters the project information and limits
the effectiveness of the ICT systems.
38
Theory Part
3.4 Intellectual history of the research
In this chapter is presented the history of requirement engineering research and EDM
research. Requirements engineering is an older field of research and it applies to many other
kind of system development than just EDM systems. EDM research is more focused field of
study that applies well to the research conducted in this study. It is also a field that has seen
more developments recently and has less standardized models and practices.
3.4.1
History of Requirement Engineering research
Computer-based systems were first implemented in the 1960s. The challenges and problems
of system requirements have been present since (Kotonya and Sommerville 1998, 3). In the
beginning of 1990s requirements engineering was starting to get recognition as its own
professional discipline (Mead 2013). Ever since the 1980s requirements engineering has been
used in the development of software as a standard practice. In 1993 IEEE (Institute of
Electrical and Electronics Engineers) launched the first symposiums for requirements
engineering. The Requirements Engineering Journal was established in 1996.
Since 1980s much of the research and practice within requirements engineering for software
systems has been focused on improving the complex process of elicitation. This has been
through the application and development of various techniques, approaches, and tools. The
data-flow model, based on visualizing the data interactions the system has with other
activities inside or outside the company, was one of the first models created and is still in use
(Kotonya and Sommerville 1998, 142).
Requirements engineering research and methods continue to develop. The waterfall model of
requirements engineering has received alternatives from spiral and agile models. In
requirement elicitation it is generally accepted that one model or technique cannot possibly
be suitable for all projects (Zwoghi and Coulin 2005). Many of the newer requirements
engineering methods have been borrowed and adapted from other disciplines such as the
social sciences.
The sociological aspects of requirements elicitation have been noticed by Macaulay (1996).
Macaulay has applied Eason’s (1989) work into requirements engineering and in choosing
elicitation techniques. The sociological aspects and their importance are noticed also by many
other researchers such as Weers and Vrancken (2010) and Hickey and Davis (2003).
39
Theory Part
3.4.2
History of Electronic Document Management research
Electronic Content Management (ECM) and Electronic Document Management (EDM)
research and disciplines have emerged together with electronic documents. Before that
documents were distributed inside the office in paper. The grown availability of computers
and the introduction and popularity of the software that created documents (first mainly text
documents from word processing software) in the 1970s slowly began the avalanche of
electronic documents in companies of every discipline.
In 1990s it became evident that these new mass of electronic documents and the digital
information inside the documents would require the companies to rethink their systems and
how they manage the content in them. An introductory to the subject was published in MIS
Quarterly by Ralph Sprague in 1995: “Electronic Document Management: Challenges and
Opportunities for Information Systems Managers”. It gives the readers, and companies alike,
an idea how the electronic documentation could be managed in a meaningful way introducing
the concept and business value of EDM. Previously, companies’ documents had been
managed to some degree but this happened mostly on paper or on personal level in electronic
format.
Traditionally, since the introduction of hard drives, documents were managed using
hierarchical structure. Around the turn of the last millennium, the EDM research shifted away
from the dominant hierarchical file structure and began studying what can be called
“placeless environment” or “placeless documents” (Dourish et al. 2000). In this placeless
environment documents would be identified based on metadata attributes tied to the
documents instead of the location of the document. Internet had enabled new ways to
collaborate and this also affected document management. The hierarchical trees that had been
logical and useful on personal computers did not meet the new needs of cloud storage and
document sharing.
Bo-Christer Björk has done multiple studies (Bäckblom et al. 2003, Björk 2006, Hjelt and
Björk 2006) on EDM, especially in the Nordic construction industry. He has studied the
development of the document management and the adaption of the EDM systems in the early
2000s. His findings have been that large companies and projects are using EDM systems
quite well but smaller companies and new users are struggling with them. Once the users
have become familiar with using EDM they could find it “difficult to go back to earlier more
primitive methods of document delivery and retrieval” (Björk 2006, 654).
40
Theory Part
O'Brien (2000) has researched the implementation and use of EDMS in different companies.
He has noticed the sociological aspects to be of great importance (instead of just traditional
technical thinking) in EDMS implementation. The importance of involving the actual users of
the system and listening to the needs and requests of them, has been supported by Björk
(2006) and by Maguire (2005). This sociological research of user acceptance and its findings
are very interesting and also critical for the success of EDMS. This sociological research of
EDMS is very similar to the sociological research results of requirement elicitation studies
(Macaulay 1996).
Different models for document management have been built and studied to find out what
could be the best approach. Pan and Anumba (2008) have developed a semantic-discovery
model for managing project documents. The semantic-discovery method the project files
have relations and connections to other files that are related to the same project or subject.
There can be metafiles which have several files under it and these sub-files will be presented
to the users when the metafile is searched. This can be very helpful to access information
across different repositories, but it also requires an existing communication link between
these repositories. The bottom layer for semantic-discovery is XML (extensible markup
language) which has RDF (resource definition framework) and logical rules on top of it to
enable the creation of the relations between the files.
As organizations continue to develop their documentation practices and systems, there
continues to be new areas and subjects for research. In regard to one of these subjects, Lech
(2012) sees that there is a significant lack of research that explores the selection process of
EDM and other enterprise systems with the focus on organizational needs and information
gathering. More ideas for further research are presented in the chapter 5.3.
41
Empirical part
4 Empirical part
The empirical part consists of information gathered from the case company KONE and its
employees. First the case company is briefly presented. Then is presented the empirical data
in two tables: users of project documentation and the requirements collected from
stakeholders. The collected requirements are explained in further detail in the chapter 4.3 and
analyzed in chapter 4.4.
4.1 The Case Company
The case company is large multinational elevator and escalator company KONE. It has been
operating since 1910. Since then the Finnish family-owned company has grown to be one of
the three largest in its field. The growth and globalization of the company has come through
many acquisitions over the years. KONE has operations in more than 50 countries and has
over 47 000 employees. In 2014 it had revenue of 7.3 billion euros (KONE 2014).
The company has very independent front offices in the countries which are supported by the
headquarters. These locally operated units are called frontlines. In most cases they are
countries but they can also be combinations of countries (like KIB frontline: Spain, Portugal,
and Andorra). There are currently 44 KONE frontlines and this large amount makes the
development of new systems complex. In order to have one KONE Way of working we need
to have a system that is usable everywhere, no matter the language, tech-savviness of users,
network coverage in the area, or the amount of employees in the frontline.
The current document management practices vary between the frontlines. Some have
developed their own document management systems; some have started using free cloudbased services like Google Drive or Dropbox. In some frontlines documents are still often
kept in paper binders.
4.2 Presentation of Empirical Data
The empirical data of user groups and their role descriptions, presented in the Table 1, have
been collected from the Finnish KONE frontline. The same users groups can be identified in
other KONE frontlines, too (Some frontlines, e.g. UK, might use other names for some of the
roles but their responsibilities are the same).
The EDM requirements (Table 2) have been collected from 13 KONE frontlines and 6 global
functions:
42
Empirical part
1) Frontlines: Australia & New Zealand, Belgium, China, Czech Republic & Slovakia,
Finland, France, Germany, Iberia (Spain, Portugal, Andorra), Middle East, North
America (Mexico, US, Canada), Sweden, Turkey, United Kingdom
2) Global functions: Customer process, Fulfill process, Maintenance process, Legal,
Major Projects, Global Installation
Altogether 42 stakeholders were involved in the requirements interviews. These 42
stakeholders and their roles are described in the Appendix D.
Many of the stakeholders interviewed have multiple responsibilities and the official names of
the roles do not tell the whole story. Often these people have worked previously in other
positions in the company and have a wide understanding of the different business processes
and experience directly from the field. They get the direct feedback of the 11 different user
roles in Sales and Fulfill processes that are the main end-users of the system.
Kotonya and Sommerville (1998, 37) remind that the requirements elicitation stakeholders
are responsible for many other things inside the company with limited time and therefore
they may not give priority to the requirement engineering process. In the requirements
elicitation this was sometimes visible from the quality and quantity of the requirements.
Some frontlines had more detailed requirements while others had requirements on more
general level.
4.2.1
Users of project documentation
The table below presents and describes the different user roles involved in the Customer and
Fulfill processes.
User role
Brief description
Customer
Customer of KONE
Salesperson
Salesperson’s role is to proactively manage customer
relationships, manage opportunities from current and new
customers and close deals
Sales manager
Sales manager sets short term and long term sales and
customer relationships targets aligned with the unit’s
overall sales targets. Sales manager leads the sales
process and sales team to achieve the sales targets by
coaching and developing the sales team.
43
Empirical part
Installation supervisor
Installation supervisor’s role is to manage and control
projects from sales-to-installation hand-over to
completion at handover to client and Maintenance.
Supervisor is in charge of leading and managing the
installation team to ensure safe, high quality, completeon-time delivery of KONE solutions within budget.
He/she acts as the KONE interface to customer and other
stakeholders throughout the Fulfill process. In addition to
this supervisor is expected to support the sales team in
pre-tender and tender activities as requested.
Installation manager
Installation manager’s role is to manage the human and
material installation resources including Installation
supervisors, Installers, and Sub-contractors. Installation
manager is accountable for achieving the planned
financial results.
Installer*
Installer performs the installation of equipment on site.
Tester
Tester carries out tests of KONE equipment and the final
inspection on site.
Project manager
Project manager manages the interface with all key
stakeholders during the project. He/she plans, directs and
coordinates the activities of designated projects to ensure
that project objectives are accomplished within the
agreed schedule and budget, using approved KONE
methodologies and tools.
Engineer (TSS)
Engineer provides technical support to the sales team to
develop, sell and successfully implement KONE products
and service solutions that meet customer’s needs. He/she
takes ownership of the order handling process in terms of
prospecting/tendering/defining specifications, details,
traffic calculations, dimensions, CAD and lay-out
drawings and estimation of installation and delivery
times and costs. He/she answers customer’s technical
questions and supports the Salesperson with technical
issues.
Installation Administrator (TSS)
Installation administrator’s role is to support the
Installation supervisors during the installation process.
This includes updating the schedules and milestones,
preparing inspection documentation and handling the
project review reporting.
Order Administrator (TSS)
Order Administrators support sales teams with booking
sales orders and installation and/or project management
teams with managing the contractual communications to
customers and supply lines by way of standard
documentation and the maintenance of communication
records.
44
Empirical part
* In some frontlines the installer is referred to as fitter, mechanic, engineer, or technician.
Table 1: User roles in Customer and Fulfill processes
There are 11 different users groups in the Customer and Fulfill processes. Some are active
throughout the lifecycle of the project, like the Customer, but most only create or use
documents in a specific stage, like the Installer. All of the roles need access to project
documentation in their work and each role creates at least some documentation. Therefore
each role are both creators and users of documentation.
ADD Figure of user involvement stages in the project lifecycle.
4.2.2
EDM requirements from stakeholders
The following table of requirements (Table 2) has been compiled from 19 individual
requirement lists collected from the frontlines and global functions. The requirements were
given points based on the amount of mentions they got and on how important the
requirements were perceived by the stakeholder. The stakeholders were asked to rank the
requirements by comparing them together, so not all of the requirements could be of high
priority. The requirements had to be given a numerical order to make a distinction between
the perceived requirement priorities, so that highest priority was given number 1, second
highest number 2, and so on. This numbering was done by the frontlines in the requirements
gathering template shown in Appendix B, and discussed together with the frontlines and the
requirements engineer in the follow-up discussions.
In Table 2 are presented the requirements in priority order. Included are the requirements
which received 10 points or more, or were mentioned over two times. The full list of elicited
requirements, also the ones that did not fill these conditions, can be seen in the Appendix C.
This short list has been created to give focus on the high priority areas but does not intend to
overlook the lower priority requirements. They are not less valuable and cannot be forgotten
outside the EDM project, but have been considered not to be defining factors in finding out
what are the key stakeholder requirements and how should the EDM architecture be designed
to support these key requirements.
The requirements were given points based on the priorities in the following manner:
Ranking system: High priority = 5 points, Medium priority = 3 p., Low priority = 1 p.
45
Empirical part
This ranking is used to keep similar point intervals between the high, medium, and low
priorities, while at the same time creating enough distinction between them.
The priority points were added up to overall points of the requirement. The list has been
given order from highest score to lowest score based on these priority scores. Therefore it is
considered that this kind of additive points ranking is the best way to compare the
requirements; low and medium priorities can add up to high overall score if the requirement
has been mentioned often enough, even no stakeholder has considered it to be their top
priority.
No. Class
1
Access
Mentio
Hig
Poi
Requirement
ns
h
Mobile access to users
15
15
0
0
75
10
10
0
0
50
7
6
1
0
33
6
6
0
0
30
4
2
2
0
16
Med Low
nts
Search capabilites (metadata search, text
2
Function
search, AND, OR, NOT)
Version history (last edited by whom and
3
Function
when)
Integratio Possible to store documents from other
4
n
systems to EPF (IMT2, Salesforce, KTOC)
Soft deletion. Users can retrieve their own
5
Function
deleted documents, admin can retrieve all.
Possible to give access to third parties
6
Access
(outside of KONE)
6
1
3
2
16
7
Access
Read/write access outside of KONE network
3
3
0
0
15
8
Access
Access rights are role-based
3
3
0
0
15
3
3
0
0
15
10 Metadata equipment or projects
3
3
0
0
15
11 Security
3
3
0
0
15
12 Structure documents through its lifecycle
3
3
0
0
15
13 Structure Unlimited storage space
3
3
0
0
15
Metadata should originate from Salesforce
9
Metadata and SAP
One document can be linked to many
Reliable backups
Project folder should cover all the project's
46
Empirical part
14 Function
Automated assembly of document binders
3
3
0
0
15
15 Function
Email to EPF (also with mobile devices)
3
2
1
0
13
16 Function
Email from EPF (also with mobile devices)
3
2
1
0
13
4
1
2
1
12
Easy/Automatic archiving once project is
17 Archiving completed
Integratio Possible to access documents from other
18 n
software (IMT2, Salesforce)
3
1
2
0
11
19 Access
Access rights managed by frontlines
2
2
0
0
10
20 Usability
Intuitive user interface
2
2
0
0
10
21 Function
One-click upload of documents to EPF
2
2
0
0
10
2
2
0
0
10
been edited or uploaded
3
0
3
0
9
24 Metadata Metadata fields populated automatically
3
1
1
1
9
25 Archiving Retention period for archived documents
3
1
1
1
9
Possible to use
22 Usability
on
limited connectivity
(Efficient netcode)
Alerts per document or folder when file has
23 Function
Table 2: Elicited requirements from KONE frontlines and functions
The requirements were given a class based on the characteristics of the requirement. These
classes were Access, Analytics, Archiving, Function, Integration, Metadata, Security,
Structure, and Usability. These classes are further analyzed in the chapter 4.4.
4.3 Explanation of the Empirical Results
In this chapter the requirements presented in Table 2 will be analyzed and explained more
thoroughly. This will cover all of the 25 requirements ranked in Table 2.
The final requirements list has been combined from 19 individual requirement lists, so the
possible maximum amount of mentions for a requirement is 19. Mobile access to users
reached highest mentions with 15, the average amount of mentions for a requirement being
2.421. The full list of requirements can be seen in the Appendix C.
When it comes to amount of mentions, it is important to understand why not every frontline
and function has mentioned the same requirements. First of all, some frontlines wrestle with
47
Empirical part
different problems than other frontlines and the global functions have often altogether
different viewpoints than the frontlines as they are looking at the larger picture of processes
instead of the day-to-day viewpoint of frontlines.
4.3.1
Requirements explained in detail
#1: Mobile access to users
This requirement was mentioned by each frontline and two global functions. It can already be
seen from this that mobility is currently the biggest problem in the frontlines. The people who
create and use the installation project documentation are in the frontlines, and they work
often outside the office where the documents are needed. It is inefficient, unnecessary, and
frustrating for the employees to travel to the office just to print out a document needed on-site
or update information collected on-site to a system that is only available at the office. All the
frontlines are aware that many hours are wasted weekly just because the lack of a mobile
document platform. The need for mobile document platform vary between user roles, as some
are working in the office (e.g. Installation and Order admins) while some are working out of
office for the major part of the time (e.g. Installers and Installation Supervisors).
#2: Search capabilities (metadata search, text search, AND, OR)
Once a document has been uploaded it has to be located. The problem of finding documents
is clearly the second biggest problem in document management. The fundamental problem
here is that usually it is one person that uploads the file somewhere and then another person
has to find it. In the interviews it was said that not even the uploader always knows where he
or she should place the file, so how could the downloader know where to look for it.
Therefore, the system needs to have good search capabilities. Metadata is something that is
used to tag documents so it would be easier to find them later on. There definitely has to be
this kind of metadata layer in place for searching purposes. In the metadata search there
should also be the possibility of using search functions such as AND, OR, and NOT to
include and exclude metadata combinations to find the correct file. This can be especially
handy in large projects where a project name metadata search could return hundreds of
documents. Also requested was text search from within the documents. Sometimes the user
only remembers certain parts of the document’s content and not the name or the metadata of
the document.
#3: Version history (last edited by whom and when)
48
Empirical part
Finding the correct and up-to-date information is exceptionally valuable. Imagine going to
the installation site and installing the elevator only to find out later that you did it using old
version of the drawings. This is what version history is for. It shows the version of the file,
when it has last been modified and by whom. It should also allow backtracking of document
versions in case the older versions are needed.
#4: Possible to store documents from other systems to EPF (IMT2, Salesforce, KTOC)
KONE has couple of existing systems that are creating a lot of documents. These are IMT2,
Salesforce, and KTOC. Currently the documents that they generate are first saved to the
user’s computer and then manually uploaded to a repository. The stakeholders requested that
this could be done straight from the other systems so that e.g. IMT2 would save the document
straight to the destination in EPF.
#5: Soft deletion (users can retrieve their own documents, admin can all)
Soft deletion means that after the initial deletion there is a defined retention period when the
deleted document can still be restored. Users could restore documents they have deleted and
the system admin could restore everybody’s documents. The current system admins
explained that every year there are several incidents where documents are accidentally
deleted or overwritten by wrong document versions. The possibility that admin can retrieve
all of the documents is more of a security feature in case some user would try to harm the
company by deleting documents.
#6: Possible to give access to third parties (outside of KONE).
KONE shares certain documents to customer, suppliers, and government authorities. As an
example, elevator drawings might be shared between KONE, the customer, and an outside
drawing’s supplier. Drawing documents are often so large in file size that they cannot be
shared as email attachments. At the moment different platforms and software are used for
sharing, like Dropbox or Google Drive. In these third-party platforms KONE has no
oversight on the shared files and who has accessed them.
#7: Read/write access outside of KONE network
KONE network connection (in the office or via VPN) has been requirement to access the
intranet, where in most frontlines the project documentation has been kept. This connection
has been impossible on mobile devices and even on laptops it has been felt as unnecessary
49
Empirical part
step just to access documents. Three frontlines felt this as a high priority requirement, while
the rest were mostly content with the current VPN access on laptops. The reason why this
was not mentioned more often could be that stakeholders felt that the #1 Mobile access to
users requirement includes the accessibility to project folders without complexity of VPN
tokens.
#8: Access rights are role-based
This requirement came up with the global functions and the admins and managers of
frontlines. With potentially thousands of users the access right management has to be
organized so, that access rights are not created individually for each user. One smart
approach for this is to create user roles and give these user roles a predefined set of
read/write/admin rights. These user roles could follow the already existing structure of
employee positions, like Installation Supervisor or Salesperson. Salesperson will have certain
rights by default and if needed the admin could upgrade or downgrade them if needed. This
kind of customization is necessary option in addition to the default role-based access rights to
ensure enough flexibility because it is certain that special situations and user roles will turn
up.
#9: Metadata should originate from Salesforce and SAP
Metadata is crucial part of EDM. It is needed to trace and find the documents. Without
metadata tags the EDM system cannot provide version history as it does not recognize the
documents as the same, nor can the users have advanced search capabilities as mentioned in
the #2 requirement. Salesforce and SAP are the two existing systems that generate
identification numbers to elevator and escalator projects, like Equipment number and Sales
Order number, that are used to identify to which project the document relates to. The
metadata used in document management should hail from this already existing foundation.
#10: One document can be linked to many equipment or projects
One document can be relevant for multiple equipment or even projects. A contract, for
example, can be cover installation of dozen elevators. In this case, the contract has to be
linked to all the relevant equipment and projects so that the contract shows up when
searching with the each of the equipment’s metadata.
#11: Reliable backups
50
Empirical part
File backups ensure that any of the documents does not disappear by accident. This means
that there are backups of individual files on the file server in case a single file goes missing or
is corrupted and also that there is a backup in case the whole server crashes or breaks down.
Backups are also something that is required for both #3 Version history and #5 Soft deletion
requirements.
#12: Project folder should cover all the project’s documents through its lifecycle
Traditionally documents in KONE have been managed in silos. These silos have been Sales,
Installation, and Maintenance. The visibility from one silo to other has been limited and not
just in documents but in the functions overall. Project information has transferred forward in
the pipeline by handovers: Sales-to-Installation handover and Installation-to-Maintenance
handover. Before the handover the latter of the functions would not see what documents have
been created for the project and therefore could not contribute in the projects earlier. This
requirement was expressed especially by the process oriented people who had visibility over
all of the three silos and hoped to break these boundaries and turn all of the three into one cooperating unit. When Sales, Installation, and Maintenance are all using the same repository
for storing documents they have earlier visibility over the projects and can participate in
them.
#13: Unlimited storage
Unlimited storage is surprisingly low on the priorities. Three frontlines mentioned it, but all
with high priority. These three countries currently suffered from insufficient space in their
local network drives, which forced them to split their projects to many different drives that
only increased the complexity of finding the documents ever more. The reason why this was
not mentioned more often was likely the fact that other frontlines had not experience these
problems of running out of storage space and therefore took it as granted. And they are not
far off, because today pretty much every cloud storage provider can give unlimited space to
their customers as long as they are paying for it. It is then up to KONE to possibly restrict the
amount of storage space allowed to control the costs.
#14: Automated assembly of document binders
The assembly of different document binders is one of the most time-consuming tasks in
document management. One of these binders is Declaration of conformity that is given to
authorities once the installation is complete and has to be created for each equipment. It is the
51
Empirical part
most important document legally. Other binders are Installation binder and Customer manual.
These document binders are assembled from individual documents and information that is
stored in KONE systems. In the interviews the stakeholders estimated that the assembly of
these binders can take between 4-10 hours depending on the size of the project. Some of the
frontlines had already developed software to help with this process but they lacked the
resources and appropriate integrations to KONE systems to make it fully functional.
#15: Email to EPF (also with mobile devices)
Email is still often the main channel of communication in companies and so it is also in
KONE. Emails flow between KONE employees and to and from customers and third parties.
Documents are being attached to these emails and currently have to be first saved on the
computer and after that stored to the correct repository, or far too often not saved anywhere
but kept in the email visible only to the participant of the email chain. To circumvent this
problem stakeholders request that it would be possible to send emails to the Electronic
Project Folders. EPF could be added to the email recipient list and based on its metadata it
would automatically be added to the correct folder. This naturally means that metadata
structure is a prerequisite also for this functionality and requirement.
#16: Email from EPF (also with mobile devices)
Together with sending email attachments to EPF stakeholders requested to have the
possibility to integrate the email so that it would be possible to send documents via email
straight from the EPF system. This would eliminate the step where user downloads the
document from EPF and then opens the email client, writes and email, and then attaches the
document to the email. Eliminating this kind of unnecessary steps, even they might seem
relatively small, multiply hundreds of thousands of times in a year in a global scale and save
a lot of work time and free resources for actions that actually create value for the company.
#17: Easy/Automatic archiving once project is completed
Once a project is completed the documentation is no longer needed on a daily or weekly or
even monthly basis. The nature of the folder and the documents inside it transforms from
dynamic to more static. It should be easy to archive the project’s documentation once the
dynamic phase is over. Stakeholders requested that the archiving could be done by pressing
and “Archive” button that would then select all the project’s documents and move them out
52
Empirical part
of the active projects to archive repository. Another option this could be automated archiving
once the project reaches certain milestone in SAP.
With 130 000 (KONE 2014) equipment installed every year and each equipment having 10 to
50 documents, it is not reasonable to keep finished projects in the active storage. Therefore an
archiving solution needs to be implemented. Even this does not currently exist and is out of
this thesis’ scope it is an important and relevant requirement. This functionality has to be
thought already at the planning phase as it might require architectural and metadata structures
that have to be created in the foundations of the system.
#18: Possible to access documents from other software (IMT2, Salesforce)
IMT2 is software used a lot by the Installation Supervisors. Salesforce on the other hand is
key software for the Salespersons. They are used to in different stages of the project but both
of them are also responsible for creating documents. Stakeholders would like to have the
possibility to access the project’s documents from these systems. As an example, the
Installation Supervisor manages a certain project using the IMT2 software and could press a
button in the software that would show documents stored in EPF relevant for that particular
project. This requirement was mentioned once as a high priority and twice as medium
priority. It would save the users time and add to the usability and accessibility of the
documentation but the EPF would still be beneficial even this integration proved to be too
complicated.
#19: Access rights managed by frontlines
This requirement was mentioned both by a frontline and a global function. Even it was only
mentioned twice, it is important that both ends feel that frontlines should be managing in
access rights. This is linked to the requirement #8 Access rights are role-based but as roles
may vary slightly between the frontlines it is important they can customize and manage
access rights themselves. This does not mean that they can set up the access rights in any way
they like and the global function has no control over it. In the interview with the global legal
department they expressed the importance that access control and rights have to be strict
especially for the documents that have financial information visible. It cannot be so that
everybody can see every document, even if the frontline would be fine with that practice.
#20: Intuitive user interface
53
Empirical part
This requirement is rather vague. The words used by the stakeholders were “intuitive”,
“clear”, and “easy to use”. Many of the employees in elevator and escalator projects are
hands-on workers with the average age between 40- to 50-years-old. They are not necessarily
tech-savvy or familiar with all the nooks and crannies of IT systems such as hotkeys or
terminology. Basic functionalities such as upload and download of documents have to be
clearly visible and less often used functionalities, like archiving, should be hidden or have
smaller exposure. One could guess that this requirement is something that is on a wish list of
every user, though it was only mentioned two times in the interviews. The reason for this
could be that most stakeholders were mentioning more concrete requirements related to
functionalities rather than on the overall usability of the interface.
#21: One-click upload of documents to EPF
Many frontlines expressed that the EDM system has to be easy to use. Two explicitly said
that there should be “one-click upload” functionality. The need for easy upload became
apparent in apparent in many of the interviews, some of the frontlines tied it together with
other functionalities as in requirement #20. One-click upload means that that there would be
one button in the system or software that uploads the document to the system instead of going
through menus, browsing through local computer file system, naming the file and setting up
the metadata, and finally getting the document to EPF.
#22: Possible to use on limited connectivity (efficient netcode)
Construction sites often have limited connectivity due to missing network infrastructure. Also
some parts of the world have very limited mobile data network that only allow slow
connection speeds. The EPF interface should be light enough so that the system itself does
not use all of the bandwidth. One alternative suggested by the stakeholders for this was to
enable setting chosen folders available offline, so that the EPF software would download
them when there is a strong connection and then they would be locally available on the
device. Otherwise, there is nothing that can be done to the download speeds if the limitation
is the network infrastructure.
#23: Alerts per document or folder when file has been edited or uploaded
Sometimes the user is waiting for a document from someone else before the project can
proceed. It is not purposeful if one has to be checking the repository once in a while just to
see if someone has uploaded a file or made the requested edits to an existing file. Before this
54
Empirical part
would have been done so that the uploader sends the other person an email telling that the file
is now available but this can be automated which saves time and effort. The three
stakeholders reporting this requirement felt it as an important functionality but also as
something that could be implemented after the more crucial functionalities were in place.
#24: Metadata fields populated automatically
As it has come apparent in a few of the previous requirements, document metadata is highly
important to make the EDM system viable. To enable requirements such as #2 Search
capabilities each document requires a wide array of metadata and as requirement #9
Metadata should originate from Salesforce and SAP states, this metadata should come from
already existing core systems. Because the metadata is already available in structured digital
format it could be automatically populated into the documents. This is already partly in use in
one of the frontlines. They write, let say, the Project name as a documents metadata and
based on that the EDM system is able to guess the rest of the metadata attributes. This will
save a lot of work when uploading the documents and ensure that the documents are actually
given the appropriate metadata to enable the implementation of other requirements.
#25: Retention period for archived documents
Even the documents have been moved to a static archive out of the active document view,
one day they are not needed anymore. Some of the documents are important for longer, like
contracts with warranty information, but other documents become obsolete quicker, like info
letters sent to customer during the construction project. Some of the documents could be
deleted after the customer has accepted the elevator and some documents would be kept as
long as the installed equipment physically exists, which could mean decades. Electronic
storage space has become ever cheaper but there is no point storing totally useless
documents. The possibility of setting retention periods for archived documents were
mentioned both on the frontline and global level. It was also a concern raised by the legal
department.
4.4 Analysis of the Results
In this chapter the elicited requirements are inspected and analyzed from the viewpoint of the
whole EDM system and its architecture and in comparison with the theory and
recommendations from literature. This analysis looks at why these requirements have been
seen as important by the stakeholders, and also why some requirements have not been
55
Empirical part
mentioned so often. The goal of this analysis is to evaluate the validity of these empirical
results and to find out what kind of requirements do they set for the design of the EDM
system.
4.4.1
Classifying the requirements
The requirements each have been given a class defining their nature: Access, Analytics,
Archiving, Content, Function, Integration, Metadata, Security, Structure, and Usability.
These classes are mentioned in the second column of the table of elicited requirements list.
The division the 57 individual requirements by classes are presented in the following Table 3:
Classes of the requirements.
Class
Mentions
Function
12
Access
11
Structure
8
Usability
8
Content
5
Metadata
4
Security
3
Analytics
2
Archiving
2
Integrations
2
Table 3: Classes of the requirements
According to Kao and Liu (2013) EDM requirements could also be classified based on the
following two aspects:
1) Support for ubiquitous access. Anytime, anywhere, any device accessibility.
2) Support for sharing and collaboration. To inside and outside of the company.
56
Empirical part
This two-class split seems too vague from the standpoint of this thesis, as not all of the
requirements are related to access or sharing and collaboration. As an example, forcing
metadata or integration requirements to either of these baskets would seem odd.
Some of the elicited requirements could have fallen under a couple of the classes (like the
Email requirements: they could have been both functionalities and integration.). The
classification has been done based on the evaluation what is the core nature of the
requirement (whether the requirement requires the Email to be a functionality of the system
or whether it requires the Email system to be integrated together with the EDM system).
From the Table 3 can be seen, that most of the requirements were related to functionalities.
This on the other hand is very much linked to the usability of the system. When
functionalities like the requirement #21 One-click upload of documents to EPF exist, it adds
to the usability of the system. This is not true for all of the requirements, though, like
usability requirement #50 Easy to learn (1 hour training is sufficient) that is an overall
quality of the system and not a functionality. Nevertheless, it can be said that functionalities
and the overall usability of the system are the areas that the stakeholders are most concerned
of, quite understandably as it is the front-end visible to the users and affecting the user
experience the most.
The other hot topic in the requirements is accessibility. Access class alone has 11
requirements, of which four are in the top eight on the requirements list. Mobility is also
considered to be part of accessibility, as the requirements core nature is to be able to access
and use the documents anywhere. The high amount of access related requirements shows that
the current system and its structure lacks in accessibility and that it has to be one of the main
focus areas when creating the new system design.
The back-end requirement classes Structure, Metadata, and Integrations may not be obvious
to the user, even though they easily determine whether the system is able to operate in a way
that enables the desired functionalities. Search capabilities exploiting metadata (requirement
#2) requires a system structure that has built-in metadata fields and if these fields are to be
populated with metadata automatically or semi-automatically it requires an integration to a
system where the metadata is located. This also highlights the interconnectivity of the
requirements and the fact that the requirements do not solely belong to one class.
57
Empirical part
4.4.2
Validity of the results
The extent of requirements collection and level of its formalization is a lot lighter when
selecting pre-existing software compared to developing new software (Lech 2012). KONE’s
aim in EDM system implementation was not to build something new from the scratch but to
enhance existing solutions to fit the KONE processes and ecosystem. Therefore we do not
have to have a detailed list of every capability the software should have, but a list of the
specific and important capabilities and functionalities should be sufficient. This has to be
taken into consideration when evaluating the validity of the results.
The elicitation results of this thesis are a combined view of project documentation’s key
stakeholders. These stakeholders were chosen based on their understanding of the business
processes, the nature of the elevator and escalator projects, and the current system and its
flaws. These subject matter experts from different areas (namely Customer and Fulfill
processes) should have the best knowledge and understanding of the EDM needs in KONE.
Still the validity of the results cannot be taken as a given.
As an example, one Legal stakeholder can easily be trumped by a dozen of frontline
stakeholders who do not see the legal issues as their priority. It does not make the single legal
requirement less important than a functionality requirement mentioned by multiple
stakeholders. Therefore the list of requirements should not be judged purely based on the
point ranking.
The points ranking gives guidance on what are the key focus areas that would improve
efficiency in documentation and make the system best serve the users. This was also the idea
behind eliciting the requirements indeed from the end-users and not from the IT function. The
IT experts would have probably created a requirement list that would have looked quite
different from the list presented here. It would have been very valid from their point-of-view
but might not have served and fulfilled the users using the system on an everyday basis.
Some of the requirements are very clearly defined while other can be more general. The
problem with too general requirements is that they do not really provide much help in
designing the system. An example of too general and vague requirement could be #11
Reliable backups or #20 Intuitive user-interface. They tell what the system should do but do
not really tell how the system should do it, something that Kotonya and Sommerville (1998)
regard as important quality of a requirement. This is fortunately the case only in very few
58
Empirical part
requirements as the rest are concrete enough to be used as building blocks of an EDM
system.
Some of the requirements share the same overall points and therefore are to be valued
similarly. The reader should take this into consideration when prioritizing the requirements
and when comparing them together. The requirements with same amount of points were not
given the same order number to avoid confusion in identifying the requirements.
Stakeholder may be able to influence the requirements based on their status or personality
instead of well-reasoned arguments. This was acknowledged in the requirements engineering
process. Each stakeholder was given the same template with the same ranking system and
their requirements were given the same weight in the final list of requirements (Appendix
C.). The high priority of one stakeholder was just as important as the high priority of the next
stakeholder.
Some requirements could be considered to be part of another requirement, like the
requirement #21 One-click upload of documents to EPF could be considered to be part of
requirement #20 Intuitive user-interface. This interrelation is very close to the subject already
discussed with the classification of the requirements. These connections should be analyzed
with care during the creation of the system to ensure a successful end result.
4.4.3
Comparison of the results with theory and literature
The theory often discusses matters on the level of strategy and models, which are simplified
constructions of the reality. Still, many of the requirements mentioned by the stakeholders are
visible also in the EDM theory and literature. Literature also shows examples of cases with
similar stakeholder requirements and of benefits gained by implementing these requirements.
The cloud storage environment is something that is considered as a standard in today’s EDM
systems (Gartner 2014). The benefits of a cloud environment are that the users are able to
access the documents anytime, anywhere, and with any device (Kao and Liu 2013). These
benefits seem to be what the KONE stakeholders are also looking for. Requirement #1
Mobile access to users indeed can be translated to being able to access the documents
anytime, anywhere, and with any device.
Already from the very beginning of the interview process, it became apparent that the future
EDM system would require integrations to existing systems. In the case company this would
59
Empirical part
mean ERP system, CRM system, Email, and couple of custom-made applications. Integration
to ERP and other IT systems enables the company to connect the document management to
the business process. The requirements #4, #9, #15, #16, and #18, all require integrations to
other systems. Volarevic et al. (2000) write in their paper that it is possible to do integrations
between EDM systems and with a diverse array of existing applications such as Microsoft
Office, SAP W3, or custom designed applications made in popular development tools (C++,
Java, Delphi...).
Searching and search capabilities were the requirement that received the second most
mentions, all of them with high priority. It is no wonder that the users give a lot of weight to
search capabilities as effective search is considered to be one of the most common
shortcomings in EDM (Ginsburg 2000). Being able to find the correct document in adequate
time is the main purpose of EDM systems and if this ends up being a shortcoming, the whole
acquisition of the system becomes questionable. The different search capabilities of metadata
and text search were also mentioned in the EDM functionalities list by Asprey and Middleton
(2003) as was shown in the chapter 3.2.2. In the elicited requirements the users also wanted
to include search functions like AND, OR, and NOT. This would help them combining
metadata attributes the way the like and help in finding the correct information easier.
The structural requirements expressed by the stakeholders reflect the status quo of document
management at the case company. Requirement #30 requests a default folder structure for
projects and requirement #47 a folder structure that is scalable based on the project’s size.
Both of these are valid requirements for a hierarchical structure but do not apply for a cloud
storage managed by metadata structure.
The importance of the version history (requirement #3) is also apparent from the literature.
Johnston and Bowen (2005) say that to ensure trust of the users in the EDM system, the
system should enforce version control of the documents. When the document versions are
monitored, the users do not have to be guessing is the document really valid and up-to-date.
The costs and risks of using and old document version can be huge. Think about the elevator
being installed using outdated version of the installation drawings. This could result in the
whole elevator shaft being created the wrong size, which is an immense job to fix afterwards.
Also Sprague (1995) highlights version control as one of the key functionalities that should
exist in an EDM system.
60
Empirical part
Requirement #24 Metadata fields populated automatically is also mentioned by Asprey and
Middleton (2003, 50) as an important feature of an EDM system. They also add that even
though metadata is populated automatically but there should also be possibility for the
creators to enter manual metadata to the documents. Automatic metadata population makes
the storing of documents much faster, user-friendly, and consistent. In regards to manually
entered metadata, Asprey and Middleton remind that every manual step is prone to human
error. This human error could result in nobody ever relocating the document or in worst case
somebody taking it for a correct document for another project.
Workflow functionality allows users to automate the review, revision, and approval business
processes in the documents lifecycle (Volarevic et al. 2000). In practice, this could mean a
business process that flows through the lifecycle of a construction drawing that is created by
an Engineer, reviewed by Engineer supervisor, approved by the Customer and by the Sales
manager. Workflow formalizes this business process so that it is executed the right way every
time and it ensures that everybody has done their part in the process.
Many companies fail to apply archival and disposal processes to electronic documents stored
in virtual repositories despite there are lot of guidance and strategies available for this
(Asprey and Middleton 2003, 43). This observation by Asprey and Middleton can be made
also in the case company and the list of requirements. Requirements #17 Easy/Automatic
archiving once project is completed expresses the need for an archiving practice that is easy,
or better yet, automatic. Requirement #25 Retention period for archived documents is more a
headache of the administrators of the system but it was raised by three different stakeholders
as an important factor to be included in the new system.
Individuals may see EDM system as a threat. They might feel that their work will become
more complex and more controlled. The benefits for the organization or the society may not
be evident from the individual user’s point of view. Therefore user acceptance is crucial in
EDM system implementation (Johnston and Bowen 2005). If users do not accept the new
system, they will start or continue to use other systems to store and manage documents. It is
important that the new system does not demand significant changes in the way how users do
their work and that the system is simple enough to use even with more rudimentary IT skills
(Johnston and Bowen 2005).
There are dozen requirements (#2, #4, #7, #14, #15, #16, #17, #18, #20, #21, #22, and #23)
that directly affect the user experience and can help in the user acceptance mentioned by
61
Empirical part
Johnston and Bowen in the previous paragraph. In this thesis it has been already mentioned
several times that the behavioral and sociological aspects of the user acceptance are very
critical for the success of the system. As said, reducing the complexity and feel of control are
big parts of this.
Storage costs are usually a small portion of document and records management budget but
what is more costly are retrievals of documents (Johnston and Bowen 2005). This should be
kept in mind when decisions are made on storage space. Is the cost of giving the users
“unlimited” storage space reasonable compared to possible problems that can arise if user
does not have enough storage space? If the users are encouraged to save space, it will likely
result in sharing and storing of only part of the important documentation. It is evident from
the requirements (#13) that the stakeholders would like to have unlimited storage for their
project documentation so that they do not have to balance between what is to be stored and
what is to be left out because of space restrictions.
Training of the users is of course an important factor in the successful implementation of any
system. The more there are human elements involved in the documentation process, the more
important training becomes (Johnston and Bowen 2005). Training was surprisingly
mentioned only once and that was outside the shortlist of 25 requirements (on place #50).
Different user roles need training that supports the actions they need to perform in their role.
It is beneficial to share best practices between the users to avoid the situation where
everybody needs to invent the wheel themselves.
62
Conclusions
5 Conclusions
As can be seen from the requirements engineering and EDM theories, as well as the
requirement process models of Kotonya and Sommerville (1998) and Zwoghi and Coulin
(2005) and the elicitation technique selection model of Hickey and Davis (2003), domain
understanding is the critical factor in EDMS development. The EDMS project should start
from business needs and have a clear goal what it is set to achieve. The problem domain has
to be well understood before jumping into implementation of the system and each stakeholder
group should be included in the project to achieve a system that is well-received by the users
and meets the expectations it has been given.
A quick answer to whether an enterprise wide EDM system can be chosen based on the list of
57 requirements from 42 stakeholders is “no”. Too many fundamental aspects remain
unknown, like performance requirements for the system, access rights determination, and
changeover from the old system. More of the excluded areas have been mentioned in the
chapter 1.4.1 about what is not included in the scope of this thesis. But the purpose of this
requirements list is not to be exhaustive list of EDM requirements but to highlight the key
focus areas at the case company that, when fixed, will allow huge leaps in efficiency and
profitability of the company.
If the question would be rephrased to “can an EDM system structure be designed based on
the list of 57 requirements from 42 stakeholders” the answer would be “yes”. What these 57
requirements do show, is that the new EDM system has to have a structure that allows
intuitive user experience where files are stored in a repository accessible anytime and
anywhere. The structure also has to enable easy uploading of documents with standardized
metadata attributes. This will make the eventual finding and accessing of the documents
much easier than it currently is. It is also clearly visible that the new system cannot be
separated from other enterprise systems but has to be integrated so that there is a symbiosis in
the IT architecture.
5.1 Recommendations for EDM structure
Weers and Vrancken (2010) mention the lack of pre-defined document management
structures as the biggest problem in EDM architectures and the reason why companies have
not been able to leverage their full potential. Asprey and Middleton (2003, 481) recognize
this same phenomenon and contemplate that too often organizations are living in a utopia that
63
Conclusions
the problem of document management will solve itself or the change from paper to digital
will make the problem of managing documents vanish. The pre-defined document
management structure is a foundation that enables the required functionalities and enables
efficient use of the system. This is something the author wanted to address in this thesis and
highlight as one of the key components in EDM system development.
What these pre-defined document management structures mean, is that there is a storage
structure that is used consistently throughout the company and that there are clear guidelines
on storing, archiving, accessing, and using the documents. The three dominant storage
structures used in EDM systems are the ones presented in this thesis: hierarchical, metadata,
and hybrid. Out of these three, the hierarchical structure does not anymore meet the business
needs of large companies where multiple persons need to access and edit the same documents.
This applies very well to the case company, where there are 11 different user roles in the
installation project who are using the documentation through different user interfaces both in
and out of the office. The hierarchical structure requires that the user knows where the
document is located in order to retrieve it. This can be very time-consuming in installation
projects that vary in complexity and size, and therefore in the amount of folders and
documents. Also for a company that operates in 44 different frontlines, it would be very
challenging to force a global hierarchical structure that would be useful and accepted
everywhere.
A benefit of hierarchical structure is that users are often familiar with it. Notably the users
who are mainly creators of documents, as compared to users who are using documents
created by others, may like the easiness of placing a document to a folder and seeing the
logical tree structure. Also the hierarchical structure is fast to use for the document’s creator
as it is sufficient just to give the document a filename and then place it in the correct folder
and move on to next tasks. This is also why the hierarchical structure can still be the best
option in small companies where the amount of documents is small and there are clear
guidelines for naming of documents and to which folders to store each document. In small
companies it might not be feasible to create a metadata structure to documents.
As was presented in the chapter 3.3 about EDM implementation in British Library (Maguire
2005), the users found the folder structure to be one of the main pain points. It was difficult
to know where to store a file and how should the folder be named. Other pain points were the
difficulty to use the system on a laptop (in this context this could be easily expanded to cover
64
Conclusions
mobile devices altogether), finding documents and records, and the unintuitiveness of the
user interface. All of these remarks made by the users of the implemented British Library
EDM system can be seen also from the requirements of KONE users. They clearly are
current problems and something that the users want to avoid in the new system.
The metadata structure is a structural requirement of an EDM system that would fulfil more
complex requirements in a company. It is obvious that in KONE metadata structure is needed
to create an EDM system and architecture that meets the user requirements and enables new
and more efficient ways of working.
Metadata is required for the system to understand the relations of each document. It will
make it possible for other software to know what documents are relevant for each project and
the EDM system can also create customized interfaces for different user roles based on
document metadata. As an example, when a salesperson is creating a tender to a particular
customer, the CRM software is able to fetch all the previous tender documents created for
that customer from the EDM system based on the customer name, a metadata attribute in the
tender documents.
Metadata structure does not only enable integrations between EDMS and other systems but to
be effective it also needs integrations. To have automated or semi-automated population of
metadata to documents this metadata has to come from somewhere. This somewhere in the
case company would be the CRM and ERP databases which are the core systems of the
company and contain the data that would be useful for the users to identify and retrieve
documents. The automated metadata flow to documents is important to avoid all of the
following: 1) user time wasted on entering metadata, 2) human error in entering the metadata,
3) the documents will not have metadata because the user did not know how to enter it or did
not feel it worth their time to enter it. Especially the last point is very important. If the system
does not enforce the documents to include at least some metadata they can be hard to find
later.
The author’s views are aligned with Hjelt and Björk (2006, 116) who see metadata
automation as a solution to the problems of metadata structure. This idea was also visible in
the elicited user requirements and should definitely be implemented into the EDM system.
The automated metadata should come from the core enterprise systems of the company, like
the ERP system that already stores a lot of data in a database form.
65
Conclusions
The hybrid structure can combine the benefits of both worlds: the familiarity and logic of
hierarchical structure and the searchability and easiness of document retrieval of metadata
structure. The hybrid structure is in essence a metadata structure but it presents the
documents to the users in views that resemble hierarchical structure. There can be various
different views, e.g. a view for every user group, and these will require customization that
can increase the costs of the system.
The searching capabilities that Alberto et al. (2009) noted (presented in chapter 3.3) suggest a
hybrid approach to the EDM system structure: Visual search by folder location is enabled by
hierarchical structure, search by index fields describing the document is enabled by metadata
structure, and search by text in the documents can be enabled by the both. The need for these
three search capabilities should be in place in an EDM system. The need for them is visible
from the research data of this thesis as well as previous studies in the field.
Central repository is recommended by Alberto et al. (2009) and Bäckblom et al. (2003)
among many others. Also from the practical viewpoint of maintenance and system
administration central repository is a necessity. The cloud storage capabilities of today enable
global access anywhere anytime, as Sumalatha et al. (2013) verify. Cloud-based centrally
managed repository is therefore aligned with both the literature and the elicited user
requirements.
The hybrid structure with centrally managed cloud storage would be the optimal fit for
KONE. Whether it is the metadata structure or the hybrid structure that is implemented, there
has to exist a solid metadata foundation. One enabler for this solid foundation and another
critical part of focus is integrating the EDMS to the core systems of the company where the
metadata originates from.
KONE should compare the available EDM solutions from system providers and investigate
their suitability to the collected requirements and to existing IT systems together with the
expected EDM costs. As the empirical results from literature showed, even the initial costs of
EDM systems can be high, the payback time and return on investment are usually on a very
good level.
5.2 Discussion
Many of the requirements mentioned by the users are the core functionalities of EDM
systems, also mentioned in the list of EDM functionalities by Asprey and Middleton (2003)
66
Conclusions
in chapter 3.2.2. It is visible from the requirements list that the users are not looking for any
revolutionary functionalities but rather traditional ones in an user-friendly context. The
commercial EDM systems have offered qualities like version history and file backups for
years as a standard functionalities but the fundamental problem of imbalance between
creators of information and users of information remains.
In construction projects it is typically so, that certain users are net deliverers of information
and others are net recipients (Björk 2006). This creates a situation where the uploader has to
spend his own time to benefit others but he may not see the benefits himself. When a
salesperson uploads his correspondence with the customer to the EDMS, he serves the next
users in the project pipeline who will work with the project (e.g. installation supervisor or
project manager) but the salesperson himself does not get any direct benefits from the upload.
Often it can feel quite the opposite: wasting time in sharing documents that might not even be
needed by the next users.
Metadata and its automation will allow the users of the documentation to be able to find a
document they need by just knowing what they are looking for: what kind of a document it is,
to what project does it belong to, who is the customer, or who has created the document. It
will also ease the burden of document creators when the creator no longer has to fill in all the
metadata manually but the EDMS will do it on his behalf.
Even the new system is implemented and the metadata flow to the documents has been
automated, the problem of legacy documents without metadata remains. This is an issue also
mentioned by Ginsburg (2000). There is no one solution to this. The transformation of the old
documents to the new system and creating metadata to them can be very costly compared to
the benefits. If the old documents are rarely used, it may be best to keep them archived in the
old structure with the file name as an identifier.
The list of requirements presented in this thesis cannot be judged purely on the basis of points
ranking. Some requirements have to be given attention even they were expressed by only
some stakeholders in the requirements elicitation. Legal, as an example, only had one
stakeholder in the requirements collection process but their requirements can be the ones
ensuring that the system is secure and follows applying laws and regulations.
Based on empirical findings from literature and EDM theory, training is definitely something
that has to be given more focus than it received in the recommendations. It was only
67
Conclusions
mentioned once (requirement #50), which is understandable considering the functional and
architectural focus of the requirements elicitation.
Even though email is often the main channel for communication in construction business, it
does have several drawbacks. The most important one is the vast amount of incoming e-mails
that floods the users. 60% of this email flood is completely irrelevant to recipients but still
requires much effort to read and archive or delete (Weers and Vrancken 2010). EDM system
can help to reduce this email flood as documents do not have to be shared via email anymore,
at least not internally.
Knowledge should be company asset but too often it is tacit knowledge stored in heads,
office desks, or files on personal computers (Volarevic et al. 2000). Creating an EDM system
that manages and organizes the company’s documents can help in turning the tacit knowledge
into explicit knowledge available for the whole organization. When the average time an
employee stays in one company has significantly lowered in the recent times, the keeping and
storing of organizational knowledge has become an important challenge for companies.
Volarevic et al. (2000) say that an EDM system does not have to be implemented to the
whole enterprise at once but instead it can be implemented gradually. Gradual
implementation allows piloting of the system on a smaller scale and learning of best practices
that can be of help in the next implementation phases. The gradual implementation approach
was adopted by the case company and, due to the complexity and the vastness of the EDM
system KONE is creating, it is the only way an EDM system can be implemented.
The solution cannot be just to increase the storage capacity, as it would just exacerbate the
documentation problem, as Asprey and Middleton (2003, 44) mention. There needs to be
strategic and structured process to manage the documents for the company to work
effectively. Structured EDM system and practices also enable the further use of enterprise
knowledge management which is impossible without a collection of data. Exploiting of
corporate knowledge collected from many individual sources is a business driver that should
nowadays be on the agenda of every major enterprise.
O’Brien (2000) states that the concept of cloud-based EDM is sound but there has been too
little attention to the particular tasks of the individuals which has made it difficult for them to
incorporate these systems in their everyday work. After O’Brien’s work in 2000, there have
been a lot of developments and new applications in the field of EDM, but his findings still
68
Conclusions
prevail today. There has to be significant attention to the actual needs of the users and
research inside the companies on how do the users actually want to use the documents.
Therefore I feel that the approach of eliciting the requirements straight from the users, as
done in this thesis, is the correct way of developing an EDMS.
Even it is obvious that benefits of EDMS are numerous and significant, the systems can be
very costly and the implementation can be complex. Traditionally the EDMS’s return-oninvestment has been high (Volarevic et al. 2000) but the benefits of a new system depend
greatly on the starting point, whether the company has a legacy EDMS or not, and also of the
industry and the size of the company. As mentioned, SMEs will very likely manage with
hierarchical network drives or with free cloud-based storages like the ones offered by
Dropbox and Google.
The costs of EDM system have to be compared with the potential benefits, as with any other
investment. EDM systems used in the construction industry are usually developed by third
parties and sold as services, provided by the supplier, rather than as licences (Björk 2006).
Even though this thesis does not address the costs or different pricing policies, they are not to
be underestimated or overlooked as decisive point in EDM system selection. Nowadays many
companies are offering free cloud storage space and document storage and sharing platforms
for smaller companies can be bought as a service for next to nothing. Keeping this in mind, a
company with simple documentation needs should not go for an overkill solution, but in case
of KONE and other similar large enterprises, the documentation needs are too complex and
include so many users and user roles that they cannot be countered with a nuts-and-bolts
solution.
The more configurable the system is, the less ready-to-use it is (Lech 2012). The large EDM
systems out there have thousands of configurable parameters that allow each company to setup the system to match their specific needs. The configuration will take time and mapping the
metadata attributes the company will use in its documentation will take time. Asprey and
Middleton (2003, 286) recommend process flow charts to determine the logical integrations
to other horizontal business applications. The flow charts make it easier to conceptualize the
customization needed between these different systems and how do they communicate with
each other.
Kotonya and Sommerville (1998, 81) say that it is impossible to produce a system that would
completely satisfy all the stakeholders. It does not mean of course that the goal should not be
69
Conclusions
to satisfy the stakeholders as highly as possible. Conflicts and challenges can arise and
therefore they should be prepared for rather than overlooked. As Lech (2012) mention, the
organisational needs are not stable so the system should allow also future upgradability and
support for changes. The system can also be fine-tuned after the implementation as better
ways of working surface and organizational learning of documentation practices takes place.
Lech’s (2012) study of Polish companies’ enterprise system selection suggests hiring an
external consultant with expertise on the particular subject to help with the selection of a
system. Another suggestion is to visit companies that are using the systems that have been
selected as alternatives to learn how the functionalities work in a real-life setting. The
observed company does not have to even in the same industry as long as they share the same
level of complexity in their documentation. Taking a benchmark company from another
industry can also be easier as the companies within the same industry might not be as willing
to share their practices with potential competitors.
5.3 Recommendations for further research
One part of successful document management is to build tools that support the user needs.
EDMS is such a tool and it can be very effective one when built properly to the
organization’s needs. The other fundamental part is the users of the system. As was
mentioned in this study, the sociological factors play a significant role in the success of an
EDMS and there has been some research on this. What could be further researched are the
document management practices used in companies to manage documents and how should
the enterprises guide the users to use the systems to the overall benefit of the enterprise. This
relates to the problem that the user might not see or receive any benefits from sharing
documents but it is vital for the organization. To help in this, motivating the users and tying
the document sharing to the processes of the company are important.
Leveraging knowledge from documents and managing this acquired knowledge.
User acceptance of EDM systems and behavioral challenges as mentioned by Winter and
Strauch (2004) and Björk (2006) in chapter 3.3.
70
Appendix A: Interview support questions
Appendix A: Interview support questions
a. What are the current systems that you use to manage documents?
 Local network drive? Intranet? Other?
 What kinds of documents are stored in which system?
b. What attributes are used for tracking documents?
 Equipment number? Site Address? Project name?
c. What are the situations that currently cause problems in documentation?
 Finding documents? Uploading documents? Accessibility? Collaboration?
d. How much time is currently being used in document handling and management?
 Could time and resources be saved? How much?
 How could having documents available mobile and on-the-go benefit users?
e. What are your current archiving practices for project related documents?
Appendix B: Requirement collection template
71
Appendix C: List of requirements
Appendix C: List of requirements
Menti Hig Me Lo Poi
No.
1
Class
Access
Requirement
Mobile access to users
ons
h
d
w
nts
15
15
0
0
75
10
10
0
0
50
7
6
1
0
33
6
6
0
0
30
4
2
2
0
16
Search capabilites (metadata search, text search,
2
Function
AND, OR, NOT)
3
Function
Version history (last edited by whom and when)
Possible to store documents from other systems to
4
Integration EPF (IMT2, Salesforce, KTOC)
Soft deletion. Users can retrieve their own deleted
5
Function
documents, admin can retrieve all.
Possible to give access to third parties (outside of
6
Access
KONE)
6
1
3
2
16
7
Access
Read/write access outside of KONE network
3
3
0
0
15
8
Access
Access rights are role-based
3
3
0
0
15
3
3
0
0
15
Metadata should originate from Salesforce and
9
Metadata
SAP
One document can be linked to many equipment
10 Metadata
or projects
3
3
0
0
15
11 Security
Reliable backups
3
3
0
0
15
Project folder should cover all the project's
12 Structure
documents through its lifecycle
3
3
0
0
15
13 Structure
Unlimited storage space
3
3
0
0
15
Automated assembly of document binders (final
14 Function
commissioning)
3
3
0
0
15
15 Function
Email to EPF (also with mobile devices)
3
2
1
0
13
16 Function
Email from EPF (also with mobile devices)
3
2
1
0
13
4
1
2
1
12
3
1
2
0
11
Easy/Automatic
17 Archiving
18 Integration
archiving
once
project
is
completed
Possible to access documents from other software
72
Appendix C: List of requirements
(IMT2, Salesforce)
19 Access
Access rights managed by frontlines
2
2
0
0
10
20 Usability
Intuitive user interface
2
2
0
0
10
21 Function
One-click upload of documents to EPF
2
2
0
0
10
2
2
0
0
10
Possible to use on limited connectivity (Efficient
22 Usability
netcode)
Alerts per document or folder when file has been
23 Function
edited or uploaded
3
0
3
0
9
24 Metadata
Metadata fields populated automatically
3
1
1
1
9
25 Archiving
Retention period for archived documents
3
1
1
1
9
Drag-and-drop functionality for adding documents
26 Function
to EPF
2
1
1
0
8
27 Function
Possible to create hyperlinks to documents
2
0
2
0
6
28 Usability
Support for digitalizing paper documents
2
1
0
1
6
29 Content
Invoices are saved in the project folder
2
0
2
0
6
30 Structure
Possible to set a default folder structure
2
0
2
0
6
Possible to get basic reports of document usage
31 Analytics
(access, content of folders, age)
2
0
2
0
6
32 Security
Revoke user rights when no longer valid
1
1
0
0
5
33 Access
Access rights managed by existing systems
1
1
0
0
5
34 Usability
Benchmark usability (Dropbox, Gdrive)
1
1
0
0
5
35 Structure
No duplicate files
1
1
0
0
5
36 Structure
One place for all project files
1
1
0
0
5
Access to field documents (manuals, diagrams,
37 Access
codes, templates….)
1
1
0
0
5
38 Metadata
No forced metadata
1
1
0
0
5
39 Usability
Possible to edit documents with tablet
1
1
0
0
5
1
1
0
0
5
Possible to select files and folders to be available
40 Function
offline
73
41 Usability
Fast opening times for documents
1
1
0
0
5
1
1
0
0
5
Documents with financial information (tenders)
42 Access
need strict access rights
Users have access only to documents relevant in
43 Access
their work
1
1
0
0
5
44 Structure
Centralized administration of documentation
1
1
0
0
5
1
1
0
0
5
Possible to administrate the system remotely
45 Access
(outside of office)
Possible to save email correspondence as a
46 Content
document
1
1
0
0
5
47 Structure
Scalable tree structure of folders
1
1
0
0
5
Possible
to
preview
documents
before
48 Function
downloading
1
1
0
0
5
49 Access
BYOD accessibility (bring-your-own-device)
1
0
1
0
3
50 Usability
Easy to learn (1 hour training is sufficient)
1
0
1
0
3
51 Usability
Fast synchronization of documents
1
0
1
0
3
Customer communication saved on customer,
52 Content
equipment and contract level
1
0
1
0
3
53 Content
No billing information stored in the project folder
1
0
1
0
3
1
0
1
0
3
1
0
1
0
3
No internal communications stored in the project
54 Content
folder
Project folder created when contract has been
55 Structure
made
Watermarks on documents printed out of EPF (for
56 Security
confidentiality purposes)
1
0
1
0
3
57 Analytics
Advanced analytics of content and its usage
1
0
0
1
1
74
Appendix D: Business roles of the interviewees
Appendix D: Business roles of the interviewees
Role name
No. involved
Process Specialist (Customer and Fulfill process)
9
Business Development Manager
8
Installation Development Manager
3
Quality Manager
2
Technical Manager
2
Change Manager
2
Business Process Change Manager
1
Installation Project Manager
1
Engineering Manager
1
Sales Director
1
Production Director
1
Sourcing Director
1
Maintenance Director
1
Major Projects Director
1
Legal Counsel
1
Installation and Order Admin
1
Feedback coordinator
1
Local EDM Application Specialist
1
Document Management Key User
1
75
References
References
Books and reports
Author(s) name, printing year, title of the book, publisher, printing location, and number of
pages:
Asprey, L. & Middleton, M. (2003) Integrative Document and Content Management:
Strategies for Exploiting Enterprise Knowledge, Idea Group Publishing, 526 pages
Hull, E., Jackson, K. & Dick, J. (2011) Requirements Engineering, Springer London, 198
pages
Kotonya, G. & Sommerville, I. (1998) Requirements Engineering: Processes and Techniques,
Wiley and Sons, 282 pages
Robertson, S. & Robertson, J. (2006) Mastering the Requirements Process, Addison-Wesley,
560 pages
Sommerville, I. & Sawyer, P. (1997) Requirements Engineering: A Good Practice Guide,
Wiley and Sons, 391 pages
Articles
Author(s), year of print, title of the article, name of the journal, volume and number of the
journal, time (e.g. Summer, Fall), and page numbers:
Björk, B.-C. (2006) “Electronic document management in temporary project organisations”,
Online Information Review, Vol. 30, No. 6, pp. 644-655.
Bäckblom, M., Ruohtula, A. & Björk, B.-C. (2003) “Use of Document Management Systems
- A Case Study of the Finnish Construction Industry”, Journal of Information
Technology in Construction, Vol.8, pp. 367-380.
Chen, H., Chiang, R.H.L, & Storey V.C. (2012) “Business Intelligence and Analytics: From
Big Data to Big Impact”, MIS Quarterly, Vol. 36, No. 4, pp. 1165-1188.
Coughlan, J. & Macredie, R.D. (2002) “Effective Communication in Requirements
Elicitation: A Comparison of Methodologies”, Requirements Engineering, Vol. 7, No.
2, pp. 47-60.
76
References
Dourish, P., Edwards, W.K., LaMarca, A., Lamping, J., Petersen, K., Salisbury, M., Teery,
D. B. & Thornton, J. (2000) “Extending Document Management Systems with UserSpecific Active Properties”, ACM Transactions on Information Systems, Vol. 18, No. 2,
pp. 140-170.
Gabrielaitis, L., Bausys, R. (2009) “Management of Project Properties in "Virtual Archive"
for Building Design Industry”, Engineering Economics, Vol. 64 No. 4, pp.15-23.
Hjelt, M. & Björk, B.-C. (2006) “Experiences of EDM Usage in Construction Projects”,
Journal of Information Technology in Construction, Vol. 11, Pp. 113-125
Johnston, G.P. & Bowen, D.V. (2005) “The benefits of electronic records management
systems: A general review of published and some unpublished cases”, Records
Management Journal, Vol. 15, No. 3, pp. 131-140.
Kao, C.H. & Liu, S.T. (2013) “Development of a Document Management System for Private
Cloud Environment”, Procedia – Social and Behavioral Sciences, Vol. 73, pp. 424429.
Lech, P. (2012) “Information Gathering During Enterprise System Selection: Insight From
Practice”, Industrial Management and Data Systems, Vol. 112, No. 6, pp. 964-981.
Maguire, R. (2005) “Lessons learned from implementing an electronic records management
system”, Records Management Journal, Vol. 15, No. 3, pp. 150-157.
Malhotra, Y. (2005) “Integrating knowledge management technologies in organizational
business processes: getting real time enterprises to deliver real business performance”,
Journal of Knowledge Management, Vol. 9, No. 1, pp. 7-28.
O’Brien, W.J. (2000) “Implementation Issues in Project Web Sites: A Practioner’s
Viewpoint”, Journal of Management in Engineering, Vol. 16, No. 3, pp. 34-39.
Pan, J. & Anumba, C.J. (2008) “Semantic-Discovery of Construction Project Files”,
Tsinghua Science and Technology, Vol. 13, No. S1, pp. 305-310.
Sprague, R.H. Jr. (1995) “Electronic Document Management: Challenges and Opportunities
for Information Systems Managers”, MIS Quarterly, Vol.19, No. 1, pp. 29-49.
Conference proceedings, reports, and parts of collections
Author(s), year of print, title of the article/chapter/paper, ”in” author(s) name, printing year,
title of the collection, publisher, location, and page numbers:
77
References
Alberto, K.G., Abella, C.M., Sicat, M.G.C.E, Niguidula, J.D. & Caballero, J.M. (2009)
“Compiling Remote Files: Redefining Electronic Document Management System
Infastructure (CReED)”, Proceedings of the International Conference on Information
and Multimedia Technology, 2009 (ICIMT '09), IEEE, pp. 347-350.
Davis, A., Dieste, O., Hickey A., Juristo, N. & Moreno A.M. (2006) “Effectiveness of
Requirements Elicitation Techniques: Empirical Results Derived from a Systematic
Review”, Proceedings of the 14th IEEE International Requirements Engineering
Conference (RE'06), IEEE, pp. 179-188.
Eason, K. (1989) “Tools for Participation: How Managers and Users Can Influence Design”,
in Knight, K. (ed.) Participation in Systems Development, Kogan Page, pp. 94-105.
Gartner (2014) “Magic Quadrant for Enterprise Content Management”, Gartner Inc., pp. 138.
Ginsburg, M. (2000) “Intranet Document Management Systems as Knowledge Ecologies”,
Proceedings of the 33rd Hawaii International Conference on System Sciences, IEEE,
pp. 1-10.
Hawking, D., Bailey, P. & Craswell, N. (2000) “Efficient and Flexible Search Using Text and
Metadata”, CSIRO Mathematical and Information Sciences Technical Report 2000/83
Hickey, A.M. & Davis, A.M. (2003) “Requirements Elicitation and Elicitation Technique
Selection: A Model for Two Knowledge-Intensive Software Development Processes”,
Proceedings of the 36th Hawaii International Conference on System Sciences
(HICSS’03)
Jiang, L., Eberlein, A. & Behrouz, F.H. (2005) “Combining Requirements Engineering
Techniques –Theory and Case Study”, Proceedings of the 12th IEEE International
Conference and Workshops on the Engineering of Computer-Based Systems
(ECBS’05), IEEE
Macaulay, L. (1996), “Requirements for Requirement Engineering Techniques”, IEEE
Proceedings of ICRE 1996, IEEE, pp. 157-164.
Mead, N. R. (2013) “A History of the International Requirements Engineering Conference”,
21st IEEE International Requirements Engineering Conference (RE), IEEE, pp. 215221.
78
References
Sumalatha, M.R., Pugazhendi, E. & Archana, D.J. (2013) “Concept Based Document
Management in Cloud Storage”, International Conference on Recent Trends in
Information Technology 2013, pp. 90-96.
Tsadimas, A., Nikolaidou, M. & Anagnostopoulos, D. (2009) “Handling Non-functional
Requirements in Information System Architecture Design”, Proceedings of the 4th
International Conference on Software Engineering Advances (ICSEA ’09), IEEE, pp.
59-64.
Volarevic, M., Strasberger, V. & Paćelat, E. (2000) “A Philosophy of the Electronic
Document Management”, 22nd Int. Conf. information Technology Interfaces ITI 2000,
IEEE, pp. 141-146
Weers, M. & Vrancken, J. (2010) “Information Retrieval and Document Management in the
early phases of Urban Development Projects”, Proceedings Of The International
Conference On Information Management And Evaluation, pp. 439-448.
Winter, R. & Strauch, B. (2004) “Information Requirements Engineering for Data Warehouse
Systems”, Proceedings of the 2004 ACM symposium on Applied Computing, ACM, pp.
1359-1365.
Zowghi, D. & Coulin, C. (2005) “Engineering and Managing Software Requirements”, in
Aurum, A. & Wohlin, C. (eds.) Engineering and Managing Software Requirements,
Springer Verlag, pp. 19-46.
Interviews
Name of the interviewee, job, company, place and time
Doe John, Director, Company XYZ, Espoo, 12.10.2001.
Internet-references
KONE (2014) KONE Financial Statements 2014. Available at:
http://cdn.kone.com/www.kone.com/en/Images/KONE-Financial-statements2014.pdf?v=3 ,[29.7.2015]
79