customer relationship management in university environment...de seguida e apresentada uma...
TRANSCRIPT
Customer Relationship Management in UniversityEnvironment
João Bruno Trindade Albuquerque Ala de Rezende
Thesis to obtain the Master of Science Degree in
Telecommunications and Informatics Engineering
Supervisors: Prof. José Luís Brinquete BorbinhaProf. Fernando Henrique Côrte-Real Mira da Silva
Examination Committee
Chairperson: Prof. Paulo Jorge Pires FerreiraSupervisor: Prof. José Luís Brinquete BorbinhaMember of the Committee: Prof. Diogo Manuel Ribeiro Ferreira
May 2015
ii
Acknowledgments
I would like to express my gratitude to my supervisors (Jose Borbinha and Fernando Mira da Silva),
for their constant monitoring and ability to always put me on track. A special thanks to Professor
Jose Borbinha, for never giving up on me.
On a personal level, I want to thank my parents because without them it would not be possible to
reach this moment. A word also for my siblings and my grandmother, who are the family that anyone
could wish for.
Last but not least, for the woman of my life. Thanks Cuca.
iii
iv
Resumo
A gestao da relacao com o cliente desempenha um papel importante em todas as empresas, in-
dependentemente da area de negocio em que a empresa opera. Quando aplicado ao ambiente
universitario, o Customer Relationship Management (CRM) centra-se nas relacoes que os alunos
desenvolvem com a universidade, e como essa relacao pode ser gerida pela universidade com
o objetivo de aumentar o sucesso de alunos ao longo da sua carreira academica. Propomos a
implementacao de uma aplicacao CRM e de sistemas paralelos que permitam aos Professores do
Departamento de Engenharia Informatica do Instituto Superior Tecnico efetuarem uma gestao mais
proxima da sua relacao com os alunos das cadeiras que ministram.
Neste documento iremos fazer um levantamento do estado de arte no que se refere a implementacao
de sistemas CRM em ambiente empresarial e universitario, bem como a analise das especificidades
do ambiente em que se pretende implementar a solucao.
De seguida e apresentada uma arquitetura que pretende resolver o problema identificado, bem
como o processo que levou a escolha de uma aplicacao em particular para se atingir esse fim.
Posteriormente sao descritos todos os passos dados para que fosse possıvel concretizar a
solucao que havia sido proposta anteriormente, bem como uma avaliacao dos resultados obtidos,
sempre tendo em conta os objetivos delineados e a solucao proposta.
Finalmente, sao retiradas conclusoes sobre todo o processo, sendo que sao ainda sugeridas
melhorias/alteracoes para as proximas iteracoes do projeto.
Palavras-chave: CRM, Relacao Professor-Alunos, Aplicacoes CRM, Segmentacao, Construcao
de perfil
v
vi
Abstract
The management of the relationship with the customer plays an important role in all companies,
regardless of the business area in which the company operates. When applied to the university
environment, the Customer Relationship Management (CRM) focuses on the relationships that stu-
dents develop with the university, and how this relationship can be managed by the university with
the goal of increasing the success of students throughout their academic career. We propose the
implementation of a CRM application and parallel systems to allow Professors in the Department of
Computer Engineering at Instituto Superior Tecnico to develop a closer management of their rela-
tionship with students in the courses ministered by them.
In this paper we survey the state of the art with regard to the implementation of CRM systems in
business and university environments, as well as the analysis of the specific environment in which
we intend to implement the solution.
A proposed architecture is presented, that aims to solve the identified problem, and the process
that led to the choice of a particular application to achieve the proposed solution.
Subsequently it is described the steps taken to make possible the implementation of the solution
that has been previously proposed and an evaluation of the results achieved, always taking into
account the objectives outlined and the proposed solution.
Finally, conclusions about the entire process are drawn, an improvements/changes are sug-
gested for future project iterations.
Keywords: CRM, Professor-Student Relationship, CRM Applications, Segmentation, Pro-
filing
vii
viii
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Goals and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 State of the art 5
2.1 CRM Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 CRM History and Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Key concepts in CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 CRM in a Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Academic CRM Implementation Case Studies . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Educational environment case studies . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 CRM impact in organizations case studies . . . . . . . . . . . . . . . . . . . . . 13
3 Problem Analysis and Proposed Solution 17
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Objective Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 IST Structure and Departments . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Reduction of the Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Formalization of goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Analysis of possible solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ix
3.5.1 SugarCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.2 Zurmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.3 VtigerCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.4 CiviCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.5 Comparison between Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.6 SugarCRM limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7 Proposed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.1 Attendance Collection Application . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7.2 SugarCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Implementation 43
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Attendance Collection Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Application construction steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Presences introduction/consultation . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Statistical information consultation . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 SugarCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.1 Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.2 Teams module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.3 Dashlet building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.4 Segmentation and communication . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Evaluation 57
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 User Acceptance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1 Test Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Simulation Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.1 Traditional methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.2 Using CRM Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Conclusions 63
6.1 Achievements and conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Bibliography 67
x
List of Tables
3.1 Criteria per category, and respective weights . . . . . . . . . . . . . . . . . . . . . . . 33
xi
xii
List of Figures
2.1 Impact of a 10% Improvement in Indicator on the Current Value of E-Commerce Firms 7
3.1 CRM application selection, categories and weights . . . . . . . . . . . . . . . . . . . . 32
3.2 Application evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Application final scoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Application for Attendance Collection proposed Architecture . . . . . . . . . . . . . . . 38
3.5 SugarCRM proposed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 FenixEDU API endpoint structure example . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Attendance Collection Excel structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Total Attendances Statistics Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Individual Attendances Statistics Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 SugarCRM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Implemented tables architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Global attendances introduction dashlet . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8 Emails module configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 SQL code to run report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Values collected with traditional methods . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Values collected with new methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Time consumed to perform actions without explanation of functionalities . . . . . . . . 61
5.5 Time consumed to perform actions with explanation of functionalities . . . . . . . . . . 61
xiii
xiv
List of Acronyms
CRM Customer Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
IST Instituto Superior Tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
DEI Departamento de Engenharia Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
DEEC Departamento de Engenharia Electronica e de Computadores . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ROI Return Over Investment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
WDMP Weighted Decision Making Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
AHP Analytic Hierarchy Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
HTML HyperText Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CSS Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
REST Representational State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
SSO Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
CAS Central Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
JSON JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
MVC Model View Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
SQL Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
xv
xvi
Chapter 1
Introduction
The CRM initiatives and applications have gained an increasing relevance in the development of the
companies businesses in recent decades.
With the need to present distinctive features and a place in customers preferences, many com-
panies felt the need to treat their customer relationship with a degree of differencing that made the
customer feel special without losing the efficiency of processes implemented in the company.
This led to the Customer Relationship Management (CRM) methodology growth, that advocates
the creation of a vision focused on the customer and the idea of creating a one-on-one relationship
with the customer started gaining ground to other methods of customer relations management. For
this methodology to thrive, the necessity to created applications that support this way of thinking and
acting within the companies arose.
This chapter is intended to explain what is the importance of CRM systems and methodology
and its relevance to the academic environment, where it is intended to carry out the CRM initiative
postulated herein.
1.1 Motivation
The management of customer relationships plays an important role in all companies, whatever area
of business in which the company operates. In the last twenty years a great effort has been wit-
nessed by the companies in the acquisition and implementation of systems to improve their rela-
tionship with customers, driven by a growing concern in the management of contacts made with
customers. This integrated view of customer relationship becomes even more relevant when the
multiplicity of communication channels is present, and the need to transmit the customer a sense of
contact with a single source has become a difficult task to accomplish.
Given the need to maintain a close relationship and contact with the client, appeared on the
1
market technological solution that aim to carry to the IT environment these notions of Marketing and
Client Management. The system that achieved greater success in this mission was the Customer
Relationship Management.
The Customer Relationship Management is a system that allows information collected from in-
teractions with customers to be stored, grouped and manipulated so as to create a compilation of
the relationship developed with the customers, thus creating a client profile as complete as possible.
From the moment that a profile of the customer is created, it becomes possible to perform customer
segmentation to create targeted campaigns, it becomes possible to create privileged communication
channels, among other features related with the management of the relationship with the customer.
Despite all these concepts being very focused and mapped to the business reality, one can easily
make a parallelism with the elements that make up the academic reality.
The concept of customer (person/company with which the entity that implements the CRM main-
tains a commercial relationship) can be identified in the academic reality as the student. Likewise,
departments of a company (elements that work in the entity that implements CRM) can be identified
as the Services/Professors/Administrative Staff in the university environment.
Given these parallelisms, it is possible to understand that the management of the relationship
between the various communication channels in a company (departments/stakeholders) with cus-
tomers can be transposed to the relationship between the various elements that make up the uni-
versity structure (Professors/Administrative Staff) and the students who attend the university.
1.2 Problem Statement
Instituto Superior Tecnico (IST) is a college of Engineering located in Portugal. The organization of
the University follows a classical model, and its main division is made by Departments.
Departments offer courses to the various Bachelors/Masters, which are taught by Professors. At
the beginning of the semester students have the possibility to enroll in one or more courses, and a
Professor can in turn be associated with one or more courses.
During a semester several classes are taught in each course, and there is one or more time
points of evaluation of the knowledge gained during the classes. Recently, one of the Department of
IST, the Departamento de Engenharia Informatica (DEI), decided it would be beneficial to collect the
attendance of students in classes, even though the class attendance is not mandatory by the School
regulations.
Regarding the way information management is performed nowadays, the process of managing
a semester is mainly supported by the Fenix service. This service is part of the Intranet of IST, and
2
offers different functionalities to the various elements that make up the school. Students may query
about their personal information while IST students, perform their registration on courses, access to
discussion forums of the courses, etc..
This application is also widely used by the Departments administrative staff, as well by the Pro-
fessors. To the school Professors the service allows then to manage the courses they give, and
gives them the ability to communicate with students through the platform. However, the application
only allows mass communication, usually by notices placed in the main course page, not allowing
the creation of special and differentiated communication channels, or the targeting of students de-
pending on a given criteria. So, it is easily concluded that despite the innumerable merits of the Fenix
service, this platform was not built with the aim of allowing that the relationship and communication
between the various school elements occurs in a fluid and natural way.
Based on an empirical observation, which was recently supported by statistics, it is possible
to observe that the rate of abandonment of the academic path and the failure rate in courses is
significantly high.
Thus, the major problem identified is that there is a dropout/absenteeism rate that is significantly
high, and that there are no tools available that allow the various responsible elements of the School
to timely identify risk behaviors that may lead to abandonment, and to interact with groups of student
in a closer and more personal way.
1.3 Goals and Contributions
Given the scenario and problem described above, it was concluded that the university could fight
this reality if it was able to understand timely which students are experiencing more difficulties and
are more likely to abandon their studies. To be able to act in this context, it is necessary that the
university develops mechanisms that enable the staff to get to know better the students, and how
their academic path is being developed.
As it is shown in the course of this document, the number and variety of elements in the univer-
sity environment that interact with students throughout their academic career is extensive. Thus, for
reasons that will be presented later, the scope of this work was limited to the relationship developed
between Students and Professors. More specifically, Professors who make up DEI.
Thus, The objective of this thesis involves understanding how a CRM initiative can assist in the
way that Professors at DEI interact with the students attending their courses.
The proposed system aims to make it possible to incorporate the personal information of students
and other data relevant to the monitoring of their courses throughout the semester, such as their
3
attendance at the classes. Furthermore, it is intended to give the possibility to create sub-sets of
students based on the analysis of the collected information, thus creating the possibility of managing
communication channels for custom identified targets. In particular, the main contributions of this
thesis are:
• Study on the business processes in place at IST, as well as what the real needs that can be
addressed with a CRM initiative.
• A compilation of information about CRM and successful CRM implementation initiatives in the
corporate environment, as well as in academic environment.
• Analysis of the adequacy of existing CRM applications in the market to a very specific type of
business (education and university environment), that has its own business processes.
• Design and development of an application to perform the collection of attendance in classes of
students of DEI, that at the same time may be connected to the CRM application.
• Implementation and adaptation of existing CRM solution on the market to the reality and needs
of the academic Department DEI.
• Set of scenarios and tests to demonstrate that the use of the application allows to perform the
activities identified more quickly and accurately.
1.4 Document Organization
This document is organized into six chapters. In Chapter 2 all the concepts needed to understand
the technologies and systems underlying this work are presented. Finally, case studies of imple-
mentations that were made in other areas are presented where it is possible to draw conclusions of
the results achieved.
In Chapter 3 an overview of the problem in question and the environment in which it operates is
presented. Subsequently a analysis of how the scope of the problem has been decreased to its final
structure is described, as well as the analysis that was made to existing systems on the market is
made. It is also presented the architecture and proposed solution to implement.
In Chapter 4 all steps for the completion of the proposed solution are described, and in Chapter
5 tests are presented to demonstrate the usefulness of the implemented solution.
Finally, in chapter 6 conclusions are drawn, and also future development in other iterations of the
project are presented.
4
Chapter 2
State of the art
In the first subsection of this chapter the CRM Fundamentals are presented, were the origin of CRM
systems is explained and which needs of the organizations are meet when implementations of this
systems are made. It is also clarified some key concepts and terminologies that are commonly used
in the CRM universe, and that are explored in this document.
Finally, some cases of CRM implementations in the business and academic environment are
presented, through which it was possible to draw some conclusions about how we should proceed
with the implementation of this solution, and what are the main obstacles usually identified and that
can lead to the failure of CRM initiatives.
2.1 CRM Fundamentals
The purpose of this Section is to make a introduction to what is Customer Relationship Management
and how this concept that is closely related to theories in Marketing as becomes a focus of study
and interest in the area of Information Technology. [21, 35]
In the subsection CRM History and Concept a brief introduction to how historically the concept
of CRM was born is presented, and how that concept is used by companies nowadays to work their
relationship with their customers, hence trying to derive maximum dividends from that relationship.
In this subsection we also look for a pragmatic and descriptive definition of what is CRM, based on
the extensive literature where this issue is discussed.
Subsequently, a glossary is presented in the subsection Key concepts in CRM, with definitions
of the key elements that are referred in this document, and that are associated with the specific lan-
guage and terms used in the CRM environment. During this document, a parallel is made between
the language used in the CRM world and the one that is commonly applied in the context studied in
5
this document. This is due to the clear differences in the nomenclature that is used in the business
environment and the one used in the academical environment, and that leads to concepts that are
presented with a nomenclature in the business environment and that are applied in the academic
world with a different nomenclature, although the final meaning to which this concepts refer are the
same.
Finally, in the CRM in a Organization subsection the impact of CRM initiatives on the three major
components of a corporate structure, the organization management, the business processes and the
technology is discussed. Given that the purpose of this document is to understand to what extent
CRM can help a university organization, we need to understand what impact CRM has on each of
these three concepts of the structure of a company, so it is possible to discuss in what elements of
the university environment the CRM should intervene.
2.1.1 CRM History and Concept
With the advent and massification of telecommunications (and specifically the Internet), the way that
a consumer can gather and compare information regarding products and services has changed dra-
matically. [28]
In the beginning of the 20th century demand outpaced supply of product and services, causing
some companies to neglect their costumers needs and characteristics, since it was almost granted
that most of the production would eventually be sold.
By the middle of the 20th century, this paradigm started to change, since the maturation of
the economy occurred to the point were consumers started to have a broader number of choices
regarding products and services, which forced companies to start paying more attention to the needs
of costumers and start to develop new marketing strategies according to the personal information
gathered about their customers (such as age, demographics and gender). Using this information, it
became possible to promote their products and services to subsets of costumers, starting to apply
a notion later called ”target marketing”.
In the 1980’s the economy reached a state of high maturation, making the selling of products and
services a hyper-competitive process. This lead to the appearance of the customer-centric vision,
were the goal is to create a positive experience to the customer throughout the entire purchase,
making the customers expectations and needs the center of the selling process in the company.
Along with this vision the notion of one-to-one marketing was revitalized, since this notion empha-
sizes personalized interactions with customers and thus leading to foster greater customer loyalty
and better return on marketing investment. The idea of one-to-one marketing was not new, since
in the past, for example, managers of a general store would take a one-to-one approach, remem-
bering details about each customer’s preferences and characteristics and using that knowledge to
provide better service. This makes a costumer feel that he is somehow special and that is treatment
6
is differentiated from the one given to other costumers.
Along with that, there were studies [10, 15, 23] developed were it was possible to prove that a
slight increase in customer retention has a very significant increase in profitability. So it became
clear to a large amount of company’s that despite the importance of increasing the number of new
customer acquiring their products, it was much more profitable to retain the current customers since
it represented more profit and less spendings to retain a existing customer then to acquire a new one.
A example of this situation may be view in Figure 2.1, where a McKensey & Co. study conclusions is
referenced by Russell S. Winer [38], where it is possible to infer that in the three categories studied
(customer attraction, customer conversion and customer retention) the greatest leverage came from
the retention of customers in comparison to customer attraction and customer conversion.
Figure 2.1: Impact of a 10% Improvement in Indicator on the Current Value of E-Commerce Firms
Combining the vision of customer-centric, to the one-to-one marketing approach, and the notion
that customer retention represents greater profitability then customer acquisition, it became clear
that it would be necessary to adopt a different kind of management, more focused on the client per-
spective and behavior over time. This new enterprise approach and management philosophy was
named Customer Relationship Management (CRM).
Although used in abundance, it is not simple to find a commonly accepted definition of CRM.
7
The difficulty in finding a broader definition arises from the multiple and different motivations that
companies have when implementing a CRM initiative, which leads to distinct ultimate goals.
When a company decides to undertake a CRM initiative it may have multiple goals [4], which may
include making a more effective segmentation of their customers, the implementation of marketing
campaigns for client with a given profile, manage the type of products or services available depend-
ing on the acceptance they have on the market, the identification of customers who represent the
best opportunity for cross-selling or up-selling, or even the reduction of direct and indirect costs.
However it seems a widespread idea that a CRM initiative always seeks a change of perspective, in
which the client becomes the main focus of the company’s processes, leading to the integration of
the companies various departments so that these initiatives may produce results.
Despite the difficulty in finding a consensual definition of what CRM is, there are definitions that
span multiple areas of activity of CRM [6, 15, 16].
One of that definitions is presented by Atul Parvatiyar and Jagdish N. Sheth [24], and possibly is
the one that better fits the notion of CRM:
Customer Relationship Management is a comprehensive strategy and process of acquiring, re-
taining, and partnering with selective customers to create superior value for the company and the
customer. It involves the integration of marketing, sales, customer service, and the supply-chain
functions of the organization to achieve greater efficiencies and effectiveness in delivering customer
value.
2.1.2 Key concepts in CRM
Being its main focus is in the business environment, it is important to clarify some of the terms that
will be used in this document, and that represent the vernacular used in the CRM industry. The
first concepts presented are related with the business perspective of CRM, the second concepts
are related with the logical separation of the CRM modules and functionalities of the applicational
component, and finally the concepts related to the characterization of the main groups of CRM pro-
cesses that can be identified.
The main concepts of CRM that are referred in this document and which are related to the
business component are:
• Account - Organization or company a user wants to track and/or sell a product or service, for
example, a customer, partner, or competitor.
• User - A human agent who has been given permission to access and use the CRM.
• Role - Roles are configured by an administrator and define visibility rights and operations for
people it is assigned to.
8
• Lead - A potential customer who must be contacted by a agent in the company and either
qualified or disqualified as a sales opportunity. Leads will be converted into accounts, contacts,
or opportunities if they are qualified. Otherwise they are deleted or archived.
• Profilling - The recording of a customer psychological and behavioral characteristics, so as to
assess or predict their capabilities of acquiring a certain product or service.
• Segmentation - Technique of identification, on the criteria chosen, of groups of potential cus-
tomers with the same requirements and needs. Usually four broad types of criteria may be
distinguished: Geographical (territory, region, housing micro-area), Socio-demographic (age, in-
come, sex, profession), Behavioral (purchase situation, user status) or Psycho-graphical (social
class, lifestyle, cultural class).
• Channel - A channel is whatever means the customers use to communicate with the company,
and vice-versa.
• Campaign - A marketing program designed to accomplish a specific result, such as introducing
a new product or increasing market share. The main way to accomplish this result is through
communicating the benefits of a product or service to people and businesses, using one or more
channels.
• Marketing - Marketing can be looked at as an organizational function and a set of processes
for creating, delivering and communicating value to customers, and managing customer relation-
ships in ways that also benefit the organization and its shareholders.
• Customer Service - It is the process where the customer is accompanied after he purchases a
product or service. This process may include the management of complaints, after-sales support
or management and renewal of the contract made during the Sale process.
Regarding the applicational elements, and considering that this is a relatively new area of study,
the number of frameworks [1, 25] that are broad enough to cover several application areas of ac-
tivity is still reduced. This means that considering the number of specific aspects of each of the
several areas that typically implement CRM initiatives, it becomes difficult to make a broad enough
generalization of the used structures so that a single framework covers most of the possible im-
plementations. Despite the difficulty in finding these frameworks, the one proposed by Malte Geib,
Annette Reichold, Lutz Kolbe and Walter Brenner in Framework Architecture for Customer Relation-
ship Management Approaches in Financial Services [17] was considered the most comprehensive
study on CRM frameworks, and in this framework three sub-categories of CRM systems are identi-
fied:
• Operational CRM - Operational CRM systems improve the efficiency of the processes that
have direct customer contact. The main focus involves coupling information from various sources
9
and present it in a useful way so it assists in processes such as marketing, sales and customer
service. It is closely associated with process automation.
• Analytical CRM - Analytical CRM systems store and evaluate knowledge about customers for
a better understanding of each customer and his behavior. They therefore support the CRM
analysis processes. Examples are data warehousing, online analytical processing (OLAP) and
data mining systems.
• Collaborative CRM - Collaborative CRM systems manage and synchronize the various cus-
tomer interaction points and communication channels.
As noted in the description of the three CRM systems sub-categories above, there is a strong
association between these sub-categories and CRM processes. There are three categories of CRM
processes, which are usually linked with the ultimate goal of the process. Although other process
may be identified [13], these are the three main types of CRM process:
• CRM delivery processes - Processes with direct customer contact that are designed to cover
part of the customer process (campaign management,sales management, service management,
complaint management).
• CRM support processes - Processes with direct customer contact that are not designed to
cover part of the customer process, but to fulfill supporting functions within the CRM context
(market research, loyalty management).
• CRM analysis processes - Processes that consolidate and analyse customer knowledge that
has been collected in other CRM processes. The analysis results are passed on to the CRM
delivery and support processes to improve their effectiveness (customer scoring and lead man-
agement, customer profiling and segmentation, feedback and knowledge management).
Despite this logical division of CRM process being very useful for defining the problem and how
the solution should be applied, its influence in the scope of this document is relatively small, since
the process of a student in a University deviates much from the process where a customer buys
a product from a company. However, the logical division has advantages when seeking to discern
what features and type of CRM to implement when defining a solution. Therefore, later in the docu-
ment some references to these cases will be made, and the differences between the definition given
above and their application in the academic scope will be discussed.
2.1.3 CRM in a Organization
The position of CRM in companies as been the target of some studies, and the changes that oc-
curred with the integration of this otherwise Marketing notion with the Information Technology area
10
has changed the way CRM positions itself in companies.
It is known that CRM initiatives can impact at three levels, and we will examine the impact that a
CRM initiative can have in each one of them. Depending on the objectives to be achieved with each
CRM initiative, its impact may vary in the three components that make up an organization. Thus, the
three organizational elements in which the CRM can impact are:
• Organization Management - At the organization management level, the impact of a CRM ini-
tiative may be seen from two different perspectives. On one hand, it is known that for a complete
and full CRM implementation, the initiative must be accompanied by strong support from top
management. This is common because such a profound change leads to a high level of resis-
tance, since it involves changing habits and routines performed by the company employees in
order to make the customer the focus of the attention. On the other hand there are cases, es-
pecially in multinational companies, where a CRM initiative leads to the creation of purely CRM
departments within companies. Normally these departments are constituted by multidisciplinary
teams, with elements of areas such as Marketing, Sales and IT, and are focused primarily on the
continuous improvement of the CRM initiative undertaken.
• Technology - The changes at the technology level may be more or less deep, depending on the
situation that the company is at the moment the CRM initiative is undertaken. In some companies
the changes are minimal, since the implementation of a CRM initiative leads only to the installa-
tion of the chosen application, and the migration or integration of data to be manipulated and/or
supplied by the CRM application. In other cases, changes to the technological level are more
relevant. In companies where the collection of customers data and interactions is lacking or is
non-uniform, or that the company’s own physical structure does not support the implementation
of a CRM system, or in cases where there are different CRM initiatives implemented individually
by various departments of the company, a deep technological change is required for the company
to be able to implement these initiatives.
• Process - Regarding the process level, a CRM initiative can have a very interesting impact. By
bringing a different view on how the company should relate with their clients, and the strong focus
on customer retention, in addition to acquiring new customers, many of the processes carried out
regularly in the company should be questioned and evaluated. Given that most companies have
a vision mainly focused on the product/service, this shift to a customer-centric view can lead to
some processes become obsolete or require major changes to how they are performed before
the implementation of the CRM initiative. It is quite common also the creation of new processes
in the routine work of the employees, in addition to the adoption of the CRM processes described
in the subsection CRM Key concepts.
Having a insight on the three levels that a CRM initiative can impact a company, it is intended
11
that at the end of this document conclusions may be taken about which/what levels in IST will the
CRM initiative impact, and why.
2.2 Academic CRM Implementation Case Studies
Despite being considered a project that carries some risk and that quite often leads to projects
that exceed the forecasted lifetime or the estimated budget, there are several examples of CRM
initiatives that have produced interesting results, and that in course of time presented a Return Over
Investment (ROI) considered relevant for the companies that implement them [20, 32, 33].
In the business world the number of success cases [6, 7, 12, 14] reported is significant, despite
the difficulties listed above.
By analysing these cases it is possible to draw some conclusions. The first is that CRM initiatives
are applied in various kinds of business, from financial institutions, the pharmaceutical industry [29],
through retailing [26], casinos, hotel chains, services industry [27, 30], etc.. However, each of these
areas of business has very particular specifications, which means that a considerable number of
adjustments to the more universal solutions has to be made in order to meet the particular needs of
each industry.
Secondly, it is possible to realize that a CRM initiative can have a wide variety of modules and
functionalities associated, and that the decision between these components is dependent on the
ultimate goal to be achieved, the current situation in which the company is at that time, and what
processes it implements and wishes to implement in the future.
Finally, the channels for which applications is developed may vary. Some applications aim for a
direct support of customer service, including call center, other applications may aim to assist sales
personal in face-to-face contact or via email with the customer, or even in some cases it may not
have the immediate objective of contacting directly with the customer, such as customer segmenta-
tion and marketing campaigns preparation.
In subsection Educational environment case studies two cases studies of CRM implementations
made in the academic environment are presented, where is possible to draw some conclusions
regarding the scope of problem studied in this document. In the subsection CRM impact in or-
ganizations case studies some case studies are presented and analysed, where it is possible to
understand the impact of CRM initiatives in non-educational organizations.
12
2.2.1 Educational environment case studies
The two case studies presented below were considered relevant to the issue discussed on this doc-
ument, since the area of business to which they apply is the same presented in this document.
The first is about the implementation of a CRM for tracking the application process of a student
at George Mason University, USA. [9]
In this paper the hypothesis tested is that it is possible to configure a CRM to meet the needs of a
university recruitment and application process, which is known that in the United States of America
is a time consuming and complex task. This hypothesis is tested with Microsoft/Great Plains eEn-
treprise application and it is concluded that this hypothesis is valid, which implies that the existing
commercial applications allow a large enough degree of customization so that is possible to adapt
them to the university environment.
This notion is further complemented with the book of Gary B. Grant and Greg Anderson [11],
Customer Relationship Management: A Vision for Higher Education. In this book, the authors argue
that with the adoption of a CRM business strategy it would be possible that all interactions with
the University could be made through a single entry point, which would have a full view of the
unique status of each student. They also claim that this would be an advantage for students, to
university staff and for the university itself as a entity, since it would remove some of the barriers to
communication that exist within universities.
This book refers also to the business component of the university since, as the article on the
implementation of CRM at George Mason University states, the implementation of a CRM to the
process of attracting new students and managing their applications could bring clear benefits to the
Universities.
Based on these articles it is possible to conclude that although there aren’t many known imple-
mentations of CRM in University environment, it might be seen as something feasible given that it
is a methodology and technology that has already had time to sufficiently mature in the business
environment, and as such can be applied to the academic environment.
2.2.2 CRM impact in organizations case studies
The following case studies allow to understand the issue presented in the subsection CRM in a
Organization. In this subsection it was discussed how the objectives outlined in the beginning of a
CRM initiative would affect different elements of the structure of an organization. As such, we intend
to look at some practical examples of implementations and realize the impact they had on those
13
organizations.
A case study that demonstrates the impact that the implementation of a CRM initiative can have
at the technology level is present in the case of H-Bank. [12]
The H-Bank is a retail bank with about 19 million customers, which arrived to the conclusion
that it needed to implement a project that allowed the integration across multiple communication
channels with the existing source systems. For that, H-Bank decided that it should implement a
CRM application that allowed it to integrate these systems and communication channels, so that it
could manage all communications with customers in a transparent and coordinated manner.
While planning this implementation it was possible to understand that much of the work involved
would be related with the integration of databases containing redundant customer information, and
the need to standardize the identification of customers across these databases, since at one point it
was possible to realize that the data gathered until then was inconsistent. This need for integration
of information was such that the H-Bank had to create a new data warehouse as a consequence of
the implementation of this initiative.
Through this case study it was possible to conclude that this CRM initiative imposed that the
changes at the technology level to be clearly superior to the changes made at the other levels, and
this was due largely to the ultimate goal the company set out to achieve.
In the case of First American Corporation, the major impact that the implementation of a CRM
initiative had was at the process level. [6]
The First American Corporation is a comprehensive financial-services holding company, which
went through dire financial times. With the arrival of a new management, several options were con-
sidered for the company’s future, including the chance of becoming a low-cost provider. Ultimately,
the decision taken stated that their competitive advantage in the long term would be to know their
customers exceptionally well, and then starting to create new products that would meet the cus-
tomers needs and expectations.
To achieve this vision for the future of the company it was decided that a implementation of a
CRM solution that could support the requirements would be essential to the breeding of this new
reality. At the same time the CRM application was implemented, a significant amount of procedures
for customer contact and decision making of the company were created or redesigned, so that the
processes reflected the focus on the customer needs and to bring forth out of the predictive ability
that a application like CRM allows.
In the eight years that followed the company has experienced an exponential increase in rev-
enue, down from a deficit of 60 millions/year to a positive balance of 221 millions/year. Besides
being a paradigmatic example of what a complete CRM implementation should be, this case study
14
demonstrates a example in which the main element of the organizational structure to be affected by
the implementation of a CRM initiative is the process level. Despite the fact that the technological
and organizational components played an important role in change, the main element to be affected
was clearly the process component, since the objectives outlined forced a redesign of internal and
customer contact processes.
15
16
Chapter 3
Problem Analysis and Proposed
Solution
3.1 Introduction
This chapter is intended to explain the process that was followed for the definition of the problem
described in this document, as well as describing the solution proposed for the resolution of the
problem.
In section Objective Scope a description of the IST reality is performed and the various elements
of the university that may be the target of a CRM initiative are analyzed. It is also presented a
reduction of the scope, which allows the definition of a set of users for which it will be implement the
CRM initiative.
In section Formalization of goals tangible goals that allow the fulfillness of the higher-level defined
goal of this initiative are set, so that the evaluation in the end of the implementation may be done in
a more concrete manner.
In the Non-functional requirements section a list of non-functional requirements that allowed the
identification of a group of CRM applications that deserved further analysis in order to identify the
application to use. The identification and description of the methodology that supported this choice
is presented in chapter Analysis of possible solutions.
The Use Cases chapter presents user cases for each of the types of users that benefit and
use the application, taking into account the type of activity that each one of this group of users will
develop and the information that should be accessed by each one. These use cases will be used to
evaluate the success of the implementation of the CRM application.
Finally, it is presented in the chapter Proposed Architecture the components of the solution to be
put in place, and the relationship between them.
17
3.2 Objective Scope
This section explains the process that was followed for the definition of the problem stated in this
document.
The genesis of this Thesis was defined as the need to find a way to better manage the rela-
tionship between students and other members of the university, as well as realize how it would be
possible to monitor the students academical path during the time they are in the university. Thus,
students can be seen from the CRM perspective as a account, since they are the entity on which
we want to keep track. Based on this concept, it was then necessary to study the environment sur-
rounding a student during their experience at the university, and understand what are their points of
contact and where much of his experience as a student resides. From the moment it was possible
to identify which of these contact points and agents interact with the students, it would be possible
to consider the areas which would create a more one-on-one relationship with the student. It would
then be possible to identify who are the users of the CRM application.
To make a better characterization of this problem it was decided to conduct a series of interviews
with various elements with different roles in the university, in order to realize where it would be
possible to improve and monitor more effectively the relationship between the university and the
students. It was concluded that it would be relevant to talk with three types of distinct elements of
the university: The administrative services of the Departments, the Office of Support to Tutoring,
and the Professors.
It was not considered necessary to speak with other students, since this document was written
by a student, and therefore this perspective was already covered.
In the subsection IST Structure and Departments is presented a description about the environ-
ment in which the objective of this thesis is incorporated, as well as a survey of the current situation
regarding the scope of the issue.
After the presentation of the conclusions drawn for each of the elements of the university, the
arguments that led to a reduction in the scope of this Thesis are presented, as well as a clear and
concise definition of the ultimate goal to achieve. This is presented in subsection Reduction of the
Scope.
3.2.1 IST Structure and Departments
Instituto Superior Tecnico (IST) is a Engineering University, based in Portugal. The university offers
Bachelors and Masters programmes, some of which operate in an integrated manner as defined
18
in the Bologna model. Usually a Bachelor lasts three years, followed by a Master component that
normally lasts for two years.
The Bachelor component is divided into semesters, and in each semester are taught a series of
courses. Each course is composed of a sequence of classes where the program of the course is
exposed, and each course must have one or more Professors.
In the Master component, during the first year classes are taught and in the following year stu-
dents are asked to develop a Master’s thesis. This Master thesis is divided into two components with
different evaluations. The first part is called Master Project, and its aim is the study and design of a
research project. The second part is called Master Thesis whose aim is to implement the research
project defined in the Master Project.
IST also offers Doctoral and Postgraduate programs, however these two formative opportunities
are outside of the scope of this project, since it was clear from the beginning that it would not be
feasible to include these two areas in the objectives of the thesis.
Administrative Services of the Departments
The administrative services primary function is to provide support and assist in the management of
the work performed by each of the departments, alongside providing support to students of courses
that are under its jurisdiction.
The administrative services interviewed were from the Department of Informatics Engineering
(DEI) and the Departamento de Engenharia Electronica e de Computadores (DEEC)). DEI is re-
sponsible for 3 Bachelors and 4 Masters programs, while DEEC is responsible 4 Bachelors and 4
Masters programs.
During these interviews it was possible to understand that despite some differences in the way
activities are performed that are largely associated with the staff of the administrative services of the
Departments methods, the processes are very similar. This similarity in the processes accrues from
the fact that these departments work in courses that have a similar structure, therefore there is no
identification of the departments in the conclusions taken, since they are consensual.
It was also possible to understand that most of the problems presented by the departments were
largely related to day-to-day functional issues. Regarding the contact with students, they occurred
mainly for two reasons: The follow-up of requirements posed by the students, and the management
of data related with the theses.
In the follow-up of requirements posed by students the role of the administrative services is
mainly functional, since usually the administrative services is just a means of passing information
19
between the Coordinators of the Departments and the School Secretariat.
Regarding the management of the theses data, the administrative services of the Departments
has a more active participation. In the first phase they are involved in the presentation of the avail-
able theses to the students. Later, its scope is the collection of all the information related with the
thesis that are going to be presented and defended, being also in charge of the release of informa-
tion on the evaluation of the theses among thesis Juries, of advisors and the student community.
At this point, both departments stated that it was difficult to maintain data on the theses updated
and organized in a coherent way, and reported that at this time the Department is unable to keep a
sheet with the state in which point the students theses are. This information would be relevant, since
empirically the Departments can say that the dropouts rates in Theses are relatively high, however
they are not able to quantify these rates, nor they can do a individually follow-up on the state of each
student who is developing a thesis.
Although it is possible to conclude that the role of the Administrative Services of the Departments
is very important to ensure that the career of students during their courses is as free of obstacles
as possible, it was also possible to conclude that the direct contact with students is wispy. This is a
consequence of the fact that much of the work performed by these services being of back-office.
Office of Support to Tutoring
At IST, the Tutor is a Professor that accompanies a group of students of 1st and 2nd year of the
Bachelor degree in a more personalized way, looking for these students to develop the full potential
of their intellectual, emotional and interpersonal heritage, fulfilling the goals of excellence teaching
that IST proposes. This project is a follow up of an analysis in which it was concluded that the rates
of dropouts in IST degrees was very high during the first two years, and so the board of IST believed
that it would be possible to reduce this rate if a closer monitoring of each student by a Tutor existed.
Thus, the mission of the Office of Support to Tutoring is to help in creating a bridge between
students and Tutors, offering for this purpose training, monitoring and follow-up to both parties.
In the interviews with some of the elements of the Office of Support to Tutoring, the main problem
identified was related with the lack of information that could complement the information already
gathered by the Office. The Office only has access to information about the status of the students at
the end of each semester, precluding a more timely intervention from the Tutor so that it is possible
to understand what is happening with students who are not having the desired performance. The
type of information that the Office indicated that it would like to access was the grades of evaluations
made during the semester, as well as information on class attendance. The Office also noted that
20
although this kind of alerts are important for the staff of the Office, it is even more important for
tutors, who often fail to identify problems in the performance of their students, sometimes making
their intervention to arrive late.
Another issue raised by the Office is the difficulty in communicating with students, since nowa-
days the multitude of communication channels is large, which makes any attempt to easily get in
contact with a student to get lost in the world of digital communications.
After the meetings with the Office it was possible to conclude that the weight of the Office in a
possible improvement in student performance can not be neglected. It was also possible to conclude
that the Office is well supplied with tools that allow the support of day-by-day activities developed
by the collaborators. The gap indicated and identified concerns with the lack of information (which
is often not available because it is confidential) and that sometimes causes the intervention of the
Office and Tutors to not arrive in time.
Professors
Of all the elements of the university that were interviewed, the Professors are surely those who have
the most direct contact with students. A professor may have several roles, including being responsi-
ble for a course, be a advisor in a thesis, be a Tutor, or even be the Coordinator of a Department.
Regarding the management of the courses, it was often referred by Professors that it is quite
difficult to maintain a relationship with all of the students, especially when dealing with large classes.
It was also noted that many students have difficulty in addressing a Professor by their initiative, thus
making it even more complicated the interaction. The beginning of this interaction becomes even
more complicated when students rarely attend classes, since currently the Professors have no way
to monitor the attendance of students to classes.
Thus, when asked how the Professors think it would be possible to provide closer monitoring
to students, the general response was that the ideal would be the possibility of identifying students
who attend fewer classes, and after the identification of those students there was the possibility of
creating a communication channel with them. By creating this communication channel it would be
easier to encourage students to present their difficulties, and so the accompaniment provided would
be bigger. When making the targeting of students that did not attend classes, Professors would be
able to communicate with them in a more personal way, making the student feel that they were the
focus of individualized attention by the Professor.
Although it was not possible to interview the Department Coordinator, it was possible to interview
a Professor that works closely with de Department Coordinator, and through this it was possible to
get to know the point of view and the reality that the Coordinator faces. Regarding the thesis, the
21
Department Coordinator feels that the number of students who does not finish their Master thesis
is quite high. Therefore he think it would be very interesting if somehow it was possible to identify
students who are idle in their thesis for some time, and to understand the reasons that led to the
abandonment or momentary stop of their thesis. Furthermore it would be very important to get
statistics about this students, so that he may consider new ways to attract them to complete their
theses.
It was also mentioned the decision to start making the collection of attendance in classes, and
that it would be quite interesting for the Coordinator to access statistics relating to attendance at the
several courses that make up the Department.
3.2.2 Reduction of the Scope
After the interviews described in the previous subsection, it was possible to draw some conclusions
that helped reduce the scope of the problem and to prove that a CRM initiative can bring value to IST.
Regarding the Administrative Services of the Departments, it was possible to identify the lack of
some tools that could make the task of managing the students and their information more efficiently,
and that would allow the Services to do perform their daily tasks in a simpler way.
Despite the advantages that the implementation of CRM could bring in this issue, it was con-
cluded that the majority of the business processes in the Administrative Services of the Depart-
ments does not lead to any direct contact with students, although this processes aims to facilitate
the course of the students during the semester.
Thus, given that the main objective is to make a closer and more personalized monitoring of
students during the semester, it was concluded that implementing a CRM system to support the
business processes of the Administrative Services would be more beneficial to the staff than for the
students. As such, it was clear that these Services should not be the main focus of this initiative.
Despite this, as explained later in this chapter, the Administrative Services of the Departments
eventually became one of the two groups of users of the implemented CRM application.
Regarding the Office of Support to Tutoring, it was possible to understand that this is an Office
which has an important role in monitoring the students performance. It was also possible to verify
that this Office is currently well-stocked in applications that enable the monitor of the students, as
well as to carry out statistical analyses that are required of this Office. Despite having the necessary
applications, the Office feels that the major limitation is related to the limited access to information
during the course of the semester, since much of the information about the performance of students
is only available upon termination of the semester.
Despite being a important component of the university environment, this Office has the role of
22
being a intermediary between Tutors and students, since the actual monitoring and contact with stu-
dents is done by the tutors. Note also that the role of this Office is limited to the first two years of each
student, and focuses primarily on the integration in academic live, more than actually monitoring the
academic performance.
Regarding the usefulness of implementing a CRM system, it was concluded that this would not
be the set of users that most benefits could get from this initiative. Given that the aim is a compre-
hensive and close monitoring of students during the semester, it makes no sense to limit this support
to students who are attending the first two years of course. Another reason that contributed to the
decision to withdraw this Office of the scope of this thesis lies in the fact that users of the application
would not be the elements of the University who have direct contact with students. As mentioned,
the elements that actually have contact with students are the Tutors, which are Professors of the
university.
Regarding the Professors, this user group was identified as being the element of the university
environment in which it would be more relevant to implement a CRM initiative.
With the analysis of the interviews conducted it became clear that the Professors are those who
maintain a closer relationship with the students, presenting themselves as the ideal group for an
initiative that aims to lead to a closer relationship between the university and the students.
Currently the process of monitoring the students throughout the semester is done in a empiri-
cal way, being based only on the information gathered by Professors resorting to observation and
instinct. Thus, it is believed that with the implementation of a CRM it would be possible to collect
and organize data in a more organized way, becoming possible the early identification of potential
problems in the students productivity.
This is a typical customer retention case, since the aim is to in a early stage identify customers
who are leaving the company’s service, which in this case are the classes taught by Professors.
Thus, since the ultimate goals are profiling, segmentation, customer retention and lead manage-
ment, this is the kind of scenario where the implementation of a CRM application and the creation
or modification of some processes carried out within the company can bring big benefits in to the
management of students along their academic path, and more specifically during a semester.
After choosing the group of users of the application, it was still necessary to decide to what
business process would make more sense to implement the solution.
In this context there were two options, taking into account the type of role that a Professor may
have during the semester. The options regarded the implementation of a CRM system for monitoring
of courses taught during the semester, or for the monitoring of the Thesis by the Professors that
guided them. It was concluded that the Thesis process leads to the creation of a more personalized
relationship with students, since that the Professors usually have a relatively small group of students
23
developing their Thesis, and that by the very nature of the work, the relationship has to be more
close and personal.
It was then concluded that it would make sense to implement the CRM system for monitoring
the courses taught during a semester, since it would be possible to achieve a larger amount of con-
clusions about the usefulness of the system, since the number of users of the application would be
much greater and the number of students able to collect the benefits of this implementation would
also be greater.
Taking in account the greater general goal of the Thesis and the reduction of the scope, it be-
comes possible to define that the ultimate objective of this Thesis undergoes the understanding of
the benefits of implementing a CRM initiative to monitor the performance of students during
a semester, by the Professors of the courses of DEI.
3.3 Formalization of goals
In the previous subsection it was stated that the final objective of this thesis is to understand the ben-
efits of implementing a CRM initiative to monitor the performance of students during the semester,
by the Professors of the courses of DEI.
However, to make this a more tangible goal, it is required to list clearly how this can be achieved
with concrete actions, what data must be collected, which are the users of the application and who
will benefit from its implementation.
To achieve the objective described above, it was considered that the best way to monitor the
performance of the students through the semester would be to provide to Professors a CRM tool
that allowed them to assemble relevant information about the students and on their performance
throughout the semester. Additionally, it was considered that the ideal would be to allow the CRM
tool to be also a point of aggregation of communications made with the students, so that a history of
interactions could be kept, as well as being able to do mass communications to specific groups of
students.
Concerning the data obtained, it was considered important for the Professors to be able to have
access to the most common and useful information regarding students. These data includes per-
sonal information, such as their contacts, and even academic information such as chairs that they
are registered and what are their courses.
Additionally, benefiting from the fact that the attendance collection is now made in the courses
provided by DEI, it was considered that it would be very important that the application would allow
the collection and processing of data of attendances, to be possible the profiling and segmentation
24
of students attending the courses, becoming possible a broader perspective of each student perfor-
mance and behaviour.
Regarding the users of the CRM application, there are two distinct profiles. On one hand we have
the Professors, whose main focus is to query information aggregated and treated in the application
and to perform some actions based on that information. On the other hand we have the administra-
tive staff of DEI, which role is the introduction into the application of data on attendance of students.
The distinction between these two types of users is relevant, since the type of access to data for
each group is different. In particular, it is intended that the type of profile of the administrative staff to
be more limiting, since it is not intended that they are able to access data and a set of functionalities
to draw conclusions about the performance of the students.
Taking in account the primary objective to be achieved with this CRM initiative and considering all
the decisions referred above, the following actions were identified as the way to achieve the ultimate
goal:
1. Implement a CRM application for aggregating relevant information on students
2. Make the introduction of the attendance at classes in order to enrich the information on stu-
dents and allow a personalized support
3. Getting to profile and segment students, by applying filters and analyses to the data collected
over time
4. Allow the performing of mass communications based on the profiling and segmentation of the
students
3.4 Non-functional requirements
Given the multiplicity of CRM tools available on the market, the first step of this application sur-
vey was to make a list of non-functional requirements that limited the number of applications to be
tested with more depth. Thus, the three non-functional requirements considered crucial so that the
application could be implemented were:
• The application must have a free version;
• The application must be open source;
• The maximum number of users of the application should be non-existent, or at least big enough
to cover the needs of the solution proposed;
25
The first non-functional requirement is that the applications tested and used should include a
free version that can meet all the other functional requirements that will be presented later. This
requirement arises due to some financial restrictions implemented by IST, even more taking in con-
sideration that the commercial solutions studied showed highly onerous values of licensing.
The second non-functional requirement was related with the need of the application being open
source. This requirement arose after the realization that there are two major classes of CRM ap-
plications, Generalist and Go Vertical. The Generalist applications intent is to be broad enough to
achieve the needs of various types of businesses. On the other hand, Go Vertical applications are
usually developed for specific types of businesses, which normally have very specific requirements.
Examples of this business are the pharmaceutical and the automotive industry.
Ideally we would seek to apply a solution of the Go Vertical type to the university environment,
since many of the specific requirements of this business would be covered at the outset, however
because the educational market is still relatively closed to CRM solutions, the existing Go Vertical
solutions are commercial, and therefore not applicable. As such, bearing in mind the need to choose
a solution of the Generalist type, it is necessary that this solution is open source, since it is crucial
that we are given the opportunity to perform the configurations and development of modules on the
application base code.
Finally, the application should not have a limit to the number of users or, if having a maximum
number of users, that number must be large enough to cover the needs of the solution to be im-
plemented. Considering the hypothesis that this solution is intended to be scaled to the point that
covers all of the School courses and Departments administrative services, the application maximum
number of users must not be a constraint to the scalability of the solution.
3.5 Analysis of possible solutions
After the analysis of several case studies of CRM implementations in companies [37] , as well as
analysis of commercial applications in order to understand what were their major advantages and
what could be learned from their know-how, it was necessary to assess the CRM applications that
met the requirements necessary for the implementation of the hypotheses raised in this document.
From the list initially collected, four applications were chosen that met the non-functional require-
ments stated in the Non-functional requirements section. The following subsections contain a short
presentation about those application and the companies that develop them. When possible, some
case studies of implementations are presented, showing examples of implementations that have
26
occurred successfully using these applications and presenting relevant findings to the context of the
problem studied in this document, or examples were is possible to understand that each application
complies with the non-functional requirements listed above.
3.5.1 SugarCRM
The SugarCRM application is developed and owned by SugarCRM Inc., which was founded in 2004.
It is the heavyweight of CRM open-source solutions [3], having in recent years received a large
number of awards among which stands out the winner and leader in the categories of Open-Source
CRM,and the Midmarket Suite CRM and Sales Force Automation prizes, delivered by CRM Maga-
zine in 2012.
This application complies with the non-functional requirements stated as needed. The free ver-
sion of this application is called SugarCRM Community Edition, which is a completely open-source
version and does not have any limitations as regards the maximum number of users. Although the
free version has fewer features than any of the other paid versions, SugarCRM provides two plat-
forms (SugarForge and SugarExchange) where developers may gather to create new modules, or
even to use modules developed and shared by other developers. This platforms are a great way
to complement the free version of SugarCRM, making possible a greater customization of the base
version. The application version tested for the porpuse of this thesis was 6.5.15.
Being a very popular application, the amount of case studies using this solution that were suc-
cessful is fairly high. Two cases in particular deserve further attention, since the focus of those cases
are implementations that use SugarCRM, and that were implemented in the university environment,
the same environment that this document focus.
The first case study reports the use of SugarCRM in Singapore Institute of Management Uni-
versity (SIM University)1. SIM University is a school for adults already in the labour market, which
came to the conclusion that it needed to provide a more personalized treatment to their students
and prospective students. After studying the various possibilities to upgrade de way how students
where treated, SIM University reached the conclusion that the best way was to implement a CRM
initiative that included in increment in the service provided over the University call-center. In the ser-
vice provided by the call-center two business process were identified, one related with meeting the
needs of students already enrolled, and a second process through which marketing of the courses
offered to prospective candidates who came in contact with the call-center was made. Thus, through
the implementation of SugarCRM, particularly of the Service and Marketing Automation modules it
1http://media.sugarcrm.com/case studies/SIMUniversity.pdf (retrieved at October 2013)
27
became possible to provide a more personalized service to students, making the resolution of inci-
dents more quick and efficient. Clear improvements were also noted in the recruitment process of
new students, especially after the first contact with the prospective students, since the information
gathered in the first contact allowed the collaborators in the call-center to be able to provide more
accurate and precise information to the prospective students, having in considerations the interest
showed in the previous contacts.
The second case study relates to the use of SugarCRM at an Australian university, Macquarie
University2. In the case of this implementation the objectives achieved are clearly broader than
those achieved in the previous case study. In the case of this implementation it was intended to
create a platform that could be used for several services and with various purposes. The objectives
were to create a new and improved set of student management services, centralize the University’s
application process, the integration with the University call-center, and the integration with social net-
works. In the future, it is intended that this solution allows post-graduate researchers and students
to be able to contact with the right academics when doing their research. This implementation has
a broad scope, but unfortunately there are no major technical papers available on the implemented
solution. This is largely due to the fact that the implementation in question was performed by a pri-
vate company, despite having used the free version of SugarCRM.
In the first case study the implementation of the CRM led only to a change in the processes that
were in place, since the information was already available and the amount of technological compo-
nents added was minimal. In the second case study, the implementation of the CRM solution lead to
a change in the processes, but also a change in the technological component of the company, since
Excel spreadsheets and papers were replaced with relational databases and physical equipment to
enable the desired change.
With this two case studies it was possible to conclude that the SugarCRM application has a
sufficient degree of customization to perform well in a implementation on a particular environment
such as academic environment, at least with the requirements of the two case studies presented.
Another conclusion from these two case studies is that the scalibility of the system doesn’t constitute
a problem to implementations that include a reasonable amount of systems user and of information.
2http://www.cio.com.au/article/455224/macquarie_university_goes_open_source_sugarcrm/ (retrieved at Octo-ber 2013)
28
3.5.2 Zurmo
Created by Intelestream Inc. which was founded in 2010, Zurmo is a fairly recent application which
just had its first release in December of 2012. What differentiates this application from other tested
is the introduction of the concept of gamification into CRM. By creating a system of virtual rewards
for the frequent user of the CRM, Intelestream Inc. intends to strike one of the biggest barriers to
the success of a CRM initiative, adherence to the use of the CRM application.
This application complies with the non-functional requirements presented as needed. This appli-
cation has only two versions, the Free Version and Pro Version. The difference between these two
versions is not in the amount of modules and features available, the difference is that the Pro version
offers technical support and hosting, if required. The Free Version tested is open-source and has no
limitation regarding the maximum number of users of the application. The tested version was 2.5.7,
which was considered the latest stable release, and was released in November of 2013.
Given that Zurmo is a fairly recent application and with a small market share, the existing case
studies on implementations in which this application was chosen are relatively low, and with little
practical conclusions. Still, there are some examples of implementations in areas as distinct as
management of state resources3, real estate companies4 or digital strategy firms5, which proves
that even being a recent company the application is having an interesting market acceptance.
3.5.3 VtigerCRM
The VtigerCRM is a application owned and developed by the company Vtiger, which was founded
in 2004. The initial idea of VtigerCRM is to be a fully open source CRM application, since all the
features are free of cost and its code can be manipulated without restrictions. Having appeared in
the same year of SugarCRM and being a fork of this application developed by a group of former
employees of SugarCRM, the major difference between these two applications lies in the fact that
VtigerCRM doesn’t sell modules or functionalities in their paid version of the application. All of the
application features are free and depend on the user community for its development. The Vtiger-
CRM has only two versions, a completely free version and a second version titled VtigerCRM On
Demand, where the only difference is that it is a cloud-based version, which as a greater degree of
support by the company.
Regarding the non-functional requirements defined as crucial, the VtigerCRM application meets
3https://zurmo.com/case-study-srclogic (retrieved at October 2013)4https://zurmo.com/case-study-ecksodus (retrieved at October 2013)5https://zurmo.com/case-study-brilliant-noise (retrieved at October 2013)
29
all of the needs. The version tested is both free and open-source. Regarding the number of users
that the application supports, no reference to limitations was found in the documentation read. The
tested version of this application was 5.4.0.
Being present on the market for quite some time, and having a very large user base, there are
countless examples of implementations with a high degree of success using VtigerCRM. Since it
was not possible to find any documented case study within the educational environment in which
VtigerCRM was used, a relevant indicator of the quality and customization level of the application is
the fact the University of Brescia has chosen VtigerCRM to be used as reference application in the
practical component of the ”Sistemi per il CRM” course. 6
3.5.4 CiviCRM
Having appeared in 2005, the CiviCRM application has in its foundation relatively different ideas
from the ones of the three applications presented previously. CiviCRM’s main characteristic is the
fact that it delivers a solution that targets mainly companies/organizations that are non-profit, non-
governmental or advocacy groups, and from this perspective it represents a Go Vertical solution,
while the three previously presented solutions are clearly of the Generalist type. At the technical level
it also presents a differentiating characteristic, since this solution has to be deployed in conjunction
with a Content Management System (CMS) in order to maximize and personalize the interactions
that customers have with the company’s website. Among the most popular CMS, CiviCRM features
compatibility with Drupal, Joomla! and WordPress.
All of the non-functional requirements were met by the application, since the tested version is
free and with no limitation to the number of users. CiviCRM is also a open-source solution. The
version of the application used in the test environment was 4.4.0, which was combined with version
2.5 of Joomla!.
A good example of the implementation using CiviCRM is presented by QuestBridge - National
College Match Program. This non-profit program aims to assist students with a good academic
record and from families with low incomes to submit applications for educational and scholarship
opportunities at some of the USA’s best colleges.
The application process for a considerable part of the American colleges is relatively complex
and time consuming. Applicants have to fill several different forms, depending on the needs of each
of the colleges that they apply, which in many cases leads to the duplication of information in different
forms. QuestBridge realized that the organization could help more students if they had a system that
6https://www.vtiger.com/blogs/?p=655 (retrieved at October 2013)
30
could store all the information gathered in a single questionnaire filled by the applicants, and this in-
formation was subsequently distributed by all the forms of the colleges that students were applying.
At the same time, QuestBridge realized the difficulty that represented managing the communications
with students and colleges after the delivery of the applications, since this process often lead to a
constant communication between the three entities involved.
To resolve the two identified issues, the CiviCRM application was used to create a single form
in which the information was subsequently redistributed by various forms of each of the colleges,
depending on the information that each of them required. Using also the CiviCRM, a process was
implemented in which all communication with applicants and colleges began to be recorded in the
application, thus improving the knowledge of each case and the current situation in which each
application was. For the implementation of the solution three CiviCRM features were used. The
Case-Management and e-Communications modules were used to provide for the management of
contacts with students and colleges, while for the management of information collected from the
candidates, the Constituent Contact Management module was used, which allowed the collection
and further processing of the applicants information.7
With this case study it was possible to conclude that the CiviCRM application has a sufficient
degree of customization to perform well in a implementation on a particular environment such as
University environment. Another conclusion to withdraw from these case study is that the scalability
of the system doesn’t constitute a problem to implementations that include a reasonable amount of
systems user and of information.
3.5.5 Comparison between Technologies
After the selection of the applications that fulfill the non-functional requirements, it was necessary
to create a procedure to choose the application that was most adequate for the goals of this Thesis
[31]. The procedure in question is explained below, as well as the criteria used for evaluating the
applications. To score each of the criteria evaluated the information collected about the companies
and the applications was used, as well as the implementation of test cases for each application.
For the procedure of choosing the application to be used, a combination of two decision mak-
ing processes was created. The two decision making processes used for this combination where
Weighted Decision Making Process (WDMP) and Analytic Hierarchy Process (AHP)) [5, 34]. None
of these process was used individually due to the fact that the WDMP methodology was considered
too simplistic, and on the other hand in was considered that the AHP methodology would entail a
7https://civicrm.org/casestudy/node/1488 (retrieved at October 2013)
31
high level of complexity considering the time available for the completion of the application choice.
The decision making process created took advantage of the notion of hierarchy often used in
AHP, and two hierarchical levels were created. In the first level three categories considered the
most relevant were created, and at the second level were included the criteria considered relevant,
grouped by each one of the three categories defined above.
From WDMP the concept of weights was applied, that were assigned to the three categories
mentioned above, as well as to criteria contained inside them. It was also used a scale of 0 to 10 to
classify the performance of each application on each criteria being evaluated. When rated with 0 it
means that the application does not provide at all the requirement stated in that criteria, on the other
hand, when rated with a 10 it means that the application fully meets expectations for that require-
ment.
In the subsection Selected Categories the three top categories are presented and explained. In
the subsection Criteria clarification and Application Scoring the criteria are grouped within each of
the three categories, and for each of the applications scores in all of the criteria is presented. Finally,
in the subsection Conclusions, conclusions derived from the scores obtained by each of the appli-
cations are presented.
Selected Categories
The first step in the decision making process was to create three major categories considered as
being relevant to the choice of the application, and assign each of those categories a weight accord-
ing to its relevance to the final decision. The categories chosen as well as the weights assigned to
each one of them are shown in Figure 3.1.
Figure 3.1: CRM application selection, categories and weights
The three categories chosen were Company Information, Product Information and Modules/Functionalities
required.
In Company Information the criteria related to the stability and position in the market of the
company that develops and supports the application is compiled. This category was assigned a
weight of 10%. Despite the stability of the company and of the application offered being relevant,
32
Table 3.1: Criteria per category, and respective weightsCategory Criterion Weight
Company InformationSystem mature and stable 0.20Customer base 0.10Development Community 0.35Application update frequency 0.35
Product InformationOn-premise solution 0.25Available Documentation 0.20Web-based solution 0.25Portuguese Language pack 0.20Development using industry standard technologies 0.10
Modules/Functionalities RequiredService Automation Module 0.10Marketing Automation Module 0.10Custom reports creation 0.15Email Integration and IMAP configuration 0.20External Database feeding 0.10Data import/export tool 0.05Scheduling of reminders, alerts and pop-ups 0.10SSO integration 0.10Role creation 0.10
it is not considered that this category should override categories related with the characteristics or
features offered by the application.
In the Product Information category, the criteria related with specific characteristics of the appli-
cation is grouped. This characteristics are not related with features/modules needed for the imple-
mentation of the hypothesis raised in this thesis, but with general characteristics of the application.
This category was assigned a weight of 30%, since it is considered important that when proceeding
to the choice of the application that it fulfils some specific criteria, which will be described later.
Finally, the Module/Functionalities Required category compiles criteria related with the mod-
ules/functionalities deemed necessary, and to be included in the evaluated applications. This cate-
gory was assigned a weight of 60%, since the features/modules that were grouped in this category
are considered relevant to the implementation of the hypothesis raised in this thesis, and that without
these relevant features/modules the realization of the hypotheses raised is very difficult.
Criteria clarification and Application Scoring
In Table 3.1 it is possible to verify all the criteria selected and that were grouped in each category,
as well as the weights that were assigned to each of the criteria.
In the Company Information category, the Active Development Community criterion took into
account the existence of forums for the development and discussion of modules/functionalities, as
33
well as the amount of functionalities that are available for applications in those forums. In addition,
it was taken in account the number of registered users on those platforms, which is a sign of how
active is the development of the application.
In the Product Information category it was taken into account the need of the application providing
a on-premise and web-accessed solution, since the need to access and manipulate information
regarding the various elements that constitute the university, it is advised the implementation of
an on-premise solution. Another criterion is related to the need for existence of consistent and
relevant information about the installation and configuration of the applications, since the need of
manipulation of the base code of the application is necessary.
Regarding the Module/Functionalities Required category, the criteria assessment was based on
the objective stated in this thesis, and the modules/functionalities listed above are the ones consid-
ered necessary for the implementation. In spite of all of these features were considered necessary
or that the possibility of their integration would be relevant, its importance for the final solution is not
the same, as it may be seen in the difference of weights that each criteria has in the final evaluation
of the category.
Of these, the highlight goes to the presence and quality of the Service Automation and Marketing
Automation modules, as well as the possibility of creating alerts and pop-ups that are intended to be
used in conjunction with the Email Integration functionality. Also note the need for the application to
allow the creation and assignment of users to roles, since the restriction on access to some of the
available information is a very important issue, and the presentation of the relevant information for
each type of user greatly influences the acceptance of the application by the users, and the usability
of the application is one of the factors leading to acceptance of the new process to implement.
The possibility of having external feeding of the database with relevant information is also rel-
evant, since it is plausible the need to have external applications gathering information that later
should be handled by the CRM tool.
In Table 3.2 the evaluation that each of the applications had in the several criteria is presented.
Conclusions
After performing the necessary calculations, it was possible to reach the conclusions presented in
Table 3.3.
Analysing the results obtained, it is possible to verify the good performance of the SugarCRM
application, which presents the best global result, and is also the application with the highest score
in all of the individual categories.
This is mainly due to the fact that it is a company with a large presence in the market, having a
very broad customer base and combining this to a very active development community. SugarCRM
also presents great results in the criteria related with the specific characteristics of the application,
34
Figure 3.2: Application evaluation
Figure 3.3: Application final scoring
as well as the features that are considered relevant to the final solution. Note that although some
of the desired features are not available in the free version of the application, many are available in
SugarExchange and SugarForge, two platforms dedicated to the development and sharing of fea-
tures for SugarCRM.
The application Zurmo got the lowest score, largely due to his youth in the market. This caused
a significant portion of criteria related with Product Information and Company Information to present
low scores, as the development community is still small. At the same time, Zurmo has a small
internal development team, which makes it harder to have proper documentation and support to
developers.
The Vtiger CRM application had the second best score, very close to the score obtained by
SugarCRM. Since this is a company with an already meaningful existence, the weakness factor
identified is related with having a structure too dependent of the development made by its users,
with the focus on internal development somewhat reduced. Also note the good results obtained in
the Module/Funcionalities Required category, which turns out to not be a surprise since it is a fork
of SugarCRM, having a similar amount of available functionalities.
35
Finally, the CiviCRM application got balanced scores, having its lowest score in the Module/Funcionalities
Required category. The lowest score in this module is due in large part to the fact that, despite being
a customizable application, focusing mostly on a non-profit market causes a significant portion of its
modules and functionalities to be automatically customized for the needs of this type of company,
forgetting the needs that arise in companies with another type of goal. This leads to a great amount
of effort in the modification of the base code of the application, for it to perform in a way that the
other three applications perform naturally.
In conclusion, it is clear that the SugarCRM application is the one that presents the best condi-
tions for the implementation of the hypotheses raised in this document.
3.5.6 SugarCRM limitations
Although SugarCRM is a tool that fulfills most of the requirements for achieving the objectives pre-
sented, there are some limitations that had to be overcome using other solutions, or by simply
dealing with the limitation as a consequence of the way that the application is build.
One of these limitations regards the collection of attendance of students. SugarCRM is not
prepared for such a specific process and for which a high degree of customization is required. This
is because when collecting data of this kind there is a multiplicity of values that can be introduced
that require specific treatment, and also because it is intended that the introduction is made by two
complementary means (via the upload of Excel sheets or through direct introduction).
Therefore, taking into account that SugarCRM allows the insertion of data directly into its database,
it was decided that the best solution would be to implement a parallel system where it would be pos-
sible to collect the attendances and also to retrieve some general statistics on students over each
course.
Another limitation detected in SugarCRM is the inelasticity of its presentation layer. Although it is
possible to make the customization of the application interfaces, all changes made by manipulating
the application’s source code must follow the graphical framework defined by SugarCRM, otherwise
they are automatically discarded. Taking into account the specificity of the data to be submitted in
this implementation, it is a significant limitation.
3.6 Use Cases
This implementation will be evaluated at IST, since it is the end customer of this solution.
36
In this solution we can consider two main user groups: The Professors and the administrative
staff of DEI. As mentioned above, although the data is available to both user groups, it is intended
that the degree of handling and management of this information to be completely different for each
one of these groups.
The main difference between these two user profiles is related to the applications that they may
access. Since the role of the administrative staff of DEI is mostly related to the data entry of at-
tendances through the Attendance Collection Application, the access to SugarCRM should not be
granted to these users as the manipulation of information of the students is not a goal for these
users.
With regard to the Professors, this users must have access to the Attendance Collection Applica-
tion and SugarCRM. Since they are the end users of these applications they must be able to access
the Attendance Collection Application in order to see some pre-generated statistics, and SugarCRM
to develop all the actions that the application offers.
The following use cases can be described, for each of the types of users and taking in account
the applications that they may access:
• Administrative Staff Perspective:
1. In Attendance Collection Application - The user is able to log in using is IST SSO cre-
dentials, performing a query on the attendances that have already been introduced for a
given class. Subsequently, the user makes the introduction some attendances, using an
Excel sheet.
• Teacher’s Perspective DEI:
1. In Attendance Collection Application - The Professor logs in the application using is IST
SSO access, and then queries the statistics of attendance of students in is course.
2. In SugarCRM application - After logging in the system, the Professor runs a report on
the data in is course, identifying all students who attended less than a certain number of
classes. After identifying these students, performs a marketing campaign where through
an email comes in contact with this group of students.
3.7 Proposed Architecture
As stated above, to complement some of SugarCRM limitations it was necessary to implement a
Attendance Collection Application independent of SugarCRM, to feed the SugarCRM database with
data on attendance in classes. Given this premise, the presentation of the proposed architecture is
37
made individually for each application, being also presented how the two applications are connected
and how they interact with FenixEDU API.
3.7.1 Attendance Collection Application
The main objective of this application is allowing the collection of attendance of the students, and
the subsequent query of these presences and of some predefined statistics that were considered
relevant for Professors.
Regarding the role of this application, it was identified that it would be necessary a special care
for its integration with the existing processes at SugarCRM database level. This means that it was
necessary to focus on the transaction management, as well as the implementation of a series of val-
idations to guarantee that the input data is consistent with the structure and constraints implemented
at the SugarCRM database level.
The proposed architecture is presented in image 3.4.
Figure 3.4: Application for Attendance Collection proposed Architecture
The access to the application by the users is done using their web browser. When a user logs in
the IST SSO, it is possible to access the Application for Attendance Collection. The use of IST SSO
aims to make more customary and simple the user access to applications. As seen in chapter State
of the Art, a major problem with a significant part of CRM implementations is related to the difficulty
in motivating users to take advantage of the application, and the integration with SSO IST aims to
build a bridge with the users.
38
On the other hand, the use of a secure and centralized mean of connection is extremely im-
portant, because it makes possible to know what is the role of the user in the IST structure and it
becomes easier the management of their permissions as well as the access to the applications that
their profile allows.
Regarding the choices made in the Client Side technologies, the markup language HyperText
Markup Language (HTML) 8 in conjunction with Cascading Style Sheets (CSS) 9 was the obvious
choice, since it is the standard in the presentation of Web content. The programming language
JavaScript 10 and its library JQuery 11 where also chosen, and in this context its main job is to allow
some pre-processing of the data and actions provided by the users of the application during its
usage. The choice of Javascript for this purpose is a consequence of the great implementation that
this technology has in the Web environment, where it is used in active matter in about 89 % 12 of the
websites in the World Wide Web, which makes it a very robust and consensual technology.
Regarding the Server Side technologies, the chosen programming language was PHP 13. PHP
is a reference in the Server Side programming languages, and was further selected the usage of the
PHPExcel library, which provides a number of classes that can be used to easily perform the cre-
ation and manipulation of Excel spreadsheets. These spreadsheets enabled the entry of data to be
done in a simpler manner by the administrative services of DEI, while allowing that some statistics
could be exported by Professors. [8, 22]
The other applications with which the Attendance Collection Application is connected, such as
SugarCRM and FenixEDU Application Programming Interface (API), are represented in the architec-
ture diagram as black boxes as for understanding of Attendance Collection Application architecture
they are irrelevant.
The communication with SugarCRM is bidirectional, as for the presentation of data on the pres-
ence already collected and statistics extraction a direct link is required with the SugarCRM database.
Conversely, the introduction or modification of attendances already collected in the Attendance Col-
lection Application is made, and these data is stored in SugarCRM.
For the FenixEDU API 14 the communication is unilateral, and of acquisition of information.
Through this API and using Representational State Transfer (REST) requests it is possible to ob-
tain information about the available courses in the DEI, about the Professors, the list of registered
students, the Professors of the courses, and even the time tables of the courses. This information is
accessed by the Attendance Collection Application initially for entering this information into Sugar-
CRM database, and for the validations with a predetermined frequency of the data collected.
8http://www.w3.org/html/ (retrieved at April of 2015)9http://www.w3schools.com/css/ (retrieved at April of 2015)
10http://www.w3schools.com/js/ (retrieved at April of 2015)11https://jquery.com/ (retrieved at April of 2015)12http://w3techs.com/technologies/details/cp-javascript/all/all (retrieved at April of 2015)13http://php.net/ (retrieved at April of 2015)14http://fenixedu.org/dev/ (retrieved at April of 2015)
39
3.7.2 SugarCRM
SugarCRM is the application that allows the implementation of the majority of the objectives pre-
sented in this document.
By building personalized access to each of the DEI Professors, it is possible for Professors to
access a list of attendance of students in their classes, and they can perceive the student as a
whole while also having access to the statistics of their attendance at other courses.
Besides being able to consult an individualized profile of the students, SugarCRM allows the
construction of communication campaigns with these students. To this end, the application allows
the segmentation of students by variable criteria, and it is possible to see the results of reports gen-
erated through the application and to create direct contact campaigns with the students concerned.
The proposed architecture for this component is as follows:
Figure 3.5: SugarCRM proposed Architecture
As seen in the Attendance Collection Application, the access to SugarCRM is done using the IST
SSO and Central Authentication Service (CAS), with all the advantages that this represents. Access
to the IST Single Sign-On (SSO) is done through the web browser on the user’s machine.
Regarding the modules identified as relevant to a solution with the desired characteristics, the
Marketing Automation Module is used, as well as the Email Integration Module, the Teams Module,
the Enhanced Studio and also the Zucker Reports.
The Marketing Automation Module allows the creation of marketing campaigns focused on a set
40
of specific users. Taking in account the environment in which this implementation of SugarCRM hap-
pens, it is intended that through this module it is possible to make the management of the contacts
with students, after their segmentation by user-defined criteria occurs.
As the name implies, Email Integration Module allows the configuration of SugarCRM for the use
of tools and external mail servers, which in this case is extremely relevant, since the synchronization
of e-mail accounts of the Professors with the application greatly facilitates the use of the application,
and it helps to ensure the continued use.
The Teams Module allows the creation of the concept of Teams, that allows a logical division in
the application. This logical division aims to ensure that each Professor only has access to informa-
tion about students who are under its jurisdiction, not allowing the dissemination of information so
that its confidentiality may be in risk.
Enhanced Studio allows the creation of field in SugarCRM that have more complex structures. As
some application fields are the result of calculations on relatively large amounts of information in the
application, it is necessary to use these module to ensure that this calculations are done correctly
and that the values are constantly updated.
Finally the Zucker Reports module is used, which enables the creation and generation of reports
on the data in the database, thus being conducted the segmentation of the students.
Regarding the way the other applications that make up the solution interact with SugarCRM, the
explanation has been made in the Attendance Collection Application, which means SugarCRM bidi-
rectionally communicates with the Attendance Collection Application and uses data from FenixEDU
API.
41
42
Chapter 4
Implementation
This chapter aims to describe the way it was carried out the implementation of the architecture and
solution proposed in the previous chapter. It is intended to present the technical and methodological
nuances that were adopted during the implementation.
Section Introduction presents the conditions that the development environment had to meet so
the implementation of the solution was possible.
Section Attendance Collection Application presents the details of the implementation of the At-
tendance Application Collection, and in the SugarCRM section the same is done for SugarCRM.
These specifications range from the options in terms of construction/adaptation of the database to
the choices made in terms of presentation and data collection.
4.1 Introduction
This section is intended to present the environment in which the implementation of the proposed
solution was implemented, also being presented the minimum and ideal requirements presented by
the used applications.
The pre-requirements for SugarCRM application and Attendance Collection Application are also
presented.
Regarding the solution development environment, it was necessary to make a few decisions.
The first decision regarded the need to choose under which Operating System should the appli-
cations be developed.
Regarding SugarCRM no significant difference in performance and configuration between ver-
sions of SugarCRM was found for Windows and UNIX environments. Concerning the Attendance
Collection Application no limitation was imposed, since all the chosen technologies are compatible
with both Operating Systems. So eventually the option was for a UNIX-like solution, since it has a
greater degree of freedom in setting up and developing than the Windows environment.
43
An Ubuntu command line version was used, specifically the Ubuntu 12.04.5 LTS version (Precise
Pangolin).
The following applications were installed and configured to allow the proper use of SugarCRM:
• Apache HTTP Server version 2.2.22
• PHP version 5.3.10-1ubuntu3.13
• MySQL version 14.14, distribution 5.5.38
4.2 Attendance Collection Application
As a starting point, it is important to emphasize that the main objective is to allow the SugarCRM
database feeding with data from the attendance of students in classes, by the elements of the
administrative services of DEI.
Later it was considered that opening the possibility for Professors to be able to enter the presence
of their students in their classes instead of these being centralized in the administrative services
could bring an interesting dynamic to the CRM initiative. Given this decision, it was considered that
it would be interesting through this interface that Professors could easily have access to some simple
statistics regarding the attendance of students, in order to stimulate the use of the application.
Given these two objectives, it was considered that it would be more relevant than the application
presented a robust and simple operation mode as opposed to an overly complex interface.
In subsection Application construction steps the steps necessary to make it possible to have the
application ready for all the actions described in the subsections that follow are described.
In subsection Presences introduction/consultation the application component that allow the pre-
sentation and introduction of the attendances in the classes are explained.
Finally, in subsection Statistical information consultation is explained how it was implemented the
application components where it is possible to review the statistics of the attendances.
4.2.1 Application construction steps
The construction of this application consisted of a well-defined sequence of developments and steps,
which allowed the creation of the application.
For each of the features implemented was used an agile development methodology, in that when-
ever an iteration on the development of a functionality happened it was immediately presented to
end users for their feedback. Considering this feedback changes were made to the functioning and
44
graphical interface of the application, to make it possible to build a application that stimulates a con-
stant use by the users.
The first step in building the application was to populate the SugarCRM database with the infor-
mation necessary to make possible the collection of attendances. The structure of the database is
described in the SugarCRM section. To make possible a correct collection of the presences it was
necessary to populate the database with the following elements:
• Data regarding the Courses - Data like the name of the course, its website, the campus where
the course is given, which Professors minister the course, the number of students, etc., was
collected
• Data regarding the Students - Data like the name of the students, its IST number, its course,
the personal contacts, and the courses where they are registered was collected
• Data regarding the Schedules - Data like the day when the class took place, the start and finish
time, and the type of class
Excluding the data regarding the students (provided by the administrative services of DEI), all
the information was obtained through the FenixEDU API.
As stated before, the FenixEDU comprehends a range of solutions, from academic and adminis-
trative processes to general purpose software libraries. This application is quite complex and aims
to serve as a basis for developments in the academic context, but for the purpose outlined above it
was only was necessary to use the API provided by FenixEDU.
Through the supply of various endpoints and using a dynamic construction of web hyperlinks it
is possible to access all the information that is required to populate the database.
One example of an endpoint used is the link in the footnote 1, through which it is possible to
access the information of the course Complex Analysis and Differential Equations. The structure
returned by the page is displayed in image 4.1, where it is possible to check that the pages have
a coded hierarchy structure using the format defined by the notation JavaScript Object Notation
(JSON)2.
By creating various PHP scripts it has been possible to make successive iterations in the JSON
arrays received from the FenixEDU API, and subsequently transform and store this information into
the SugarCRM database.
In total it was transformed and introduced into the database the data for the 5 courses managed
by DEI. Thus, data were introduced about 80 courses, 2266 students and 6358 class schedules
where students presences could be introduced.1https://fenix.tecnico.ulisboa.pt/api/fenix/v1/courses/1610612946134/ (retrieved at January 2014)2http://www.json.org/ (retrieved at January 2014)
45
Figure 4.1: FenixEDU API endpoint structure example
4.2.2 Presences introduction/consultation
This feature aims to serve both user groups identified for this application, ie, the administrative
services of DEI and the Professors.
With this feature the aim is to give these two groups of users the possibility to make the intro-
duction/update of attendances in classes in predefined schedules, and the possibility to consult the
schedules in which presences were already introduced.
The data introduction can be made by two methods.
The first step of the procedure works the same way for both methods. This first phase involves
choosing to which course you want to make the introduction attendance. At the request of users, the
chairs are grouped by name, which is quite useful for chairs that are held for various courses and/or
different campus.
After choosing the chair it is necessary to choose the class schedule for which it is intended to
make the attendance introduction. The identification of the class can be done through a grid where
it is possible to identify the day of the week when the class was held, then the date and start/finish
time. At the same time, it is possible to identify the classes by its identifying code, and these codes
are the same used on the web pages of the courses in the IST website.
After choosing the class to which it is intended to make the introduction, it is then possible to
carry out the introduction by means of the two different methods refered above.
The first involves selecting all students who attended the class, making for such a check on the
available checkboxes with the names of the students. Although this method is useful for classes
where the number of students present is relatively low, it is very costly when the number of students
to introduce is significantly high.
Thus, was created the possibility for users to introduce the data using Excel sheets. As a tool
used quite frequently by both groups of users and for allowing the introduction of mass data, Excel
46
presented itself as the ideal tool for bulkintroduction of attendances.
For this mean of introducing data it was necessary to create a template file with a well-defined
structure, which allowed the validation of the entered data. The selected model is displayed in image
4.2.
Figure 4.2: Attendance Collection Excel structure
In this structure the user enters the information for the student (IST identification number and
student name), followed by whether they attended the class. The number of students that can be
entered is practically unlimited and all of the appearances in a class may be introduced in one file.
Regarding the technical component, for the graphical interface HTML and CSS were the chosen
programming languages.
To validate the choices and actions performed by the user JavaScript programming language
was used, with its library JQuery.
Regarding the processing and validation of input data (either with the manual insertion of each
presence, or the Excel validation) was performed using the PHP programming language, together
with the PHPExcel library.
Upon validation of the actions using JavaScript a significant amount of processing burden is
passed on to the client side, allowing the server to have a better overall performance with a higher
number of requests.
A careful management of transactions in SugarCRM database is made at this level. Given that
it is likely the simultaneous use of the Attendance Collection Application and SugarCRM, and that
the applications shares the same database, it was necessary that the Attendance Collection Appli-
cation respected the transaction rules imposed by SugarCRM. Thus, a management was adopted
at the transaction level for the Collection Attendance Application which ensures that all data manip-
ulation language activities take place unambiguously and with a policy of all-or-nothing. This was
achieved using a series of commands available at the PHP level which allow the management of the
transactions in a MySQL database.
47
4.2.3 Statistical information consultation
This feature is intended to serve only the Professors, since it can be considered that these are
conclusions drawn from confidential data.
With this feature it is intended to give Professors the ability to access two types of simple statistics
regarding the frequency in their classes. A first statistic lets them know what is the total number of
students who were present in each of their classes during the semester, while a second statistic al-
lows them to know the statistics of attendance of each one of his students throughout the semester.
These statistics are exported to Excel in order to make it easier the handling by the Professors.
The first statistic available is represented image 4.3.
Figure 4.3: Total Attendances Statistics Excel
In this statistic it is possible to check for each of the classes scheduled for that course what was
the number of students that were present. These classes are grouped by week in order to facilitate
their viewing.
It is also presented a reference to the number of students who are enrolled in the course.
The second statistic aims to show the percentage of presences of each student enrolled in the
course, and an example of this statistic is shown in image 4.4.
Figure 4.4: Individual Attendances Statistics Excel
In this type of statistic is presented a list of the students enrolled in the course, and it is possible
to identify which classes they attended. Each class is identified by a letter, which identifies in each
week what were the classes in which each student was present.
Taking into account the maximum number of classes in which the student could be present, it is
also indicated the percentage of presences for each student.
The big challenge in the construction of these statistics is that the courses follow their how orga-
nizational model taking in account its specificities, and the type of class that each chair can range
from four different types: Theoretical, Pratical, Laboratories and Seminars.
Thus, it was necessary to create a generic algorithm that allowed to survey the classes that had
already been introduced to the selected course, ensuring that each type of classes were grouped in
48
a different tab of the Excel provided to the Professor.
To make it possible to provide this functionality the same programming languages were used as
the ones in the previous functionality, with a special emphasis on PHPExcel library.
4.3 SugarCRM
SugarCRM is the centerpiece of the architecture of the proposed solution. Through this application
it is intended to make possible the segmentation and profiling of students by the Professors, thus
providing an application that allows a closer and personalized monitoring for each student.
SugarCRM is an application that features a very well-defined structure and through its own frame-
work allows the development on its base features. It also allows the incorporation of modules devel-
oped by other users, thus enriching the available features.
The application logic architecture is shown in the image 4.5.
Figure 4.5: SugarCRM Architecture
SugarCRM follows a model pattern Model View Controller (MVC) [18]. Given the changes that
had to be implement to accommodate the solution requirements, it was necessary to make any
changes at all levels.
49
At the database level the technology chosen was MySQL. This choice is a consequence of the
fact that this technology is free, coupled with the fact that MySQL is recognized as being a consistent
technology. Regarding the Data Layer the PHP DBManager class was used, which allowed to
perform a series of operations from the creation of users to the creation and manipulation of tables
in the database.
Regarding the Business Layer Sugar Beans (a Object Relational Mapper) was frequently used,
allowing the creation and management of objects created from the database and used by several
modules created in SugarCRM.
Regarding the Application Layer, SugarCRM shows little flexibility and openness to changes in its
interface. Thus, this layer turned out to be not handled directly at the code level, but mainly through
the graphical manipulation tools offered by SugarCRM [2, 36].
Note that this implementation was accomplished using SugarCRM Community Edition release
6.5.15, which is the free version of SugarCRM.
4.3.1 Database structure
SugarCRM database structure is very complex, and as such it will not be analysed in the present
document. However, we will describe the structures that were created to store the data on elements
that represent the IST business.
The created elements and the relationship between them is shown in image 4.6.
Figure 4.6: Implemented tables architecture
By implementing these tables it was possible to map much of the business that this document
50
addresses.
The tables implemented have the following utility:
• Students - Here is stored all the relevant information about the students, including their contact
details.
• Courses - In this table is stored data on courses that are teached in DEI. The academicterm
variable allows to identify the semester in which the course was given, since it is impossible to
uniquely identify the chairs just by its name. The nstudents field indicates the number of officially
registered students in each courses.
• Schedules - This table contains information regarding schedules where it is possible to record
attendances. In the field type it is possible to identify the type of class (if it’s Theoretical, Practice,
Laboratory or Seminary).
• Attendances - In this table the presence of students in the classes are recorded. The intro-
duced by field allows to identify who was responsible for the introduction of that presence, and
through field enrolled it is possible to identify if the student is enrolled in the course.
Note that the information on the Professors is not described in this structure. This is because for
this was used one of the base tables of SugarCRM, the Users table.
All tables represented in this structure are also linked to a number of other native tables of the
SugarCRM structure, but since that relations have little importance in the implementation of the IST
business rules, they are not represented in this architecture.
4.3.2 Teams module
One of the obvious concerns when implementing this application relates to the safety and limitation
of access to data.
Regarding the connection restriction it is possible to achieve this objective using the integration
with the IST SSO, but the limitation of access to the data within the application has to be reached
through other means.
Because we are dealing with sensitive data from students, it is necessary to ensure that even the
users who can access the application only access data which concerns them directly.
An example of data visualization limitations is easily identified: A Professor should only have
access to information relating to students who are enrolled or attende their courses. This means
that they should not have access to data from that students with whom there is the need to obtain
information in order to create a one-to-one academic monitoring.
51
Because we used the Community Edition version of SugarCRM, it is assumed by the application
that any user who has access to the application can access all the data stored in it.
Thus, it was necessary to use, configure and change a module provided by SugarCRM commu-
nity, the Teams module.
Teams module applies the concept of teams, which is very common in the business environment.
This concept means that users are grouped into teams, and for each team a perimeter of access to
data is set.
Despite using this module provided by the SugarCRM community, the specificity of this project
required the manipulation of the module source code to accomplish its mission.
Since it is intended that each Professor only accesses information of their courses, classes and
students, it can be considered that each Professor is a Team. So, after understanding the inner
workings of this module were developed multiple Structured Query Language (SQL) scripts to carry
out the creation and massive population of SugarCRM tables for creating individual Professor Teams.
4.3.3 Dashlet building
As an initial image of the application, the main screen dashlets are a way to present the most relevant
information to the user, and thus captivate him to use the application frequently.
These dashlets are presented on the homepage of SugarCRM, and the information presented
and its order is configurable.
For the homepage of each Professor three dashlets were created. One of the dashlets presents
information on students attending courses that the Professor minister, another that displays the
reports created and consulted lately, and finally a dashlet that displays information about the courses
that are taught by the Professor. The latter dashlet can be seen in image 4.7.
This dashlets present a challenge faced in this implementation. The fields with the count of the
number of classes introduced to each of the courses according to the type of classes is considered
a complex type field in SugarCRM. In practice, a complex field is a field whose value must be
calculated and updated with some frequency, depending on the changes in the database.
For it to be possible to create such fields it was necessary to resorted to a SugarCRM module
called Enhanced Studio.
Through this module it is possible to create fields whose value can be updated depending on the
implementation of SQL code to perform queries on the database and return values that are updated
and displayed to the user.
To apply the changes to the source code of this module it was used PHP programming language.
52
Figure 4.7: Global attendances introduction dashlet
4.3.4 Segmentation and communication
This feature represents a significant portion of the objectives that were proposed for this implemen-
tation.
It is intended that with this feature it is possible for a Professor to create reports based on the
collected data, allowing him to identify groups of students for which he considers that closer monitor-
ing is beneficial. It also offers the opportunity to create a communication channel with the identified
students using the email functionality.
In the CRM methodology this feature is the embodiment of a segmentation activity, in which the
segmentation of customers is made based on a characteristic identified as relevant.Taking in ac-
count that specific and relevant information was previously was collected on these same customers
(in this case, the attendances in classes), we are facing an example of profiling.
By using the Zucker Reports module it is possible to create on-demand report, by filling some
input parameters. The reports are based on SQL queries that are applied to the database, then
returning a result set. The returned result set is also configurable.
After the report runs is then possible do decide how the data may be view, and whether to take
any action in based on the new information gathered.
One possible action is to create a Targets List. As previously explained, in the CRM methodology
a Target is an existing customer that after performing a segmentation action is considered as a
possible target for a particular campaign/contact.
By adding the students returned by the report to a Targets List it becomes possible to use the
53
Marketing Module for the creation of a targeted marketing campaign.
The Marketing module allows tracking of a marketing campaign from its inception to its comple-
tion. In the case of this implementation it is intended to assume a marketing campaign of somewhat
different contours to a common marketing campaign in a business environment. In this implementa-
tion it is intended that a marketing campaign represents a set of logical actions taken by a Professor
to a Targets List identified as a consequence of the segmentation made using the reports.
To achieve this goal it was necessary to make several changes to the Marketing module base
structure [19]. One of the most relevant changes was the withdraw the obligatoriness that this mod-
ule had regarding the number of sequential steps to building the campaign and setting a deadline
for completing these steps.
This change required a rather large redefining of the framework of this module, and these
changes have been made using the SugarBeans SugarCRM model.
After making these changes it became possible to perform an unlimited number of actions in
each of the campaigns. These actions are as varied as setting alerts for changes in the Targets List,
the management of the elements that make up the Targets List, or the management and use of a
communication channel.
In this implementation the communication channel was created and configured through the email.
To do this it was necessary to configure the SugarCRM Emails module.
The SugarCRM Emails module offers the possibility to use and configure e-mail synchronization
with the application. By using this component it is possible for the user to view its emails in Sug-
arCRM, make the association between emails and students in the application, or be able to make
email communications directly from the application and using its email address.
In the context of this implementation, the setup of the user email account in the application is of
great importance, as it allows the use of the application has a continuity from the Professor, as often
allows him to be reminded of the necessity to perform a relationship management of their students.
For this implementation it was considered that as all Professors have a IST e-mail address, it
would be interesting to test and configure the use of the IST mail server in the application.
To do this, the settings presented in the image 4.8 where tested, where for the test user it was
possible to make the loading of the emails present in its account, and to make the sending of emails
through that same account.
54
Figure 4.8: Emails module configuration
55
56
Chapter 5
Evaluation
5.1 Introduction
5.1.1 Objectives
The evaluation of this Thesis is made by checking if through the implementation of the proposed
solution it was possible to achieve the objectives described in the previous sections.
So, it will present how these objectives have been achieved, using a proof of concept performed
using real data collected by the administrative services of DEI and that allows to prove that the solu-
tion implemented meets the necessary requirements.
Section User Acceptance Tests intends to present tests that confirm that using the functionalities
of the application it is possible to perform the activities described in the objectives.
Section Simulation Tests intends to prove that by using the implemented solution it is possible to
perform the tasks described more efficiently then using the currently available methods.
5.2 User Acceptance Tests
This section is intended to explain what tests where performed to prove that through the implemen-
tation carried out it is possible to achieve the objectives set during the analysis of the problem. Thus,
in subsection Test Specification are specified the conditions under which the tests were made and
the steps taken for its completion.
The subsection Conclusions presents the conclusions drawn on the usefulness of the implemen-
tation in the completion of the proposed objectives.
57
5.2.1 Test Specification
In order to prove that with this CRM implementation it is possible to achieve the proposed objectives
it was necessary to create a test that represented a proof of concept.
The first step was to use the Attendance Collection Application to conduct the introduction of
attendances of some students for a number of classes of one of the available courses.
Then it was necessary to use the implementation of SugarCRM in order to identify which students
attended less than a given number of classes.
For this it was necessary to create a report that would allow to proceed with this research.
Using Zucker Reports three input parameters were created for the report: The minimum number
of classes attended, what type of class we wanted to analyse, and to which course we wanted to run
the analysis.
After the creation of these input parameters it was necessary to create the report. For this it was
necessary to define the SQL code that allowed to search the SugarCRM database. For this report
in particular it was used the code shown in the image 5.1.
Figure 5.1: SQL code to run report
Later it was possible to run the report by filling the necessary input parameters. The report return
was a list of students, which was stored as a Target List.
From there it was necessary to create a new marketing campaign, adding the Target List created
as the final recipients of the campaign.
From that moment it was then possible to get in touch with the students concerned, using for
such the previously configured email, and getting this communication associated with the profile of
students.
5.2.2 Conclusions
Through the previously presented case study it was concluded that all objectives can be achieved
through the implemented solution.
Using the Attendance Collection Application the objective of Make the introduction of the atten-
dance at classes in order to enrich the information on students and allow the personalized support
is achieved, and this application also contributes decisively to the profiling of the students.
Through the implementation of SugarCRM, and as was seen with the use of several built and
58
manipulated modules it is possible to meet the objectives of Implement a CRM application for ag-
gregating relevant information on students, the Getting to profile and segment students , by applying
filters and analyses to the data collected over time and still objective, and also the Allow the per-
forming of mass communications based on the profiling and segmentation of the students objective.
Through this test it is possible to prove that from a functional point of view the implemented
solution provides all the functionalities needed to achieve the objectives that had been discriminated.
5.3 Simulation Tests
This section is intended to compare how efficient are in performing the activities described in the ob-
jectives when using the CRM implementation and the traditional methods currently available. To this
end, it was asked users to performed the sequence of actions that were described in the previous
section, and cover all the objectives for this implementation.
So that the results were more conclusive, the simulations were divided into two components. In
a first test users were given only a few references regarding the application the were about to use,
not being given any indication as to the features that each application had.
In a second test it was given users a more detailed insight into the existing features of each
application.
All tests were repeated twice in order to be able to draw conclusions about the real gains with re-
gard to continued use of the application, as opposed to the conclusions drawn by the tests described
above, where it was possible to draw conclusions about the learning curve for the applications.
5.3.1 Traditional methods
This method aims to understand how is it possible for users to able to meet the actions described in
the test mentioned in the previous section with the tools and applications currently available.
In image 5.2 are the mean values collected for the set of tests that were conducted.
Figure 5.2: Values collected with traditional methods
As stated above, the collected values of the time needed to perform the activity indicated for the
two scenarios described above are presented.
It should be noted that there are no major differences with regard to the times that users need to
accomplish the task when we proceed to the explanation of the features and applications that can
59
be use to achieve the objective.
This is easily explained by the fact that users are already familiar with most of the tools used
to achieve the proposed objectives. When this is so, an explanation of the existing features and
applications does not have a impact on how quickly users can perform the proposed tasks.
5.3.2 Using CRM Implementation
Using this method it is expected that users perform all actions previously described using only the
applications implemented in the proposed solution. Note that prior actions, such as creating the
user in the SSO and applications is deemed to have been made earlier, as well as the user email
configuration in SugarCRM.
In image 5.3 are the mean values collected for the set of tests that were conducted.
Figure 5.3: Values collected with new methods
As stated above, the time needed to perform the activity indicated for the two scenarios is de-
scribed above.
In this case it is relevant to note the difference in the values collected when the user does not
have any formal presentation to the features and applications available from when the user is formally
introduced to the applications and features.
5.3.3 Conclusions
To draw conclusions of the tests the graphics in the images 5.4 and 5.5 were used, which were
obtained based on the data presented in the preceding subsections tables.
In the graphic of image 5.4 it is showed the comparison between the collected time when there
is no explanation of the type of functionality that make up the final solution, for both methods.
In the graphic of image 5.5 it is showed the values obtained from the collection of time required
to complete the action when an introduction of the applications available and their functionality is
made.
In both cases it is contemplated the time necessary to successfully carry out the first trial and the
average of the two further attempts.
Using the values of both graphs it is possible to draw some conclusions.
The first is that when users are unaware of Attendance Collection Application and SugarCRM
and are faced with their use some difficulties in completing the proposed tasks.
60
Figure 5.4: Time consumed to perform actions without explanation of functionalities
Figure 5.5: Time consumed to perform actions with explanation of functionalities
This means that the application operation mode is not intuitive, since the common user finds it
difficult to complete the task in less time than using the tools that he is used to.
However, when we look for continuous use, the solution presented shows encouraging results.
We realize that ceases to be relevant that the user had a formal presentation to the application
functionality, as with repeated action it becomes intuitive. We can verify that the frequent use of the
implemented solution leads to a reduction of the activity of the proposed actions in over 50% of the
time, which represents a interesting gain.
61
As a broad analysis, it can be concluded that this implementation allows to perform the activities
for which it is proposed, and that the necessary training in their use can dramatically reduce the time
spent in profiling and segmentation of the students to provide them with better monitoring.
62
Chapter 6
Conclusions
6.1 Achievements and conclusions
The high-level purpose for this thesis was to understand of the benefits of implementing a CRM
initiative to monitor the performance of students during a semester, by the Professors of the
courses of DEI.
Given the objectives of lower level of granularity which were described in the Evaluation section
have been achieved, it can be concluded that there are benefits to implementing a CRM initiative to
monitor the performance of students during a semester.
By providing to Professors a set of tools that allows them to easily understand which is the current
situation of their students opens up the prospect to Professors to act more effectively in preventing
cases of abandonment and failure in academic courses that they minister.
However, what may be debatable is the adequacy of a CRM application of type Generalist to an
environment with the specifics of the academic environment.
With this thesis it is confirmed that such is possible and reachable, but however there are some
considerations that should be taken into account. Taking in account the tests made, it is possible to
see that when the user is not aware of the functioning of the applications developed some difficulties
arise in performing the task proposed since it may require a prior knowledge of the logic associated
with a CRM initiative. The particular case of the use of SugarCRM may be a issue, as there is a
clear difficulty in manipulating the GUI.
With this we conclude that using a solution of the Generalist type it is possible to implement a
CRM initiative in the academic environment, and it would be possible to obtain better results if even
better results if a Go Vertical CRM application was used, since this applications are already built
taking in account the specificities of a particular business environment.
63
6.2 Future Work
As possible iterations in this solution there are two major areas that can be developed.
The first area regards the increase of the amount of information that allows the profiling of stu-
dents. By including more criteria, such as information relating to intermediate evaluations, it be-
comes possible the construction of more complete student profiles, resulting in a more accurate
segmentation.
A second area involves the expansion of this concept to other components of academic life. An
example of the application of this methodology to other areas may be the monitoring of students
during the period of the Theses. Because it is a very particular phase of the academic path, it would
be interesting to be the target of a CRM initiative focused on that stage.
64
Bibliography
[1] Ali M. Al-Khouri. Customer relationship management: Proposed framework from a government
perspective. Journal of Management and Strategy, 3(4):34–54, 2012.
[2] Mark Alexander Bain. Sugarcrm Developer’s Manual : Customize and Extend SugarCRM.
Packt Publishing Ltd, 2007.
[3] Simon R. B. Berdal. Peculiarities of the commercial open source business model: Case study
of sugarcrm. Master thesis, Norges teknisk-naturvitenskapelige Universitet, 2013.
[4] Merlin Stone Bryan Foss and Yuksel Ekinci. What makes for crm system success - or failure?
Journal of Database Marketing and Customer Strategy Management, 15(15):68–78, 2008.
[5] Maria Manuela Cruz-Cunha and Joao Eduardo Varajao. Seleccao de sistemas crm utilizando
ahp. Teoria e Pratica em Administracao, 1(1):01–17, 2011.
[6] Barbara H. Wixom Dale L. Goodhue and Hugh J. Watson. Realizing business benefits through
crm: Hitting the right target in the right way. MIS Quarterly Executive, 1(2):79–94, 2002.
[7] Harry Watkins Denis R. Pombriant, Kent Allen and Karen E. Smith. What works, ten significant
crm implementations of 2003. Technical report, Aberdeen Group, Inc., Boston, Massachusetts,
2003.
[8] Paul DuBois. MySQL (5th Edition). Developer’s Library, 2013.
[9] Wen-Bin Cheng Fitzgerald Barrientos and Thomas Gulledge. Customizing crm for university
implementations. International Journal of Electronic Business Management, 1(2):63–74, 2003.
[10] Arezu Ghavami and Alireza Olyaei. The impact of crm on customer retention. Master thesis,
Lulea University of Technology, 2006.
[11] Gary B. Grant and Greg Anderson. Web Portals and Higher Education : Technologies to Make
IT Personal. Jossey-Bass, A Wiley Company, 2002.
[12] Gil-Hyung Lee Hee-Woong Kim and Shan Pan. Exploring the critical success factors for cus-
tomer relationship management and electronic customer relationship management systems. In
ICIS 2002 Proceedings, 2002.
65
[13] Haslina Mohd Khalid Rababah and Huda Ibrahim. Customer relationship management (crm)
processes from theory to practice: The pre-implementation plan of crm system. International
Journal of e-Education, e-Business, e-Management and e-Learning, 1(1):22–27, 2011.
[14] William J. Kettinger Khawaja A. Saeed, Varun Grover and Subo Guha. The successful im-
plementation of customer relationship management (crm) system projects. ACM SIGMIS
Database, 42(2):9–31, 2011.
[15] Benjamin Appiah Kubi and Andrews Kingsley Doku. Towards a successful customer rela-
tionship management: A conceptual framework. African Journal of Marketing Management,
2(3):037–043, March 2010.
[16] Wilco Leenslag. Influential aspects of relevance for a crm system in a b2b environment. 3rd
Twente Student Conference on IT, 2005.
[17] Lutz Kolbe Malte Geib, Annette Reichold and Walter Brenner. Architecture for customer rela-
tionship management approaches in financial services. In 38th Hawaii International Conference
on System Sciences, 2005.
[18] John Mertic. The Definitive Guide to SugarCRM : Better Business Applications. Apress, 2009.
[19] John Mertic. Building on SugarCRM. O’Reilly Media, Inc., 2011.
[20] Alok Mishra and Deepti Mishra. Customer relationship management: Implementation process
perspective. Acta Polytechnica Hungarica, 6(4):83–99, 2009.
[21] Bang Nguyen and Dilip S. Mutum. A review of customer relationship management: successes,
advances, pitfalls and futures. Business Process Management Journal, 18(3):400–419, 2012.
[22] Robin Nixon. Learning PHP, MySQL, and JavaScript. O’Reilly Media, 2009.
[23] Samson Ifejionu Nwankwo and Sunday Stephen Ajemunigbohun. Customer relationship man-
agement and customer retention: Empirical assessment from nigeria insurance industry. Busi-
ness and Economics Journal, 4(2):2–6, 2013.
[24] Atul Parvatiyar and Jagdish N. Sheth. Customer relationship management: Emerging practice,
process, and discipline. Journal of Economic and Social Research, 3(2):01–34, 2002.
[25] Adrian Payne and Pennie Frow. A strategic framework for customer relationship management.
Journal of Marketing, 69(1):167–176, 2005.
[26] Leigh McAlister Edward C. Malthouse Manfred Krafft Peter C. Verhoef, Rajkumar Venkatesan
and Shankar Ganesan. Crm in data-rich multichannel retailing environments: A review and
future research directions. Journal of Interactive Marketing, 1(24):121–137, 2010.
66
[27] Franka Piskar and Armand Faganel. A successful crm implementation project in a service
company: Case study. Organizacija, 42(5):199–208, 2009.
[28] Professor Vidyaranya B Gargeya Mr G Jason Goddard Professor Gerhard Raab, Professor Riad
A Ajami. Customer Relationship Management: A Global Perspective. Gower Publishing, Ltd,
2012.
[29] Hubert Osterle Rainer Alt and Thomas Puschmann. Customer relationship management ar-
chitecture in the pharmaceutical industry. Int. J. Healthcare Technology and Management,
5(3):297–314, 2003.
[30] Mornay Roberts-Lombard and Leon du Plessis. Customer relationship management (crm)
in a south african service environment: An exploratory study. African Journal of Marketing
Management, 4(4):152–165, 2012.
[31] SITI NUR THAZLIAH BINTI MOHD THAZALI. Comparison of two open sources customer
relationship management: Sugarcrm and vtiger on usability for community college. Master
thesis, Universiti Utara Malaysia, 2012.
[32] Timothy M. Devinneyb Tim R. Coltmana and David F. Midgley. Customer relationship manage-
ment and firm performance, 2009.
[33] Carl Tinnsten. Implementing a system of customer relationship management : Recurring issues
and necessary perspectives of the implementation phase. Master thesis, Umea University,
2014.
[34] Evangelos Triantaphyllou and Stuart H. Mann. Using the analytic hierarchy process for deci-
sion making in engineering applications: Some challenges. Interational Journal of Industrial
Engineering: Applications and Practice, 2(1):35–44, 1995.
[35] Yonggui Wang and Hui Feng. Customer relationship management capabilities: Measurement,
antecedents and consequences. Management Decision, 50(1):115–129, 2012.
[36] Michael J. R. Whitehead. Implementing SugarCRM. Packt Publishing Ltd, 2006.
[37] Kate Leggett Boris Evelson Brian K. Walker Reedwan Iqbal William Band, Stephen Powers and
Rowan Curran. The forrester waveTM: Crm suites for midsize organizations, q3 2012. Technical
report, Forrester Research, Inc., 60 Acorn park Drive, Cambridge, MA 02140 USA, 2012.
[38] Russell S. Winer. A framework for customer relationship management. California Management
Review, 43(4), Summer 2001.
67
68