E-mail:
Contraseña:

Deseo registrarme
He olvidado mis datos de acceso

Regístrate para votar

CAPÍTULO 5

DESARROLLO DEL PROTOTIPO DE eCRM

 

 

En el capítulo anterior se describió un modelo para la implementación de soluciones CRM, y adicionalmente se describieron algunas de las técnicas empleadas en la constitución del componente analítico de un eCRM, ahora se planteará un caso hipotético y se construirá un prototipo para mostrar las funcionalidades básicas de un eCRM Analítico.

 

5.1  SELECCIÓN DE UN CASO DE ESTUDIO

 

Las siguientes líneas son parte del artículo “Un análisis de las alternativas de implantación de soluciones CRM” [48] publicado recientemente en la revista electrónica e-Contact1, en el mismo que se exponen algunas consideraciones previas a la implementación de una solución de eCRM:

 

“El desarrollo de una solución eCRM implica una serie de retos. Las principales áreas que una compañía debe analizar son los desafíos de negocios, las consideraciones tecnológicas, los problemas operativos, las implicaciones financieras y el tiempo respecto al mercado.

 

Desde el punto de vista financiero, el costo para una solución eCRM es abrumador. Una manera de darse una idea del orden de la inversión consiste en tomar en cuenta diferentes categorías de inversión. Las categorías de inversión que se requieren para crear, operar y mantener una solución eCRM son:

 

1. Hardware y software de producción.
2. Gastos de mano de obra – los gastos del personal operativo para respaldar, modificar y actualizar el uso de la solución tecnológica por parte de la empresa.
3. Hardware y software de pruebas y preparación.
4. Gastos de mantenimiento (ambientes de producción y de prueba).
5. Gastos de investigación y desarrollo en tecnología de información (para evaluar nuevas tecnologías de administración del servicio al cliente y su impacto en las necesidades actuales o potenciales del negocio).

 

La mayoría de las empresas que cuentan con un entorno maduro de servicio y atención al cliente han invertido en las categorías uno, dos y cuatro, antes mencionadas. Pero estas inversiones se han destinado primordialmente a los aspectos de infraestructura de voz y gestión de contactos de los centros de contacto (y están orientadas principalmente al Centro de Contacto). Su tecnología se está volviendo obsoleta y empiezan a experimentar dificultades para agregar e integrar las propuestas de Internet y autoservicio que se requieren hoy en día, así como las tecnologías de "middleware" para administrar sus canales de contacto.

 

Un número aún menor de empresas ha invertido en la categoría tres, la infraestructura necesaria para probar, preparar y lanzar nuevas versiones de sus soluciones de gestión de clientes. Esto se traduce en una preparación y lanzamiento deficientes de nuevas tecnologías, y en interrupciones de la operación del negocio cuando se introduce un nuevo producto o se actualiza algún componente.

 

Por su parte, la inversión actual en la categoría cinco se limita por lo general a asistir a alguna exposición o leer publicaciones especializadas. Por desgracia, estas medidas no bastan para preparar a una empresa para entender de qué manera las últimas tendencias afectan sus inversiones existentes o en dónde resulta más conveniente introducir nuevos productos y tecnologías.

 

Con respecto a los tiempos, las empresas esperan obtener resultados y un indicador de las inversiones realizadas en su solución eCRM. Los resultados de negocios van en función directa de la ventaja que les brinda su solución eCRM, es decir, la información acerca del comportamiento de los clientes y el impacto que tienen sus recursos y programas de servicio al cliente en sus canales de contacto críticos.

 

La implantación de soluciones eCRM multicanal puede llevarse de 12 a 15 meses, o incluso más. Cuando se toman en cuenta las iniciativas clave necesarias (como, por ejemplo, los requerimientos y la estrategia de negocios, el "business case", el diseño de la experiencia que se va a ofrecer al cliente, solicitudes de propuesta de producto y adquisición y desarrollo de una funcionalidad de preparación y pruebas, integración con sistemas heredados, pruebas exhaustivas, capacitación y lanzamiento) la solución se lleva demasiado tiempo desde la óptica de los patrocinadores clave en la empresa.

 

La industria proveedora debe hacer frente a esta problemática y ofrecer soluciones y técnicas para implantar la arquitectura eCRM que se requiere, así como sus mejoras subsecuentes, a fin de proveer más pronto los indicadores y beneficios de negocios esperados.

 

Por ejemplo, muchas empresas maduras están tratando de incursionar en nuevos mercados o regiones geográficas en los que no cuentan con una masa crítica de clientes. Estas compañías no pueden darse el lujo de esperar de 12 a 15 meses o más para desarrollar una infraestructura propia con las tecnologías integradas clave indispensables para competir. Quizá una solución temporal que les permitiera crecer rápidamente, adquirir clientes, aprender y medir el comportamiento sería un buen primer paso hacia el desarrollo de una arquitectura eCRM óptima”.

 

El artículo anteriormente mencionado sirve para dejar en claro que realizar una aplicación que ponga en práctica todos los conceptos y funcionalidades propias de una solución eCRM requeriría de la definición de un sistema con características muy amplias que tomaría tiempos de desarrollo muy prolongados y con costos que resultarían excesivamente onerosos; adicionalmente también se necesitaría de una empresa dispuesta a esperar estos tiempos y a financiar los costos involucrados en el desarrollo del proyecto. De tal modo que resultó imposible reunir esos prerrequisitos y es por esto que para poder alcanzar los objetivos propuestos para el presente trabajo, la aplicación desarrollada se limita a un prototipo evolutivo en el cual se implementaron algunas de las características y funcionalidades más notables que pueden encontrarse en un CRM Analítico.

 

Para el desarrollo del prototipo se utilizaron los datos de la base de datos de ejemplo “FoodMart”, la misma que se incluye en la distribución estándar de Microsoft SQL Server 2000. La base de datos FoodMart representa a la compañía ficticia FoodMart, Inc., una cadena de supermercados sólo para miembros que utiliza las prácticas de membresía para reducir sus gastos generales operativos, y proporcionar artículos de calidad a los miembros a precios substancialmente más bajos que aquellos que se encuentran normalmente en establecimientos convencionales al mayoreo o menudeo.

 

Como la mayoría de las grandes empresas, FoodMart se enfrenta a una variedad de retos que tienen relación con la administración de sus datos. Para manejar el negocio diariamente, FoodMart debe monitorear el inventario en sus almacenes, así como las existencias y ventas de sus tiendas. De este modo FoodMart se ha percatado de que, para ellos, es una prioridad contar con la capacidad de reunir datos de toda la compañía, analizarlos e identificar las tendencias que permitan a la cadena reaccionar rápidamente ante las demandas cambiantes de sus consumidores en cada región, con el fin de que estas acciones se conviertan en una ventaja competitiva importante ante su competencia más inmediata.

 

5.2  PLANTEAMIENTO DEL PROBLEMA

 

 

Los accionistas de FoodMart Inc, concientes de que el futuro de su empresa, radica en la conservación y consolidación de las relaciones con sus clientes actuales, han optado por emprender una estrategia de CRM que les permita obtener el máximo beneficio posible de la información que actualmente almacenan de cada transacción o intento de negociación que realizan con sus clientes, para esto, como fase inicial, han planteado la construcción de un módulo de CRM Analítico el mismo que funcionará como fuente primaria para el soporte a la toma de decisiones del sector gerencial.

 

La alimentación de datos para el módulo CRM provendrá de la información acumulada de las ventas y de la información de los clientes de FoodMart, de modo que partiendo del análisis de CRM le permitirá a la gerencia de ésta empresa conocer la siguiente información:

 

¨      Reporte de densidad poblacional de los clientes: Los accionistas podrán conocer la forma en la que se encuentran distribuidos sus clientes en las diferentes ciudades donde tienen sucursales. De esta forma podrán conocer en que ciudades cuentan con mayor número de clientes y en función de esto podrán determinar cuáles son las ciudades donde los clientes son más rentables y en que ciudades necesitarían abrir o cerrar sucursales, según sea el caso.

 

¨      Reporte de resultados de promociones:  La información de las ventas le permitirá mostrar al módulo de CRM, los resultados alcanzados, en términos de éxito o fracaso monetario, por cada una de las  promociones emprendidas por la compañía en un periodo determinado.

 

¨      Pirámide de clientes: Los accionistas podrán conocer quienes son los mejores clientes para la organización y además tendrán la conformación y distribución exacta de los mismos en la pirámide, a partir de esto podrán conocer cuáles fueron los niveles de consumo de un cliente para un periodo determinado.

 

¨      Reporte de hábitos de consumo: Gracias al análisis de la información de ventas, los accionistas podrán conocer detalles relevantes de las compras de sus clientes y a partir de estos se podrían establecer los patrones de consumo seguidos por un cliente o grupo de clientes en particular.

 

 

5.2.1 DECLARACIÓN DE PROPÓSITOS

 

 

Descripción General:

 

El Sistema de Administración de Relaciones con Clientes tiene como finalidad primordial ayudar a la organización en el manejo de las relaciones comerciales y personales que mantiene con sus clientes, buscando la eficiencia y la excelencia en todos y cada uno de los procesos que conlleva la difícil y a veces tediosa labor de edificar y mantener contactos sustentables y rentables con los clientes de la empresa; es por esto que implementará un prototipo de CRM Analítico para brindar a los mandos administrativos y a los ejecutivos la posibilidad de tener la información adecuada para la toma de decisiones acertadas con respecto a  los procesos de atención dirigidos a sus clientes, el éxito o fracaso de una determinada campaña de promoción, conocerán también cuáles son las ciudades que concentran el mayor número de clientes o que generan mayores ingresos, así como  podrán disponer de información referente a aquellos productos que cuentan con mayor aceptación del público.

 

En términos generales deberá existir una persona conocida como administrador del sistema quien tendría entre sus funciones el registro de nuevos datos, la actualización y mantenimiento del sistema, el manejo de contraseñas y claves, entre otros, de manera que se constituirá en el responsable directo del buen uso de todos los conceptos de seguridad que se implementen en el sistema.

 

Responsabilidades:

 

El alcance inicial se limita a construir un módulo de CRM analítico que funcione dentro de la Intranet de la compañía de tal modo que facilite el acceso a la información de los clientes para realizar las siguientes acciones:

 

¨      Segmentación geográfica de clientes.

¨      Elaboración de una pirámide de clientes.

¨      Medición de promociones.

¨      Reporte de hábitos de consumo de los clientes.

 

El prototipo implementado permitirá obtener esta información y la presentará en los formatos adecuados, dejando las decisiones finales para los expertos en marketing de la compañía quienes deberán utilizar estos datos para sus definiciones y estrategias de mercado.

 

Exclusiones:

 

Las acciones que no se contemplan en el presente desarrollo son las siguientes:

 

¨      El alcance de esta implementación se limita al componente analítico del CRM,  la parte operacional o de contacto con los clientes no será desarrollada.

 

¨      El CRM implementado es una herramienta orientada a dar soporte para la toma de decisiones.

 

5.2.2 SEGMENTACIÓN GEOGRÁFICA DE CLIENTES

 

A los empresarios de FoodMart Inc, les interesa conocer la densidad poblacional de sus clientes, relativa a cada una de las sedes de la compañía con el fin de poder determinar aquellos sitios donde es factible abrir nuevas dependencias para fortificar su presencia en el mercado.

 

Para lograr esta segmentación, el CRM Analítico explorará la información de clientes y obtendrá el conjunto de ciudades en donde ellos realizan sus compras para luego cruzar esta información con los datos de compras de los clientes. El resultado final será un reporte donde se ordenen las ciudades por número de clientes y por montos de compras de los mismos.

 

5.2.3 CONFORMACIÓN DE LA PIRÁMIDE DE CLIENTES

 

Los accionistas de FoodMart Inc concordaron en que es necesario recurrir a  la elaboración de una Pirámide de Clientes lo que les permitirá contar con una herramienta con la cual podrán clasificar a sus clientes y a la vez determinar cuáles de éstos son los más rentables con el fin de enfocar hacia ellos las nuevas estrategias de mercadeo que se establezcan en el futuro.

 

5.2.4 MEDICIÓN DE PROMOCIONES

 

La información de las ventas de productos le permitirá mostrar al módulo de CRM, los resultados alcanzados, en términos de éxito o fracaso monetario, por cada una de las  promociones emprendidas por la compañía en un periodo determinado. De esta forma los accionistas y gerentes de la organización podrán tener una mejor noción acerca de los productos y campañas publicitarias que han tenido un mayor impacto en las ventas.

 

5.2.5 REPORTE DE HÁBITOS DE CONSUMO

 

Gracias al análisis de la información de ventas, los accionistas podrán conocer en un mejor detalle, los hábitos de consumo de sus clientes en periodo determinado, como por ejemplo, en que tienda o supermercado hicieron sus compras, qué productos compraron y en qué cantidad lo hicieron o incluso cuál es el día de la semana que prefieren para realizar sus compras.

 

5.3  ESPECIFICACIÓN DE REQUERIMIENTOS

 

5.3.1 INTRODUCCIÓN

 

En esta sección se describirá la especificación de requisitos del proyecto prototipo de  “eCRM – Analítico”, intentando seguir la norma IEEE 830 [18] en todos los apartados en los que sea posible. Se pretende ofrecer una definición completa y global de la funcionalidad de operación que se va a tener disponible en el prototipo, a fin de que acepte dicha funcionalidad como requisitos de usuario o de que introduzca todas la modificaciones que considere necesarias para la versión especificada.

 

5.3.1.1 Alcance

 

Esta especificación de requisitos está dirigida al usuario del sistema, a partir de ahora referido como el usuario, que estaría directamente involucrado en la implantación del sistema, a las personas que potencialmente puedan ser usuarios del sistema y el equipo de desarrollo de dicho sistema

 

5.3.1.2 Ámbito

 

El producto final creado según los requisitos especificados en este documento será el prototipo de eCRM de ahora en adelante llamado “CRM Explorer”.

 

El prototipo “CRM Explorer” estará básicamente compuesto de dos partes con funcionalidades distintas. Estas funcionalidades serán:

¨      Configuración del sistema 

¨      Módulo de CRM Analítico.

 

5.3.1.2.1  Configuración del sistema

 

¨      Añadir o eliminar datos de usuarios: El administrador del prototipo podrá ingresar ó eliminar la información de los usuarios del sistema por medio de la interfaz del mismo.

 

¨      Definir perfiles de usuario:  El nivel de información que el prototipo presentará al usuario está definido por el perfil que éste tenga para el sistema, para este prototipo se definen dos perfiles: Administrador y Gerente .

 

5.3.1.2.2 CRM Analítico

 

¨      Cargar datos externos: CRM Explorer deberá contar con procesos para cargar datos externos provenientes de la información de ventas y clientes de la organización.

 

¨      Segmentación geográfica de clientes: El usuario de CRM Explorer podrá contar con información acerca de la densidad poblacional y distribución de los clientes en las diferentes ciudades donde opera la organización.

 

¨      Conformación de la pirámide de clientes: CRM Explorer podrá emplear la información de ventas para poder segmentar a los clientes en función del volumen de compras realizado por cada uno de ellos en un período determinado, para esto se elaborará la “Pirámide de Clientes” de la organización.

 

¨      Medición de promociones: CRM Explorer permitirá determinar cuáles de todas las promociones de productos obtuvieron ingresos mayores a los generados por los gastos de publicidad y difusión de las mismas.

 

¨      Reporte de hábitos de consumo: CRM Explorer permitirá conocer cuál fue el comportamiento de un cliente, con respecto a sus consumos, en un período determinado.

 

5.3.2 DESCRIPCIÓN GENERAL

 

5.3.2.1 Perspectiva del producto

 

Debido al contexto en el que se usará el prototipo, éste deberá tener un fácil y rápido uso, y poseer una interfaz de usuario sencilla.

 

Este producto deberá ser independiente y autocontenido.

 

5.3.2.2 Características de los usuarios          

 

Los usuarios no deben tener ningún conocimiento avanzado, tan solo deberán conocer los distintos parámetros de configuración necesarios para realizar la segmentación y clasificación de los clientes.

 

5.3.2.3  Limitaciones generales

 

Los requisitos de hardware y software mínimos e indispensables para el correcto funcionamiento del sistema se definen a continuación:

 

5.3.2.3.1 Requerimientos de Hardware

 

Servidor

¨       Procesador: Pentium IV o Superior.

¨       Memoria RAM: 128 MB o más.

¨       2 GB de espacio libre en disco duro.

¨      Tarjeta de red.

¨      Mouse.

 

Clientes

¨       Procesador: Pentium III o Superior.

¨       Memoria RAM: 64 MB o más.

¨       Tarjeta de red.

¨       Mouse.

 

5.3.2.3.2 Requerimientos de Software

 

Servidor

¨       Sistema Operativo: Windows NT 4.0 ó Superior.

¨       Browser: Internet Explorer 5.0 ó superior.

¨       Herramientas de desarrollo: Visual Basic 6.0, Visual Interdev 6.0.

¨       Servidor Web: Internet Information Server 4.0 ó superior.

¨       Base de Datos: Microsoft SQL Server 2000.

 

Clientes

¨       Sistema Operativo: Windows 98 ó superior.

¨       Browser: Internet Explorer 5.0 ó superior.

 

 

5.3.2.4 Suposiciones y dependencias

 

Se han establecido las siguientes suposiciones:

¨      El usuario está familiarizado con el funcionamiento de un sistema de ventanas común y con el uso de navegadores de internet (browsers).

 

¨      Los equipos en los que se vaya a ejecutar la aplicación, deben cumplir los requisitos antes indicados, para garantizar una ejecución correcta de la misma.

 

5.3.2.5 Operaciones

 

El usuario podrá efectuar las siguientes operaciones:

 

¨      Segmentación geográfica de clientes.

¨      Conformación de la pirámide de clientes.

¨      Medición de promociones.

¨      Reporte de hábitos de consumo de clientes.

 

La descripción de cada una de estas operaciones ya fue expuesta en la sección 5.2 del presente documento.

5.3.3 REQUISITOS ESPECÍFICOS

 

5.3.3.1 Interfaces Externas

 

5.3.3.1.1 Interfaces con el usuario

 

La interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de texto. Esta deberá ser construida específicamente para el prototipo propuesto y será visualizada desde un navegador de Internet.

 

5.3.3.1.2 Interfaces de hardware

 

El prototipo a construirse no maneja interfaces de hardware, únicamente le es indispensable que los equipos en donde se ejecute cumplan con lo señalado en la sección 5.3.2

 

5.3.3.1.3 Interfaces de Software

 

El prototipo se comunica con una base de datos propia (SQL Server) desde donde tomará toda la información que se presente al usuario. Adicionalmente en el caso de existir otras bases de datos como por ejemplo una base de datos de ventas o clientes, es necesario construir mecanismos para importar esa información hacia la base de datos propia del prototipo.

 

5.3.3.2 Fuentes de entrada

 

Las fuentes de entrada para el prototipo serán el teclado y el ratón.

 

5.3.3.3  Destino de la salida

 

De forma general la salida de información se presentará por pantalla.

 

5.3.3.4 Rangos Válidos

 

Las entradas estarán controladas por el prototipo de tal forma que no existan valores fuera de rango.

 

5.3.3.5 Restricciones Temporales

 

No existen restricciones de este tipo.

 

5.3.3.6 Relaciones con otras entradas / salidas

 

Las entradas provocarán la pantalla de salida correspondiente. Las modificaciones en el perfil de un usuario afectarán a las sucesivas consultas que éste puede realizar sobre el prototipo.

 

5.3.3.7 Formato de pantalla

 

El usuario visualizará la interfaz del prototipo corriendo sobre un navegador o browser, todas las pantallas que se construyan tendrán la siguiente estructura:

Figura 5.1: Formato de Pantalla

La Figura 5.1 muestra el esquema general de la interfaz de CRM Explorer, la misma que está compuesta de las siguientes partes:

 

¨      Barra del navegador: Tal como se ha expresado en secciones anteriores, para poder visualizar la interfaz del prototipo es necesario contar con un navegador, en el mismo en que se deberá escribir la URL donde se encuentre publicado el sitio web desde donde atenderá el prototipo, por ejemplo : http://MiServidorWeb/PrototipoCRM/CRM.html.

 

¨      Área de Títulos: Mostrará información descriptiva acerca del prototipo

 

¨      Botones de Conexión / Desconexión: Se utilizarán para autentificar a los usuarios del prototipo.

 

¨      Área de Menú: En esta se formará un menú de lista desplegable que se construirá dependiendo del perfil que tenga el usuario que se conecte al sistema.

 

¨      Área de mensajes: Se desplegará información de interés para el usuario.

 

¨      Área de navegación: Cada vez que se haga “click” sobre un ítem del menú se desplegará en ésta área una página HTML con la información solicitada.

 

5.3.3.8 Formato de los datos

 

Todos los datos se introducirán en cajas de texto, por lo que tendrán un formato de texto plano.

 

5.3.3.9 Formato de las órdenes

 

Sobre la interfaz del prototipo se han utilizado los siguientes elementos:

 

¨      Botones, que representan una operación, bien sea para consultar, insertar o eliminar un elemento ó bien sea para cerrar la ventana actual o acceder a otra ventana.

 

¨      Cuadros de Lista, que representan una selección de distintas opciones. Se utilizarán también para selecciones múltiples.

 

¨      Radio Buttons, que representan una operación de selección excluyente (uno u otro).

 

5.3.3.10 Mensajes Finales

 

Cuando se produzca un error en las consultas, por ejemplo el hecho de que no exista el registro o la información está corrupta, se informará al usuario. También se le informará cuando ha insertado información en un formato incorrecto en algún formulario, para así poder controlar la entrada de los campos que son propensos a errores.

 

5.3.4 FUNCIONES

 

En esta sección se detallarán las funciones implementadas en el prototipo de CRM Analítico. Estas funciones son las siguientes:

 

5.3.4.1 Definir roles de usuario

 

Esta funcionalidad permite definir los perfiles o roles existentes para los distintos usuarios del prototipo.

 

Los roles predeterminados son:

¨      Gerente

¨      Administrador

 

 

5.3.4.1.1 Interfaz preliminar

 

Figura 5.2: Interfaz preliminar pantalla de “Definición de Perfiles de Usuario”

 

5.3.4.1.2 Validación de las entradas

 

La figura 5.2 muestra la interfaz preliminar que tendrá la pantalla para “Definición de Perfiles de Usuario”. Las entradas para esta pantalla son dos campos de texto, donde se permite el ingreso de caracteres alfanuméricos, una vez que se presione el botón “Aceptar” se le ordena al sistema que procese la información a ser ingresada

 

5.3.4.1.3 Secuencia de las operaciones

 

¨      Llenar los campos de texto

¨      Presionar el botón “Aceptar”

 

 

5.3.4.1.4 Secuencia de las salidas

 

Una vez ingresados los datos, el  sistema presenta una ventana con un mensaje indicando si la información se ingresó o no.

 

5.3.4.2 Ingresar datos de usuarios

 

Se definió una pantalla para el ingreso de la información personal de los usuarios del prototipo.

 

5.3.4.2.1 Interfaz preliminar

 

Figura 5.3: Interfaz preliminar pantalla de “Ingreso de Datos de Usuarios”

 

 

5.3.4.2.2 Validación de las entradas

 

La figura 5.3 muestra la interfaz preliminar que tendrá la pantalla para “Ingreso de Datos de Usuario”. En esta pantalla cada campo es validado en su longitud y tipo de dato antes de ser enviado y procesado.

 

5.3.4.2.3 Secuencia de las operaciones

 

¨      Llenar los campos de texto

¨      Presionar el botón “Aceptar”

 

5.3.4.2.4 Secuencia de las salidas

 

Una vez ingresados los datos, el  sistema presenta una ventana con un mensaje indicando si la información se ingresó o no.

 

5.3.4.3 Cargar datos externos

 

Esta funcionalidad permite importar la información presente en las bases de datos relacionales de la compañía.

 

5.3.4.3.1 Interfaz preliminar

 

Se utilizará la herramienta “Enterprise Manager” de Microsoft SQL Server 2000, para importar la información presente en la base de datos FoodMart, la misma que viene en formato de Microsoft Access 2000. Después se ejecutarán algunos procedimientos almacenados que se encargarán de transportar esa información hasta la base de datos predestinada para el efecto.

 

 

 

 

5.3.4.3.2 Validación de las entradas

 

El proceso de importación de datos del “Enterprise Manager” se encargará de validar que la correcta carga de la información.

 

5.3.4.3.3 Secuencia de las operaciones

 

¨      Expandir el “Enterprise Manager”

¨      Seleccionar Tareas -> Importar

¨      Seguir paso a paso las instrucciones dadas por el asistente

 

5.3.4.3.4 Secuencia de las salidas

 

Al final de este proceso la herramienta muestra una pantalla donde se resumen las tablas que se cargaron en la base de datos

 

 

5.3.4.4 Segmentación geográfica de clientes

 

Esta funcionalidad permite determinar la distribución geográfica de los clientes de FoodMart en todas las ciudades donde existen dependencias de la compañía.

 

Esta distribución se hace en base a dos criterios:

 

¨      Número de Clientes: Permite ordenar a las ciudades en función del número de clientes que realizan sus compras en cada una de ellas.

 

¨      Volumen de Ventas:  Permite ordenar a las ciudades en función del volumen  de las compras realizadas por los clientes en cada una de ellas, en un periodo determinado.

 

 

5.3.4.4.1 Interfaz preliminar

 

Figura 5.4: Interfaz preliminar pantalla de “Segmentación Geográfica de Clientes”

 

5.3.4.4.2 Validación de las entradas

 

La figura 5.4 muestra la interfaz preliminar de la pantalla para “Segmentación Geográfica de Clientes”. Las entradas para esta pantalla están dadas por la selección que haga el usuario en el criterio de búsqueda (Número de clientes o volumen de compras), seguidas luego de la acción de presionar el botón “Buscar”.

 

5.3.4.4.3 Secuencia de las operaciones

 

¨      Seleccionar la opción o criterio de búsqueda

¨      Elegir la pestaña con la cual se va a trabajar

¨      Hacer click en el botón “Buscar”

 

5.3.4.4.4 Secuencia de las salidas

 

La información producto de la consulta se desplegará en el área correspondiente a la hoja Excel incrustada dentro de la pantalla.

 

 

5.3.4.5 Conformación de la Pirámide de Clientes

 

Esta funcionalidad permite obtener la segmentación de los clientes de FoodMart utilizando el criterio del volumen de compras efectuado por cada cliente en un período determinado. 

 

En ésta segmentación se ha utilizado el criterio de “Pirámide de Clientes” por considerarlo el más apropiado, para poder agrupar a toda la cartera de clientes de FoodMart en los siguientes 4 grupos:

 

¨      Clientes Superiores: El 1% con mayor participación en las compras.

 

¨      Clientes Grandes: El 4% siguiente en función del total adquirido.

 

¨      Clientes Medianos: El 15% siguiente.

 

¨      Clientes Pequeños: El 80% restante.

 

 

La pantalla cuenta con 3 viñetas, y desde un combo desplegable se podrá seleccionar un período o año fiscal para obtener los datos consolidados para la conformación de la respectiva “Pirámide de Clientes”.

 

 

 

 

 

5.3.4.5.1 Interfaz preliminar

 

Figura 5.5: Interfaz preliminar pantalla de “Conformación de la Pirámide de Clientes”

 

5.3.4.5.2 Validación de las entradas

 

La figura 5.5 muestra la interfaz preliminar que tendrá la pantalla para “Conformación de la Pirámide de Clientes”. Las entradas para esta pantalla están dadas por la selección que haga el usuario en el criterio de búsqueda seguidas luego de la acción de presionar el botón “Buscar”.

 

 

 

5.3.4.5.3 Secuencia de las operaciones

 

¨      Elegir la pestaña con la cual se va a trabajar

¨      Seleccionar el criterio de búsqueda

¨      Hacer click en el botón “Buscar”

 

5.3.4.5.4 Secuencia de las salidas

 

La información producto de la consulta se desplegará en el área correspondiente a la hoja Excel incrustada dentro de la pantalla.

 

5.3.4.6 Medición de Promociones

 

Esta funcionalidad permite comparar los gastos efectuados en una promoción versus los ingresos provenientes de la misma, para un período determinado.

 

5.3.4.6.1 Interfaz preliminar

 

Figura 5.6: Interfaz preliminar pantalla de “Medición de Promociones”

5.3.4.6.2 Validación de las entradas

 

La figura 5.6 muestra la interfaz preliminar que tendrá la pantalla para “Medición de Promociones”. Las entradas para esta pantalla están dadas por la selección que haga el usuario para escoger el año indicado en el combo desplegable ubicado en la parte superior derecha de la pantalla.

 

5.3.4.6.3 Secuencia de las operaciones

 

¨      Hacer click sobre el combo desplegable ubicado en parte superior derecha de la pantalla.

¨      Visualizar la información en la hoja Excel.

 

5.3.4.6.4 Secuencia de las salidas

 

La información producto de la consulta se desplegará en el área correspondiente a la hoja Excel incrustada dentro de la pantalla.

 

5.3.4.7 Consultar  información y hábitos de consumo de los clientes

 

Esta funcionalidad permite consultar la siguiente información de los clientes de FoodMart:

 

¨      Información personal.

 

¨      Información de tipo económico como por ejemplo su rango de ingresos anuales.

 

¨      El detalle de los consumos realizados por un cliente en particular durante un periodo determinado.

 

 

 

5.3.4.7.1 Interfaz preliminar

 

Figura 5.7: Interfaz preliminar pantalla de “Consulta de Información de Clientes”

 

5.3.4.7.2 Validación de las entradas

 

La figura 5.7 muestra la interfaz preliminar que tendrá la pantalla para “Consulta de Información de Clientes”. Cuando se carga ésta pantalla, el combo desplegable se llena con los nombres de todos los clientes, de tal modo, que la única entrada de datos que proporciona el cliente es la de escoger el cliente cuyos datos quiere consultar

 

5.3.4.7.3 Secuencia de las operaciones

 

¨      Escoger el cliente

¨      Seleccionar la pestaña

¨      Visualizar la información

 

 

 

5.3.4.7.4 Secuencia de las salidas

 

De acuerdo con la pestaña seleccionada por el usuario se presenta la información correspondiente.

 

5.3.5 REQUISITOS DE RENDIMIENTO

 

5.3.5.1 Número máximo de usuarios simultáneos

 

El número máximo de usuarios está definido por el número máximo de conexiones configurado para la base de datos, en una base de datos SQL Server el valor por defecto es 0, es decir un número ilimitado de conexiones.

 

5.3.5.2 Cantidad y tipo de información que se maneja

 

Para éste prototipo su fuente básica de información será la base de datos FoodMart la misma que cuenta con 10281 registros de clientes y cerca de 300000 registros de compras de clientes para los años 1997 y 1998.

 

5.3.6 RESTRICCIONES DE DISEÑO

 

Este prototipo partirá de cero por lo que no estará sujeto a antiguos estándares o regulaciones de otros sistemas.

 

5.3.7 ATRIBUTOS DEL SISTEMA DE SOFTWARE

 

5.3.7.1 Fiabilidad

 

Las operaciones de consulta y análisis de información deben ser consistentes para garantizarle al usuario la fiabilidad de las mismas.

 

 

 

 

5.3.7.2 Disponibilidad

 

El prototipo deberá estar disponible siempre que los servicios tanto del servidor de la base de datos como del servidor web estén levantados y corriendo.

 

5.3.7.3  Seguridad

 

La seguridad se maneja en dos niveles:

 

¨      A nivel de encriptación de información de usuarios, se emplea encriptación de passwords para garantizar que sólo sea el usuario el único que conozca el valor exacto de su clave

 

¨      A nivel de perfiles, en el prototipo se definieron perfiles de usuarios para determinar las pantallas a las que tendría acceso un usuario de acuerdo con el perfil que se le haya otorgado.

 

5.3.7.4 Portabilidad

 

El prototipo será desarrollado con las siguientes herramientas: Visual Interdev 6.0 para las páginas HTML que utiliza, Visual Basic 6.0 para elaborar un conjunto de componentes ActiveX necesarios para su funcionamiento y con Microsoft SQL Server 2000 para las bases de datos a las que accede, por lo que su portabilidad se reduce a entornos en donde la plataforma de software sea enteramente Microsoft y la plataforma de hardware sea compatible con el software que se necesita para su ejecución.

 

5.4  DISEÑO DEL PROTOTIPO

 

Para el desarrollo del proyecto CRM Explorer se ha seguido un ciclo de vida en espiral [6], por tanto el diseño ha sido refinado en cada iteración de este. El ciclo de vida utilizado se indica en la figura 5.8:

 

Figura 5.8: Ciclo de Vida en Espiral

 

 

El prototipo fue depurado durante el ciclo de vida, y en cada iteración se le ha añadido nuevas funcionalidades. Las herramientas de programación que se han usado para crear la aplicación son: Visual Interdev 6.0 para las páginas HTML que utiliza, Visual Basic 6.0 para elaborar un conjunto de componentes Actives necesarios para su funcionamiento y con Microsoft SQL Server 2000 para la bases de datos a las que accede.

 

 

 

 

 

5.4.1 IDENTIFICACIÓN DE ENTIDADES EXTERNAS

 

Las entidades externas con las que interactúa CRM Explorer son:

 

¨      Gerentes: Los accionistas de la organización, se conectan a la aplicación para obtener informes relativos al éxito o fracaso de las promociones, así como todos los reportes generados por el CRM Analítico.

 

¨      Ventas: La aplicación necesita acceder a todos los detalles de las ventas realizadas a los clientes de FoodMart.

 

¨      Empleados: Eventualmente diferentes empleados de la organización podrían conectarse a la aplicación para solicitar o actualizar la información de los clientes.

 

¨      Administrador del sistema: Será el encargado de mantener actualizados los catálogos y datos generales de la aplicación.

 

¨      Clientes: La aplicación necesita alimentarse con los datos de los clientes de la organización para poder generar los reportes requeridos por los gerentes.

 

¨      Productos: La aplicación necesita alimentarse con los datos del catálogo de productos de la organización para contar con la información necesaria para elaborar algunos de los reportes que genera, como por ejemplo el reporte de hábitos de consumos de clientes.

 

¨      Promociones: La información de las diferentes campañas promocionales de marketing deberá estar disponible para que la aplicación pueda medir el resultado de cada una ellas en un período determinado.

 

5.4.2 DIAGRAMA DE CONTEXTO

 

Para el diseño de la aplicación se elaboró el correspondiente diagrama de contexto que indica las interacciones del sistema con cada de las entidades externas. Como se puede observar, existen siete entidades externas, que serán:

 

¨      Los gerentes de la organización quienes usan la aplicación para obtener datos consistentes acerca de los clientes y las interacciones que mantienen con la empresa.

 

¨      Los empleados quienes requieren datos de los clientes y eventualmente pueden actualizar la información o datos de los clientes.

 

¨      Los clientes quienes por medio de las interacciones que mantienen con la empresa proporcionan datos relevantes de si mismos.

 

¨      El departamento de ventas que proporcionará los datos de las adquisiciones realizadas por los clientes.

 

¨      El administrador del sistema que será el encargado de interactuar con la aplicación para mantener actualizada la información de los catálogos y demás datos necesarios para el correcto funcionamiento de la aplicación.

 

¨      El catálogo de productos, al que será necesario acceder para la elaboración de los reportes de la aplicación.

 

¨      La información de las promociones de marketing llevadas a cabo por la organización, la misma que cruzada con los datos de ventas servirá para poder medir cuáles fueron las campañas promocionales que resultaron éxitosas económicamente para la organización.

 

La figura 5.10 muestra el DFD de Nivel 1, elaborado para comprender mejor el funcionamiento interno del sistema de CRM, que expone la funcionalidad del prototipo a nivel de subsistemas y la interacción de las entidades externas con  los módulos del sistema.

 

En el gráfico también pueden observarse los componentes Operacional, Analítico y Colaborativo que constituyen a un CRM, así como las interacciones existentes entre cada uno de ellos.

 

Así tendríamos que:

 

¨      El CRM Operacional se encargaría de la interacción directa entre el prototipo de CRM y los clientes de la organización, proporcionándoles información de productos y/o servicios, y receptaría de los mismos sus datos personales, las quejas o sugerencias y hasta podría encargarse de atender sus requermientos de compras.

 

¨      EL CRM Colaborativo actuaría como un nexo entre la aplicación de CRM y los demás aplicativos corporativos,  receptando, actualizando y transmitiendo la información de los clientes hacia cada uno de los posibles destinatarios dentro de la organización.

 

¨      Finalmente el CRM Analítico es el verdadero núcleo de la aplicación de CRM, puesto que recibiría y analizaría la información de ventas, productos, clientes, promociones, etc y por medio de un análisis cruzado de estos datos podría elaborar estadísticas referentes a: Segmentación de clientes, Éxito de Promociones, Estándares de atención, Hábitos de Consumo de clientes, etc.

 

Entranto en detalles, es necesario que el DFD de Nivel 1 sea explosionado para cada uno de los módulos de la aplicación, sin embargo por restricciones de tiempo y diseño se explotará únicamente el componente de CRM Analítico como se muestra a continuación:

La figura 5.11 muestra la explosión del DFD de Nivel 1, en el primer DFD de Nivel construido para el Módulo de CRM Analítico, en la figura se detallan las principales funcionalidades que deberá tener el prototipo a implementarse.

 

No se muestran DFD’s para los módulos CRM Operacional y CRM Colaborativo, puesto que estos módulos no serán desarrollados, en detalle, para el presente alcance de éste trabajo.

 

5.5  DISEÑO DE OBJETOS Y COMPONENTES DEL SISTEMA

 

 

Para el correcto desarrollo de la solución propuesta, es necesario establecer el diseño arquitectónico de la misma en función de los módulos o subsistemas determinados en el punto 5.4.2.

 

El diseño arquitectónico debe proporcionar una mejor orientación con respecto a la manera en la que se comportará el prototipo de CRM Explorer una vez construido. “Su objetivo primario es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. Además, el diseño arquitectónico combina la estructura del programa y las estructuras de datos” [6].

 

La figura 5.12 muestra las interacciones entre cada uno de los módulos y los componentes de los mismos a nivel macro.

Figura 5.12: Arquitectura de la Solución

 

La figura 5.12 muestra los diferentes módulos que van a componer al prototipo CRM Explorer, en ella pueden verse los componentes que tendrá el mismo. A nivel macro estos componentes son:

 

¨      Bases de datos transaccionales: Se asume la existencia previa de BDD’s transaccionales que contienen, por ejemplo, la información de ventas y de clientes de la organización.

 

¨      Programas de Extracción, conversión y carga de información: Dadas las características del prototipo estos programas serán básicamente un conjunto de procedimientos almacenados que se encargarán de formatear la información, que existe previamente, para poder cargarla sin mayor problema hacia la estructura de datos definida expresamente para el prototipo de CRM.

 

¨      BDD de CRM: Es necesario establecer una estructura de datos propia para ser usada por el prototipo, de tal modo que las consultas y operaciones de los usuarios sean realizadas directamente sobre estas estructuras.

 

¨      Programas de Análisis y Minería de Datos: Fundamentalmente se recurrirá al empleo de procedimientos almacenados que permitirán realizar el análisis y minería de datos de la información presente en la base de datos del CRM, y serán los encargados de transmitir estos resultados hacia el Front End de la aplicación.

 

¨      Manejador de Conexiones a la BDD: Se construirá una aplicación “dll” que se usará para manejar las conexiones a la base de datos disparadas desde el Front End, en cierta forma establece un primer nivel de seguridad puesto que ninguno de los componentes de la aplicación podrá conectarse a la base sin hacer uso de la dll de conexión.

 

¨      Autentificador de Usuarios y Seguridades: Se definirá una estructura jerárquica de perfiles de usuario para poder establecer el menú que debe tener cada usuario una vez que se logee al sistema. Adicionalmente se empleará una dll para encriptar y validar la información de passwords y logines de los usuarios de la aplicación.

¨      Front End Empresarial: Para presentar la información a los usuarios del prototipo se construirá un web site dentro de la Intranet corporativa de tal modo que será posible acceder a la aplicación utilizando un navegador de internet.

 

5.5.1 DISEÑO DE LA BASE DE DATOS

 

Para el diseño de la BDD de CRM Explorer se utilizó la herramienta PowerDesigner, la misma que además del modelamiento de los datos, permite la generación del correspondiente script de instalación de la BDD.

 

Las tablas que componen a la BDD de CRM Explorer son las siguientes

 

¨      CRM_CALENDARIO: Guarda un calendario día a día para poder cruzar la información de compras y obtener la fecha y día exacto en el que fueron realizadas las mismas.

 

¨      CRM_CATALOGO: Se emplea para almacenar los diferentes catálogos empleados en la aplicación. Por ejemplo, para el catálogo “Sexo”, se guardarían los valores: “M-Masculino” y “F-Femenino” .

 

¨      CRM_CIUDAD: La información de las ciudades, donde la organización mantiene dependencias es almacenada en esta tabla.

 

¨      CRM_CLIENTE: Los datos de cada uno de los clientes de la organización son guardados en esta tabla para su posterior consulta y uso por parte del prototipo.

 

¨      CRM_COMPRAS_CLIENTES: El resumen de las compras realizadas por los clientes en un periodo determinado se lo obtiene de la información de ventas y se lo coloca en esta tabla para que este a disposición de los usuarios del prototipo.

 

¨      CRM_DEPARTAMENTO: Se emplea para guardar un listado de los departamentos de la organización que interactuarán con el prototipo.

 

¨      CRM_HABITOS_CONSUMO: El resumen del comportamiento del cliente con respecto a sus hábitos de consumo se trasporta a esta tabla para su posterior visualización en el prototipo.

 

¨      CRM_LOCAL: Se emplea para almacenar el listado de las dependencias o locales de la organización en cada una de las ciudades.

 

¨      CRM_LOGGER: Se utiliza para llevar un control de los usuarios que se conectan a la aplicación.

 

¨      CRM_MEDICION_PROMOCION: Sirve para cruzar los datos de las campañas promocionales de marketing versus la información de ventas y establecer así cuáles fueron las promociones que obtuvieron un éxito o fracaso dependiendo de la aceptación de los clientes hacia el producto promocionado.

 

¨      CRM_MENU: El listado de menús disponibles para los usuarios del prototipo se obtiene de esta tabla.

 

¨      CRM_PANTALLA: Se emplea para establecer a que pantallas tendrán acceso los usuarios en función del rol que tengan para el sistema.

 

¨      CRM_PIRÁMIDE: El resultado de la conformación de la pirámide de clientes de la organización es consultado desde esta tabla.

 

¨      CRM_PRODUCTO: Se emplea para mantener un catálogo de los productos ofertados por la organización.

 

 

 

¨      CRM_PROMOCION: Se emplea para mantener disponible la información de las campañas promocionales de marketing.

 

¨      CRM_REGION: Las regiones geográficas donde la organización tiene presencia física son consultadas desde esta tabla.

 

¨      CRM_ROL: El listado de roles o perfiles que tendrán los usuarios es almacenado en esta tabla.

 

¨      CRM_SEGMENTO_GEOGRAFICO: Una vez realizada la segmentación geográfica de los clientes, los resultados son almacenados en esta tabla.

 

¨      CRM_TABLA: Se emplea para mantener el listado de las tablas de catálogos de la aplicación.

 

¨      CRM_USR_TAREAS: Se emplea para informarle al usuario de sus tareas pendientes en el sistema.

 

¨      CRM_USUARIO: Los datos de los usuarios de la aplicación se guardan en esta tabla.

 

 

A continuación en la figura 5.13 se muestra el modelo conceptual de CRM Explorer, en el diagrama pueden observarse todas las tablas que conformarán a la base de datos de la aplicación.

 

5.5.2 DISEÑO DEL FRONT END DE LA APLICACIÓN

 

CRM Explorer se implementará para que funcione dentro de la Intranet corporativa de la compañía ficticia FoodMart, de tal modo que el front end de la aplicación estará constituido por un conjunto de páginas webs y ocx’s, los mismos que deberán soportar la lógica de funcionamiento determinada para el prototipo.

 

La estructura prevista para cada una de las páginas de la aplicación es la siguiente:

 

<HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0"> <TITLE></TITLE> </HEAD> ********************************************************************************************************* Cuerpo de la página ********************************************************************************************************* <BODY> Llamada a objeto contenedor del ocx <OBJECT ID="UserPiramideClientes" CLASSID="CLSID:B5E549B8-3706-44E4-B49B-464BF8E670C2" CODEBASE=url/Ocx/NombreOcx/Paquete/NombreOcx.CAB#version=1,0,0,0> </OBJECT> Fin llamada a objeto contenedor del ocx ******************************************************************************************************** </BODY> </HTML>

 

La estructura del sitio web que se construirá para la aplicación es la siguiente:           

Figura 5.14: Estructura del Sitio Web de CRM Explorer

 

Donde:

 

¨      Directorio Base: Es el directorio que deberá crearse en el servidor web para la publicación del sitio web de la aplicación. Como se trabajará en un ambiente Microsoft, este directorio base debe crearse dentro del directorio “Inetpub/wwwroot”, para el caso específico de este desarrollo, este directorio se llamará “TesisCRM”.

 

¨      Images: Es el directorio donde se ubicarán las imágenes utilizadas en las páginas HTML de la aplicación.

 

¨      OCX: En este directorio se construirá una carpeta por cada OCX necesaria para el funcionamiento de la aplicación.

 

Se construirá una aplicación central o esqueleto, la misma que tendrá la lógica de conexiones y validaciones de usuario contra la base de datos, y desde la cual se implementarán llamadas a cada una de las funcionalidades dispuestas para la aplicación.

 

La figura 5.15 muestra la Interfaz de Usuario que tendrá está aplicación central.

 

Figura 5.15: Pantalla de la Interfaz de Usuario de la Aplicación Central de CRM Explorer

 

Cada una de las OCX, que componen a la aplicación, contará con la siguiente estructura:

Figura 5.16: Estructura de las OCX componentes de la aplicación

 

Como puede observarse en la figura 5.16 cada una de las OCX, componentes de la aplicación, tendrá las siguientes partes:

 

¨      Páginas de propiedades: El archivo ProPage.pag expondrá un conjunto de propiedades configurables para cada uno de los objetos.

 

¨      Controles de Usuarios: Para una OCX el “User Control” es la interfaz que expone el objeto cuando es invocado por una aplicación externa, generalmente una OCX toma el mismo nombre de su “User Control”.

 

¨      Módulos: Las OCX de la aplicación tendrán dos módulos con funciones y variables globales. El primero “modVariables.bas” tendrá un conjunto de variables y funciones globales comunes para todos los componentes del control. El segundo módulo de nombre “modSubMain.bas” implementará funciones que permitan marcar al control como “seguro”  para permitir su ejecución y funcionamiento en el navegador o browser de Internet.

 

¨      Formularios: Algunos de los controles contarán con uno o varios formularios adicionales, dependiendo de la funcionalidad que se implemente en ellos.

 

5.6  IMPLEMENTACIÓN

 

Tal como se lo indicó en secciones anteriores, el alcance de éste desarrollo se limitará a la construcción del componente analítico del CRM, las subsecciones siguientes mostrarán la manera como fueron implementados las distintas partes del prototipo de CRM Analítico.

 

5.6.1 IMPLEMENTACIÓN DEL SUBMÓDULO DE CONEXIONES

 

Para manejar las conexiones a la BDD se desarrolló una dll, la misma que es instanciada desde el evento “Iniciatilize” en cada uno de los componentes que hacen parte de la aplicación. Esta dll fue desarrollada utilizando Visual Basic 6.0 y su codificación se presenta a continuación:

 

Archivo: SQLConexion.dll

Función Conexión (Conexión): Se encarga de establecer la conexión entre el objeto y la base de datos. Recibe como parámetros los siguientes argumentos: Nombre del Servidor Login de Usuario de la base de datos Password de Usuario de la base de datos Nombre de la base de datos a la que se conectará la aplicación     Public Function Conexion(ByVal Con_Server As String, ByVal Con_User As String, ByVal Con_Password As String, ByVal Con_Base As String) As ADODB.Connection On Error GoTo LocalErrorHandler Dim Con_Conexion As String    Con_Conexion = "DRIVER={SQL Server};"  Con_Server = "SERVER=" & Con_Server & ";"  Con_User = "UID=" & Con_User & ";"  Con_Password = "PWD=" & Con_Password & ";"  Con_Base = "DATABASE=" & Con_Base    Con_Conexion = Con_Conexion & Con_Server & Con_User & Con_Password & Con_Base    Set SQL_Conexion = New ADODB.Connection  SQL_Conexion.ConnectionString = Con_Conexion  SQL_Conexion.ConnectionTimeout = 30  SQL_Conexion.Open   Con_Error = Err.Number Conex_Status = Con_Status   Set Conexion = SQL_Conexion      LocalErrorHandler:     Con_Error = Err.Number     Conex_Status = Con_Status    Exit Function   End Function

Función Desconexión (Desconexion): Se encarga de dar por finalizada la conexión entre el objeto y la base de datos. No requiere parámetros.   Public Function Desconexion() As Integer  SQL_Conexion.Close  Desconexion = 0 End Function

Función Estatus (Con_Status): Se encarga de devolver el estatus o estado actual de la conexión entre el objeto y la base de datos. No requiere parámetros.   Public Function Con_Status() As Long   Con_Status = Con_Error End Function

Función Validar Conexión (Val_Conexión): Se encarga de validar que los datos de conexión sean correctos. Emplea los mismos parámetros indicados en la función Conexión.   Public Function Val_Conexion(ByVal Con_Server As String, ByVal Con_User As String, ByVal Con_Password As String, ByVal Con_Base As String) As Long On Error GoTo LocalErrorHandler Dim Con_Conexion As String    Con_Conexion = "DRIVER={SQL Server};"  Con_Server = "SERVER=" & Con_Server & ";"  Con_User = "UID=" & Con_User & ";"  Con_Password = "PWD=" & Con_Password & ";"  Con_Base = "DATABASE=" & Con_Base    Con_Conexion = Con_Conexion & Con_Server & Con_User & Con_Password & Con_Base    Set SQL_Conexion = New ADODB.Connection  SQL_Conexion.ConnectionString = Con_Conexion  SQL_Conexion.ConnectionTimeout = 30  SQL_Conexion.Open    Con_Error = Err.Number  Conex_Status = Con_Status  SQL_Conexion.Close  Val_Conexion = 0      LocalErrorHandler:     Con_Error = Err.Number     Conex_Status = Con_Status     Val_Conexion = Con_Status     Exit Function   End Function

 

5.6.2 IMPLEMENTACIÓN DEL SUBMÓDULO DE SEGURIDADES

 

La seguridad para el prototipo CRM Explorer se manejará a dos niveles:

 

¨      Nivel de Personalización de Menú de Usuarios: Cada usuario del sistema contará con un login, un password y un perfil de usuario, de tal modo que el menú que le presente la aplicación se forma dinámicamente en función del rol del usuario en el sistema, con esto se garantiza que los distintos usuarios tengan acceso únicamente a la información que le corresponda de acuerdo con sus funciones.

 

¨      Encriptación de información:  Para el almacenamiento de información crítica como logines y passwords de usuarios se emplea una “dll” para que ésta información se almacene encriptada en la base de datos.

 

5.6.2.1 Nivel de Personalización de Menú de Usuarios:

 

El prototipo CRM Explorer emplea la tabla “crm_pantalla” para construir un menú de usuarios personalizado en función del login o rol del usuario en el sistema.

 

 

Donde:

¨      pan_id : Se emplea para notar el secuencial o identificador de la pantalla.

 

¨      ro_id: Se emplea para indicar el ID del rol que tendrá acceso a esa pantalla. En la tabla anterior pueden verse todos las pantallas a las que tendrá acceso un usuario cuyo ID de rol sea 1.

 

¨      pan_cod_interno: Cada submenú cuenta con un secuencial interno para indicar el número de pantallas que le pertenecen. Por ejemplo, en la tabla anterior puede verse que para el menú “CRM...” se tendrán 5 pantallas.

 

¨      pan_menu: Nombre del menú que aparecerá en la pantalla principal del usuario.

 

¨      pan_nombre: Nombre de la opción de menú que aparecerá en el menú desplegable del usuario.

 

¨      pan_path:  Nombre o ubicación del archivo físico que contiene al “ocx” donde se visualizará la pantalla.

 

5.6.2.2 Encriptación de información

 

Para encriptar la información de logines y passwords CRM Explorer emplea la dll pública “Cast.dll” tomada del sitio web http://www.paipai.net. Esta dll, escrita en el lenguaje Visual Basic, provee un conjunto de rutinas para encriptar y desencriptar información, en los anexos que acompañan al presente trabajo se incluirá la documentación técnica donde se muestra el uso de esta dll.

 

Como clave de entrada para encriptar o desencriptar información, se empleará combinadamente el ID y el login del usuario. La forma de uso de la dll es la siguiente:

 

1) En el objeto central o esqueleto de la aplicación se incluye la siguiente declaración:                       Set Crypto = CreateObject("cast.cipher") Esto crea una nueva instancia de dll

2)  Se realiza una consulta a la BDD para traer los datos del usuario:   Cad_Conex = "select usr_nombre, usr_apellido, usr_id, usr_login,usr_clave,ro_id from crm_usuario" Cad_Conex = Cad_Conex + " where usr_login = '" & Cad_User & "'"

3) Se forma la clave para encriptar / desencriptar la información con los datos recuperados de la consulta:   Key = Trim(rst.Fields(3)) + Trim(rst.Fields(2)) PassCripto = Trim(rst.Fields(4)) PassCripto = Crypto.cast128decode(Key, PassCripto)

4) Los datos desencriptados, recuperados de la BDD, son comparados con la información ingresada por el usuario para validar que sean correctos y permitir o no el ingreso al sistema:   If lg_login = Cad_User And PassCripto = Cad_Pwd Then         lbldata.Caption = "Validado Ok"         cn_estatus = 1 'Conectado         lg_rol = LTrim(RTrim(rst(5)))         cn_login = rst(2) 'id del login      Else        lbldata.Caption = "Error en conexión"        cn_estatus = 0 'No conectado        Cad_Welcome = "Bienvenido: "        MsgBox "Usuario o Clave Incorrecto: No es posible establecer comunicación con el servidor" End If

 

5.6.3 IMPLEMENTACIÓN DEL BACK END DE LA APLICACIÓN

 

Como se mostró en la figura 5.12, el Back End está constituido básicamente por elementos como procedimientos almacenados y disparadores (triggers) que son empleados para la carga de información y para efectuar el análisis y minería de los datos para preparar su presentación hacia los usuarios del prototipo.

 

5.6.3.1 Programas de extracción y carga de información

 

Se implementaron los siguientes procedimientos almacenados para la carga de datos en la base de datos del CRM:

 

¨      sp_carga_cliente.sp: Este procedimiento almacenado se encarga de formatear los datos de los clientes para poder cargar esta información a la base de datos del CRM. Los datos son tomados desde la base de datos de ejemplo FoodMart y son transportadas hacia la tabla crm_cliente ubicada en la base de datos “crm_explorer”.

 

¨      sp_carga_compras_cliente.sp: Este procedimiento almacenado barre las tablas “'FoodMart..sales_fact_1997'” y “'FoodMart..sales_fact_1998'” de la base de datos “FoodMart” y luego carga esta información en la tabla “crm_explorer..crm_compras_clientes” de la base de datos “crm_explorer”.

 

¨      sp_carga_promocion.sp: Este procedimiento almacenado se emplea para cargar la información de las diferentes promociones de productos de la empresa ficticia FoodMart.

 

¨      sp_carga_producto.sp: Este procedimiento almacenado se emplea para cargar la información de los diferentes productos de la empresa ficticia FoodMart

 

5.6.3.2 Programas de análisis y minería de datos

 

Se implementaron los siguientes procedimientos almacenados para el análisis y minería de datos en la base de datos del CRM:

 

¨      sp_medicion_promocion.sp: Este procedimiento almacenado se encarga de verificar los gastos realizados en cada una de las distintas promociones y compara este valor versus los ingresos generados por las compras de los clientes que tengan relación con una promoción en particular para poder determinar, en términos simples, si la promoción fue un éxito o un fracaso.

 

¨      sp_habitos_consumo.sp: Este procedimiento almacenado se emplea para obtener un breve resumen de los hábitos de consumo de los clientes de la organización, como por ejemplo su local  y día de la semana favorito para realizar sus compras.

 

¨      sp_segmentacion_geografica.sp: Este procedimiento almacenado se emplea para obtener un resumen de la densidad o distribución poblacional de los clientes de la organización.

 

¨      sp_piramide_cliente.sp: Este procedimiento almacenado se emplea para elaborar la “Pirámide de Clientes” de la empresa FoodMart. Los clientes son clasificados en la pirámide en función de los ingresos que generan para la organización.

 

5.6.4 IMPLEMENTACIÓN DEL FRONT END DE LA APLICACIÓN

 

Cada componente de la interfaz ha sido implementado como una OCX independiente y a continuación se listan cada una de ellas:

 

 

¨      CRMExplorer.ocx: Contine la Interfaz Central de la Aplicación y las funciones para la construcción del menú personalizado del usuario.

 

¨      prjSegGeografica.ocx: Contiene las funciones para consultar la información de la Segmentación Geográfica de los Clientes de FoodMart.

 

¨      PrjPiramideClientes.ocx: Permite desplegar la información de la clasificación de la Pirámide de Clientes de FoodMart.

 

¨      prjPromo.ocx:   Permite obtener los datos de los resultados de ventas generados por las promociones de FoodMart en un período determinado.

 

¨      RelCliente.ocx: Permite consultar la información de los clientes de FoodMart.

 

¨      prjRol.ocx:         Permite definir los perfiles o roles que tendrán los usuarios de la aplicación.

 

¨      prjUsuario.ocx: Permite ingresar los datos de cada uno de los usuarios de la aplicación.

 

¨      prjPantalla.ocx: Permite ingresar la información de cada una de las pantallas que tendrán disponibles los usuarios del prototipo.

 

¨      prjDepartamento.ocx: Permite ingresar la información de los departamentos de la organización que tendrán acceso a la aplicación.

 

 

 

 

 

Esta obra está licenciada bajo licencia Creative Commons de Reconocimiento-No comercial-Sin obras derivadas 2.5