Acceso Acerca de

CRM Inteligente :: Documentación

Capítulo 6
Implementación

Debido a que el objetivo del proyecto es diseñar un sistema CRM Inteligente, la implementación se ha reducido a la realización de un prototipo.

El prototipo se ha implementado como una aplicación web usando JSP. Se ha utilizado una base de datos relacional creada en MySQL versión 5.0.51. El motor usado es MyISAM. Se ha optado por su utilización debido a la sencillez de uso, además se trata del motor por defecto con el SGBD MySQL.

El servidor web utilizado ha sido Apache Tomcat 6 (http://tomcat.apache.org/). Como entorno de desarrollo, optamos por Eclipse EE 3.3 (http://www.eclipse.org/)

La implementación para el sistema en producción se llevaría a cabo de manera similar. Probablemente habría que cambiar de motor de almacenamiento en la BBDD sustituyendo MyISAM por InnoDB. La versión de SQL utilizada en la BBDD es SQL:2003.

La aplicación, aunque no usa ningún framework para el prototipo, para la implementación del sistema Modelo-Vista-Controlador sería recomendable utilizar uno del estilo de Struts, incorporado en el proyecto Apache (http://struts.apache.org/)

6.1. Decisiones sobre el diseño de la Base de Datos

La base de datos creada para nuestro sistema tuvo algunos cambios desde el inicio de su diseño. Para ello y para su creación e implementación nos valimos de la herramienta DB Designer 4, disponible gratuitamente desde fabforce.net.

Al principio creamos tres bases de datos independientes, relacionadas con las tres funcionales a las que íbamos a proveer al sistema, esto son, los siguientes tipos de incidencias por las que un cliente podía ponerse en contacto con la empresa: Averías, Reclamaciones y Consultas de Información.

En un principio, tal y como lo veíamos, cada subsistema tenía elementos diferentes. Al haber tantas funcionalidades como componentes del grupo de proyecto, nos las repartimos, de manera que cada uno hiciera una parte, de modo que al hacerlas individualmente, nos sirviera como una especie de “tormenta de ideas”, y cada uno aportara lo que pensaba que fuera conveniente. Por tanto, aunque los conceptos eran mayoritariamente parecidos, había incompatibilidades entre los tres diseños, empezando por el nombre de atributos que representaban lo mismo pero tenían nombres diferentes.

Para juntar las tres partes creadas, nos fijamos primero en las similitudes de los tres modelos. En todos los casos habíamos creado una entidad llamada cliente, que, intuitivamente, guardaba todos los datos personales necesarios. Sin embargo, algunas veces parecía necesario guardar la información de cómo había ido reaccionando, para lo cual en un diseño se incluyó como una tabla adicional relacionada con la tabla clientes. Al juntar los tres diseños, esta tabla se suprimió, integrándose esta información dentro de otra tabla que contenía el histórico.

Otra de las similitudes que disponían los tres diseños era un sistema de Acciones y Reacciones. La filosofía de la aplicación, de guardar todos los datos relacionados con lo que se le hace al cliente, obligaba a guardar un registro de Históricos de Acciones y Reacciones, así como de otra tabla, diseñada para ser más leída que modificada, en la que se almacenaban los distintos tipos de acciones que se pueden aplicar a un cliente. Esta tabla de Acciones guarda un identificador de acciones, junto con una descripción en un campo de texto.

En un principio, por simplicidad a la hora de juntar el trabajo que habíamos hecho por separado, pensamos que lo mejor sería crear tres históricos de Acciones y de Reacciones distintos para cada funcionalidad. Esto aseguraba que no se pudieran aplicar erróneamente. Sin embargo, la similitud entre las funcionalidades de Averías y de Reclamaciones (ya que muchas veces el cliente detecta un fallo en el producto o una deficiencia en el servicio, pero no sabe distinguirlo de un error de configuración) hizo pensar que, posiblemente, el conjunto de las Acciones de ambas funcionalidades pudieran no ser disjuntos. Como uno de los objetivos de una base de datos es, en la medida de lo posible, evitar información redundante, para simplificar las modificaciones, decidimos crear históricos conjuntos para las Averías y Reclamaciones.

Con las Consultas tuvimos serias dudas para integrarlas con las mismas tablas, pero al final, resultaba más sencillo de mantener. Para ello, pusimos un campo en las tablas que identificaba a cada registro con el tipo al que pertenecía

Con estas y otras modificaciones, terminamos agrupando todo en un único modelo en el cual encontramos, vertebrando, las tablas Incidencias, Reclamaciones y Consultas. Estas tres tablas, que no se relacionan entre ellas (son subsistemas diferentes) en definitiva, terminan comportándose de manera similar entre sí. Se relacionan con la tabla Clientes, y con las tablas Acciones y Reacciones, estas últimas, a su vez, referencian a un producto.

El resultado final es el mostrado en el apartado diseño de la memoria.

6.2. Capturas de pantalla del prototipo

En las siguientes capturas de pantalla se podrá ver el aspecto del prototipo de la aplicación. Se trata de una aplicación web lo que facilita su implantación así como la incorporación de nuevos cambios sin realizar instalaciones expresas en cada uno de los terminales. Se muestran una serie de pantallas con algunas de las funcionalidades que incorporaría la aplicación funcional. Quedan pendientes incluir nuevas funcionalidades a la interfaz. Como ejemplo se han incorporado datos inventados sobre clientes así como mensajes de advertencia, información o alerta al usuario sobre el perfil del cliente. El usuario deberá utilizar la información de los mensajes para tratar al cliente así como seguir el protocolo de la empresa en sintonía con las políticas de negocio incorporadas al CRMI. El sistema proporcionará acciones que se aplicarán a cada cliente en función de lo que se explicó a lo largo del presente documento.

Es posible que en alguna captura de pantalla la cantidad de información contenida sea excesiva, en este caso, el sistema ocultará la información no relevante. Es necesario que los usuarios estén familiarizados con el uso de la aplicación. Alguna de la información que se muestra puede no ser necesaria para el usuario encargado de responder las llamadas de los clientes, pero por el contrario si puede resultar de gran utilidad a otros usuarios interesados en la optimización y funcionamiento del sistema. Un sistema de estas características necesita de un proceso de funcionamiento previo para adaptarse a los clientes y satisfacer sus necesidades asegurando un porcentaje mínimo de bajas de los clientes en la empresa.


PIC

Figura 6.1: Inicio de sesión en el sistema CRMI



PIC

Figura 6.2: Formulario de alta de un nuevo cliente



PIC

Figura 6.3: Modo de recuperación de la contraseña de usuario olvidada



PIC

Figura 6.4: Página inicial al entrar al sistema



PIC

Figura 6.5: Averías activas



PIC

Figura 6.6: Reclamaciones activas



PIC

Figura 6.7: Consultas activas



PIC

Figura 6.8: Formulario de edición de una incidencia