PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE LA RELACIÓN CON LOS CLIENTES EN UNA EMPRESA PROVEEDORA DE SERVICIOS DE TELEVISIÓN DE PAGO Tesis para optar por el Título de Ingeniero Informático, que presenta el bachiller: André Hugo Montoya Del Pino ASESOR: Ing. Rony Cueva Moscoso Lima, octubre de 2014 ii Resumen En el rubro de las telecomunicaciones, las empresas proveedoras de servicios de televisión de pago han experimentado un gran incremento de usuarios en los últimos cinco años, lo que también supuso un incremento en la competencia. Frente a esta situación, los proveedores de estos servicios han rediseñado sus planes de negocio para efectos de fidelizar a sus clientes y adecuar la oferta de servicios a condiciones más estrictas por parte del usuario. Esta estrategia de negocios requiere de una optimización de las operaciones de gestión y seguimiento de clientes en las áreas de Ventas y Atención al Cliente. El presente proyecto de tesis plantea la implementación de un sistema de Gestión de la Relación con los Clientes para el soporte del proceso de Comercialización del área de Ventas y el proceso de Atención de Reclamos del área de Atención del Cliente en una empresa de televisión de pago. Estos procesos de negocio involucran operaciones importantes de interacción con los abonados y, por lo tanto, tienen alta participación en la entrega de valor. La herramienta desarrollada brinda soporte a los usuarios para realizar la gestión de clientes, ventas y reclamos, que hasta el momento se venía realizando manualmente, logrando evitar pérdidas de información y retrasos de actividades. Este documento se encuentra estructurado en 5 capítulos. En primer lugar, se describe la problemática que se desea solucionar, para luego presentar los objetivos, resultados esperados, metodologías a utilizar y el alcance del proyecto. En el siguiente capítulo se detalla el análisis realizado para empezar el desarrollo de la herramienta empezando por el entendimiento detallado de los procesos y reglas de negocio. En el tercer capítulo se presenta el diseño de la solución propuesta incluyendo la arquitectura seleccionada y el diseño de interfaz gráfica de la aplicación. El cuarto capítulo contiene la descripción de las actividades en la fase de construcción del software, desde la selección de herramientas tecnológicas hasta la elaboración de algoritmos para la asignación de clientes a colaboradores; así como el conjunto de pruebas que se realizaron para asegurar la calidad del producto entregado. En el capítulo final se hace una reflexión de las conclusiones obtenidas a partir del trabajo realizado y se presentan recomendaciones para futuros proyectos que tomen el presente como base. iii iv v Índice de contenido CAPÍTULO 1 : GENERALIDADES ............................................................................... 1 1.1 Problemática ......................................................................................................... 1 1.2 Marco Conceptual ................................................................................................. 3 1.2.1 Empresa proveedora de servicio de televisión por cable ............................... 3 1.2.2 Gestión de la Relación con los Clientes (CRM) ............................................. 8 1.3 Estado del Arte ................................................................................................... 12 1.3.1 Sistemas CRM ............................................................................................ 12 1.3.2 Comparación de soluciones ........................................................................ 14 1.3.3 Investigaciones ............................................................................................ 15 1.3.4 Conclusiones ............................................................................................... 16 1.4 Objetivo general .................................................................................................. 17 1.5 Objetivos específicos .......................................................................................... 17 1.6 Resultados esperados ........................................................................................ 17 1.7 Métodos, metodologías y procedimientos ........................................................... 18 1.7.1 Relacionados a la gestión del proyecto ....................................................... 18 1.7.2 Relacionados al desarrollo del producto ...................................................... 19 1.8 Alcance y limitaciones ......................................................................................... 21 1.8.1 Alcance ....................................................................................................... 21 1.8.2 Limitaciones ................................................................................................ 22 1.9 Viabilidad y justificativa del proyecto ................................................................... 23 1.9.1 Análisis de viabilidad ................................................................................... 23 1.9.2 Justificativa .................................................................................................. 25 1.10 Plan de proyecto ................................................................................................. 26 1.10.1 Plan de actividades ................................................................................. 26 1.10.2 Estructura de Descomposición del Trabajo .............................................. 26 1.10.3 Gestión de riesgos ................................................................................... 27 CAPÍTULO 2 : ANÁLISIS ........................................................................................... 28 2.1 Modelado de procesos ........................................................................................ 28 2.1.1 Comercialización ......................................................................................... 29 2.1.2 Venta y seguimiento de clientes .................................................................. 30 2.1.3 Atención de reclamo .................................................................................... 32 2.1.4 Registro de reclamo .................................................................................... 33 2.2 Identificación de requerimientos .......................................................................... 34 2.2.1 Requerimientos funcionales ........................................................................ 35 vi 2.2.2 Requerimientos no funcionales ................................................................... 38 2.3 Análisis de la solución ......................................................................................... 39 2.3.1 Especificación de actores ............................................................................ 39 2.3.2 Diagrama de paquetes ................................................................................ 41 2.3.3 Diagramas de Casos de uso ....................................................................... 41 2.3.4 Especificación de casos de uso ................................................................... 46 CAPÍTULO 3 : DISEÑO ............................................................................................. 47 3.1 Arquitectura del Sistema ..................................................................................... 47 3.1.1 Diagrama de componentes.......................................................................... 50 3.2 Diseño de Base de datos .................................................................................... 50 3.2.1 Diagrama de clases ..................................................................................... 51 3.2.2 Diagrama de base de datos ......................................................................... 52 3.3 Diseño de Interfaz Gráfica ................................................................................... 53 3.3.1 Elementos de diseño ................................................................................... 53 3.4 Diseño de Interfaz de carga de datos .................................................................. 56 CAPÍTULO 4 : CONSTRUCCIÓN Y PRUEBAS ......................................................... 58 4.1 Construcción ....................................................................................................... 58 4.1.1 Selección y configuración inicial de herramientas ........................................ 58 4.1.2 Construcción de la interfaz de carga ........................................................... 59 4.1.3 Construcción de algoritmos ......................................................................... 60 4.2 Pruebas .............................................................................................................. 65 4.2.1 Plan de pruebas .......................................................................................... 65 4.2.2 Diseño de casos de prueba ......................................................................... 66 4.2.3 Catálogo de pruebas ................................................................................... 66 CAPÍTULO 5 : OBSERVACIONES, CONCLUSIONES Y RECOMENDACIONES ..... 70 5.1 Observaciones .................................................................................................... 70 5.2 Conclusiones ...................................................................................................... 71 5.3 Recomendaciones .............................................................................................. 72 REFERENCIAS BIBLIOGRÁFICAS ............................................................................ 74 vii Índice de figuras Figura 1.1 Mapa de procesos eTOM ............................................................................. 4 Figura 1.2 Agrupamientos de procesos de eTOM ......................................................... 5 Figura 1.3 Grupos de procesos de la Gestión de la Relación con el Cliente ................. 6 Figura 1.4 Proyecto CARUSO .................................................................................... 16 Figura 1.5 Estructura de Descomposición de Trabajo ................................................. 27 Figura 2.1 Modelo del proceso de comercialización .................................................... 29 Figura 2.2 Modelo del proceso de comercialización actualizado ................................. 31 Figura 2.3 Modelo del proceso de atención de reclamo .............................................. 32 Figura 2.4 Modelo del proceso de atención de reclamo actualizado ........................... 34 Figura 2.5 Diagrama de paquetes del sistema ............................................................ 41 Figura 2.6 Diagrama del paquete de Mantenimiento ................................................... 43 Figura 2.7 Diagrama del paquete de Ventas ............................................................... 44 Figura 2.8 Diagrama del paquete de Atención al Cliente ............................................ 45 Figura 3.1 Arquitectura del sistema ............................................................................. 48 Figura 3.2 Diagrama de componentes ........................................................................ 50 Figura 3.3 Diagrama de Clases .................................................................................. 51 Figura 3.4 Diagrama de base datos ............................................................................ 52 Figura 3.5 Pantalla principal del sistema ..................................................................... 54 Figura 3.6 Pantalla con ventana modal de mensajes .................................................. 55 Figura 3.7 Pantalla con mensaje en la parte superior ................................................. 55 Figura 3.8 Estructura de datos .................................................................................... 56 viii Índice de tablas Tabla 1.1 Comparación de soluciones existentes ....................................................... 15 Tabla 1.2 Estimación de costos .................................................................................. 24 Tabla 2.1 Requerimientos del módulo de Ventas ........................................................ 35 Tabla 2.2 Requerimientos del módulo de Atención al cliente ...................................... 36 Tabla 2.3 Requerimientos del módulo de Mantenimiento ............................................ 37 Tabla 2.4 Requerimientos del módulo de Seguridad ................................................... 37 Tabla 2.5 Requerimientos del módulo de Reportes .................................................... 38 Tabla 2.6 Requerimientos no funcionales ................................................................... 38 Tabla 2.7 Casos de Uso y Requerimientos Funcionales ............................................. 42 Tabla 4.1 Variables de la asignación de clientes a vendedores .................................. 62 Tabla 4.2 Variables de la asignación de reclamos a técnicos ..................................... 62 Tabla 4.3 Clases de equivalencia: Asignación de clientes .......................................... 66 Tabla 4.4 Clases de equivalencia: Programación de actividad .................................... 66 Tabla 4.5 Clases de equivalencia: Agendar visita técnica ........................................... 67 Tabla 4.6 Clases de equivalencia: Asignación de agendas ......................................... 67 Tabla 4.7 Caso de prueba: Asignación de clientes ..................................................... 67 Tabla 4.8 Caso de prueba: Programación de actividad ............................................... 68 Tabla 4.9 Caso de prueba: Agendar visita técnica 1 ................................................... 68 Tabla 4.10 Caso de prueba: Agendar visita técnica 2 ................................................. 69 Tabla 4.11 Caso de prueba: Asignación de agendas .................................................. 69 1 Capítulo 1 : Generalidades En este capítulo se abarca el planteamiento general de la problemática que motivó a desarrollar el proyecto de fin de carrera y de la solución propuesta. Luego, se presentan los objetivos y el alcance del proyecto, así como las metodologías seleccionadas y la planificación de actividades. 1.1 Problemática Una empresa proveedora de servicios de televisión de pago es aquella que ofrece a los consumidores un sistema de servicios que se transmiten a los televisores fijos a través de cables coaxiales o fibra óptica. Este servicio incluye una programación de canales de películas, deportes, noticias, programas infantiles, educativos y otros. En el Perú, la mayoría de empresas de esta categoría brindan servicio de televisión por cable. En los últimos años, se ha experimentado un notable crecimiento en esta industria debido al aumento de la demanda por parte de la población peruana, tanto en Lima como en provincias. Prueba de ello es que el número de abonados de este servicio en el país pasó de 579,329 en el año 2006 a 1, 139,963 en el año 2012 [1]. En el Perú existen más de 200 empresas que cuentan con una concesión otorgada por el Ministerio de Transportes y Comunicaciones para brindar el servicio de televisión de pago [2]. La gran mayoría de estas son pequeñas y medianas empresas que ofrecen servicio de televisión por cable en una o varias localidades a lo largo del país. Por lo general, es muy difícil ofrecer y mantener un servicio exclusivo, ya que la competencia iguala la oferta o, incluso, ofrece algo mejor. De este modo, las empresas operadoras de televisión por cable garantizan su éxito con dos factores esenciales: competitividad y diferenciación, siempre considerando que la aprobación de dichos factores la tiene, en última instancia, el cliente. Las empresas entienden que su mayor centro de atención es el cliente y la relación que tenga establecida con el mismo. Con la creciente demanda del servicio de televisión de pago en el Perú, los usuarios cuentan en la actualidad con más opciones para hacer valer su dinero y recibir servicios de mejor calidad. En consecuencia, los 2 proveedores de estos servicios han rediseñado sus planes de negocio para efectos de fidelizar a sus clientes y para adecuar la oferta de servicios a condiciones más estrictas por parte del usuario [3]. Sin embargo, pese a sus esfuerzos, varias empresas del rubro no pueden dar respuestas concisas a las siguientes preguntas: 1. ¿Sabe por qué sus clientes se suscriben a su servicio y no el de otro? ¿Cómo lo sabe? 2. ¿Sabe cuáles son las razones más importantes de adquisición del servicio para cada cliente? 3. ¿Sabe contra qué tipo de cliente pierde ofertas más seguido y por qué? 4. ¿Cómo el cliente se contactó con la empresa la última vez? ¿Mediante correo electrónico, llamada telefónica o se acercó a las oficinas personalmente? Esto evidencia que han fallado en entender a sus clientes incluso en el nivel más básico. En el panorama altamente competitivo como el de hoy, proveer el servicio al cliente no es suficiente; el seguimiento y administración de las expectativas del cliente es, en cambio, el camino para crear clientes satisfechos. Los procesos de negocio involucrados en esta tarea, son aquellos que soportan las operaciones de interacción con los clientes y que tengan participación en la entrega de valor [4]. En una empresa proveedora de servicios de televisión estos son los procesos de las áreas de Ventas y Atención al cliente. Las preguntas mencionadas atrás debieron ser respondidas por, justamente, el personal involucrado en estos procesos. Para alcanzar los mejores niveles de satisfacción del cliente es necesario enfocarse en el concepto de “Conocimiento del cliente” (CK: Customer Knowledge). Esto involucra el uso de la información que la empresa tenga del cliente con el fin de desarrollar y mantener una relación con el mismo [5]. Una empresa de la industria de la televisión de pago debe ser capaz de gestionar, dar seguimiento y medir el “Conocimiento del cliente” a través de sus procesos de interacción con el cliente. Como menciona Kostojohn [6], “no se puede gestionar lo que no se puede medir”. Pero gestionar y darle seguimiento a la información de la creciente cantidad de abonados al servicio de la televisión de pago sin el uso de herramientas adecuadas dificulta la tarea de averiguar las necesidades de los clientes y como responder a sus 3 expectativas. Para ello, la empresa puede apoyarse en el uso de una herramienta informática a la medida. Es decir, debe ser fácil de instalar, debe funcionar con los recursos que la empresa pueda disponer y, sobretodo, debe mejorar la eficiencia de los procesos de gestión y seguimiento de clientes manteniendo un ratio costo- beneficio aceptable. La presente tesis propone la implementación de una herramienta de Gestión de la Relación con los Clientes (CRM: Customer Relationship Management)para mejorar la eficiencia de los procesos de gestión y seguimiento del cliente. Además, la empresa se puede apoyar en el sistema para desarrollar estrategias centradas en el cliente más efectivas. En el largo plazo, la correcta implementación de una herramienta CRM se puede convertir en sinónimo de ventaja competitiva y protección del negocio [7]. 1.2 Marco Conceptual En este apartado se describirán los procesos de negocio comerciales y de atención de reclamos de una empresa que provee el servicio de televisión de pago y los conceptos relacionados con una herramienta CRM. 1.2.1 Empresa proveedora de servicio de televisión por cable Una empresa proveedora de servicio de televisión de pago alquila varias señales de televisión que ofrece a los consumidores en la forma de un paquete de canales. Los servicios que puede ofrecer están orientados a la población de una determinada área geográfica donde la empresa posea una red de telecomunicaciones que soporten la transmisión de señales de televisión. La red está compuesta por cable coaxial, que es tendido a lo largo de la localidad donde se ofrece el servicio. Una persona interesada en el servicio puede contactar a la empresa por teléfono, o bien, puede ir hasta a la oficina que atiende en su localidad. La suscripción de un cliente al servicio involucra la instalación de un decodificador y una extensión de cable desde la red principal hacia su domicilio. El abonado, denominado de esta forma cuando se suscribe a la empresa, recibe una factura mensual por los cargos del servicio. Asimismo, puede presentar un reclamo si ocurre una avería en su servicio, como por ejemplo que algunos canales se congelen o que el cable coaxial presente daños. 4 1.2.1.1 Procesos de negocio Se utilizará el Mapa de Operaciones de Telecomunicación mejorado (eTOM: enhanced Telecomunication Operations Map), para describir a grandes rasgos las áreas de procesos de negocio de la empresa. El eTOM es un Marco de Procesos de Negocio desarrollado por el grupo Telemanagament Forum con el fin de categorizar todas las actividades de un proveedor de servicio de telecomunicaciones en todos los niveles de empresa. Su elección se debe a que es el marco referencial más aceptado y utilizado en las empresas del sector de telecomunicaciones que están trabajando para automatizar sus procesos, mejorar su costo-eficiencia y aumentar la satisfacción del cliente [8], como, por ejemplo, una empresa proveedora de servicios de televisión de pago. El eTOM es una herramienta útil para planificadores, administradores, estrategas y diseñadores de software; haciendo un énfasis en una estructura de componentes de proceso e interacciones de los mismos; proporcionando un conjunto de requerimientos para desarrollar soluciones como sistemas, arquitecturas y tecnologías. Figura 1.1 Mapa de procesos eTOM [8] Es importante notar que no todos los procesos definidos por el eTOM son usados por todos los proveedores de servicios [9]. Por ello, se adaptarán los ejemplos de procesos desarrollados por el eTOM, para empresas proveedoras de servicios de 5 telecomunicaciones en general, a los procesos específicos del ambiente de negocio de una empresa que presta servicio de televisión de pago. La estructura conceptual del eTOM está compuesta por tres áreas de procesos como se puede ver en la Figura 1.1. Las áreas de procesos de Estrategia, Infraestructura y Producto, y Operaciones se dividen en 7 agrupamientos de procesos verticales, los cuales se concentran en actividades “end-to-end” e incluyen procesos que involucran clientes, servicios, recursos y proveedores. En la Figura 1.2 se puede apreciar que estos agrupamientos representan un ciclo de operaciones cuando se mira de izquierda a derecha. La vista conceptual del eTOM describe, además de las principales áreas de procesos, a las áreas de proceso funcionales, ilustradas como capas horizontales en la Figura 1.2 Las áreas funcionales reflejan los enfoques requeridos para alcanzar los objetivos de negocio. Figura 1.2 Agrupamientos de procesos de eTOM [8] Como se puede observar, los procesos relacionados a la Gestión de la Relación con el Cliente aparecen en el área de Operaciones del eTOM. A su vez, el agrupamiento de procesos se divide en 4 categorías representadas como agrupamientos verticales. 6 Como se mencionó anteriormente, eTOM pone énfasis en el cliente y los procesos que interactúan con él directamente. Los tres agrupamientos verticales de procesos de Aprovisionamiento, Aseguramiento y Facturación son aquellos que corresponden a esta tarea; y son conocidos comúnmente como procesos de operaciones con el cliente. Estos procesos interactúan y apoyan al cliente; y son la prioridad de la empresa. Asimismo, es necesario contar con un soporte de operaciones que incluya procesos que aseguren que las operaciones con el cliente respondan a las necesidades del cliente, en el tiempo y al costo que el mismo requiere. El agrupamiento de procesos encargado de ello es el Soporte y Alistamiento de Operaciones. En el agrupamiento de Gestión de la Relación con el Cliente se considera importante el conocimiento de las necesidades del cliente e incluye todas las funcionalidades necesarias para la adquisición, mejora y retención de la relación con el cliente [10]. Se trata de servicio y soporte al cliente, ya sea por diferentes medios como teléfono, web o personalmente. Cabe destacar que el nombre de este agrupamiento coincide con el de la herramienta informática propuesta. En el contexto del eTOM, CRM es una agrupación de procesos de interacción con el cliente. Por otro lado, un software CRM es aquel que ofrece soporte tecnológico a, justamente, dichos procesos. Figura 1.3 Grupos de procesos de la Gestión de la Relación con el Cliente [9] 7 El presente proyecto de fin de carrera centrará sus esfuerzos en dar soporte tecnológico a los procesos del agrupamiento de Gestión de la Relación con el Cliente que involucran a las áreas de Ventas y Atención al cliente.  Comercialización Grupo: Ventas (Selling) El objetivo de este proceso es la promoción de un producto o servicio a los clientes que conozca la empresa para asegurar el éxito de las ventas. En el caso de una empresa de televisión de pago el objetivo es la venta de paquetes de canales. El jefe o supervisor de Ventas se encarga de crear la lista de clientes objetivo para el proceso. A cada vendedor o representante de ventas se le asignan los clientes de la lista para contactarlos y darle seguimiento con el fin de lograr ventas para la empresa. La negociación con el cliente puede terminar en éxito o fracaso. Al finalizar exitosamente, se ejecutan los procesos de Instalación de servicio, del grupo Manejo de órdenes (Order Handling) y Facturación, del grupo de Gestión de facturación (Billing and Collections Management).  Atención de reclamos Grupo: Manejo de incidencias (Problem Handling) El objetivo de este proceso es la atención del cliente dentro del tiempo acordado en el contrato del servicio. Los operadores reciben los reclamos de los clientes sobre su servicio y se agendan visitas técnicas para su solución en caso sea problema técnico. Luego, el jefe o supervisor del área asignará un técnico a una agenda y se encargará de la gestión del reclamo con el objetivo de no sobrepasar el plazo. La atención finaliza cuando el técnico asegura que la incidencia se ha solucionado. Estas actividades están relacionadas con los procesos del grupo de Calidad de servicio y Gestión del acuerdo de nivel de servicio (Customer QoS/SLA Management). Los procesos descritos se ven comprometidos con la entrega de valor al cliente. El soporte de estas actividades es el primer paso para elevar el nivel de conocimiento del cliente que tiene la empresa. También se hace evidente que para reducir los tiempos del proceso de Atención de reclamos, la asignación de agendas a técnicos se puede realizar de forma automática con la ayuda de un software, basándose en el valor del 8 cliente para la empresa y la disponibilidad y capacidades del personal. De la misma forma se puede mejorar la eficiencia de la asignación de clientes a vendedores para el proceso de Comercialización. 1.2.2 Gestión de la Relación con los Clientes (CRM) En este apartado se presentará la definición del concepto de Gestión de la Relación con los Clientes y luego se abarcará las clasificaciones y funcionalidades de un sistema de información CRM. 1.2.2.1 Definición El significado de Gestión de la Relación con los Clientes puede variar según los diferentes puntos de vista de la ciencia, investigación y práctica. En este último punto de vista se encuentran los significados que serán relevantes para la presente tesis. Como parte de una estrategia de negocio, CRM está definida como una estrategia de negocio centrada en el cliente diseñada para optimizar la rentabilidad, ingresos y la satisfacción del cliente [5]. Esta definición se complementa con la propuesta por Goldenberg[11]: CRM es una estrategia de negocios que involucra personal, procesos y tecnología para maximizar la relación con los clientes. La estrategia CRM involucra: - Medir las entradas y salidas de las áreas de ventas y servicios en términos de ingreso, rentabilidad y valor por cliente. - Adquirir y actualizar constantemente el conocimiento de las necesidades, motivaciones y comportamiento del cliente en el ciclo de vida de la relación con el mismo. - Aplicar el “Conocimiento del cliente” para mejorar el rendimiento de los procesos aprendiendo de los éxitos y fracasos. - La implementación de los sistemas apropiados para el soporte de “Conocimiento del cliente” y la medición de la efectividad de la estrategia. - Flexibilizar los procesos de ventas de acuerdo a las necesidades cambiantes del cliente para maximizar la rentabilidad. 9 Entre los negocios que han adoptado estrategias similares de negocio, resalta el rubro de las telecomunicaciones. En el Perú, las empresas de este rubro han orientado sus estrategias de negocio para efectos de fidelizar a sus clientes y para adecuar la oferta de servicios a condiciones más estrictas por parte del usuario. Esto significa que se pueden beneficiar de una estrategia CRM. Además, como ya se pudo observar, los procesos relacionados a la Gestión de la Relación con el Cliente son parte del corazón de eTOM, marco de procesos de negocio más aceptado internacionalmente. Para darle soporte a los negocios en esta estrategia enfocada en el cliente y la gestión del mismo, surgieron sistemas de información, que heredan el nombre la estrategia, comúnmente conocidas como aplicaciones CRM. Estas aplicaciones están soportadas por diferentes tecnologías según la necesidad de cada empresa: sistemas cliente- servidor, aplicativos web o aplicaciones “en la nube”. La complejidad de la infraestructura del CRM refleja la escala de la organización. Para una pequeña o mediana empresa, solo se requiere una implementación en un único servidor físico que tendrá los roles de servidor de aplicación y base de datos; mientras que para grandes empresas se requerirán varios servidores para soportar la gran cantidad de usuarios así como la inclusión de otros componentes de hardware específicos a las necesidades [5]. 1.2.2.2 Clasificación De acuerdo a Vogt [5], el entorno CRM está compuesto por tres categorías de aplicaciones:  CRM Operacional: Estas aplicaciones ayudan al personal de ventas a ser más productivos y efectivos. Incluye software para automatizar las ventas, marketing y servicio al cliente. Estos sistemas tienen los datos de nivel transaccional de productos, clientes y transacciones. Ofrecen soporte a los procesos de interacción con el cliente ya sea a través de correo, teléfono, internet o físicamente. Son conocidas comúnmente como aplicaciones “front-office”.  CRM Analítico: Estas aplicaciones son desarrolladas para ocuparse de los datos del cliente para mejorar el valor de la compañía. Se basa en toda la información del cliente incluyendo datos de venta (registro de compras), datos financieros 10 (registro de pagos, crédito otorgado), datos de marketing (resultados de campaña) y datos de servicio. Ofrece los prospectos de los mejores programas de ventas- cruzadas, una mejor retención del cliente y programas de adquisición de clientes.  CRM Colaborativo: Ayudan a “orquestar” los diálogos con los clientes para facilitar la comunicación con el mismo e identificar sus patrones de comportamiento. Además, facilitan la coordinación entre empleados y las colaboraciones con los socios del negocio. 1.2.2.3 Funcionalidades comunes Según Kostojohn [6], se pueden dividir las funcionalidades de las aplicaciones CRM en los siguientes módulos:  Clientes El registro de clientes es el corazón de una aplicación CRM. Esta se puede dividir en registro de “compañías” que representan las organizaciones con las que se interactúa y registros de “contactos” o “individuos” para representar a personas individuales. Incluye: - Posibilidad de añadir campos que categoricen los clientes en diferentes formas, por ejemplo: territorio de ventas, segmentos de mercado o por industria. - Posibilidad de dar seguimiento a diferentes tipos de organizaciones, ya sea usando el registro de cliente u otros registros, ya sean vendedores o prospectos. - Posibilidad de crear múltiples relaciones para relacionar cuentas y contactos con fin de representar la multitud de relaciones que puedan existir. - Posibilidad de dar seguimiento a las interacciones con los clientes como encuentros, llamadas telefónicas, e-mails y faxes.  Marketing Las funcionalidades de marketing están hechas para ejecutar y dar seguimiento a actividades de marketing. Un factor importante es qué tan bien las funciones de marketing persisten en el módulo de ventas para ayudar a unir los ingresos con las actividades de dicha área. Incluye: 11 - Posibilidad de gestionar información de prospectos independientemente de los clientes para la calificación y objetivos de marketing. - Posibilidad de desarrollar listas usando varios criterios y luego relacionar las actividades de marketing contra las listas. - Posibilidad de organizar las actividades de marketing en diferentes campañas para fines de planificación. - Posibilidad de ejecutar campañas de e-mail de forma robusta. Por ejemplo: dar seguimiento a repuestas de e-mails. - Posibilidad de relacionar las ventas realizadas con las actividades de marketing realizadas.  Ventas Es una de las prioridades de muchas iniciativas de implementación de CRM. De hecho, las aplicaciones CRM nacieron de las aplicaciones de automatización de ventas (Sales Force Applications). Incluye: - Posibilidad de administrar la información de oportunidades de venta como tamaño de oferta, tiempo estimado de cierre, servicios más vendidos en un ciclo de ventas. - Posibilidad de definir y gestionar una metodología estructurada de ventas. - Posibilidad de crear prospectos de venta. - Posibilidad de realizar reportes para la gestión de ventas.  Atención al cliente Las aplicaciones CRM están desarrolladas para ayudar a las organizaciones a registrar las incidencias con sus clientes y gestionarlas efectivamente para su solución. Es muy importante debido a que tienen un significativo impacto en la satisfacción del cliente. Incluye: - Posibilidad de gestionar y categorizar los reclamos de los clientes. Se puede dar seguimiento a cada reclamo según los procesos involucrados, tipo de reclamo y servicios involucrados. - Posibilidad de definir y dar soporte a múltiples procesos de tratamiento de reclamos para las diferentes categorías de reclamos. 12 1.3 Estado del Arte Existen en el mercado varias soluciones CRM para empresas. Oracle es el líder en este tipo de software con sus aplicaciones Siebel CRM, ofreciendo soluciones adaptadas específicamente a más de 20 sectores, incluyendo telecomunicaciones [12]. Sin embargo, este apartado se concentrará en software CRM desarrollado para empresas de televisión de pago. Además, se incluyen investigaciones realizadas para evaluar los beneficios de esta herramienta en empresas de telecomunicaciones y, particularmente, a proveedoras de servicio de televisión de pago. 1.3.1 Sistemas CRM  Infusionsoft Ofrece una solución para automatizar las actividades de ventas y marketing para pequeñas y medianas empresas [13]. Se enfoca en los siguientes aspectos: o Clientes: Permite desplegar campañas de páginas web, redes sociales y correo electrónico. Puede capturar información de clientes potenciales automáticamente. Además permite medir los esfuerzos de la empresa para optimizar los procesos. o Ventas: Permite calificar los prospectos y encontrar oportunidades de venta. Además permite administrar las relaciones e interacciones con el cliente. Provee herramientas para eliminar las actividades manuales, lo que contribuye a la eficiencia del personal de ventas. o Marketing: Permite segmentar la lista de clientes y enviar mensajes a clientes objetivo. Posee una herramienta para diagramar campañas de marketing y personalización para mejores conversiones. Seguimiento de oportunidades venta a través de cadenas de correos electrónicos. o Ventas online: Permite crear un crear una página web de ventas. Se puede editar las páginas de los productos. Es posible automatizar la facturación. La gran ventaja consiste en que a partir de la información de ventas realizadas se pueden editar las ofertas y enviar mensajes al cliente. 13  SugarCRM Es una plataforma CRM diseñada para gestionar prospectos, compartir información de ventas y elevar la satisfacción del cliente [14]. Es una solución Web pensada para pequeñas y medianas empresas en la versión “Profesional” del software, así como para grandes empresas y organizaciones gubernamentales en su versión “Corporativa”. Provee soporte para la automatización de Ventas, Marketing y Atención al Cliente a través de la gestión de oportunidades, prospectos y cuentas de clientes; administración de campañas de marketing; y permite el seguimiento de incidentes para la gestión de reclamos. Sus mejores funcionalidades son la elaboración de reportes y la predicción de ventas, catálogo de productos y contratos. Posee aplicaciones nativas para iPhone y Android que se sincronizan con el sistema para consultar la información de clientes, ventas y marketing. Soporta 22 lenguajes y tiene integración con Google Docs y Gmail.  Sage CRM Es una solución para la gestión de las actividades críticas comerciales, de marketing y atención al cliente [15]. Se ofrece en diferentes versiones, la más cara con más funcionalidades, y con diferentes tipos de implementación: local o “en la nube”. La arquitectura del software está basada en web y ofrece soporte personalizado, por lo que las empresas no necesitan dedicar recursos de TI para obtener los mejores beneficios de esta solución. Particularmente la versión “Profesional” de Sage CRM incluye funcionalidades para la gestión de oportunidades y clientes potenciales, gestión de incidencias y gestión de campañas de marketing. Entre las funciones disponibles adicionales se pueden encontrar integración con Outlook, gestión de llamadas salientes y flujos de trabajo. A partir de las funcionalidades que ofrece el software, las empresas pueden beneficiarse en cada uno de los siguientes departamentos o áreas: 14 o Departamento comercial (o de ventas): se proporciona una mayor visibilidad de las operaciones en curso y el rendimiento comercial. Además disminuye el tiempo dedicado a tareas administrativas. o Departamento de marketing: permite el envío de comunicaciones personalizadas a los clientes, garantizando que recibe el mensaje apropiado en el momento oportuno. También permite el cálculo del ROI (Return of Investment) de cada campaña. o Departamento de atención al cliente: permite medir y evaluar la satisfacción del cliente de modo comparativo. o Departamento de TI: la solución requiere mínima configuración para su puesta en marcha y es fácil de integrar con aplicaciones de terceros. 1.3.2 Comparación de soluciones Las soluciones presentadas tienen las funcionalidades básicas necesarias para cubrir los procesos de Ventas y Marketing. Con la adquisición de estos sistemas o servicios, ya que ambas soluciones también son ofrecidas como SaaS (Software as a Service), las empresas pequeñas y medianas, en general, pueden automatizar las operaciones de gestión y seguimiento de clientes como calificación de prospectos, seguimiento de oportunidades de venta y gestión de campañas de marketing. Sin embargo, SugarCRM y Sage CRM incorporan además un módulo para Atención al Cliente. Las soluciones que ofrece este módulo para automatizar los procesos de esta área, ya sean llevadas a cabo en la misma empresa o a través de un Call Center para el caso de SugarCRM. Cabe destacar que SugarCRM es también ofrecido como software open source (de código abierto) lo que es conveniente para las empresas. La plataforma de código abierto es bastante flexible, pero es necesario tener en cuenta aspectos importantes como la estrategia de negocio para asegurarse que el CRM cumpla con todo y no tener problemas en la implementación de la tecnología [5]. Por último, Infusionsoft cuenta con herramientas para el soporte de e-commerce, lo que ayuda a las empresas incrementar sus ganancias a través de ventas on-line. En la Tabla 1.1 se muestra un resumen de la comparación de estas soluciones. 15 Criterio Infusionsoft v.Plus SugarCRM v.Profesional Sage CRM v.Profesional Soporte a Ventas x x x Soporte a Marketing x x x Soporte a Atención al Cliente x x Personalización de reportes x Soporte a móviles x Integración con correo electrónico x x x Código abierto (Open Source) x Soporte a e-commerce x Tabla 1.1 Comparación de soluciones existentes 1.3.3 Investigaciones  Customer Relationship Management for SMEs Se realiza un análisis de los beneficios y requerimientos especiales de un software CRM para pequeñas y medias empresas. Según Baumeister [16], las empresas requieren un sistema de información que se adapte fácilmente a las necesidades de su interacción con el cliente (y no al revés), siempre manteniendo un costo bajo. Como parte de los beneficios, Baumeister señala que las aplicaciones CRM permiten a la empresa establecer una relación personalizada con su cliente a través del soporte provisto al área de ventas. Menciona también que el CRM analítico, con su capacidad de analizar el comportamiento del cliente y sus herramientas de reportes y data- mining, permite a las empresas medir la satisfacción del cliente y amplia el conocimiento de sus problemas y preferencias. Entre los requerimientos se explica que se requieren soluciones que se adapten al modelo de negocio de la empresa. Además, que no es admisible para la compañía que se tenga que cambiar toda su infraestructura de TI para la implementación del software CRM, por lo tanto, este último debe integrarse a los recursos de TI existentes de la compañía. Como parte de esta investigación se introduce el proyecto CARUSO (Customer Care and Relationship Support Office), cuyo objetivo es proveer a las empresas de un 16 marco de trabajo para implementar aplicaciones CRM especializadas y de bajo precio. En vez de proveer una solución monolítica, la solución provee un conjunto de componentes básicos. Los componentes se pueden juntar y configurar para construir aplicaciones CRM de front-office, que se incluyen dentro del tipo operacional descrito anteriormente, que actuarán como “shell” (escudo) de la empresa como se puede apreciar en la Figura 1.4. Idealmente, la comunicación con el cliente es iniciada por el mismo o la empresa, luego es pasada a través del “shell” compuesto por y enviada a uno de los componentes de CARUSO. Además tiene herramientas para monitorear el estado del software CRM y generar reportes personalizados. Figura 1.4 Proyecto CARUSO [16] 1.3.4 Conclusiones Una herramienta CRM es una buena alternativa para automatizar los procesos de cara al cliente de las áreas de Ventas y Atención al Cliente. Además tiene el valor agregado de otorgar información precisa del cliente a la empresa para que pueda desarrollar estrategias más enfocadas en el mismo y generar rentabilidad. Actualmente existen varias soluciones CRM en el mercado para conseguir estos beneficios. Pero no muchas están orientadas específicamente a empresas de la 17 industria de telecomunicaciones, y mucho menos, a la industria de la televisión de pago. Como ya se comentó en el apartado de la problemática, la creciente demanda de estos servicios en el Perú y la necesidad de las empresas de entender a sus clientes justifican la inversión en este tipo de tecnología. En la presente tesis se propone implementar un sistema de información CRM para las necesidades específicas de una empresa mediana de servicios de televisión de pago. De esta forma, se espera contribuir en el desarrollo de mejores soluciones de software para este rubro de negocio. 1.4 Objetivo general Analizar, diseñar e implementar un sistema CRM en una empresa proveedora de servicios de televisión de pago para dar soporte a las operaciones de gestión y seguimiento de clientes. 1.5 Objetivos específicos 1. Analizar los métodos y procedimientos del negocio para identificar las necesidades de automatización. 2. Diseñar un repositorio de datos para la gestión y seguimiento del cliente. 3. Desarrollar un prototipo del sistema de información para la definición de los requisitos detallados de entrada, procesamiento y salida. 4. Desarrollar un mecanismo que soporte la carga de información de los clientes de la empresa. 5. Implementar algoritmos para ejecutar la asignación automática de clientes a vendedores y de agendas a técnicos. 1.6 Resultados esperados  Resultado 1 para el objetivo 1: Modelo de procedimientos levantados de la empresa.  Resultado 2 para el objetivo 2: Modelo de base de datos centralizada que permita gestionar al cliente a través de los diferentes procedimientos analizados. 18  Resultado 3 para el objetivo 3: Prototipo del sistema de información que permita al usuario realizar intuitivamente las tareas de carga masiva y administración de la información de los clientes.  Resultado 4 para el objetivo 4: Interfaz de carga de datos de clientes utilizando archivos XML.  Resultado 5 para el objetivo 5: Pseudocódigo de los algoritmos que resuelvan el problema de asignación generalizada. 1.7 Métodos, metodologías y procedimientos En este apartado se describen las metodologías utilizadas para la gestión del proyecto; así como aquellas seleccionadas para alcanzar los resultados esperados. 1.7.1 Relacionados a la gestión del proyecto Se utilizarán los principios metodológicos del PMBOK (Project Management Body of Knowledge) para llevar a cabo la gestión del presente proyecto de tesis. Esto puede tener un impacto considerable en el éxito del proyecto, debido a que proporcionan un conjunto de conocimientos, procesos, habilidades, herramientas y técnicas que se aplican a la mayoría de proyectos, y que existe consenso sobre su valor y utilidad. Aplicar las buenas prácticas del PMBOK no significa que se deba aplicar la metodología completa de la misma forma en todos los proyectos, sino que se debe establecer lo que es apropiado para un proyecto determinado [17]. En primer lugar, se aplicará el área de conocimiento de Gestión del alcance para definir, verificar y controlar qué se incluye y qué no se incluye en el proyecto. Se utilizará una Estructura de Descomposición de Trabajo (EDT) en el proyecto para la subdivisión del proyecto en entregables, que abarcará las etapas de análisis, diseño e implementación. Se utilizarán las buenas prácticas de la Gestión del tiempo como una guía para alcanzar la finalización del proyecto a tiempo, a través de la definición y estimación de la duración de las actividades necesarias. El objetivo es llevar un control adecuado del cronograma. 19 Con el fin de presentar una estimación de los costos que justifiquen la viabilidad del proyecto y para mantener bajo control los costos asociados, los mínimos posibles en este caso, se seguirá la metodología de Gestión de costos. Finalmente, los riesgos relacionados al desarrollo de software deben ser identificados tempranamente y controlados según el impacto que podrían causar. Se implementarán los procesos de planificación de gestión de riesgos y respuesta a los mismos; además de métodos de monitoreo y control definidos en el PMBOK. Como se mencionó, no se aplicarán todos los principios al proyecto. A continuación se detallarán las respectivas justificaciones: El proyecto será llevado a cabo por una sola persona: el tesista; por lo que no es necesario llevar a cabo la Gestión de recursos humanos. Por último, no se realizará compras o adquisiciones de productos o servicios que representen un gran impacto. Además, se cuenta, de antemano, con las herramientas necesarias para llevar a cabo la construcción de la solución. Por estas razones no utilizarán los principios de la Gestión de adquisiciones. 1.7.2 Relacionados al desarrollo del producto  BPMN Para desarrollar el resultado esperado relacionado con el modelamiento de procesos de negocio de la empresa objetivo, se seguirán los principios metodológicos de la Gestión de Procesos de Negocio (BPMN: Business Process Model and Notation). Este conjunto de métodos, herramientas y tecnologías, se utiliza frecuentemente en el diseño, representación, análisis y control de procesos de negocio operacionales. BPMN está enfocado en los procesos para mejorar el rendimiento combinado de las tecnologías de información con metodologías de proceso y gobierno [18]. En el presente proyecto, se utilizará fundamentalmente la metodología propuesta por BPMN para el diseño y modelado de los procesos levantados. A través de la aplicación de este principio es posible, de forma sencilla y rigurosa, la definición de los procesos que serán automatizados por el sistema desarrollado. Se identificarán los 20 roles y comportamientos de las personas y recursos necesarios dentro de los procesos.  RUP Para alcanzar los resultados esperados relacionados con el ciclo de vida de desarrollo de software se utilizarán los principios metodológicos de RUP (Rational Unified Process). Este framework de procesos provee un conjunto de conocimiento base y herramientas para la implementación de sistemas de información [19]. Mediante el uso de la metodología ofrecida por RUP, se espera desarrollar los resultados esperados: o Base de datos centralizada que permita gestionar la información del cliente a través de los diferentes procedimientos que corresponden la estrategia CRM. o Interfaz de carga de datos de clientes utilizando archivos XML. o Prototipo del sistema de información que permita al usuario realizar intuitivamente las tareas de carga masiva y administración de la información de los clientes. La metodología RUP sugiere que el software debe desarrollarse mediante cuatro fases, donde cada una consiste de una o más iteraciones. Dentro del proyecto de la presente tesis no se utilizará toda la metodología provista por RUP a través de estas fases, sino que se aplicarán las que sean convenientes en este proyecto en particular. A continuación se detallarán, por fase, los elementos que se utilizarán: o Fase de Incepción: Dentro de esta fase, se considera la delimitación del alcance del sistema y se entienden los detalles de las reglas de negocio gracias a la recopilación de información por parte de los usuarios correspondientes. Aplicación al proyecto: - Documento de Visión (ANEXO A) o Fase de Elaboración: En esta fase se realiza el análisis y diseño del sistema a desarrollar. Se determinan las funcionalidades que se soportaran así como se define una arquitectura estable para el desarrollo. Aplicación al proyecto: - Documento de Análisis y Diseño 21 - Especificaciones de casos de uso (ANEXO G: Especificación de Requisitos del Software) - Diagrama de base de datos o Fase de Construcción: Se emplearán como guía las buenas prácticas de RUP en la codificación del sistema de acuerdo a las iteraciones programadas y la ejecución de las pruebas. Aplicación al proyecto: - Módulos con implementación finalizada (Primera iteración, Segunda iteración, Tercera iteración) - Documento de Pruebas o Fase de Transición: En esta fase no se aplicarán las metodologías de RUP enfocadas a la venta y/o puesta en producción del producto resultante, las cuales son actividades relacionadas a la implantación del sistema, mientras que el presente proyecto está limitado a la construcción del sistema. Por ende, sólo se aplicarán los principios para el desarrollo del producto final y las instrucciones de instalación y configuración. Aplicación al proyecto: - Manual de instalación y configuración (ANEXO I) 1.8 Alcance y limitaciones En este apartado se define qué se incluye y qué no se incluye en el proyecto de tesis. 1.8.1 Alcance El presente proyecto plantea una solución para ser usada exclusivamente en una empresa seleccionada del rubro de servicios de televisión de pago, debido a que el desarrollo será realizado teniendo en cuenta las particularidades de sus procesos y modelo de negocio. El proyecto de tesis se limitará a las etapas de análisis, diseño, construcción y pruebas del sistema de información propuesto. 22 De este modo, el proyecto se enfocará en la automatización de las operaciones de gestión y seguimiento de clientes a través de las áreas de Ventas y Atención al Cliente, las cuales son el enfoque de la gestión de la relación con los clientes como ya se describió. Particularmente, el sistema resultante brindará:  Soporte del proceso de comercialización del área de Ventas.  Soporte del proceso de atención de reclamos del área de Atención al Cliente. En cuanto al producto resultante del proyecto, este será basado en web y podrá ser accedido desde el navegador Google Chrome. Además, permitirá al usuario realizar cargas masivas de información de clientes a partir de los archivos XML que genera la herramienta de exportación del sistema ERP (Enterprise Resource Planning) que maneja la empresa objetivo. 1.8.2 Limitaciones Como se comentó, el producto a ser desarrollado estará orientado a un tipo particular de empresa. En ese sentido, se deben tener en cuenta aspectos que pueden impactar negativamente en el proyecto, considerados como limitaciones y obstáculos los cuales son mencionados a continuación.  El levantamiento de información puede dificultarse en caso que el grupo de usuarios, tanto jefes de área como colaboradores, no sepa explicar con suficiente detalle que esperan o que requieren de la herramienta para sus actividades diarias. Asimismo, para lograr tener la colaboración e interés del personal para el presente desarrollo, es necesario el apoyo y promoción de los niveles más altos de la empresa.  En cuanto a la facilidad para la codificación del sistema, esto dependerá de las tecnologías seleccionadas (lenguaje de programación, frameworks, entorno de desarrollo, etc.) así como la experiencia y habilidad del propio tesista.  El sistema no soportará los procesos de gestión de recursos materiales del área técnica que estén relacionados con la atención de reclamos, sólo se tendrá en cuenta a los clientes. De este modo, no registrará el equipo o material de trabajo técnico.  El tiempo que requiere el análisis, diseño y desarrollo del producto, así como otras actividades pertinentes al proyecto, está limitado a la disponibilidad del tesista, siendo en este caso un período de un ciclo académico regular más vacaciones de verano (6 meses). 23 1.9 Viabilidad y justificativa del proyecto A continuación se detalla el análisis de la viabilidad del proyecto y las razones que justifican su puesta en marcha. 1.9.1 Análisis de viabilidad En este apartado se realizará un análisis de viabilidad del proyecto de implementación de un sistema CRM según el alcance propuesto en el acápite anterior. En el presente proyecto de tesis se tomarán en cuenta dos aspectos fundamentales que definirán la viabilidad del mismo: tiempo y costo.  Tiempo Respecto al tiempo de ejecución del proyecto, este será de aproximadamente seis meses, empezando desde el inicio del mes de enero de 2013 y finalizando a principios del mes de julio del mismo año. Durante cada semana del espacio de tiempo propuesto, se espera dedicar 15 horas a las actividades planificadas. Se utilizarán los principios metodológicos del PMBOK para llevar a cabo la Gestión del Tiempo del proyecto, por lo que se espera llevar un control riguroso de los tiempos propuestos y cumplir satisfactoriamente con el cronograma establecido. Se tiene como consideración principal que el equipo de ejecución del proyecto estará compuesto únicamente por una persona, la cual tiene la experiencia y conocimientos necesarios para la implementación de un sistema web. En otras palabras, durante el proyecto no se espera tener problemas o retrasos considerables con respecto al aprendizaje de herramientas, metodologías o tecnologías. Cumpliendo la metodología propuesta y con las ventajas mencionadas, el tiempo de 6 meses es viable para la finalización del proyecto con una sola persona encargada.  Costo El análisis de costos involucra los factores económicos que permitirán llevar a cabo la implementación del sistema. Se realizó una estimación del costo de las actividades 24 laborales, calculado a partir de las horas/hombre empleadas en cada etapa. El costo de las actividades de gestión, presente durante toda la vida del proyecto, está incluido en el costo de hora/hombre. Asimismo se consideró el costo de actividades no laborales como transporte, materiales (considerando principalmente el costo del uso de una computadora personal) e impresiones. El resultado de la estimación se puede observar en la Tabla 1.2. Estimación de costos Actividades Esfuerzo (días) Horas/hombre diarias Esfuerzo total (horas/hombre) Costo (S/.) Laborales Gestión 121 0.5 60.5 1,512.5 Análisis 37 3.5 129.5 3,237.5 Diseño 15 3.5 52.5 1,312.5 Construcción 100 3.5 350 8,750.0 Pruebas 15 3.5 52.5 1,312.5 Total laborales 16,125.0 No laborales Transporte 150.0 Materiales 100.0 Impresiones 75.0 Total no laborales 325.0 Total 16450.0 Costo de hora/hombre = S/.25 Tabla 1.2 Estimación de costos No se espera incurrir en más gastos considerables durante el proyecto, pero el número total de horas de trabajo estimadas siempre es susceptible a cambiar debido a cambios en la planificación inicial del desarrollo del sistema. Para ello se llevará un control de los costos adicionales que puedan generar las horas no contempladas al principio. En resumen, el proyecto será desarrollado durante un espacio de tiempo razonable para cumplir con el alcance del mismo, considerando que será ejecutado únicamente por una persona. Se tiene como ventaja principal que la persona a cargo cuenta con las capacidades, recursos necesarios y disponibilidad para llevar a cabo el desarrollo 25 del sistema sin tener mayores inconvenientes. Además, no se esperan costos durante el proyecto que representen un impacto negativo importante en la ejecución del mismo. En base a las razones expuestas, los objetivos y el alcance del presente proyecto de fin de carrera se pueden cumplir considerando los factores de tiempo y costo. De este modo, se concluye que el proyecto es viable. 1.9.2 Justificativa A continuación se detallarán las razones que justifican la ejecución del proyecto:  Motivación En la investigación del estado del arte se encontraron soluciones que cubrían ciertos aspectos de la problemática planteada. Las soluciones consisten en sistemas CRM para medianas empresas en general, es decir, no están orientadas al perfil de las empresas de servicio público de telecomunicaciones. De este modo, cubren el soporte de parte de las operaciones de gestión y seguimiento de clientes en una empresa proveedora de servicios de televisión de pago. Como valor agregado del sistema, se implementará un algoritmo que soporte la asignación de clientes entre el personal, tanto a vendedores como a técnicos. Así, la motivación principal del proyecto se encuentra en desarrollar una solución que contribuya al estado del arte del problema planteado. Como motivación personal, se tendrán en consideración las preferencias y conocimientos de la persona que ejecutará el proyecto, fundamentalmente sobre sistemas de información basados en web y lenguajes de programación como Java.  Beneficios La implementación del sistema resultante del presente proyecto en una empresa de televisión de cable permitirá que pueda contar con información empírica sobre el nivel de conocimiento de las necesidades específicas de cada cliente. De esta forma, la empresa podrá realizar sus operaciones de gestión y seguimiento de clientes sobre una base adecuada y bien definida. 26 Esto se logrará a través del soporte de los procesos de interacción con el cliente. Como primer paso, se realizará un análisis y modelamiento de dichos procesos. La empresa se beneficiará de la documentación resultante y el modelo de procesos actualizado. Luego, el sistema CRM permitirá la reducción de tiempos en la ejecución de las operaciones soportadas. Todo esto, manteniendo un ratio costo-beneficio aceptable según la estimación de costos realizado para el proyecto en el apartado anterior. Por último, la herramienta CRM correctamente implementada se puede convertir en sinónimo de ventaja competitiva y protección del negocio. 1.10 Plan de proyecto Siguiendo la metodología de PMBOK, en este apartado se detalla el plan de actividades del proyecto y la estructura de descomposición del trabajo. 1.10.1 Plan de actividades En este apartado se definen las actividades necesarias para el cumplimiento del proyecto de tesis. Como se mencionó anteriormente, el tiempo de ejecución del proyecto es de aproximadamente 6 meses. Se realizarán las actividades desde el inicio del mes de enero del año 2013 y se espera la conclusión y cierre del proyecto a inicio del mes de julio del mismo año. Se elaboró un diagrama de Gantt con el plan de actividades del proyecto en el ANEXO B. Dentro del plan se considera fundamentalmente las actividades concernientes a la gestión del proyecto, siguiendo los principios del PMBOK y las actividades de análisis, diseño e implementación del sistema, siguiendo la metodología RUP. 1.10.2 Estructura de Descomposición del Trabajo Para la mejor organización del proyecto se procedió a dividirlo en tareas y actividades cuyo resultado esperado son entregables, los cuales componen el EDT que se presenta en la Figura 1.5. 27 Figura 1.5 Estructura de Descomposición de Trabajo En el ANEXO C se puede apreciar el diccionario del EDT, en el cual se detalla los paquetes de trabajo que componen el proyecto de desarrollo de software. Por cada paquete hay uno o más entregables. Se definen también los criterios de aceptación de los entregables, para lograr que sean de calidad; y la duración estimada para su realización, la cual está en concordancia con el cronograma del plan de proyecto. 1.10.3 Gestión de riesgos Se identificaron los riesgos que representan amenazas para el proyecto de desarrollo de software. Según los principios del PMBOK, es necesario categorizarlos según la probabilidad de que ocurran y el impacto que podrían causar. De esa forma, se mantienen bajo control y se realiza seguimiento de los riesgos que tienen la severidad más alta. En el ANEXO D se encuentra el documento de gestión de riesgos, el cual fue actualizado a lo largo del proyecto. Algunos de los riesgos se volvieron realidad y otros dejaron de ser una amenaza para el proyecto de acuerdo a la etapa alcanzada. Desarrollo de un sistema de Gestión de la Relación con los Clientes para una operadora de TV de pago Gestión del proyecto Plan de Proyecto Ejecución y control del proyecto Cierre del proyecto Plan de gestión de riesgos Análisis Análisis de procesos Catálogo de requisitos ERS Diseño Documento de arquitectura Prototipo de GUI Plan de pruebas Modelo de base de datos Construcción Módulo de seguridad Módulo de mantenimiento Módulo de ventas Módulo de atención al cliente Módulo de reportes Pruebas Pruebas unitarias Pruebas integrales 28 Capítulo 2 : Análisis En este capítulo se abarca la etapa de análisis de la solución informática propuesta. Se incluye el modelado de procesos, la especificación de requerimientos del sistema y la especificación de los casos de uso. 2.1 Modelado de procesos En el presente apartado se detallan las actividades que constituyen los procesos de negocio que son objetivo del sistema de información a desarrollar, siguiendo la notación BPMN 2.0 para el modelado de procesos. Como se detalló en el apartado de Metodologías, BPMN provee una forma sencilla y rigurosa de definir las tareas de un proceso de acuerdo a los estándares propuestos. Asimismo, se identifican los roles de las personas y recursos dentro de los procesos que serán la base del capítulo de análisis de la solución informática. Los procesos de negocio que serán documentados en este proyecto comprenden:  Comercialización  Venta y seguimiento de clientes  Atención de reclamo  Registro de reclamo La implementación del sistema CRM desarrollado en este proyecto tendrá un impacto en los procesos de negocio mencionados. Por eso motivo, los cambios esperados son detallados en este capítulo, incluyendo también el modelado de los procesos de negocio actualizados con el uso de la herramienta propuesta. A continuación se describen los procesos de negocio y se muestran los diagramas de los modelos correspondientes. 29 2.1.1 Comercialización Figura 2.1 Modelo del proceso de comercialización 30 2.1.1.1 Detalle del proceso El equipo de Ventas es responsable de la comercialización y promoción de los servicios y productos de la empresa en este proceso. El proceso de comercialización comienza con la decisión de promocionar un servicio o producto de la empresa a un determinado grupo de clientes. Normalmente el jefe de Ventas utiliza el ERP de la empresa para obtener un archivo Excel con los abonados, y selecciona los prospectos que requiera de los informes entregados por sus vendedores previamente. Luego, consolida la información de abonados y prospectos en un único archivo Excel, los cuales serán el público objetivo del proceso. A cada vendedor se le asignan clientes para contactarlos y, posteriormente, darle seguimiento a través de actividades como llamadas telefónicas, correo electrónico o visitas a domicilio con el fin de lograr ventas para la empresa. Estas actividades constituyen el subproceso de venta y seguimiento de clientes. Una vez que se llega a la fecha de cierre de campaña, el jefe de Ventas comunicará a sus colaboradores el fin de actividades correspondientes a este proceso. Cada vendedor entregará un informe con el resumen de las ventas que consiguió y las negociaciones que no llegó a concluir. Como última actividad, el jefe elabora manualmente un informe de cierre de campaña con los resultados totales obtenidos. El sistema CRM desarrollado en este proyecto mantiene en un repositorio centralizado la información de prospectos y abonados, permitiéndole al jefe de Ventas generar la lista de clientes objetivo sin la necesidad de consolidar manualmente la información de distintas fuentes. Luego, se podrán asignar automáticamente los clientes seleccionados a los vendedores mediante el algoritmo implementado. Una vez que el jefe confirme el resultado de la asignación de clientes, los vendedores podrán visualizar a los clientes que les han sido asignados y completar los detalles de las negociaciones en el sistema conforme las vayan realizando. En la Figura 2.2 se puede apreciar el modelo del proceso actualizado. 2.1.2 Venta y seguimiento de clientes Para apreciar este proceso y su detalle, referirse al ANEXO F. 31 Figura 2.2 Modelo del proceso de comercialización actualizado 32 2.1.3 Atención de reclamo Figura 2.3 Modelo del proceso de atención de reclamo 2.1.3.1 Detalle del proceso Diariamente los operadores del Área de Atención al Cliente reciben llamadas telefónicas de los clientes que tengan un reclamo sobre su servicio. Normalmente los reclamos son registrados en formularios impresos. Estas actividades realizadas por los operadores constituyen el subproceso de registro de reclamo. 33 Luego de obtener los formularios completados por los operadores, el jefe del área asignará un técnico a una agenda luego de revisar la prioridad del reclamo y el tipo de avería que se ha reportado. Asimismo, se encarga de la gestión de la atención del cliente con el objetivo de no sobrepasar el plazo de atención establecido. El técnico asignado deberá realizar la actuación técnica en el domicilio del cliente en la fecha acordada durante el registro del reclamo. En el caso que la avería no se haya solucionado con la actuación técnica, el técnico debe agendar una nueva visita con el fin de terminar el trabajo. Cuando el técnico asegura que la avería del servicio se ha solucionado, se procede a liquidarla completando el formulario del reclamo con los detalles correspondientes. Finalmente, si es requerido, el jefe del área se contacta con el cliente para verificar la conformidad de la atención técnica. Con la implementación de la herramienta propuesta, se pretende registras las agendas técnicas en la base de datos para una mejor gestión. El jefe de atención al cliente podrá visualizar las agendas pendientes y asignarlas automáticamente a los trabajadores teniendo en cuenta que la prioridad del reclamo, la hora de la visita y la experiencia del técnico. Cuando el jefe confirme los resultados de la asignación de agendas, los técnicos tendrán acceso a los reclamos correspondientes para poder registrar las actuaciones técnicas que realicen y liquidar el reclamo cuando el problema sea resuelto. Una gran ventaja es que el jefe puede consultar en cualquier momento el avance del cumplimiento de la atención de reclamos. En la Figura 2.4 se puede apreciar el diagrama del proceso de atención de reclamo actualizado. 2.1.4 Registro de reclamo Para apreciar este proceso y su detalle, referirse al ANEXO F. 34 Figura 2.4 Modelo del proceso de atención de reclamo actualizado 2.2 Identificación de requerimientos En este apartado se presentará la especificación de los requisitos funcionales y no funcionales del sistema a desarrollar como parte del proyecto de fin de carrera. 35 2.2.1 Requerimientos funcionales Los requerimientos funcionales deben considerar: las necesidades de automatización de los procesos de negocio que se detallaron en el apartado anterior, la configuración de los parámetros del sistema y la disponibilidad de reportes para determinados periodos de tiempo. 2.2.1.1 Módulo de Ventas En la Tabla 2.1 se listan los requerimientos del módulo de Ventas. Código Descripción VE001 El sistema permitirá registrar y editar una lista de clientes objetivo del proceso de comercialización de un servicio de la empresa. VE002 El sistema permitirá buscar clientes por filtros de datos personales o paquete de televisión asociado para incluirlo en la lista de clientes potenciales. VE003 El sistema permitirá asignar los clientes de una lista a un conjunto de vendedores utilizando un algoritmo. La asignación debe ser según el costo del servicio actual y la deuda que tenga en ese momento, así como el record de ventas del vendedor. VE004 El sistema permitirá asignar manualmente un cliente de la lista a un vendedor. VE005 El sistema enviará una notificación automática a los vendedores de los clientes que le fueron asignados. VE006 El sistema permitirá ver los detalles de cada cliente asignado incluyendo sus datos personales y los del servicio con el que cuenta. VE007 El sistema permitirá ver el historial de actividades que se han realizado con el cliente, separando la negociación actual de las anteriores. VE008 El sistema permitirá programar y editar una actividad de seguimiento (comunicación telefónica, encuentro, mail) con el cliente. VE009 El sistema permitirá visualizar las actividades en un calendario, con la opción de acceder a la edición de las actividades. VE010 El sistema permitirá cerrar la negociación con el cliente, indicando si fue éxito o fracaso; y registrando la fecha de cierre. Tabla 2.1 Requerimientos del módulo de Ventas 2.2.1.2 Módulo de Atención al Cliente En la Tabla 2.2 se listan los requerimientos del módulo de Atención al cliente. 36 Código Descripción AC001 El sistema permitirá registrar un reclamo del servicio que reporte el cliente. El reclamo debe estar asociado al servicio con el que cuente el cliente. AC002 Debido a que el titular del servicio no necesariamente es el que realiza la llamada de reclamo, el sistema permitirá registrar a la persona que realizó el reclamo como “contacto”. AC003 Si el reclamo es de tipo administrativo, será posible enviar una notificación con los detalles necesarios a un correo electrónico que se haya configurado inicialmente. AC004 El sistema permitirá agendar una visita técnica al cliente para solucionar la avería reportada. Si hay una agenda pendiente anterior, se debe cancelar. Asimismo, no se debe permitir que se registren nuevas agendas sobre una avería que tiene una agenda en curso hasta después del número de horas configuradas. AC005 El sistema mostrará un mensaje de alerta al usuario si desea agendar una visita técnica en un día que haya alcanzado el límite de agendas máximas por día. En caso el usuario agende una visita técnica en dicho día se enviará una notificación automática al Jefe del Área Técnica. AC006 El sistema enviará una notificación automática al Jefe del Área Técnica si se cancela una agenda que ya tenía un técnico asignado. AC007 El sistema permitirá registrar una observación sobre una avería pendiente si el cliente realiza una segunda llamada de reclamo sobre una misma avería. AC008 El sistema permitirá visualizar el historial de observaciones y agendas realizadas en el reclamo. AC009 El sistema permitirá visualizar las averías pendientes que hayan sido agendadas utilizando filtros de rango de fechas y estado. Se debe resaltar las averías de clientes críticos. AC010 El sistema permitirá asignar las agendas pendientes a los técnicos utilizando un algoritmo. La asignación debe ser según la prioridad de la avería reportada y la agenda correspondiente; y la carga de trabajo del técnico y cantidad de agendas que haya atendido con el mismo tipo de avería. AC011 El sistema permitirá asignar manualmente una agenda pendiente a un técnico. AC012 El sistema enviará una notificación automática al técnico con la agenda que le fue asignada. AC013 El sistema permitirá modificar el estado de una agenda de visita técnica para indicar que fue atendida o se encuentra en curso, registrando además la fecha y hora de modificación, el técnico responsable y actividades realizadas. AC014 El sistema permitirá cambiar el estado del reclamo a liquidada. Se deberá registrar la fecha y hora de modificación, el usuario responsable, y el tiempo total transcurrido desde que se registró el reclamo. Tabla 2.2 Requerimientos del módulo de Atención al cliente 37 2.2.1.3 Mantenimiento En la Tabla 2.3 se listan los requerimientos del módulo de Mantenimiento. Código Descripción MA001 El sistema permitirá registrar y editar a las personas interesadas en el servicio (prospectos). MA002 El sistema permitirá realizar la carga de los abonados mediante un archivo XML. Se cargaran tanto los datos personales del abonado como los detalles del servicio(s) con el que cuenta actualmente. MA003 El sistema permitirá registrar y editar los paquetes de televisión de cable de la empresa. MA004 El sistema permitirá registrar y editar los tipos, tiempos máximos de atención y notificaciones por correo electrónico de los reclamos. MA005 El sistema permitirá registrar y editar los motivos y acciones de agendas y observaciones realizadas sobre una avería. MA006 El sistema permitirá realizar el mantenimiento de los parámetros de los algoritmos para asignación de clientes. Tabla 2.3 Requerimientos del módulo de Mantenimiento 2.2.1.4 Seguridad En la Tabla 2.4 se listan los requerimientos del módulo de Seguridad. Código Descripción SE001 El sistema permitirá registrar y administrar los perfiles del sistema. SE002 El sistema permitirá registrar y administrar los usuarios del sistema. Tabla 2.4 Requerimientos del módulo de Seguridad 2.2.1.5 Reportes En la Tabla 2.5 se listan los requerimientos del módulo de Reportes. 38 Código Descripción RE001 El sistema permitirá generar el reporte del proceso de comercialización. Se mostrarán las ventas realizadas, fracasos de venta, tiempo total invertido y tiempo estimado. RE002 El sistema permitirá generar el reporte de las actividades ventas. Se deben mostrar el total de prospectos nuevos, clientes regulares y servicios vendidos agrupados por mes. RE003 El sistema permitirá generar el reporte de reclamos en un rango de tiempo determinado. Se debe mostrar el total de reclamos registrados, liquidados, promedio de tiempo de atención, agrupados por mes y tipo de reclamo. RE004 El sistema permitirá generar el reporte del nivel de servicio en un rango de tiempo determinado. Se debe mostrar el total de averías atendidas y las que sobrepasaron el número de horas máximas de atención. RE005 El sistema permitirá exportar los reportes a PDF para poder imprimirlos. Tabla 2.5 Requerimientos del módulo de Reportes 2.2.2 Requerimientos no funcionales En la Tabla 2.6 se especifican los requerimientos de software y hardware que debe cumplir el servidor que alojará el sistema y las computadoras cliente que accederán a través de navegador web. Requerimientos del servidor Código Descripción NF001 Sistema Operativo Windows XP/Vista/7/8 o Linux NF002 Servidor Web Apache Tomcat 7.0.27.0 como contenedor de J2EE NF003 Oracle JRE Runtime Environment 1.7 NF004 Memoria RAM 2GB NF005 Motor de Base de Datos Microsoft SQL Server 2008 R2 Requerimientos del PC cliente Código Descripción NF006 Sistema Operativo Windows XP/Vista/7/8 o Linux NF007 Navegador Google Chrome Versión 25.0.x.x m Tabla 2.6 Requerimientos no funcionales 39 2.3 Análisis de la solución En este apartado se realiza la especificación de actores, casos de uso y diagrama de clases de análisis. Los cambios que se puedan realizar sobre las funcionalidades del sistema, resultado del análisis realizado en esta etapa del proyecto, se registran en el documento de control de cambios que se incluye en el ANEXO E. 2.3.1 Especificación de actores En esta sección se muestra a los actores que participan en el sistema y que fueron identificados previamente en el modelo de procesos de negocio. 1. Jefe de Ventas: Persona encargada de la planificación de ventas en la empresa. Es responsable de dirigir al equipo de Ventas para ejecutar los procesos del área y alcanzar las proyecciones realizadas. Funciones:  Administrar paquetes de TV de la empresa.  Generar lista de clientes objetivo.  Asignación de clientes a vendedor.  Generar reporte de ventas. 2. Vendedor: Persona encargada de contactar y darle seguimiento al cliente para concretar la venta de un servicio. Acordará actividades con el cliente o le hará saber de las ofertas de servicios de televisión de pago a través de diversos medios. La negociación con el cliente puede terminar en éxito o fracaso. Funciones:  Registrar prospectos.  Programar actividad de seguimiento.  Cerrar negociación. 3. Operador: Persona encargada de recepcionar las llamadas del cliente para atender sus reclamos, los cuales son derivados al Área Técnica. 40 Funciones:  Registrar contacto.  Registrar reclamo.  Agendar visita técnica.  Registrar observaciones de avería. 4. Jefe de Atención al cliente: Persona encargada de la gestión de los reclamos ingresados. Asigna las agendas de averías técnicas entre los técnicos y es el principal encargado de solucionar las averías reportadas, dando prioridad a los clientes críticos. Funciones:  Configuración de parámetros de atención al cliente  Asignar agenda a técnico.  Administración de reclamo.  Generar reporte de reclamos. 5. Técnico: Persona encargada de realizar visitas técnicas que le han sido asignadas para solucionar las averías que reportaron los clientes. Una vez solucionada, el técnico liquida el reclamo. Puede agendar una visita extra si es necesario. Funciones:  Actualizar estado de agenda.  Agendar visita técnica.  Liquidar reclamo. 6. Administrador: Persona encargada de la administración y configuración de los parámetros del sistema; y de la carga de la información de los abonados de la empresa. También se encarga de la gestión de usuarios y perfiles. Funciones:  Administración de usuarios y perfiles.  Carga de abonados.  Configurar parámetros del sistema. 41 2.3.2 Diagrama de paquetes El sistema fue organizado en paquetes, donde cada paquete corresponde a un módulo. En la Figura 2.5 se muestra el diagrama de paquetes del sistema y la dependencia entre ellos. Como parte de la metodología RUP, se utilizó el Lenguaje Unificado de Modelado (UML) para elaborar este diagrama. Figura 2.5 Diagrama de paquetes del sistema 2.3.3 Diagramas de Casos de uso A partir de la identificación de los requerimientos funcionales del sistema y los actores que participarán en el uso del mismo, se realizó la especificación de los casos de uso. Los últimos están agrupados en los módulos que conforman el sistema: Mantenimiento, Ventas, Atención al Cliente, Seguridad, Reportes. En la Tabla 2.7 se muestran los casos de uso y los requerimientos funcionales que cumple cada uno. Como se puede observar, algunos tienen más requerimientos asociados que otros, lo cual aumenta la complejidad al momento de la codificación. En las siguientes subsecciones se muestran los diagramas y las descripciones generales de los casos de uso principales del sistema propuesto por paquete definido. Para el caso de los diagramas, se siguió el formato UML con el fin de mantener el estándar sugerido en la documentación. 42 Código Caso de Uso Requerimientos Paquete de Mantenimiento CU001 Administración de prospectos MA001 CU002 Carga de abonados MA002 CU003 Administración de paquetes de TV MA003 CU004 Configuración de reclamo MA004, MA005 CU005 Configuración de algoritmos MA006 Paquete de Ventas CU006 Administración de comercialización VE001, VE002 CU007 Asignación de clientes VE003, VE004, VE 005 CU008 Programación de actividad VE006, VE007, VE 008, VE009 CU009 Cierre de negociación VE010 Paquete de Atención al Cliente CU010 Administración de reclamo AC001,AC002,AC003, AC008 CU011 Agendar visita técnica AC004, AC005, AC006 CU012 Observación de reclamo AC007 CU013 Asignación de agendas AC009, AC010, AC011, AC012 CU014 Cumplimiento de agenda AC013, AC014 Paquete de Reportes CU015 Reporte de comercialización RE001, RE005 CU016 Reporte de actividades de ventas RE002, RE005 CU017 Reporte de reclamos RE003, RE005 CU018 Reporte de Acuerdo de nivel de servicio RE004, RE005 Paquete de Seguridad CU019 Administración de perfiles SE001 CU020 Administración de usuarios SE002 Tabla 2.7 Casos de Uso y Requerimientos Funcionales 2.3.3.1 Casos de uso del Paquete de Mantenimiento Los casos de uso de este paquete son los relacionados a la administración de los prospectos y paquetes de TV; así como la configuración de reclamos, notificaciones y algoritmos. También se incluye el caso de uso que realiza la carga de la información de los abonados de la empresa. Ver Figura 2.6. 43 Figura 2.6 Diagrama del paquete de Mantenimiento  Administración de prospectos Este caso de uso permite realizar el mantenimiento de los prospectos que los vendedores consigan en sus actividades. Los prospectos son objetivos del proceso de comercialización en los siguientes casos de uso.  Carga de abonados Este caso de uso permite cargar la información de los clientes desde un archivo en formato XML y almacenarla en la base de datos del sistema.  Administración de paquetes de TV Este caso de uso permite realizar el mantenimiento de los paquetes de televisión de la empresa. El sistema permitirá colocar los paquetes activos como objetivo de venta en los siguientes casos de uso.  Configuración de parámetros de atención Este caso de uso permite configurar los límites de tiempo de atención a los reclamos del cliente y realizar el mantenimiento de los tipos de reclamo y de observaciones que se puedan registrar. 44  Configuración de algoritmos Este caso de uso permite configurar los parámetros del algoritmo utilizado para la asignación de clientes y agendas a los vendedores y técnicos respectivamente. 2.3.3.2 Casos de uso del Paquete de Ventas Los casos de uso de este paquete son los relacionados al soporte del proceso de comercialización. Los casos de uso realizan la administración de la lista de clientes objetivo y la asignación de los mismos a los vendedores. Ver Figura 2.7. Figura 2.7 Diagrama del paquete de Ventas  Administración de comercialización Este caso de uso permitirá registrar y editar una lista de clientes objetivo para el proceso de comercialización de un paquete de televisión. Permite realizar una búsqueda de prospectos y abonados utilizando diferentes filtros y añadirlos a la lista de objetivos.  Asignación de clientes Este caso de uso permitirá asignar los clientes de una lista a un conjunto de vendedores, que el jefe seleccione, utilizando un algoritmo. La asignación debe ser según el valor del cliente, es decir, basándose en el costo de su servicio actual y la deuda que tenga en ese momento, así como el récord de ventas del vendedor. 45  Programación de actividad Este caso de uso permitirá registrar y editar una actividad de seguimiento al cliente como comunicación telefónica, encuentro o correo electrónico y agregarla al calendario de actividades del usuario.  Cierre de negociación Este caso de uso permitirá cerrar la negociación con el cliente para indicar el fin de las actividades con el mismo, la venta puede resultar en éxito o fracaso. 2.3.3.3 Casos de uso del Paquete de Atención al Cliente Los casos de uso de este paquete son los relacionados a la administración de reclamos y agendas de visita técnica. Ver Figura 2.8. Figura 2.8 Diagrama del paquete de Atención al Cliente  Administración de reclamo Este caso de uso permitirá registrar un reclamo de un cliente. El reclamo se asocia al servicio con el que cuente el cliente y puede ser modificada para aumentar su prioridad según sea el caso. Luego del registro del reclamo se puede agendar una visita técnica. 46  Agendar visita técnica Este caso de uso permitirá agendar una visita técnica a un reclamo pendiente. Se consideró que el técnico pueda asignarse después. La agenda se puede modificar para cambiar la hora de visita o anularla según sea el caso.  Observación de reclamo Este caso de uso permitirá registrar una observación sobre una avería indicando el motivo y la acción que se llevó a cabo.  Asignación de agendas Este caso de uso permitirá asignar las averías que tengan una agenda pendiente a los técnicos dividiendo la carga de trabajo utilizando un algoritmo de distribución de tareas según la prioridad de la avería reportada, la carga de trabajo del técnico y la cantidad de agendas que haya atendido con el mismo tipo de avería.  Cumplimiento de agenda Este caso de uso permitirá editar la agenda para colocarla como cumplida y registrar las actividades que se realizaron en la reparación del servicio del cliente. A continuación el usuario podrá liquidar la avería y el sistema calculará el tiempo total de atención. 2.3.4 Especificación de casos de uso La especificación de los casos de uso principales del sistema, incluyendo el flujo y las condiciones, se encuentra en el documento ERS del ANEXO G. 47 Capítulo 3 : Diseño En este capítulo se abarca la etapa de diseño de la solución informática propuesta. Se incluye la descripción de la arquitectura seleccionada y los criterios que fueron la base del diseño de la interfaz gráfica de usuario. 3.1 Arquitectura del Sistema El sistema de información requirió un patrón de diseño que fuese conveniente para alcanzar los objetivos propuestos relacionados a las actividades de diseño y desarrollo; así como facilitar el cumplimiento de los requerimientos identificados. La arquitectura seleccionada debía proporcionar una forma simple de organizar el código del sistema y de este modo, orientar el desarrollo por buen camino. De este modo, se seleccionó el patrón MVC (Modelo-Vista-Controlador) como la base de la arquitectura que adoptará el sistema de información. Este patrón de diseño ofrece la ventaja de organizar fácilmente las aplicaciones al mantener una clara separación entre la interfaz de usuario y la lógica de negocio. La justificación de esta elección se basa en que:  Permite alcanzar los objetivos específicos rápidamente Entre los objetivos del proyecto se especifica el desarrollo de un prototipo del sistema de información para la definición de los requisitos detallados de entrada, procesamiento y salida. Debido a que una de las principales bondades del patrón de diseño MVC es que permite separar la interfaz gráfica del resto del código del sistema, sería posible desarrollar el prototipo del sistema en primer lugar como parte de la capa de Vista y alcanzar un hito importante del proyecto. El desarrollo posterior del sistema y el cumplimiento del resto de los objetivos se centrarían en las capas de Controlador y Modelo.  Proporciona una base sólida para el desarrollo y despliegue de la aplicación El uso del patrón MVC en el desarrollo de aplicaciones web es considerado recomendable porque organiza la capa Vista corresponde a la interfaz de usuario 48 mostrada en el browser del cliente, la capa Controlador se encarga de recibir los pedidos de los usuarios centralizadamente y realizar cambios en la capa Modelo para finalmente redirigir al usuario a una nueva vista. Entonces, el patrón permite separar la construcción del sistema en el desarrollo de las páginas web de la capa Vista y el desarrollo del servidor para implementar la lógica de negocio.  Abundancia de tecnologías que implementen el patrón Es posible ahorrar tiempo y esfuerzo en la etapa de construcción al utilizar una tecnología web que se encuentre abierta para la comunidad de desarrolladores. Entre la gama de tecnologías disponibles, es posible encontrar marcos de trabajo (frameworks) de desarrollo de software de alta calidad que implementen el patrón MVC. La elección del patrón MVC condujo a utilizar el marco de trabajo JSF (Java Server Faces), el cual es un estándar dentro de la especificación JEE (Java Platform Enterprise Edition).Dicha especificación ofrece un modelo de aplicación distribuible entre las capas Modelo, Vista y Controlador; componentes reusables y simplificación del despliegue de aplicaciones web [20]. En la Figura 3.1 se puede apreciar la arquitectura que se diseñó para la solución. Vista Facelets, XHTML Controlador Faces Servlet Modelo Managed Beans, Hibernate SQL Server Usuario final Petición Respuesta JDBC Figura 3.1 Arquitectura del sistema 49 En las siguientes secciones se especificarán los aspectos técnicos y funciones que desempeña cada capa del patrón MVC en el proyecto.  Vista Responsable de la lógica de la presentación y la captura de datos del sistema. La capa de vista está compuesta por páginas XHTML. Gracias a los componentes de JSF, denominados Facelets, se pueden crear interfaces de usuario mucho más ricas desde el punto de vista de la usabilidad, y simplificar el desarrollo de las páginas web. La versión 2 de JSF da soporte directo a la tecnología AJAX, pudiendo actualizar partes de la página sin necesidad de hacer una petición pesada al servidor. Desde esta forma se mejora el ancho de banda, ya que por la red viajan menos datos, y se mejora la experiencia del usuario.  Controlador Responsable de trasladar las peticiones HTTP del usuario a la capa Modelo, y según la respuesta, la re-direcciona a la capa Vista. El principal componente de esta capa es el Faces Servlet, el motor de todas las aplicaciones basadas en JSF. Además de examinar las peticiones recibidas, se encarga de actualizar la representación del interfaz del cliente y los datos de las clases de la capa Modelo.  Modelo Contiene la lógica y entidades de negocio. La lógica de negocio está contenida en clases de Java denominadas ManagedBeans, los cuales son objetos de respaldo gestionados por JSF. Estos objetos responden a los eventos generados por los componentes durante la ejecución de la aplicación. Por otro lado, las entidades de negocio son modeladas en los componentes denominados Business Beans. La capa Modelo también contiene los objetos de acceso a datos (DAO) que implementan las operaciones de crear, leer, actualizar y eliminar. Se seleccionó el marco de trabajo de desarrollo Hibernate para poder trabajar de forma sencilla con la base de datos. Hibernate es ampliamente utilizado para implementar JPA (Java Persistence API) en los distintos gestores de bases de datos, en este caso SQL Server. Esto permite que el desarrollo se centre en la lógica de negocio, olvidando los detalles de la implementación del acceso a datos. 50 3.1.1 Diagrama de componentes En el diagrama de componentes de la Figura 3.2, se presenta la organización lógica entre componentes de software y las dependencias que mantienen entre sí. Figura 3.2 Diagrama de componentes La vista del diagrama de componentes se concentra en la construcción, la gestión y la reutilización del software. También se consideran las restricciones impuestas por el lenguaje de programación, en este caso Java, y las diversas herramientas seleccionadas para el desarrollo. 3.2 Diseño de Base de datos En este apartado se presenta la estructura lógica de la base de datos del sistema CRM que se obtuvo a partir de la identificación de las clases necesarias para el soporte de las reglas de negocio analizadas. 51 3.2.1 Diagrama de clases En la Figura 3.3 se muestra el diagrama de clases que será la base de la implementación del sistema de gestión de clientes. El diagrama se diseñó a partir de las entidades de negocio identificadas para el soporte de los procesos analizados según la especificación de los requerimientos y los casos de uso. Figura 3.3 Diagrama de Clases 52 3.2.2 Diagrama de base de datos En la Figura 3.4 se muestra el diagrama de base de datos que se obtuvo usando las técnicas de modelamiento y normalización en la estructura presentada en el diagrama de clases. Figura 3.4 Diagrama de base datos 53 3.3 Diseño de Interfaz Gráfica En este apartado se describen los componentes y características de la interfaz gráfica para el sistema de información. La solución propuesta debería poseer una interfaz amigable para el usuario y, principalmente, permitir mostrar de manera ordenada los elementos que conforman el modelo de negocio. 3.3.1 Elementos de diseño Los elementos de diseño de la interfaz gráfica de usuario hacen referencia a la forma de presentación de las pantallas. Los elementos de diseño que se tomaron en cuenta para el desarrollo del sistema se encuentran: diseño estructural y zona de mensajes. 3.3.1.1 Diseño estructural El diseño estructural consiste en un esquema general de la forma de presentación de las pantallas del sistema. Al momento de definir el esquema general se determinan que elementos de diseño, como encabezados y menús, deben ser comunes para la correcta navegación del usuario a través de las pantallas del sistema. Utilizar el diseño estructural trae la ventaja de darle uniformidad al sistema, haciéndolo agradable estéticamente. En la Figura 3.5 se muestra la pantalla principal del sistema CRM basada en el diseño estructural seleccionado. Los elementos del diseño estructural se describen a continuación:  Encabezado: Se ubica en la parte superior de las páginas web y contiene el nombre del usuario que ha iniciado una sesión en el sistema y la opción de cerrar sesión. Además, contiene un logo que identifica la aplicación.  Menú: Se ubica justo debajo del encabezado y consiste en una barra de botones. Su función principal es permitir la navegación a través de los diferentes módulos del sistema. 54  Zona de contenido: Contiene la información que el usuario desee visualizar. Es la más amplia y se altera a medida que se navegue por el sistema de información. Además, contiene una cabecera con la ubicación del usuario en el sistema.  Pie de página: Está ubicada en la parte inferior de las páginas y muestra la información de los derechos de autor. Figura 3.5 Pantalla principal del sistema 3.3.1.2 Zona de mensajes Esta zona se encarga de mostrar los mensajes del sistema, que pueden ser informativos, de error o éxito. Se utilizaron tres esquemas para la implementación de esta zona:  Ventana modal de mensajes: Consiste en una ventana modal que se muestra según la finalización de un evento, con un mensaje que explica el desenlace del mismo. En otras palabras, se utiliza para mostrar el resultado de una operación del sistema. Debajo del mensaje tiene un botón para continuar al siguiente paso del flujo. En la Figura 3.6 se puede observar este esquema. 55 Figura 3.6 Pantalla con ventana modal de mensajes  Mensaje en la parte superior: Consiste en mostrar un mensaje en la parte superior del formulario en una página. Se utiliza para mostrar mensajes de error de validaciones al completar un formulario, así como mensajes de error de validaciones de la lógica de negocio. En la Figura 3.7 se puede observar este esquema. Figura 3.7 Pantalla con mensaje en la parte superior 56 3.4 Diseño de Interfaz de carga de datos El sistema permitirá realizar la carga de la información de los abonados a partir de archivos XML. En esta funcionalidad de carga también se incluye el registro del detalle de los servicios a los que estén suscritos, de tal forma que se pueda calificar al cliente en base al costo del servicio y al número de meses de facturación que tenga de deuda. Esta calificación es utilizada en las funcionalidades de asignación que se implementaron usando algoritmos. El archivo XML se obtiene de la herramienta de exportación de datos del sistema ERP de la empresa objetivo, por lo tanto, las etiquetas (tags) del archivo ya están definidas. Un ejemplo de la estructura que se maneja se puede apreciar en la Figura 3.8. Figura 3.8 Estructura de datos 57 La etiqueta raíz del archivo es “Abonados”, lo que significa que el archivo contiene los datos de un conjunto de los mismos. Por cada abonado están definidos los campos con su información personal como código, nombres, apellidos, número de documento, dirección y teléfono. Asimismo, cada abonado puede tener varios servicios, los cuales se definen con una etiqueta “Servicios”. De forma similar, por cada servicio están definidos los campos código, paquete de televisión, costo, número de televisores y número de meses de deuda que tenga el cliente en el momento que se obtiene el archivo XML. Al realizar la carga de la información el sistema validará que si un abonado ya registrado se vuelve a cargar mediante el archivo XML, se actualicen los datos que tenga en la base de datos, porque no se puede tener dos registros del mismo y la carga más reciente es la que se debe tener en cuenta. Para ello se hará una búsqueda del código de abonado: si no existe, se procede a registrarlo; si existe, se procede a actualizar su información. 58 Capítulo 4 : Construcción y Pruebas En la primera parte de este capítulo se detalla cómo fue el proceso de construcción de la solución informática y se abarca la selección de tecnologías utilizadas para el desarrollo. En la segunda parte, se describen las pruebas realizadas para asegurar la calidad del software. 4.1 Construcción La etapa de construcción se realizó en iteraciones. Al fin de cada etapa se completó un avance parcial de la codificación del sistema, hasta llegar a la versión final. Durante la construcción del sistema se evaluó el uso de diferentes tecnologías y librerías que faciliten la implementación. Esto debido a que proveen mecanismos de calidad que son comúnmente aceptados por las diferentes comunidades de desarrollo de software. A continuación se describirán las actividades y decisiones más importantes de la etapa de construcción. 4.1.1 Selección y configuración inicial de herramientas En el comienzo del desarrollo, se estableció una plataforma, constituida por diferentes herramientas y tecnologías, sobre la cual funcionen las páginas web XHTML que tendría la aplicación.  Librería de componentes visuales La definición de estándares y estilos de los componentes visuales del sistema (como botones, combo-boxes, tablas, etc.) se apoyó en el uso de una librería para facilitar la tarea de la construcción de las páginas web. La librería de componentes de interfaz de usuario seleccionada fue Primefaces. La gran ventaja que ofrece es que sus componentes aportan una abstracción para el uso de la tecnología AJAX ya soportada en JSF 2 [21], con lo que es posible desarrollar 59 funcionalidades sin tener que preocuparse por el código Java Script que se ejecutará en el cliente. La elección de Primefaces permitió construir la parte de la aplicación que es visible al usuario (front-end) y, al mismo tiempo, implementar sencillamente funcionalidades basadas en AJAX.  Configuración de Hibernate En primer lugar se realizó la implementación de la base de datos a partir del modelo de datos definido en la etapa de análisis. Luego, se realizó la configuración de la tecnología de Hibernate para brindar el acceso a los datos almacenados. Para llevar a cabo dicha tarea, se utilizó la funcionalidad de ingeniería inversa que proporciona Hibernate, que consiste en crear clases Java y mapeos de XML a partir de las tablas y relaciones de una base de datos existente. Estas clases son conocidas como POJOs (Plain Old Java Object) con propiedades accesibles mediante métodos setter y getter. El acceso a la base de datos fue sencillo debido a que Hibernate es una herramienta eficiente: menos código para las consultas SQL y más funcionalidad con el manejo de los POJOs. 4.1.2 Construcción de la interfaz de carga La interfaz de carga usando archivos XML es una funcionalidad del módulo de mantenimiento que permite almacenar de forma masiva la información de los abonados del sistema ERP de la empresa en el nuevo sistema CRM. Para su construcción se utilizó una librería para el manejo de archivos XML; y se crearon índices en la base de datos para realizar validaciones en la tabla de abonados al momento de realizar la carga.  Librería de manejo de XML Se investigó librerías que permitan que la implementación del manejo del formato XML sea eficiente, con el fin de que el tiempo total del proceso de carga no sea largo. 60 La librería seleccionada fue XStream, la cual permite deserializar cadenas de texto en formato XML en objetos Java. La ventaja de esta librería es su facilidad de uso y que no requiere especificar mapeos de las clases con el formato que tengan el archivo. De esta forma, la creación de objetos de la clase abonados y sus correspondientes servicios a partir del archivo XML se realiza de forma sencilla y rápida.  Índices para la funcionalidad de carga masiva La funcionalidad de carga masiva de abonados tiene como requerimiento que si un cliente ya registrado se vuelve a cargar mediante el archivo XML, se actualicen los datos que ya tenía en la base de datos, porque no se puede tener dos registros del mismo y la carga más reciente es la que se debe tener en cuenta. Por lo anterior, se requiere realizar una búsqueda de cada cliente del archivo de carga en la tabla Abonado por código de abonado: si existe, se actualizan sus datos y si no, se registra. Asimismo se realizarán validaciones con las tablas con las guarda relación. En vista que la consulta será más lenta con el crecimiento de dichas tablas, y se realizarán consultas por cada registro del archivo, se crearon índices en las tablas de Cliente, Abonado y Servicio para disminuir el tiempo total de búsquedas. 4.1.3 Construcción de algoritmos Para cumplir los requerimientos de la asignación de los clientes a los vendedores y técnicos para los procesos de seguimiento de oportunidades de venta y atención de reclamos correspondientemente, se empleó algoritmos que dieran la solución a las necesidades del caso. En vista que la asignación de los clientes, para ambos casos, se puede considerar como un problema de asignación generalizado, esta etapa de la construcción del sistema comenzó con la definición del problema y luego se seleccionó al algoritmo GRASP para aplicarlo como solución.  Definición del problema El problema de asignación básico consiste en emparejar n tareas a n agentes. En la versión generalizada, un agente puede ser asignado a más de una tarea. Además, se 61 debe considerar que las tareas demandarán parte de la capacidad del agente [22]. Esto conduce al siguiente modelo en el contexto de la asignación de clientes: Maximizar: ∑∑ Con las restricciones: ∑ ∑ Donde si un agente es asignado a un cliente , 0 si no. es el beneficio de asignar el agente al cliente , y es la capacidad disponible del agente . La primera restricción asegura que cada cliente es asignado únicamente a un agente, y la segunda restricción asegura que un agente no exceda su capacidad. En la asignación de clientes, la capacidad de cada vendedor o técnico será el resultado de dividir el total de clientes seleccionados entre los trabajadores, ya que no se planea sobrecargar de tareas a un solo trabajador y se toma en cuenta que los clientes deben ser distribuidos equitativamente. El cálculo del beneficio de la asignación estará dado de las siguientes formas: o Asignación de clientes a vendedores El objetivo de la asignación de clientes a vendedores es realizar la venta de un paquete de televisión. Se tendrán en cuentan las variables de la Tabla 4.1. El valor del cliente depende del costo en soles de su servicio actual (el costo es cero si se trata de un prospecto) y la deuda está basada en el número de meses de morosidad acumulados. La experiencia del vendedor se define según el número de ventas que haya concretado. 62 Variable Valor Valor del cliente (v) Si COSTO > 70 → v = 50 Si 40 < COSTO <= 70 → v = 30 Si 0 < COSTO <= 40 → v = 20 Si COSTO = 0 → v = 10 Record de ventas del vendedor (r) Si VENTAS > 200 → r = 5 Si 100< VENTAS <= 200 → r = 3 Si 0<= VENTAS <= 100 → r = 1 Deuda del cliente (d) Si MESES = 0 → d = 1 Si MESES > 0→ d = MESES*10 Tabla 4.1 Variables de la asignación de clientes a vendedores Con las variables establecidas, el beneficio se define de acuerdo a la siguiente función: o Asignación de reclamos de clientes a técnicos El objetivo de la asignación de los reclamos a técnicos es asegurar que el problema del cliente sea resuelto en la primera visita técnica. Se tendrán en cuenta las variables de la Tabla 4.2. El valor del cliente se maneja similarmente a la asignación anterior, mientras que la experiencia del técnico se define según el número de averías reparadas y el número de agendas con observaciones (incumplimiento o inconformidad) que tenga. Variable Valor Valor del cliente (v) Si COSTO > 70 → v = 50 Si 40 < COSTO <= 70 → v = 30 Si 0 < COSTO <= 40 → v = 20 Experiencia del técnico(e) Si AVERÍAS > 200 → e = 5 Si 100< AVERÍAS <= 200 → e = 3 Si 0<= AVERÍAS <= 100 → e = 1 Agendas observadas del técnico (a) Si AGENDAS > 20 → e = 3 Si 10< AGENDAS <= 20 → e = 2 Si 0<= AGENDAS <= 10 → e = 1 Tabla 4.2 Variables de la asignación de reclamos a técnicos 63 Con las variables establecidas, el beneficio se define de acuerdo a la siguiente función: El valor de las variables puede cambiar en el tiempo según las necesidades del usuario final, por lo tanto, en el módulo de mantenimiento se implementó la funcionalidad de configuración de los parámetros del cálculo de beneficios para ambos casos.  Aplicación del algoritmo GRASP al problema Con el fin de resolver el problema planteado, se seleccionó al algoritmo GRASP fase construcción para aplicarlo como solución, pues es comúnmente usado para resolver problemas de optimización de combinaciones y asignación de tareas, demostrando buenos resultados computacionales en pruebas comparativas de rendimiento [23]. El pseudocódigo del algoritmo se presenta a continuación: Procedimiento GRASP (Cantidad_iteraciones, Semilla) Leer_datos(); Para k = 1,…, Cantidad_iteraciones hacer Solución = Construcción (Semilla); Actualizar_solución (Solución, Mejor_solución); Fin para Devolver Mejor_solución; Fin GRASP El número de iteraciones del procedimiento será configurable por el usuario. En cada iteración el algoritmo GRASP tiene dos fases: construcción y búsqueda local de soluciones. En el proyecto solo se consideró la fase de construcción. La función de construcción realiza el proceso de confección de una solución. En cada iteración que realice la función, se asigna un cliente a un agente. El proceso termina cuando todos los clientes han sido asignados. A continuación se presenta el pseudocódigo. 64 Función Construcción (Semilla) Para j = 1,…, Total_agentes Clientes_asignados(j) = Ø; Fin para RLC = Construir_lista(Lista_clientes, Lista_agentes); Mientras falte asignar clientes hacer Agente = Elegir_randomicamente (RLC, Cliente); Asignar (Clientes_asignados, Agente, Cliente); Si Verificar_capacidad_maxima (Agente) entonces Retirar (Agente, RLC); Fin si Fin mientras Devolver Clientes_asignados; Fin Construcción La construcción de la lista restringida de candidatos (RLC) consiste en un arreglo de agentes para cada cliente, de tal manera que }, donde es un parámetro que limita la dimensión de la lista restringida de tal forma que solo los agentes que cumplan con el beneficio mínimo sean considerados. Este parámetro es configurable dentro del sistema. Para el caso de la asignación de agendas de visita técnica se toma en cuenta principalmente la fecha y hora de la agenda, por lo que la lista restringida solo considera a los técnicos candidatos que no tengan una agenda pendiente en ese momento además del beneficio de la asignación. Si no hay técnicos disponibles para la agenda se enviará un mensaje de alerta. Es posible que en algún momento la lista restringida resulte ser vacía, lo que significa que ninguna de las asignaciones alcanzó el beneficio mínimo , en este caso se escogen a los primeros candidatos que tengan mejor beneficio de asignación. A partir del RLC se elige randómicamente a un agente para que sea asignado a un cliente. Esta asignación se agrega al arreglo de clientes por agente: cuando se asignan todos los clientes se llega a una solución. Si se alcanza la capacidad máxima del agente, este ya no es considerado como un candidato. 65 Finalmente se compara la solución obtenida con la mejor solución hasta el momento. Aquella solución que maximice la sumatoria de beneficio es elegida como la nueva mejor solución. 4.2 Pruebas En este apartado se describen las diferentes pruebas a realizar para comprobar el correcto funcionamiento del sistema de información desarrollado, asegurando que el producto final cumpla los requerimientos identificados en la etapa de análisis. La realización de las pruebas del sistema es importante porque previene que salten errores al momento de utilizarlo, ocasionado generalmente por defectos no corregidos en el software. De esta forma, se evitan también correcciones futuras que comúnmente involucran costos proporcionales al avance en los proyectos de desarrollo de software. 4.2.1 Plan de pruebas El alcance de la etapa de pruebas del proyecto fue la definición y ejecución de un conjunto de pruebas unitarias que aseguren el funcionamiento del sistema y el cumplimiento de los requisitos establecidos. En cada iteración del proyecto, las incidencias encontradas durante la ejecución de las pruebas se registraron y se realizó un levantamiento de los errores en el código fuente. Luego, se volvió a ejecutar las pruebas con la versión corregida. Este proceso se repitió hasta conseguir la ejecución correcta de las pruebas del catálogo para la correspondiente iteración. Respecto a la especificación de los casos de prueba, estos deben cumplir las siguientes condiciones: 1. Dejar claro el propósito de la prueba. 2. Especificar los pasos de ejecución de la prueba. 3. Definir el resultado que se espera. 66 4.2.2 Diseño de casos de prueba Para el diseño de las pruebas se empleó el enfoque de caja negra, que consiste en estudiar la especificación de la entrada y salida de los flujos del sistema. Luego, se seleccionó el criterio de particiones de equivalencia, el cual se realiza en dos pasos. En primer lugar, se identifican las clases de equivalencia. Esto consiste en definir un conjunto de estados válidos y no válidos para las condiciones de entrada de un programa. Por último, se identifican los casos de prueba. Se asigna un número único a cada clase de equivalencia y se definen los casos de prueba de modo que cubran todas las clases válidas e inválidas. 4.2.3 Catálogo de pruebas A continuación se muestran las clases de equivalencia y los casos de prueba para las principales funciones del sistema. En el ANEXO H se incluye el resto del catálogo. 4.2.3.1 Clases de equivalencia  Módulo de Ventas o Asignación de clientes Condición de entrada Clases válidas Clases no válidas Cantidad de clientes seleccionados Cant. de clientes seleccionados > 0 A Cant. de clientes seleccionados = 0 B Cantidad de vendedores seleccionados Cant. de vendedores seleccionados > 0 C Cant. de vendedores seleccionados = 0 D Tabla 4.3 Clases de equivalencia: Asignación de clientes o Programación de actividad Condición de entrada Clases válidas Clases no válidas Tipo de actividad Tipo <> “Seleccione” A Tipo = “Seleccione” B Descripción 1 <= Cant. Caracteres <= 100 C Cant. Caracteres < 1 o Cant. Caracteres > 100 D Vacío E Prioridad Prioridad <> “Seleccione” F Prioridad = “Seleccione” G Fecha Tipo = Fecha H Tipo <> Fecha I Vacío J Tabla 4.4 Clases de equivalencia: Programación de actividad 67  Módulo de Atención al Cliente o Agendar visita técnica Condición de entrada Clases válidas Clases no válidas Fecha Cant. Agendas < Cant. Agendas máxima A Vacío C Cant. Agendas >= Cant. Agendas máxima B Hora Tipo = Hora D Tipo <> Hora E Vacío F Observación 1 <= Cant. Caracteres <= 100 G Cant. Caracteres < 1 o Cant. Caracteres > 100 I Vacío H Tabla 4.5 Clases de equivalencia: Agendar visita técnica o Asignación de agendas Condición de entrada Clases válidas Clases no válidas Cantidad de agendas seleccionadas Cant. de agendas seleccionadas > 0 A Cant. de agendas seleccionadas = 0 B Cantidad de técnicos seleccionados Cant. de técnicos seleccionados > 0 C Cant. de técnicos seleccionados = 0 D Tabla 4.6 Clases de equivalencia: Asignación de agendas 4.2.3.2 Casos de prueba  Módulo de Ventas o Asignación de clientes Clases Valores Secuencia de pasos Resultado esperado Ejecución AC 100 clientes seleccionados, 10 vendedores seleccionados 1. Se ingresa a “Comercialización”. 2. Se selecciona una lista de clientes activa. 3. Se selecciona el botón Asignar. 4. Se seleccionan 100 clientes de la lista. 5. Se seleccionan 10 vendedores. 6. Se pulsa “Asignar auto.”. Se muestra el mensaje: “(100) Clientes asignados a (10) vendedores”. Se muestra el mensaje de éxito esperado. AD 100 clientes seleccionados, no se seleccionan vendedores 1. Se ingresa a “Comercialización”. 2. Se selecciona una lista de clientes activa. 3. Se selecciona el botón Asignar. 4. Seleccionar 100 clientes y pulsar “Asignar auto.”. Se muestran el mensaje: “Debe seleccionar al menos un vendedor”. Se muestra el mensaje de error esperado. Tabla 4.7 Caso de prueba: Asignación de clientes 68 o Programación de actividad Clases Valores Secuencia de pasos Resultado esperado Ejecución ACFH Encuentro, Visita para venta de paquete y cobro de instalación, Importante, 02/05/2013 2 pm 1. Se ingresa a la opción “Negociación”. 2. Se selecciona un cliente de la lista. 3. Se pulsa el botón Programar actividad. 4. Se ingresa los valores determinados. 5. Se pulsa el botón Registrar. Se muestra el mensaje: “Actividad registrada con éxito”. La actividad debe aparecer con fecha y hora: 02/05/2013 2pm. Se muestra el mensaje de éxito esperado. BEGJ Seleccione, vacío, Seleccione, vacío 1. Se ingresa a la opción “Paquetes de TV”. 2. Se ingresa los valores determinados. 3. Se pulsa el botón Registrar. Se muestran los mensajes: “Tipo de actividad es campo obligatorio”, “Descripción es campo obligatorio”, “Prioridad es campo obligatorio”, “Fecha es campo obligatorio”. Se muestra el mensaje de error esperado. Tabla 4.8 Caso de prueba: Programación de actividad  Módulo de Atención al Cliente o Agendar visita técnica Clases Valores Secuencia de pasos Resultado esperado Ejecución ADG 12/05/2013 (cantidad de agendas < máximo), 3 pm, Cliente indicó que deben llamar a su teléfono primero 1. Se ingresa a la opción “Reclamo”. 2. Se selecciona un reclamo pendiente de la lista. 3. Se pulsa el botón Agendar. 4. Se selecciona la fecha 12/05/2013 del calendario. 5. Se ingresa los valores determinados. 6. Se pulsa el botón Registrar. Se muestra el mensaje: “Agenda registrada con éxito”. La agenda debe aparecer en el calendario en la fecha 12/05/2013. Se muestra el mensaje de éxito esperado. BDG 12/05/2013 (cantidad de agendas > máximo), 3 pm, Cliente indicó que deben llamar a su teléfono primero 1. Se ingresa a la opción “Reclamo”. 2. Se selecciona un reclamo pendiente de la lista. 3. Se pulsa el botón Agendar. 4. Se selecciona la fecha 12/05/2013 del calendario. 5. Se pulsa el botón Aceptar del mensaje de alerta. 6. Se ingresa los valores determinados. 7. Se pulsa el botón Registrar. El sistema debe mostrar una alerta al seleccionar la fecha: “La fecha alcanzó la cantidad máxima de agendas. ¿Desea continuar?”. Luego, se muestra el mensaje: “Agenda registrada con éxito”. La agenda debe aparecer en el calendario en la fecha 12/05/2013 la cual tendrá un ícono rojo indicando que se alcanzó el límite de agendas. Se muestra el mensaje de éxito esperado. Tabla 4.9 Caso de prueba: Agendar visita técnica 1 69 Clases Valores Secuencia de pasos Resultado esperado Ejecución AFH 12/05/2013 (cantidad de agendas < máximo), vacío, vacío 1. Se ingresa a la opción “Reclamo”. 2. Se selecciona un reclamo pendiente de la lista. 3. Se pulsa el botón Agendar. 4. Se selecciona la fecha 12/05/2013 del calendario. 5. Se ingresa los valores determinados. 6. Se pulsa el botón Registrar. Se muestra el mensaje: “Hora es campo obligatorio”. Se muestra el mensaje de error esperado. Tabla 4.10 Caso de prueba: Agendar visita técnica 2 o Asignación de agendas Clases Valores Secuencia de pasos Resultado esperado Ejecución AC 20 agendas seleccionadas, 4 técnicos seleccionados 1. Se ingresa a la opción “Bandeja de pendientes”. 2. Se seleccionan 20 agendas de la lista. 3. Se seleccionan 4 técnicos. 4. Se pulsa el botón Asignar automáticamente. Se muestra el mensaje: “(20) Agendas asignadas a (4) técnicos”. Se muestra el mensaje de éxito esperado. AD 20 agendas seleccionadas, no se seleccionan técnicos 1. Se ingresa a la opción “Bandeja de pendientes”. 2. Se seleccionan 20 agendas de la lista 3. Se pulsa el botón Asignar automáticamente. Se muestran el mensaje: “Debe seleccionar al menos un técnico”. Se muestra el mensaje de error esperado. Tabla 4.11 Caso de prueba: Asignación de agendas 70 Capítulo 5 : Observaciones, Conclusiones y Recomendaciones En este capítulo final, se relatarán las observaciones y conclusiones del trabajo realizado. Por último, se incluyen recomendaciones para trabajos futuros que se conciban a partir del presente proyecto. 5.1 Observaciones A continuación se presentan algunas observaciones respecto al proyecto realizado.  En el presente proyecto de fin de carrera se desarrolló un sistema de información que dé soporte a los principales procesos de interacción con el cliente de las áreas de Ventas y Atención del Cliente; siendo las necesidades principales: distribuir a los clientes entre los vendedores para efectuar el seguimiento de oportunidades de venta, la asignación de reclamos a los técnicos y el mantenimiento del historial de actividades efectuadas con los clientes.  Durante el proceso de levantamiento de información y desarrollo de la solución se contó con el apoyo de una empresa de televisión de pago en Lima. Afortunadamente se contó con amplia disponibilidad de los trabajadores y personas involucradas en los momentos requeridos. De esta forma la toma de datos fue lo más precisa posible y también sirvió para darle credibilidad al proyecto.  La lista de requerimientos y los casos de uso fueron realizados según las entrevistas llevadas a cabo al personal de la empresa. Se contó también con las validaciones de los interesados clave del proyecto. La alta comunicación con los interesados, ya fuera de forma presencial o por teléfono, permitió gestionar los cambios solicitados sin mayor inconveniente.  Se contó con un gran apoyo de parte del asesor, quien revisó y validó continuamente los avances del documento y el producto realizados. Las observaciones y correcciones indicadas fueron clave para que los entregables 71 sean aprobados por los profesores coordinadores de los cursos y el proyecto se oriente a los marcos a los que fue evaluado.  En la selección de tecnologías y frameworks para implementar el sistema se tomó en cuenta la cantidad de documentación existente de las mismas para aprovechar las ventajas que pueden ofrecer y superar los obstáculos que se presentaran en el desarrollo. 5.2 Conclusiones Las conclusiones obtenidas al finalizar el proyecto son las siguientes:  El escenario de negocios de la televisión de pago se encuentra en constante cambio, con clientes cada vez mejor informados y con la aparición de nuevos competidores. Una empresa que desea ser competitiva debe replantear su estrategia de negocios para centrar su visión en los clientes. Con el apoyo de un sistema CRM, la empresa puede gestionar eficazmente a sus clientes y ofrecer un mejor servicio. Sin embargo, para asegurar el éxito del proyecto, los participantes e interesados deben entender el propósito de la implementación de este producto y los beneficios que genera, como ahorro de tiempo y recursos.  La herramienta CRM desarrollada brinda la posibilidad de identificar las variaciones del valor real y potencial de los clientes de la empresa. En el área de Ventas, el sistema identifica el valor real de los clientes según su paquete de televisión y sus meses de deuda. Luego, el vendedor asignado puede determinar su valor potencial con el historial de negociaciones que la herramienta mantiene, permitiendo explotar las oportunidades de negocio que se puedan dar. En el área de Atención al cliente, el sistema permite gestionar los reclamos técnicos eficazmente, otorgando preferencia a los clientes de alto valor para la empresa. Los clientes que son bien atendidos cuando tienen problemas con su servicio de televisión desarrollarán una alta lealtad hacia la empresa.  Se logró desarrollar un algoritmo, basado en GRASP fase construcción, para la asignación de clientes a vendedores y técnicos en los distintos procesos de 72 negocio, permitiendo que los jefes de área puedan llevar a cabo la tarea de asignación de forma más rápida, aprovechando al mismo tiempo la información que el sistema registra tanto del cliente como del vendedor o técnico. Esta suma de beneficios demuestra que es factible utilizar las técnicas básicas de la rama de Inteligencia Artificial en la aplicación de un problema real.  Se desarrollaron distintos tipos de reporte para obtener información importante para la empresa a partir de los datos que almacena el sistema cuando los usuarios registran actividades de ventas y atención de reclamos. Los reportes permiten a los jefes de área conocer si se cumplen las metas propuestas de las campañas de comercialización que se vienen trabajando, así como medir los tiempos y el nivel de atención al cliente. De este modo la herramienta brinda un respaldo y apoyo constante a la toma de decisiones. 5.3 Recomendaciones En esta última sección se listan las recomendaciones para futuros proyectos que tomen el presente trabajo como base.  Para el desarrollo de un sistema CRM para una empresa y modelo de negocio específico, el compromiso de la gerencia es de vital importancia, debido a que se trata de una iniciativa estratégica que se refleja en la revisión y renovación de los procesos de negocio para obtener una visión centrada en el cliente. Se recomienda la promoción del proyecto desde los niveles más altos de la empresa.  Analizar la posibilidad de implementar un módulo adicional que dé soporte a los procesos del área de Marketing. Luego, la herramienta CRM puede permitir que se comparta la información entre todas las áreas de interacción con el cliente, de forma que se obtenga una perspectiva más completa del mismo y sus necesidades. De este modo se fomenta la integración de información en la empresa y se beneficia la gestión de los clientes en general.  Por último, se sugiere experimentar los beneficios que podría traer la implementación de la fase de búsqueda local al algoritmo GRASP utilizado para la asignación de clientes. Esto permitirá encontrar mejores soluciones al 73 problema de la asignación de clientes, pero se debe tener en consideración que el tiempo total de procesamiento no debe ser muy largo, pues el objetivo principal es ofrecer soporte eficientemente a los procesos de negocio. 74 Referencias bibliográficas [1] MINISTERIO DE TRANSPORTES Y TELECOMUNICACIONES 2011 Estadísticas de Servicios Públicos de Telecomunicaciones a nivel nacional - Información a Setiembre 2011. Consulta: 12 de setiembre de 2012. [2] MINISTERIO DE TRANSPORTES Y TELECOMUNICACIONES 2012 Información Estadística detallada de los Servicios Públicos de Telecomunicaciones II - T 2012. Consulta: 12 de setiembre de 2012. [3] BASOMBRÍO ZENDER, Ignacio 2010 Telecomunicaciones: Tendencias, servicios y derechos de los usuarios. Consulta: 12 de setiembre de 2012 [4] KHALID Rababah; HASLINA, Mohd; HUDA, Ibrahim 2011 “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, Vol. 1, No. 1, Abril 2011. [5] VOGT, Henrik 2009 Open Source Customer Relationship Management Solutions: Potential for an Impact of Open Source CRM Solutions on Small-and Medium Sized Enterprises. Hamburgo: Diplomica. [6] KOSTOJOHN, Scott; PAULEN, Brian; JOHNSON, Mathew 2011 CRM fundamentals. Nueva York: Apress [7] VIDALDI DÍEZ, Ignasi 75 2004 Cómo conquistar el mercado con una estrategia CRM. Madrid: Fundación Confemetal. [8] TELEMANAGEMENT FORUM 2012 Business Process Framework (eTOM) Overview. Consulta: 12 de setiembre de 2012. [9] TELEMANAGEMENT FORUM 2011 Business Process Framework (eTOM) Release 9. Nueva Jersey. [10] JIEJIN, Hou 2009 A Practical Approach to the Operation of Telecommunication Services driven by the TMF eTOM Framework. Tesis para el grado de Maestría. Cataluña: Universidad Politécnica de Cataluña, Departamento de Teoría de Señales y Comunicaciones. [11]GOLDENBERG, Barton J. 2008 CRM in Real Time. New Jersey: Information Today Inc. [12] ORACLE CORPORATION 2012 Aplicaciones Siebel Customer Relationship Management (CRM).Consulta: 20 de setiembre de 2012. [13] INFUSIONSOFT, INC. 2012 InfusionSoftFeatures. Consulta: 20 de setiembre de 2012. [14] SUGARCRM 2012 Sugar Professional CRM. Consulta: 20 de setiembre de 2012. [15] SAGE ESPAÑA 2012 Sage CRM. Consulta: 01 de noviembre de 2012. 76 [16] BAUMEISTER, Hubert 2002 “Customer Relationship Management for SMEs”. Múnich: Ludwig Maximillians Universit, Departamento de Programación e Ingeniería de Software. [17] PROJECT MANAGEMENT INSTITUTE, INC. 2008 Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). 4ta Edición. Pennsylvania. [18] OBJECT MANAGEMENT GROUP, INC. 2011 Business Process Model and Notation (BPMN) Version 2.0. Consulta: 15 de enero de 2013. [19]POLLICE, Gary; AUGUSTINE Liz; LOWE Chris 2004 Software development for small teams: a RUP-centric approach. Boston: Pearson Education, Inc. [20]ORACLE CORPORATION 2013 Java Platform, Enterprise Edition 6. Consulta: 18 de marzo de 2013. [21] PRIMEFACES 2013 Primefaces Documentation. Consulta: 20 de marzo de 2013. [22] PENTICO, David W. 2005 “Assignment problems: A Golden anniversary survey”. European Journal of Operational Research.Vol. 176.Año 2007. [23] RAMALHINHO, Helena; SERRA Daniel 2002 “Adaptative Search Heuristics for the Generalized Assignment Problem”. Barcelona: Universitat Pompeu Fabra.