Template-Driven Documentation for Enterprise Recruitment Best
Practices
Saleh Alamro, Huseyin Dogan, Raian Ali and Keith Phalp
Faculty of Science and Technology, Bournemouth University, U.K.
Keywords: Recruitment, Enterprise Recruitment, Enterprise Recruitment Best Practices, Enterprise Recruitment
Architecture.
Abstract: Recruitment Best Practices (RBPs) are useful when building complex Enterprise Recruitment Architectures
(ERAs). However, they have some limitations that reduce their reusability. A key limitation is the lack of
capturing and documenting recruitment problems and their solutions from an enterprise perspective. To
address this gap, a template for Enterprise Recruitment Best Practice (ERBP) documentation is defined. This
template provides a model-driven environment and incorporates all elements that must be considered for a
better documentation, sharing and reuse of ERBPs. For this purpose, we develop a precise metamodel and
five UML diagrams to describe the template of the ERBPs. This template will facilitate the identification and
selection of ERBPs and provide enterprise recruitment stakeholders with the guidelines of how to share and
reuse them. The template is produced using design science method and a detailed analysis of three case
studies. The evaluation results demonstrated that the template can contribute to a better documentation of
ERBPs.
1 INTRODUCTION
Recruitment is the practice of attracting sufficient
numbers of qualified individuals on a timely basis to
fill job vacancies within an organization (Ahamed
and Adams, 2010). It is a key strategic opportunity for
organisations to achieve a competitive advantage
over rivals (Carless and Wintle, 2007). With this
purpose in mind, organisations should seek support
from enterprise architectures, shortly EAs (Penaranda
et al., 2010; Vallejo al., 2012).
EAs rely on the integration of both a conceptual
representation and a systematic approach to build a
system (Zachman, 2008). In enterprise recruitment
architectures (ERAs), the conceptual representation
facilitates communication and coordination within
and across the enterprise entities through a better
visualisation and understanding of the enterprise
components from different perspectives. On the other
hand, a step-by-step methodology is to systematically
transform the enterprise facilitated by different
principles, methods, and tools (Gartner, 2008).
Methodologies based best practices can provide a
systematic approach when building new information
system or evolving existing ones (Molina and
Medina, 2003). Recruitment Best Practices (RBPs)
are already being shared and reused to some extent in
some organisations (Madia, 2011). However, they
have some limitations that reduce their reusability: (1)
they are fragmented and limited in scope (Simard and
Rice, 2007; Buschmann et al., 2007); and (2) they
lack proper documentation (Vesely, 2011).
With these limitations and the need of ERAs
support, we define a template for Enterprise
Recruitment Best Practice (ERBP) documentation.
The objective of ERBP template is to provide a top-
down strategy based on models for defining ERAs in
different levels of abstraction towards software
specifications. An ERBP will identify and combine a
set of existing RBPs describing an ERA that fills a job
vacancy in a specific enterprise context. To do this,
we develop a precise metamodel complemented with
five UML diagrams to describe the template of the
ERBPs.
The goal of this paper is to design and evaluate a
template for supporting the documentation and reuse
of ERBPs. The main focus is on the template
proposed to define and document the elements of
ERBPs while the methodology of reusing ERBPs is
out of the scope of this paper. The paper is structured
as follows: this section presents an introduction to the
research study. Section 2 provides a brief review of
research on BPs sharing and reuse. Section 3 presents
the research methodology followed to design and
evaluate the ERBP template. Section 4 defines the
238
Alamro, S., Dogan, H., Ali, R. and Phalp, K.
Template-Driven Documentation for Enterprise Recruitment Best Practices.
DOI: 10.5220/0007766602380248
In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 238-248
ISBN: 978-989-758-372-8
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
ERBP template and the relationship with the ERA
elements. Section 5 shows the evaluation results of
the ERBP template. Finally, Section 6 presents some
conclusions and future work.
2 BEST PRACTICES
According to Renzl et al. (2006), best practices (BPs)
are key approaches for sharing and reusing explicit
knowledge. A great deal of research on the definition
of BPs and their impact on knowledge transfer and
reuse has been conducted. In the next subsections, the
definition of BPs and the challenges that impede the
sharing and reuse of BPs in general and recruitment-
related BPs in specific are presented.
2.1 Definition of BP
BP is related to different domains and contexts, and
is therefore subject to a variety of circumstantial
definitions. Graupner et al. (2009) define BP as the
most efficient and effective way of accomplishing a
task, based on repeatable procedures that have proven
themselves over time for large numbers of people.
Investopedia (2016) defines BP as a set of guidelines
or ideas that represent the most efficient and prudent
course of actions.
2.2 Challenges in Documenting BPs
One of the key challenges in sharing and reusing BPs
is the lack of proper documentation of BPs. More
precisely, incomplete description of BPs reduce their
reusability. Regardless of the industry of BPs, some
key examples of such incomplete description are: lack
of description of the purpose of the BPs (Hanafizadeh
et al. 2009); and lack of description of the problem
domain in which BPs are ‘best’ (Alwazae, 2015).
Complete description of BPs is very crucial in their
successful application and reusing (Mansar and
Reijers, 2007; Simard and Rice, 2007).
Given the complexity of real-world practices, one
way to promote BP completeness is to model the
various attributes of a BP and establish a consistent
structure for documentation (Vesely, 2011). This will
enable a proper documentation, sharing and reuse of
BPs. However, the way how a BP is properly
modelled and structured has not been examined
extensively in the literature (Alwazae, 2015). Hence,
it is a knowledge gap for which this paper attempts to
fill by providing a new template-driven
documentation of recruitment-related BPs.
2.3 Challenges in the Scope of BPs
BPs have been criticised being limited in scope
(Simard and Rice, 2007; Madia, 2011). This implies
being intended to piecemeal and fragmented
problems, and being seen as building blocks with no
means to be combined in one meaningful entity
(Stephenson and Bandara, 2007). Given that the focus
of this paper is on enterprise recruitment, this scope
will require new ways to capture and document
enterprise recruitment best practices (ERBPs). This
points up a knowledge gap in research for which the
paper will try to address.
2.4 Challenges in the Selection of BPs
These concern the difficulties in finding and selecting
BPs in large collections, or repositories (Hanafizadeh
et al. 2009; Vesely, 2011). In this paper, the focus will
be on providing domain-independent recruitment
concepts that serve as search indices (Vesely, 2011;
Graupner et al. 2009). These indices consists of
recruitment terms that are not associated with a
specific domain. Hence, practitioners are able to find
and select ERBPs from different domains and
industries.
3 RESEARCH METHODOLOGY
The research method used is design science.
According to (Johannesson and Perjons, 2014),
design science creates new artefacts for solving
practical problems. These artefacts can be methods,
models, constructs, frameworks, prototypes or IT
systems, which are “introduced into the world to
make it different, to make it better” (Johannesson and
Perjons, 2014). The design science research process
carried out in this research included five research
activities as defined by the design science method
framework of (Johannesson and Perjons, 2014).
These activities and their application are presented
below.
3.1 Problem Explication
The first activity in the design science process is to
explicate the practical problem(s) that motivates why
the artefact(s), in our case the ERBP template needs
to be designed and developed. The practical problems
are: (1) RBPs are fragmented and limited in scope;
and (2) RBPs lack proper documentation. These
practical problems denote knowledge gaps in the
Template-Driven Documentation for Enterprise Recruitment Best Practices
239
literature which, in turn, impede sharing and reuse of
RBPs. These knowledge gaps have been discussed in
Section 2. Hence, the artefact (ERBP template) is
designed to solve these problems and fill these gaps.
3.2 Requirements Definition
The second activity in the design science process is to
define the requirements of the ERBP template. These
requirements will be used as a basis to evaluate the
resulting artefact and guide the construction process
of it in addition to any refinement steps. Based on the
literature review, the following requirements are
selected:
Requirement 1: The ERBP template shall be
comprehensive. The ERBP template shall
consist of a complete set of ERBP elements to
achieve its defined goal. According to the
research literature, the successful application of
BPs depends on their complete documentation
(Vesely, 2011).
Requirement 2: The ERBP template shall be
easy to use for sharing and reusing. Users should
be able to use the artefact to achieve a particular
goal easily. According to the research literature,
a clear documentation structure will distil
information about a BP and makes it easy to use
(Motahari-Nezhad et al. 2010).
Requirement 3: The ERBP template support both
the creation of high quality ERBPs and the
evaluation of already existing ERBPs. This
means that the ERBP template should enable
documenting of new ERBPs as well as guide the
quality assessment of already designed ERBPs.
According to research literature, a well-structured
BP template will facilitate the creation and
evaluation of BPs (Jashapara, 2011).
3.3 Design and Development
This third activity is to design and develop the artefact
that address the explicated problems and fulfils the
defined requirements, in this case design and develop
the ERBP template.
The ERBP template was developed by means of
two complementary processes: (1) addressing the
elements of ERAs that support ERBP documentation;
and (2) addressing the elements of ERBP template for
documentation. The results of these two processes
were merged together into the final ERBP template.
The ERA elements were selected from the
artefacts (POCM and Onto-RPD) designed from the
analysis of three case studies (SA enlistment, BA
enlistment (UCAS recruitment) conducted in Alamro
et al. (2018). The links between ERA elements were
also addressed. Thanks for the POCM and Onto-RPD
artefacts. However, the elements of ERBP template
were selected from the template provided by
Buschmann et al. (2007) with some important
elements added from the literature.
The elements of ERA and ERBP template were
combined together in fulfilling of the defined
requirements. The tentative draft of combination was
validated and refined in a number of refinement
phases. In each of which, one or two academic experts
were asked to evaluate and refine the ERBP template.
Purposive sampling was applied. In total, six
academic experts in the area of BPs were interviewed.
The final ERBP template is described in Section 4.
3.4 Demonstration and Evaluation
This activity is to use and assess how well the artefact
solves the practical problem based on the defined
requirements. We have evaluated the ERBP template
by conducting a focus group of recruitment-related
academic experts. The number of participants was 10
and the results are presented in Section 5.
4 ERBP TEMPLATE
The ERBP template is designed to document the key
elements of recruitment practice in an enterprise
environment. These elements are a combination of
ERA elements and the elements of a selected template
from the literature for a more comprehensive
documentation of an ERBP. The ERA elements that
must be taken into account are as follows:
Goal of recruitment: The goal of enterprise
recruitment has been clearly defined as “to fill a
vacancy”. Depending on the size and the type of
industry and organisation in which recruitment
is conducted, the number of vacancies and their
types may vary.
Problem: The problem of enterprise recruitment
reflects the potential/existing differentiation or
fragmentation between a number of recruitment
stakeholders’ interests across a number of
interest dimensions such as recruitware,
information, and timing (Alamro et al., 2018).
An enterprise recruitment problem is defined as
the problem frame (i.e. type of problem) that is
agreed on by all stakeholders as the most
problematic issue to be solved towards the goal
of recruitment.
Symptoms/Threats: There are a number of
symptoms or threats that are associated with the
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
240
enterprise recruitment problem and prevent the
goal of recruitment to be achieved. These are: no
engagement (i.e. when there is no action received
at all from the target agent); withdrawal (i.e.
when a target agent withdraw out of interaction);
and rejection (when a target agent clearly send a
rejection message to an offer). A recruitment
analyst must be aware of these symptoms/threats
and find the root causes (i.e. interest dimensions)
that lead to such actions.
Context: A major factor of successful sharing
and reuse of an ERBP is to capture the
knowledge of the business context or domain in
which a recruitment problem exists. The
business context can be recognised by a
combination of the specific recruitment problem
frame and the corresponding recruitment
solution (i.e. policies, actions, and software
specifications) to solve this type of problem
according to its goal of recruitment and
environment. It is very common that problem
owners characterise the problematic situations
as being of a known problem type or category
(Smith, 1989; Abd Rahman et al., 2011). Hence,
rather than representing and defining the current
situation as a whole, they define a problem by
matching the features of this situation to the
characteristics of well-known experienced
problems so facilitating the selection and
tailoring of recruitment policies, mechanisms,
and IT solution specifications. The environment
for ERBPs is composed of recruitment realms
(RRs) and is associated with an enterprise
overarching based on the interest levels and the
set of policies applied on each interest
dimension within these RRs. These sub-
elements will be explained in the next sections.
Stakeholders: A stakeholder can be any
individual, a group of individuals, or an
organisation with an interest or set of interests in
enterprise recruitment system. The stakeholders
of an ERBP populate the recruitment realms
(RRs) and interact with each other across
interest dimensions.
Solution: A solution in ERBP must be captured
in different levels of abstraction including
technological tools. However, information
systems such as recruitment system could
operate without the use of e-solution or simply
transform into e-space (Sharp et al., 2007;
Smalikiene and Trifonovas, 2012). Hence, the
solution in ERBP will be limited to four levels
of abstraction: Recruitment Problem Definition
(RPD), Early Requirements Definition (ERD),
Functional Requirements Definition (FRD), and
E-Recruitment Solution Specification (ERSS).
These four viewpoints of a solution were based
on the ex-MDA (Fouad et al., 2011).
The elements of the template provided by Buschmann
et al. (2007) and some new sections that we consider
necessary when integrating with the ERA elements
are described in the following texts:
Name: The name of ERBP should represent the
problem to be solved. The name must be also
unique and within the scope of this type of
ERBP.
Intent: This provides a short description of the
intended purpose of the ERBP.
Context: This section describes the generic
environment under which the ERBP should be
applied. This may include: (a) the type of
vacancies to be filled (job description and
specification); (b) the RRs involved in the
ERBP; (c) the set of stakeholders within each
RR; and (d) the general features and interactions
between RRs. This context can be specified by
context diagram.
Problem: This section describes the problematic
situation that has led to the necessity to apply the
corresponding solution, including: (a) the
threats/symptoms; (b) the forces (problem frame
and interest dimensions) that cause the problem
and guide the solution; and (c) the type of
interacting agents (whom to recruit (with))
because this will affect the recruitment
mechanisms of the solution.
Known cases: This section describes the real
cases of known recruitment incidents related to
the problem.
Solution: This section describes how the
problem is solved and how the threats associated
with filling job vacancies and forces are treated.
The solution will be expressed through the four
levels of abstractions used in the POCM-RAA:
RPD, ERD, FRD, and ERSS.
Considerations: This section describes the set of
key perceptions and impressions of all relevant
stakeholders about the solution given in the
ERBP.
Consequences: This section discusses the
benefits and drawbacks of the solution in
relation to the forces (interest dimensions) found
in the problem.
Known uses: This section describes the real
cases where the solution provided is used.
Related ERBP: This section gives references to
the ERBPs that solve similar problems, consider
similar contexts, or complement this ERBP.
Template-Driven Documentation for Enterprise Recruitment Best Practices
241
Figure 1: UML metamodel for ERBP template.
4.1 A Metamodel for ERBP Template
The ERBP template will include a wide range of
items describing an ERBP that solves an enterprise
recruitment problem in a specific context. To do this,
the ERBP template will integrate, in one cohesive
UML metamodel, both the ERA elements and all
elements of the template defined earlier. Figure 1
presents the metamodel of ERBP template that
defines the elements of ERA (shaded rectangle) and
the elements of the ERBP template (white rectangle
with *), as well as the relationships between them.
However, some of these elements are shared such as
context, problem, and solution.
In the next sections, the UML metamodel for
ERBP template will be complemented with a number
of UML diagrams to describe the details of each
element of the ERA (shaded rectangles) used in
Figure 1 to define and document the ERBPs.
4.1.1 UML Metamodel for Vacancy
When building a recruitment system, organisations
should identify their job vacancies in order to
facilitate the recruitment analyst’s work. This
identification includes the job description (i.e. all the
job-oriented information about a specific job); and the
job specification (i.e. all employee-oriented
information required to fill a job). These information
indicate the importance that those job vacancies have
for organisations and the interest record that has to be
or factors so that when classifying jobs, the
organisations should seek support from a risk analysis
methodology.
The identification of job vacancies will facilitate
the setup of cost-effective policies that constitute the
interest record necessary to fill these vacancies. For
example, the ‘location of work’ of a job vacancy will
need recruitment policies related to the quality feature
“accessibility”; the ‘tasks involved’ will need
recruitment policies related to the quality feature
“familiarity”. However, there might be vacancy
elements that need a set of recruitment policies to be
considered. Figure 2 presents the metamodel of
vacancy.
Figure 2: UML metamodel for vacancy.
4.1.2 UML Metamodel for Context
The elements included in the context of ERBPs are:
The type of enterprise recruitment addressed in an
ERBP, the recruitment realms (RRs) involved in that
type of enterprise, and the interest record associated
with those realms. Figure 3 presents a UML
metamodel of the context elements and the
relationships between them.
islocatedIn
Context*
Intent*
Vacancy
isAssociated
Solution*
Problem*
attemptsToSolve
isAssociatedWith
Threats
Known Cases*
areBased
Consequences* Known Uses*
areRelatedTo
Considerations*
Stakeholders
resultIn
isAssociatedWith
areRelatedTo
Pkg ERBP Template
isAssociatedWith
isToFill
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
242
Figure 3: UML metamodel for context.
The Enterprise Levels
The enterprise can be addressed from different
perspectives or levels. According to Graves (2009),
these levels are the organisation level, the value-chain
level, the market level, and finally the extended level
where the enterprise includes everyone. In each level,
there will be a set of recruitment realms (RRs)
involved. These RRs are explained in the next
section.
Recruitment Realms (RRs)
RRs can be defined as logical and discrete entities that
partition the enterprise network. Based on the
definition of recruitment adopted in Alamro et al.
(2018), these RRs have the same interest dimensions
and quality features through which they interact.
Therefore, a set of different recruitment policies can
be applied in each RR.
In Figure 3, there are different types of realms
(TR) that can be found in enterprise recruitment.
These RRs, based on Alamro et al. (2018), are:
Recruiter: This realm consists of a recruiter or a
group of recruiters with the same purpose.
Recruiters typically conduct recruitment
activities. This realm is composed of the
following:
Locator: The one who typically define or
find where the potential applicants are.
Announcer: The one who prepares
recruitment message and selects one or a
set of methods to announce it to the
target applicants.
Inspector: The one who screens
applicants or their applications against a
set of requirements to discover if there is
anything wrong with them.
Examiner: The one who assesses the
things such as knowledge, skills, and
abilities that have been thought to the
applicant.
Offeror: The one who selects a candidate
and extends an offer for him.
Hirer: The one who signs the recruitment
contract with an applicant.
Context
Recruitment Realms
Recruiter
Hirer
Job Provider Qualification Provider
Control Level (CL)
composedOf
Announcer
Examiner
Offeror
Fully Controlled
Inspector
Externally ControlledNo Control
PkgContext
Applicant
Interest Record
Interest levels
associatedWith
Interest Sets
composedOf
composedOf
Enterprise
represents
Level
consistOf
consistsOf
MarketValue-ChainOrganisation Extended
Type (TR)
consistOf
Regulator CompetitorCommunity
Locator
Recruitment
Policies
associatedWith
Template-Driven Documentation for Enterprise Recruitment Best Practices
243
Applicant: This realm consists of one applicant
or a group of applicants with the same purpose.
An applicant typically seeks a job and apply for
it. Applicants could be internal as employees
inside the organisation; or external from the
outside. Applicants are the customer of recruiter
in case of value-chain enterprise.
Job Provider: This realm consists of one job
provider or a group of job providers with the
same purpose. Job providers are typically
responsible for the creation of a job vacancy, the
notification for filling, and the embarkation of
new recruits. Job providers are job suppliers in
the case of value chain enterprise.
Qualification Provider: This realm consists of
one qualification provider or a group of
qualification providers with the same purpose.
Qualification providers are those provide things
such as statements, references, reports or letters
that qualify an applicant to apply for a job.
Examples of this realm are schools, universities,
hospitals, or identity checkers. Qualification
providers are supplier of recruiter in case of
value-chain enterprise.
Regulator: This realm consists of one regulator
or a group of regulators with the same purpose.
A regulator is typically a person or organisation
whose job is to control recruitment-related
activities and make sure that they operate
according to official rules or law.
Competitor: This realm consists of one
competitor or a group of competitors with the
same purpose. A competitor typically a person
or company who is a rival against others.
Community: This realm consists of one person
or a group of persons with the same purpose.
The influence of such realm typically appears in
case of extended enterprise. Examples of this
realm are non-client, anti-client, or society as a
whole.
The RRs are also classified by their control level
(CL) for the recruiting organisation. Based on this
level of control, the recruitment policies applied in
each RR could change. These CLs are derived from
the work of Alwazae et al. (2015), as follows:
No control (NC): If the RR with no control, the
realm is not controlled by any organisation.
Hence, the recruiting organisation has no ability
to set or impose recruitment policies within that
realm. However, the policies and mechanisms of
this RR can be expected.
Externally controlled (EC): If the RR is
externally controlled, the RR is managed by
another organisation or partner. Hence, the
recruiting organisation has no ability to set
recruitment policies within the realm but it can
have a service agreement (agreed conditions) by
which a set of policies are agreed on.
Fully controlled (FC): If the RR is fully
controlled, the recruiting organisation has the
full ability to set or impose a set of recruitment
policies within the realm.
When classifying the RRs, two things have to be
considered: the TR that can be found in an enterprise
network, and their CL (who manages this type of
realm). Hence, the classification of RRs can be
defined as RR: TR X CL. These specific RRs can be
used to describe the different types of contexts in
which ERBPs are applied. Table 2 presents the
various types of RRs resulting from our classification
marked with (√).
Table 1: Classification of recruitment realms (RRs).
Type of
Realm (TR)
Control Level (CL)
No
Control
Externally
controlled
Recruiter
-
Applicant
Job Provider
Qualification
Provider
Regulator
-
Competitor
Community
-
The Interest Record
In ERBPs, the interest levels that are applied in all
RRs included in a specific context of enterprise form
the interest record needed for filling a vacancy. In
each RR, there will a set of interest levels which
determine the overall interest of that RR to interact
for filling a job vacancy. These interest levels are
reflected by the recruitment policies adopted in a
specific realm and by the corresponding set of actions
used in interaction. The recruitment policies applied
in each realm are defined in reference to the
recruitment problem type (frame) to solve (i.e.
interest dimensions as well as their interrelationships
and related quality features, see Alamro et al. (2018).
The problem types suffered in each realm can vary,
but the focus here will be on a set of problems that
can be suffered by all RR in common.
Given the definition of recruitment adopted in
Alamro et al. (2018) being a set of interactions, the
common problems of these interactions are related to:
the information exchanged (information dimension);
the timeframe of interaction (time dimension); the
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
244
duration or length of interaction (time dimension);
and the medium of interaction (recruitware
dimension). For each problem, there are some related
recruitment quality features that must be taken into
account by all RRs when defining recruitment
policies to solve such a problem. For instance, an
information-related problem is associated with
features such as information adequacy and accuracy;
a timeframe-related problem is associated with a
feature such as timeliness; a duration-related problem
is associated with a feature such as availability; and
finally a medium-related problem is associated with a
feature such as accessibility.
To establish the interest record for filling a job
vacancy in an enterprise context, the recruitment
analysts should maintain the interest sets of all RRs
included in the context. To maintain the interest set in
each recruitment realm, the recruitment analysts will
assign a set of appropriate recruitment policies to
each realm according to the problems suffered and
their related quality features taking into account the
dependencies between the problems themselves as
well as between RRs in the different levels of
abstractions.
The output of interest record is a set of numbers
that represent the interest sets (the set of interest
levels and the policies applied) for each RR included
in the context. These numbers or interest levels will
help recruitment analysts to select a course of
recruitment actions that fit to these levels. Moreover,
based on these numbers, recruitment analysts can
decide whether the ERBP is appropriate or not when
reusing.
4.1.3 UML Metamodel for Problem and
Threats
Figure 4 shows a UML metamodel for the problem
and threats. The problem that the ERBP attempts to
solve must address the threats associated with filling
a job vacancy and the set of forces that enable those
threats. The threats, such as no engagement,
withdrawal, and rejection, stop filling of a vacancy
and result in some consequences. These
consequences should match the threats identified. The
forces consist of interest dimensions (recruitware,
information, and timing), their elements, and the
intervening relationships between these elements.
The problem lies in the conflict between these interest
dimensions and their elements when the RRs are
interacting.
Figure 4: UML metamodel for problem and threats.
Problem*
Dimensions
Threats
Interest Record
Consequences*
Pkg Problem & Threats
TimingInformationRecruitware
Type
consistOf
composedOf
associatedWith
RelationshipsElements
Quality Features
composedOf
associatedWith
areBasedOn
associatedWith
resultIn
RejectionWithdrawalNo engagement
Type
consistOf
associatedWith
Known Cases*
Template-Driven Documentation for Enterprise Recruitment Best Practices
245
Figure 5: UML metamodel for solution.
4.1.4 UML Metamodel for Solution
In Figure 5, the UML metamodel for solution defines
four solution viewpoints. The first is the RPD which
is related to the problem environment and model the
type of problem to solve. The other three ERD, FRD,
and ERSS are related to the solution environment and
modelled in three levels of system abstractions.
As can be seen in Figure 5, the RPD is used by the
recruitment analysts to capture the problem domain
knowledge and then define the enterprise recruitment
problem to solve. The ERD is used by the recruitment
analysts to define the early requirements of the
system without considering of the functional aspects
of a process. These early requirements are the
recruitment policies that the system solution enforce.
The FRD is used by the recruitment analysts to define
the functional and operational requirements of the
system. In this viewpoint, the recruitment
mechanisms and actions that the system should
perform based on the predefined policies are
captured. Finally, the ERSS is used by both the
business and software analysts to define the context
and specifications of e-recruitment solution. The four
models used in the UML metamodel for solution are
instantiated over the same set of RRs in a specific
context to build the solution for the enterprise
problem.
4.1.5 UML Metamodel for Stakeholders
Figure 6 shows the UML metamodel for stakeholders.
The ERBP should provide a qualitative evaluation
(set of considerations) of the solution from different
stakeholders’ perspectives according to the same set
of RRs in a specific context. When carrying out the
evaluation, the quality features of the Onto-RPD
artefact should be used for assessment.
Figure 6: UML metamodel for stakeholders.
5 DEMONSTRATION AND
EVALUATION OF ERBP
TEMPLATE
In this section, the demonstration and evaluation of
the ERBP template will presented.
5.1 Evaluation
The evaluation of the ERBP template was carried out
with a focus group consisting of 10 domain experts.
In preparing for the meeting, a full package including
the ERBP template, the five UML complementary
diagrams, and a questionnaire based on the defined
requirements along with the instructions of use were
Solution*
ERD FRD ERSS
Recruitment Polices Recruitment Mechanisms E-Solution Specifications
transformedTo
transformedTo
RPD
Problem*
transformedTo
Recruitment Realms
associatedWith
Pkg Solution
Stakeholders Considerations*
Pkg Stakeholders
Solution
relatedTo
Information Recruitware Timing
associatedWith
Interest
Diemensions
relatedTo
Recruitment Realms
associatedWith
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
246
sent to the participants. During the meeting, the
ERBP template, the practical problems that the ERBP
template was meant to address, and the defined
requirements by which this template is assessed were
all presented. Each expert was asked to comment on
the ERBP template and its elements. The discussion
was directed by a facilitator. During the discussion,
experts were asked to write down their comments on
the contribution of the ERBP template to the
requirements prescribed using the templates
provided. At the end, they were also asked to add their
suggestions and recommendation for improving the
ERBP template.
5.2 Results from the Evaluation
The key findings from the evaluation that is centred
on the requirements and characteristics of the ERBP
template are presented in section 3.2, are as follows:
Requirement 1: The ERBP template shall
consist of a complete set of ERBP elements.
Four experts confirmed that the ERBP template
covers all of the elements in ERBP. One of them
reported “the template is quit full. I can see all
key elements included”. Another expert
suggested some elements to be added to the
template such as date, keywords, and
technologies used.
Requirement 2: The ERBP template shall be
easy to use for sharing and reuse. Two experts
reported that the description of the elements and
their relationships are clear and straight-
forward. However, two other experts stated that
the template is very complex to understand
particularly interest record and levels. One of
them stated that “an example of application is
needed”. Another stated that some
reformulation might be needed”. These point up
the need of applying the ERBP template to some
case studies as someone might not be able to
estimate the comprehensiveness and easiness of
use until the application in real-life cases.
Requirement 3: The ERBP shall support both
the creation of high quality ERBPs and the
evaluation of already exiting BPs. According to
three experts, the ERBP template could be used
for both these purposes. They confirmed that the
template represents a good foundation to
structure and articulate ERBPs. One expert
stated “the template gives a concrete structure
for what elements you have to document, and it
makes ERBP easier to use”. Some experts
criticised the template as being hard to use and
needs some time and training to do that. Other
experts stressed the need of a methodology by
which such ERBP template can be shared and
reused.
6 CONCLUSIONS
In this paper, an ERBP template for is designed for a
proper documentation of ERBPs. The template was
represented using a precise metamodel with five
complementary UML diagrams. The findings of the
evaluation of ERBP template is encouraging. The
future work will focus on applying the ERBP
template into real-life case studies to assess its
comprehensiveness and usability.
REFERENCES
Abd Rahman, A.A. Sahibuddin, S. and Ibrahim, S. 2011. A
study of process improvement best practices.
Information technology and multimedia (ICIM),
International Conference on IT & Multimedia at
UNITEN (ICIMU 2011) Malaysia, 1-5.
Ahamed, S., Adams, A., 2010. Web recruiting in
government organisations: A case study of the Northern
Kentucky / Greater Cincinnati Metropolitan Region,
Public Performance & Management.
Alamro, S., Dogan, H., Cetinkaya, D., Jiang, N. and Phalp,
K., 2018. Conceptualising and Modelling E-
Recruitment Process for Enterprises through a Problem
Oriented Approach. Information, 9 (11), 269.
Alwazae, M. Perjons, E. and Johannesson, P. (2015).
Applying a template for best practice documentation.
The 3rd Information Systems International Conference,
November, 2-4, Surabaya, Indonesia.
Carless, S.A., Wintle, J., 2007. Applicant Attraction: The
role of recruiter function, work-life balance policies and
career salience. International Journal of Selection and
Assessment, 15(4), pp. 394-404.
Buschmann, F., Henney, K., Schmidt, D.C. 2007. Pattern
Oriented Software Architecture. On Patterns and
Pattern Languages, vol. 5. Wiley, Chichester.
Fouad, A., 2011. Embedding requirements within the
Model Driven Architecture. PhD Thesis, Bournemouth
University.
Gartner. 2008. Gartner Clarifies the Definition of the Term
'Enterprise Architecture'. Gartner research. ID
Number: G00156559.
Graupner, S. Motahari-Nezhad, H.R. Singhal, S. and Basu,
S. 2009. Making processes from best practice
frameworks actionable. Enterprise Distributed Object
Computing Conference Workshops, 13th IEEE, 1-4
September, 25-34.
Hanafizadeh, P. Moosakhani, M. and Bakhshi, J. 2009.
Selecting the best strategic practices for business
Template-Driven Documentation for Enterprise Recruitment Best Practices
247
process redesign. Business Process Management
Journal, 15 (4), 609-627.
Investopedia. 2016. Best Practice. Accessed (2016-07-15)
at https://www.Investopedia.com/terms/best_practice
Jashapara A. Knowledge Management: An Integrated
Approach. 2nd Edition. Pearson Education, Harlow,
Essex; 2011.
Johannesson P., Perjons E., 2014. An introduction to design
science. Springer International Publishing,
Switzerland.
Madia, S. 2011. Best practices for using social media as a
recruitment strategy. Strategic HR Review, vol. 10, no.
6, pp. 1924, 2011.
Mansar, S. and Reijers, H. 2007. Best practices in business
process redesign: Use and impact. Business Process
Management Journal, Emerald Group Publishing
Limited, 13 (2), 193-213.
Molina, A., Medina, V., 2003. Application of enterprise
models and simulation tools for the evaluation of the
impact of best manufacturing practices implementation.
Annual Reviews in Control, 27 (2003) 221228.
Motahari-Nezhad HRM, Graupner V, Bartolini C. 2010. A
framework for modelling and enabling reuse of best
practice IT processes. Business Process Management
Workshops; 2010, p. 226-231.
Penaranda, N., Mejia, R., Romero, D. and Molina, A. 2010.
Implementation of product lifecycle management tools
using enterprise integration engineering and action-
research. International journal of computer integrated
manufacturing, 23 (10), 853-875.
Renzl, B. Matzler, K. and Hinterhuber, H. 2006. The Future
of Knowledge Management. Palgrave Macmillan, New
York.
Sharp, H., Rogers, Y., and Preece J., 2007. Interaction
Design: Beyond HumanComputer Interaction.
Simard, C. and Rice, R.E. 2007. The practice gap: Barriers
to the diffusion of best practices. In McInerney, C. R.
and Day R. E. Ed., Re-Thinking Knowledge
Management: From Knowledge Objects To Knowledge
Processes, Dordrecht, The Netherlands: Springer-
Verlag, 87-124.
Smith, G., 1989. Defining managerial problems: A
Framework for Prescriptive Theorizing. Management
Science, vol. 8, pp. 963-981.
Stephenson, C. and Bandara, W. 2007. Enhancing Best
Practices in Public Health: Using Process Patterns for
Business Process Management. In Proceedings ECIS
2007 - The 15th European Conference on Information
Systems, St. Gallen, Switzerland, 2123-2134.
Vallejo, C, Romero, D. and Molina, A. 2012. Enterprise
integration engineering framework and toolbox.
International journal of production research, 50 (6),
1489-1511.
Vesely A. Theory and methodology of best practice
research: A critical review of the current state. Central
European Journal of Public Policy, vol. 2; p. 98-117.
Zachman, J., 2008. The concise definition of the Zachman
framework, link: https://www.zachman.com/about-the-
zachman-framework.
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
248