Business Process Support in the Context of Records Management
João Pires, André Vasconcelos and José Borbinha
INESC-ID, Instituto Superior Técnico, Avenida Rovisco Pais 1, Lisbon, Portugal
Keywords: Records Management, Business Process Management, Records, Workflow, Enterprise Service Bus, REST
API.
Abstract: For an organization to achieve benefits from records management, it needs to include several practices such
as the implementation of a records management system in alignment with the organization's reality and
business processes. The focus of this work is on framing records management in business process
management by identifying the role that records management plays in business. This research is applied in
the replacement of a records management system workflow module. This research proposes the replacement
of the workflow module by a flexible and open source solution, composed by an enterprise service bus and
two workflow engines, accessed through a single API. The solution proves to be a flexible and scalable
solution to the workflow module and that can even be used by more systems than records management
systems. The implementation of records management in organizations is analysed, including the alignment
between business processes, records management and workflows. This research shows that records
management acts as an essential component to business that supports business processes and all the phases of
their management, allowing for improvement regarding the storage, management and monitoring of records
while also optimizing the execution of business activities.
1 INTRODUCTION
Records are “information created, received and
maintained as evidence and as an asset by an
organization or person, in pursuit of legal obligations
or in the transaction of business” (ISO 2016). Records
management is therefore how an organization stores,
manages and monitors its records. Records
management is usually required for legal compliance,
but when properly aligned with the business, the best
practices of records management also allow the
adding of value for the organizations, by maximizing
the value of the information. On other words, the
management and preservation of records according to
the requirements of the organization and its
regulatory context can be a new capability to increase
business efficiency and reduce costs of storage and
search of information.
The correct application of records management to
an organization comprises a set of practices to be
applied, such as a previous analysis of the records
management desired and most fit to the business,
elaboration of classification tables and other more
advanced practices like the implementation of system
that have processes regarding records management:
the records management systems.
1.1 Problem
Although the application of records management to
organizations can bring several benefits, an
inefficient development of a records management
system or implementation of records management
can bring additional processes for the business,
mainly regarding business process efficiency and
optimization.
While the development and implementation of a
records management system can be essential for the
application of records management, it is not the only
practice of records management needed and should
have in mind the organization where it is going to be
implemented and the other records management
practices.
Therefore, the main problem proposed in this
research is the framing of records management in
business process management, which is expected to
allow to identify the role of records management
relating to this methodology applied to the business
processes used in organizations. Having identified the
Pires, J., Vasconcelos, A. and Borbinha, J.
Business Process Support in the Context of Records Management.
DOI: 10.5220/0007354000250035
In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 25-35
ISBN: 978-989-758-372-8
Copyright
c
 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
25

role that records management plays in business,
because it is a part of the application of records
management, the way to develop and implement a
records management system with the interaction with
business process in mind will allow for additional
benefits for organizations, namely more efficiency in
records management and business processes
management.
1.2 Goals
As referred in the previous section, the main goal of
this work is the framing of records management
regarding business process management. For this
framing to be possible, there must be an identification
to the benefits that come from an optimal interaction
between records management and business, mainly
business processes.
This framing includes the development of a
records management system, through the
identification of requirements, system components
and interaction with other systems. To allow the
automatization of tasks regarding records
management, in the development of a records
management, this research will develop a workflow
module inside of a specific system. This paper
proposes a solution to the back end of the workflow
module in a records management system.
After the development of a records management
system, this paper discusses solutions to implement a
records management system in an organization,
including the identification of several issues that
prevent optimal implementations and
implementations that end up causing inefficiencies
regarding the organization’s business processes and
desired records management. In this research the role
records management plays regarding other business
components, mainly business processes, is identified,
allowing for the correct framing of records
management regarding business process
management.
1.3 Document Organization
After the introduction to the problem and to the
concept of records management and the benefits that
come to an organization form applying it properly, in
Section 2, the topics of business process management,
records management, workflow and integration of
systems are detailed, including existing work done
one these topics. In Section 3, there is an analysis of
the problem at hand, regarding the development of a
records management system, GfiDoc, with a big
focus on the replacement of its workflow module,
which previous solution included several problems,
In Section 4 the solution to address the problems
identified in Section 3 is presented through the
proposed architecture, functionalities, message
behaviour and finally through the development made
to the new back end to GfiDoc’s workflow module,
that was given the name of business layer. To identify
benefits of the use of the proposed business layer,
evaluate its functionality and consider if the problems
presented were solved, in Section 5 there is the
development of a prototype to which tests were made,
and the analysis of the results regarding the business
layer are mentioned. In Section 6, the implementation
of a records management system is discussed,
regarding issues and wrong implementations, to
define an optimal solution that has in mind an
organization’s business processes, including the
framing of records management regarding business
process management. Finally, in Section 7, the main
conclusions of the work are referred along with future
work that is advised to be done.
2 RELATED WORK
2.1 Business Process Management
The Object Management Group (2017) defines
Business process management (BPM) as “a method
of efficiently aligning an organization with the wants
and needs of clients”. Dumas et al. (2013) defines a
business process as “a chain related events, activities
and decisions that lead to a raise of value to an
organization or for its clients. One or more actors
participate in these processes and they also possess
resources and artefacts associated”.
Dumas et al. (2013) refers to BPM as a continuous
cycle of improvement, with the following phases:
 Process identification: development of an
organization’s process architecture;
 Process discovery: processes are documented
as one or more models (As-is model);
 Process analysis: each process is evaluated
regarding problem identification and impact
and effort to solve each problem;
 Process redesign: changes are made to
processes and result in a new process model
(To-be model);
 Process implementation: processes are
implemented, regarding changes in the
organization’s culture and technology to
support new processes;
 Process monitoring and controlling: data
gathering from the execution of processes is
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
26

used to identify new problems, giving birth to
a new iteration of the cycle.
To model business processes, the most important
notation used is the Business process modelling
notation (BPMN), being an easy to use graphical
modelling notation, which produces easy to
understand processes (OMG 2013). Along with this
notation, that are also other notations that
complement the use of BPMN, such as Case
management modelling notation (CMMN), which
supports case management, Decision modelling
notation (DMMN), which provides support regarding
decision making and XPDL, which “provides a
standard mechanism for defining and executing
business processes, allowing interoperability”
(White, 2017).
2.2 Records Management
“Records management has the goal of providing
efficient and systematic control over the production,
reception, maintenance, utilization and destination of
records, including the processes to constitute and
maintain evidence and information about activities
and transactions” (DGARQ, 2011). Records
management, as referred by DGARQ (2011),
includes the application of several practices regarding
documentation, including simple ones such as
ordering and development of classification tables and
more advanced ones such as the implementation of a
records management system. Standards such as
MoReq2010, ISO 15489:2016 and ISO/PDTR 21965
are guidelines that support the development of
records management in an organization, including the
structure and processes a records management system
should possess regarding the management of
information stored.
2.2.1 Implementation of Records
Management in Organizations
APDSI (2016), identifies obstacles to the correct
implementation of a records management system in
organizations, such as lack of interoperability and
loss of business process due to focus only on
document procedures. APDSI (2016) also proposes
guidelines that would lead to a correct
implementation of records management, such as
analysis of the organization’s reality and processes,
formation of users and proper selection of
information systems that follow requirements based
on standards such as MoReq2010 but that also adjust
to the records management desired to be applied.
2.2.2 GfiDoc
“GfiDoc® is and innovative solution in total
alignment with the European standard MoReq®
(Model Requirements for the Management of
Electronic Records) and with new digital tendencies.
It ensures an integrated and complete capture, registry
and management of all document’s life cycle.
GfiDoc® is characterized by its functional richness,
simplicity and ergonomic utilization or
administration. It provides a robust integration layer,
allowing the aggregation of documental evidence
from other business applications, while also
providing workflows.” (Microsoft, 2017).
GfiDoc provides workflows through its workflow
module, that uses the system K2, mainly through its
framework SmartObjects, which allows for GfiDoc to
possess an interface managed by K2 in its workflow
module. The workflows present in GfiDoc’s
workflow module are called document-centric
workflows, which Marchetti et al. (2005) defines as
“the automation and administration of particular
document procedures”. Many records management
systems possess workflow modules, which are
workflow management systems that hold these
workflows, that possess only activities regarding the
management of records stored in the records
management systems such as GfiDoc.
2.3 Enterprise Service Bus
Zdun (2005) refers that the use of an enterprise
services bus as a mediator for communicating
applications, on top of SOA, allows these to
communicate by using adaptors regardless of the
communication protocols supported, because of the
capabilities over messages that an enterprise service
bus possesses. In this way, applications that only
support REST protocols (being the most used
nowadays), such as HTTP, can communicate with an
application that only supports SOAP protocols, due to
the utilization of an enterprise service bus, that
mediates the messages. An example of an enterprise
service bus is WSO2 Enterprise Integrator, an open
source solution, which possesses an enterprise service
bus as a main component, illustrated in Figure 1, but
also possesses other profiles to better the integration
experience, such as a Message broker profile that
provides queueing and message storage capabilities
to the enterprise service bus profile.
Business Process Support in the Context of Records Management
27

Figure 1: Enterprise service bus profile architecture of
WSO2 Enterprise Integrator (WSO2, 2018).
3 PROBLEM ANALYSIS
Records management and business processes act as
important components for business efficiency.
Therefore, there needs to be a definition of how a
records management system, as part of the
application of records management, should be
developed, regarding requirements and components,
and implemented ensuring alignment with the
organization business processes.
Having a records management system developed
and a reference for the correct implementation of this
system, we then gain insight of the role that records
management must play in business, mainly regarding
the organizations processes.
In order to frame records management in the
business process management context, this research
was applied to GfiDoc, a records management system
referred in Section 2.2.2. In this research a workflow
module was replaced that used the system K2 and its
framework, SmartObjects and presented two
problems that needed to be solved regarding the
module.
The first problem was flexibility, because the
functionality of the workflow module depends on the
use of K2, not being able to use any workflow engines
to support GfiDoc’s workflow module. This vendor
lock-in problem, that adds up to the fact of GfiDoc
not having any control over its module interface,
because, through the SmartObject, all actions are
perceived and processed by K2.
The second problem is the cost of the solution,
because the use of K2 implies the acquisition of a paid
license, increasing the price of the solution.
4 PROPOSED SOLUTION
This section proposes a solution for the replacement
of GfiDoc’s workflow module, that instead of using
the system K2 and its SmartObject to provide
workflow management capabilities to GfiDoc, will
use an enterprise service bus, which will then allow
communication with other workflow modules,
through the execution of calls to a single REST API.
The architecture for this solution, named business
layer, illustrated in Figure 2, is composed of an
enterprise service bus, that will receive messages and
transform and redirect them, as needed, to their
respective workflow engines to be processed and then
returned to GfiDoc. The enterprise service bus used
for the business layer is the enterprise service bus
profile of WSO2 Enterprise Integrator (WSO2 2018).
There will be two workflow engines considered for
the business layer, although there could be more
engines added in the future.
The usage of two workflow engines is expected to
prevent the development from following a route of
development of a point-to-point communication of
the enterprise service bus with a specific workflow
engine. The system’s engines to be considered for the
business layer are Bonita Community edition and
WSO2 Business Process Server (both are open source
systems).
Figure 2: Architecture of the proposed solution.
Regarding functionalities, the ones defined are
considered as being the essential functionalities for
the business layer to be able to support a workflow
module and to provide correctly workflow
management capabilities. The functionalities are:
 List workflows;
 Generate instance of a workflow;
 Give task to a user;
 Complete task;
 Cancel a workflow instance;
 Suspend/Active the instantiation from a
specific workflow.
Additionally, there are four more functionalities,
which consists of events that are triggered when the
following actions occur in the workflow engines:
 When a workflow instance is created;
 When a new pending task appears;
 When a task is completed;
 When a workflow instance ends;
In these four cases, the workflow engine sends a
message directly to GfiDoc notifying about the event
that occurred, along with the information related to
the workflow/task in question so that GfiDoc can
cmpGfiDoc
Workflow module
Business layer
Enterprise service
bus profile - WSO2
Enterprise
Integrator
WF_API
WSO2 Business
Process Server
REST
API
Bonita
REST
API
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
28

store the information about the event. In the case of
the other functionalities, the message is sent from
GfiDoc asking for an action to be performed to the
business layer, the message is treated by the
enterprise service bus, that transforms and redirects it
as needed, sending the message to the API of the
chosen engine, as shown in Figure 3.
Figure 3: Messages of GfiDoc with business layer.
4.1 Data Model and Interface
For GfiDoc to store information regarding workflows
and tasks, the data model had to be changed to
guarantee these capabilities. As shown in Figure 4,
two new entities were added to the existing data
model: Workflow and Task. By adding these entities
two entities GfiDoc can now store metadata regarding
workflows and tasks, through the attributes present in
each entity.
Figure 4: Entities added to the data model (with thicker and
red border) and their relations.
Being able to store information essential for the
workflow module, a user interface was also
developed in GfiDoc. This interface, completely
controlled by GfiDoc, is not dependent of any other
system like the last one, that belonged to K2. This
interface is shown in Figure 5, that shows a list of
pending workflows to instantiate.
Figure 5: New interface showing pending workflows.
4.2 Business Layer
4.2.1 Requirements
Table 1 identifies the requirements that the business
layer needs to fulfil to support GfiDoc’s workflow
module, identified by GfiDoc’s development team.
These requirements were referred by GfiDoc’s clients
as main problems that needed to be solved regarding
the former workflow module, that used K2, and
therefore need to be fulfilled with the use of the
business layer. The comparison, in Table 2, of the
requirements and the technologies that allow to
perform them, show that, using the business layer, all
requirements are fulfilled. Even though neither one of
the two engines used can fulfil requirements 3 and 4,
the enterprise service bus introduces capabilities that
fulfil them and show the business layer can support
GfiDoc’s workflow engine.
Table 1: Detailed requirements of the business layer.
Requirement Description
Req. 1 Allow the modelling of workflows
using tools compatible with the
notation BPMN 2.0.
Req. 2 Process workflow autonomously and
deliver results to GfiDoc.
Req. 3 Present the state of a workflow
graphically.
Req. 4 Maintain independence of specific
workflow engine
Req. 5 Allow the use of more than one
workflow engine simultaneously.
4.2.2 Enterprise Service Bus Profile of
WSO2 Enterprise Integrator
According to the functionalities defined for the business
layer, a service was defined, resulting in the development
of a REST API that would be the API that will receive
messages
from GfiDoc. In the API there are the resources
classDomainModel
Aggregation
Record
Workflow
Task
0..*
0..1
0..*
0..1
0..*0..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..1
Business Process Support in the Context of Records Management
29

Table 2: Detailed Requirements of the Business Layer.
Requirement Bonita WSO2
Business
Process
Server
Business
Layer (ESB
and engines)
Req. 1 Yes Yes Yes
Req. 2 Yes Yes Yes
Req. 3 No Yes Yes
Req. 4 No No Yes
Req. 5 No No Yes
workflow and task, to better explain where each
functionality will be applied. For example, for the actions
“Give task to a user”, “Complete task” and
“
Suspend/Active the instantiation from a specific
workflow”, the services are accessible through the
URL http://<Host><Port>/bpmn/task, the HTTP
method POST, the header “software” indicating the
engine desired (with value “bonita” or ”wso2_bps”)
and with a field, in the body, named “action” that has
the value of “claim”, “complete” and
“suspend/activate”, respectively. For a service to be
applied on the workflow resource, for example the
action “Cancel a workflow instance”, the URL is
http://<Host><Port>/bpmn/task.
The integration flows in the enterprise service bus,
that indicate the steps through which the message
goes through until it is sent to a workflow engine,
were develop using the tool WSO2 Developer Studio,
that allows a graphical modelling of the integration
flows, that are translated in run time to an XML that
describes the API. For each functionality of the first
six for the business layer, an integration flow was
developed, given that the other four, regarding events,
are done by each of the workflow engines. In each
integration flow, the redirection to the desired
workflow engines is enabled by a mediator called
switch mediator, that chooses a path of the flow to
take depending on the value of the header that
chooses the workflow engine. Figure 6 shows the
integration flow for the functionality “Generate
instance of a workflow”, where there are three
branches because, regarding whether a workflow
needs variables or not to be instantiated, the message
format differs.
4.2.3 Bonita
We use Bonita as a workflow engine, in the business
layer, since its REST API can already receive
messages from the enterprise service bus used.
The first workflow modelled in the workflow
engines is a simple workflow, composed of two
events, a start event and an end event, and one task
named “Send message” that receives two variables
“remetent” and “message”. This ad-hoc workflow is
meant to simulate the sending of a message to a
certain user and is modelled in BPMN 2.0.
Figure 6: Integration flow for the instantiation of a
workflow.
For the sending of messages, since the use of
listeners and events are not available in the open
source version of Bonita (Community edition), a
connector called REST connector was used, that
allows, for each of the 4 events defined, the sending
of a REST message to a URL, being this URL
specified as the one to GfiDoc. The message to send,
for each event of each task/workflow, is written in
Groovy.
4.2.4 WSO2 Business Process Server
Following the same development as in Bonita, a
workflow identical to the ad-hoc workflow modelled
in Bonita was modelled to be uploaded to the WSO2
Business Process Server, by creating an Activiti
project with the workflow in BPMN 2.0, as shown in
Figure 7. Since, in this case, we can use listeners and
events, written in Java, these just have to be
associated with the workflow and its task, associating
a different event to each of the four events, because
the data sent to GfiDoc in the case of each of the four
events differs from one another. In Figure 7, besides
the workflow modelled, there are also represented the
associations for the two events regarding workflows,
where we associate the event “start” for the event of
when a workflow instance is created and “end” for
when a workflow instance ends.
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
30

Figure 7: Ad-hoc workflow modelled, and workflow events
associated.
5 DEMONSTRATION AND
RESULTS
To evaluate the business layer developed, we first
assess its integration with GfiDoc’s workflow
module. We first demonstrate if the business layer is
scalable solution that can handle several messages
from users simultaneously, then we validate if the
business layer supports the back end of a workflow
module in a records management system. After
guaranteeing the business layer as a valid solution, we
analyse if the problems identified in Section 3 are
solved with the use of this solution, while also
referring additional benefits that can come from the
use of the business layer for other purposes than the
one referred.
A prototype was developed to evaluate if the
business layer can act as a back end for GfiDoc’s
workflow module. As illustrated in Figure 8, the
prototype uses a HTTP server to receive messages
from the engines in the business layer regarding
events and uses a REST client, Postman, to send
messages to the business layer REST API (WF_API).
Figure 8: Architecture of the prototype developed.
Only WSO2 Business Process was used because
there wasn’t considered need to test both workflow
engines since the integration flows are already
developed.
The test of the prototype was developed according
to Ferme et al. (2015), by sending simultaneous
messages to simulate an increasing number of
simultaneous users and calculating the throughput
value for each set of messages sent and processed by
the engine of the business layer. By comparing the
throughput obtained and its growing rate, these shows
if the system is a good workflow management system
compatible with the notation BPMN 2.0. The
message chosen to be the same sent in all messages is
for the instantiation of a workflow, given it requires
quite a bit of processing from the system. The
sequence of messages that will happen for each
message sent in the test is the same as the one
illustrated in Figure 9.
Figure 9: Sequence of each message performed in the test.
As a comparing measure, the tests performed on
the business layer were also performed with a point
to point communication between the REST client
(Postman) and WSO2 Business Process Server.
Regarding to Figure 9, the only difference in this case
is that messages, instead of being treated by the
enterprise service bus, go directly to WSO2 Business
Process Server. This way not only the functionality of
the business layer is evaluated, but also if the use of
the enterprise service bus as a mediator of the
messages is beneficial or not to support the business
layer and GfiDoc.
5.1 Results
5.1.1 Throughput
The results of the tests performed using Jmeter are
illustrated in Figure 10, which shows that the business
layer is an acceptable workflow management system
and can support GfiDoc’s workflow module. Also,
cmpProtótipo
GfiDocrepla ce me nts
Postman(RESTclient)
HTTPserver
ESBprofileofWSO2
EnterpriseIntegrator
WF_API
WSO2Business
ProcessServer
APIRES T
Business Process Support in the Context of Records Management
31

the use of an enterprise service bus is beneficial and
guarantees a scalable solution. The throughput values
obtained show that, when using an enterprise service
bus, the throughput values are always higher than
when there is a point-to-point communication with
the workflow engine.
The values shown regarding throughput could be
even greater if more profiles of WSO2 Enterprise
Integrator would be used, given that the queueing
capabilities are much greater when also using the
Message broker profile. Also, the API and integration
flows developed lack optimizations regarding
performance, given that they intend to show most of
all the functionality of the business layer.
Adding to these results, latency was tested, which
results are shown in Figure 11, showing that the
messages processed with the help of the enterprise
service bus are in average faster than in the other test
case, that proves the use of the business layer for
GfiDoc’s workflow module.
Figure 10: Values of throughput for the test cases of using
an enterprise service bus (blue) and only using and
workflow engine (red).
Figure 11: Values of latency for the test cases of using an
enterprise service bus (blue) and only using and workflow
engine (red).
5.1.2 Price
Since the business layer is, for now, only composed
of open source systems, the use of this system
comparing to the use of a proprietary system like K2
presents less costs. Therefore, cost wise, the use of the
business layer in GfiDoc’s workflow module presents
a cheaper solution than its predecessor.
Regarding the cost of development, the business
layer possesses a high development time to
implement a workflow module, given the low amount
and quality of support that exists regarding open
source technology, relying mostly on user forums or
on paid support packages, that still are cheaper than
the acquisition of most proprietary systems such as
K2.
Furthermore, because the business layer is
composed of open source systems, according to Das
et al. (2010), it also possesses the following benefits:
 “Test before buying”;
 “Lower cost to start”;
 “More simplistic and easier to understand”;
 “No mishmash”;
 “Availability of the source code and the
right to modify it”;
 “Right to redistribute modifications and
improvements to the code”.
Additionally, given that many cloud services
vendors charge based on CPU usage, the use of the
enterprise service bus profile of WSO2 Enterprise
Integrator, which is an XML that describes all the API
and can be uploaded to the server, is a lightweight
solution to deploy in the cloud.
5.1.3 Flexibility
Regarding the problem referred in Section 3 about the
use of K2 preventing other workflow engines from
being used, the business layer does not suffer from
this problem, allowing several workflow engines to
be implemented in the layer and to even be used
simultaneously.
To add another workflow engine to the business
layer, the integration flow, after analysis of the
engine’s available functionalities and REST API,
needs to be developed and all endpoints needed
added. Additionally, in the workflow engine, there
needs to be a way to send messages to GfiDoc in the
referred events, whether by using listeners like in
WSO2 Business Process Server or a REST connector
like in Bonita. Having done this, with the adding of
another possible value for the header of the message
for the selection of this workflow engine, it can be
used by GfiDoc’s workflow module.
5.1.4 Main Contributions
Through the proposal and development of the
business layer, the workflow module of GfiDoc is
33,8
43,9
34,6
38,4
36,8
51,8
59
14
12,6
18,8
19,9
21,3
22,8
26,9
0
20
40
60
80
5 25 50 75 100 125 150
Throughput (#messages/ms)
#Messages sent simultaneously
132
450
1140
1432
1612
1676
1527
306
1765
2058
2945
3297
3903
4356
0
1000
2000
3000
4000
5000
5 25 50 75 100 125 150
Latency (ms)
#Messages sent simultaneously
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
32

now a more flexible and cheaper solution. The
development of an open source solution that allows
the communication with several workflows’ engines
and the use of their capabilities through a single
REST API, being also a scalable and lightweight
solution is an attractive solution for a back end of a
workflow module. Using a workflow module in a
records management system, task regarding records
management are automatized, since it reduces the
change of human error in records processing.
The simultaneous use of several workflow
engines is not advised, but can be useful in
exceptional cases, such as when a migration of
processes from an engine to another occurs.
By using a records management system aligned
with an organization’s business processes and culture,
the usage of documents and the efficiency of business
activities are optimized. This also allows the
automatic generation of records to act as evidence for
the execution of these activities, having in mind that
the perseverance and management of all records
stored, according to records management standards
such as MoReq2010 are guaranteed.
6 DISCUSSION
In this section we analyse how a records management
system, such as GfiDoc, and the workflow module
developed in Section 4 should be implemented in an
organization.
Since organization’s activities have as main focus
the business and the generation of value, the focus on
records of the records management systems show that
these cannot be a central platform for a business.
Instead, records management systems, along with
other practices of records management must act as
support for the business, mainly for the business
processes. These business processes are orchestrator
of activities, that have the objective of producing
value for the organization and the records
management systems need to be able to generate
records that prove these executions and support
activities that utilize records stored in the system.
Does this mean that workflows are not necessary?
Ruh and Gold-Bernstein (2014) refers that workflow
are meant to automatize only manual tasks and
business processes are composed of manual tasks and
service calls to other systems, like workflow
management systems. Furthermore, Ruh and Gold-
Bernstein (2014) also refer that workflow
management focus on the optimization of processes,
while business process management focus on a
continuous improvement lifecycle. Therefore, to
perform complex calls, made by business processes,
to certain systems such as records management
systems, workflow modules can be used to
automatize these workflows whose focus is more of
the area of the system at hand, having in mind that
there should not be a loss of the business context at
any time.
This way, the implementation of records
management in an organization needs to be aligned
with the existing business processes and how these
are managed, while also having in mind the culture
and reality of the organization, for optimal benefits to
be achieved.
6.1 Obstacles to the Implementation of
Records Management
Although the benefits of the application of records
management in organizations, that include the
implementation of a records management system
such as GfiDoc, according to APDSI (2016), only
74% of organizations interviewed in Portugal possess
records management systems implemented, and not
all possess integration with business processes. In
order to analyse why records management systems
are not implemented in every organization, along
with their workflow modules such as the one
developed in Section 4, which introduces an open
source and flexible solution to increase business
efficiency, the main obstacles identified that lead to
an incorrect or inexistent integration of records
management and business process management are
described in the following subsections.
6.1.1 Wrong Idea of Records Management
Records management and its benefits are not totally
acknowledged by organizations; the benefits of the
management of information are but the ones
regarding the increase of business efficiency when
integrated with the business are not. Also, records
management is not only about acquiring a records
management system, because it requires other
practices to be applied such as the development of
classification tables, control access lists and analysis
of the business processes. By only implementing a
records management system and not integrating with
any other systems and practices because they are not
seen as essential components to the business, some
organizations undervalue records management,
seeing it as a cost to comply with regulations and not
as an investment to achieve benefits for the business.
Using the architecture proposed in this paper, the
organization can possess a records management
Business Process Support in the Context of Records Management
33

system with a set of workflows that increase the
efficiency of the business and benefits from applying
records management. As shown in Section 5, the
business layer supports the workflow module and can
provide an increase in efficiency for the
organization’s business.
6.1.2 Business Process with Low Maturity
In a public administration organization in Lisbon,
Portugal, the records management system is used as a
main platform and is not integrated with its business
processes because these do not present a maturity
level high enough to support be business, leading to a
greater focus of records management and loss of
context in the business when executing workflows.
Having acknowledge this, the organization has not
been able to optimize its business process due to a
strong resistance to change, which along with the
limited interoperability that its records management
system possesses with other systems, to a greater use
of paper documents.
Although an understandable situation, it can never
be a good solution, rather it must be seen as a
temporary solution, until the business process can be
optimized and managed and a better records
management can be applied.
Regardless of the benefits that can come from
implementing a records management system such as
GfiDoc, with a workflow module that introduces
flexibility and cost reduction to an organization, if the
business processes cannot support records
management practices, there are going to be
inefficiencies. The organization will still benefit from
using the records management system, which will
store its documents and increase the automation of
workflows, but optimal benefits from aligning these
with business processes cannot be achieved.
Additionally, there is the danger of loss of business
context and incorrect modelling of the workflows,
given that most of the workflows in the workflow
module are modelled by the organization and these
workflows can present the same problem that for the
business processes, which is a low maturity level, that
leads to an inefficient records management performed
by the records management system.
6.2 Framing Records Management
Having in mind that records management is a
business component that supports an organization’s
business processes, these processes need to be
adjusted to the desired records management,
implying the identification of problems and new
modelling of business processes by an organization.
These processes, according to the business process
management cycle referred in Section 2.1, are
executed and data is gathered from this execution to
identify possible improvements to the processes.
Furthermore, ISO (2016) refers that, when
defining the architecture of an organization, records
management as to be accounted for.
This way, we conclude that records management
is present in all phases of the business process
management lifecycle, as a support business rather
than an independent area of an organization’s
business.
7 CONCLUSIONS AND FUTURE
WORK
Records management, when applied in alignment
with an organization’s business processes and reality,
can bring great benefits regarding the management of
its information and regarding the increase of business
efficiency. Also, the correct application of records
management includes the implementation of several
practices rather than simply developing and
implementing a records management system.
By defining the requirements and components of
a records management system that is based on the
standard MoReq2010, a workflow module of GfiDoc
was replaced by an open source, scalable and flexible
solution, called business layer. This layer acts as the
back end for GfiDoc’s workflow module and allows
it to communicate to several workflow engines
through a single REST API, but also other systems
through the sending of messages to one or more
workflow engines that belong to the business layer
developed.
Finally, the correct way to implement records
management system was defined, and problems that
prevent this implementation were identified and
analysed, resulting in the identification of the role
records management plays in the organization,
leading to the framing of records management in
business process management. This framing resulted
in the conclusion that records management is present
in every phase of business process management and
therefore in every stage of the business, by optimizing
the usage of records and the generation of records that
act as evidence for the actions done in the business.
Regarding future work, GfiDoc’s workflow
module still needs to fully be developed, by adding
services in GfiDoc to communicate with the business
layer. Regarding the business layer, the API and the
business layer needs optimizations focused on
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
34

increasing the performance of the solutions. Also,
case management could be added to improve the
flexibility of the solution, and the enterprise service
bus of the business layer can also possess integration
flows for more systems, rather than only workflow
engines.
ACKNOWLEDGEMENTS
The authors express their gratitude to Gfi Portugal,
mainly João Portugal and Anquetil Neves for all the
help and for the opportunity provided in making the
research for this paper.
This work was supported by national funds
through Fundação para a Ciência e a Tecnologia
(FCT) with reference UID/CEC/50021/2019 and by
the European Commission program H2020 under the
grant agreement 822404 (project QualiChain).
REFERENCES
Associação para a Promoção e Desenvolvimento da
Sociedade da Informação (APDSI) (2016). O Estado da
Arte na Gestão Documental em Portugal (State of art of
Records management in Portugal). Lisbon.
Das, R., Patra, M., Misro, A. (2010). OPEN SOURCE SOA
FOR E-GOVERNANCE. 7th International Conference
on E-Governance ICEG 2010: Indian Institute of
Management, Bangalore (IIMB).
Direção-Geral de Arquivos (DGARQ) (2011).
Recomendações para a produção de: Planos de
Preservação Digital (Recommendations for the
production of: Digital Preservation Plans). Lisbon,
November 25th, 2011.
Dumas, M., La Rosa, M., Mendling, J., & Reijers, H.
(2013). Fundamentals of Business Process
Management (1ª ed.). Berlin, Heidelberg: Springer-
Verlag.
Ferme V., Ivanchikj A., Pautasso C. (2015). A Framework
for Benchmarking BPMN 2.0 Workflow Management
Systems. Lecture Notes in Computer Science, vol 9253.
Cham, Switzerland: Springer.
International Organization for Standardization (ISO)
(2016). ISO 15489-1:2016 – Information and
Documentation – Records Management – Part 1.
International Organization for Standardization – ISO.
Microsoft. (2017). GfiDoc. Available at:
https://www.microsoft.com/pt-pt/azurebizcenter/
GfiDoc.aspx, accessed on November 15th, 2017.
Object Management Group (OMG), (2013). Business
Process Model and Notation (BPMN) (Version 2.0.2).
Needham, MA: Object Management Group.
Ruh, W., Gold-Bernstein, B. (2004). Enterprise Integration:
The Essential Guide to Integration Solutions. Boston,
MA: Addison-Wesley Professional.
White, S. (2017). XPDL and BPMN. Monrovia, CA:
SeeBeyond.
WSO2 (2018). WSO2 Enterprise Integrator: Overview.
Available at: https://docs.wso2.com/display/EI630/
Overview, accessed on August 8
th
, 2018.
Zdun, U., Hentrich, C. and van der Aalst, W.M.P. (2006).
‘A Survey of Patterns for Service-Oriented
Architectures’. International Journal of Internet
Protocol Technology, Vol 1, nº 3, pp.132—143. doi:
10.1504/IJIPT.2006.009739.
Business Process Support in the Context of Records Management
35