Plan de Proyecto: Pablo Emmanuel Bazan

Plan De Proyecto
6-9-2022
Pablo Emmanuel Bazan

índice
Historia de Cambio..............................................................................................................................2
1. Introducción......................................................................................................................................2
1.1 Antecedentes...................................................................................................................................2
1.2 Situación Actual..............................................................................................................................3
1.3 Objetivo...........................................................................................................................................4
1.4 Justificación del Proyecto..............................................................................................................5
1.5 Beneficios del Proyecto...................................................................................................................5
1.6 Supuestos.........................................................................................................................................5
1.7 Propósito del Proyecto...................................................................................................................5
1.8 Director de Proyecto / Nivel de autoridad ................................................................................6
2. Project Charter.................................................................................................................................6
3. Alcance del Proyecto........................................................................................................................9
3.1 Enunciado del Alcance de Proyecto..............................................................................................9
3.2 Creacion de la EDT......................................................................................................................12
Explicacion del Diccionario EDT.........................................................................................................12
3.2.1 Diccionario de la EDT/WBS.....................................................................................................12
3.2.2 Diccionario de la EDT...............................................................................................................13
3.3 Plan de Gestion de Cambios........................................................................................................17
4. Planificacion de Cronograma........................................................................................................20
4.1 Cronograma de Hitos...................................................................................................................20
4.2 Planificacion de Proyecto.............................................................................................................21
4.2.1 Secuenciar Actividades..............................................................................................................21
4.2.2 Definicion de Actividades..........................................................................................................21
4.2.3 Atributos de las actividades......................................................................................................22
Plan de Costos.....................................................................................................................................29
Estimación inicial de tiempo................................................................................................................29
Estimación inicial de costes..................................................................................................................30
Scrum..................................................................................................................................................31
Equipo..................................................................................................................................................31
Objetivo general...................................................................................................................................32
Alcance................................................................................................................................................32
Conclucion..........................................................................................................................................37
1
Bibliografia.........................................................................................................................................37
Historia de Cambio
Versión # Implemented Revision Approval Approval Reason

By Date Date Date
1.0 Belén Quiros 6-Julio-2022 6-Julio-2022 Creación del
Documento
2.0 Florencia Actualización de
Fernández detalle
2.1 Equipo Documentos Externos
2.2 Pablo Bazán Metodología Scrum
1. Introducción
1.1 Antecedentes
En el presente trabajo abordaremos el proyecto de desarrollo de un portal que permita la
recepcion y centralizacion de todos los comprobantes de proveedores que cada tienda recibe en
forma local, que permita agilizar, automatizar y hacer ma eficiente el proceso de la gestión de
pago que existe actualmente.
El portal ayudara a reducir el trabajo manual, automatizar el proceso, reducir errores, optimizar
tiempo, trazabilidad e integridad del flujo de trabajo.
Es por este motivo que se comenzó a diseñar un proyecto que ayudara a administrar la
información de una manera más eficiente ágil y segura.
La compañía ha crecido un 50% en ventas en los últimos tres años, esto género que el nivel de
facturación y documentos a pagar que se deben administrar, también se vio impactado en un %
similar, por lo que el proceso que hoy se lleva a cabo dejo de ser tan eficiente, generando un back
log significativo que no solo está impactando en los plazos de pagos, sino que también empezó a
afectar la relación comercial con algunos de sus principales proveedores TOP.
Lo que se está buscando es una solución que permita tanto, acotar los tiempos en el proceso como
también lograr hacerlo más eficiente y con la menor cantidad de recursos asignados a la tarea, se
necesita administrar las diferentes reglas de negocio que permita soportar volumen y los
estándares que necesita la operación.
2
Hoy en día el proceso actual necesita 4 recursos que se encargan de recepcionar, clasificar e
identificar errores en las imágenes recibidas, una a una (imagen por imagen) las cuales en el caso
de detectar algún error deben ser reclamadas a las tiendas responsables para su reenvió, esto
genera la necesidad de un recurso adicional exclusivo que esté dando seguimiento de estos
reenvió, para ingresarlos de forma prioritaria al flujo de trabajo (debido a la demora que se
produce, entre la detección del error , el reclamo y el reenvió de la tienda) como también estará
realizando el reclamo de los documentos que se identifican como, sin registro.
Ahora bien, en el caso de que la imagen llegue de forma correcta, el recurso deberá tipear de
forma manual la información de cabecera de documento, junto a su soporte de recepción. Esta
información es cargada por medio de la herramienta que de “Pre Screener”.
Dicha herramienta permite registrar los documentos que llegan escaneados de forma diaria a casa
central de cada una de las diferentes tiendas (2500 a 3000 doc. al día). A su vez la herramienta
tiene la funcionalidad de arrojar un reporte el cual va a identificar tanto los datos de cabeceras
cargados, como también las diferentes categorías, tipo de proveedores, tipo de documentos y
vencimientos, que hacen al orden de las prioridades y clasificación que necesita la operación.
Una vez se tienen el reporte se agrupan los documentos según su categoría y prioridad para poder
enviar de forma ordenada a través de los diferentes flujos de trabajo por medio de la plataforma
de BPM del equipo de escaneo al equipo de cuentas a pagar, que será el encargado de
contabilizar dichos doc. en su ERP.
1.2 Situación Actual

Storemarket es uno de los reteilers más importantes de la Argentina, con una estructura de 90
tiendas y 2 centros de distribuciones a lo largo de todo el país.
Cuenta con un robusto proceso de reabastecimiento y recepción de mercadería administrado por 3
diferentes sistemas que se llevan a cabo todos los días en cada tienda de todo el país
interactuando con más de 3000 proveedores que hoy se encuentran activos.
 El proceso comienza cuando desde casa central, el sector comercial emite una orden de
compra (OC).
3
 Para poder realizar la recepción en la tienda, el proveedor debe solicitar un turno para luego
concurrir en el día y horario asignado con los productos, la OC y la factura.
 En la recepción de la tienda se comprueba que toda la documentación se encuentre correcta
y se procede a la descarga.
 Se imprime el conforme de entrega por duplicado uno que se llevará el proveedor y el otro
se adjunta a la factura física, que luego deberá enviarse por mail a la casilla de facturas
centralizadas FactCentral@Storemarket.com que es administrada por el equipo del centro
de escaneo en casa central.
 Al finalizar la jornada el responsable de recepción de cada tienda debe asegurar el envió de
cada documento para asegurar el flujo de contabilización y pagos de cada factura en
tiempo y forma.
 Una vez que el documento llegaba a la casilla los usuarios de casa central deben acceder
cada día a descargar las imágenes de las tiendas, controlar su calidad, que venga
acompañada de su documento de recepción, llevar un registro en una planilla de cálculo
identificando los documentos que llegaron correctamente y los que no para continuar con
el proceso de contabilización para los que están ok o reclamos a las tiendas de los
documentos que llegan con error.
En estos últimos 2 puntos punto en donde el proyecto se va a enfocar para lograr identificar los
puntos de dolor que ayuden a agilizar y eficientizar dicho proceso ya que hoy se considera el
punto más débil dentro del flujo de trabajo que impacta en el resto del proceso debido a que es un
trabajo con un alto grado de intervención manual.
1.3 Objetivo
Desarrollo de un portal que permita la recepcion y centralizacion de todos los comprobantes de
proveedores que cada tienda recibe en forma local, que permita agilizar, automatizar y hacer ma
eficiente el proceso de la gestión de pago que existe actualmente.
4
1.4 Justificación del Proyecto
Disminución de reclamos y de esta forma mejorar la relación comercial, ampliar la cantidad de
proveedores satisfechos e incrementar volúmenes luego de la implementación vs proceso actual y
pagos a tiempo
1.5 Beneficios del Proyecto

Desarrollo de portal el cual permita la recepcion y centrlizacion de informacion de nuestros
proveedores, fácil de utilizar donde los usuarios se sientan cómodos que permita agilizar,
automatizar y hacer más eficiente el proceso, que permita responder a la alta demanda de una
manera sencilla y costo efectiva.
1.6 Supuestos
. El proveedor del desarrollo del portal deberá firmar un contrato de confidencialidad
. El sistema provee servicio 24/7
1.7 Propósito del Proyecto

Haremos énfasis en el proyecto, sus necesidades, la etapas y acciones que lo componen. Será una
guía en el curso de acción para cumplir con los objetivos que el proyecto se plantea.
El mismo cuenta con los siguientes ítems a destacar:
- Resumen ejecutivo o Project Charter
- Alcance del proyecto
- Estructura de desglose del trabajo
- Sistema de control de cambios
- Plan de cronograma
- Plan de costos
- Plan de riesgos
5
1.8 director de Proyecto / Nivel de autoridad
Rodrigo Valente / SR Manager Finanzas AP
El será la máxima autoridad en la administración de costo y recursos asociados al proyecto.
Cambios en alcance y tiempo deberán ser acordados con el Management.
1.9 Proyecto:
Portal de Proveedores
2. Project Charter
6
7
8
Aprobaciones
3. Alcance del Proyecto

El proyecto a realizara a partir de la necesidad de la empresa Storemarket SRL de agilizar,
automatizar y hacer más eficiente el proceso de la gestión de pago que existe actualmente, esto
sumara a la propuesta de valor y al funcionamiento de la organizacion .
Se realizara una reunion inicial con los directivos de la empresa para conocer las necesidades y
requerimientos, de esta manera se procedera a la realizacion del alcance de proyecto.
Posteriormente se presentara la conformacion del dicho documento para que el mismo sea
aprobado por los actores que intervienen en el proyecto: Cloud Provider, Consultora Desarrollo
Diseño, PMO
3.1 Enunciado del Alcance de Proyecto
Descripcion del Proyecto

Storemarket es uno de los reteilers más importantes de la Argentina, con una estructura de
90 tiendas y 2 centros de distribuciones a lo largo de todo el país.
El proyecto consistira en el Desarrollo de un portal que permita la recepcion y
centralizacion
Alcance del Producto

Se solicita el desarrollo de un portal que permita la centralización de todos los
Comprobantes de Proveedores que cada tienda recibe en forma local y la envíen de forma
9
segura a Casa Central para su gestión de pago. Adicionalmente cada tienda necesita
efectuar el pago de ciertos gastos que no son a través de comprobantes fiscales (facturas)
para lo cual se contempla un circuito diferente. Se estima el procesamiento de
aproximadamente entre 2000 y 3000 comprobantes diarios.
Entregables
Anticipo
• Firma de la Propuesta Comercial y Entrega del Plan de Trabajo
Entregable 1
• Las funcionalidades descriptas en el Punto 1.2 – Validación Automática – Lectura
del Mail
Entregable 2
• Las funcionalidades descriptas en el Punto ABM de Criterios de Clasificación
• Las funcionalidades descriptas en el Punto 1.3 Validación y Carga de Cabecera –
Centro de Escaneo
• Las funcionalidades descriptas en el Punto 1.4 Validación Automática – Inicio
BPM Circuito Clasificación – Portal
Entregable 3
• Las funcionalidades descriptas en el Punto 1.5 Circuito de Aprobación
Comprobantes
Entregable 4
• Las funcionalidades descriptas en el punto 2.1 Circuito Comprobantes NO fiscales-
Tienda
• Las funcionalidades descriptas en el punto 2.2 Validación Automática – Inicio
BPM Circuito Clasificación
• Las funcionalidades descriptas en el punto 2.3 Circuito de Aprobación
Comprobantes NO Fiscales
Entregable 5
• Las funcionalidades descriptas en el Punto 3.1 Consulta Individual
10
• Las funcionalidades descriptas en el Punto 3.2 Consulta Masiva
• Las funcionalidades descriptas en el Punto 3.3 Reportes
• Las funcionalidades descriptas en el Punto 3.4 Almacenamiento
Entregable 6
• Instalación en Producción de las funcionalidades
Criterios de Aceptacion
Tanto los usuarios finales como los supervisores incluso el director del proyecto debes
conocer controlar y aprobar cada uno de estos entregables según los siguientes lineamientos
• Revisión de cada punto detallado asegurando la correcta funcionalidad de la
herramienta.
• Cumplir con los tiempos establecidos.
• Desarrollo de manuales y procedimientos para el usuario final.
• Garantizar la seguridad e integridad de los datos y la información del sistema.
• Cumplir con el presupuesto acordado.
Supuestos
. El proveedor del desarrollo del portal deberá firmar un contrato de confidencialidad
. El sistema provee servicio 24/7
Se espera la participación y compromiso de los líderes del proyecto y de los stakeholders
para llevar adelante el proyecto exitosamente.
La moneda de pago es la que se expresa en el contrato. Esto permite mantener el
presupuesto vigente.
Exclusiones
El proyecto no debe exceder el costo presupuestado
11
Requisitos de aprobacion
Director financiero y ceo tienen que aprobar el proyecto
Aprobación de todos los entregables por parte del cliente interno
3.2 Creacion de la EDT

La creacion de la EDT consiste en dividir y subdividir el alcance de proyecto y entregables para
que estos sean de mejor manejo.
Explicacion del Diccionario EDT

El mismo contendra las siguientes caracteristicas:
 Descripciom
 Riesgos
 Recursos Asignados
 Duracion
3.2.1 Diccionario de la EDT/WBS
12
Cada uno de los bloques del gráfico es un entregable que tiene un objetivo y dependencias. Las
mismas, al igual que la descripción, la fecha estimada de entrega y los responsables de cada una
se pueden observar en el Diccionario de la EDT
3.2.2 Diccionario de la EDT
13
14
15
16
17
3.3 Plan de Gestion de Cambios
El plan de administración de cambios se ocupa de las variaciones en las condiciones
del proyecto. Estas variaciones se pueden dar en varias partes del proyecto, como son
principalmente: Alcance. Cambios en las características del producto o servicio a entregar.
Nombre del Proyecto Siglas del Proyecto

Fox F.X
Nombre del Rol Persona Asignada Responsabilidades Nivel de Autoridad
18
Sponsor Patricio Quiroga Dirigir
requerimientos y
decisiones en los
cambios
Comite de control de Belen Quiros Controlar los
Cambios cambios a lo largo
del proyectos
(aprobarlos o no)
Gerente de Pablo Bazan Planificacion y
Planificacion control de cambios
Gerente de Costos Rodrigo Valente Evaluacion en los
plan de costos y
contigencias
Interesados StakeHolders Solicitud de cambios
en los plazos y
acuerdos de pago
Tipo de cambios
Las acciones correctivas representan una propuesta de mejora que planteas como
consecuencia de haber estudiado la CAUSA de una no conformidad detectada en tu
organización.
Una accion preventiva es una decisión que se toma para evitar que aparezca una
situación no deseada que hemos identificado que podría ocurrir.
Proceso General de Gestion de Cambios
Se detectan las solicitudes de cambios y se preparan los documentos y presupuestos para
dichas contingencias

· Entrevista al Interesado y releva
SOLICITUD DE CAMBIOS: información detallada sobre el cambio
solicitado
19
· Formaliza la iniciativa de cambio
Recibir las solicitudes y preparar el elaborando la Solicitud de Cambio
documento en forma adecuada y precisa. respectiva. Presenta la Solicitud de cambio al
Director de Proyecto.

El unico autorizado para utilizar y ejecutar personalmente este Plan de

Contingenciaes es el Scrum Master:
Registrar la Solicitud de Cambio: Scrum Master registra personalmente la solicitud
Verificar la Solicitud de Cambio: Scrum Master verifica la solicitud
Evaluar Impactos: Scrum Master evalúa impactos
Tomar Decisión: Scrum Mastertoma la decision consultando telefonicamente alSponsor, o
en su defecto consultando a por lo menos dos miembros del Comitéde Control de Cambios
Implantar el Cambio: Scrum Master implanta el cambio
Formalizar el Cambio: Scrum Master convoca al Comité de Control de Cambios y
sustenta la necesidad de haber utilizado este procedimiento de urgencia.Comité de Control
de Cambios formaliza la aprobación o reconsidera la decisióndel Scrum Master
Ejecutar Decisión del Comité: Scrum Master ejecuta decisión del Comité
Concluir el Cambio: Scrum Master concluye el proceso de cambio.
Herramientas de Gestion de Cambios

SOFTWARE : Privados
PROCEDIMIENTOS: El procedimiento estándar es el siguiente: Solicitar el Cambio,
Verificar la Solicitud del Cambio, Evaluar los Impactos, Tomar una decisión y replanificar,
Implantar el Cambio. Concluir el Proceso del Cambio
FORMATOS: Formato de solicitud de cambios
OTROS: -
20
4. Planificacion de Cronograma
Se debe documentar la planificacion como planificar, gestionar y controlar el proyecto.
Comenzando por la definicion de actividades.
Forman parte de este plan los hitos, la lista de actividades, sus atributos y la secuenciación de las
mismas
4.1 Cronograma de Hitos
Cronograma de Hitos del Proyecto

Hito o Evento Significativo
Inicio del proyecto 1 de Junio
1. Relevamiento 8 de Junio
2.1 Entregable version test de la 7 de Julio
Herramienta
3. PRUEBA UAT 4 de Agosto
4. Cloud 8 de Septiembre
5. Testing Arquitectura Cloud 22 de Septiembre
6. Implementacion 23 de Septiembre
7. Informes 9 de Septiembre
FIN DEL PROYECTO 30 de Septiembre
21
4.2 Planificacion de Proyecto
4.2.1 Secuenciar Actividades
2.2 }Definicion de Actividades
22
4.2.3 Atributos de las actividades
Consiste en documentar nombre de las tareas, duracion, actividad precesora y sucesora, hitos y
nombre del responsable asignado
Identificador en la EDT 1
Nombre Inicio
Código 1
Descripción Hito
Actividad predecesora
Actividad sucesora 1.1
Relación de dependencia Obligatoria
Adelanto o retraso
Requisito de recursos Director de Proyecto
Fechas impuestas 1/6/2022
Restricciones
Supuestos El CEO coincide con la fecha
Persona responsable Director de Proyecto
Lugar de realización Oficina del cliente
Nivel de esfuerzo Medio
Identificador en la EDT 1.1

Nombre Inicio
Código 1.1
Conocer la situacion actual de la institucion y
Descripción
crear el acta de constitucion
Actividad predecesora 1
Actividad sucesora 1.1.1
Adelanto o retraso No finalizar luego de 1/06/2022
Requisito de recursos
Restricciones Maximo 3 Horas
Supuestos Recursos disponibles
Persona responsable Analista financiero
Lugar de realización Oficina
23
Identificador en la EDT 1.1.1
Nombre Caso de Negocio
Código 1.1.1
Descripción Analisis de projecto
Actividad predecesora 1.1
Supuestos Máximo de 4 dias
El gerente de sistemas se encuentra disponible
Persona responsable
para el relevamiento
Lugar de realización Oficina del cliente, dpto de sistemas
Identificador en la EDT 1.1.2

Nombre Project Charter
Código 1.1.2
Confeccion del Project Charter, el cual se
Descripción plasma los aspectos relevantes que detallan los
aspectos fundamentales del proyecto
Actividad predecesora 1.1.1
Requisito de recursos Lider del proyecto
Supuestos Máximo de 4 dias
El gerente de sistemas se encuentra disponible
Persona responsible
para el relevamiento
Lugar de realización Oficina del cliente, dpto de sistemas
24
Nombre Acta de Constitucion
Código 1.2
Descripción Crear el Acta del Proyecto
Actividad predecesora 1.1.2
Requisito de recursos 1 Analista
Supuestos Los recursos estas disponibles
Persona responsible Analista
Lugar de realización Oficina del cliente

Nombre Estado del Proyecto
Código 1.3
Documento elaborado desde la fase de planeación,
Descripción con sus revisiones, modificaciones y aprobación por
el sponsor y el director del proyecto
Requisito de recursos Director del Proyecto
Supuestos El acta debe prepararse previamente a la ejecución
Persona responsible Director de Proyecto
Lugar de realización Oficina, Dpto de Sistemas

Nombre Plan de Proyecto
Código 2.1
Una vez aprobados los requerimientos, se
Descripción comenzará con la documentación para definir la
estructura y diseño del sistema
Requisito de recursos Contar con todos los requerimientos del sistema
Supuestos y riesgos Contar con todos los requerimientos del sistema
Persona responsible 1 lider de proyecto y 1 programador
25
Nombre EDT y Diccionario de EDT
Código 2.2
Comenzará con la documentación para
Descripción
definir la estructura, tiempos y definir tareas
Requisito de recursos Se proporciona los Informes de las tareas
Persona responsable PM

Nombre Plan de Cronograma
Código 2.3
Calcular y confeccionar el cronograma con el
Descripción
tiempo del Proyecto
Requisito de recursos Se proporciona los Informes de las tareas
Que el cronograma final lleve mas tiempo que la
Supuestos y riesgos
idea principal
Persona responsable Director e Interesado

Nombre Plan de Cronograma
Código 2.4
Selección de canales y técnicas de comunicación
Descripción
adecuada para nuestro publico
Requisito de recursos Gestor de Comunicacion
Supuestos y riesgos No dar un mensaje claro a nuestro publico Objetivo
Persona responsable Recursos Humanos
26
Nombre Monitoreo y Control
Código 2.5
Descripción Seguimiento de los cambios de gestión
Requisito de recursos Gestor de cambios
Supuestos y riesgos Se analizara las solicitudes de cambios
Persona responsable Gestor de cambios
Lugar de realización Dpto de Sistemas

Nombre Circuito factura Proveedores
Código 3.1
Seguimiento y control de todos los comprobantes
Descripción
que los proveedores envían a la compañía
Requisito de recursos Software
Los comprobantes no son recibidos de forma
Supuestos y riesgos
correcta
Persona responsable PM
Nivel de esfuerzo Alto

Nombre Recepcion y Escaneo
Código 3.2
Cada una de las tiendas cuando reciben los
Descripción comprobantes realizaran el escaneo de las facturas
y del resto de los comprobantes que conforman el
Requisito de recursos Personal
Supuestos y riesgos Retraso en la recepcion
Persona responsable
27
Nombre Validacion Automatica
Código 3.3
El portal efectua el procesamiento de los
Descripción
comprobantes que llegan por mail
Supuestos y riesgos Caida del Sitema
Persona responsable Direccion de Sistemas

Nombre Inicio de Circuito
Código 3.5
Se inicia de manera individual una solicitud de
Descripción
BPM
Requisito de recursos Sistema de Sowtware
Supuestos y riesgos Falla en el proceso de solicitud
Persona responsable
28
Nombre Almacenamiento, Consultas y Reportes
Código 4.1
El usuario tendrá la posibilidad de programar un
Descripción
reporte que le permita bajar en formato CSV
Supuestos y riesgos
Persona responsable Usuarios
Lugar de realización

Nombre Consulta Individual
Código 4.2
Consulta de datos individuales de los clientes y
Descripción
proveedores
Requisito de recursos Datos
Supuestos y riesgos Riesgo de alteracion de datos
Persona responsable Clientes y Proveedores

Nombre Consulta Masiva
Código 4.3
Descripción Garantizar el Rendimiento del Sitio Web

Requisito de recursos Portal Web
Persona responsable Director de Sistemas
29
Nombre Cierre de Proyecto
Código 5.1
Descripción Creacion de informes ejecutivos

Actividad sucesora -
Requisito de recursos Documento General del Proyecto y 1 Analista
Supuestos y riesgos Documentacion incompleta Post Impelemtacion
Persona responsable Stakeholders y director de proyecto
Cronograma de Sucesion
2.1
1.1
INICIO 1.2 2 3 4
1.3 2.2
Plan de Costos
Estimación inicial de tiempo
El desarrollo, testeo y salida en vivo del proyecto tienen una duración estimada de 6 meses, con
fecha de inicio el próximo 01/06/2022 por lo que el portal debe estar completamente finalizado
para su salida en vivo el 01/12/2022.
Fecha de finalización: 01 de diciembre de 2022.
30
Estimación inicial de costes
*El valor hora expresado corresponde a la realización de tareas en días hábiles, en el horario de
9:00 a 18:00 hs. En días hábiles, después de las 18:00 hs., existe un recargo del 50% sobre el
valor horario establecido, mientras que en sábados, domingos y feriados el recargo será del
100%.
31
Scrum
Al analizar las problemáticas que surge luego de la implementación y con intenciones de reducir
el impacto para la operación, decidimos proponer el desarrollo de la solución aplicando el marco
de trabajo Scrum
Issue
Luego del lanzamiento de la solución y en plana producción el equipo de desarrolladores es

advertido que el equipo funcional está sufriendo un problema de migración de información
debido a un error al leer un tipo de código QR especifico el cual no se había tenido en cuenta
como caso de negocio al momento del desarrollo.
Esto está generando demoras en la operación y proceso de pago debido a los controles manuales
que se deben realizar de forma diaria para asegurar que la información enviada allá sido recibida,
como resultado de dicho control se pueden generar 2 escenarios, a) que el control confirme que se
recepcionaron los documentos correctamente, por lo que el flujo continua y b) que exista una
diferencia en el control y esto obligara al usuario que busque y realice el mach de los documentos
correctos por medio de diferente cruces de información de reportes que debe bajar a demanda
cada vez que los necesita. Por último, cuando finalmente el usuario detecte la diferencia debe
entrar al repositorio del sistema a completar los datos necesarios (que no fueron leídos por el
error del QR) y liberar la línea del error de forma manual.
Por lo que el scrum master decide realizar 2 sprint para atacar la iniciativa, cada sprint es de 3
semanas y en base a esta duración se planificara las ceremonias de seguimiento necesarias para
garantizar los entregables esperados.
Equipo
Está formado por
 Product Owner
 Scrum master
 Desarrollador 1
 Desarrollador 2
 Desarrollador 3
32
Objetivo general
Acotar tiempos del proceso, respetar acuerdos comerciales en cuanto a los plazos de pago,
automatizar controles manuales, detectar diferencias, automatizar el mach de los documentos con
error para que flujo no sea interrumpido.
Alcance
Teniendo en claro la problemática, el back log a considerar y el objetivo final se decidió dividir la
solución en 2 sprint la misma surge de la metodología a trabajo de una matriz de 2 entradas,
“esfuerzo”, “impacto”, la cual nos permite ponderar y priorizar cada una de ellas según los
siguientes criterios.
Matriz Esfuerzo Impacto
Dependencia
Criterios de Impacto en Tiempos
IT/Proveedor/Áreas no Estado de la Iniciativa
Esfuerzo de Implementación
cliente
0 - N/A N/A N/A N/A
Quick Win = < 1 Sprint Iniciativa finalizada pendiente de

1 - Low Short Term = entre 1-2 No hay dependencia validación y/o pruebas para su
Sprint implementación
Iniciativa On Hold con

Medium Term = entre
3 - Medium Hay alguna dependencia relevamientos funcionales y/o
2-5 Sprint
técnicos pendientes
5 - High Long Term > 6 Sprint Depende 100% Iniciativa Nueva
33
Criterios Disminución
Implementación Impacto Colaboradores
de de Horas de Cliente
de Controles Automatización afectados
Impacto Procesamiento
0 - N/A N/A N/A N/A N/A N/A
La iniciativa no
conlleva la No automatiza el
1 - Low <5 < 10 Otros
implementación proceso
de un Control
Automatiza
3- Se implementa un
parcialmente el 5 - 10 10 - 50 GPO, PO
Medium Control Manual
proceso
Automatiza la CFO, VP
Se implementa un
mayoría o Admin&Control,
5 - High Control > 10 > 50
totalidad del Auditoría Interna,
Automático
proceso Auditoría Externa
Luego de validar cada iniciativa concluimos en llevar adelante la solución de la siguiente manera
Sprint 1 planing
En esta reunión previa al comienzo del sprint en donde participa todo el equipo Scrum, se define
la problemática que debemos atacar y los próximos pasos a seguir en base a la necesidad que
tienen los usuarios debido a esta falla de lectura.
Luego de tener bien identificados los puntos de dolor del proceso a resolver, se propone una
solución dividida en 2 fase contemplando el esfuerzo e impacto de cada una
Sprint 1 – Fase 1 “Control automático de proceso de lectura”
1.1 Bajar los reportes de forma automática
1.2 validación de volumen recepcionado vs recibidos
1.3 Automatizar cruce de información, detectar campos vacíos
Sprint 2 (dependencia del Sprint 1) – Fase 2 “. Maching Automático”

34
2.1 Completar campos vacíos detectados de forma automática
2.2 Validación y control de campos automáticos
2.3 Liberación automática de las facturas a contabilizar
Objetivo y alcance
Sprint 1, Implementar controles automáticos y detectar errores para ser remediados por el
usuario.
Sprint 2, Remediar errores y realizar el maching automático de los documentos
Daily scrum
El equipo administras sus novedades en 3 dailys semanales, lunes miércoles y viernes a las 9 a
9:15 de la mañana en donde el equipo de desarrolladores informara sobre los avances, que estará
realizando como próximos pasos, como también informara al equipo si tienen algún tipo de
dificultad para continuar. Sera una tarea clave del Scrum Master velar por que el equipo pueda
sortear cualquier dificultad que impida alcanzar o este demorando sus objetivos.
El product owner será invitado como opcional de poder participar, deberá actuar como espectador
para evitar correr el foco de la reunión.
En esta primera daily no hubo mayores novedades por lo que cada punto que lleva cada
desarrollador se encuentra acorde al plan
Daily a daily se fueron comentando y dando seguimiento a los avances los cuales no sufrieron
ningún desvío cuanto a tiempo por lo que se logró llegar al final del sprint de forma satisfactoria.
Sprint review
Debido a los avances y el seguimiento que se realizó en el Sprint en este primer sprint review
podemos brindar como equipo una solución a los usuarios y departamentos solicitantes, es el
momento en donde podemos cumplir con los asumidos cumplidos, entregando un producto
incremental que general valor para la operación.
Asistentes de la reunión el equipo Scrum, Gte. De Finanzas, Key User.
35
El equipo muestra el producto final al se había comprometido en este primer sprint y demuestra
el incremento del producto en cuanto a la baja de los reportes, la validación del volumen recibido,
los controles implementados, como también los pasos a segur que deberá realizar el usuario para
los pasos que aún continúan siendo manual.
Si bien em esta primera instancia funciono todo según lo esperado esperamos retroalimentación
del usuario una vez que ponga en marcha la solución.
Sprint Retrospective
1 semana después de finalizar el primer Sprint se realiza la reunión de retrospectiva con el key
user el gerente Financiero más el equipo de Scrum.
En esta instancia lo que buscamos es el feedback de nuestros clientes dentro de la organización

en donde nos cuenta la experiencia que tuvieron con esta solución y si existen puntos de mejora
que podamos incluir en un siguiente sprint.
En esta oportunidad la solución funciono según lo esperado por los usuarios por lo que en este
caso continuamos al siguiente sprint sin novedades y según lo planeado.
Sprint 2 planing
Antes de Iniciar con el 2° Sprint nuevamente vamos a celebrar la reunión de planificación en
donde volvemos a marcar los próximos pasos a seguir, tiempos y responsables de cada tarea. En
este caso la Fase 2 “. Maching Automático” está compuesto por las siguientes historias de
usuario.
 2.1 Completar campos vacíos detectados de forma automática

 2.2 Validación y control de campos automáticos
 2.3 Liberación automática de las facturas a contabilizar
El scrum master hace un seguimiento del cronograma y de los temas que se den llevar adelante
por el equipo para cumplir con los objetivos.
Los desarrolladores establecen un plan para asegurar cubrir con todas las necesidades requeridas.
Objetivo del sprint: Remediar errores y realizar el maching automático de los documentos
36
Daily scrum 2
Siguiendo con la metodología de las dailys anteriores notamos que todo se venía desarrollando
con normalidad hasta la segunda semana en donde la validación y el control de campos
automáticos se encuentra demorada por un problema técnico el cual nace de un problema de
interface en donde está faltando extraer un campo de una de las tablas, Si bien se cree que este
inconveniente se puede remediar de forma ágil, el Scrum Master estar siguiendo muy de cerca
esta issue ya que la siguiente actividad depende que esta finalice correctamente en tiempo y
forma.
Por suerte ya en la siguiente Daily el inconveniente había sedo remediado por lo que el proceso
continuo sin demasiados sobresaltos y por el momento no corremos riesgo de incumplimiento del
sprint
Sprint 2 review
Debido a los avances y el seguimiento que se realizó en el Sprint y sorteando los improvistos
técnicos nuevamente logramos brindar la solución que los usuarios y departamentos solicitantes
estaban esperando, cumpliendo con los compromisos asumidos fomentando un marco de
confianza y transparencia con el resto de los departamentos, entregando un producto incremental
que general valor para la operación.
Asistentes de la reunión el equipo Scrum, Gte. De Finanzas, Key User.
El equipo muestra el producto final funcionando con las funcionalidades desarrolladas al 100%
logrando de esta manera el control y la automatización completa del flujo de trabajo, generando
un ahorro en tiempo en los procesos, disminuyendo el volumen de reclamos por pagos tardíos y
automatizando controles lo cual aporta a la disminución de errores.
Si bien en esta primera instancia funciono todo según lo esperado esperamos retroalimentación
del usuario una vez que ponga en marcha la solución.
Sprint 2 retrospective
Como es costumbre según nuestro calendario de actividades 1 semana después de finalizar Sprint
se realiza la reunión de retrospectiva con el key user el gerente Financiero más el equipo de
Scrum.
37
En donde esperamos el feedback de nuestros clientes nos cuenta la experiencia que tuvieron al
usar esta solución y si existen puntos de mejora que podamos incluir en un siguiente sprint.
En esta oportunidad la solución funciono según lo esperado por los usuarios, aunque no descartan
seguir planteando mejoras en busca un producto final superador.
Conclucion
Gracias a este proyecto pudimos entender los diferentes puntos de vista a considerar a la hora de
iniciar con un proyecto, absorbiendo conocimiento de los diferentes marcos de trabajo que
existen y de qué manera pueden ser aplicados dependiendo de la necesidad del cliente y el tipo de
solución que se proponga para desarrollarlo.
Pudimos entender que no existe una única manera de afrontar los proyectos y que siempre va a
depender de las circunstancias, el entorno, el tipo de problema, la urgencia, criticidad y necesidad
y posibilidad de cada organización.
Sin duda creemos que hoy nos podemos llevar una herramienta más para continuar el camino del
desarrollo profesional.
Bibliografia
 PMBOK_6ta_edicion
 Lledó, Pablo. Director de Proyectos . 2016.
 https://proyectosagiles.org/que-es-scrum/
38

Plan de Proyecto: Pablo Emmanuel Bazan

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plan de Proyecto: Pablo Emmanuel Bazan

Cargado por

Copyright:

Formatos disponibles

Plan De Proyecto

Pablo Emmanuel Bazan

Versión # Implemented Revision Approval Approval Reason

1.2 Situación Actual

1.5 Beneficios del Proyecto

. El sistema provee servicio 24/7

1.7 Propósito del Proyecto

El mismo cuenta con los siguientes ítems a destacar:

- Resumen ejecutivo o Project Charter

- Alcance del proyecto

- Estructura de desglose del trabajo

- Sistema de control de cambios

3. Alcance del Proyecto

3.1 Enunciado del Alcance de Proyecto

Descripcion del Proyecto

Alcance del Producto

3.2 Creacion de la EDT

Explicacion del Diccionario EDT

3.2.1 Diccionario de la EDT/WBS

3.2.2 Diccionario de la EDT

Nombre del Proyecto Siglas del Proyecto

Nombre del Rol Persona Asignada Responsabilidades Nivel de Autoridad

El unico autorizado para utilizar y ejecutar personalmente este Plan de

Herramientas de Gestion de Cambios

4.1 Cronograma de Hitos

Cronograma de Hitos del Proyecto

2.2 }Definicion de Actividades

Identificador en la EDT 1.1

Identificador en la EDT 1.1.2

Identificador en la EDT 1.3

Identificador en la EDT 2.1

Identificador en la EDT 2.3

Identificador en la EDT 2.4

Identificador en la EDT 3.1

Identificador en la EDT 3.2

Identificador en la EDT 3.5

Identificador en la EDT 4.2

Identificador en la EDT 4.3

Descripción Garantizar el Rendimiento del Sitio Web

Actividad predecesora 4.2

Descripción Creacion de informes ejecutivos

Actividad predecesora 4.3

Fecha de finalización: 01 de diciembre de 2022.

Luego del lanzamiento de la solución y en plana producción el equipo de desarrolladores es

Matriz Esfuerzo Impacto

0 - N/A N/A N/A N/A

Quick Win = < 1 Sprint Iniciativa finalizada pendiente de

Iniciativa On Hold con

5 - High Long Term > 6 Sprint Depende 100% Iniciativa Nueva

0 - N/A N/A N/A N/A N/A N/A

Sprint 1 – Fase 1 “Control automático de proceso de lectura”

1.1 Bajar los reportes de forma automática

1.2 validación de volumen recepcionado vs recibidos

1.3 Automatizar cruce de información, detectar campos vacíos

Sprint 2 (dependencia del Sprint 1) – Fase 2 “. Maching Automático”

2.2 Validación y control de campos automáticos

2.3 Liberación automática de las facturas a contabilizar

Sprint 2, Remediar errores y realizar el maching automático de los documentos

Asistentes de la reunión el equipo Scrum, Gte. De Finanzas, Key User.

En esta instancia lo que buscamos es el feedback de nuestros clientes dentro de la organización

 2.1 Completar campos vacíos detectados de forma automática

Asistentes de la reunión el equipo Scrum, Gte. De Finanzas, Key User.