Improving Employee Life-Cycle Processes Support by

using a Web-Enabled Workflow System: An Agile

Approach

Leon Welicki

, Francisco Javier Piqueres Juan

Fernando Llorente Martin

and Victor de Vega Hernandez

ONO, Information Systems and Internet Services Department

Basauri 7-9, 28007, Madrid, Spain

ONO, Human Resources Department, Basauri 7-9, 28007, Madrid, Spain

Abstract. Employee life-cycle processes management (hiring new employees,

changing their conditions, and dismissing them) is a critical task that has a big

impact in HR Information Systems. If these processes are not handled correctly

the consistency of HR databases is compromised. In many cases (especially in

small and mid-size business) these processes are implemented using semi-

manual procedures based on unstructured information. In this paper we will

present the results of our real-world experience building a web-enabled work-

flow system for managing employee life-cycle process instances in the context

big Spanish telecommunications company.

1 Introduction

Employee life-cycle management is a critical task that affects all companies without

regard of their size and business. These processes include hiring new employees,

changing working conditions (promotion, demotions, change of cost centre, changes

in the compensation package, change of function, change of organizational unit, etc.)

and dismissals (end of relationship). In this paper we will present our real-world ex-

perience building a web-enabled workflow system for managing employee life-cycle

process instances in a big Spanish telecommunications company. In the first section

we will present ONO, our company, in order to set the organizational context. In the

second section we will present the problem that we faced and set the requirements for

building a tool to solve it. In the third section the web-enabled workflow system is

presented, making special focus on the agile approach used to build it and how the

previously stated requirements are met. Finally we will offer some conclusions and

future lines of work.

Welicki L., Javier Piqueres Juan F., Llorente Martin F. and de Vega Hernandez V. (2008).

Improving Employee Life-Cycle Processes Support by using a Web-Enabled Workﬂow System: An Agile Approach.

In Proceedings of the 2nd International Workshop on Human Resource Information Systems, pages 63-75

DOI: 10.5220/0001745000630075

 SciTePress

1.1 About ONO

ONO is the leading alternative provider of telecommunications, broadband Internet

and pay television services in Spain and the only cable operator with national cover-

age. ONO offers its services to more than 1.8 million residential cable access and

69,000 business customers as of 31 March 2007, through its own state of the art net-

works which give direct access to nearly six million homes in franchises that cover

the majority of Spain, including the nine largest cities. ONO is the principal competi-

tor to the incumbent telecommunications and pay television operators in Spain. For

the first Quarter 2007, ONO generated revenues of €1,608 million and EBITDA of

€592 million, on an annualized basis. ONO has several offices all around Spain.

Fig. 1. ONO Spanish coverage and operating highlights. ONO offers their services to clients in

almost all the national territory, covering more than 17.500 homes in Spain (according the

Spanish INE).

2 The Problem

In the last years, ONO experienced a very fast growth in a very short period of time.

The biggest leap was the merge with Auna (a company that had the same size than

ONO at the time of the joint). One of ONO’s main characteristics was being very

agile, with very simple and human-centred processes. Some of them didn’t scale to

the new context of the company, since they were designed and implemented having

another model of enterprise in mind. The employee life-cycle management support

processes (hiring, changing working conditions, and dismissal) fell in this group.

Each of these processes were based on paper-printed documents (that in the best

case where based in corporate Excel templates), with all the problems that this im-

plies including inconsistency in the input (files were completed differently by the

requestors), traceability (all the Excels were sent internal mail), problems for enabling

team-work (there wasn’t any mechanism for dispatching the requests and therefore a

single request could be handled incorrectly by several HR (Human Resources) em-

ployees at the same time), lack of a unified way for notifying the participants in the

flow, lack of tools for reusing the requests, lack of reporting (there wasn’t any auto-

matic way to get a report of what was going on in the company), lot of human effort

of very low added-value (HR managers consolidating hundreds of Excel files and e-

mails), among other problems. To make things worst, ONO has a region-based organ-

izational model (based on the division of the company in the Spanish geography),

increasing the impact of the above mentioned problems.

2.1 Description of the Manual Processes

ONO is a young company, and therefore some of their processes matured in the last

years and some of them are still maturing. The employee life-cycle management proc-

ess was a manual process that was based in interactions among people that knew each

other (at least by telephone). They were manual workflows where all the participants

worked collaboratively on a physical paper document.

Following, we will describe briefly (and in a broad way) how the processes were

run:

1. A user creates a request document (for staring a new hire, a change in the con-

ditions of one of his employees, or a dismissal). In the best cases this docu-

ment was based on a corporate template. While this was the best case, it was

far from being ideal: since the requestors weren’t HR specialist (a petitioner

could be any manager that needs to hire a new employee or to promote one of

his employees) usually the document wasn’t correctly fulfilled.

2. After the document was created and printed, it was signed by the petitioner

and by her manager.

3. The petitioner notifies the HR department (by email or by phone) and then he

sends the physical document by internal mail.

4. HR receives the document and validates it. If they need further clarification,

they would contact the petitioner or her manager to discuss about the request.

5. In the case that the conditions of the hiring / promotion / change / etc. varied

significantly after the discussion, a new physical document needed to be is-

sued and signed again.

6. HR registers the transaction, contacts the employee that would be hired / pro-

moted / fired / etc., does their usual tasks according the type of process, and

registers all the information in their HR systems (payroll, SAP HR module,

etc.)

7. Periodically (twice a month), the HR staff manually created reports of the on-

going processes to inform the upper management. They also used this infor-

mation to verify that the HR budget wasn’t overrun (this verification was also

manual on a process-by-process basis).

The above description is a simplified version of the manual processes, with the

goal to illustrate its fragility. It was very error prone, produced lots of unnecessary

work, unreliable (in some cases, papers where lost and the process needed to be

started over), and unique for each petitioner (according to her personality). It con-

sumed lots of time of the HR team performing tasks of near-to-null value, such as

verifying the input data and trying to interpret it, creating reports manually, tracking

papers, notifying personally each of the actors in the process, and controlling the

budget.

2.2 ONO-AUNA Merge Related Problems

The process mentioned above worked fairly well in mid-to-low-size environment

(less than 2.500 employees), with a relatively small HR department, and a very peo-

ple oriented culture. Since the process was mainly based in human interactions, it

worked better when the participants knew each other. Additionally, each instance of

the process was highly dependant in the actors: some requesters (hiring managers in

the hundreds of departments of the organization) where good “process players” and

sent the information in good shape while others where very chaotic.

When ONO bought Auna and the merge started the company doubled its size. A

manual process mainly based in interactions among people that knew each other

didn’t scale well in the new scenario, in one part because the size of the company

increased but mainly because the people running the process didn’t knew all their

counterparts anymore (and given the new size of the company, it was very improb-

able that they would do ever).

To worsen things, the amount of HR transactions regarding employee life-cycle

increased exponentially: is well known by everyone that in a merge process lots of

new people come to the company, lots of people leave the company, and even more

people changes position (in the average, there are two employees for each position,

since both companies where in the same business).

A final added problem was traceability and auditability: since the process was

based in physical paper sheets, it was mandatory to keep the original papers for a time

period according with the Spanish law. During the merge, lots of work centre moves

were done. Each move affected the paper files and therefore increased the difficulty

to locate the papers (they could be lost or at any branch of the company). In these

cases, lots of time of the HR was lost just doing “paper chasing”.

2.3 The Need for a Tool

It was very clear that the company needed a tool to assist the employee life-cycle

management, with the goal of making it easier, more reliable, predictable and audit-

able, to provide all the participants in the process the information they need just in

time without any further hassle, and to provide the upper management with reporting

tools to know the global picture regarding the overall HR budget of the company.

After jointly studying the problem ONO’s HR and IT departments decided to build

a set of tools to support the employee life-cycle processes. The main goal of these

tools was to enable the collaborative work between all the actors implied in each of

the employee life-cycle management processes. Each of these actors should be able to

interact with the new tool in a very simple and efficient manner. Additionally, the tool

should be proactive, providing a “push model”: each participant in the process should

be notified whenever a process instance requires his participation. The tool should

support the approval workflow [13] for each type of process, dynamic headcount

validation and automatic reporting.

2.4 Requirements for the Tool

The following requirements where established by ONO’s HR department:

• HR Budget Control. Provide an automatic control of the HR budget at all the

appropriate levels. For example, when a new request is issued it should be

checked against the requesting department HR budget to verify if the request is

valid. At a higher level the upper management and HR directors need to have re-

porting facilities to have a general view of evolution the overall HR budget of the

company.

• Support for the Approval Workflows. Model the manual processes using a work-

flow systems. This implies modelling semi-formal processes using formal speci-

fications.

• Enabling Collaborative Work. The tool should allow each employee to partici-

pate in the approval workflow at the right moment. It should inform the partici-

pant in the flow of the new events that require their attention. It should also give

a unique single point for checking the status of the on going processes (eliminat-

ing e-mail and phone).

• Automatic Reporting. Generate all the reports automatically, without manual

intervention.

• Traceability and Auditability. All the process instances should be traceable and

auditable, giving a fine grained control over the past events.

• Reducing Manual Work. reduce all the low value added manual work

• Input Consistency: simplify data input in order to give reduce ambiguity and

improve consistency in data that enters to the approval flow.

• Reduce Bottlenecks in the Process. Provide tools to avoid a single person to stop

all the ongoing flows when she is not available.

• Ease of use and Far Reach. Create a very easy to use tool in order to make the

learning curve as low as possible. It should also accessible by any employee of

the organization without the need of any complex setup in his computer.

3 A Web-Enabled Workflow System as a Response to the Problem

After the problem was clearly established ONO’s IT and HR departments started

working on how to deliver a cost and time effective solution following ONO’s cul-

tural principles [4]. The working group determined that the best approach for solving

the problem was building a web-enabled workflow-based system, since it would

empower the collaborative work on the employee life-cycle requests without any

special requirement in the client computers.

The group also decided to build it with a low budget without sacrificing the quality

and functionality, using the technologies and tools available at the company (mainly

based in the development framework created by ONO’s IT department). An agile

approach was the methodological choice since it allowed to build small deliverables

in short iterations, delivering value in small (but continuous) slots of time. In the

economic side, this approach would allow to build with the resources at disposal: if

the team was short on economic resources, it could do less ambitious iterations or

even do no iteration without affecting the overall project (whenever any iteration was

finished a new fully working module was delivered and deployed in production).

3.1 Modelling the Business Processes

The processes were modelled after a careful analysis of their manual counterparts. A

joint work between ONO’s HR and IT department was performed in order to come

out with the most accurate representation of the business processes involved in the

employee life-cycle.

The business process modelling was a very important part of the process: lot of

tacit organizational knowledge [10] needed to be transformed in explicit knowledge

[10] that can be used as a formal specification. It was a big challenge to come out

with a model that clearly represents the interactions for each employee life-cycle

process: since the process was semi-formal, there where significant ambiguities that

needed to be resolved.

The main premise in this specification process was simplicity: our goal was to

come out with the simplest process definition as possible. All the resulting flows are

very similar: this is the result of a commonality analysis [6] between all the processes

in order to find all the similarities between processes and model them as uniform as

possible to make them simpler and easier.

Observing, Learning Building, and Delivering: An Agile Approach for Model-

ling the Business Processes. We took an agile [1] [8] [2] [11] approach built our first

model iteratively and incrementally: instead of trying to come out with the final ver-

sion of the three flows up-front we went through several short iterations on the first

one (the hiring process) and improved it using the feedback and experience gained

from its real users.

We created a simple implementation of the hiring process according to the more

immediate needs of HR. When it was in production we actively observed the prob-

lems and situations that arose to our users when using the tool and the error logs of

the system. With all this information we built packages of fixes (in short sprints) and

delivered new versions taking the same approach (observing, learning, building, and

delivering).

This approach allowed us to constantly deliver value and to supply a working solu-

tion to our users without spending unnecessary time in the analysis phase (lot of the

changes that we included in the packages where product of our continuous improve-

ment process).

3.2 An Agile Approach for Implementing the HR Workflow System

The Software Development area in ONO’s IT department works under the principle

of dividing big projects in small chunks in order to deliver functionality earlier in

shorter intervals of time and with more client checkpoints. This allows building ap-

plications with smaller budget, deliver early working products to the clients, and

giving them the chance to change or add new requirements after each iteration. The

main goal of our approach is to deliver value to clients in the shortest interval as pos-

sible and to evolve the functionalities based on real world information mined from the

usage of the application (observe, learn, build, and deliver).

ONO’s Software Development area uses a variant of SCRUM [11]. Each sprint

[11] starts with the creation of a scope document that is validated by IT and its clients

(in this case, HR). After the document is approved, a high level architecture and high

level designs are built and a product backlog is created. This backlog may also con-

tain small user stories on each of its items. The backlog is revised on a daily basis

doing stand-up meetings. In that stand-up meetings, some architectural or design

issues may arise. In that case they are discussed later in other special purpose meet-

ings, in order to make the daily stand ups as short as possible and not keeping all the

members of the team busy with things that are not interesting for them. In our

SCRUM variant, the sprints are not of a fixed size and we have an architect role to

ensure conceptual integrity [3] and alignment and synergies with Ono.CDI, our cor-

porate software development framework.

We calculate the size of the sprint according to the commitments established with

the clients. However, we always work actively with the clients to keep the sprints

shorter than six weeks. Ideally, and on the average, the sprints have three weeks dura-

tion.

After sprint is finished, a User Acceptance Test (UAT) with the client area is per-

formed. In this test some minor issues may arise, so we always plan some days in our

schedule to fix these minor issues. After the UAT is passed and the fixes are ap-

proved we deliver the product of the iteration.

Deliverables Planning: Technology for the Masses. HR and IT established to pol-

icy of “Deliver value to 4980 employees first and later to the remaining 20”. This

was our guiding metaphor [10] [2] and means that we work to deliver functionality to

all the company first (the front-end of the application) and leave the detailed back-end

operations for later iterations.

The following example illustrates the idea: we focused on creating client applica-

tions with very clear and crisp user interfaces to deliver good tools to all the employ-

ees in the company for going through the employee life-cycle processes. This elimi-

nated the physical sheet of paper, the phone calls, and the ambiguities in the process,

improving the operations of all the hiring managers and organizational unit managers

in the company (and potentially of any employee in the company). However, in the

first versions the back-end tools for the HR team where less sophisticated since we

used all our resources for providing value to the biggest number of users.

Technology Planning. In order to create a reliable and fully functional tool with a

low budget and fast delivery we leveraged Ono.CDI (Ono Content Driven Infrastruc-

ture Framework), our corporate software development framework for intranet based

applications. Ono.CDI contains a set of tools and engines that provide core and basic

services (figure 2) that includes a Workflow Engine, Document Management Engine,

Business Request Framework, and Caching Engine [14] [15]. It has crosscutting Se-

curity and Audit modules that ensure that applications complain with ONO’s IT secu-

rity policies and with legal audit requirements.

Ono.CDI also includes prescriptive architectural guidelines and blueprints that

govern the architecture of ONO’s intranet applications. Therefore the application is

completely aligned with ONO’s development policies lowering its technology trans-

fer and maintenance cost (the maintenance and the development team are formed by

different people) and ensuring a quality minimum based proven architectural patterns

[5] [6] and development practices.

Fig. 2. ONO’s development framework high level architectural view.

3.3 HR Workflow System

The result of the process is the HR Workflow System that provides support for the

employee life-cycle management processes. In the section 2.4 we established a set of

requirements that needed to be fulfilled by the system. Following, we will explain

how these requirements have been met by the tool.

HR Budget Control. The system provides a detailed HR budget control. It has been

designed and built to keep track of the budget of each organizational unit on a process

instance basis. For example, when a manager requests HR to hire a new employee the

system checks if his area is above or below its headcount budget. If the area is above

its headcount budget the request is annotated with special information (as shown in

figure 3) in order to make this situation easily noticeable to the rest of the participants

in the flow. The application also includes reports to provide the HR experts and the

upper management with high level real-time views of the overall HR budget evolu-

tion in the organization.

Fig. 3. Fragment of the “hiring request” screen. Notice how the headcount indicators (“HC

presupuestado” and “HC real” fields) are highlighted in red. This means that this request is

above the headcount of the requesting organizational unit.

Support for the Approval Workflow. The system used ONO’s Workflow Engine

capabilities to model the approval workflows. A workflow definition has been created

for each of the flows associated with each type of employee life-cycle process (hiring,

change of working conditions, and dismissal).

Enabling Collaborative Work. The HR Workflow System notifies each employee

of new events via e-mail whenever a process needs his participation. This enhances

the users experience since the users don’t need to be polling the application periodi-

cally to check if there is something that requires their attention. Additionally, the

system implements an “Inbox” metaphor (similar to the one used in the e-mail sys-

tems) that gathers the requests that need participation of the user. When a user enters

in the application his inbox is displayed. Additionally a summary of it (figure 4) is

present during all his session within the application.

Fig. 4. Inbox summary. This widget is displayed in the left menu bar of the screen and is al-

ways visible. This widget shows the total number of requests of each type that require the

participation of the logged user. When the user clicks in any of the request types the complete

inbox is displayed

Automatic Reporting. The system generates automatically the necessary reports for

HR control and for the upper management control. They are generated dynamically

and can be requested at any moment providing an up-to-date picture of the overall

active employee life-cycle processes in the organization.

Traceability and Auditability. Every action in the approval workflow of the em-

ployee life-cycle process instances is recorded in a history log that is displayed within

each process instance (figure 5). Additionally, access information is recorded but not

shown (this is used for privacy and access control audits)

Fig. 5. History of a process. Each action performed on the request is recorded (including the

execution user, date, target state, and observations).

Reducing Manual Work. All the notifications to participants, reporting, and archival

of finished processes is done automatically, eliminating the most tedious and error

prone manual tasks.

Input Consistency. The input screens reduce the work to be done by the users. Each

participant only needs to complete a very concrete (and ideally small amount of)

information in each step of the flow. The employee and organizational related infor-

mation is extracted directly from ONO’s IT infrastructure, and the rest of the fields

are parameterized lists (whenever is possible) simplifying considerably the creation of

new requests (figure 6).

Fig. 6. Input screen for working conditions change. After an employee is selected (first field)

all his information is retrieved from the corporate SAP HR database and displayed in read only

fields. The remaining input fields in the form are parameterized drop down lists.

Reduce Bottlenecks in the Processes. The application provides “delegation” func-

tionality that allows an employee to “delegate” in another employee his functions.

There are also “super-users” (HR members) that can act in any request at any time.

Therefore, except in the case rare situations that need a careful analysis of a senior

manager, no employee is a bottleneck for a process instance in the system.

Ease of Use and Far Reach. We based our user interface (UI) in our corporate Intra-

net (OnoNET) that is well known among all ONO employees (figure 7). We also used

all the UI widgets of our development framework having consistency with the exist-

ing applications in the intranet. The use of web-based technologies simplifies the

deployment and reach of the tool: any user with a browser can access and use the HR

Workflow System. Our UI foundation follows the usability guidelines presented in

[7] and [9].

Fig. 7. UI consistency and simplicity: the HR Workflow System (right side of the figure) is

similar to the corporate intranet (left side of the figure).

4 Conclusions and Future Work

The workflow system has been in production for a year. It has successfully managed

a big number of requests (we cannot disclose that information here), bringing reliabil-

ity, traceability and audatibility to the employee life-cycle management processes. It

has become one of the core systems for supporting HR operations.

The resolution of each employee life-cycle process went down from weeks (in the

manual case) to just days or hours (according the complexity of the request). Each

participant in the process has to just perform a very concrete action and work with

very concrete set of data. Additionally, he is notified via mail every time he needs to

perform an action on a request.

Reporting is done automatically. The HR staff doesn’t have to spend time on creat-

ing reports and the upper management has real-time in information on the on-going

employee life-cycle processes.

Everyone in the company knows the processes (they are unambiguous, well docu-

mented, and accessible to everyone in the organization) and the processes are always

the same for every employee in the organization. They are no longer dependent on the

participants. At the same time the processes model the reality of our company and had

been tailored to provide as much value as possible to it.

We could summarize the main benefits of the system in these three items:

1. Reliable Information: the data sources are accurate based on normalized input

and each process instance is auditable.

2. Agile Information: the employees are notified only when they have to partici-

pate in a flow eliminating unnecessary and unproductive “polling” in an appli-

cation.

3. Improved Information Management: the employee process life-cycle proc-

esses information is centralized, easy to access, and normalized, making it

easy to know about the state of any on going or finished process in a uniform

and simple way.

We improved and normalized the employee life-cycle support significantly, but

our work isn’t finished yet. Currently, we are working on the following enhancements

to the system:

• Improve Integration with ONO’s Implementation of SAP: after an employee

life-cycle process is finished it should be directly registered in SAP (now this

step is performed manually) using a loosely-coupled service interface.

• Dynamic HR Budget with SAP Business Warehouse: implement SAP BWI to

provide dynamic and up-to-date information on the headcount budget. Cur-

rently the budget is loaded in the system upon HR’s request.

• Improving the Support for the Selection Process: currently some parts of the

selection process (for hiring new employees) are done offline. The system

doesn’t provide support for managing the interviews with candidates and man-

aging offer letters (this two issues need very special attention of ONO’s legal

department according to Spanish laws on information protection).

• Creation and Archival of Formal Letters: Automatically create formal letters

within each process and archive them in the process instance.

References

1. Agile Alliance (1999) http://www.agilealliance.com/

2. Beck, K..: Extreme Programming: Embrace the Change. Addison-Wesley Professional

(1999)

3. Brooks, F.: The Mythical Man-Month: Essays on Software Engineering, Anniversary

Edition. Addison-Wesley Professional (1995)

4. Davenport, T., Prusak, L.: Working Knowledge. Harvard Business School Press (2000)

5. Fowler, M..: Patterns of Enterprise Application Architecture. Addison-Wesley Professional

(2002)

6. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley Professional (1999)

7. Krug, S.: Don’t Make Me Think! New Riders Press (2000)

8. Martin, R.: Agile Software Development, Principles, Patterns, and Practices. Prentice Hall,

USA (2002)

9. Nielsen, J.: Designing Web Usability. Peachpit Press (1999)

10. Nonaka, I., Takeuchi, H.: The Knowledge-Creating Company: How Japanese Companies

Create the Dynamics of Innovation. Oxford University Press, USA (1995)

11. Schwaber, K., Beedle, M.: Agile Software Development with SCRUM. Prentice Hall, USA

(2001)

12. Seely Brown, J., Duguid, P.: The Social Life of Information. Harvard Business School

Press (2002)

13. Workflow Management Coalition. The Workflow Reference Model (1995)

14. Welicki, L., Sanjuan Martinez, O.: Improving Performance and Server Resource Usage

with Page Fragment Caching in Distributed Web Servers. International Workshop on Scal-

able Data Management Applications and Systems - WORDLCOMP 2007 (Las Vegas, Ne-

vada, USA, July 2007)

15. Welicki, L..: The Configuration Data Caching Pattern. 13

Conference on Pattern Lan-

guages of Programs – PLoP 2009 (Portland, Oregon, USA, October 2006)