Sistema Web para el Seguimiento de ventas Cruzadas

FACULTAD DE INGENIERÍA LIMA NORTE

INFORME DE PRÁCTICA PRE – PROFESIONAL II

TELEATENTO DEL PERÚ S.A.C

CENTRO DE INFORMACIÓN Y ANÁLISIS

PROYECTO ACADÉMICO:

SISTEMA WEB PARA EL SEGUIMIENTO

DE VENTAS CRUZADAS EN LA

EMPRESA TELEATENTO DEL PERU

Practicante:

Juárez Manayay, Adriano Mauricio

Docente:

Mg. Villaverde Medrano, Hugo

Supervisor:

Ing. Vílchez Benítez, Carlos A.

Jefe inmediato:

Chojeda Acedo, José

INGENIERÍA DE SISTEMAS

Setiembre – Diciembre 2014

Lima – Perú

DEDICATORIA

A Cristhian y Juan Diego, amante y amigo.

Escuela de Ingeniería de Sistemas

PRESENTACIÓN

Con el cumplimiento a las normas establecidas por el Reglamento de Practicas Pre-

Profesionales de la Universidad César Vallejo, se presenta el trabajo denominado:

“Sistema informático basado en plataforma web para el seguimiento de ventas

cruzadas en la empresa Teleatento del Perú S.A.C”.

Este proyecto se está realizando en la empresa Teleatento del Perú, empresa

dedicada a la prestación de servicios de atención de las relaciones entre las

empresas y sus clientes a través de Contac Centers o plataforma multicanal. La

oferta de Atento Perú abarca tanto productos especializados de gran valor añadido

como servicios automatizados, ofreciendo así a sus clientes un servicio combinado

que les permite un ahorro de costes. El área involucrada es la Jefatura Oro,

encargada de brindar servicio de Post Venta a los clientes de Telefónica del Perú

que cuentan con servicios multiproducto, a quienes se les absuelve las dudas y/o

problemas y; además, se aprovecha el contacto para ofrecer nuevos servicios,

basándose en estudio de sus necesidades, fidelizando a los cliente y obteniendo

más valor mediante estrategias de ventas cruzadas.

En dicho contexto se desarrollará un Sistema Web para el seguimiento de ventas

cruzadas de la Jefatura en mención, de acuerdo a un plan de trabajo estructurado y

supervisado en base a lo establecido por el Reglamento de Practicas Pre-

Profesionales con el fin de poner en práctica las competencias adquiridas durante

los años de formación profesional y contribuir con investigaciones que den prestigio

a la universidad y sirvan de base a futuras generaciones de estudiantes.

ÍNDICE GENERAL

RESUMEN ................................................................................................................................... 3

INTRODUCCIÓN ........................................................................................................................ 4

CAPÍTULO I: GENERALIDADES ............................................................................................ 5

1. Descripción del Sector ................................................................................................... 5

2. Descripción General de la Empresa ............................................................................ 9

2.1 Breve descripción general de la Empresa .......................................................... 9

2.2 Organización de la Empresa .............................................................................. 12

2.3 Descripción del área ............................................................................................ 13

3. Funciones del Ingeniero .............................................................................................. 13

3.1 Funciones del departamento .............................................................................. 13

3.2 Perfil del profesional, descripción del puesto de trabajo ................................ 14

CAPÍTULO II: PROYECTO O TAREA ACADÉMICA ......................................................... 16

1. Título ............................................................................................................................... 16

2. Realidad Problemática ................................................................................................. 16

3. Definición del problema ............................................................................................... 17

4. Antecedentes ................................................................................................................ 18

5. Marco Teórico ............................................................................................................... 22

5.1 Sistema Web ......................................................................................................... 22

5.2 Ventas Cruzadas .................................................................................................. 25

5.3 Metodología de desarrollo ................................................................................... 28

5.4 Metodología SCRUM ........................................................................................... 32

6. Objetivos ........................................................................................................................ 36

6.1 Objetivo General ................................................................................................... 36

6.2 Objetivos Específicos ........................................................................................... 36

7. Desarrollo ....................................................................................................................... 36

7.1 Plan de proyecto ................................................................................................... 36

7.2 Primera iteración ................................................................................................... 54

7.3 Segunda iteración ................................................................................................. 69

7.4 Tercera iteración ................................................................................................... 84

7.5 Fase de implementación ................................................................................... 100

8. Análisis de los resultados .......................................................................................... 100

9. Conclusiones ............................................................................................................... 100


10. Sugerencias ............................................................................................................. 101

BIBLIOGRAFÍA ....................................................................................................................... 102

ANEXOS .................................................................................................................................. 103


1

SISTEMA WEB PARA EL SEGUIMIENTO DE

VENTAS CRUZADAS EN LA EMPRESA

TELEATENTO DEL PERÚ

JUÁREZ MANAYAY ADRIANO MAURICIO

ÍNDICE DE TABLAS

Tabla 1: Cuadro comparativo de metodología RUP y SCRUM .................................................... 31

Tabla 2: Historia H1 Autentificar asesor...................................................................................... 37

Tabla 3: Historia H2 Visualizar maqueta de asesor ..................................................................... 37

Tabla 4: Historia H3 Visualizar detalle de indicadores de asesor ................................................ 38

Tabla 5: Historia H4 Visualizar detalle de contactos de asesor ................................................... 38

Tabla 6: Historia H5 Visualizar detalle de no transferencias de asesor ...................................... 39

Tabla 7: Historia H6 Registrar reclamos de ventas ..................................................................... 39

Tabla 8: Historia H7 Registrar reclamos de indicadores ............................................................. 40

Tabla 9: Historia H8 Autentificar supervisor ............................................................................... 40

Tabla 10: Historia H9 Visualizar maqueta de supervisor ............................................................ 41

Tabla 11: Historia H10 Visualizar detalle de indicadores de supervisores .................................. 41

Tabla 12: Historia H11 Visualizar detalle de contactos de equipo de supervisión ..................... 42

Tabla 13: Historia H12 Visualizar detalle de no transferencias de equipo de supervisión ......... 42

Tabla 14: Historia H13 Aprobar reclamos de ventas de equipo de supervisión ......................... 43

Tabla 15: Historia H14 Aprobar reclamos de indicadores de equipo de supervisión ................. 43

Tabla 16: Historia H15 Registrar incidencias laborales de equipo de supervisión ...................... 44

Tabla 17: Historia H16 Registrar reuniones qualitas supervisor ................................................. 44

Tabla 18: Historia H17 Autentificar movilizador ......................................................................... 45

Tabla 19: Historia H18 Visualizar maqueta de movilizador ........................................................ 45

Tabla 20: Historia H19 Visualizar detalle de indicadores de movilizador ................................... 46

Tabla 21: Historia H20 Visualizar detalle de contactos de equipo movilizador .......................... 46

Tabla 22: Historia H21 Visualizar detalle de no transferencias de equipo movilizador .............. 47

Tabla 23: Historia H22 Aprobar reclamos de ventas de equipo movilizador .............................. 47

Tabla 24: Historia H23 Aprobar reclamos de indicadores de equipo movilizador ...................... 48

Tabla 25: Historia H24 Registrar incidencias de ventas de equipo movilizador ......................... 48

Tabla 26: Historia H25 Registrar reuniones qualitas de equipo movilizador .............................. 49

Tabla 27: Historia H26 Reporte de incidencias ........................................................................... 49

Tabla 28: Cronograma de reuniones con el cliente .................................................................... 50

Tabla 29: Pila de producto para el proyecto ............................................................................... 52

Tabla 30: Plan de entregas y pruebas de aceptación .................................................................. 53

Tabla 31: Reuniones para la primera iteración ........................................................................... 54

Tabla 32: Tareas de primera iteración ........................................................................................ 55

Tabla 33: Prueba de aceptación de H1 ................................................................................ 60







Tabla 40: Reuniones para la segunda iteración .................................................................. 69

Tabla 41: Tareas de la segunda iteración ............................................................................ 70



Tabla 44: Prueba de aceptación de H10 .............................................................................. 75


2











Tabla 51: Reuniones para la tercera iteración ..................................................................... 84

Tabla 52: Tareas de la tercera iteración ............................................................................... 85






Tabla 58: Prueba de aceptación H22 .................................................................................... 93






3





RESUMEN

El proyecto comprende el desarrollo, implementación y evaluación de un sistema

informático basado en plataforma web para seguimiento de ventas cruzadas en la

empresa Teleatento del Perú S.A.C.

El objetivo principal del proyecto es mejorar el seguimiento de las ventas cruzadas a

partir de un análisis del proceso el cual comprende los siguientes indicadores:

Tiempo de entrega de indicadores y utilización del tiempo pagado. Por tratarse de

una gestión en proceso de reestructuración y que requiere de la participación activa

de un equipo se utilizará SCRUM como metodología de trabajo. Para su desarrollo

se utilizará el lenguaje de programación PHP y el sistema gestor de base de datos

MySQL, los cuales son estándares para el desarrollo web dentro de la empresa.

La implantación del sistema informático dará como resultado lo siguiente: lograr

disminuir el tiempo de entrega de indicadores de ventas cruzadas, de igual manera,

disminuir el tiempo utilizado en gestiones diferentes a las que son motivo de pago. El

proyecto demostrará que el uso del sistema informático basado en plataforma web

mejorará el seguimiento de ventas cruzadas en la jefatura Oro de Teleatento del

Perú S.A.C.

PALABRAS CLAVE: GESTIÓN DE VENTAS CRUZADAS – ANÁLISIS DE

INDICADORES DE VENTAS CRUZADAS – METODOLOGÍA SCRUM.


4





INTRODUCCIÓN

El proyecto aborda una de las problemáticas que desde hace cuatro años dificulta el

seguimiento de ventas cruzadas en la jefatura Oro de Teleatento del Perú S.A.C, y

es el no contar con un sistema que permita que el tiempo de entrega de la

información a los usuarios sea el óptimo sin que en el proceso las personas

desvíen su atención en labores por las que no han sido contratadas. En la jefatura

Oro de Teleatento del Perú S.A.C. el seguimiento de ventas cruzadas se realiza de

forma manual y a partir de observaciones y del levantamiento de información se

pudo detectar que la empresa presenta diversas falencias al momento de la entrega

de los indicadores a los usuarios finales; provocando de esta manera contratiempos

en la disponibilidad de la información, pérdida de tiempo en la entrega de

indicadores, sobre costos generados asociados al uso de papelería y flujo de

información muy lento. Actualmente el tiempo de entrega de la información es muy

alto, aproximadamente 85 minutos, y en la mayoría de casos la información no llega

al usuario que la requiere, a esto debemos añadir que los supervisores y

movilizadores del área invierten aproximadamente 11 minutos de su tiempo en la

preparación, impresión y entrega de indicadores a sus asesores en vez de enfocarse

en supervisar e impulsar la mejora de los mismos, ambas son actividades críticas

que dificultan el seguimiento del proceso de ventas cruzadas.

Durante el seguimiento de ventas cruzadas sin un sistema informático la entrega de

indicadores era una actividad manual, tediosa, que demandaba mucho tiempo y que

además requería del apoyo de personas desviándolas de sus labores principales,

por lo que la implementación del sistema informático permitirá reducir el tiempo de

entrega de la información y el tiempo utilizado en gestiones diferentes para las

cuales la empresa contrata.

Esta investigación se compone de dos capítulos y de la siguiente forma: en el

capítulo I se describirá a la empresa y el sector en el que se desempeña, al área

específica en donde se desarrolla el proyecto así como el perfil profesional que se

requiere. En el capítulo II se detalla lo concerniente al proyecto que se desarrolla, la

realidad problemática que se pretende resolver, los antecedentes, marco teórico,

objetivos, metodología de desarrollo, análisis de los resultados, conclusiones y

sugerencias. Además, se adjuntó la bibliografía y los anexos.


5





CAPÍTULO I: GENERALIDADES

1. Descripción del Sector

Teleatento del Perú S.A.C es una empresa dedicada a la prestación de servicios de

atención de las relaciones entre las empresas y sus clientes a través de Contac

Centers o plataforma multicanal. La oferta de Atento Perú abarca tanto productos

especializados de gran valor añadido como servicios automatizados, ofreciendo así

a sus clientes un servicio combinado que les permite un ahorro de costes. Es así que

la empresa en mención es prestadora de servicios de Contac Center tercerizados en

el sector de las telecomunicaciones.

La industria de los Call Centers se puede considerar como un buen caso de

negocios para desarrollar prácticas laborales responsables, basadas en una relación

virtuosa entre servicio y beneficio. En esta relación, Operadores Telefónicos más

productivos generan clientes más satisfechos, obteniendo así una mayor rentabilidad

para la empresa. Las prácticas laborales responsables aumentan la eficiencia y

reducen los costos laborales, contribuyendo así a la competitividad y al crecimiento

de las empresas.

Esta industria es una de las que cuenta con mayor crecimiento en los últimos años,

principalmente en América Latina y El Caribe, donde la mano de obra es barata y los

jóvenes ven en ellos una buena oportunidad para el crecimiento. Micheli Thirión

(2006) nos dice que “Los datos sobre el tamaño de esta industria en la escala

internacional son diversos, con una colección de estimados: se calcula la existencia

de una fuerza de trabajo de 2.86 millones de personas en Estados Unidos

(Datamonitor, 2004), aunque autores especializados señalan la existencia entre los

2.5 millones y 6.5 millones de personas (Moss, Salzman y Tilly, 2004:34). Para otros

países, una recopilación a partir de diversas fuentes nos ilustra un escenario como el

siguiente: Europa cuenta con 750 mil personas operando en esta industria

(Datamonitor, 2004), en Francia hay 200 mil (Novethic, 2005), una cantidad similar a

la de México que tiene casi 190 mil personas (Instituto Mexicano del Telemarketing,

2005), en Centroamérica y el Caribe se espera la creación de 24 mil empleos en los

años próximos (estimación de la empresa Avaya 2).”. Así mismo, Mejía (2012) nos

dice que lo que más prima son dos cosas: Los recursos humanos y la calidad. Y es

esa una de las razones por la que los mercados de América Latina y El caribe se

han convertido en una región con grandes oportunidades para la industria.


6





Siguiendo el razonamiento anterior, en Perú, este año, el sector ha creado alrededor

de nueve mil puestos de trabajo. Teniendo un escenario similar en otros países de la

región. Por ejemplo podemos mencionar que en el año 2007 los contratos por

Contac Center de USA representan el 82% del total generado para la región y se

estima que en dos años vengan a Latinoamérica 60 mil puestos de Call Center de

USA.

Para el caso de Perú, según APECCO, la industria de los Contac Centers crecerá

22% en 2012. Además nos dice que “Perú viene explotando sus principales ventajas

respecto a los demás países de la región; desde 2011, ya cuenta con más de 19 mil

posiciones tercerizadas”. Las figuras 1 y 2 muestran el crecimiento del sector y la

proyección al 2015, en Perú.

Figura 1

Desde el año 2004 la industria de los Contac Center ha incrementado

exponencialmente.

© A

PEC

CO


7





Figura 2

Perspectivas de evolución de la industria al 2015

La figura 3 muestra los principales mercados de exportación y la figura 4 muestra la

concentra de empleos en el sector teniendo en cuenta Lima y Provincias.

Figura 3

Principales mercados de exportación

© A

PEC

CO

© A

PEC

CO


8





Figura 4

Ubicación de los centros de contacto

Es en este escenario en el que la empresa en estudio se encuentra inmersa,

experimentando el crecimiento narrado y también con una fuerte competencia.

© A

PEC

CO


9





2. Descripción General de la Empresa

2.1 Breve descripción general de la Empresa

En Atento Perú laboran más de 12 mil colaboradores. Es una empresa líder en la

prestación de servicios de atención de las relaciones entre las empresas y sus

clientes a través de Contac centers o plataformas multicanal (teléfono, Internet,

SMS). Fue constituida en septiembre de 1999, partiendo de la actividad y

experiencia de Telefónica Marketing Directo, e inició sus operaciones en octubre de

ese mismo año.

Nació como una compañía de plataformas multicanal, que se benefició de las

sinergias de su pertenencia al Grupo Atento, y lograron diversificar nuestra actividad

hacia servicios de valor añadido para aquellas empresas o instituciones que

gestionan grandes carteras de clientes o demandan una fluida relación con sus

usuarios.

Durante los últimos dos años en Atento Perú ha pasado por grandes cambios,

registrando aumento de actividad e incremento significativo de personal.

Atento Perú desarrolló y viene gestionando con una fuerza de ventas presencial de

más de 700 personas en diversas ciudades. Esta operación se encuentra a cargo de

la Dirección de Negocios BPO (Bussines Process Outsourcing). Esta línea de

negocio implica no sólo una nueva actividad como es la asesoría de productos y

servicios a clientes a través del contacto directo sino también la descentralización de

las operaciones. Más del 40 por ciento de los vendedores opera en 17 ciudades del

interior del país.

Adicionalmente el BPO de Atento Perú ya incorporó negocios de Instalaciones o

Contratas, Venta de tarjetas de crédito y módulos de APV (Atención Personal

Virtual).

A lo largo del año pasado Atento Perú siguió aumentando los servicios

deslocalizados, fortaleciendo la relación con los clientes del segmento de

telecomunicaciones, tales como Americatel USA. Este año Movistar Chile a través

del servicio Inbound también ha puesto sus operaciones de consultas, reclamos y

cobros en manos de Atento.


10





En los negocios Multisector local, este año ha logrado captar nuevos clientes como

es el caso Edelnor, importante empresa de sector energía eléctrica del Perú que ha

confiado en Atento Perú el total de sus operaciones.

Asimismo, Procter & Gamble, otorgó el manejo de sus servicios de cobranzas a nivel

nacional. Citibank, es otra importante entidad bancaria norteamericana que en

nuestro país ha confiado a Atento la gestión de pago adelantado a proveedores de

las principales empresas clientes de este banco.

La meta: es ser la empresa más admirada del sector. Y los aspectos fundamentales

de la estrategia se pueden observar en la figura 5.

Figura 5

Visión y estrategia de Atento

La estrategia de Atento se articula en base a tres pilares: Negocios, Procesos y

Personas.

Para cada uno de ellos se han definido unos objetivos estratégicos que marcan

metas concretas y ayudan a medir los niveles de consecución de nuestra estrategia.

© A

ten

to P

erú


11





Además, cada pilar cuenta con unas iniciativas estratégicas que tienen carácter

transversal (afectan a toda la compañía), regional (afectan a una región) o local (a un

país concreto) y que constituyen verdaderos planes de acción para alcanzar los

objetivos. La figura 6 muestra un detalle de la estrategia de Atento Perú S.A.C.

Figura 6

Pilares de Atento Perú

La página web de la compañía es:http://www.atento.com

© A

ten

to P

erú

http://www.atento.com/


12





2.2 Organización de la Empresa

Teleatento del Perú S.A.C se encuentra organizado de la siguiente manera:

Figura 7

Organigrama de Atento del Perú

Teleatento del Perú cuenta con dos Direcciones: Dirección Negocios Telefónica y

Dirección Multisector, en la figura 7, se muestra el organigrama de la Dirección

Negocios Telefónica, la cual cuenta con Cinco Gerencias. La Oro (Antiguamente

Premium) se ubica en la Gerencia Dirigida por Violeta Fernández Serna

(anteriormente Miguel Campos Páez), es allí donde se realizan el trabajo de

investigación.

© A

ten

to P

erú


13





2.3 Descripción del área

La estructura del área de estudio es la siguiente:

La Jefatura tiene dos grandes actividades que gestionar: Nivel de Atención y las

ventas cruzadas, los indicadores de Nivel de Atención son gestionados directamente

por el Jefe, quien es el responsable de operaciones con ayuda de los supervisores; y

los indicadores de ventas cruzadas son gestionados por el Responsable de ventas

cruzadas, quien tiene como apoyo principalmente a los movilizadores de ventas

cruzadas y también a los supervisores, ambas actividades tienen diferentes

estructuras y gestionan diferentes indicadores, en el gráfico se ilustra el organigrama

de la gestión de ventas cruzadas.

3. Funciones del Ingeniero

3.1 Funciones del departamento

El departamento en donde se desarrolla las prácticas pre profesionales es la jefatura

Centro de Información y Análisis, la cual brinda servicio de soporte a las jefaturas de

operaciones. El servicio de soporte consta de elaboración de reportes de

indicadores, proyectos de automatización para mejorar las gestiones que realizan,

análisis del comportamiento de los indicadores y propuestas de mejora que generen

más valor en la operación, tanto para la empresa como para el cliente contratante.

Gudelia Paz Nuñez (Jefe)

Heidi Torres Uribe (Responsable de Ventas Cruzadas)

Supervisores Movilizadores de Ventas Cruzadas


14





Para realizar las labores antes mencionadas, la jefatura cuenta con 100 personas,

las cuales están divididas en equipos de 10 analista que brindan servicio

especializado a cada una de las gerencias de Teleatento del Perú S.A.C. y cada

integrante del equipo se especializa ya sea en reportes, análisis y propuestas de

mejora de un indicador específico o de una jefatura de la gerencia asignada.

3.2 Perfil del profesional, descripción del puesto de trabajo

El Analista se encarga principalmente de:

Mantener actualizados los reportes internos y externos.

Brindar información sobre los principales KPI y la evolución en el tiempo.

Plantear proyectos para mejorar la gestión a través de una metodología

estructurada (Seix Sigma).

Trasladar los objetivos mensuales a los equipos de supervisión, formular el

plan de acción para cumplir los mismos durante el mes, obtener las notas

mensuales por equipos de supervisión y asesores así como los bonos,

incentivos y comisiones.

Formular el plan de acción para cubrir el presupuesto de la Jefatura, mejorar

la rentabilidad (RO) y el OIBDA.

En consecuencia para ser analista en la jefatura de información y análisis de

Teleatento del Perú se requiere:

Nivel Académico: Egresado o estudiante universitario de Ingeniería o afines.

Habilidades Técnicas: Conocimiento de gestión de proceso, manejo de Office a

nivel avanzado, conocimiento en SQL Server u otra herramienta para la gestión de

bases de datos, conocimiento de herramientas para automatización y conocimiento

de metodologías para gestión de proyectos.

Habilidades Actitudinales: Proactivo, comunicación de alto nivel, con vocación de

aprendizaje y dispuesto a desarrollar una carrera en empresa en expansión.

Experiencia Laboral: Según las políticas de la empresa, generalmente se realizan

convocatorias internas entre asesores que cumplan con los requisitos para cubran

las vacantes. Se promueve línea de carrera dentro de la empresa desde nivel asesor

hasta jefe, gerente o director.


15





Capacitación: Tendrán seis meses de prueba antes de regularizar el cargo en los

sistemas de recursos humanos.

Especialización: No es imprescindible, la empresa brinda las especializaciones de

acuerdo al cargo.


16





CAPÍTULO II: PROYECTO O TAREA ACADÉMICA

1. Título

Sistema web para el seguimiento de ventas cruzadas en la empresa

Teleatento del Perú.

2. Realidad Problemática

En la actualidad las empresas de telecomunicaciones tienen el reto de llegar

cada vez a más personas, y en esta travesía tienen que lidiar con otras que

tienen los mismos retos y probablemente ofrezcan los mismos o mejores

servicios. Es en este contexto en el que las estrategias de ventas cruzadas se

convierten en una opción para seguir avanzado en un mercado saturado de

productos y proveedores. Según Expósito (2006), el cross selling es el

“crecimiento de la relación con el cliente mediante de venta de mayor número

de productos o servicios que tiene como principal ventaja conocer mejor las

necesidades del cliente, sus exigencias de entrega y timming”, esto permite

fidelizar y obtener mayor valor de los clientes.

La jefatura Oro de Teleatento del Perú ha sido contratada por Movistar S.A.A.

para brindar servicio de post venta a sus clientes multiproducto (aquellos

clientes que cuentan con los servicios de línea, internet y cable en paquetes)

y para mejorar la experiencia del cliente contratante aprovecha el contacto

con el usuario para generar más provecho mediante estrategias de ventas

cruzadas. Para tal motivo ha creado una estructura (responsable de ventas

cruzadas y movilizadores de ventas cruzadas) dedicada exclusivamente a la

gestión de dichos indicadores.

La gestión de ventas cruzadas se desarrolla de la siguiente manera:

Mensualmente se establecen objetivos de ventas por productos, los cuales

son validados con el cliente y obedecen a un propuesto de ingresos tanto

para la jefatura como para la empresa contratante. Una vez aceptados los

objetivos, la jefatura se compromete a cumplir el cien por ciento de los

objetivos de ventas. Para asegurar el cumplimiento de los objetivos de ventas,

tanto en volumen de productos como en ingresos económicos, se formulan

maquetas en cuatro niveles: Maqueta anual de cumplimiento de ingresos

presupuestado para el responsable de ventas cruzadas y jefe del servicio,


17





maqueta mensual con indicadores de cumplimiento de objetivos, efectividad,

abordaje y otros KPI de apoyo para supervisores, movilizadores de ventas

cruzadas y asesores. Para el seguimiento y cumplimiento de las maquetas

propuestas, se elaboran reportes diarios que muestren el avance de los

diferentes indicadores propuestos. La elaboración de los reportes, se realiza

de manera manual en la herramienta Excel, procesando la información de los

sistemas de atento (multigestión, herramienta en donde se guarda el detalle

de la llamada, así como las gestiones realizadas durante la misma) y del área

de grabaciones, quienes se encargan de leer el contrato de voz e ingresar el

pedido en los sistemas después de que el cliente aceptó el producto ofrecido.

Dichos reportes son colocados en un compartido para que puedan ser

revisados por los gestores y responsable de ventas cruzadas y, además se

envían por correo electrónico a los supervisores para la revisión y

seguimiento respectivo. Tanto los supervisores como movilizadores de ventas

cruzadas cuentan con una única estación (que tiene instalada la aplicación

Excel) para revisar, analizar e imprimir los indicadores de sus equipos. Es

conveniente indicar que Teleatento del Perú no cuenta con más licencias para

instalar la aplicación en otras estaciones y comprarlas no resulta rentable.

Este proceso manual con poco recursos toma excesivo tiempo y en la

mayoría de casos muchos de los asesores y supervisores terminan su

jornada de trabajo sin poder revisar sus indicadores diarios, lo que dificulta la

buena gestión para el cumplimiento de indicadores. Además promueve a que

los supervisores y gestores cross pierdan tiempo armando reportes

personalizados, que luego deberán ser impresos y recortados para la entrega

final a los asesores y desvíen su atención en exclusivamente la gestión de los

indicadores mediante reuniones qualitas con sus equipos que permitan

compartir buenas prácticas y formular acciones de mejora.

Planteado el escenario podremos decir que ¿Un sistema web permitirá

disminuir el tiempo de entrega de la información y ayudará a reducir el tiempo

usado en gestiones diferentes a las contratadas?

3. Definición del problema

Po: ¿De qué manera influye el sistema web en el seguimiento de ventas

cruzadas de la empresa Teleatento del Perú?


18





P1: ¿De qué manera influye el sistema web en el tiempo de entrega de

reportes a los supervisores, gestores y asesores en el seguimiento de ventas


P2: ¿De qué manera influye el sistema web en el tiempo efectivo de la gestión

de actividades de supervisores y gestores en el seguimiento de ventas


4. Antecedentes

No se ha encontrado antecedentes sobre la aplicación de un sistema web

para el proceso puntual en estudio, por lo a continuación se detallan algunos

en los que se ha aplicado un sistema web para optimizar procesos parecidos.

En el año 2012,Wilmer Calo Pallo elaboró la tesis titulada “Sistema de gestión

de ventas para el centro de servicios informáticos La Biblioteca” desarrollada

en la Universidad técnica de Cotopaxi de Cuba, en la cual aborda el problema

de la ineficiencia en el proceso de gestión de ventas en el Centro de servicios

informáticos La Biblioteca, debido a que dicho proceso se realiza de forma

manual, en documentos impresos y en hojas de cálculo, lo que ocasiona

pérdidas de información relevante debido a la manipulación indebida, falta de

seguridad y errores humanos. Los objetivos de la investigación fueron los

siguientes: caracterizar el proceso de gestión, planificación y control de

ventas en el Centro de servicios informáticos La Biblioteca e Implementar un

sistema para informatizar el proceso de gestión de ventas en el Centro de

servicios informáticos La Biblioteca a partir de los requerimientos derivados

de la descripción del sistema de gestión, de los modelos y el diseño

elaborado. La justificación del proyecto es tecnológica, económica e

institucional. No se especifica población y muestra definidas. La metodología

de investigación fue la aplicada. La metodología de desarrollo fue

Programación Extrema (XP). Las pruebas fueron satisfactorias. Las

conclusiones de la investigación demuestran que se logró aplicar

satisfactoriamente la herramienta y de ese modo se logró cumplir con los

objetivos propuestos.

De este trabajo de investigación deduce que un sistema web ha sido aplicado

con éxito en la mejora de un seguimiento de ventas aplicando una


19





metodología ágil. Por lo que se tomará en cuenta dicha metodología para el

desarrollo del sistema web para el seguimiento de ventas cruzadas.

En el año 2011, Patricia Matta elaboraron la tesis titulada “Sistema web para

el control de ventas y facturación usando agente inteligentes” desarrollada en

la Universidad Mayor de San Andrés de Bolivia en el cual aborda el problema

del área de ventas donde la facturación, registro de ventas, búsqueda de

planillas y reporte de ventas es manual y cauda pérdida de datos, además

cuando se requiere reportes fuera de la oficina, los mismos no se obtienen a

tiempo por falta del medio adecuado. Los objetivos fueron diseñar la

facturación, registro de ventas, módulo de cotización y generación de reportes

automatizados y usando agentes inteligentes para facilitar las listas de

productos generadas por cada cliente, de modo que no se las tenga que

volver a realizar. Este proyecto está justificado económica, social y

tecnológica. No se especifica población y muestra definidas. Se utilizó el

método científico como metodología de investigación, el tipo de investigación

es explorativa – descriptiva. La metodología de desarrollo fue la Metodología

extrema (XP). Las pruebas de los módulos fueron satisfactorias. La

investigación concluyo que las metodologías de análisis y diseño de sistemas

se aprovechan mejor cuando son aplicadas en conjunto, la utilización de

software da la posibilidad de crear una interfaz que permite al usuario el fácil

uso y navegabilidad, los agentes inteligentes tienen el potencial para

automatizar una variedad muy grande de actividades lo que permite a las

personas usar más el tiempo en analizar los resultados y tomar decisiones, la

implementación del sistema logró cumplir los objetivos propuestos de la

facturación automatizada que ha logrado disminuir el tiempo de elaboración

de la factura de quince a cinco minutos y la cantidad de errores ha disminuido

a cero, se logró además llevar un registro completo y ordenado de las ventas

lo cual ha disminuido la desorganización de la información y los reportes

generados son de gran ayuda al momento de tomar decisiones sobre las

inversiones de la empresa.

De esta tesis se rescata el uso de metodologías de desarrollo y análisis en

conjunto para obtener mejores resultados. Además se evidencia que un

sistema web optimiza los procesos en los que se aplica. Así mismo, se

tomará en cuenta el uso de metodología ágiles para el desarrollo de la

aplicación.


20





En el año 2008, Pavel Novoa elaboró el estudio titulado “Sistema para la

gestión de información de presupuestos de ventas: una solución Web a la

medida” desarrollada en el Centro de Información y Gestión tecnológica de

Cuba, en la que se aborda el problema de las dificultades en el proceso de

confección del presupuesto de ventas en la empresa Comandante Ernesto

Che Guevara que atentaban contra la integridad y confiabilidad de la

información, perjudicando a los presupuestos dependientes. El objetivo del

estudio es informatizar el proceso de confección del presupuesto de ventas.

La justificación del estudio tiene sustento institucional y tecnológico. No se

especifica una población y muestra definidos. La metodología de

investigación es múltiple teniendo como base el método científico. La

metodología de desarrollo fue RUP, apoyado con UML y ASP. Las pruebas

fueron satisfactorias. Las conclusiones a las que llegó el estudio fueron las

siguientes: El estudio preliminar mediante método científico permitió la

identificación satisfactoria de las principales entradas, procesos y salidas del

presupuesto de ventas, lo que además permitió definir un software a la

medida que se materializó en una aplicación Web ASP. Además la solución

resuelve el problema encontrado y se integró satisfactoriamente al portal

corporativo de la empresa permitiendo interconexión con sistemas dedicados

a la confección de otros presupuestos. A esto debemos añadir que el nivel

adecuado de aceptación de los usuarios finales.

De esta tesis se tomará la metodología de desarrollo RUP para contrastarla

contra las metodologías ágiles propuestas en las dos tesis anteriores. De este

modo se podrá decidir cuál es la mejor opción para un desarrollo adecuado

del sistema web.

En el año 2008, Alfonso Fernández desarrolló la tesis titulada “Sistema de

control de inventarios y facturación de la licorería Tropical Club de Girardot”

desarrollada en la Universidad minuto de dios de Cundinamarca la cual

aborda el problema de falta de sistematización en el control de entrada y

salida de productos como también en la contabilidad que es llevada de

manera manual y con excesivo gasto de tiempo. La justificación es

tecnológica debido a que el sistema servirá de apoyo a las actividades del

establecimiento e institucional debido a que el mismo se convertirá en una

herramienta útil y fiable a la hora llevar una contabilidad sistematizada y la

facturación correspondiente. Los objetivos de la investigación fueron realizar


21





un inventario en forma ordenada y confiable, optimizar la búsqueda de un

producto utilizado utilizando una base de datos y ofrecer a los clientes una

rápida y eficaz atención al momento de realizar sus compras. El estudio no

cuenta con población y muestra definidas. Se utiliza el modelo lineal

secuencial, conocido también como “ciclo de vida”, como metodología de

desarrollo. La metodología de la investigación es aplicada. Las pruebas

fueron satisfactorias. La investigación concluye indicando que el sistema

desarrollado bajo el modelo lineal secuencial agilizará los procesos y no

habrá pérdida de datos ni errores en las actividades.

De esta tesis se tomará el modelo lineal secuencial para ser comparado con

las metodologías RUP y ágiles y determinar la mejor opción al momento de

desarrollar una solución web.

En el año 2007, Antonio Villa elaboró la tesis titulada “Sistema para el control

de ventas e inventarios de la empresa Antiguo Arte Europeo” desarrollada en

la Universidad Autónoma del Estado de Hidalgo. Trata de resolver la

problemática de que los presupuestos se realizan de manera manual, lo que

ocasiona que existan errores en las claves y los precios; además de los

problemas que se tienen con los clientes debido a malos entendidos

relacionados con las fechas y precios establecidos. Los objetivos principales

de la investigación son diseñar el modelo de un sistema que permita mejorar

los procesos y solucionar las necesidades de administración de la información

en la empresa, diseñar interfaces fáciles de entender y utilizar, implementar el

sistemas, previa capacitación del personal, con prueba de 30 días y sujeto a

futuras mejoras o actualizaciones. La justificación es institucional debido a

que busca mejorar los procesos de ventas e inventarios, con la finalidad de

brindar un servicio de mayor calidad a los clientes, mejorar la eficiencia del

personal e incrementar la calidad de los datos y la información. No se tiene

población y muestra definidas. La metodología de investigación es aplicada y

se propone como metodología de desarrollo los modos para programar en

Visual Basic. Las pruebas fueron satisfactorias. La investigación concluye

indicando que se lograron los objetivos propuestos y que gracias al desarrollo

e implementación de un sistema computarizado las organizaciones pueden

satisfacer la necesidad que conlleva la administración, el control y consulta de

información; además ayudó a obtener un mayor rendimiento en el personal y

los recursos con los que cuentan.


22





De esta investigación se evaluará la propuesta de una solución de escritorio,

en contraste con la aplicación web que se pretende desarrollar, a fin de reforzar

lo adecuado de la solución propuesta.

5. Marco Teórico

5.1 Sistema Web

Existen diversos conceptos entorno a los sistemas web, siendo rescatables

distinguir el concepto de sitios web y el de las aplicaciones web.

Para López (2005, p. 254) un sitio web hace referencia al conjunto de páginas

web que forman una unidad funcional y de sentido. A veces incluso se puede

tener un sitio web de una sola página, y es entonces cuando página web t sitio

web se usan de forma indistinta, debido a que es fácilmente confundible. Los

sitios web requieren de una dirección particular o URL para que los usuarios

puedan acceder a la información contenida en ellos. Dicha dirección puede

remitir semántica y operativamente a una organización o institución.

Según Calo (como se citó García y Martínez, 1994) las aplicaciones web son

un conjunto de páginas enlazadas que permiten visualizar la información que

se quiere mostrar a través de ella. Afirma que constituyen una de las mejores

herramientas para divulgar, gestionar y compartir la información por lo que

traen consigo un aumento de la eficiencia en cuanto a la manipulación de gran

cantidad de elementos. Siguiendo la línea afirma que las aplicaciones web

agregan funcionalidad de negocio al proceso apoyados por los servicios web

que son hoy en día muy importantes, debido a que no sólo permiten mostrar

información estática o escrita con anterioridad a través de internet o una

intranet, sino que son capaces de generar datos solicitados a través de

consultas, debido a la dinámica sobre la que están basados.

Para Conallen (2003, p. 22), las aplicaciones web utilizan las tecnologías

facilitadoras para hacer su contenido dinámico y permitir que los usuarios del

sistema puedan afectar la lógica del negocio en el servidor.

Así mismo realiza una distinción sutil entre los sitios y las aplicaciones web, la

cual se basa en la capacidad de un usuario para afectar el estado de la lógica

del negocio en el servidor. Ciertamente, si no existe la lógica de negocio en un

servidor el sistema no puede ser considerado una aplicación web.


23





Entonces para aquellos sistemas en los que el servidor web – o servidor de

aplicaciones que utiliza un servidor web para el ingreso de un usuario – permite

a través de navegadores afectar la lógica del negocio, el sistema es

considerado aplicación web.

En este trabajo se adoptará la última definición, principalmente debido a que se

asumirá que la relación entre una aplicación web y sitio web es que la primera

evolucionó a partir de la segunda y por consiguiente, una aplicación web utiliza

un sitio web como máscara para mostrar una aplicación alojada en un servidor.

Además es fundamental el hecho de que mediante una aplicación web un

usuario pueda afectar “al estado del negocio”. Y esto es precisamente lo que

se desea.

A) Estructura de la aplicación web

Para Lujan (2002, p. 48) una aplicación web es también un tipo

especial de aplicación cliente/servidor, donde tanto el cliente

(navegador, explorador o visualizador) como el servidor (el servidor

web) y el protocolo mediante el que se comunican (HTTP) están

estandarizados y no han de ser creados por el programador de

aplicaciones.

El protocolo HTTP forma parte de la familia de protocolos de

comunicaciones TCP/IP, que son empleados en Internet. Estos

protocolos permiten la conexión de sistemas heterogéneos, lo que

facilita el intercambio de información entre distintos ordenadores.

HTTP se sitúa en el nivel 7 (aplicación) del modelo OSI.

Figura 8

Estructura Cliente/Servidor de una aplicación web

© L

ujá

n


24





a) El cliente

El cliente web es un programa con el que interacciona el

usuario para solicitar a un servidor web el envío de los

recursos que desea obtener mediante HTTP.

La parte cliente de las aplicaciones web suele estar

formada por el código HTML que forma la página web

más algo de código ejecutable realizado en lenguaje de

script del navegador o mediante pequeños programas

realizados en java. Por tanto, la misión del cliente web es

interpretar las páginas HTML y los diferentes recursos

que contienen.

b) El servidor

El servidor web es un programa que está esperando

permanentemente las solicitudes de conexión mediante

el protocolo HTTP por parte de los clientes web. La parte

servidor de las aplicaciones web está formada por página

estáticas, recursos adicionales que se pueden emplear

dentro de las páginas o estar disponibles para ser

descargados y ejecutados en el cliente y otros programas

o script.

B) Arquitectura Cliente/Servidor

Cliente/Servidor es una arquitectura en la cada ordenar o proceso

en la red es cliente o servidor. Normalmente, los servidores son

ordenadores potentes dedicados a gestionar unidades de disco,

impresoras, tráfico de red, datos o incluso aplicaciones; mientras

que los clientes son máquinas menos potentes y usan recursos que

ofrecen los servidores.

La arquitectura cliente/servidor permite la separación de funciones

en tres niveles como se muestra en la figura 9.


25





Figura 9

Separación de funciones cliente/servidor

a) Lógica de presentación

Se encarga de la entrada y salida de la aplicación con el

usuario. Sus principales tareas son: obtener información del

usuario, enviar la información del usuario a la lógica del negocio

para su procesamiento, recibir los resultados del procesamiento

de la lógica de negocio y presentar estos resultados al usuario.

b) Lógica de negocio (o aplicación)

Se encarga de gestionar los datos a nivel de procesamiento.

Actúa de puente entre el usuario y los datos. Sus principales

tareas son: recibir la entrada del nivel de presentación,

interactuar con la lógica de datos para ejecutar las reglas de

negocio que tiene que cumplir la aplicación y enviar el resultado

del procesamiento al nivel de presentación.

c) Lógica de datos

Se encarga de gestionar los datos a nivel de almacenamiento.

Sus principales tareas son: almacenar los datos, recuperar los

datos, mantener los datos y asegurar la integridad de los datos.

5.2 Ventas Cruzadas

Para Frutos (2012, p. 227) la venta cruzada es la táctica mediante la cual

un vendedor intenta vender productos complementarios a los que consume

o pretende consumir un cliente, basándose en sus compras anteriores. Con

la venta cruzada se pretende dar cobertura a un mayor abanico de

© L

ujá

n


26





necesidades con el objetivo de aumentar las ventas y además, fidelizar al

comprador.

Para algunos podría significar simplemente vender más productos a los

clientes. Sin embargo, para los especialistas en marketing nada tiene que

ver con la venta indiscriminada de productos a los clientes habituales. Más

bien al contrario, su significado está relacionado con conocer tan bien a

nuestro cliente, que podamos adelantarnos a sus necesidades y

satisfacerlas antes de que se haya producido la demanda puntual,

aumentando, no solo los ingresos de la empresa, sino la fidelidad del

consumidor. En resumen se puede hablar de ventas cruzadas cuando en la

oferta tras escuchar al cliente y ofrecerle un producto que satisfaga sus

necesidades, le presentemos, al menos, un segundo producto que mejore

los resultados del primero o sea complementario para lograr los resultados

demandados.

Para López-Pinto (2008, p. 322) las ventas cruzadas son una de las

estrategias más utilizadas para fidelización de clientes, la cual consiste en

que la empresa, conocedora de los gustos e historial del consumidor,

intenta venderle distintos productos, no necesariamente de la misma

categoría de la que está comprando actualmente. Los bancos, por ejemplo,

que son líderes del buen uso del database marketing, aprovechan en

vender distintos productos a sus clientes: fondos de inversión, seguros,

hipotecas, planes de pensiones, etc. Acota que hay empresas que hacen

un extensivo uso de la web y del teléfono para ampliar el ticket de compra

de sus consumidores. Cada vez que un cliente se conecta al site, suele

recibir una oferta de la venta de algún producto, y también recibe llamadas

con distintas ofertas, incluso servicios de telefonía.

Para Setó (2004, p. 10) la venta cruzada es consecuencia de la fidelidad de

los clientes y ocurre cuando la empresa consigue vender al usuario de un

servicio otros servicios, que pueden estar o no relacionados con el primero.

Este tipo de ventas permite conseguir, además, lo que se conoce como

economía de variedad o de conjunto, en la cual se consigue repartir los

costes fijos de las actividades que permiten tener acceso al mercado entre

un mayor número de unidades. Cuando a un mismo cliente se le puede

vender más de un producto o servicio, conseguimos cierta economía de

variedad, en tal sentido la mayoría de las empresas gozan de múltiples


27





oportunidades para realizar ventas cruzadas; basta con disponer de una

cartera de servicios adaptada a las necesidades de los clientes y a su

evolución.

En este trabajo se adoptará la primera definición, principalmente debido a

que es una definición integral que involucra tanto los aspectos de la venta,

el conocimiento del cliente y su satisfacción.

A) Aplicación de la venta cruzada

Para Frutos (2012, p. 227) se debe seguir las siguientes directrices en caso

el cliente sea receptivo a este tipo de venta:

Planificar: Se debe hacer previamente a la presentación del

producto al cliente. Para ello, resulta útil elaborar una lista de

aquellos productos o servicios que se pueden sugerir y establecer

los objetivos que se pretender conseguir.

Proporcionar y proponer: En primer lugar, hay que darle al cliente

lo que ha venido a buscar y luego sugerirle lo que nosotros hemos

detectado que necesita, y que él no sabe.

Usar un tono adecuado: Se deben hacer las sugerencias en tono

reflexivo y positivo. Es aconsejable no utilizar preguntas que inviten

a una respuesta negativa.

Demostrar: un truco que da buen resultado en ventas cruzadas, es

tener a mano el producto que queremos ofrecer. Así, no

olvidaremos hacer la sugerencia, a la ve mostramos sus cualidades.

B) Tipos de venta cruzada

Hay distintos tipos de ventas cruzadas y, aunque no nos demos cuenta de

ello, la mayoría de empresas nos las sugieren constantemente, como:

Venta basada en productos o servicios relacionados.

Venta basada en nuevos productos o servicios.

Mayor cantidad de producto.

Mayor calidad de producto.


28





C) Técnicas de venta cruzada

Una buena técnica de venta cruzada debe tener en cuenta los siguientes

cinco pilares fundamentales:

Conocimiento de los clientes.

Conocimiento del producto.

Preguntas inteligentes y escucha activa para captar pistas.

Asesoramiento al cliente sobre sus necesidades y ofrecimiento de

los productos adecuados.

Tratamiento de la venta como sugerencia. De ese modo, los clientes

se sienten cómodos con la información ofrecida voluntariamente y

es más fácil para ellos aceptar la oferta de la venta cruzada.

5.3 Metodología de desarrollo

Para el proyecto se evaluarán dos metodologías de desarrollo: RUP y

SCRUM.

El Proceso Unificado de Rational (RUP)

Para Carrillo (2008, p. 25), la metodología RUP es la más tradicional, se

centra en la definición detallada de los procesos y tareas a realizar,

herramientas a utilizar, y requiere una extensa documentación, ya que

pretende prevenir todo de antemano. Este tipo de metodologías son

más eficaces y necesarias cuando mayor es el proyecto que se

pretende realizar respecto a tiempo y recursos que son necesarios

emplear, donde una gran organización es requerida y se divide el

desarrollo en 4 fases que definen su ciclo de vida como muestra en la

Figura 10.

Inicio: El objetivo es determinar la visión del proyecto y definir lo que

se desea realizar.

Elaboración: Etapa en la que se determina la arquitectura óptima del

proyecto.

Construcción: Se obtiene la capacidad operacional inicial.

Transmisión: Obtener el producto acabado y definido.


29





Figura 10

Diagrama del esfuerzo de actividades según la etapa del proyecto

Filosofía RUP: La metodología RUP tiene 6 principios clave. (Carrillo,

2008, p. 28)

Adaptación del proceso: El proceso debe adaptarse a las

características de la organización para la que se está desarrollando

el software.

Balancear prioridades: Debe encontrarse un balance que satisfaga

a todos los inversores del proyecto.

Colaboración entre equipos: Debe haber una comunicación fluida

para coordinar requerimientos, desarrollo, evaluaciones, planes,

resultados, etc.

Demostrar valor iterativamente: Los proyectos se entregan, aunque

sea de una forma interna, en etapas iteradas. En cada iteración se

evaluará la calidad y estabilidad del producto y analizará la opinión

y sugerencias de los inversores.

Elevar el nivel de abstracción: Motivar el uso de conceptos

reutilizables.

Enfocarse en la calidad: La calidad del producto debe verificarse en

cada aspecto de la producción.

Disciplina de desarrollo de RUP: Determina las etapas a realizar

durante el proyecto de creación del software. (Carrillo, 2008, p. 28).

Fu

ente

: G

arri

do

, 2

008


30





Ventajas:

Evaluación en cada fase que permite cambios de objetivos

Funciona bien en proyectos de innovación.

Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora

de desarrollar el software.

Desventajas

La evaluación de riesgos es compleja

Excesiva flexibilidad para algunos proyectos

Estamos poniendo a nuestro cliente en una situación que puede

ser muy incómoda para él.

SCRUM

Para Solís (2006, p. 7), Scrum es un proceso ágil y liviano que sirve

para administrar y controlar el desarrollo de software. El desarrollo se

realiza en forma iterativa e incremental (una iteración es un ciclo corto

de construcción repetitivo). Cada ciclo o iteración termina con una pieza

de software ejecutable que incorpora nueva funcionalidad. Las

iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum

se utiliza como marco para otras prácticas de ingeniería de software

como RUP o Extreme Programming.

Figura 11

Esquema de trabajo SCRUM

Fu

ente

: S

olí

s, 2

00

6


31





Ventajas:

Entrega de un producto funcional al finalizar cada Sprint.

Posibilidad de ajustar la funcionalidad en base a la necesidad de

negocio del cliente.

Visualización del proyecto día a día.

Desventajas

No genera toda la evidencia o documentación de otras

metodologías.

No es apto para todos los proyectos.

Tal vez sea necesario complementarlo con otros procesos.

Tabla 1: Cuadro comparativo de metodología RUP y SCRUM

Fuente: Solís, 2006

Metodología

de Desarrollo

Descripción Características Calificación

RUP

La Metodología para

el desarrollo del

sistema está basada

en el Proceso

Unificado de Rational

(RUP), con

iteraciones

incrementales en la

fase de construcción.

La metodología RUP

se divide en 4 fases:

Inicio, Elaboración,

Construcción y

Transición.

C1: Tiene un

proceso de

desarrollo más

detallado.

C2: Requiere

definir una

arquitectura,

modelaje visual y

uso de

herramientas

como puntos

fundamentales.

C3: Se utiliza

para proyectos de

procesos en

desarrollo.

C4: Flexibilidad

a los cambios de

requerimientos.

C1: 4

C2: 4

C3: 2

C4: 4

TOTAL: 14

SCRUM

Es un marco de

trabajo para la

gestión y desarrollo

de software basada en

un proceso iterativo

incremental utilizado

comúnmente en

entornos basados en

el desarrollo ágil de

software.

C1: 3

C2: 4

C3: 5

C4: 5

TOTAL: 17


32





5.4 Metodología SCRUM

Metodologías ágiles: Las metodologías ágiles son un marco conceptual de la

Ingeniería de Software que promueve iteraciones en el desarrollo a lo largo de

todo el ciclo de vida del proyecto, considerando una iteración como una

unidad de tiempo que dura de uno a cuatro semanas. Donde cada iteración

del ciclo de vida incluye planificación análisis, diseño, codificación, revisión y

documentación. Una iteración no debe agregar demasiada funcionalidad para

justificar el lanzamiento del producto al mercado, pero la meta es tener un

producto parcial o una parte del todo al final de cada iteración.

Las metodologías ágiles buscan lo siguiente:

• Evitar los tortuosos y burocráticos caminos de las metodologías

tradicionales, enfocándose en la gente y los resultados.

• Minimizar los riesgos, desarrollando software en cortos lapsos de tiempo

(iteraciones).

• Enfatizar las comunicaciones cara a cara en vez de la documentación.

• Enfatizar que el software funcional es la primera medida del progreso.

Las metodologías ágiles platean centrarse en otras dimensiones, como por

ejemplo el factor humano o el producto software, siendo esto su principal

filosofía. Dando mayor valor al individuo, a la colaboración con el cliente y al

desarrollo incremental del software con iteraciones muy cortas. Este enfoque

está mostrando su efectividad en proyectos con requisitos muy cambiantes y

cuando se exige reducir drásticamente los tiempos de desarrollo pero

manteniendo una alta calidad.

Metodología Scrum: plantea un proceso de desarrollo de software iterativo y

creciente, utilizado comúnmente en entornos basados en el desarrollo ágil de

software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de

software, puede ser utilizado en equipos de mantenimiento de software, o en

una aproximación de gestión de programas: Scrum de Scrums. Scrum, por

sus características no es válido para cualquier proyecto persona o equipos de


33





personas, es óptimo para equipos de trabajo de hasta 8 personas, aunque

existen empresas que han utilizado con éxito Scrum con equipos más

grandes.

A) Principios básicos de SCRUM

Existen dos aspectos fundamentales a diferenciar en Scrum que son: los

actores y las acciones, donde los actores son los que ejecutan las acciones.

Los actores contemplados en esta metodología son los siguientes:

• ProductOwner, conoce y marca las prioridades del proyecto o producto.

• Scrum Master, es la persona que asegura el seguimiento de la metodología

guiando las reuniones y ayudando al equipo ante cualquier problema que

pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas

ante las presiones externas.

• ScrumTeam, son las personas responsables de implementar la

funcionalidad o funcionalidades elegidas por el ProductOwner.

• Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes

viendo los progresos, pueden aportar ideas, sugerencias o necesidades.

Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que

el mecanismo y forma de trabajar que a continuación se indica, tiene como

objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo:

• Productbacklog, corresponde con todas las tareas, funcionalidades o

requerimientos a realizar que son marcadas por el Productowner.

• Sprint backlog, corresponde con una o más tareas que provienen de la lista

de tareas (Productbacklog), donde estas tareas se deben acometer en unas 2

semanas o 4 semanas.

Existe una norma fundamental que mientras un Sprint backlog se inicia no

debe ser alterado o modificado, hay que esperar a que concluya para hacerlo.

• Dayliscrummeeting, es una tarea iterativa que se realiza todos los días que

dure el Sprint backlog con el equipo de desarrollo, con lo cual se busca


34





identificar obstáculos o riesgos que impidan el normal avance, verificar el

avance de las tareas y la planificaciones de las mimas para el día.

• Sprint planningmeeting, son reuniones cuyo objetivo es planificar el Sprint

Backlog a partir del ProductBacklog, suelen participar el Scrum master,

Scrumteam y el Productowner.

• Sprint review, una vez finalizado un Sprint backlog, se revisa en

aproximadamente dos horas si se ha obtenido un producto que pueda ver y

tocar el Cliente o usuario, donde un Scrumteam es quien muestra los

avances.

• Sprint retrospective, el Productowner revisará con el equipo los objetivos

marcados inicialmente en el Sprint backlog concluido, se aplicarán los

cambios y ajustes si son necesarios, y se marcarán los aspectos positivos

(para repetirlos) y los aspectos negativos (para evitar que se repitan) del

Sprint backlog.

B) Proceso de desarrollo de SCRUM

El proceso parte de la lista de tareas (Productbacklog), que no son otra cosa

que los requisitos del producto y que actúa como un plan del proyecto. De

esta lista el cliente prioriza los requisitos basándose en objetivos,

balanceando el valor que le aportan a su coste y quedando repartidos en

iteraciones y entregas (Sprint backlog).

De manera regular el cliente puede maximizar la utilidad de lo que se

desarrolla mediante la replanificación de objetivos que se puede realizar al

inicio de cada iteración.

Cada día de una iteración debe realizarse una reunión con los integrantes del

equipo con el objetivo de obtener de primera mano los avances de las tareas

y los obstáculos que se van presentando a lo largo del desarrollo de la

iteración.

Una vez finalizado un Sprint backlog, se revisan con el usuario o cliente los

productos obtenidos (Sprint review) y si cumplen con las necesidades

plasmadas por el usuario al inicio de la iteración. Cada fin de un Sprint

Backlog, se debe revisar los aspectos positivos y negativos del mismo con el


35





objetivo de poder utilizar estos para una mejor planificación de la siguiente

iteración a realizar. La siguiente figura muestra el desarrollo de la

metodología.

Figura 12

Esquema de metodología SCRUM

La siguiente figura nos muestra una comparación entre SCRUM y otras

metodologías tradicionales.

Figura 13

SCRUM comparada con otras metodologías tradicionales

© M

iller

©

Mill

er


36





6. Objetivos

6.1 Objetivo General

- Determinar la influencia del sistema web en el seguimiento de ventas

cruzadas en la empresa Teleatento del Perú.

6.2 Objetivos Específicos

- Reducir el tiempo de entrega de reportes a los supervisores, gestores y

asesores en el seguimiento de ventas cruzadas de la empresa

Teleatento del Perú.

- Incrementar el tiempo efectivo de la gestión de actividades de

supervisores y gestores en el seguimiento de ventas cruzadas de la

empresa Teleatento del Perú.

- Desarrollar e implementar el sistema web para el seguimiento de ventas

cruzadas en la empresa Teleatento del Perú.

7. Desarrollo

7.1 Plan de proyecto

7.1.1 Historias de usuario

A continuación se listan las historias de usuario recopiladas, cada una de

ellas con su respectiva descripción, riesgo y prioridad, tal como se muestra

desde las tablas 2 a la 27.


37





A) Historia de usuario H1: Autentificar asesor

Tabla 2: Historia H1 Autentificar asesor

Historia de Usuario H1 Nombre: Autentificar asesor

Usuario: Usuario asesor

Prioridad en Negocio: Alta

Riesgo en Desarrollo: Alto

Iteración: 1

Descripción:

Se debe de ingresar al sistema previa validación de un usuario y una contraseña, en caso dichos datos sean correctos se mostrará el menú correspondiente a la vista asesor

Observaciones:

El usuario será siempre el DNI del asesor. En caso se desee crear nuevos usuarios, cambiar o resetear contraseña se deberá solicitar mediante ARANDA.

Fuente: Elaboración propia

B) Historia de usuario H2: Visualizar maqueta de asesor

Tabla 3: Historia H2 Visualizar maqueta de asesor

Historia de Usuario H2 Nombre: Visualizar maqueta de asesor




Iteración: 1

Descripción:

Permite al asesor visualizar su maqueta, nota por cada indicador y nota final del mes en curso

Observaciones: ---



38





C) Historia de usuario H3: Visualizar detalle de indicadores de

asesor

Tabla 4: Historia H3 Visualizar detalle de indicadores de asesor

Historia de Usuario H3

Nombre: Visualizar detalle de indicadores de asesor




Iteración: 1

Descripción:

Permite al asesor visualizar el detalle de cada indicador medido. El sistema permitirá seleccionar la descripción de cada indicador para que pueda verse el detalle de cada uno.

Observaciones: ---


D) Historia de usuario H4: Visualizar detalle de contactos de

asesor

Tabla 5: Historia H4 Visualizar detalle de contactos de asesor

Historia de Usuario H4 Nombre: Visualizar detalle de contactos de asesor


Prioridad en Negocio: Media

Riesgo en Desarrollo: Medio

Iteración: 1

Descripción:

Permite al asesor ver el detalle de respuestas del área de grabaciones (CE, CNE, NC). El sistema permitirá realizar filtros de todos los campos para una mejor gestión de la información.

Observaciones: ---



39





E) Historia de usuario H5: Visualizar detalle de no transferencias

de asesor

Tabla 6: Historia H5 Visualizar detalle de no transferencias de asesor


Nombre: Visualizar detalle de no transferencias de asesor


Prioridad en Negocio: Baja

Riesgo en Desarrollo: Bajo

Iteración: 1

Descripción:

Permite al asesor visualizar el detalle de sus marcaciones no transferidas. El sistema permitirá realizar filtros en todos los campos para una mejor gestión de los datos.

Observaciones: ---


F) Historia de usuario H6: Registrar reclamos de ventas

Tabla 7: Historia H6 Registrar reclamos de ventas

Historia de Usuario H6 Nombre: Registrar reclamos de ventas




Iteración: 1

Descripción:

El asesor podrá seleccionar desde el menú la opción de registrar reclamos de ventas. El sistema mostrará un formulario en donde el asesor podrá registrar los datos necesarios para la revisión del caso.

Observaciones: ---



40





G) Historia de usuario H7: Registrar reclamos de indicadores

Tabla 8: Historia H7 Registrar reclamos de indicadores

Historia de Usuario H7 Nombre: Registrar reclamos de indicadores




Iteración: 1

Descripción:

El asesor podrá seleccionar desde el menú la opción de registrar reclamos de indicadores. El sistema mostrará un formulario en donde el asesor podrá registrar los datos necesarios para la revisión del caso.

Observaciones: ---


H) Historia de usuario H8: Autentificar supervisor

Tabla 9: Historia H8 Autentificar supervisor

Historia de Usuario H8 Nombre: Autentificar supervisor

Usuario: Usuario supervisor



Iteración: 2

Descripción:

Se debe de ingresar al sistema previa validación de un usuario y una contraseña, en caso dichos datos sean correctos se mostrará el menú correspondiente a la vista supervisor

Observaciones:

El usuario será siempre el DNI del supervisor. En caso se desee crear nuevos usuarios, cambiar o resetear contraseña se deberá solicitar mediante ARANDA.



41





I) Historia de usuario H9: Visualizar maqueta de supervisor

Tabla 10: Historia H9 Visualizar maqueta de supervisor

Historia de Usuario H9 Nombre: Visualizar maqueta de supervisor




Iteración: 2

Descripción:

Permite al supervisor visualizar su maqueta, nota por cada indicador y nota final del mes en curso

Observaciones: ---


J) Historia de usuario H10: Visualizar detalle de indicadores de

supervisor

Tabla 11: Historia H10 Visualizar detalle de indicadores de supervisores


Nombre: Visualizar detalle de indicadores de supervisores




Iteración: 2

Descripción:

Permite al supervisor visualizar el detalle de cada indicador medido. El sistema permitirá seleccionar la descripción de cada indicador para que pueda verse el detalle de cada indicador de cada uno de sus asesores.

Observaciones: ---



42





K) Historia de usuario H11: Visualizar detalle de contactos de

equipos de supervisión

Tabla 12: Historia H11 Visualizar detalle de contactos de equipo de supervisión


Nombre: Visualizar detalle de contactos de equipo de supervisión




Iteración: 2

Descripción:

Permite al supervisor visualizar el detalle de respuestas del área de grabaciones (CE, CNE, NC) de todos los miembros de su equipo. El sistema permitirá realizar filtros de todos los campos para una mejor gestión de los datos.

Observaciones: ---


L) Historia de usuario H12: Visualizar detalle de no transferencias

de equipo de supervisión

Tabla 13: Historia H12 Visualizar detalle de no transferencias de equipo de supervisión


Nombre: Visualizar detalle de no transferencias de equipo de supervisión




Iteración: 2

Descripción:

Permite al supervisor visualizar el detalle de registros no transferidos al área de grabaciones. El sistema permitirá realizar filtros en todos los campos para una mejor gestión de los datos.

Observaciones: ---



43





M) Historia de usuario H13: Aprobar reclamos de ventas de equipo

de supervisión

Tabla 14: Historia H13 Aprobar reclamos de ventas de equipo de supervisión


Nombre: Aprobar reclamos de ventas de equipo de supervisión




Iteración: 2

Descripción:

El supervisor podrá seleccionar del menú la opción "Reclamos de ventas" y será dirigido a una vista donde se mostrará todos los reclamos de ventas, los cuales podrán ser aprobados o rechazados. El sistema rechazará los reclamos si pasados tres días no se ha recibido una respuesta.

Observaciones: ---


N) Historia de usuario H14: Aprobar reclamos de indicadores de

equipo de supervisión

Tabla 15: Historia H14 Aprobar reclamos de indicadores de equipo de supervisión


Nombre: Aprobar reclamos de indicadores de equipo de supervisión




Iteración: 2

Descripción:

El supervisor podrá seleccionar del menú la opción "Reclamos de indicadores" y será dirigido a una vista donde se mostrará todos los reclamos de indicadores, los cuales podrán ser aprobados o rechazados. El sistema rechazará los reclamos si pasados tres días no se ha recibido una respuesta.

Observaciones: ---



44





O) Historia de usuario H15: Registrar incidencias laborales de

equipo de supervisión

Tabla 16: Historia H15 Registrar incidencias laborales de equipo de supervisión


Nombre: Registrar incidencias laborales de equipo de supervisión




Iteración: 2

Descripción:

El supervisor podrá seleccionar del menú la opción "Registrar incidencias laborales" y será dirigido a un formulario en donde deberá de llenar algunos datos.

Observaciones: ---


P) Historia de usuario H16: Registrar reuniones qualitas

supervisor

Tabla 17: Historia H16 Registrar reuniones qualitas supervisor

Historia de Usuario H16 Nombre: Registrar reuniones qualitas supervisor




Iteración: 2

Descripción:

El supervisor podrá seleccionar del menú la opción "Registrar reunión qualitas" y será dirigido a un formulario en donde deberá de llenar algunos datos.

Observaciones: ---



45





Q) Historia de usuario H17: Autentificar movilizador

Tabla 18: Historia H17 Autentificar movilizador

Historia de Usuario H17 Nombre: Autentificar movilizador

Usuario: Usuario movilizador



Iteración: 3

Descripción:

Se debe de ingresar al sistema previa validación de un usuario y una contraseña, en caso dichos datos sean correctos se mostrará el menú correspondiente a la vista movilizador

Observaciones:

El usuario será siempre el DNI del asesor. En caso se desee crear nuevos usuarios, cambiar o resetear contraseña se deberá solicitar mediante ARANDA.


R) Historia de usuario H18: Visualizar maqueta de movilizador

Tabla 19: Historia H18 Visualizar maqueta de movilizador

Historia de Usuario H18 Nombre: Visualizar maqueta de movilizador




Iteración: 3

Descripción:

Permite al movilizador de ventas cruzadas visualizar su maqueta, nota por cada indicador y nota final del mes en curso

Observaciones: ---



46





S) Historia de usuario H19: Visualizar detalle de indicadores de

movilizador

Tabla 20: Historia H19 Visualizar detalle de indicadores de movilizador


Nombre: Visualizar detalle de indicadores de movilizador




Iteración: 3

Descripción:

Permite al movilizador de ventas cruzadas visualizar el detalle de cada indicador medido. El sistema permitirá seleccionar la descripción de cada indicador para que pueda verse el detalle de cada indicador de cada uno de sus asesores.

Observaciones: ---


T) Historia de usuario H20: Visualizar detalle de contactos de

equipo movilizador

Tabla 21: Historia H20 Visualizar detalle de contactos de equipo movilizador


Nombre: Visualizar detalle de contactos de equipo movilizador




Iteración: 3

Descripción:

Permite al movilizador de ventas cruzadas visualizar el detalle de respuestas del área de grabaciones (CE, CNE, NC) de todos los miembros de su equipo. El sistema permitirá realizar filtros de todos los campos para una mejor gestión de los datos.

Observaciones: ---



47





U) Historia de usuario H21: Visualizar detalle de no transferencias

de equipo movilizador

Tabla 22: Historia H21 Visualizar detalle de no transferencias de equipo movilizador


Nombre: Visualizar detalle de no transferencias de equipo movilizador




Iteración: 3

Descripción:

Permite al movilizador de ventas cruzadas visualizar el detalle de registros no transferidos al área de grabaciones. El sistema permitirá realizar filtros en todos los campos para una mejor gestión de los datos.

Observaciones: ---


V) Historia de usuario H22: Aprobar reclamos de ventas de equipo

movilizador

Tabla 23: Historia H22 Aprobar reclamos de ventas de equipo movilizador


Nombre: Aprobar reclamos de ventas de equipo movilizador




Iteración: 3

Descripción:

El movilizador de ventas cruzadas podrá seleccionar del menú la opción "Reclamos de ventas" y será dirigido a una vista donde se mostrará todos los reclamos de ventas, los cuales podrán ser aprobados o rechazados. El sistema rechazará los reclamos si pasados tres días no se ha recibido una respuesta.

Observaciones: ---



48





W) Historia de usuario H23: Aprobar reclamos de indicadores de

equipo movilizador

Tabla 24: Historia H23 Aprobar reclamos de indicadores de equipo movilizador


Nombre: Aprobar reclamos de indicadores de equipo movilizador




Iteración: 3

Descripción:

El movilizador de ventas cruzadas podrá seleccionar del menú la opción "Reclamos de indicadores" y será dirigido a una vista donde se mostrará todos los reclamos de indicadores, los cuales podrán ser aprobados o rechazados. El sistema rechazará los reclamos si pasados tres días no se ha recibido una respuesta.

Observaciones: ---


X) Historia de usuario H24: Registrar incidencias de ventas de

equipo movilizador

Tabla 25: Historia H24 Registrar incidencias de ventas de equipo movilizador


Nombre: Registrar incidencias de ventas de equipo movilizador




Iteración: 3

Descripción:

El movilizador de ventas cruzadas podrá seleccionar del menú la opción "Incidencias de ventas" y será dirigido a un formulario en donde deberá de llenar algunos datos.

Observaciones: ---



49





Y) Historia de usuario H25: Registrar reuniones qualitas de equipo

movilizador

Tabla 26: Historia H25 Registrar reuniones qualitas de equipo movilizador


Nombre: Registrar reuniones qualitas de equipo movilizador




Iteración: 3

Descripción:

El movilizador de ventas cruzadas podrá seleccionar del menú la opción "Registrar reunión qualitas" y será dirigido a un formulario en donde deberá de llenar algunos datos.

Observaciones: ---


Z) Historia de usuario H26: Reporte de incidencias

Tabla 27: Historia H26 Reporte de incidencias

Historia de Usuario H26 Nombre: Reporte de incidencias




Iteración: 3

Descripción:

El movilizador de ventas cruzadas podrá seleccionar del menú la opción "Reportes de incidencias" y será dirigido a una interfaz que le permitirá exportar el detalle de la incidencias de ventas y reuniones qualitas registradas

Observaciones: ---



50





7.1.2 Reuniones

Se planificó reuniones con el cliente para identificar los objetivos,

metas y requerimientos (funcionales y no funcionales) del sistema a

desarrollar; así como la estructura que se utilizará en las diferentes

iteraciones. El esquema de reuniones realizadas se muestra en la

tabla 28.

Tabla 28: Cronograma de reuniones con el cliente

Reunión Fecha Inicio Fecha Fin Planificación, análisis y diseño del proyecto 13/10/2014 24/10/2014

Establecer las historias de usuario de la primera iteración 27/10/2014 07/11/2014

Establecer las historias de usuario de la segunda iteración 10/11/2014 21/11/2014

Establecer las historias de usuario de la tercera iteración 24/11/2014 05/12/2014


7.1.3 Alcance del proyecto

El proyecto pretende automatizar los reportes tanto para asesores,

supervisor y movilizadores de ventas cruzadas con el fin de reducir

los tiempos de entrega de reportes e incrementar el tiempo efectivo

en el desarrollo de actividades, esto como prioridad principal.

Adicionalmente se pretende construir los módulos de registro y

exportado de reclamos como prioridad baja. En caso no se cuente

con el tiempo necesario, éstas últimas actividades no serán

desarrolladas.

El proyecto no contemplará el manejo de usuario (cambio y reseteo

de clave, creación de nuevos usuarios, etc.). Tampoco se contempla

el desarrollo del módulo de aprobación o desaprobación de

reclamos en instancia final, debido a que estas funcionalidades

corresponden a un módulo administrador que será desarrollado en

una segunda etapa. Mientras tanto serán trabajadas directamente

sobre la base de datos mediante el sistema ARANDA con el que

cuenta la empresa para este tipo de requerimientos.

7.1.4 Pila de producto

Cada historia registrada por los usuarios, será gestionada para su

resolución, por medio de la “Pila de producto”, que es el inventario

de funcionalidades, mejoras, tecnologías y correcciones de errores,

que deben incorporarse al producto a lo largo de las sucesivas

iteraciones.


51





Para el diseño de este entregable se realizó una reunión con el

cliente del producto para determinar las prioridades de los

requerimientos funcionales que se especificaron en las historias de

usuario. De esta manera el equipo de proyecto definió la estimación

de los tiempos aproximados para el desarrollo del proyecto.

La pila de producto se muestra en la tabla 29.


52





Tabla 29: Pila de producto para el proyecto

Iteración 1 2 3 4

N° Historia Descripción Prioridad Riesgo Estimación 37 25 13 0

H1 Autentificar Asesor Alta Alto 1 1 0 0 0

H2 Visualizar Maqueta Asesor Alta Alto 2 2 0 0 0

H3 Visualizar detalle de indicadores de asesor Alta Alto 3 3 0 0 0

H4 Visualizar detalle de contactos de asesor Media Medio 2 2 0 0 0

H5 Visualizar detalle de no transferencias de asesor Baja Bajo 2 2 0 0 0

H6 Registrar reclamos de ventas Baja Alto 1 1 0 0 0

H7 Registrar reclamos de indicadores Baja Alto 1 1 0 0 0

Sprint 1 Entrega del módulo de Asesor

H8 Autentificar Supervisor Alta Alto 1 1 1 0 0

H9 Visualizar Maqueta Supervisor Alta Alto 2 2 2 0 0

H10 Visualizar detalle de indicadores de supervisor Alta Alto 3 3 3 0 0

H11 Visualizar detalle de contactos de equipo de

supervisión Media Medio 1 1 1 0 0

H12 Visualizar detalle de no transferencias de equipo

de supervisión Baja Bajo 1 1 1 0 0

H13 Aprobar reclamos de ventas de equipo de

supervisión Baja Alto 1 1 1 0 0

H14 Aprobar reclamos de indicadores de equipo de


H15 Registrar incidencias laborales de equipo de


H16 Registrar reuniones qualitas supervisor Baja Alto 1 1 1 0 0

Sprint 2 Entrega del módulo de Supervisor

H17 Autentificar Movilizador Alta Alto 1 1 1 1 0

H18 Visualizar Maqueta Movilizador Alta Alto 2 2 2 2 0

H19 Visualizar detalle de indicadores de movilizador Alta Alto 3 3 3 3 0

H20 Visualizar detalle de contactos de equipo

movilizador Media Medio 1 1 1 1 0


movilizador Baja Bajo 1 1 1 1 0

H22 Aprobar reclamos de ventas de equipo

movilizador Baja Alto 1 1 1 1 0

H23 Aprobar reclamos de indicadores de equipo


H24 Registrar incidencias de ventas de equipo


H25 Registrar reuniones qualitas movilizador Baja Alto 1 1 1 1 0

H26 Reporte de Incidencias Baja Alto 1 1 1 1 0

Sprint 3 Entrega del módulo de Movilizador



53





En la figura 14 se muestra la estimación de días por iteración.

Figura 14

Esfuerzo en días por cada iteración durante el desarrollo del proyecto

7.1.5 Plan de entregas y pruebas de aceptación

Para aproximar el tiempo que demorará realizar la entrega de los

prototipos y su evaluación se propuso el siguiente plan de entregas

según las iteraciones de quince días de duración.

Tabla 30: Plan de entregas y pruebas de aceptación

Entregas y pruebas de aceptación

Entregas y pruebas de aceptación de la primera iteración

Entregas y pruebas de aceptación de la segunda iteración

Entregas y pruebas de aceptación de la tercera iteración

Fecha Inicio Fecha Fin Fecha Inicio Fecha Fin Fecha Inicio Fecha Fin

27/10/2014 07/11/2014 10/11/2014 21/11/2014 24/11/2014 05/12/2014


© P

rop

ia


54





7.2 Primera iteración

7.2.1 Fase de planificación de la iteración

Se planificó reuniones con el cliente para identificar y

estructurar la primera iteración las cuales se muestran en la

tabla 31.

Tabla 31: Reuniones para la primera iteración

Reunión Fecha Inicio Fecha Fin

Definir los objetivos para la primera iteración 27/10/2014 27/10/2014

Asignación de tareas al equipo del proyecto 27/10/2014 27/10/2014

Realizar el Sprint Backlog 27/10/2014 27/10/2014

Realizar el Scrum Taskboard 27/10/2014 07/11/2014

Definir fecha para el entregable 07/11/2014 07/11/2014


7.2.2 Fase de análisis de la iteración

En esta fase se obtiene las especificaciones funcionales

registradas en cada una de las historias de usuario de esta

iteración.

A) Sprint Backlog

A continuación se muestra las historias de usuario a

desarrollar en la primera iteración:

- Historia H1: Autentificar asesor.

- Historia H2: Visualizar maqueta de asesor.

- Historia H3: Visualizar detalle de indicadores de

asesor.

- Historia H4: Visualizar detalle de contactos de

asesor.

- Historia H5: Visualizar detalle de no

transferencias de asesor.

- Historia H6: Registrar reclamos de ventas.

- Historia H7: Registrar reclamos de indicadores.


55





La tabla 32 muestra el detalle de tareas de la primera

iteración.

Tabla 32: Tareas de primera iteración

Iteración en días

0 1 2 3 4 5 6 7 8 9 10 11 12 13

N° Historia Historia/Tarea 780 120 110 100 90 80 70 60 50 40 30 20 10 0

H1 Autentificar Asesor

Diseñar y crear las tablas de usuarios 5 5

Diseñar y crear la interfaz de acceso 4 4

Realizar la conexión de la pantalla con la base 1 1

H4 Visualizar detalle de contactos de asesor

Diseñar las tablas de contactos y ventas 20 10 10

Desarrollar la interfaz de contactos 30 10 10 10

Conectar la interfaz con la base de datos 20 5 5 5 5

H2 Visualizar Maqueta Asesor

Diseñar la tablas de objetivos 20 5 5 5 5

Desarrollar la interfaz de maqueta 50 10 10 10 10 10

Conectar la interfaz con la base de datos 30 5 5 5 5 5 5

H3 Visualizar detalle de indicadores de asesor

Diseñar la interfaz de detalle de indicadores 30 5 5 5 5 5 5

Conectar la interfaz con la base de datos 70 10 10 10 10 10 10 10

H5 Visualizar detalle de no transferencias de asesor

Desarrollar la interfaz de no transferencias 40 5 5 5 5 5 5 5 5

Conectar la interfaz con la base de datos 40 5 5 5 5 5 5 5 5

H6 Registrar reclamos de ventas

Diseñar y crear las tablas de reclamos de ventas 90 10 10 10 10 10 10 10 10 10

Desarrollar la interfaz de reclamos de ventas 100 10 10 10 10 10 10 10 10 10 10

Conectar la interfaz con la base de datos 55 5 5 5 5 5 5 5 5 5 5 5

H7 Registrar reclamos de indicadores

Diseñar y crear las tablas de reclamos de indicadores 55 5 5 5 5 5 5 5 5 5 5 5

Desarrollar la interfaz de reclamos de indicadores 60 5 5 5 5 5 5 5 5 5 5 5 5

Conectar la interfaz con la base de datos 60 5 5 5 5 5 5 5 5 5 5 5 5



56





La figura 15 muestra el trabajo por días de la primera

iteración.

Figura 15

Esfuerzo en horas por cada día durante el desarrollo del proyecto

B) Scrum Taskboard

La figura 16 muestra el listado de historias de usuario

terminadas, en proceso y pendientes de la primera

iteración.

Figura 16

Scrum Taskboard de la primera iteración

© P

rop

ia

© P

rop

ia


57





7.2.3 Fase de diseño de la iteración

A) Diseño de diagrama de casos de uso de sistema

En la figura 17 se muestra el diagrama de casos de uso

del sistema correspondiente a la primera iteración.

Figura 17

Diagrama de casos de uso del sistema para la primera iteración

© P

rop

ia


58





B) Diseño del modelo lógico de la base de datos

En la figura 18 se muestra el modelo lógico de la base de

datos correspondiente a la primera iteración.

Figura 18

Diseño del modelo físico de la base de datos

© P

rop

ia


59





C) Diseño del modelo físico de la base de datos

En la figura 19 se muestra el modelo físico de la base de

datos correspondiente a la primera iteración.

Figura 19

Diseño del modelo físico de la base de datos

© P

rop

ia


60





7.2.4 Fase de construcción y pruebas de la iteración

A) Autentificación de usuario asesor

Figura 20

Interfaz de logueo de asesor

Tabla 33: Prueba de aceptación de H1

Caso de Prueba de Aceptación

Código: PH1 Número de historia de usuario: 1

Nombre de la prueba: Introducción del nombre de usuario y contraseña incorrecto.

Descripción: El usuario, al iniciar la aplicación observará una ventana de acceso a la aplicación, en la que se le solicitará el nombre de usuario y la contraseña. El usuario debe introducir estos campos y cuando cumple que el usuario no está dado de alta en el sistema, no tendrá acceso a la aplicación

Condiciones en ejecución: Ninguna

Entrada: - El usuario ejecuta la aplicación. - Aparece un formulario que solicita el usuario y contraseña. - El usuario introduce ambos y presiona el botón "ingresar". - El sistema verifica ambos campos en la base de datos y comprueba que no existe tal usuario. - El sistema muestra un mensaje de error y se retorna al formulario para que se ingrese los datos correctos.

Resultado esperado: Sólo los usuarios dados de alta en el sistema tienen permiso de acceso a la aplicación

Evaluación de la prueba: Satisfactoria


© P

rop

ia


61





B) Visualizar detalle de contactos de asesor

Figura 21

Detalle de contactos transferidos




Nombre de la prueba: Filtro de estados de un producto específico

Descripción: El usuario, seleccionará del menú la opción "Detalle de contactos", y en el panel derecho se mostrará una tabla con todos los registros de sus contactos transferidos al área de grabaciones en donde podrá filtrar cualquier campo para obtener la información deseada.

Condiciones en ejecución: El usuario deberá tener registros de transferencias en el sistema.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de ventas". - En el panel izquierdo aparecerán todos los registros de sus contactos. - El usuario filtrará del campo "Gestión" los registros con valor "CE" y del campo "Familia" los registros con el valor "Equipos". - El sistema muestra los registros que cumplen con los valores filtrados.

Resultado esperado: Al aplicar los filtros, el sistema debe arrojar la información esperada.



© P

rop

ia


62





C) Visualizar maqueta de asesor

Figura 22

Maqueta actual del asesor




Nombre de la prueba: Visualizar maqueta actual de asesor

Descripción: El usuario, seleccionará del menú la opción "Maqueta actual", y en el panel derecho se mostrará una tabla con todos los indicadores medidos y la nota final a obtenida a la fecha. La aplicación sólo mostrará la información del mes en curso.

Condiciones en ejecución: El usuario deberá tener información en el sistema.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Maqueta actual". - En el panel izquierdo aparecerá una tabla con la nota por cada indicador y la nota final obtenida.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el resumen de su maqueta actual.



© P

rop

ia


63





D) Visualizar detalle de indicadores de asesor

Figura 23

Detalle del indicador abordaje productivo




Nombre de la prueba: Visualizar detalle del indicador "Abordaje Productivo"

Descripción: El usuario, seleccionará del menú la opción "Abordaje productivo", y en el panel derecho se mostrará una tabla con la composición del indicador. Adicionalmente podrá observar la evolución del indicador por día.

Condiciones en ejecución: El usuario deberá tener registros de marcaciones abordadas de lo contrario el sistema no mostrará ningún tipo de información

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Abordaje productivo". - En el panel izquierdo aparecerá una tabla con la composición del indicador y además mostrará un gráfico con el evolutivo por día de dicho indicador. - El usuario podrá navegar de manera didáctica por la tabla y el gráfico.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el detalle del indicador seleccionado



© P

rop

ia


64





E) Visualizar detalle de No Transferencias de asesor

Figura 24

Detalle de registros no transferidos




Nombre de la prueba: Filtro de registros no transferidos.

Descripción: El usuario, seleccionará del menú la opción "Detalle de no transferencias", y en el panel derecho se mostrará una tabla con todos los registros de los registros no transferidos al área de grabaciones en donde podrá filtrar cualquier campo para obtener la información deseada.

Condiciones en ejecución: El usuario deberá de tener registros almacenados en el sistema

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de no transferencias". - En el panel izquierdo aparecerán todos los registros de sus no transferencias. - El usuario filtrará del campo "Resultado" los registros con valor "Gestión sin cierre" y del campo "Familia" los registros con el valor "Dúos". - El sistema muestra los registros que cumplen con los valores filtrados.




© P

rop

ia


65





F) Registrar reclamos de ventas

Figura 25




Nombre de la prueba: Registrar reclamo de un “No contacto”.

Descripción: El usuario podrá realizar el reclamo de cualquiera de los registros de la opción "Detalle de contacto" y de los registros con resultado "Aceptó titular" de la opción "Detalle de no transferencias". Además podrá visualizar el detalle de todos sus reclamos seleccionando la opción "Reclamos de ventas" del panel izquierdo de la aplicación.

Condiciones en ejecución: El usuario deberá tener registros de almacenados en el sistema. Además sólo podrá reclamar el registro por única vez.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de contactos". - En el panel izquierdo aparecerá una tabla con el detalle de sus transferencias, seleccionará la opción reclamar registro de cualquiera de los registros con gestión "NC". - El usuario llenará el formulario y lo guardará, posteriormente seleccionará la opción "Reclamos de ventas" y podrá visualizar, editar o eliminar el reclamo realizado.

Resultado esperado: Al seleccionar la opción la opción reclamar registro el asesor podrá realizar previo llenado de un formulario.



© P

rop

ia


66





G) Registrar reclamos de indicadores

Figura 26




Nombre de la prueba: Registrar reclamo de indicador abordaje productivo.

Descripción: El usuario deberá de seleccionar la opción "reclamos de indicadores" del panel izquierdo y la aplicación mostrará (en el panel derecho) el detalle de todos los reclamos de indicadores realizados, los cuales podrán ser editados o eliminados. Además podrá seleccionar la opción realizar reclamo que lo derivará a un formulario en donde deberá de llenar algunos datos necesarios.

Condiciones en ejecución: Ninguna.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Reclamos de indicadores". - En el panel izquierdo aparecerá una tabla con el detalle de sus reclamos y un botón en donde podrá ingresar un nuevo reclamo. - El usuario llenará el formulario y lo guardará, luego de ello la tabla con detalle de indicadores se actualizará con la nueva información.

Resultado esperado: Al seleccionar la opción "Ingresar un reclamo" será derivado a un formulario en donde deberá de llenar información necesaria para el reclamo.



© P

rop

ia


67





7.2.5 Revisión de la iteración

Para Kniberg (2007, p89) el Sprint Review es aquella

reunión en equipo donde se presenta al cliente los requisitos

completados en la iteración, en forma de incremento del

producto preparado, evaluando el desempeño del equipo a

lo largo de la duración de la iteración.

En la figura 27 se aprecia la evolución del desarrollo de las

historias de usuario a través del tiempo donde se puede

identificar que se cumplieron con las fechas establecidas.

Figura 27

Gráfico Burndown de la primera iteración

La presentación del producto se realizó con un miembro

quién expuso las metas de la iteración, el Sprint Backlog

comprometido y el Sprint Backlog completado.

7.2.6 Retrospectiva

Según Kniberg (2007, p.101) el Sprint Retrospective tiene el

objetivo de mejorar de manera continua la productividad y la

calidad del producto que se está desarrollando. El equipo

analiza los valores durante la iteración registrando los

aspectos resaltantes producidos durante el desarrollo de la

iteración.

Para hacer partícipe a cada uno de los miembros del equipo,

se procede a recopilar los puntos más relevantes,

dividiéndolos en tareas que se hicieron bien, tareas que se

hicieron mal y tareas que pueden mejorarse tal como se

muestra en la figura 28.

© P

rop

ia


68





Figura 28

Revisión de las actividades realizadas

A continuación se muestra un listado de lo aprendido durante

la primera iteración:

Al inicio dela iteración el equipo estuvo realizando

tareas ajenas al proyecto, por tal motivo se tuvieron

retrasos en el desarrollo. Con el transcurso del

tiempo se planificó mejor las actividades ajenas al

proyecto para evitar el fracaso del mismo.

El rendimiento del equipo fue incrementando con el

transcurrir de los días hasta lograr alta productividad.

Cada miembro del equipo estuvo enfocado en

mejorar el incremento de la iteración, por lo que se

estuvo en comunicación constante con los

involucrados en el proyecto.

© P

rop

ia


69





7.3 Segunda iteración



estructurar la segunda iteración las cuales se muestran en la

tabla 40.

Tabla 40: Reuniones para la segunda iteración










registradas en cada una de las historias de usuario de esta

iteración.

A) Sprint Backlog


desarrollar en la segunda iteración:

- Historia H8: Autentificar supervisor.

- Historia H9: Visualizar maqueta de supervisor.

- Historia H10: Visualizar detalle de indicadores de

supervisor.

- Historia H11: Visualizar detalle de contactos de

equipo de supervisión.

- Historia H12: Visualizar detalle de no

transferencias de equipo de supervisión.

- Historia H13: Aprobar reclamos de ventas de


- Historia H14: Aprobar reclamos de indicadores de


- Historia H15: Registrar incidencias laborales.

- Historia H16: Registrar reuniones qualitas.


70





La tabla 41 muestra el detalle de tareas de la segunda

iteración.

Tabla 41: Tareas de la segunda iteración

Iteración en días

0 1 2 3 4 5 6 7 8 9 10 11 12 13

N° Historia Historia/Tarea 120 120 110 100 90 80 70 60 50 40 30 20 10 0

H8 Autentificar supervisor

Diseñar y crear las tablas de supervisor 2 2

Conectar la interfaz de logueo con la base de datos 2 2

H9 Visualizar maqueta de supervisor

Desarrollar la interfaz de maqueta 10 10 4

Conectar la interfaz con la base de datos 10 10 10 4

H10 Visualizar detalle de indicadores de supervisor

Diseñar las interfaces de indicadores 10 10 10 10 4

Conectar las interfaces con la base de datos 10 10 10 10 10 4

H11 Visualizar detalle de contactos de equipo de

supervisión

Diseñar la interfaz de detalle de contactos 3 3 3 3 3 3

Conectar la interfaz con la base de datos 2 2 2 2 2 2


de supervisión

Desarrollar la interfaz de no transferencias 3 3 3 3 3 3 2

Conectar la interfaz con la base de datos 2 2 2 2 2 2 2

H13 Aprobar reclamos de ventas de equipo de

supervisión

Desarrollar la interfaz de reclamos de ventas 10 10 10 10 10 10 10 4

Conectar la interfaz con la base de datos 5 5 5 5 5 5 5 5

H14 Aprobar reclamos de indicadores de equipo de

supervisión

Desarrollar la interfaz de reclamos de indicadores 10 10 10 10 10 10 10 10 9

Conectar la interfaz con la base de datos 5 5 5 5 5 5 5 5 5 4

H15 Registrar incidencias laborales

Diseñar y crear las tablas de incidencias laborales 2 2 2 2 2 2 2 2 2 2

Desarrollar la interfaz de incidencias laborales 10 10 10 10 10 10 10 10 10 10 6


H16 Registrar reuniones qualitas

Diseñar y crear las tablas de reuniones qualitas 2 2 2 2 2 2 2 2 2 2 2 2

Desarrollar la interfaz de reuniones qualitas 12 12 12 12 12 12 12 12 12 12 12 12 5




71





La figura 29 muestra el trabajo por días de la segunda

iteración.

Figura 29

Esfuerzo por horas durante el desarrollo de la segunda iteración

B) Scrum Taskboard


terminadas, en proceso y pendientes de la segunda

iteración.

Figura 30

Pizarra de tareas para el seguimiento durante el desarrollo

© P

rop

ia

© P

rop

ia


72








del sistema correspondiente a la segunda iteración.

Figura 31


© P

rop

ia


73






A) Autentificación de usuario supervisor

Figura 32

Interfaz de acceso al sistema





Descripción: El usuario, al iniciar la aplicación conservará una ventana de acceso a la aplicación, en la que se le solicitará el nombre de usuario y la contraseña. El usuario debe introducir estos campos y cuando cumple que el usuario no está dado de alta en el sistema, no tendrá acceso a la aplicación






© P

rop

ia


74





B) Visualizar Maqueta de supervisor

Figura 33

Interfaz de la maqueta del supervisor




Nombre de la prueba: Visualizar maqueta actual del supervisor

Descripción: El usuario, seleccionará del menú la opción "Maqueta actual", y en el panel derecho se mostrará una tabla con todos los indicadores medidos y la nota final a obtenida a la fecha. La aplicación sólo mostrará la información del mes en curso, además del detalle de cada miembro de su equipo

Condiciones en ejecución: El usuario deberá de tener datos registrados en el sistema.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Maqueta actual". - En el panel izquierdo aparecerá una tabla con la nota por cada indicador y la nota final obtenida. - El usuario podrá visualizar también la nota final de cada miembro de su equipo.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el resumen de su maqueta actual y la de su equipo.



© P

rop

ia


75





C) Visualizar detalle de indicadores de supervisor

Figura 34

Interfaz del indicador “Ventas por hora”




Nombre de la prueba: Visualizar detalle del indicador "Ventas por hora"

Descripción: El usuario, seleccionará del menú la opción "Ventas por hora", y en el panel derecho se mostrará una tabla con la composición del indicador. Adicionalmente podrá observar la evolución de cada miembro de su equipo.

Condiciones en ejecución: El usuario deberá tener registros de marcaciones abordadas de lo contrario el sistema no mostrará ningún tipo de información.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Ventas por hora". - En el panel izquierdo aparecerá una tabla con la composición del indicador y además la evolución de cada miembro de su equipo. - El usuario podrá navegar de manera didáctica por la información mostrada.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el detalle del indicador seleccionado.



© P

rop

ia


76





D) Visualizar detalle de contactos de equipo de

supervisión

Figura 35

Interfaz de detalle de contactos




Nombre de la prueba: Filtro de contactos de un miembro del equipo.



Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de ventas". - En el panel izquierdo aparecerán todos los registros de sus contactos. - El usuario filtrará del campo "Asesor" los registros de algún miembro de su equipo. - El sistema muestra los registros que cumplen con los valores filtrados.




© P

rop

ia


77





E) Visualizar detalle de no transferencias de equipo de

supervisión

Figura 36

Interfaz de detalle de no transferencias




Nombre de la prueba: Filtro de registros no transferidos por asesor



Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de no transferencias". - En el panel izquierdo aparecerán todos los registros de sus no transferencias. - El usuario filtrará del campo "Asesor" los registros de alguno de los miembros de su equipo. - El sistema muestra los registros que cumplen con los valores filtrados.




© P

rop

ia


78





F) Aprobar reclamos de ventas de equipo de

supervisión

Figura 37

Interfaz de aprobación de reclamos de ventas




Nombre de la prueba: Aprobar reclamo de un asesor

Descripción: El usuario podrá visualizar el detalle de todos los reclamos de los miembros de su equipo seleccionando la opción "Reclamos de ventas" del panel izquierdo de la aplicación. Así mismo podrá aprobar o rechazar el reclamo.

Condiciones en ejecución: El reclamo no deberá tener más de tres días de ingresado, de lo contrario se rechazará de manera automática.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Reclamos de ventas". - En el panel izquierdo aparecerá una tabla con el detalle de los reclamos que han realizado los miembros de su equipo. - El usuario aprobará uno de los registros seleccionados.

Resultado esperado: Al seleccionar la opción la opción aprobar reclamo, el registro se actualizará con la nueva información.



© P

rop

ia


79





G) Aprobar reclamos de indicadores de equipo de

supervisión

Figura 38

Interfaz de aprobación de reclamos de indicadores




Nombre de la prueba: Aprobar reclamo de indicador de asesor

Descripción: El usuario podrá visualizar el detalle de todos los reclamos de los miembros de su equipo seleccionando la opción "Reclamos de indicadores" del panel izquierdo de la aplicación. Así mismo podrá aprobar o rechazar el reclamo.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Reclamos de indicadores". - En el panel izquierdo aparecerá una tabla con el detalle de los reclamos de indicadores que han realizado los miembros de su equipo. - El usuario aprobará uno de los registros seleccionados.

Resultado esperado: Al seleccionar la opción la opción aprobar reclamo de indicador, el registro se actualizará con la nueva información.



© P

rop

ia


80





H) Registrar incidencias laborales

Figura 39

Interfaz de registro de incidencias laborales




Nombre de la prueba: Registrar incidencia "Descanso médico prolongado"

Descripción: El usuario podrá registrar una incidencia laboral de cualquiera de los miembros de equipo seleccionando la opción "registrar incidencia laboral" y en la misma opción podrá visualizar el detalle de los registros realizados.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Registrar incidencia laboral". - En el panel izquierdo aparecerá una tabla con el detalle las incidencias registradas y un botón en donde podrá ingresar una nueva incidencia. - El usuario llenará el formulario y lo guardará, luego de ello la tabla con detalle de las incidencias registradas se actualizará con la nueva información.

Resultado esperado: Al seleccionar la opción registrar incidencia el usuario podrá realizarla previo llenado de un formulario.



© P

rop

ia


81





I) Registrar reuniones qualitas

Figura 40

Interfaz de registro de reuniones qualitas




Nombre de la prueba: Eliminar reunión qualitas

Descripción: El usuario podrá registrar un evento qualitas seleccionando la opción "registrar reunión qualitas" y en la misma opción podrá visualizar el detalle de los eventos registrados, así mismo podrá editar y eliminar cualquiera de los registros.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Registrar reunión qualitas". - En el panel izquierdo aparecerá una tabla con el detalle las incidencias registradas y un botón que le permitirá eliminar cualquiera de ellas. - El usuario confirmará la eliminación del registro, luego de ello la tabla con detalle de las incidencias registradas se actualizará con la nueva información.

Resultado esperado: Al seleccionar la opción eliminar el usuario podrá eliminar el registro previa confirmación.



© P

rop

ia


82






En la reunión en equipo se presentó al cliente los requisitos







Figura 41

Gráfico Burndown de la segunda iteración




7.3.6 Retrospectiva

El equipo analiza los valores durante la iteración registrando

los aspectos resaltantes producidos durante el desarrollo de

la iteración.


se procedió a recopilar los puntos más relevantes,




© P

rop

ia


83





Figura 42

Revisión de las actividades realizadas



Se apreció mayor colaboración por parte de los


La disponibilidad de tiempo por parte de cada uno de

los miembros del equipo fue mayor, debido a que

organizaron los tiempos dedicados al proyecto y a las

tareas paralelas que entorpecieron el desarrollo en la

primera iteración.

A pesar de que la disponibilidad de tiempo fue mayor,

aún no fue suficiente para cumplir con los

entregables en los plazos acordados, por lo que se

plantea una nueva estrategia para la tercera

iteración.

El rendimiento del equipo se incrementando con lo

que logró mejorar la productividad en comparación

con la obtenida en la primera iteración.


mejorar el incremento de la iteración brindando una

colaboración activa.

© P

rop

ia


84





7.4 Tercera iteración



estructurar la tercera iteración las cuales se muestran en la

tabla 51.

Tabla 51: Reuniones para la tercera iteración










registradas en cada una de las historias de usuario de la

tercera iteración.

A) Sprint Backlog


desarrollar en la tercera iteración:

- Historia H17: Autentificar movilizador.

- Historia H18: Visualizar maqueta de movilizador.

- Historia H19: Visualizar detalle de indicadores de movilizador.

- Historia H20: Visualizar detalle de contactos de equipo

movilizador.

- Historia H21: Visualizar detalle de no transferencias de equipo

movilizador.

- Historia H22: Aprobar reclamos de ventas de equipo movilizador.

- Historia H23: Aprobar reclamos de indicadores de equipo

movilizador.

- Historia H24: Registrar incidencias de ventas de equipo

movilizador.

- Historia H25: Registrar reuniones qualitas.


85





- Historia H26: Generar reportes de incidencias.

La tabla 52 muestra el detalle de tareas de la tercera iteración.

Tabla 52: Tareas de la tercera iteración

Iteración en días

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Historia/Tarea 120 120 110 100 90 80 70 60 50 40 30 20 10 0

Autentificar movilizador

Diseñar y crear las tablas de movilizador 2 2

Conectar la interfaz de logueo con la base de datos 2 2

Visualizar maqueta de movilizador

Desarrollar la interfaz de maqueta 7 7 1

Conectar la interfaz con la base de datos 9 9 9

Visualizar detalle de indicadores de movilizador

Diseñar las interfaces de indicadores 7 7 7 7

Conectar las interfaces con la base de datos 9 9 9 9 6

Visualizar detalle de contactos de equipo movilizador

Diseñar la interfaz de detalle de contactos 3 3 3 3 3

Conectar la interfaz con la base de datos 2 2 2 2 2 1 Visualizar detalle de no transferencias de quipo

movilizador

Desarrollar la interfaz de no transferencias 3 3 3 3 3 3

Conectar la interfaz con la base de datos 2 2 2 2 2 2

Aprobar reclamos de ventas de equipo movilizador

Desarrollar la interfaz de reclamos de ventas 10 10 10 10 10 10 6

Conectar la interfaz con la base de datos 5 5 5 5 5 5 5 1 Aprobar reclamos de indicadores de equipo

movilizador

Desarrollar la interfaz de reclamos de indicadores 10 10 10 10 10 10 10 10 1

Conectar la interfaz con la base de datos 5 5 5 5 5 5 5 5 5

Registrar incidencias de ventas de equipo movilizador

Diseñar y crear las tablas de incidencias de ventas 2 2 2 2 2 2 2 2 2

Desarrollar la interfaz de incidencias de ventas 10 10 10 10 10 10 10 10 10 8

Conectar la interfaz con la base de datos 5 5 5 5 5 5 5 5 5 5 3

Registrar reuniones qualitas

Desarrollar la interfaz de reuniones qualitas 12 12 12 12 12 12 12 12 12 12 12 5


Generar reportes de incidencias

Desarrollar los botones de generar reportes 5 5 5 5 5 5 5 5 5 5 5 5 5




86





La figura 43 muestra el trabajo por días de la segunda

iteración.

Figura 43

Esfuerzo por horas durante el desarrollo de la tercera iteración

B) Scrum Taskboard


terminadas, en proceso y pendientes de la segunda

iteración.

Figura 44

Pizarra de tareas a desarrollar durante la tercera iteración

© P

rop

ia

© P

rop

ia


87








del sistema correspondiente a la tercera iteración.

Figura 45


© P

rop

ia


88






A) Autentificación de usuario supervisor

Figura 46

Interfaz de acceso al sistema





Descripción: El usuario, al iniciar la aplicación observará una ventana de acceso a la aplicación, en la que se le solicitará el nombre de usuario y la contraseña. El usuario debe introducir estos campos y cuando cumple que el usuario no está dado de alta en el sistema, no tendrá acceso a la aplicación






© P

rop

ia


89





B) Visualizar maqueta de movilizador

Figura 47

Interfaz de maqueta de movilizador




Nombre de la prueba: Visualizar maqueta actual del movilizador

Descripción: El usuario, seleccionará del menú la opción "Maqueta actual", y en el panel derecho se mostrará una tabla con todos los indicadores medidos y la nota final a obtenida a la fecha. La aplicación sólo mostrará la información del mes en curso, además del detalle de cada miembro de su equipo

Condiciones en ejecución: El usuario deberá de tener datos registrados en el sistema.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Maqueta actual". - En el panel izquierdo aparecerá una tabla con la nota por cada indicador y la nota final obtenida. - El usuario podrá visualizar también la nota final de cada miembro de su equipo.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el resumen de su maqueta actual y la de su equipo.



© P

rop

ia


90





C) Visualizar detalle de indicadores de movilizador

Figura 48

Interfaz de detalle de indicadores de movilizador




Nombre de la prueba: Visualizar detalle del indicador "Efectividad productiva"

Descripción: El usuario, seleccionará del menú la opción "Efectividad productiva", y en el panel derecho se mostrará una tabla con la composición del indicador. Adicionalmente podrá observar la evolución de cada miembro de su equipo.

Condiciones en ejecución: El usuario deberá tener registros de marcaciones abordadas de lo contrario el sistema no mostrará ningún tipo de información.

Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Efectividad productiva". - En el panel izquierdo aparecerá una tabla con la composición del indicador y además la evolución de cada miembro de su equipo. - El usuario podrá navegar de manera didáctica por la información mostrada.

Resultado esperado: Al seleccionar la opción el usuario podrá visualizar el detalle del indicador seleccionado.



© P

rop

ia


91





D) Visualizar detalle de contactos de equipo movilizador

Figura 49

Interfaz de detalle de contactos de movilizador




Nombre de la prueba: Filtro de contactos de un miembro del equipo.



Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de ventas". - En el panel izquierdo aparecerán todos los registros de sus contactos. - El usuario filtrará del campo "Asesor" los registros de algún miembro de su equipo. - El sistema muestra los registros que cumplen con los valores filtrados.




© P

rop

ia


92





E) Visualizar detalle de no transferencias de equipo

movilizador

Figura 50

Interfaz de detalle de “No transferencias” de equipo movilizador




Nombre de la prueba: Filtro de registros no transferidos por asesor



Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Detalle de no transferencias". - En el panel izquierdo aparecerán todos los registros de sus no transferencias. - El usuario filtrará del campo "Asesor" los registros de alguno de los miembros de su equipo. - El sistema muestra los registros que cumplen con los valores filtrados.



© P

rop

ia


93






F) Aprobar reclamos de ventas de equipo movilizador

Figura 51

Interfaz para aprobar reclamos de ventas

Tabla 58: Prueba de aceptación H22



Nombre de la prueba: Aprobar reclamo de ventas de un asesor

Descripción: El usuario podrá visualizar el detalle de todos los reclamos de los miembros de su equipo seleccionando la opción "Reclamos de ventas" del panel izquierdo de la aplicación. Así mismo podrá aprobar o rechazar el reclamo.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Reclamos de ventas". - En el panel izquierdo aparecerá una tabla con el detalle de los reclamos que han realizado los miembros de su equipo. - El usuario aprobará uno de los registros seleccionados.

Resultado esperado: Al seleccionar la opción la opción aprobar reclamo, el registro se actualizará con la nueva información.



© P

rop

ia


94





G) Aprobar reclamos de indicadores de equipo

movilizador

Figura 52

Interfaz para aprobar reclamos de indicadores




Nombre de la prueba: Aprobar reclamo de indicador de asesor

Descripción: El usuario podrá visualizar el detalle de todos los reclamos de los miembros de su equipo seleccionando la opción "Reclamos de indicadores" del panel izquierdo de la aplicación. Así mismo podrá aprobar o rechazar el reclamo.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Reclamos de indicadores". - En el panel izquierdo aparecerá una tabla con el detalle de los reclamos de indicadores que han realizado los miembros de su equipo. - El usuario aprobará uno de los registros seleccionados.

Resultado esperado: Al seleccionar la opción la opción aprobar reclamo de indicador, el registro se actualizará con la nueva información.



© P

rop

ia


95





H) Registrar incidencia de ventas de equipo movilizador

Figura 53

Interfaz para registrar incidencia de ventas




Nombre de la prueba: Registrar incidencia "Caída aplicativo multigestión"

Descripción: El usuario podrá registrar una incidencia de ventas seleccionando la opción "registrar incidencia de ventas" y en la misma opción podrá visualizar el detalle de los registros realizados.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Registrar incidencia de ventas". - En el panel izquierdo aparecerá una tabla con el detalle las incidencias registradas y un botón en donde podrá ingresar una nueva incidencia. - El usuario llenará el formulario y lo guardará, luego de ello la tabla con detalle de las incidencias registradas se actualizará con la nueva información.

Resultado esperado: Al seleccionar la opción la opción registrar incidencia el usuario podrá realizarla previo llenado de un formulario.



© P

rop

ia


96





I) Registrar reuniones qualitas

Figura 54

Interfaz de registro de reuniones qualitas




Nombre de la prueba: Editar reunión qualitas

Descripción: El usuario podrá registrar un evento qualitas seleccionando la opción "registrar reunión qualitas" y en la misma opción podrá visualizar el detalle de los eventos registrados, así mismo podrá editar y eliminar cualquiera de los registros.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Registrar reunión qualitas". - En el panel izquierdo aparecerá una tabla con el detalle las incidencias registradas y un botón que le permitirá editar cualquiera de ellas. - El usuario confirmará la eliminación del registro, luego de ello la tabla con detalle de las incidencias registradas se actualizará con la nueva información.

Resultado esperado: Al seleccionar la opción editar el usuario podrá actualizar el registro previa confirmación.



© P

rop

ia


97





J) Generar reporte de incidencias

Figura 55

Interfaz para generar reportes de incidencias




Nombre de la prueba: Generar reporte de incidencia de ventas

Descripción: El usuario podrá seleccionar la opción incidencia de ventas y será dirigido a un interfaz donde se mostrará el detalle de las incidencias registradas, a su vez tendrá la opción de exportar los registros mediante el botón exportar ubicado en la parte superior de la interfaz.


Entrada: - El usuario se encuentra en la interfaz principal de la aplicación. - En el panel izquierdo deberá seleccionar la opción "Registrar incidencia de ventas". - En el panel izquierdo aparecerá una tabla con el detalle las incidencias registradas y un botón que le permitirá exportar la totalidad de los registros.

Resultado esperado: Al seleccionar la opción exportar el usuario podrá exportar la totalidad de los registros ingresados en la base de datos.



© P

rop

ia


98






En la reunión en equipo se presentó al cliente los requisitos







Figura 56

Gráfico Burndown de la tercera iteración




7.4.6 Retrospectiva

El equipo analiza los valores durante la iteración registrando

los aspectos resaltantes producidos durante el desarrollo de

la iteración.


se procedió a recopilar los puntos más relevantes,




© P

rop

ia


99





Figura 57

Revisión de las actividades realizadas en la tercera iteración



Se apreció mayor colaboración por parte de los


La disponibilidad de tiempo por parte de cada uno de

los miembros del equipo fue mayor, debido a que

organizaron los tiempos dedicados al proyecto y a las

tareas paralelas que entorpecieron el desarrollo en la

primera iteración.

A pesar de que la disponibilidad de tiempo fue mayor,

aún no fue suficiente para cumplir con los

entregables en los plazos acordados, por lo que se

plantea una nueva estrategia para la tercera

iteración.

El rendimiento del equipo se incrementando con lo

que logró mejorar la productividad en comparación

con la obtenida en la primera iteración.


mejorar el incremento de la iteración brindando una

colaboración activa y con ello un incremento de

productividad.

© P

rop

ia


100





7.5 Fase de implementación

Para Kniberg (2007, p56) la fase de implementación es muy relevante

para la puesta en marcha del sistema, incluyendo el sistema validado y

probado, los manuales operativos, personal capacitado para su

utilización, requerimientos funcionales totalmente desarrollados y el

cumplimiento de toda documentación acordada al inicio del proyecto.

Por tal motivo, habiendo culminado la tercera iteración, se procedió a

realizar la implementación final del proyecto integrado, el resultado fue

satisfactorio como se demostró en cada una de las pruebas de

aceptación realizadas.

8. Análisis de los resultados

Después de la implementación del sistema web se observó lo siguiente:

a) El tiempo de entrega de reportes sin el sistema web era de 84.97 minutos y

con el uso del sistema se redujo significativamente a 0 después del

procesamiento de la información. Los resultados demuestran que el

sistema web redujo el tiempo de entrega de los reportes en 100%.

Por tanto se afirma que el sistema web disminuye el tiempo de entrega de

reportes a supervisores, movilizadores de ventas cruzadas y asesores, y se

logra de esta forma cumplir con el primer objetivo del presente trabajo.

b) El tiempo que utilizaban los supervisores y movilizadores de ventas

cruzadas en armar reportes personalizados para entregárselos a sus

asesores a cargo sin el sistema web era de 10.85 minutos por cada

supervisor y movilizador de ventas cruzadas. Con el uso del sistema web

se redujo a 0 minutos, debido a que los asesores pueden revisar sus

indicadores desde sus estaciones sin la necesidad de que sus supervisores

los impriman en un papel y se los entreguen. Por tanto se afirma que el

sistema web incrementa el tiempo efectivo en la gestión de actividades de

supervisores y movilizadores de ventas cruzadas en 100%. De este modo

se cumple con el segundo objetivo del trabajo.

Finalmente se puede indicar que la implementación del sistema web se

implementó con éxito y cumplió con los objetivos planteados.

9. Conclusiones

Después del desarrollo de la investigación y la implementación del sistema web

para el seguimiento de ventas cruzadas se llegó a las siguientes conclusiones:


101





a) Un sistema web es una herramienta eficiente para disminuir el tiempo de

entrega de reportes a los distintos actores del proceso de ventas cruzadas,

este hecho se evidencia al demostrar que el mismo se reduce en 100%.

b) Un sistema web es una herramienta eficiente para incrementar el tiempo

efectivo en la gestión de actividades de los distintos actores del proceso de

ventas cruzadas debido a que redujo en 10.85 minutos el tiempo empleado

en actividades que no eran relevantes para el éxito del proceso.

c) Utilizar SCRUM en la implementación de un sistema web para el

seguimiento de ventas cruzadas ha sido provechoso debido a que durante

el desarrollo se observó que era necesario constantes interacciones con los

involucrados para determinar el enfoque adecuado que debía aplicarse a la

solución tecnológica. Además es necesario acotar que los procesos de

ventas cruzadas son bastante dinámicos y requieren una metodología

flexible, para lo cual SCRUM se acopló de manera excepcional.

d) Las empresas de CONTACT CENTER se encuentran en una época de

máximo apogeo por lo que muchos de los procesos se van creando de

manera desordenada y en la mayoría de casos se requiere abandonar

algunos para iniciar con otros que son más importantes (ya sean procesos

nuevos o procesos antiguos, mal estructurados, que están experimentando

fallas). Por tanto, el desarrollo de proyectos en este contexto está

amenazado por la aparición de requerimientos más importantes o por el

desorden.

10. Sugerencias

La presente investigación ha ofrecido un marco metodológico para el desarrollo

de un sistema web aplicado a un caso de estudio en concreto en el que se

demostró los beneficios de su implementación principalmente para la reducción

de tiempos, en base ello se plantean algunas sugerencias para futuras líneas

de investigación:

a) La gestión de ventas cruzadas es una gestión de indicadores cambiantes,

pero que siguen un patrón establecido, por lo que se recomienda crear una

plataforma web universal para el seguimiento de indicadores de ventas

cruzadas, en la que cada empresa pueda personalizar la información que

muestra a los usuarios.

b) En relación con el ítem anterior y para procesos maduros, se recomienda

utilizar RUP de modo que se pueda documentar de manera adecuada el

proceso. Por el contrario si se desea implementar el sistema en un proceso

cambiante es preferible utilizar SCRUM debido a la flexibilidad que plantea

en el desarrollo.


102





BIBLIOGRAFÍA

Alfonso Fernández, J., & Díaz Guzmán, M. Á. (2008). Sistema de control de

inventarios y facturación de la Licorería Tropical Club de Girardot. Recuperado el 29

de Setiembre de 2014, de

http://repository.uniminuto.edu:8080/jspui/bitstream/10656/393/1/TTI_DiazMiguelAngel

_08.pdf

APECCO. (2014). APECCO. Recuperado el 29 de Setiembre de 2014, de

http://www.apecco.org/

Calo Pallo, W. P., & Ortiz Iza, C. O. (Julio de 2012). Sistema de gestión de ventas para

el centro de servicios informáticos "La Biblioteca". Recuperado el 29 de Setiembre de

2014, de http://repositorio.utc.edu.ec/bitstream/27000/1409/1/T-UTC-0988.pdf

Conallen, J. (2003). Building Web Applications with UML. Boston: Pearson Education

Inc.

Del Perú, T. (2012). Atento. Recuperado el 29 de Setiembre de 2014, de

http://www.atento.com/informe2012/informe.html

Frutos Sastre, M. J. (2012). Disposición y venta de producto. Madrid: Ediciones

Paraninfo.

López-Pinto Ruiz, B., Mas Machuca, M., & Viscarri Colomer, J. (2008). Los pilares del

marketing. Barcelona: Ediciones UPC.

Lujan Mora, S. (2002). Programación de aplicaciones web: historia, principios básicos

y clientes web. España: Editorial Club Universitario.

Matta Catacora, P. E. (2011). Sistema Web para el control de ventas y facturación

usando agentes inteligentes. Recuperado el 29 de Setiembre de 2014, de

http://bibliotecadigital.umsa.bo:8080/rddu/bitstream/123456789/1868/1/T-2308.pdf

Novoa Hernández, P. (Julio de 2008). Sistema para la gestión de información de

presupuestos de ventas: una solución a la medida. Recuperado el 29 de Setiembre de

2014, de http://www.redalyc.org/pdf/1815/181518069005.pdf

Setó Pamies, D. (2004). De la calidad del servicio a la fidelidad del cliente. Madrid:

ESIC Editorial.

Sullivan, F. &. (2014). Analysis of Contact Center Outsoursing Services Market in Peru.

Latinoamérica: Frost & Sullivan.

Villa Gutiérrez, M. A. (Marzo de 2007). Sistema para el control de ventas e inventarios

de la empresa Antiguo Arte Europeo. Recuperado el 29 de Setiembre de 2014, de

http://www.uaeh.edu.mx/docencia/Tesis/icbi/licenciatura/documentos/Sistema%20para

%20el%20control%20de%20ventas%20e%20inventarios.pdf


103





ANEXOS

ANEXO N°1: Entrevista con el responsable de ventas cruzadas de la jefatura Oro de

Teleatento del Perú S.A.C.


104






105





Nro FechaTiempo de

entrega (min)

Promedio Tiempo

de entrega

Tiempo de

procesamiento (min)

Promedio tiempo de

procesamiento

1 15/10/2014 0 11

2 15/10/2014 19 13

3 15/10/2014 42 9

4 15/10/2014 58 9

5 15/10/2014 73 7

6 15/10/2014 86 5

7 15/10/2014 95 9

8 15/10/2014 110 9

9 15/10/2014 125 9

10 15/10/2014 140 10

11 17/10/2014 0 12

12 17/10/2014 21 10

13 17/10/2014 39 15

14 17/10/2014 65 7

15 17/10/2014 78 6

16 17/10/2014 89 3

17 17/10/2014 95 12

18 17/10/2014 115 6

19 17/10/2014 125 18

20 17/10/2014 155 15

21 20/10/2014 0 21

22 20/10/2014 35 6

23 20/10/2014 45 8

24 20/10/2014 59 36

25 20/10/2014 119 3

26 20/10/2014 125 6

27 20/10/2014 136 6

28 20/10/2014 147 10

29 20/10/2014 165 7

30 20/10/2014 178 12

2539 84.63 310 10.33

Ficha de observación - Tiempo de entrega de reportes y tiempo de procesamiento para supervisores

TOTAL

Proceso observado

Ubicación

Empresa en donde se investiga

Practicante Juárez Manayay Adriano Mauricio

Teleatento del Perú S.A.C.

Av. La Molina 200

Seguimiento de ventas cruzadas

74.8

78.2

100.9

9.1

10.4

11.5

ANEXO N°2: Ficha de observación para determinar los tiempos utilizados por los

supervisores


106





ANEXO N°3: Ficha de observación para determinar los tiempos utilizados por los

movilizadores de ventas cruzadas

Nro FechaTiempo de

entrega (min)

Promedio Tiempo

de entrega

Tiempo de

procesamiento (min)

Promedio tiempo de

procesamiento

1 16/10/2014 0 9

2 16/10/2014 15 15

3 16/10/2014 40 16

4 16/10/2014 68 10

5 16/10/2014 86 9

6 16/10/2014 101 18

7 16/10/2014 132 9

8 16/10/2014 147 12

9 16/10/2014 168 8

10 16/10/2014 182 12

11 21/10/2014 0 11

12 21/10/2014 19 7

13 21/10/2014 31 10

14 21/10/2014 48 14

15 21/10/2014 72 7

16 21/10/2014 85 16

17 21/10/2014 113 17

18 21/10/2014 142 15

19 21/10/2014 167 17

20 21/10/2014 196 13

21 24/10/2014 0 9

22 24/10/2014 16 10

23 24/10/2014 33 9

24 24/10/2014 49 11

25 24/10/2014 68 7

26 24/10/2014 80 12

27 24/10/2014 101 9

28 24/10/2014 116 10

29 24/10/2014 134 9

30 24/10/2014 150 10

2559 85.30 341 11.37

74.7 9.6

TOTAL

Proceso observado Seguimiento de ventas cruzadas

93.9 11.8

87.3 12.7

Ficha de observación - Tiempo de entrega de reportes y tiempo de procesamiento para movilizadores

Practicante Juárez Manayay Adriano Mauricio

Empresa en donde se investiga Teleatento del Perú S.A.C.

Ubicación Av. La Molina 200

Documents

Sistema Web para el Seguimiento de ventas Cruzadas