Sistema
“Control de Gestión de Venta”
Documento Visión y Alcances
Proyecto para Brinks Chile
Contenido
{
Contexto del Proyecto: el cliente.
{
Motivación y Necesidad
{
Visión de Requerimientos y Detalle
Preliminar
{
Alcances y Restricciones
{
Plataforma Tecnológica
{
Calendario General y Fases
{
Detalles de Requerimientos
El Cliente y su Contexto
{
Brinks Chile es una filial local de Brinks
Internacional que presta servicios de
transporte y administración de valores:
z
Transporte de Valores
z
Procesamiento de Valores
z
Atención Integral de Cajeros Automáticos
z
Atención Integral a Plazas de Peaje
z
Atención Integral de Centros de Pago
z
Servicios de Transporte de Valores
Internacional
Key Account Manager Cliente
El Cliente y su Contexto
{
En particular, la gerencia comercial de
Brinks se focaliza en la atención de
clientes que requieren de algunos de los
servicios ofrecidos.
{
Parte de su misión:
z
“Cumplir siempre nuestros COMPROMISOS con los
clientes.”
z
“Construir sobre nuestro CORE BUSINESS de protección,
transporte y proceso de valores para Bancos, Retail y
otras organizaciones comerciales y de gobierno.”
z
“Desarrollar soluciones innovadoras basadas en
TECNOLOGÍA, que se anticipen a las necesidades
emergentes de nuestros clientes.”
El Cliente y su Contexto
{
Gestión de Venta, depende de:
z
la adecuada atención de los contactos
con clientes
z
y en el análisis de la gestión de venta
para detectar posibilidades interesantes
de negocio.
Key Account Manager Cliente
El Cliente y su Contexto
{
Cada cliente es atendido por un
ejecutivo de cuenta, quien lleva
adelante las gestiones comerciales
con dicho cliente, lo cual incluye un
ciclo de contactos que van desde el
prospecto de venta, a la atención
post-venta, pasando por cotización,
venta y coordinación de servicios.
Key Account Manager Cliente
Motivación y Necesidad
{
Actualmente no existe una manera sistemática de
hacer seguimiento y gestión sobre las
cotizaciones y contactos de venta realizados.
{
Más allá, no existe una manera de realizar gestión
sobre los contactos realizados, de modo de
optimizar los esfuerzos del equipo de venta sobre
la detección de buenas oportunidades.
{
Por ello, la jefatura de la gerencia comercial no
tiene herramientas para mejorar la gestión de
oportunidades de negocio ni medir el rendimiento
de los ejecutivos (KAM).
Visión de Solución
{
Se requiere una solución que:
z
Se implemente y utilice en el área comercial.
z
Sea de fácil uso: interfaz amigable e intuitiva,
así como fácil de ejecutar.
z
Sea fácilmente instalable por personal de la
gerencia comercial, o en su defecto por
personal técnico de OpenSoft.
z
Registre lo realizado por cada uno de sus
ejecutivos (KAM - Key Account Manager) a
cargo y permita a sus jefaturas consultar esta
información,
z
Permita consultar información relacionada con
los contactos de negocio y así determinar
oportunidades por explorar.
Visión General de la Solución
Gerencia Comercial Consulta y Reportes
Sistema de Control de Gestión Registro de
contactos y actividades
KAM
(Key Account Manager) Clientes
Información Básica
{
Cliente
z
Datos contacto y
propios.
z
KAM
z
Servicios
contratados.
{
Actividad c/Cliente
z
Fecha.
z
Tipo.
z
Comentarios.
z
Estado.
{
Cotización
z
Fecha
z
Servicio
z
Detalles
Alcances y Restricciones
{
La solución podrá operar en forma
autónoma, no involucrando la
alimentación de información desde, ni
hacia ningún otro sistema de la empresa.
{
Se requiere que la solución esté
disponible y accesible para diversos
ejecutivos del área comercial de la
empresa.
{
Es factible y posiblemente necesario, que
la aplicación funcione en forma local en el
computador de cada ejecutivo.
Plataforma Tecnológica
{
Servidores disponibles en Brinks
para producción de la posible
solución.
z
Base de datos: servidor de testing con
SQL 2000 Estándar y Reporting Services
z
Web: servidor Windows 2003 Estándar,
IIS 6.0, Framework .Net 1.1 y 2.0
{
Características de los computadores
de los usuarios de la solución.
z
Pentium 4, 512 MB RAM, Windows XP
Participación y Roles
Rol
Función
Quién
Product
Owner
Representar los intereses de Brinks en la solución funcional. Definir requerimientos básicos y priorizarlos.
BRINKS
Sebastián Mena
Raúl Macías
(OpenSoft)User
Experience
Representar intereses de los usuarios de Brinks
que utilizarán el sistema en el día a día.
BRINKS
Sebastián Mena
Deployment
Manager
Velar por los aspectos técnicos de la solución con vista a su explotación en regimen en ambiente de producción.
BRINKS
Raúl Macías
(OpenSoft)Program
Manager
Velar por el cumplimiento del plan de trabajo y
facilitar la comunicación entre las partes.
PUC
Rodrigo Sandoval
Developers
Construir y codificar las partes necesarias de la solución, estimando esfuerzos y definiendo aspectos técnicos relacionados.PUC
Alumnos IIC3140
Testing
Definir y realizar casos de prueba que verifiquenla correctitud de los elementos construidos, así como entregar las funcionalidades
adecuadamente empaquetadas al cliente.
PUC
Calendario Inicial y Fases
{
Fase de Visión/Concepción
(contexto y alcances):
20 abril al 09 mayo 2007.
z Definición de equipo de trabajo. z Confección de este documento. z Análisis general de arquitectura. {
Fase de Diseño/Elaboración:
10 al 25 mayo 2007.
z Levantamiento de Requerimientos detalle (11 al 15 mayo).
z Armado ambientes de desarrollo y pruebas.
z Análisis de paquetes de software requeridos/anteriores.
z Planificación detallada de desarrollo.
z Definición de casos de pruebas. z Asignación de trabajo por
módulos.
z Implementación de historias y tareas de desarrollo iniciales (incluyendo modelo de datos).
{
Fase de Construcción/Desarrollo:
26 mayo al 10 junio 2007
z Construcción de funcionalidades. z Testing de funcionalidades y correcciones correspondientes. z Iteración 1 (05 junio) Æ instalación y demostración. {Fase de Estabilización/Deployment
11 al 28 junio.
z Implementación de cambios y ajustes.z Desarrollo de historias restantes. z Instalación en ambiente de
producción.
z Pruebas de funcionalidades y de instalación.
z Iteración 2 (26 junio).
{
Cierre del Proyecto: 28 de junio.
z Entrega de versión final de códigofuente, ejecutables y documentación de
Roles de Team de Desarrollo
{
Developers
z
Trabajar en pares: Pair-Programming
zAdoptar TDD
z
Tener Repositorio Código centralizado e integrar
frecuentemente
z
Asistir a “Daily” Scrum
zAsistir a Sprint Meeting
z
Mantener al día el Sprint Plan
zAdoptar Standards de código
zAdoptar vocabulario común.
{
Tester
z
Documentar Backlogs
zCasos de Prueba
z
Pruebas y resultados
zDemostraciones
z