CRM: DESARROLLO DEL PROTOTIPO DE eCRM

0
48289

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 c
ada
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.

 



Tabla:


crm_pantalla


 


 



pan_id


 


 



ro_id


 



pan_cod_interno


 



pan_menu


 



pan_nombre


 



pan_path

1

1

1


Administración…

Administrar Base
de Datos

BDDAdmin.htm

2

1

2


Administración…

Ingreso de
Usuarios

Usuarios.htm

3

1

3


Administración…

Ingreso de
Clientes

Clientes.htm

4

1

4


Administración…

Ingreso de
Productos

Productos.htm

5

1

5


Administración…

Ingreso de
Departamentos


Departamentos.htm

6

1

6


Administración…

Ingreso de
Promociones

Promociones.htm

7

1

1

CRM…

Datos de
Clientes

DatCliente.htm

8

1

2

CRM…

Pirámide de
Clientes

Piramide.htm

9

1

3

CRM…

Medición de
Promociones

Promocion.htm

10

1

4

CRM…

Segmentación
Geográfica

Segmentacion.htm

11

1

5

CRM…

DataMining –
Cubo de Información

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
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.

 

 

 



1

Dirección electrónica:  http://www.imt.com.mx/

 

 

Dejar respuesta

Please enter your comment!
Please enter your name here