foros) diana marcela archila dirección: jorge a
TRANSCRIPT
DISEÑO E IMPLEMENTACIÓN TRANSVERSAL DE PROCESOS DE NEGOCIO DE SERVICIO AL CLIENTE PARA UN MARKETPLACE
(Procesamiento de solicitudes PQRS, monitoreo de correo, creación de notificaciones y foros)
Diana Marcela Archila [email protected]
Dirección: Jorge A. Villalobos, Ph.D. [email protected]
Colaboración especial: Laura C. Manzur V., M.Sc. [email protected]
MarketPlace de Los Alpes Grupo Empresarial de Los Alpes
Laboratorio de Arquitectura Empresarial
Bogotá, Enero 2013
TABLA DE CONTENIDO I. Lista de ilustraciones................................................................................................................ 4
II. Resumen .................................................................................................................................... 5
1. Introducción .............................................................................................................................. 6
2. Objetivos .................................................................................................................................... 8
2.1. Objetivo General ................................................................................................................... 8
2.2. Objetivos Específicos............................................................................................................ 8
3. Contexto ..................................................................................................................................... 9
3.1. Arquitectura empresarial (AE) ........................................................................................... 9
3.2. Metodologías de arquitectura empresarial ..................................................................... 11
3.3. TOGAF ................................................................................................................................. 12
3.4. Laboratorio de Arquitecturas Empresariales – Universidad de los Andes ............... 14
3.5. MarketPlace de los Alpes (MPLA) ................................................................................... 15
3.6. Procesos de Servicio de al Cliente .................................................................................... 17
3.7. CRM (Customer Relatioship Management) ................................................................... 18
4. Análisis y Diseño de la solución ........................................................................................... 19
4.1. Proceso de gestión de pqrs ................................................................................................ 20
4.2. Proceso de gestión de monitoreo de correos de servicio al cliente ............................. 21
4.3. Proceso de gestión de publicaciones en el foro de MPLA ............................................ 22
4.4. Análisis y Diseño de la Arquitectura Empresarial Objetivo del MPLA ..................... 23
ARQUITECTURA DE NEGOCIO ................................................................................................ 24
ARQUITECTURA DE DATOS .................................................................................................... 25
ARQUITECTURA DE APLICACIONES ....................................................................................... 28
ARQUITECTURA TECNOLÓGICA ............................................................................................. 29
ARQUITECTURA DE SOLUCIÓN............................................................................................... 30
5. Implementación y resultados ............................................................................................... 32
5.1. Entorno de Desarrollo ........................................................................................................ 32
5.2. Equipo de Trabajo del MPLA ........................................................................................... 33
5.3. Estrategia de desarrollo y resultados .............................................................................. 34
VISTA TOTAL ............................................................................................................................ 35
6. Validación ................................................................................................................................ 45
7. Conclusiones ........................................................................................................................... 46
7.1. Discusión ............................................................................................................................. 46
7.2. Trabajo Futuro .................................................................................................................... 46
8. Bibliografía .............................................................................................................................. 48
9. Anexos ..................................................................................................................................... 49
9.1. Anexo No.1 Análisis y diseño de arquitectura empresarial y procesos ..................... 49
I. LISTA DE ILUSTRACIONES
Ilustración 1 DIMENSIONES DE TOGAF ............................................................................................. 10
Ilustración 2 COMPARACIÓN DE LAS CUATRO METODOLOGÍAS DE ARQUITECTURA
EMPRESARIAL MAS DESTACADAS .................................................................................................... 12
Ilustración 3 DIAGRAMA POR CAPAS DE LA ARQUITECTURA TECNOLÓGICA DEL
MPLA .............................................................................................................................................................. 17
Ilustración 4 CADENA DE VALOR MPLA ........................................................................................... 24
Ilustración 5 DIAGRAMA BPMN DEL SUBPROCESO GESTIÓN DE MONITOREO DE
CORREOS DE SERVICIO AL CLIENTE ................................................................................................. 25
Ilustración 6 Modelo de entidades del MPLA ...................................................................................... 26
Ilustración 7 Modelo Estrella Genérico de los KPI .............................................................................. 27
Ilustración 8 DIAGRAMA DE COOPERACIÓN DE APLICACIONES MPLA ............................. 28
Ilustración 9 DIAGRAMA POR CAPAS DE LA ARQUITECTURA TECNOLÓGICA DEL
MPLA .............................................................................................................................................................. 30
Ilustración 10 BLUEPRINT ARQUITECTURA MPLA ........................................................................ 31
Ilustración 11 11 DIAGRAMA DE DESPLIEGUE DE DESARROLLO DEL MPLA ..................... 32
Ilustración 12 VISTA TOTAL MPLA ...................................................................................................... 35
Ilustración 13 REPORTE DE SOLICITUDES TOTALES POR TIPO DE CLIENTE CRM OD .... 37
Ilustración 14 PROCESO DE GENERACIÓN DE QUEJAS ............................................................... 39
Ilustración 15 Proceso de atención de solicitudes ............................................................................... 40
Ilustración 16 REPORTE ESTADO NOTIFICACIONES ..................................................................... 41
Ilustración 17 ENVIAR QUEJA MPLA PORTAL WEB ....................................................................... 43
Ilustración 18 VER NOTIFICACIONES MPLA PORTAL WEB ........................................................ 43
Ilustración 19 ACTUALIZAR NOTIFICACIÓN MPLA PORTAL WEB ......................................... 44
II. RESUMEN
Este documento muestra los resultados obtenidos a partir del desarrollo de un proyecto de
implementación de procesos de negocio. Este se llevó a cabo en el contexto del Laboratorio
de Arquitectura Empresarial de la Universidad de los Andes (LAE), con el objetivo de
brindar a los estudiantes escenarios asociados a las verticales de negocio de tal forma que
se tenga un acercamiento con la implementación de procesos fundamentales en las
organizaciones, así como facilitar el entrenamiento con las principales herramientas
tecnológicas que están liderando en mercado.
El proyecto se realizó sobre el escenario del Marketplace de los Alpes (MPLA), uno de los
escenarios que conforma el laboratorio de arquitectura empresarial. MPLA es una
plataforma que permite hacer transacciones de negocio entre fabricantes (o proveedores) y
comercializadoras de productos (comercios). Sin embargo en el área de servicio al cliente
aún no se han desarrollado los procesos principales, es por esto que por medio del análisis,
diseño e implementación en las cuatro dimensiones de la arquitectura (datos,
aplicaciones, infraestructura y negocio), se integraron y automatizaron los procesos
gestión de solicitudes PQRs, gestión de seguimiento de correos de servicio al cliente y
gestión de publicaciones en foros. Para este último proceso solo se realizó el análisis y
diseño de la arquitectura empresarial y de solución.
El desarrollo del proyecto se inició con un análisis de la situación actual de la empresa,
para esto se siguió como metodología TOGAF por su robustez y reconocimiento en la
industria. A continuación se introducen los nuevos procesos de negocio a implementar
mostrando el nuevo diseño de arquitectura empresarial incluyendo las cuatro vistas
principales (Negocio, Aplicaciones, Datos y Tecnología). Con la etapa anterior también se
muestra cómo el diseño inicial es impactado y siguiendo con el desarrollo del proyecto se
hace una consolidación de las principales decisiones de diseño que se tomaron para llevar
cabo la implementación de dichos procesos. Para finalizar, luego de hacer una validación
transversal de la implementación realizada por medio de pruebas funcionales y unitarias,
se muestran las conclusiones más relevantes obtenidas como resultado de todo el ejercicio
de diseño e implementación y se exponen algunas oportunidades que se podrían realizar
como trabajo futuro para enriquecer el escenario.
1. INTRODUCCIÓN
Con la evolución de la tecnología se han habilitado nuevas capacidades en el área de
tecnologías de información TI que permiten hacer más eficientes los procesos en las
organizaciones. Anteriormente en las empresas existía un departamento de sistemas, que
soportaba algunas labores asociadas al mantenimiento de los equipos y sistemas de
información de la compañía, pero no había un soporte transversal de los procesos y en
general de la operación de la empresa. Sin embargo, la complejidad al interior de las
mismas organizaciones ha llevado a tener cada vez procesos y estructuras mas complejas
que necesitan tener una infraestructura tecnología lo suficientemente completa de tal
forma que no se vea comprometida ni la competitividad y ni la continuidad del negocio.
La falta de alineación entre el negocio y TI da como resultado un desperdicio significativo
de recursos y oportunidades, que muchas veces colocan a las organizaciones en desventaja
con la competencia en el mercado. Es por esto necesario alinear las estrategias de negocio
con TI, y la Arquitectura Empresarial (AE) es un enfoque de gestión de TI que permite
lograr este objetivo.
Identificando la necesidad de tener personas con conocimiento en este campo la
Universidad de los Andes a través del Departamento de Ingeniería de Sistemas y
Computación, creo un espacio dirigido al desarrollo de metodologías y escenarios que
permitan a los estudiantes diseñar e implementar proyectos de arquitectura empresarial,
tomando como base unos escenarios virtuales que representan las principales verticales de
negocio. El MarketPlace de los Alpes es uno de estos escenarios sobre el cual se llevó a
cabo el diseño e implementación de una solución de arquitectura empresarial para la
generación de solicitudes PQRS, seguimientos de correo electrónico de servicio al cliente y
el diseño de arquitectural empresarial para la gestión de publicaciones en foros.
La estructura del documento consta de una parte inicial en donde se definen los objetivos
generales y específicos del proyecto, apoyado por un contexto que enmarca las principales
definiciones y conceptos claves para entender el desarrollo y metodología del mismo.
Seguido de esto se profundiza acerca de la solución propuesta y las principales decisiones
que se tomaron durante la etapa de diseño y posteriormente de implementación, teniendo
en cuenta que muchas de las decisiones iniciales no fueron definitivas. A continuación se
expone la solución definitiva de la implementación de los procesos de negocio, siguiendo
SOA (Service Oriented Architecture) como estilo arquitectural. Por último se muestra la
estructura de las pruebas realizadas para llevar a cabo la validación de los procesos
implementados por medio de pruebas funcionales y unitarias, para de esta forma concluir
acerca de las lecciones aprendidas y de los resultados obtenidos finalizando así con
algunas oportunidades que se podrían realizar como trabajo futuro para enriquecer el
escenario.
2. OBJETIVOS
2.1. OBJETIVO GENERAL
Diseñar, implementar e integrar transversalmente dentro del MaketPlace de los Alpes
los procesos de negocio enfocados a servicio al cliente, para ampliar las
funcionalidades ya existentes por medio de la arquitectura empresarial y de solución.
2.2. OBJETIVOS ESPECÍFICOS
Adaptar las herramientas con las que cuenta el MPLA a los nuevos procesos de
negocio tomando como referencia la arquitectura definida.
Diseñar e implementar procesos que brinden flexibilidad y autoservicio a los
clientes y empleados de MPLA.
Diseñar e implementar las nuevas aplicaciones legado que soporten las
funcionalidades de los nuevos procesos a implementar.
3. CONTEXTO
3.1. ARQUITECTURA EMPRESARIAL (AE)
La arquitectura empresarial (AE) es un método y un principio de organización que
alinea los objetivos funcionales y estrategias de negocio con una estrategia de TI y el
plan de ejecución. La AE proporciona una guía para dirigir la evolución y
transformación de las empresas con la tecnología. [4]
Una arquitectura empresarial suele producir los entregables como: situación actual de
la arquitectura(AS-IS), arquitectura objetivo (TO-BE) o modelo de referencia que se
necesita para ejecutar la estrategia de negocio propuesto, análisis de brecha que
identifica las deficiencias de la situación actual en términos de su capacidad para
apoyar los objetivos y estrategias de la empresa y el plan de implementación o roadmap
de la arquitectura que define las iniciativas necesarias para migrar desde el estado
actual al estado futuro.
Tomando una perspectiva de toda la empresa a través de servicios de negocio,
procesos de negocio, información, aplicaciones y tecnología, una AE asegura que los
objetivos de la empresa se aborden de manera integral en todos los proyectos de TI.
La arquitectura empresarial se descompone en cuatro vistas, bajo a metodología
TOGAF:
ILUSTRACIÓN 1 DIMENSIONES DE TOGAF
La arquitectura de negocio obedece a la estrategia de negocio, gobierno,
organización y procesos de negocio, e interacción de estos conceptos, requeridos
para soportar los requerimientos y motivadores de negocio de la organización.[5]
La arquitectura de aplicaciones está compuesta por las directrices, normas, y
modelos que guían el diseño interno de todos los sistemas empresariales y
aplicaciones, de tal forma que compartan una misma estructura y que utilicen
herramientas y recursos comunes. Se deben también tener presentes las funciones y
los marcos proporcionados a través de la empresa para estructurar diagramas en
donde se identifiquen componentes e interfaces entre los mismos.
La arquitectura de información está compuesta por el modelo global de datos
corporativos para la empresa, la forma en que se hace el almacenamiento de la
información, tanto como los datos operativos como el concomimiento, cómo se
estructuran los datos, la definición del diseño de los modelos de datos, diseños
ontológicos y por ultimo como es accedida dicha información.
La arquitectura de tecnología está compuesta por el hardware, redes y software del
sistema que soporta los entornos de desarrollo de la implementación, también se
encargan del funcionamiento de todos los sistemas de negocio. Otros componentes
importantes son los sistemas operativos, los protocolos de comunicación, los
compiladores y herramientas de desarrollo de capa media como plataformas
empresariales, buses de servicios y motores de procesos, entre otros.
3.2. METODOLOGÍAS DE ARQUITECTURA EMPRESARIAL
La implementación un proyecto de arquitectura empresarial desde cero puede ser una
tarea de enormes proporciones, por esto los frameworks de AE se crean, para
simplificar el proceso y guiar a los arquitectos a través de todas las áreas del desarrollo
del proyecto. Un marco de arquitectura empresarial ofrece una recopilación de las
mejores prácticas, estándares, herramientas, procesos y plantillas para ayudar en la
creación de la arquitectura de la empresa. [4]
Los marcos y metodologías de arquitectura empresarial incluyen por lo general los
siguientes componentes:
Vocabulario común, modelos y taxonomía.
Procesos, principios, estrategias y herramientas, arquitecturas de referencia y
modelos.
Guía para entregables de EA (procesos de EA, contenido arquitectura, ruta de
implementación proyectos, gobierno)
Catálogo de artefactos y prestaciones de la arquitectura
Arquitectura de contenidos empresariales (Metamodelos)
Conjunto de productos y configuraciones
La utilización de un marco de arquitectura empresarial agiliza el proceso de creación y
el mantenimiento de las arquitecturas de todos los niveles (por ejemplo, las
arquitecturas empresariales, arquitecturas de negocio, arquitecturas transversales de
dominio de tecnología y arquitecturas de solución) y permite a las organizaciones
aprovechar el valor de las mejores prácticas de arquitectura.
Una serie de marcos de EA existen en la industria con el objetivo de afrontar el reto
básico de evaluar, alinear y organizar los objetivos empresariales con los requisitos
técnicos y las estrategias de negocio. Algunos ejemplos son la empresa Zachman
Framework, The Open Group Architecture Framework (TOGAF), OMB Federal
Enterprise Architecture (FEA) y la metodología de Gartner.
Cada marco tiene diferentes fortalezas y debilidades, lo que hace difícil encontrar un
marco ya existente que es ideal para todas las situaciones. La Ilustración 1 muestra
cuatro Frameworks de Arquitectura Empresarial con sus respectivas debilidades y
fortalezas:
ILUSTRACIÓN 2 COMPARACIÓN DE LAS CUATRO METODOLOGÍAS DE
ARQUITECTURA EMPRESARIAL MAS DESTACADAS
3.3. TOGAF
TOGAF es un marco de arquitectura empresarial. TOGAF proporciona los métodos y
herramientas para ayudar en la aceptación, la producción, el uso y el mantenimiento
de una arquitectura empresarial. Se basa en un modelo de proceso iterativo con el
apoyo de las mejores prácticas y un conjunto reutilizable de los activos de la
arquitectura existente.
ISO / IEC 42010:2007 define la "arquitectura" como: "La organización fundamental de
un sistema, representada en sus componentes, sus relaciones entre sí y el medio
ambiente, y los principios que rigen su diseño y evolución"[6].
TOGAF incluye parte pero no se adhieren estrictamente a la norma ISO / IEC
42010:2007 en su terminología. En TOGAF, "arquitectura" tiene dos significados,
dependiendo del contexto:
Una descripción formal de un sistema, o un plan detallado del sistema a nivel
de componente para orientar su aplicación.
La estructura de los componentes, sus interrelaciones, y los principios y
directrices que rigen su diseño y evolución en el tiempo.
Hay cuatro dominios de arquitectura empresarial que son comúnmente aceptadas
como subconjuntos de una arquitectura general de la empresa:
La arquitectura de negocios define la estrategia de negocios, gobierno,
organización y procesos clave de negocio.
La arquitectura de datos describe la estructura de los activos lógicos y físicos de
una organización y los recursos de gestión de datos.
La arquitectura de aplicaciones proporciona una guía para las aplicaciones
individuales que se despliegan, sus interacciones y sus relaciones con los
procesos centrales de negocio de la organización.
En la arquitectura tecnológica se describen las capacidades lógicas de software y
hardware que se requieren para apoyar el despliegue de negocio, datos y
servicios de aplicación. Esto incluye la infraestructura, middleware, redes,
comunicaciones, procesamiento, normas, etc.
La arquitectura TOGAF y su método Architecture Development Method (ADM) brinda una
metodología estándar para el desarrollo de arquitecturas. El ADM incluye el
establecimiento de un marco de arquitectura, desarrollo de contenidos arquitectura, la
transición, y que regula la realización de arquitecturas. Todas estas actividades se llevan a
cabo dentro de un ciclo iterativo de definición de la arquitectura y la realización continua
que permite a las organizaciones a transformar sus empresas de una manera controlada en
respuesta a los objetivos de negocio y oportunidades [6].
Fases dentro de la ADM:
En la fase preliminar se describen las actividades de preparación e iniciación
necesarias para crear una capacidad de Arquitectura incluyendo personalización
de TOGAF y definición de los principios de la arquitectura.
Fase A: Architecture Vision: describe la fase inicial de un ciclo de desarrollo de la
arquitectura. Incluye información acerca de la definición del alcance de la iniciativa
de desarrollo de la arquitectura, la identificación de las partes interesadas, la
creación de la Visión Arquitectura, y obtener la aprobación para proceder con el
desarrollo de la arquitectura.
Fase B: Arquitectura de actividades: describe el desarrollo de una arquitectura de
negocios para apoyar la Architecture Vision definida.
Fase C: Arquitecturas de Sistemas de Información: describe el desarrollo de
Arquitecturas de Sistemas de Información para apoyar la visión de la arquitectura
definida.
Fase D: Arquitectura de Tecnología se describe el desarrollo de la arquitectura de la
tecnología para apoyar la visión de la arquitectura definida.
Fase E: Oportunidades y Soluciones: lleva a cabo la planificación de la
implementación inicial y la identificación de los entregables para la arquitectura
definida en las fases anteriores.
F Fase: Planificación de la migración: se explica cómo pasar de la línea de base para
las arquitecturas de destino al finalizar un plan de implementación y plan de
migración detallado.
Fase G: Implementación de Gobierno: proporciona una supervisión arquitectónica
de la aplicación.
Fase H: Change Management Architecture: establece los procedimientos para la
gestión del cambio a la nueva arquitectura.
Requirements Management: examina el proceso de gestión de requisitos de arquitectura
a lo largo de la ADM.[3]
3.4. LABORATORIO DE ARQUITECTURAS EMPRESARIALES –
UNIVERSIDAD DE LOS ANDES
La velocidad en los cambios de las organizaciones y la constante evolución de la
tecnología y los sistemas de información han generado nuevas necesidades que los
profesionales en el área de TI, específicamente el campo de la arquitectura empresarial que
lo profesionales deben suplir. Ante la creciente demanda de personal entrenado y
calificado, la Universidad de los Andes a través del Departamento de Ingeniería de
Sistemas y Computación crea espacios para generar tales competencias de tal forma que
los estudiantes puedan dar solución de problemas utilizando TI como herramienta.
Para tal fin se creó el Laboratorio de Arquitecturas Empresariales (LAE), el cual cuenta con
una robusta infraestructura de software que soporta un conjunto de empresas virtuales
pertenecientes a diferentes verticales de negocio, las cuales plantean retos arquitecturales
que el estudiante debe entender, analizar y resolver, sin el impacto que esto significa en el
ambiente real de una compañía. Dicho enfoque se utiliza gradualmente en pregrado y
posgrado, donde el tamaño y el nivel de complejidad de los retos se adaptan al nivel del
estudiante. LAE se compone por la infraestructura de hardware y software necesaria para
mantener un conjunto amplio y variado de escenarios y retos, de manera que los
estudiantes puedan enfrentarse a ellos como parte de los cursos que toman. Este enfoque
se puede utilizar de pregrado, postgrado o de formación de empresas, cambiando
únicamente el tamaño de las empresas y la dificultad de los retos. [7]
Actualmente el laboratorio cuenta con los siguientes escenarios:
Banco de los Alpes
Muebles de los Alpes
Marketplace de los Alpes
AlpesCOM
Seguros de los Alpes
Inmobiliaria de los Alpes
BPO de los Alpes
3.5. MARKETPLACE DE LOS ALPES (MPLA)
El MarketPlace de Los Alpes (MPLA) es una empresa de mediación de transacciones entre
fabricantes (o proveedores) y comercializadoras de productos y/o servicios. El MPLA
actualmente es considerado líder en el país en mediar transacciones de negocio entre
comercios y fabricantes. Se calcula que cerca del 80% de los pedidos que se generan desde
las entidades de comercio tipo Grandes Superficies (Carrefour, Éxito, Carulla, Alkosto,
etc.) hacia las empresas de manufactura de alimentos (Alpina, Nestle, Nacional de
Chocolates, Noel, Rica, etc.) son mediadas a través del MarketPlace.
La operación del MarketPlace de los Alpes se centra principalmente en mediar cuatro tipos
de transacciones entre los comercios y los fabricantes:
1. PRICAT: Replicar el catálogo de productos (oferta comercial) de un fabricante
hacia entidades de comercio registradas en el MarketPlace.
2. PO (Purchase Order): Recibir órdenes de compra desde un comercio y direccionarla
a un fabricante en específico.
3. DA (Dispatch Advice): Recibir avisos de despacho como respuesta a una orden de
compra desde unl fabricante y direccionarla a la entidad de comercio que generó la
orden de compra.
4. RMA (Return Material Advice): Recibir avisos de retorno de mercancía/productos
desde una entidad de comercio y direccionarla al fabricante que realizó el
despacho de mercancía (DA).
Estas cuatro transacciones se ejecutan bajo el siguiente contexto de alto nivel:
Los comercios generan las transacciones de PO y RMA, y los fabricantes generan
las transacciones PRICAT y DA.
La comunicación entre el MarketPlace y las entidades se realiza a través de un
portal empresarial. Allí dichas entidades pueden consultar su información y
preferencias de productos que desean comprar y ofrecer.
La propagación del PRICAT desde un fabricante hacia los comercios se realiza de
la siguiente manera:
El fabricante envía un mensaje con la lista de productos que desea
ofrecer al MarketPlace.
El MarketPlace revisa producto por producto y procede a enviar el
producto a los comercios que manifestaron deseos de adquirir dicho
producto.
Es de vital importancia, para efectos de cobro de comisión, que se
garantice la entrega del producto a los comercios.
El cobro de comisión es fijo y se realiza al fabricante que está
propagando el catálogo.
MarketPlace cobra una comisión por mediar una transacción compuesta de
negocio exitosa. Una transacción compuesta de negocio considera los mensajes PO
y DA. El porcentaje de comisión a cobrar es estándar para todos los clientes. Sin
embargo, a medida que se transan operaciones entre los fabricantes, comercios y el
MarketPlace, el porcentaje de comisión a cobrar se ve afectado por el historial del
cliente. [2]
La arquitectura de solución de MarketPlace es presentada en la Ilustración 2:
ILUSTRACIÓN 3 DIAGRAMA POR CAPAS DE LA ARQUITECTURA TECNOLÓGICA
DEL MPLA
3.6. PROCESOS DE SERVICIO DE AL CLIENTE
Dentro de la cadena de valor del MPLA encontramos el macroproceso de gestión de
servicio al cliente. Es común que actualmente en las organizaciones este macroporceso
concentre una de las piezas fundamentales que pueden ser generadoras de diferenciación,
significando grandes esfuerzos por parte de las compañías para ganar una fracción mayor
los clientes y por ende del mercado. Términos como la satisfacción y fidelización de los
clientes se convierten en los pilares definitivos de las estrategias comerciales de las
organizaciones.
El servicio al cliente significa entonces, proporcionar asistencia a los clientes de tal forma
que se genere un mayor grado de satisfacción y que dicha asistencia sea consecuente con
los objetivos del negocio. Fundamentalmente los procesos de servicio al cliente deben estar
encaminados a la constante preocupación por las preferencias de los clientes, tanto a nivel
de interacción con ellos, como en el diseño de espacios apropiados a través de los cuales se
brinda el servicio. [1]
La tecnología juega un rol definitivo en el desarrollo de mejores procesos de servicio al
cliente, pues facilita herramientas para el manejo de información asociada a clientes, que
muchas veces no es bien utilizada por falta de recursos o porque simplemente no se ha
visto el valor agregado en el uso de la misma. Adicional a los sistemas de información y
plataformas empresariales que más adelante se introducirán, otros elementos tecnológicos
como los smartphones y otros dispositivos de tecnología, son nuevos canales que facilitan el
acercamiento con los clientes. Cada vez se crean más aplicaciones que permiten llegar al
cliente con productos y servicios apropiados y seleccionados a su perfil, creando nuevo
vínculos entre las organizaciones y los clientes, y un nuevo tipo de relación cliente-
empresa.
Por todo esto la innovación en los procesos de servicio al cliente representa un reto en las
organizaciones que buscan tener mejores y más duraderas relaciones con sus clientes,
invirtiendo recursos tanto tecnológicos como humanos. En consecuencia, las
organizaciones deben incluir en su organigrama los roles de los empleados encargados de
la gestión de servicio al cliente y también definir la responsabilidades asociadas a la
disposición y atención de canales comunicación para atender las solicitudes y comentarios
de los usuarios, de tal forma que estos sientan un acompañamiento por parte de la
empresa una vez se realizó la venta del producto o servicio.
En conclusión, las empresas para ofrecer un excelente servicio al cliente deben contar con
los canales que le permitan una comunicación amable, sencilla y efectiva con los clientes,
herramientas para llevar acabo análisis y modelos a partir de la información de los clientes
para identificar sus preferencias y de esta forma ofrecerle productos y servicios que se
adapten a lo que ellos están buscando. Por ultimo es vital contar un equipo que atienda los
procesos definidos y que cumpla sus responsabilidades para complementar de la mejor
manera todo el acercamiento con los clientes.
3.7. CRM (CUSTOMER RELATIOSHIP MANAGEMENT)
Gartner define el CRM (Customer Relatioship Management) como el software que se
ocupa de la gestión de los clientes y del ciclo de vida de gestión de procesos de
negocio asociados a los mismos, proporcionado las principales funcionalidades para
las empresas de ventas, marketing y en general empresas enfocadas a servicio al cliente
(incluyendo llamadas y centros de contacto) a través de componentes de colaboración,
operacionales y analíticos.
Actualmente las compañías más grande proveedoras de los grandes sistemas de
información ofrecen a las empresas una gran variedad de productos entre ellos los
CRM’s, cada uno de ellos enfocados en diferentes verticales de negocio y cubriendo
diferentes necesidades según el tipo de industria. El CRM utilizado en la solución es el
CRM on Demand de Oracle.
Dentro de las soluciones completas de Oracle, el CRM on Demand ofrece capacidades
muy amplias y profundas que ayudan a para impulsar las ventas, el marketing, la
lealtad y la eficacia del servicio. Oracle CRM On Demand tiene las siguientes
características:
• Una interfaz de usuario intuitiva y personalizable que facilita la aceptación y
productividad del usuario.
• Fuertes capacidades analíticas que proporcionan información procesable de las
tendencias del negocio y la visibilidad del mismo.
• Entrenamiento integrado de ventas que ayuda a cumplir las mejores prácticas y
proporciona guía en tiempo real
• El modelo Hosted que ofrece más bajas y costos predecibles, lo que lleva a menores
tiempos en la creación de valor con los clientes. [3]
4. ANÁLISIS Y DISEÑO DE LA SOLUCIÓN
Para el MarketPlace, sus clientes son lo más importante. Sin embargo, en la actualidad el
MPLA tiene un servicio al cliente muy pobre, ocasionando una baja en el volumen de las
transacciones mensuales que el portal del MPLA recibe. Es por esto que la alta gerencia del
MarketPlace ha decidido invertir en fortalecer los procesos de atención a clientes. Para
ello, se debe contar con diferentes puntos de contacto con los clientes, como lo son: manejo
de peticiones quejas y reclamos (PQRs), correos electrónicos de atención al cliente y foros.
A continuación se describe cada uno de los procesos que fueron diseñados e imprentados.
4.1. PROCESO DE GESTIÓN DE PQRS
A través de PQRs, los clientes pueden enviar solicitudes al MarketPlace. El MPLA desea
que, inicialmente, los clientes puedan registrar las siguientes solicitudes:
Quejas sobre el mal funcionamiento de un servicio del portal.
Reclamos sobre una comisión mal cobrada.
Cuando un cliente desea registrar una PQR, debe ingresar al portal y registrar la solicitud.
Para ello, debe indicar que tipo de solicitud es (Petición, Queja o Reclamo) y llenar ciertos
campos dependiendo de la solicitud.
Para el caso de una Queja:
El cliente procede a especificar el tipo de la queja (en este caso, mal funcionamiento
de una opción del portal), así como una descripción del error que se está
presentando.
Una vez se recibe la solicitud, se registra en el CRM y se direcciona a un
representante del departamento de desarrollo en la vicepresidencia de TI. De igual
forma, se le envía un correo electrónico al cliente que registró la solicitud
agradeciéndole por registrar el problema e informándole que se ha procedido a
atender la queja.
Una vez se ha solucionado el problema, el representante del departamento de
desarrollo debe registrar el cierre de la solicitud con una serie de observaciones al
respecto.
Finalmente, se procede a enviarle una notificación al cliente que registró la
solicitud informándole que se ha resuelto el problema gracias a su colaboración.
Para el caso de un Reclamo:
El cliente procede a especificar el tipo de reclamo (en este caso una comisión mal
cobrada), así como el número de referencia de la factura en la cual se registró el
cargo y el número de referencia de la transacción que presentó el cargo.
Adicionalmente, el cliente debe incluir una descripción explicando por qué este
cargo no es correcto.
Una vez se recibe la solicitud, se registra en el CRM y se direcciona a un
representante del departamento de facturación y recaudos en la vicepresidencia de
operaciones. De igual forma, se le envía un correo electrónico al cliente que registró
el reclamo informándole que su solicitud está en proceso.
Para poder atender la solicitud, el representante debe evaluar el proceso que
generó la comisión a través del número de seguimiento de la operación registrada
en Billing Charges. Si se rechaza la solicitud, el cargo se mantiene y se notifica al
cliente que la solicitud fue evaluada y el cargo es correcto.
Si se acepta la solicitud, se registra un cargo por el mismo valor como saldo a favor
del cliente (valor negativo), el cual debe aparecer en la siguiente factura del cliente,
y se notifica al cliente que su solicitud fue aceptada y que la devolución del valor se
reflejará en la próxima factura como saldo a favor.
En cualquier caso, se cierra la solicitud en el CRM.
4.2. PROCESO DE GESTIÓN DE MONITOREO DE CORREOS DE SERVICIO
AL CLIENTE
El MarketPlace desea ser capaz de monitorear los mensajes entrantes a las cuentas de
correo electrónico de servicio al cliente. Para ello, se requiere una aplicación que sea
capaz de monitorear la bandeja de entrada de la cuenta.
Cada 3 días, el sistema de monitoreo de cuentas de correo debe revisar si
existen nuevos correos de servicio al cliente por atender.
Si existen correos electrónicos por atender, se le deben asignar a un
representante de servicio al cliente para evaluar. Estos correos deben aparecer
como notificaciones en la lista de tareas pendientes del representante.
Los representantes de atención al cliente deben ingresar al portal diariamente
para revisar sus tareas pendientes. Si tiene una tarea pendiente, debe
seleccionarla y en ella podrá ver la información sobre lo que se requiere, la cual
es extraída de los correos electrónicos recibidos.
Entre la información de la tarea pendiente se debe mostrar el correo electrónico
del cliente, la fecha de recepción, el asunto del correo y el mensaje recibido.
El representante responde el correo y se debe registrar su respuesta en el CRM.
La respuesta luego es direccionada al cliente que envió la solicitud. Dentro de
la respuesta, se debe pedir al cliente que ingrese al portal del MarketPlace y
llene una encuesta de satisfacción de servicio al cliente, la cual debe registrar
con un código que se le envía en el correo.
4.3. PROCESO DE GESTIÓN DE PUBLICACIONES EN EL FORO DE MPLA
o Es importante para el MPLA que el foro tenga ciertas reglas de juego que se deben
respetar para garantizar el uso adecuado del portal. El uso de foros requiere de un
rol de administrador encargado de mediar los mensajes que se intercambian.
o Cuando un cliente desea postear en un foro, éste debe seleccionar el tema de
conversación en el cual desea participar y enviar un mensaje. Antes del envío
definitivo, se le presentan al cliente las reglas de uso del foro, las cuales debe
aceptar para proceder.
o Al ser recibido el mensaje, éste debe pasar por un sistema de verificación de
manera que se garantice el cumplimiento de las reglas del foro. Si el sistema dicta
un veredicto inconcluso, se debe delegar la responsabilidad al administrador del
foro para verificar el mensaje.
o Si el mensaje pasa las verificaciones, éste se publica en el foro. Si el mensaje no
pasa las verificaciones:
Si es la primera vez que sucede, se le envía un correo electrónico al cliente
que emitió el mensaje informándole que el mensaje incumple las normas
del foro y que si esta situación se vuelve a presentar, se le inactivará la
cuenta durante 1 mes.
Si es la segunda vez que sucede, se le inactiva la cuenta al cliente y se le
envía un correo electrónico informándole que es la segunda vez que
incumple con las reglas del foro y que su cuenta ha sido inactivada durante
1 mes.
Si ya se le ha inactivado la cuenta 1 vez, se inactiva nuevamente la cuenta
durante 3 meses y se le envía un correo electrónico al cliente informándole
que es la tercera vez que incumple las reglas del foro y que su cuenta se ha
inactivado durante 3 meses.
Si ya se ha inactivado el cliente 2 veces, se cancela la cuenta del cliente en el
MarketPlace y se le envía un correo electrónico informándole que teniendo
en cuenta los incumplimientos recurrentes de las reglas del foro, la cuenta
del cliente se ha cancelado en el MarketPlace.
4.4. ANÁLISIS Y DISEÑO DE LA ARQUITECTURA EMPRESARIAL
OBJETIVO DEL MPLA
De tal forma que los nuevos procesos del MarketPlace de los Alpes se puedan integrar a la
arquitectura que ya tenía definida el escenario previamente, se hizo necesario adaptar
algunos componentes y crear otros nuevo entregando como resultado una arquitectura
que incluye tanto los procesos que ya hacían parte de MPLA, como los nuevos procesos
que apoyan el área de Servicio al Cliente. En el Anexo No. 1 Análisis y diseño de
arquitectura empresarial y procesos, se muestra de manera detallada cada uno de los
componentes nuevos y los que ya existían y se adaptaron.
ARQUITECTURA DE NEGOCIO
Dentro de la arquitectura de negocio del MarketPlace de los Alpes se agregaron tres
subprocesos Gestión de publicaciones en el foro, Gestión de solicitudes PQRs y Gestión de
monitoreo de correos de servicio al cliente. Estos a su vez se encuentra dentro del proceso
de servicios sobre clientes y del eslabón de Gestión de servicio al cliente.
ILUSTRACIÓN 4 CADENA DE VALOR MPLA
Teniendo en cuenta que los procesos que se querían integrar en su mayoría eran
totalmente nuevos e independientes de los otros procesos se diseñaron por completo, sin
embargo el uso de componentes como el Mailer , componente para el envío de correos
electrónicos, fue necesario pues las funcionalidades son de vital importancia para terminar
el proceso debidamente. A continuación se muestra cada una de las actividades detalladas
del subproceso de gestión de monitoreo de correos de servicio al cliente:
ILUSTRACIÓN 5 DIAGRAMA BPMN DEL SUBPROCESO GESTIÓN DE
MONITOREO DE CORREOS DE SERVICIO AL CLIENTE
ARQUITECTURA DE DATOS Dentro de la arquitectura de datos se realizó el análisis y diseño de las nuevas entidades
que debían ser incluidas en el modelo canónico que ya tenía definido el MPLA, además
siendo consistentes con las metas de negocio de la compañía se diseñaron unos
indicadores de desempeño (KPI’s, por sus siglas en inglés) que permitieran monitorear los
nuevos procesos de servicio al cliente para ver que tanto están aportando con el
cumplimiento de dichas metas y como se podrían mejorar en beneficio del cliente.
Para cumplir con las nuevas funcionalidades necesarias para llevar a cabo los procesos
nombrados anteriormente fue necesario adicionar nuevas entidades al modelo canónico
del MarketPlace de los Alpes. Entidades como notificación, solicitud PQRs, queja, reclamo,
departamento, empleado, rol, tema foro, publicaciones foro se crearon y se integraron
conservando la consistencia y coherencia con el modelo que ya estaba hecho. El modelo
con las nuevas entidades resaltadas se puede observar en la Ilustración 6.
ILUSTRACIÓN 6 MODELO DE ENTIDADES DEL MPLA
Dentro del diseño de los indicadores de desempeño se definieron seis indicadores que
facilitaran a MPLA a evidenciar cómo era el comportamiento de los procesos a integrar y
cómo los usuarios estaban respondiendo a estos, lo que permitiría encontrar posibles
falencias en procedimientos internos y facilitar la toma oportuna de decisiones. Los
indicadores son:
Porcentaje de solicitudes PQRs resueltas, definido como:
Tiempo promedio de respuesta de una solicitud PQR, definido como:
∑
Número de solicitudes PQRs por tipo, definido como:
∑
Porcentaje de correos de servicio al cliente atendidos resueltas, definido como:
Tiempo promedio de respuesta de un correo de servicio al cliente, definido como:
∑
Número de notificaciones por tipo, definido como:
∑
Para poder implementar cada uno de los indicadores de desempeño fue necesario
construir los esquemas que permitieran registrar la información necesaria para que se
pudieran ver los resultados de cada indicador en el componente BAM. Para esto se debía
tener en cuenta cada una de las entradas necesarias en la tabla de hechos, en la Ilustración
7 se puede observar el modelo estrella general de los KPIs definidos en el proyecto.
ILUSTRACIÓN 7 MODELO ESTRELLA GENÉRICO DE LOS KPI
ARQUITECTURA DE APLICACIONES
Para llevar a cabo la implementación transversal de los procesos propuestos fue necesario
diseñar e implementar aplicaciones legado que brindaran todas las funcionalidades
requeridas, además se utilizó un componente que ya hacia parte del escenario, este fue el
CRM, para apoyar el manejo de peticiones quejas y reclamos. Las aplicaciones
desarrolladas fueron MonitoringEmails y NotificationManager, la primera encargada del
manejo de monitoreo de correos de servicio al cliente y la segunda se construyó para llevar
el manejo de notificaciones, que no hace parte como tal de un proceso definido, sino de
una funcionalidad que fue abstraída y que es común a varios procesos. A continuación se
poder ver el diagrama de cooperación de aplicación, en el cual se encuentran las
aplicaciones nombradas y la relación entre ellas.
ARQUITECTURA TECNOLÓGICA
En la arquitectura tecnológica del MarketPlace de los Alpes, la cual sigue un estilo
arquitectural orientado a servicios (SOA), encontramos seis componentes principales cada
uno con la responsabilidad de proveer las funcionalidades necesarias para que los
procesos diseñados se puedan llevar a cabo hasta el usuario final. Cada uno de los
componentes se observa en la Ilustración 9. EJB’s está compuesto por cada una de las
aplicaciones legado del escenario desarrolladas en Java, en su mayoría desarrolladas en la
plataforma NetBeans 6.7.1, basadas en EJB2 y desplegadas en un servidor Glassfish 2.1,
adicional a la lógica de las aplicaciones legado también están los componentes externos,
que son componentes empresariales como el CRM que también brindan funcionalidades
para la ejecución de los procesos. El siguiente componente que encontramos es el OSB-
BACK, un bus de servicios que sirve como puente entre las aplicaciones legado y el motor
de procesos que más adelante se explicará, este componentes elimina acoplamiento en la
arquitectura facilitando las integración de nuevos componentes en caso de que sea
necesario el reemplazo de alguno, o simplemente por requerimientos nuevos sin importar
si está desarrollado en otra tecnología como en el caso de componentes empresariales.
Otro de los componentes es el Business Activity Monitor (BAM), encargado de la
visualización de los indicadores de desempeño diseñados para el MPLA por medio de
reportes que se actualizan en tiempo real, a integración de los datos que permiten
construir los reportes se hace por medio del motor de procesos BPEL, otro de los
componentes que hace parte de la arquitectura. Este componente es de vital importancia
pues permite automatizar etapas del proceso que no requieren de intervención humana.
Más adelante encontramos el OSB-FRONT, otro bus de servicios que incrementa la
seguridad en el acceso de los componentes del back-end y sirve como puente entre los
procesos automatizados del BPEL, las operaciones del OSB-BACK y el portal que es el que
finalmente entrega las funcionalidades al usuario final por medio de una interfaz que
centraliza todos los procesos que tiene el escenario.
ARQUITECTURA DE SOLUCIÓN
En la Ilustración 10. Se puede observar el Blueprint de la arquitectura del MPLA, con cada
una de las zonas definidas, la descripción detallada del diseño de la Arquitectura de
Solución pude verse en el Anexo No. 2 Documento de Arquitectura de Solución. Cada uno
de los nuevos servicios ofrecidos fue integrado y clasificado.
5. IMPLEMENTACIÓN Y RESULTADOS
Teniendo en cuenta que uno de los objetivos principales del proyecto era la integración de
nuevos componentes y funcionalidades a la arquitectura que ya se encontraba definida en
implementada en el MPLA y siguiendo con el estilo arquitectural orientado a servicios
(SOA), el cual utiliza una estrategia de desarrollo centrada en el negocio, buscando
acoplamiento flexible entre los componentes y bloques interoperables que se pueden
combinar y reutilizar rápidamente, dentro y entre las empresas, para satisfacer las
necesidades del negocio[8], se llevó a cabo el desarrollo e integración de cada componente
para los procesos de gestión de solicitudes de peticiones, quejas y reclamos, y gestión de
monitoreo de correo de servicio al cliente, incluyendo además el desarrollo de todas las
capas para la funcionalidad abstraída de notificaciones.
5.1. ENTORNO DE DESARROLLO
El proyecto se desarrolló en una máquina virtual que emuló el ambiente de desarrollo en
el que está desplegada la arquitectura del MPLA, la estructura de servidores se muestra en
el Ilustración 11.
ILUSTRACIÓN 11 11 DIAGRAMA DE DESPLIEGUE DE DESARROLLO DEL MPLA
En la capa superior se encuentra el servidor JDeveloper Integrated WebLogic Server el
cual alberga el Oracle Web Center Suite, portal sobre el cual se entrega el acceso a las
funcionalidades implementadas al usuario final. En la capa inferior hallamos el servidor
Oracle Weblogic 11gR1 Patchset 2, este aloja los buses de servicios BACK y FRONT, el
BAM y el motor de procesos BPEL. El CRM On Demand de Oracle se encuentra conectado
a este servidor, a través de este se lleva a cabo la gestión de los clientes del MPLA,
incluyendo la gestión de peticiones quejas y reclamos implementados a lo largo del
proyecto. A nivel de aplicaciones se encuentra un servidor Glassfish 2.1 que aloja todas las
aplicaciones legado implementada en los diferentes proyectos, incluyendo el presente
proyecto, por los miembros del MPLA. Cada una de estas aplicaciones se desarrolló en el
ambiente NetBeans 6.7.1, basadas en EJB2 .Las funcionalidades expuestas en las
aplicaciones legado se hacen a través de web services. En la última capa el escenario cuenta
con un servidor MySQL 5.1 configurado desde la suite WAMP, este incluye la base de
datos y al administrador phpMyAdmin que facilita la gestión de las bases de datos, tablas,
índices, entre otros, por medio de una interfaz web amigable. Adicional al ambiente usado
para el desarrollo del proyecto, todas las conexiones entre servidores y componentes de la
arquitectura se realizaron a través de web services consumidos por medio de peticiones
SOAP/HTTP 1.1.
5.2. EQUIPO DE TRABAJO DEL MPLA
El equipo de trabajo del MarketPlace de Los Alpes durante el proyecto fue el siguiente:
Laura Manzur
Jefe del Escenario y colaboradora en el diseño del proyecto
Estudiante de Doctorado en Ingeniería de Sistemas y Computación de la Universidad
de Los Andes
Joseph Guevara
Estudiante de Maestría en Ingeniería de Sistemas y Computación de la Universidad de
Los Andes
Diana Archila
Estudiante de Pregrado en Ingeniería de Sistemas y Computación de la Universidad de
Los Andes
Este grupo de trabajo del MPLA fue creado para el desarrollo e integración de nuevos
componentes y funcionalidades que surjan para cumplir con todas las necesidades del
escenario, enriqueciendo la arquitectura empresarial del mismo por medio de los
diferentes artefactos y entregables resultado de los proyectos realizados.
En las primeras etapas del proyecto los encargados de definir cuáles eran los lineamientos
a seguir y sobre cuales temas en específico se debería trabajar durante el proyecto fueron
Laura Manzur y Joseph Guevara. Posteriormente se acordó un cronograma de trabajo y un
horario para llevar a cabo reuniones semanales para el seguimiento del proyecto. El
proyecto se desarrolló en su totalidad por la autora de este trabajo Diana Archila
incluyendo el diseño, el análisis, la construcción de la arquitectura empresarial, la
construcción de la arquitectura de solución y la implementación.
5.3. ESTRATEGIA DE DESARROLLO Y RESULTADOS
La estrategia de desarrollo del proyecto se realizó en varias etapas, iniciando con la
elaboración del documento de arquitectura empresarial, que incluye el diseño de cada una
de las cuatro vistas negocio, aplicaciones, datos y tecnología. Seguido de este se elaboró el
documento de arquitectura solución y portafolio de servicios, lo que dio pie al inicio de la
implementación de cada proceso.
Para la implementación se decidió iniciar por la capa de aplicaciones, siguiendo con el
primer bus de servicio, el motor se procesos, en el cual se llevó a cabo la integración de los
reportes diseñados en el BAM. El siguiente componente a implementar fue el segundo bus
de servicios y por último el portal.
El desarrollo de esta metodología fue incremental e iterativa, primero se llevó a cabo para
los procesos para los cuales era necesario la construcción de aplicaciones legado y
posteriormente para la gestión de peticiones, quejas y reclamos PQR’s, debido a que este
proceso debía ser implementado en el CRM y era necesario realizar consultas adicionales
pues el proceso de implementación era diferente.
Para asegurar que cada capa entregue las funcionalidades y requerimientos esperados, se
realizan pruebas que aseguren resultados consistentes con los esperados, tanto para casos
de éxito como de fracaso. A diferencia de todas las capas, para el portal se entrega un
demo de cada funcionalidad implementada, evidenciando los resultados desde el lado del
usuario final.
VISTA TOTAL
ILUSTRACIÓN 12 VISTA TOTAL MPLA
En la Ilustración 12 se puede observar la vista total del MPLA, los componentes resaltados
en rojo muestran las nuevas aplicaciones y procesos que se diseñaron e implementaron. En
primer lugar una de las funcionalidades abstraídas que se hizo común en todos los
proceso y que facilitarían a futuro algunas nuevas funcionalidades fue la gestión de
notificaciones. Para llevar a cabo la implementación de esta funcionalidad se desarrolló
una aplicación legado llamada NotificationManager, la cual se encarga de gestionar las
notificaciones de los empleados cuando estos tienen tareas nuevas, especialmente
solicitudes de servicio al cliente, ya sea correos, quejas o reclamos. Esta aplicación también
necesito el diseño y creación de la base de datos, incluyendo tablas e índices, esta se llamó
Notification DB. Por otro lado para gestionar el monitoreo de correos de servicio al cliente
se desarrolló otra aplicación legado llamada MonitoringEmails, la cual automáticamente
está revisando la bandeja de entrada de la cuenta de servicio al cliente, para más adelante
apoyada en NotificactionManager, generar las notificaciones de cada empleado. Adicional
en esta aplicación se habilito un control de administración para activar o desactivar al
monitoreo de los correos de tal forma que el empleado encargado pueda gobernar el
proceso. Dicho control se referencia en una tabla de la base datos que también se creó con
el nombre de Admin DB.
Un proceso de vital importancia para MPLA es la gestión de solicitudes de peticiones,
quejas o reclamos, pues es uno de los principales canales de acercamiento con el cliente,
por esto se tomó la decisión de implementar dicho proceso tomando como base las
funcionalidades del CRM On Demand, para esto fue necesario realizar una análisis del
modelo de datos que ofrece este, y de esta forma determinar cuál era la mejor opción para
integrar el nuevo proceso. Luego de realizar algunas pruebas y revisar la documentación,
se decidió que la mejor opción era utilizar el objeto ServiceRequest debido a que está
diseñado para registrar y cubrir las solicitudes de los clientes, facilitando realizar un
seguimiento de estas, y de esta forma ofrecer información o asistencia al cliente. El Service
Request además tiene asociaciones con el cliente directamente, lo que facilita la futura
integración de otros objetos que también ya han usado en el escenario del MPLA. Por otro
lado con la implantación del proceso de gestión de PQR´s en el CRM se pudo facilitar la
elaboración de algunos reportes que complementan los indicadores de desempeño del
BAM. En la Ilustración 13 podemos ver algunos de los reportes obtenidos.
ILUSTRACIÓN 13 REPORTE DE SOLICITUDES TOTALES POR TIPO DE CLIENTE CRM OD
Luego de haber probado cada una de las aplicaciones construidas y siguiendo con la
metodología propuesta inicialmente se inició la integración de cada proceso con el bus de
servicios Back-End, para esto fue necesario implementar los servicios proxy y las
transformaciones necesarias para mantener la consistencia entre las aplicaciones legado, es
decir el modelo canónico del MPLA y el resto de la arquitectura. Luego de realizar la
implementación de cada una de las operaciones expuestas por las aplicaciones legado y las
funcionalidades ofrecidas por el CRM OD en el bus y de realizar pruebas necesarias para
verificar que se estuvieran entregando los resultados esperados se continuó con la
orquestación del motor de procesos BPEL. Es importante resaltar que una de las etapas
que más tomo tiempo en la implementación del proceso de gestión de solicitudes de
peticiones, quejas o reclamos fue la integración del CRM OD con el bus de servicios,
debido a la falta de experiencia con el componente y el manejo de errores en el momento
de la integración. Continuando con la orquestación que se realizó en el componente BPEL,
se diseñaron cuatro nuevos procesos que no requirieran de la intervención humana y que
pudieran incluir las diferentes funcionalidades ofrecidas por las aplicaciones del escenario.
Los cuatro procesos implementados fueron:
Monitoreo correos
Atención de solicitudes
Generación de Quejas
Generación de reclamos.
El primero enfocado en el proceso de gestión de monitoreo de correos de servicio al
cliente, el segundo diseñado para response cualquier tipo de solicitud ya sea correos,
quejas o reclamos. Y por último el tercero y cuarto para la gestión de solicitudes de
peticiones de quejas y reclamos. Cada uno de estos procesos incluyo la integración con el
BAM de tal forma que los reportes se pudieran generar en tiempo real soportado con la
información de los procesos.
El proceso de generación de quejas, que se encuentra representado en la Ilustración 14,
primero verifica la existencia del cliente que está ingresando la queja con los registros
existentes en el CRM, de tal forma que no se pueda ingresar una solicitud si el cliente aún
no ha sido registrado en MPLA. Luego de realizar esta verificación se procede a crear el
registro de la queja, de tal forma que una vez se crea se envía un email al cliente para que
sea enterado de que su solicitud fue recibida, se crea además la notificación dirigida al
empleado y un correo igualmente enterándolo de una nueva tarea, finalmente se
alimentan los reportes del BAM y el proceso termina esperando a que el empleado
actualice el estado de la solicitud o cierre la misma, entregado una solución al cliente. El
mismo proceso se lleva a cabo para la generación de reclamos, con la diferencia que se
reciben como campos adicionales el número de cuenta y el número de factura. Cuando el
reclamo se crea el empleado encargado de atenderlo debe también definir si el reclamo es
válido o no y generar la nueva factura autorizando el desembolso, sin embargo esta parte
del proceso no está automatizada y debe ser el empleado el que realice las operaciones
necesarias por medio de la aplicación Billing Charges.
ILUSTRACIÓN 14 PROCESO DE GENERACIÓN DE QUEJAS
Luego de la generación de una notificación a raíz de un correo, una queja o un reclamo, es
necesario que por medio del proceso de atención de solicitudes se entregue una solución al
cliente y se cambie el estado de las mismas. Y así es como se lleva a cabo este proceso, se
da una solución a cliente, se notifica por correo electrónico y si es una queja o un reclamo
se cambia el estado en el CRM. En la Ilustración 15 se observa en el proceso de atención de
solicitudes.
ILUSTRACIÓN 15 PROCESO DE ATENCIÓN DE SOLICITUDES
Como ya se ha nombrado antes la definición de indicadores de desempeño y el
componente BAM se diseñaron dos reportes que permitieran monitorear y evaluar los
resultados de los procesos implementados. El primer reporte fue diseñado para mostrar el
estado de las notificaciones, incluyendo el tipo de las mismas y el tiempo de respuesta. En
la Ilustración 16 podemos se puede observar el reporte final visualizado desde la consola
del BAM.
ILUSTRACIÓN 16 REPORTE ESTADO NOTIFICACIONES
Adicional a este reporte se diseñó otro con el fin de presentar el estado de las quejas y
reclamos, un importante puente de comunicación entre los clientes y el MPLA, por lo que
se debe tener un total control y monitoreo de como es el comportamiento de los proceso
asociados a este tipo de solicitudes, además evaluar constantemente los indicadores se
pueden tomar decisiones de manera más rápida y efectiva que favorezcan los resultados
del negocio. En la Ilustración 17 se puede observar el reporte de estado de solicitudes
quejas o reclamos, que incluye el estado, el tipo y el tiempo de respuesta de las mismas.
ILUSTRACIÓN 16 REPORTE ESTADO SOLICITUDES PQR'S
Es importante resaltar que por medio de los reportes diseñados e implementados se puede
monitorear cada uno de los indicadores de desempeño KPI definidos en la vista de datos
de la arquitectura empresarial.
Una vez concluida la implementación y las pruebas del motor de procesos, se llevó a cabo
el desarrollo del segundo bus de servicios ESB Front-End, en este se integraron algunas
operaciones bus a bus necesarias para facilitar la visualización de algunos elementos en el
portal y así como también cada uno de los procesos implementados en el motor BPEL.
Esta capa de la arquitectura también fue sometida a pruebas para asegurar que las
funcionalidades requeridas pudieran ser expuestas en el portal.
Por último se crearon las páginas y los portlets necesarios para exponer al usuario final la
interfaz por medio de la cual puede acceder a la creación de quejas y reclamos en el caso
del cliente, y también en el caso del empleado de visualizar y responder las notificaciones
generadas en al MPLA, en las siguientes ilustraciones se puede evidenciar el resultado
final de cada proceso en el portal.
ILUSTRACIÓN 17 ENVIAR QUEJA MPLA PORTAL WEB
ILUSTRACIÓN 18 VER NOTIFICACIONES MPLA PORTAL WEB
ILUSTRACIÓN 19 ACTUALIZAR NOTIFICACIÓN MPLA PORTAL WEB
Las ilustraciones muestran la secuencia de lo que sería una ejecución de proceso de gestión
de una solicitud tipo queja, indicando por él envió de los datos principales de la queja,
incluyendo los motivos del problema. Una vez la queja se envía y queda registrada en el
sistema, tanto en la aplicación que maneja las notificaciones como en el CRM, de esta
forma el empleado puede entrar a consultar sus notificaciones y responder al cliente.
6. VALIDACIÓN
Las pruebas unitarias en cualquier proyecto de desarrollo de componentes de software e
integración de los mismos, representan una buena práctica que da garantía para obtener
un resultado robusto y unos componentes más fáciles de mantener. Teniendo en cuenta
que cada una de las capas de la arquitectura expone web services, se decidió utilizar soapUI
Pro como la herramienta indicada para ello, como veremos a continuación.
La forma en que se realizaron las pruebas fue por medio de peticiones SOAP/HTTP 1.1
hacia los web services. Estas pruebas de integración verificaron que cada capa consumía la
capa inferior correctamente. Adicional a estas pruebas a lo largo del desarrollo de cada
capa fueron de gran uso las consolas de cada componentes, que también proveían
interfaces que facilitaban llevar a cabo pruebas para evidenciar que los componentes
estaban funcionado de manera correcta y que la integración había sido exitosa. En este
proceso de pruebas se verificaron casos de éxito y casos de fracaso y adicionalmente se
verifico en cada prueba el estado inicial y el estado resultante luego de la ejecución del
proceso para verificar que todo marchara bien.
Por último, se llevaron a cabo pruebas funcionales sobre los formularios del portal.
Durante estas pruebas se desplegaron diferentes escenarios para verificar que el control de
errores si estuviera funcionando, es decir que cada capa donde se manejaron los posibles
casos de excepción si estuvieran funcionado. De igual forma se revisó el estado de las
bases de datos verificando que los datos insertados y actualizados de forma consistente y
coherente.
7. CONCLUSIONES
7.1. DISCUSIÓN
Como resultado final del proyecto se diseñaron, implementaron e integraron exitosamente
los procesos de negocio gestión de solicitudes PQR´s y monitoreo de correos de servicio al
cliente, fortaleciendo el área de servicio al cliente del MPLA, sin dejar de lado el
autoservicio, la automatización y la orientación hacia el cliente. Asimismo, se efectuaron
los cambios en la arquitectura empresarial del MarketPlace de los Alpes, diseñando los
nuevo procesos, si alterar los proceso que ya estaban definidos y asegurando que los
motivadores de negocio definidos desde el inicio del proyecto se cumplieran a cabalidad.
Otro de los resultados más importante fue el aporte que se dio al escenario, pues la
implementación de estos procesos son una base para continuar trabajando e investigando
en nuevos componentes que permitan consolidar el área de servicio al cliente, y que desde
AE se continúe un avance se sigan formulando nuevos retos que den como resultado
soluciones que puedan ser un puente entre el negocio y TI.
Por último, como estudiante de Ingeniería de Sistemas y Computación de la Universidad
de los Andes, esta fue una experiencia de gran crecimiento a nivel profesional, pues tener
contacto con un proyecto que se asemeja a la vida real permite crear habilidades y
desarrollar capacidades para enfrentarse a problemas más complejos como lo son la
integración de componentes empresariales. Al mismo tiempo durante cada etapa del
proyecto se reforzaron muchos conceptos adquiridos a lo largo del pregrado,
espacialmente en al área de arquitectura empresarial, como el manejo y comprensión de
los entregables y metodologías.
7.2. TRABAJO FUTURO
Como trabajo futuro y siguiendo con el objetivo de fortalecer el servicio al cliente en el
MPLA es importante incluir nuevos canales que permitan acercar más a los clientes del
MPLA, esto incluye la implementación del proceso diseñado en la arquitectura
empresarial de manejo de publicaciones en el foro. Otros canales que incluyan redes
sociales y chats también facilitarían al escenario la fidelización de clientes, aumentando el
volumen de transacciones.
Adicionalmente, integrar un motor de reglas a la arquitectura ayudaría a configurar
nuevas necesidades de negocio, disminuyendo complejidad en otros componentes como
esta implementado actualmente en el escenario, además permitirá que estas fueran
específicas y que su administración fuera más fácil de llevar cabo, con un tiempo de
implementación mucho menor en caso de que dichas reglas cambien.
8. BIBLIOGRAFÍA
[1] Collins, H. D. (2006). El servicio invisible Fundamento de un buen Servicio al Cliente.
Bogotá: ECOE Ediciones.
[2] Guevara, J. A. (01 de 2012). Diseño e Implementación Transversal de Procesos de
Neogio de Mediación de Transacciones para un MarketPlace. Diseño e Implementación
Transversal de Procesos de Neogio de Mediación de Transacciones para un MarketPlace.
Bogotá, Colombia.
[3] Oracle. (2008). Rapidly Increase Your Sales Team’s Effectiveness with Oracle E-
Business Suite and Oracle CRM On Demand . Rapidly Increase Your Sales Team’s
Effectiveness with Oracle E-Business Suite and Oracle CRM On Deman.
[4] Oracle. (10 de 2009). www.oracle.com. Recuperado el 11 de 2012, de Oracle White
Paper in Enterprise Architecture—The Oracle Enterprise Architecture Framework
http://www.oracle.com/technetwork/topics/entarch/oea-framework-133702.pdf
[5] The Open Group TOGAF. (2009). Recuperado el 11 de 2012, de
http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9-M7-Metamodel.pdf
[6] The Open Group TOGAF. (2011). TOGAF® Version 9.1, an Open Group Standard.
Recuperado el 11 de 2012, de http://pubs.opengroup.org/architecture/togaf9-doc/arch/
[7] Universidad de los Andes, Dep. Ingeniería de Sistemas y Computaión. (s.f.).
sistemas.uniandes.edu.co. Recuperado el 11 de 2012, de
http://sistemas.uniandes.edu.co/~lae/index.php?option=com_content&view=article&id
=21&Itemid=32&lang=es
[8]Wilkins, M. (09 de 2010). Oracle® Reference Architecture. Recuperado el 01 de 2013, de
http://www.oracle.com/technetwork/topics/entarch/oracle-ra-soa-foundation-r3-1-
176715.pdf
9. ANEXOS
9.1. ANEXO NO.1 ANÁLISIS Y DISEÑO DE ARQUITECTURA EMPRESARIAL Y
PROCESOS