Acceso Acerca de

CRM Inteligente :: Documentación

Apéndice B
Listado de las actas de las reuniones

Durante el desarrollo del proyecto tal como se explico en el apartado de metodología de desarrollo hicimos reuniones periódicas. El seguimiento de dichas reuniones se encuentra en este listado de actas.

B.1. Acta 1 (24/10/2007)

El proyecto trata de documentar diseñar e implementar un Sistema de Atención al Cliente o CRM que tiene como objetivo guardar y gestionar toda la información posible acerca de los productos, los clientes, ventas, etc así como las relaciones que puedan existir entre ellos. Existen elementos fundamentales tales como:

Nuestro sistema tendrá información acerca de los productos concretos tal como: nombre, garantía, modelo, además será necesario identificar cada producto de forma unívoca a través del S/N (Serial Number).

Como es natural, pueden existir varios modelos para un mismo producto. Por ello será necesario poder recabar información de cada modelo, como puede ser la versión o el año de creación.

Para los clientes el sistema ha de manejar sus datos personales: nombre, apellidos, fecha de nacimiento,… así como atributo adicional para identificarlo y distinguirlo del resto de clientes.

El sistema recogerá información acerca de las acciones de los clientes.

En la operación compra se relaciona un producto con el cliente que lo adquirió. Almacenando algún dato identificativo del cliente así como un identificador para compra, siendo así posible recuperar posteriormente esta información para cualquier otro fin. Además cada compra tendrá el importe y la fecha en la que fue hecha.

El aprendizaje del sistema es importante para determinar de qué forma suele actuar cada cliente. Esto nos permite averiguar cuáles son sus preferencias y en general patrones de comportamiento. Los datos se extraerán bien de la forma de actuar de cada cliente o mediante cuestionarios. A partir de estos datos podemos crear perfiles de clientes que actúen de la misma forma.

El sistema registrará cada incidencia que el cliente plantee. Cada incidencia recogerá datos como modelo afectado, cliente, así como alguna información extra relacionada con la forma de proceder o solventar. Además se extraerán datos relevantes relacionados con el funcionamiento de cada producto y sobre el uso que cada usuario hace. Dependiendo del tipo de incidencia puede llevarse a cabo distintas alternativas para la solución de la misma como por ejemplo sustituir el producto por otro de características similares. Incluso dependiendo del tipo de cliente (por ejemplo un VIP) que tiene la incidencia se puede actuar de distinta forma como por ejemplo ofrecer un modelo superior a un VIP.

Otro aspecto importante a destacar es el funcionamiento de cada modelo. Muchas veces los clientes no entienden el funcionamiento de un producto y existen dudas bastantes comunes. Por ello se crean manuales de usuario que ayuden a comprender su funcionamiento y contienen una lista de preguntas más frecuentes (FAQ). Además si de manera usual una duda sobre el uso del producto lleva a otra duda el sistema indicará la respuesta a la 2ª duda relacionada con la 1ª.

B.2. Acta 2 (31/10/2007)

El proyecto trata de documentar diseñar e implementar un Sistema de Atención al Cliente o CRM que tiene como objetivo guardar y gestionar toda la información posible acerca de productos, clientes, ventas, incidencias, quejas, soluciones, así como las relaciones que puedan existir entre ellos, y dar respuestas a las consultas de los clientes. Además, una funcionalidad muy importante que debería implementar el sistema que se está especificando es el aprendizaje, basado en casos, por lo cual podremos obtener soluciones satisfactorias.

El sistema registrará cada consulta que el cliente plantee. El aprendizaje del sistema es muy importante para determinar de qué forma suele actuar cada cliente. Esto nos permite averiguar cuáles son sus preferencias y en general patrones de comportamiento. Los datos se extraerán bien de la forma de actuar de cada cliente o mediante cuestionarios. A partir de estos datos podemos crear perfiles de clientes que actúen de la misma forma. Pasando a la descripción técnica de nuestro sistema, existen elementos fundamentales tales como:

Los productos son aquellos elementos de consumo, que han sido vendidos o están en stock o incluso puede que aun estén en desarrollo experimental (prototipos). Los productos se pueden identificar unívocamente por su Serial Number (S/N), además de disponer una serie de atributos, que aun no interesa detallar. Como es natural, pueden existir varios modelos para un mismo producto.

Los clientes son todos aquellos usuarios, pasados, presentes y futuros, de los que tengamos constancia y datos en nuestro sistema, que podrán ser utilizados para la generación de estadísticas, y, por consiguiente, para el aprendizaje. Se les podrá clasificar según perfiles, para darle un servicio de asistencia diferente dependiendo del perfil (económico, social, etc). Por ejemplo: Pepito. Varón. 45 años. Dos hijos. Médico = Torpe. Explicarle las cosas de manera sencilla. Juan. Varón. 30 años. Sin hijos. Ingeniero de Telecomunicaciones = Listo. Hablarle con términos técnicos. El sistema recogerá información acerca de las acciones de los clientes. Las compras, las reclamaciones, las consultas, los gustos, los problemas que tienen con los productos, debido a su uso, a su manejo o a la facilidad que tienen de entenderlos.

Las consultas son las llamadas que hacen los clientes al servicio técnico. Pueden ser por varias causas: averías, reparaciones, quejas, recomendaciones o información adicional.

Las Incidencias o Averías ocurren cuando un producto deja de funcionar correctamente. Entonces, el cliente usará el servicio de soporte técnico para intentar solucionarlo. Puede haber muchas clases de averías, desde, por ejemplo, rotura por caída, o que se moje un producto, hasta que el cliente haya desconfigurado el producto y no sepa como restaurar el estado original. Evidentemente habrá más consultas por averías mientras el producto esté en garantía, ya que a partir de esa fecha, es muy probable que compense vender un producto nuevo que arreglar el viejo, pero puede que no. Cada incidencia recogerá datos como modelo afectado y tipo de cliente, y a partir de ella se generará información extra relacionada con la forma de proceder o solventar. Además se extraerán datos relevantes relacionados con el funcionamiento de cada producto y sobre el uso que cada usuario hace.

Las Reparaciones se refieren al arreglo de un producto. Como consultas, las reparaciones pueden proporcionar al cliente información sobre fechas, plazos y costes de la reparación antes de que se produzca. Todos estos datos pueden surgir a partir de la experiencia con otros productos similares o en ocasiones distintas. También se podría proporcionar información, una vez que el producto se ha mandado a reparar, del tiempo que quedará (por ejemplo, se detecta que es un fallo de un componente y que va a tardar un tiempo en llegar uno nuevo). Una idea extra sería hacer un sistema de alarmas, que cuando se modificara un dato de reparaciones se avise al cliente.

Las quejas son las reclamaciones de los clientes, que no quedan satisfechos con el producto o con el servicio, por ejemplo con un retraso en una entrega de un equipo en reparación o venta.

Las consultas de Información se refieren a las características que tiene un producto, funcionalidad (con vistas a adquirirlo o no), propuestas de equipos, dependiendo del perfil socio-económico del cliente, o sobre su manejo. Muchas veces los clientes no entienden el funcionamiento de un producto y existen dudas bastantes comunes. Cada modelo de producto debería disponer de un manual y de una lista de preguntas más frecuentes (FAQ) que pueden ser diferentes dependiendo del perfil. Además si de manera usual una duda sobre el uso del producto lleva a otra duda el sistema indicará la respuesta a la segunda duda relacionada con la primera.

Las recomendaciones son las propuestas que se le da a un cliente que pide un producto con unas características determinadas. Se le intentaría proponer algo que contentara lo máximo posible al cliente, dependiendo de su perfil socioeconómico y de lo que requería.

Las soluciones son aquellas medidas que el equipo del Servicio Técnico toma para cada situación, dependen del tipo de cliente, del caso o problema que se presenta, y del grado de satisfacción conseguido en ocasiones anteriores. Según el tipo de cliente (por ejemplo un VIP) que tiene la incidencia se puede actuar de distinta forma como por ejemplo ofrecerle un modelo superior. Por ejemplo, si a un representante de una empresa se le ha dado un terminal telefónico cutre y ha quedado decepcionado porque la imagen que han tenido los clientes de su compañía ha sido mala, el sistema aprende y la próxima vez no toma esa decisión. Dependiendo de la consulta puede llevarse a cabo distintas alternativas para la solución de la misma como por ejemplo sustituir el producto por otro de características similares.

B.3. Acta 3 (07/11/2007)

Se le presenta el documento de presentación del proyecto con las modificaciones de la versión anterior, completo y adecuado a las expectativas salvo un par de matices

Ver documento modificado.

Además, no interesa que un producto vaya a tener más reparaciones mientras esté en garantía, ya que eso, como mucho, sería un dato estadístico más.

Una vez que ya tenemos una idea de lo que trata el producto, se nos pide definirlo mediante diagramas de secuencia .

Un diagrama de secuencia, (formalmente diagrama de traza de eventos) muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario.

Por ejemplo, qué sucede exactamente cuando un cliente llama por una avería, si se le toman los datos, si se consulta en la Base de Datos de qué tipo de avería se puede tratar, o si se trata únicamente de una desconfiguración del producto, ayudando al cliente a configurarlo correctamente.

Otro ejemplo sería el de un cliente que pide información porque se quiera comprar un nuevo modelo de un producto que ya tiene. Haría falta, por ejemplo, consultar qué producto está usando y cual es la nueva versión, y se le enumerarían las características del nuevo producto, por ejemplo.

B.4. Acta 4 (14/11/2007)

Revisión de los diagramas de secuencia, resultando demasiado triviales en algunas partes como demasiado orientados al código en otras. Es por eso que nos dividimos el trabajo para hacer cada uno de nosotros un tipo de consulta. De manera individual realizaremos un trabajo de abstracción e imaginación de la lógica de negocio. Generaremos un diagrama en el que quede reflejado cuáles son las características o atributos o propiedades o circunstancias del cliente y su consulta, por lo que se ha de priorizar para que el sistema proporcione alternativas. Como aún estamos en una fase preliminar, los tipos de respuesta serán de carácter general, (p.e. acción dura, acción media, acción blanda, etc)

Diagrama de flujo de las incidencias

B.5. Acta 5 (21/11/2007)

Exponemos los diagramas generados, en los que se representa el árbol de decisiones que el sistema tendría que tomar para ofrecer una respuesta adecuada dependiendo de las condiciones del cliente. Estas condiciones serían por las que el sistema tendría que priorizar. Entre las condiciones del cliente propuestas tenemos:

Tras revisar los diagramas encontramos algunos fallos:

El documento de las incidencias se puede encontrar en [PNG ] o [PDF]

B.6. Acta 6 (28/11/2007)

Revisamos los diagramas de manera conjunta con el profesor. En la revisión descubrimos algunos cambios y mejoras.

Por ellos generamos los diagramas correspondientes atendiendo a estos cambios. En formato [PNG ] y [PDF ]

B.7. Acta 7 (05/12/2007)

Realizamos una revisión de los diagramas con las modificaciones de la reunión anterior. Limitándonos a mostrar la estructura que tendría el sistema así como los “atributos” requeridos para que la inteligencia proponga una o varias respuestas. Lo que llamaremos acciones.

Empezamos una nueva fase: el diseño de la base de datos. Primeramente capturamos los atributos que hacen falta para modelar el comportamiento deseado. En esta primera fase nos centraremos en poner el nombre de la tabla junto con los campos que contendría, sin centrarnos en el tipo de datos de los campos, ni en los datos que contendría cada tabla, ni optimizaciones sobre la bbdd.

El sistema debe tener un comportamiento de acción - reacción. Por ellos es importante almacenar las acciones que hemos hecho sobre cada cliente, así como las reacciones que los clientes tienen al realizar dicha acción. De todos estos datos se podrán extraer comportamientos estadísticos con los que se sustituirán las acciones según los intereses de la empresa que use CRMI (por ejemplo: aquellas acciones que provoquen bajas de los clientes deberán ser sustituidas por otras si así lo aconsejan)

Como primera aproximación generamos una vista preliminar de las tablas y los campos que contendrían para gestionar las incidencias. Disponible en versión [PDF] y [PNG ]

B.8. Acta 8 (12/12/2007)

En la reunión revisamos el esquema de tablas y atributos generados. Sin encontrar mayor problema, generaremos un ejemplo a modo ilustrativo para hacer más palpable que las tablas propuestas y sus atributos cumplen las especificaciones del proyecto. Aun no estamos en condiciones de asegurar de que esas serán todas las tablas de nuestra BBDD en nuestro sistema (seguramente harán falta más) es por ello por lo que es necesario ver la completidud del sistema con el soporte de las tablas actual. Al hacer la revisión de las tablas nos dimos cuenta de que hacía falta unificar los nombres así como la disposición de las mismas.

El documento generado para la orden del día es un ejemplo que muestra para un caso genérico incidencias, aunque se han usado algunos datos concretos para aportar mas claridad al ejemplo, de cuales serían los atributos que se han de recuperar de la bases de datos así como la relación de algunas atributos con algunas tuplas en otras tablas. El documento generado se encuentra en formato [PNG] y [PDF]

Para ir entrando en materia se propone una implementación de la base de datos para ellos se genera el diagrama E/R relativo a las incidencias. El diagrama E/R se encuentra en [PNG] y [PDF]

B.9. Acta 9 (19/12/2007)

No hubo reunión. Debido a la cercanía del comienzo de las vacaciones de navidad, el profesor no tuvo clase la hora anterior a la reunión, por lo tanto se suspendió la reunión posponiéndola para el siguiente miércoles de enero.

B.10. Acta 10 (09/01/2008)

En la primera parte el profesor revisa los documentos generados en la Reunión 8 y muestra su conformidad con lo que se propone en ellos. Desde hace algunas reuniones, nuestro sistema tiene un modulo que se incorpora como una caja negra. Se trata del módulo de la inteligencia. Como es natural ese módulo dispondrá de una serie de reglas, las cuales serán actualizadas y coherentes con el conocimiento estadístico extraído de la propia interacción de los clientes con el sistema. Además puede estar asentado sobre un conocimiento mas general, pero siempre estará adaptado a las reacciones que tienen los clientes. Existen diversas maneras de implementar el módulo de inteligencia:

Por el momento el profesor sugiere que usemos el 2º modo de implementación (usando una BBDD)

En ambos sistemas las reglas deben tener la siguiente forma:


Condición 1 Condición 1 Condición i Condición N Acción
Valor a Valor b Valor c Valor d Acción A
Valor b Valor f NULL Valor g Acción B

De tal forma que si se cumplen todas las condiciones de una fila se activara la acción correspondiente a dichos valores.

Como condiciones aparecerán todas las condiciones usadas por alguna de las reglas almacenadas en el sistema. De esta forma será frecuente la aparición de valores NULL para alguna de las condiciones de una regla. Esto será así siempre y cuando ese valor no sea relevante para aplicar dicha acción.

Para esta reunión se trata de esbozar el diseño del módulo de inteligencia. Centrándonos en el diseño de la tabla que almacene las reglas.

Se muestra un ejemplo de lo que contendría la tabla de reglas.

id idAccion edad_Min edad_Max profesión tipoCliente estUltLlamada
1 1 0 17 NULL Normal NULL
2 2 18 26 Ingeniería Normal conforme
3 1 18 26 NULL moroso disconforme
4 1 35 45 Funcionario NULL conforme

La tabla reglas forma parte de la BBDD que se muestra en formato

[PDF] y [PNG]

B.11. Acta 11 (16/01/2008)

Revisamos los diagramas propuestos por el profesor. Dado el visto bueno, nos pide que implementemos la base de datos. Para ello usaremos el diseño generado con el programa fabFORCE generando así las correspondientes instrucciones SQL de creación de tablas.

El código SQL para la generación de la base de datos se muestra a continuación: Notar que el código que se genera crea las tablas necesarias y algunas filas para su uso con las reclamaciones. La incorporación de la parte de soluciones y reclamaciones solo conllevaría algunas modificaciones en el actual diseño. Siendo necesario la inclusión de alguna nueva tabla así como la posible inclusión de atributos adicionales en las ya existentes.

Descarga el archivo 1.sql

B.12. Acta 12 (23/01/2008)

Presentamos los diseños preliminares de la base de datos al profesor. Sin entrar en los detalles propios del diseño, para las siguientes reuniones empezaremos a implementar la BBDD. Como comentamos en reuniones pasadas, utilizaremos MySQL para gestionar la base de datos del proyecto. Para poder realizar pruebas en los laboratorios se solicitó acceso a MySQL.

Comprobado que se carga la base de datos en los laboratorios. Se ha modificado el archivo generado para la pasada reunión que se adjunta a continuación. 2.sql

B.13. Acta 13 (04/03/2008)

Realizamos una integración de las 3 partes constituyentes el CRMI, a saber: Reclamaciones, Incidencias y Consultas de Información

El diseño de la BBDD realizado es el siguiente Diseño completo

Las instrucciones SQL para crear dicha BBDD son

B.14. Acta 14 (11/03/2008)

Como se pedía para esta reunión se genera un pequeño ejemplo de los pasos que se llevarían a cabo vistos desde el puneto de vista de la BBDD. El ejemplo trata de manera esquemática el proceso desde que un nuevo cliente llega al sistema, crea una nueva incidencia, pasado un tiempo consulta el estado de la misma. Además de quedar registrado en el según el modelo acción - reacción.

Al final se muestra un pequeño ejemplo de una selección para obtener las acciones que se le aplicarían al cliente. Tener en cuenta que el ejemplo es una simplificación. Para la obtención de las acciones sería necesario restringir mas por mayor numero de campos. Además la información de las reglas es meramente ilustrativa no contiene significado adecuado en el dominio.

B.15. Acta 15 (2/04/2008)

Esta reunión (Reunión 15) estaba prevista para el día 25/03/2008, por motivos de incompatibilidad de horarios se ha pospuesto a una reunión posterior. Corresponde al Acta 16.

Se han realizado algunos cambios en la BBDD. De esta forma se clarifica la estructura de la BBDD en aras de facilitar su genericidad y facilitar el desarrollo.

Diagrama de flujo

El diagrama de flujo muestra el comportamiento del CRMI para el caso de un cliente existente o no quiera interaccionar con el sistema. El diagrama se centra sobre todo en las reglas y la selección de las acciones que se realizaran al cliente.


PIC

Figura B.1: Diagrama de flujo


Nueva versión del documento disponible en el Acta 16

B.16. Acta 16 (16/04/2008)

En esta reunión se enseña al profesor los casos de uso, la documentación referente a la memoria y el diagrama de flujo generado en el acta 15. Respecto al dicho diagrama se sugiere la modificación y explicación de las variables que intervienen en el módulo buscar reglas correspondientes a la etapa de inteligencia. Por ellos se genera un diagrama modificado según lo propuesto.

En una segunda parte de la reunión se concretan las partes que debe contener la memoria.

Se incluye una nueva versión del diagrama de flujo generado en el acta 15 incorporando el árbol discriminatorio, en lugar de un filtro como aparecía en la versión anterior. Las diferencias entre filtro y árbol discriminatorio son:


PIC

Figura B.2: Diagrama de flujo - Versión 2


B.17. Acta 17 (29/04/2008)

En esta reunión hemos estado hablando de como debe estar estructurada la memoria final del proyecto. Los distintos apartados que la componen son los siguientes:

Antecedentes:
Aquí definimos que es un CRM-I mediante una definición completa
Objetivos del proyecto:
Dejaremos claro que es lo que queremos mostrar con el proyecto
Metodología de desarrollo:
Explicaremos cómo nos hemos organizado en el proyecto y cómo se han llevado a cabo las reuniones.
Análisis:
Se describen las distintas técnicas estudiadas para llevar a cabo nuestro objetivo
Diseño:
En este apartado mostraremos los diagramas y la estructura final de la base de datos. Se incluyen los casos de usos ya implementados
Implementación:
Describimos las tecnologías de desarrollo utilizadas y mencionamos parte del interfaz con algún pantallazo incluido
Resultados:
Se mencionan los casos más significativos.
Conclusiones:
 
Futuras
extensiones:
Bibliografía:
 

En cuanto a las extensiones de cada apartado no está muy claro.

B.18. Acta 18 (21/05/2008)

Reunión de control para revisar la memoria. El objetivo de esta reunión es presentar al profesor la memoria para que nos de su opinión y corrija posibles fallos, tanto como cambios de contenidos, punto de vista, temas que se debieran tratar, etc. A fecha de la reunión la memoria se encuentra en pleno desarrollo, aún no esta terminada, pero si bastante avanzada, por eso requerimos el punto de vista del profesor para que establezca nuevos objetivos de la memoria. Por falta de tiempo del profesor, en la reunión solo pudimos darle la memoria en formato editable.

B.19. Acta 19 (04/06/2008)

En la reunión se revisa la memoria y se establecen nuevos objetivos. El contenido de la memoria es adecuado, pero quedan limar detalles relacionados con al expresión y el estilo. Aunque el contenido es correcto quedan temas pendientes de desarrollar. Es una reunión bastante breve aunque nos sirve de punto de partida para seguir ampliando la memoria.

B.20. Acta 20 (10/06/2008)

Tras la revisión de la memoria del acta anterior (Acta 19) y habiendo ampliado la memoria en los puntos comentados, se procede a una revisión mas exhaustiva con el profesor revisando más en detalle los contenidos de la memoria. Se establecen nuevos objetivos para la memoria: añadir un apartado de ejemplos de funcionamiento que refleje el funcionamiento del sistema. Además comentamos cuestiones relacionadas con la exposición del proyecto: