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:
- Hardware y software de producción.
-
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. -
Hardware y software de pruebas y
preparación. -
Gastos de mantenimiento (ambientes de
producción y de prueba). -
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.
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.
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:
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
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:
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.
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>
Cuerpo de la página
Llamada a objeto contenedor
|
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:
|
|
|
|
|
Public Function
On
Dim
Con_Conexion
Con_Server =
Con_User = «UID=» &
Con_Password =
Con_Base =
Con_Conexion =
Set
Con_Error =
Set
Exit
End |
|
|
|
Public SQL_Conexion.Close Desconexion = 0
End |
|
|
|
Función Estatus
Public
End Function |
|
|
|
Función Validar
Public
On
Dim
Con_Conexion
Con_Server =
Con_User = «UID=» &
Con_Password =
Con_Base =
Con_Conexion =
Set
Val_Conexion
LocalErrorHandler:
Con_Error =
End |
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.
|
|
|||||
|
|
|||||
|
|
|
|
|
|
|
|
1 |
1 |
1 |
|
Administrar Base |
BDDAdmin.htm |
|
2 |
1 |
2 |
|
Ingreso de |
Usuarios.htm |
|
3 |
1 |
3 |
|
Ingreso de |
Clientes.htm |
|
4 |
1 |
4 |
|
Ingreso de |
Productos.htm |
|
5 |
1 |
5 |
|
Ingreso de |
|
|
6 |
1 |
6 |
|
Ingreso de |
Promociones.htm |
|
7 |
1 |
1 |
CRM… |
Datos de |
DatCliente.htm |
|
8 |
1 |
2 |
CRM… |
Pirámide de |
Piramide.htm |
|
9 |
1 |
3 |
CRM… |
Medición de |
Promocion.htm |
|
10 |
1 |
4 |
CRM… |
Segmentación |
Segmentacion.htm |
|
11 |
1 |
5 |
CRM… |
DataMining – |
CRMAnalitico.htm |
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
Esto crea una nueva instancia de dll |
|
2) Se realiza una consulta a la BDD
Cad_Conex = «select
|
|
4) Los datos
|
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.
1
Dirección electrónica: http://www.imt.com.mx/
