CRM Inteligente :: Documentación

Capítulo 5
Diseño

En esta fase se explicarán cómo se llevarán a cabo lo definido en la fase de análisis. De esta forma se detallarán las distintas decisiones que hemos tomado para el desarrollo del sistema. Además se incluyen los casos de uso extraídos a partir de la toma de requerimientos.

5.1. Arquitectura

El sistema esta compuesto por 4 grandes componentes:

Base de datos. almacena toda la información sobre los clientes y su interacción con el sistema. En un CRM es de vital importancia recoger la información de usuario acerca de cuando interactúa y de que modo.
Análisis de resultados. Este módulo se encarga de examinar las acciones de los clientes y obtener tendencias, generar árboles de decisión, etc.
Capa de presentación. Se encarga de mostrar una interfaz al usuario.
Lógica de negocio. Se encarga de controlar las operaciones y funcionamiento de la aplicación.

5.2. Casos de uso

Son una forma de especificar los requisitos de un sistema. Tienen como misión describir la interacción entre un usuario ajeno al sistema y el sistema con texto en lenguaje natural. Los casos de uso representan los requisitos funcionales desde el punto de vista del usuario y cada uno de ellos realiza una funcionalidad concreta (iniciar sesión, registrar incidencia, ...). Para ello será necesario identificar cuales son los usuarios que interaccionan con el sistema y cuáles son sus operaciones dentro de él.

Objetivos de los casos de uso

Los objetivos de los casos de uso son:

Comprender qué es lo que debe realizar el sistema
Discutir con el usuario nuestra visión de esa funcionalidad
Identificar conceptos del sistema, clases, atributos y operaciones
Validar el análisis y el diseño del modelo
Proporcionar información para las pruebas de validación y aceptación del sistema

Elementos que intervienen

Existen dos tipos de elementos que intervienen en los casos de uso:

Actores:: Son todas aquellas personas que tienen un rol en la interacción con el sistema. Todos los actores pueden desempeñar varios roles y un rol puede ser desempeñado por varios actores. Un usuario adopta la función de un actor cuando éste interactúa con el sistema.
Caso de uso:: Es la interacción que se quiere simular.

5.2.1. UC - 1. Iniciar sesión

Caso de uso 1	Iniciar sesión
Objetivos	Identificar y validar a un cliente en el sistema
Actores	Usuario, Sistema
Entradas	Identificador de usuario, contraseña
Condiciones previas	La aplicación debe estar activa, no debe haber sesión iniciada
Salidas	Mensaje informativo de inicio correcto o fallido
Post-condición si éxito	Sesión iniciada, mostrar la pantalla de bienvenida
Post-condición si fallo	No se inicia sesión, y se muestra un mensaje de error por pantalla
Activador	Botón ”Iniciar Sesión” en la pantalla de inicio de la aplicación
Secuencia	Introducir los datos, pulsar el activador
Excepciones	Los datos no son validados correctamente
Frecuencia de uso	Siempre. Previamente a cualquier acción en el sistema es preciso haber iniciado la sesión.
Asuntos pendientes

5.2.2. UC - 2. Registrar un nuevo cliente

Caso de uso 2	Registrar un nuevo cliente
Objetivos	Dar de alta en la aplicación a un nuevo cliente e incorporar sus datos al sistema
Actores	Usuario, sistema
Entradas	Datos personales de usuario
Condiciones previas	Estar en la pantalla de registro de nuevos clientes
Salidas	Confirmación de registro correcto o excepciones E1, E2
Post-condición si éxito	El usuario queda registrado como cliente en el sistema
Post-condición si fallo	El usuario queda registrado como cliente en el sistema
Activador	Botón ”Registrar usuario” en la pantalla de registro
Secuencia	Introducir los datos de usuario, pulsar el botón activador
Excepciones	E1: Ya hay un cliente registrado con el mismo identificador E2: Faltan datos obligatorios o son incorrectos (formato, etc)
Frecuencia de uso	Baja. Una vez por cliente.
Asuntos pendientes

5.2.3. UC - 3. Crear una nueva incidencia

UC - 3.1 Crear una nueva avería

Caso de uso 3.1	Crear una nueva avería
Objetivos	Registrar los datos correspondientes a una avería
Actores	Usuario, sistema.
Entradas	Descripción de la avería, tipo de avería, fecha, urgencia, efectos y repercusión de la avería
Condiciones previas	Que se haya detectado una avería
Salidas	Notificación de operación correctamente finalizada, Identificador de avería, Acciones a tomar
Post-condición si éxito	Registro correcto de la avería; Notificación a los técnicos (si procede) u otras acciones para resolver el problema; Notificación de confirmación al cliente
Post-condición si fallo	Mensaje informativo explicando el motivo del fallo
Activador	Botón ”Introducir Avería”
Secuencia	Rellenar los datos de la avería y pulsar el activador Si error, E1
Excepciones	E1: No haber rellenado todos los campos obligatorios
Frecuencia de uso	Alta. Cada vez que se detecta una avería
Asuntos pendientes

UC - 3.2 Crear una nueva reclamación

Caso de uso 3.2	Crear una nueva reclamación
Objetivos	Registrar los datos correspondientes a una reclamación
Actores	Usuario, sistema.
Entradas	Descripción de la reclamación, tipo de reclamación, fecha, causas de la reclamación
Condiciones previas	Cliente descontento
Salidas	Notificación de operación correctamente finalizada, Identificador de reclamación, Acciones a tomar
Post-condición si éxito	Registro correcto de la avería Notificación a los técnicos (si procede) u otras acciones para resolver el problema Notificación de confirmación al cliente
Post-condición si fallo	Mensaje informativo explicando el motivo de la reclamación
Activador	Botón ”Introducir Reclamación”
Secuencia	Rellenar los datos de la reclamación y pulsar el activador Si error, E1
Excepciones	E1: No haber rellenado todos los campos obligatorios
Frecuencia de uso	Alta. Cada vez que se enuncia una reclamación
Asuntos pendientes

UC - 3.3 Crear una nueva consulta

Caso de uso 3.3	Crear una nueva consulta
Objetivos	Obtener información
Actores	Usuario, sistema.
Entradas	Descripción de la consulta, tipo de consulta, fecha
Condiciones previas	Sesión iniciada. Cliente pide información.
Salidas	Respuesta a la información que se pide, si se conoce, o un aviso de que la consulta va a ser enviada a un experto
Post-condición si éxito	Registro correcto de la consulta Si se conoce la respuesta: notificación de la respuesta a la consulta Si no: notificar a un experto para que encuentre y envíe al cliente una respuesta a la consulta
Post-condición si fallo	Mostrar el mensaje de error informando del fallo
Activador	Botón ”Consultar”
Secuencia	Rellenar los datos de la reclamación y pulsar el activador Si error, E1
Excepciones
Frecuencia de uso	Alta. Cada vez que se enuncia una reclamación
Asuntos pendientes

5.2.4. UC - 4. Consultar una incidencia

UC - 4.1 Consultar una avería

Caso de uso 4.1	Consultar una avería
Objetivos	Obtener información de una avería existente
Actores	Usuario, Sistema
Entradas	Identificador de la avería
Condiciones previas	Que el usuario haya iniciado sesión, que la avería exista
Salidas	Se muestran los datos de la avería solicitada y su estado actual Acciones a tomar
Post-condición si éxito	Se guarda la actividad del cliente en el histórico del cliente
Post-condición si fallo	Se muestra un mensaje de error indicando el motivo del fallo
Activador	Botón ”Consultar” en la pantalla de averías
Secuencia	Introducir el identificador del cliente. Pulsar el activador. Si fallo E1
Excepciones	E1 que el identificador no sea válido
Frecuencia de uso	Alta
Asuntos pendientes

UC - 4.2 Consultar una reclamación

Caso de uso 4.2	Consultar una reclamación
Objetivos	Obtener información de una reclamación existente
Actores	Usuario, Sistema
Entradas	Identificador de la reclamación
Condiciones previas	Que el usuario haya iniciado sesión, que la reclamación exista
Salidas	Se muestran los datos de la reclamación solicitada y su estado actual Acciones a tomar
Post-condición si éxito	Se guarda la actividad del cliente en el histórico del cliente
Post-condición si fallo	Se muestra un mensaje de error indicando el motivo del fallo
Activador	Botón ”Consultar” en la pantalla de reclamaciones
Secuencia	Introducir el identificador del cliente. Pulsar el activador. Si fallo E1
Excepciones	E1 que el identificador no sea válido
Frecuencia de uso	Alta
Asuntos pendientes

UC - 4.3 Recuperar una consulta

Caso de uso 4.3	Recuperar una consulta
Objetivos	Obtener información de una consulta existente
Actores	Usuario, Sistema
Entradas	Identificador de la consulta
Condiciones previas	Que el usuario haya iniciado sesión, que la consulta exista
Salidas	Se muestran los datos de la consulta solicitada y su estado actual Respuesta a la consulta si se ha encontrado
Post-condición si éxito	Se guarda la actividad del cliente en el histórico del cliente
Post-condición si fallo	Se muestra un mensaje de error indicando el motivo del fallo
Activador	Botón ”Recuperar” en la pantalla de consultas
Secuencia	Introducir el identificador del cliente. Pulsar el activador. Si fallo E1
Excepciones	E1 que el identificador no sea válido
Frecuencia de uso	Alta
Asuntos pendientes

5.2.5. UC - 5 Proponer acciones

Caso de uso 5	Proponer acciones
Objetivos	Obtener una o varias acciones aplicables al contexto de la incidencia
Actores	Sistema
Entradas	Identificador del cliente, identificador de la incidencia
Condiciones previas	Que el usuario haya iniciado sesión, que la incidencia exista
Salidas	Se muestran las acciones adecuadas a la incidencia correspondiente
Post-condición si éxito
Post-condición si fallo	Se muestra un mensaje de error indicando el motivo del fallo
Activador	Automático
Secuencia
Excepciones
Frecuencia de uso	Muy Alta. Cada vez que se crea una incidencia
Asuntos pendientes

5.2.6. UC - 6 Cerrar sesión

Caso de uso 6	Cerrar sesión
Objetivos	Finalizar la sesión del cliente
Actores	Usuario, Sistema
Entradas
Condiciones previas	Que el usuario haya iniciado sesión
Salidas	Se muestra un mensaje informativo notificando la desconexión del sistema
Post-condición si éxito	Sesión cerrada
Post-condición si fallo	No se cierra la sesión
Activador	Botón ”Cerrar sesión”
Secuencia	Pulsar el activador.
Excepciones
Frecuencia de uso	Siempre
Asuntos pendientes

5.3. Diseño de la base de datos

Una vez realizado el análisis y establecido los requisitos, es necesario decidir diseñar la solución al problema. En el diseño de la base de datos se utilizó un diagrama entidad - relación. Como suele ser habitual en este tipo de diagramas cada tabla se representa junto con los atributos que la componen. Además se especifica el tipo de cada atributo. Junto a cada atributo se muestran unos pequeños iconos

que aportan información sobre cada atributo. Tienen el siguiente significado:

: Indica que el atributo forma parte de la clave primaria.
: Indica que el atributo forma parte de una clave ajena.
: Icono por defecto.

Cada tabla según el modelo entidad - relación puede estar relacionada con una o varias tablas del modelo. La nomenclatura utilizada para las relaciones es la siguiente:

: Relación uno a uno
: Relación uno a muchos

Además para clarificar la lectura del diagrama se agrupan las tablas en regiones.

Figura 5.1:

Diagrama entidad - relación

Dependiendo de su funcionalidad cada una de las tablas pertenecen a un grupo de los siguientes:

Datos descriptivos (Perfil del cliente):: Los datos descriptivos proporcionan información sobre el cliente. Dentro de este grupo distinguiremos 2 tipos de datos: los datos estáticos y los datos dinámicos. Los datos estáticos corresponden a aquellos datos que no cambian o lo hacen muy poco. Deben actualizarse periódicamente en plazos no menores a un año aunque existen excepciones como cuando un cliente cambia de domicilio. Los datos dinámicos de un cliente son aquellos que son más propensos a cambios. Un cliente puede adoptar varios perfiles dentro de la empresa durante su vida y existen factores que determinan su perfil. Estos factores pueden ser: deudas establecidas con la empresa, beneficios aportados, gastos, …
Datos promocionales (Acciones al cliente):: Cuando se produce una incidencia la empresa proporciona en el menor tiempo posible una solución al cliente. Esa solución se denomina ’acción’ y para cada incidencia y cada producto se guardarán todas las acciones propuestas en la tabla ’HistóricoAcciones’. Todas las acciones se almacenarán en la tabla ’Acciones’ y en el caso de que se proporcione un nuevo tipo de acción se guardará en la tabla ’Acciones’.
Datos transaccionales (Reacciones del cliente):: Dependiendo del grado de aceptación por parte del cliente a la acción propuesta por la empresa ante una incidencia, se generará una reacción (en algunos casos no se produce ninguna). Esta reacción se guardará en la tabla ’HistóricoReacciones.’ Si el tipo de reacción no se ha producido nunca se creará una nueva entrada en la tabla ’Reacciones’
Inteligencia:: Esta es la parte más compleja del diseño. A través de estas tablas se quiere proporcionar al sistema de inteligencia. El módulo de inteligencia está compuesto de reglas que mediante unos procesos estadísticos determinan cúales son las acciones que deben realizarse ante una determinada incidencia. Los factores que intervienen para determinar que acción se va a tomar en los procesos estadísticos son muy diversos, pero se basa en que reacciones se han obtenido a las diversas acciones que se han planteado ante incidencias del mismo tipo.
Datos usuarios:: Almacena los datos de los usuarios (trabajadores) y sus roles. Esta información no será procesada por las herramientas de Data Mining. Su tamaño dependerá del número de trabajadores de la empresa. Además de almacenar datos personales, también almacena el rol de cada usuario, de tal forma que cada rol tiene asociados unos privilegios. De esta forma como suele ser habitual cada trabajador, dependiendo de su rango podrá ver más o menos datos o incluso algunos datos podrán dejar de ser interesantes para determinados tipos de usuarios por lo que no se mostrarían a los usuarios con ese rol.
Incidencias:: En esta parte del diseño aparentemente simple reside la tabla de incidencias que se interconecta a través de claves ajenas con los módulos de inteligencia, datos promocionales, datos transaccionales, y datos del cliente. Cada vez que haya una nueva incidencia se almacenará en este módulo. Además para el análisis y clasificación de los datos este módulo junto con algún otro resultara fundamental ya que permite averiguar qué acción acciones llevaron al cliente a reaccionar.
Productos:: En este módulo se distinguen 2 tablas. Ambas almacenan información de productos, los productos y servicios con los que comercializa la empresa. La razón de que haya 2 tablas es para separar la información, meramente descriptiva del producto, esto es, sus características, desde el punto de vista del cliente. Dependiendo de los productos y servicios que venda la empresa dicha tabla podría ser necesario ampliarla o duplicarla de tal manera que una tabla almacena productos o servicios de un tipo y otros productos o servicios de otro tipo. En cambio la tabla Productos almacena información estadística de primera mano relevante y alguna característica necesaria para inferir comportamientos en torno a ese producto.

5.4. Diseño conjunto del sistema

El sistema dispondrá de varios módulos para alcanzar su objetivo:

Módulo de inteligencia / Estadístico / Inferencia
Base de datos
Interfaz con el usuario

El módulo de inteligencia recopilará la información de la base de datos, en general del DW y otros almacenes de datos dinámicos para elaborar los árboles de decisión necesarios para el proceso productivo y toma de decisiones.

Este proceso se realizará “offline” dada la gran cantidad de datos almacenados. En producción el flujo de datos será el siguiente:

El usuario necesita una acción para proponer al cliente.
El sistema puede acceder a los datos del cliente tras su identificación
Además el sistema podría solicitar datos referentes al estado actual del cliente.
Con toda esa información disponible y haciendo uso de los árboles y estructuras generadas por el módulo de inteligencia es capaz de recuperar la acción o conjunto de ellas más apropiada para el cliente, asegurando que el cliente no se marcha.

Figura 5.2:

Interrelación de los módulos del sistema