Plantilla - Plan de Direccion Del Proyecto

PLAN DE DIRECCIÓN DE PROYECTO
7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Proveedor XXX
EAPSA
PLAN DE DIRECCION
DEL PROYECTO
DATAMART OPERATIVO
XXX - EAPSA
Versión 2.0
Actualizado al 31 de
Enero del 2014
7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
HISTORIAL DE LAS REVISIONES
Responsable de
Ítem Versión Fecha Autor Descripción Estado Revisión y/o
Aprobación
5 2.0 31/01/2014 Sofia Versión Final (actualizada) Aprobado Sofia
del Plan
Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 2 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
TABLA DE CONTENIDO
1. RESUMEN EJECUTIVO............................................................................................................ 6
2. OBJETIVOS DEL PROYECTO.................................................................................................6
3. ALCANCE.................................................................................................................................. 6
3.1. ALCANCE DEL PRODUCTO.................................................................................................... 6
3.2. PROCESOS DEL NEGOCIO..................................................................................................... 7
3.3. ASUNCIONES........................................................................................................................... 7
3.4. ACOTACIONES DEL PROYECTO........................................................................................... 9
3.5. RESTRICCIONES DEL PROYECTO........................................................................................9
4. PLAN DEL PROYECTO.......................................................................................................... 10
4.1 CRONOGRAMA DEL PROYECTO......................................................................................... 10
4.2 DOCUMENTOS DE GESTIÓN............................................................................................... 11
4.3 ENTREGABLES DE INGENIERÍA......................................................................................... 11
4.4 PROCESO DE APROBACIÓN DE ENTREGABLES.............................................................12
4.5 ACTUACIÓN DE LOS RESPONSABLES DEL PROYECTO.................................................12
4.6 SUPERVISIÓN DEL PROYECTO.......................................................................................... 13
4.6.1 COMITÉ DE GERENCIA......................................................................................................... 13
4.6.2 COMITÉ DE OPERATIVO DEL PROYECTO..........................................................................14
4.7 ORGANIZACIÓN PROPUESTA PARA EL PROYECTO.......................................................14
4.7.1 ORGANIGRAMA..................................................................................................................... 14
4.1.1. ROLES Y RESPONSABILIDADES DEL PROYECTO............................................................15
5. TÉRMINOS DE ATENCIÓN..................................................................................................... 18
RESPONSABILIDADES DE LAS PARTES......................................................................................... 18
5.1.1. POR EAPSA............................................................................................................................ 19
5.1.2. POR XXX................................................................................................................................. 19
5.2. CUMPLIMIENTO DE PLAZOS................................................................................................ 20
5.3. CONFIDENCIALIDAD DE LA INFORMACIÓN.......................................................................20
5.4. CASO FORTUITO O FUERZA MAYOR..................................................................................20
5.5. SUSPENSIÓN DEL PROYECTO............................................................................................ 20
5.6. PROPIEDAD INTELECTUAL.................................................................................................. 21
5.7. PROCEDIMIENTO PARA LAS MODIFICACIONES...............................................................21
5.8. CONDICIONES DE INICIO...................................................................................................... 21
5.9. CONDICIONES DE TÉRMINO DEL PROYECTO...................................................................21
5.10. GARANTÍA.............................................................................................................................. 21
6. CONTROL Y SEGUIMIENTO DEL PROYECTO.....................................................................22

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
6.1. INFORME PERIÓDICO DE AVANCE.....................................................................................22

6.2. SEGUIMIENTO DE DESVIACIONES SIGNIFICATIVAS.........................................................22
6.3. CORTE DE EVALUACIÓN - NO APLICA..............................................................................23
7. CONTROL DE CAMBIO.......................................................................................................... 23
7.1. CAMBIOS................................................................................................................................ 23
7.2. CLASIFICACIÓN DEL CAMBIO............................................................................................. 23
7.3. ACTA DE CONTROL DE CAMBIO PARA LA APROBACIÓN DE LA SOLICITUD DE
CAMBIOS DE ALCANCE DEL PROYECTO...........................................................................23
8. GESTION DE COMUNICACIONES......................................................................................... 23
8.1. CANALES DE COMUNICACIÓN............................................................................................ 29
8.2. MATRIZ DE COMUNICACIONES........................................................................................... 29
8.3. INTERDEPENDENCIAS CON OTROS PROYECTOS............................................................30
9. GESTIÓN DE LA CALIDAD DEL PROCESO Y PRODUCTO................................................30
9.1. ASEGURAMIENTO DE CALIDAD DEL PROCESO...............................................................30
9.2. ASEGURAMIENTO DE CALIDAD DEL PRODUCTO.............................................................30
9.2.1. REVISIÓN DE PARES............................................................................................................. 31
NO APLICA.......................................................................................................................................... 31
9.2.2. PRUEBAS UNITARIAS E INTEGRALES...............................................................................31
9.2.3. PRUEBAS DE TRANSICIÓN.................................................................................................. 31
9.3. TIPOS DE OBSERVACIONES................................................................................................ 31
9.3.1. MALFUNCIONAMIENTO O ERRORES..................................................................................31
9.3.2. OBSERVACIÓN DE RENDIMIENTO (TIEMPO DE RESPUESTA).........................................32
9.3.3. OBSERVACIONES A VALIDACIONES Y/O CONSISTENCIAS.............................................32
9.3.4. OBSERVACIONES A VACÍOS FUNCIONALES Y/O DEFINICIONES AMBIGUAS...............32
9.3.5. OBSERVACIONES DE MEJORA........................................................................................... 32
9.4. TRATAMIENTO A OBSERVACIONES...................................................................................33
9.4.1. DE RESPONSABILIDAD XXX................................................................................................ 33
9.4.2. DE RESPONSABILIDAD DE EAPSA.....................................................................................33
9.5. NUEVOS REQUERIMIENTOS DEL PROYECTO...................................................................33
10. INFRAESTRUCTURA............................................................................................................. 33
10.1. RECURSOS MATERIALES QUE EL CLIENTE PROPORCIONARÁ.....................................34
1. COORDINAR LUGARES FÍSICOS PARA EL EQUIPO DE XXX (SEDE LIMA).....................34
2. REQUERIMIENTOS DE 3 EQUIPOS INFORMÁTICOS CON LAS SIGUIENTES
CARACTERÍSTICAS:.............................................................................................................. 34
A. PROCESADOR: INTEL CORE, PORCESADOR (3M CACHE, 1.80 GHZ).............................34
B. MEMORIA RAM:8.0 GB.......................................................................................................... 34
C. ALMACENAMIENTO: 250GB................................................................................................. 34

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
D. SISTEMA OPERATIVO: WINDOWS XP SP3 64 BITS...........................................................34

3. DAR ACCESO AL PERSONAL DE XXX (3 RECURSOS ) EN LOS SIGUIENTES
SERVICIOS, POR UN PERIDO DE 7 MESES:.......................................................................34
A. SVN.......................................................................................................................................... 34
B. SERVIDOR WIKI..................................................................................................................... 34
C. JIRA......................................................................................................................................... 34
D. BASE DE DATOS WARI (BRANCH DESARROLLO DATAMART A.....................................34
E. CORREO INTERNO................................................................................................................ 34
F. PERFIL INTERNET DE SISTEMAS........................................................................................ 34
G. TELÉFONO.............................................................................................................................. 34
4. IMPLEMENTAR AMBIENTE DE BASE DE DATOS DE DESARROLLO
WARI(ACTUALIZACIÓN DE BASE DE DATOS)...................................................................34
5. CREARSE CUENTAS DE BASE DE DATOS CON EL PERFIL DE
DEVELOPER_FACTORIES PARA EL EQUIPO DE XXX.......................................................34
6. IMPLEMENTAR AMBIENTE DE DESARROLLO DATAMART:.............................................34
A. INSTALAR SISTEMA OPERATIVO (SERVIDOR DATAMART).............................................34
B. INSTALAR Y CONFIGURAR HERRAMIENTA DE BI............................................................34
C. CREACIÓN DE CUENTAS EN AMBIENTES (ACCESOS).....................................................34
7. INSTALACIÓN DE DATASTAGE, COGNOS, DB2…EN LOS AMBIENTES DE
PRODUCCIÓN, DESARROLLO Y PRE-PRODUCCIÓN, AL INICIAR A LA
CONSTRUCCIÓN.................................................................................................................... 34
8. COMPRA DE LICENCIAS....................................................................................................... 34
11. GESTIÓN DE RIESGOS.......................................................................................................... 34
12. GESTION DE LA CONFIGURACION......................................................................................36
13. PLAN DE CAPACITACIÓN..................................................................................................... 36
13.1. ALCANCE DE LA CAPACITACIÓN.......................................................................................36
13.2. ACTIVIDADES PREVIAS A LA CAPACITACIÓN..................................................................36
13.3. GRUPO DE USUARIOS A CAPACITAR.................................................................................37
13.4. PROGRAMACIÓN DE CAPACITACIÓN.................................................................................37
13.5. EJECUCIÓN DE CAPACITACIÓN.......................................................................................... 37
13.6. DESPUÉS DE CAPACITACIÓN.............................................................................................. 37
14. ANEXOS.................................................................................................................................. 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
1. RESUMEN EJECUTIVO
Con la finalidad de disponer de una herramienta de soporte a la toma de decisiones, para obtener y
analizar, en forma fácil y oportuna, información relevante y confiable sobre aspecto del negocio;
EAPSA ha decido desarrollar el DATAMART DE OPERACIONES. En este sentido, la solución será
desarrollada considerando características de escalabilidad y capaz de proporcionar información
centralizada y actualizada.
EAPSA desarrollóo un documento de diseño funcional que fue explicado al proveedor XXX y mediante
reuniones se detalló el alcance del proyecto que incluye información consolidada de las tenencias,
eventos corporativos, ganancia de capital, internacional y negociación con sus respectivos indicadores
y métricas a analizar.
Con respecto a la seguridad de la herramienta, este considera usuarios, perfiles y acceso a

información por perfiles.
Para poder implementar el proyecto de manera adecuada, el desarrollo incluirá el uso de la

metodología de proyectos que asegura el éxito del proyecto mediante las siguientes fases: Incepción,
Elaboración, Construcción y Transición, donde se incluyen las actividades necesarias y los
responsables respectivos.
Gerente Sponsor: XXX

Responsable del Proyecto: XXXX
Analista de Sistemas: XXX
2. OBJETIVOS DEL PROYECTO
 Contar con información estadística consistente (tenencias, ganancia de capital, negociación,

internaciones y eventos corporativos), confiable y oportuna para la toma de decisiones del área
de Operaciones.
 Gestar las bases de una herramienta de soporte a la toma de decisión fácil de usar y de rápido
acceso a toda la empresa EAPSA.
3. ALCANCE
3.1. Alcance del Producto.
o El DATAMART DE OPERACIONES a desarrollar considera los siguientes componentes:
a. Cinco (5) tablas de hechos:
 Tenencia de valores.
 Negociación.
 Eventos corporativos.
 Internacionales.
 Asignación

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
b. Quince (13) dimensiones:
 Dimensión Tiempo
 Dimensión Tipo de Retención
 Dimensión Valores
 Dimensión Titulares Cabecera
 Dimensión Titulares Detalle
 Dimensión Hechos de Importancia
 Dimensión Participantes
 Dimensión Tipo Valorizado
 Dimensión Tipo Operaciones Internacionales
 Dimensión Tipo Operación
 Dimensión Tipo de Modificación
 Dimensión Tipo de Incumplimiento
 Dimensión Rol de Operación
c. Análisis de Datos
 Carga de Datos considerada desde el año 2003 en adelante.

 Se considera dos (2) esquemas de base de datos:
 Esquema 1: Relacionado con la BD histórica (aproximadamente 30 tablas)
 Esquema 2: Relacionado a la BD actual de WARI (aproximadamente 40 tablas).
d. Procesos y Reportes
 Tableros de Control - Se estiman 2 Tableros de Control

 Reportes - Se estiman 15 reportes
e. Métricas (ver diseño funcional)
f. KPI (Indicadores de Negocio) (ver diseño funcional)
3.2. Procesos del Negocio.
No aplica:
3.3. Asunciones.
La presente propuesta ha tenido como base para su elaboración las siguientes asunciones que
constituyen condicionales del Proyecto:

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Ítem Asunciones
1 Durante todo el tiempo de desarrollo del proyecto, XXX presentará por escrito un
informe semanal con el estado de avance de todas las actividades realizadas y al
finalizar el proyecto un informe final.
2 Los informes de avance semanal y final serán elaborados en conjunto por XXX y
EAPSA y presentados en los comités operativos (Semanales) y Gerenciales
(Mensuales).
3 EAPSA brindaráa las condiciones laborales necesarias para el desarrollo del

requerimiento.
EAPSA asegurará la disponibilidad de los usuarios claves para poder atender
4 consultas y definiciones funcionales, las cuales serán programadas en las
reuniones semanales de avance de proyecto.
5 Participación activa del Usuario Líder durante las distintas fases del Proyecto.
La aprobación de cada Entregable significa su aceptación y autorización para
6
proseguir con las etapas subsiguientes de acuerdo al cronograma del proyecto.
En el cronograma se deberán indicar claramente todas las acciones a desarrollarse
7 en forma sistemática basado en el plan de trabajo propuesto para la realización del
proyecto.
Se respetarán los plazos previstos en el cronograma del proyecto, tanto por parte
8
de XXX como por EAPSA.
Las labores del Proyecto estarán sujetas al alcance funcional y y a la operativa
descrita en el presente documento y en el documento de especificaciones
9
funcionales, en caso de ser aceptadas, debiendo mediar acuerdos suscritos por
ambas partes para cualquier modificación de eéstos.
El Proyecto se atenderá en las instalaciones de EAPSA, y este a su vez, deberá
10 brindar los recursos que cumplan con los requisitos mínimos necesarios de
hardware y software, durante todo el proyecto.
EAPSA debe asegurar la estabilidad de los servicios de red, comunicaciones, y
11 demás servicios requeridos para la operación del sistema durante las etapas de
Construcción, Certificación y Producción.
EAPSA es responsable de implementar los ambientes de producción, desarrollo y
12
pre-producción.
EAPSA proporcionaráa facilidades de acceso a la fuente de datos que contempla
13
dos esquemas de Base de datos en Oracle 10g .
XXX implementaraá los procesos de carga inicial (del 2009 en adelante) y carga
históorica (del 2003 en adelante) de datos. La carga histoórica estaráa sujeta a
14
revisióon (análisis de impacto) de ambas partes (EAPSA – XXX) respecto a su
implementación.
XXX se compromete en la media de lo posible, a no reasignar ni remover ningún
miembro de su personal asignado. Si un integrante del equipo de XXX debiera
15 reemplazarse por razones de fuerza mayor, el reemplazante deberá ser aprobado
por EAPSA y reunir al menos las mismas habilidades, competencia y experiencia
que el reemplazado.
EAPSA se reserva el derecho de solicitar a XXX que cualquier miembro del
personal de este último, sea retirado y reemplazado por una persona con
16 experiencia y perfil adecuado, cuando considere que la cantidad o calidad del
trabajo en cuestión resultan inaceptables.
17 XXX y EAPSA responderán las observaciones o consultas efectuadas por ambas

partes dentro de un plazo máximo de dos (2) días útiles a partir de formuladas las
observaciones o consultas, el tiempo adicional que se demore en responder;
serán contabilizadas como demora atribuida a las empresas. En donde las
respuestas de las observaciones por parte de ambas empresas necesite un tiempo

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Ítem Asunciones
adicional a lo indicado, todas las partes analizaráan el impacto en el cronograma
del proyecto y acordaraán una fecha límite de conformidad del entregable que no
debería extenderse a más de una semana.
XXX se compromete que durante el desarrollo del proyecto efectuará la

18 transferencia de conocimientos al (los) recursos técnicos asignado por EAPSA.
Durante la fase de transición EAPSA ejecuta por metodología pruebas con las
19 áreas: Usuarios funcionales, Seguridad de la información, Aseguramiento de la
calidad, Desarrollo y Producción.
XXX acompañaraá a EAPSA en la fase de Transición (pruebas) durante 15 días
20 laborables. De requerir una extensión del soporte a las pruebas, ambas partes
revisaraán el impacto.
Estas asunciones han sido consideradas para la estimación de esfuerzo, y determinación de plazo
y costos, por lo que de alterarse podrá impactar el precio ofertado.
3.4. Acotaciones del Proyecto.
El Proyecto no contempla las siguientes labores:
Ítem Acotaciones
1 Atención de ningún trabajo que no esté especificado en el documento funcional.
2 Labores de detección y depuración de datos o inconsistencias.
El equipo de XXX no tiene participacion directa en la instalacion y/o configuracion
3
de los aplicativos de datastage, Cognos y DB2
4 Implementación de hardware o software base.
5 Los reportes construidos en el proyecto no mostraráan data en linea.
La solución no contempla Implementación de alta disponibilidad.
6
El Proyecto no incluye procesos de Limpieza de Datos, ni tampoco la programación
7 de interfaces para la toma o digitación de los datos (Data Entry). La calidad de la
data, su consistencia y su integridad son responsabilidad de EAPSA.
8 Licenciamiento de uso de toda la infraestructura de software.
Modificaciones del código de los aplicativos de EAPSA.
9
La presente propuesta ha sido elaborada en función a la documentación alcanzada por EAPSA.

De surgir cambios en eéstos durante la ejecución del Proyecto, deberá atenderse a través del
procedimiento de Control de Cambio conforme al procedimiento formulado en este documento.
3.5. Restricciones del Proyecto
Las restricciones son los factores que limitan el rendimiento del proyecto, el rendimiento de un
proceso del proyecto, o las opciones de planificación del proyecto, pueden aplicar a los objetivos
del proyecto o a los recursos que se emplea en el proyecto.
Las restricciones a considerar para el desarrollo del proyecto, se declaran en el siguiente cuadro:

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Ítem Restricciones
1 El desarrollo del proyecto estáa sujeto a los recursos tanto de hardware como de
software necesarios para la fase de desarrollo.
El desarrollo del proyecto estáa sujeto a la disponibilidad de los recursos asignados
2
al proyecto.
3 Retrasos por actividades de limpieza de datos, por requerimiento del usuario.
La implemetacion de algun requerimiento en paralelo que afecte la data y/o objetos
4 considerados parte del alcance de este proyecto, generaraá una solicitud de control
de cambio.
4. PLAN DEL PROYECTO
4.1 Cronograma del Proyecto
Se presenta a continuación el cronograma del proyecto, que registra los plazos por cada fase del
Proyecto.
<Incluir Cronograma Project>
Se precisa que el Cronograma del Proyecto una vez aprobado por EAPSA se realizará el Kick-off
del inicio del proyecto.
El cronograma en detalle se presenta como anexo en el artefacto denominado “Proyecto Datamart

v4.0.mpp”.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
4.2 Documentos de Gestión
Durante la ejecución del Proyecto, la Gerencia del Proyecto de XXX administrará los siguientes
documentos de gestión, muchos de los cuales seraan de uso común o compartidos con EAPSA
para una visibilidad de la evolución del Proyecto:
Documentos de Gestión Compartido

Plan de Dirección de Proyecto SI
Cronograma del Proyecto SI
Acta de inicio de Proyecto (Kick-Off Meeting) SI
Informe de Seguimiento SI
Actas SI
Plan de Capacitación SI
Plan de Pruebas SI
Informe de Cierre del Proyecto SI
4.3 Entregables de Ingeniería

El proveedor XXX se compromete a presentar por las actividades descritas, los siguientes
Entregables:
Fecha Fecha
Fase Entregables
Entrega Aprobación
Diagrama de Arquitectura 25/02/14 25/03/14
Análisis Fichas de Reportes y/o tableros 25/02/14 25/03/14
Funcional Documento de Especificaciones 19/03/14 25/03/14
Funcionales (REF)
Modelo de Datos 20/03/14 08/04/14
Diccionario de Datos 01/04/14 08/04/14
Análisis
Dimensionamiento de BD 01/04/14 08/04/14
Técnico
Documento de Especificaciones 02/04/14 08/04/14
Técnicas (preliminar)
Informe de Pruebas Unitarias (RPU) 19/05/14 23/05/14
Informe de Pruebas Integrales (RPI) 30/05/14 05/06/14
Documento Modelo Lógico 24/04/14 06/06/14
Construcción (Framework Manager)
Plan de certificación 02/06/14 06/06/14
Documento de Especificaciones 02/06/14 06/06/14
Técnicas (Final)
11/07/14 11/07/14
Acta de Aceptación del producto
Transición Manual de Usuario 18/07/14 25/07/14
Manual de Instalación 18/07/14 25/07/14
Pase Producción 18/07/14 25/07/14
Informe de Cierre del Proyecto 25/07/14 25/07/14

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
4.4 Proceso de aprobación de Entregables.
a) Los Entregables podrán presentarse a través de correo dirigido a los responsables del
Proyecto (jefe de Proyecto) para su revisión y aprobación.
b) Su aprobación formal se realizará mediante Correo Electrónico o Acta suscrita por los
Responsables del Proyecto dentro del plazo previsto por el Cronograma del Proyecto, o en
su defecto en caso de no precisarlo el cronograma, en un plazo de 5 días hábiles
posteriores a su entrega. En caso de no comunicarse observaciones en dicho plazo,
procederá la aprobación automática, debiéndose regularizar la aprobación del acta dentro
de los 2 días siguientes. En caso donde las consultas sean complejas y EAPSA considere
que el tiempo de respuesta sea mayor a lo indicado, todas las partes analizar áan el
impacto en cronograma del proyecto y acordaraán una fecha límite de entrega que no
debería extenderse a más de una semana.
c) Se podrá anticipar la presentación de Entregables, adelantando automáticamente las
fechas de revisión y aprobación del mismo, sin embargo ello no representa compromiso de
adelanto de los Entregables subsiguientes o recorte del plazo del proyecto, salvo que el
proveedor XXX así lo manifieste, debiendo mediar una re-planificación del proyecto.
d) La Puesta en Producción es una actividad de competencia de EAPSA que deberá atender
directamente, por tanto, la actuación del equipo del proveedor en esta actividad será de
índole consultivo.
4.5 Actuación de los responsables del Proyecto
Los responsables del proyecto (jefe de proyecto) tienen como principal función velar por la exitosa
culminación de cada proyecto, para lo cual deberán atender las siguientes labores entre otras:
a) Revisar, validar y aprobar/hacer aprobar los entregables dentro de los plazos previstos en
el Cronograma del Proyecto, y suscribir las Actas de Aceptación de los mismos.
b) Revisar, validar y hacer aprobar las Actas de Control de Cambio por parte del Gerente
Sponsor para los casos en que se redefinan: Alcance del producto, definiciones de diseño
aprobado, cronograma, actividades o entregables comprometidos.
c) Asistir a los Comités de seguimiento planificados, en caso se vea impedido de asistir
deberá enviar un responsable en delegación con facultad de tomar decisiones en ella.
d) Identificar e involucrar a personas o áreas afectadas por cada proyecto.
El siguiente cuadro identifica a los Responsables del Proyecto por las partes involucradas
(EAPSA y XXX):
Por parte de EAPSA:
Nombres y Apellidos Rol EAPSA E-mail Teléfono

Daniel A Gerente Sponsor DanielA@EAPSA.com.pe 3257
Hector Analista de sistemas HectorP@EAPSA.com.pe 3298
Responsable del
Roxana RoxanaJ@EAPSA.com.pe 3258
area Desarrollo
Javier Analista funcional JavierN@EAPSA.com.pe 3218
Carla Analista funcional CarlaG@EAPSA.com.pe 3229
Ricardo Gerente Funcional RicardoK@EAPSA.com.pe 3230
Sub Gerente
Norman NormanQ@EAPSA.com.pe 3275
Funcional
Vanessa Gerente funcional vbarton@EAPSA.com.pe 3228

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Responsable de XXX
Elena Seguridad de la ElenaD@EAPSA.com.pe
información
Responsable de XXX
Maria Aseguramiento de la MariaS@EAPSA.com.pe
calidad
Responsable de XXX
Jose JoseT@EAPSA.com.pe
Produccióon
Responsable de XXX
Cesar CesarA@EAPSA.com.pe
Tecnologiía
Gabriel Analista de Riesgos GabrielL@EAPSA.com.pe XXX
Por parte del Proveedor: XXX
Nombres y Apellidos Rol Proveedor E-mail Teléfono

Gabriel Gerente del
GrabielO@XXXsac.com XXX
proyecto XXX
David Analista Funcional DavidB@XXXsac.com XXX
Renan Analista Técnico RenanK@XXXsac.com XXX
John Jefe de Proyecto JohnF@XXXsac.com XXX
Nathali Ejecutiva de XXX
NathaliA@XXXsac.com
cuentas
4.6 Supervisión del Proyecto.
Para efectos de supervisión del servicio y conforme a lo definido en el pliego de condiciones

técnicas, se establecerán los siguientes comités:
4.6.1 Comité de Gerencia
Incepción
Tiene por objeto verificar que los planes del proyecto se cumplan. Por parte de
EAPSA deberán participar: el Líder Usuario (Gerencia o Sub Gerencia funcional de
Operaciones y/o Gerencia de Negocios e Investigación), el Sponsor del proyecto
(Gerencia de Sistemas), el responsable del proyecto y la PMO. Por parte del
proveedor XXX participará el Gerente del Proyecto y el jefe de proyecto.
El Comité de Gerencia se reunirá por lo menos una vez por mes a fin de tomar
decisiones respecto a la conducción del proyecto, debiendo:
 Revisar el avance del proyecto.
 Resolver conflictos que en primera instancia el Comité Operativo no ha podido
resolver.
 Convocar el apoyo o participación de otras áreas de EAPSA y/o de XXX
afectadas por el proyecto.
 Mantener informado a los stakeholders del proyecto respecto al alcance y
evolución del mismo.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Los Comités de Gerencias serán convocados los últimos martes de cada mes.
4.6.2 Comité de Operativo del Proyecto
Tiene por objeto realizar el seguimiento detallado a las actividades del proyecto. Por
EAPSA deberá participar el responsable del proyecto, y los analistas técnicos y por
parte de XXX participarán el Jefe del Proyecto y analistas.
El Comité Operativo del Proyecto deberá reunirse semanalmente. Los informes de

avance semanal y final serán elaborados en conjunto por XXX y EAPSA y
presentados en los comités operativos (Semanales) y Gerenciales (Mensuales).
El Comité Operativo se convocaráa con el objeto de tomar decisiones y evaluar los

siguientes aspectos de cada proyecto:
 Revisar en detalle el cronograma del proyecto.
 Aprobar cambios menores en el cronograma, siempre que no afecte plazos de
cierre de hitos.
 Aprobar los Entregables.
 Formular solicitudes de Control de Cambio.
 Resolver conflictos que se pudieran presentar durante la ejecución del proyecto.
 Gestionar los riesgos del proyecto.
 Convocar el apoyo o participación de nuevos usuarios o personal de soporte de
EAPSA y/o del proveedor.
 Convocar Comités de Seguimiento del Proyecto de urgencia cuando situaciones
de alto riesgo del proyecto lo amerite.
Asimismo, el Comité operativo podrá contar con la participación de los usuarios

funcionales y/o sponsor si es que así lo requiriese.
4.7 Organización propuesta para el Proyecto.
El Plan de Gestión Humana del proveedor establece formalmente los lineamientos a seguir para
gestionar eficientemente al personal asignado al proyecto, a fin de cumplir con los objetivos
planteados en el presente proyecto.
4.7.1 Organigrama.
Recogiendo las necesidades del proyecto, se propone la siguiente organización para la prestación
del proyecto:

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Sponsor
Responsable de
Proyecto
PMO Riesgos
Equipo de Equipo de Equipo de Grte. Proyecto

Usuarios Seguridad Sistemas EAPSA (TASE)
Ejecutivo de
Cuenta
Jefe Proyecto
(TASE)
Analista Analista Técnico

Funcional(Tase) (TASE)
4.1.1. Roles y Responsabilidades del Proyecto
Rol Responsabilidades
 Garantizar la disponibilidad de los recursos que aseguren el
éxito del proyecto.
Gerente de Proyecto (XXX)
 Informar el avance de los proyectos en el Comité de Gerencia
del Servicio.
 Supervisar en forma directa la ejecución del Plan detallado del
Proyecto.
 Administrar y controlar los recursos asignados al proyecto.
 Controlar que el Proyecto se lleve a cabo en los plazos
previstos y con la calidad adecuada.
 Revisar y aprobar el plan del proyecto.
Jefe de Proyecto (XXX)  Identificar problemas, riesgos y tomar acciones de forma
preventiva
 Informar semanalmente el avance de los proyectos al Comité
Operativo.
 Realizar las estimaciones y elaborar el cronograma de trabajo
 Realizar el análisis de impacto de la solicitud de cambios de
alcance del Proyecto.
Analista Funcional (XXX)  Elaborar en conjunto con el Jefe del proyecto en el desarrollo
del Plan de Proyecto, definiendo para ello el alcance del
proyecto, alcance del producto.
 De forma conjunta con el jefe de proyecto define la
organización del proyecto y elabora los planes de soporte.
 Informar al jefe de proyecto sobre la evolucion del desarrollo
del proyecto, identtificando problemas y posibles riesgos.
 Participar en la ejecución del plan detallado del proyecto.
 Sostener reuniones periódicas con el Responsable del
proyecto de EAPSA y los analistas funcionales involucrados

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
según amerite.
 Responsable de elaborar el análisis, diseño funcional del
proyecto.
 Analizar y elaborar la documentacion funcional del proyecto
 Transferir la documentación y conocimiento funcional al equipo
de Sistemas de EAPSA para que puedan realizar las
actividades de soporte y continuidad de negocio.
 Sostener reuniones, según amerite, con el Responsable del

proyecto de EAPSA y los analistas tecnicos/funcionales
involucrados.
 Responsable del análisis, diseño técnico del proyecto.
 Efectuar la construccion cumpliendo con los estándares.
Analista Tecnico (XXX)
 Elaborar la documentacion teecnica de la Solucion
 Elaborar y/o actualizar los documentos teécnicos relacionados
con el Desarrollo de la Solucióon.
 Dar soporte, debiendo absolver consultas y solucionar
observaciones que EAPSA formule durante su etapa de
pruebas.
 Realizar visitas periódicas con el fin de monitorear el status
general del proyecto.
 Establecer y mantener comunicación constante entre ambas
Ejecutivo de Cuenta (XXX) empresas a fin de recibir sugerencias, observaciones,
inquietudes o insatisfacciones.
 Medir el nivel de cumplimiento y satisfacción del cliente con
respecto a los servicios prestados.
 Centralizar comunicación con el proveedor
 Elaborar el plan de direccion del proyecto (PDP) con el
proveedor
 Controlar que el proyecto se dasarrolle de acuerdo a las
consideraciones del PDP
 Gestionar los requerimientos del proyecto.
 Hacer seguimiento al avance de las actividades con el
proveedor
 Convocar y participar en las reuniones del Comité Operativo y
Comité de Gerentes del proyecto durante las actividades con el
proveedor
Responsable de Proyecto
 Elaborar el informe de avance semanal de las actividades con
(EAPSA)
el proveedor
 Informar el avance semanal de las actividades con el
proveedor a la PMO
 Validar que todos los entregables hayan sido aprobados por el
Sponsor/Responsable a cargo
 Identificar riesgos y gestionar la ejecucióon de los planes de
accion acordados con el equipo del proyecto
 Validar las facturas y centros de costos asignados
 Reportar al sponsor las solicitudes de control de cambio
 Asegurar que el proyecto estée alineado con los
requerimientos del Sponsor
Analista de Aseguramiento  Planificar y validar el cumplimiento de las revisiones de control
de la Calidad de la calidad del producto, considerando los estándares

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
establecidos por EAPSA.
(EAPSA)  Realizar las pruebas en el ambiente de calidad.
 Informar las no conformidades encontradas.
 Hacer seguimiento al cierre de las no conformidades.
 Encargado de la elaboracion del plan de pruebas.
 Encargado de la realización de las pruebas funcionales en el
ambiente de pre-producción.
 Evaluar los resultados de las no conformidades notificadas por
las áreas usuarias del requerimiento desplegado en pre-
Analista Funcional producción.
(EAPSA)  Realizar la aceptación del producto luego de la aprobación de
las pruebas de certificación firmando el Acta de Aceptación del
Producto.
 Validar que el alcance funcional satisfagacen las
especificaciones solicitadas por el usuario.
 Validar los entregables funcionales del proyecto (alcance del

proyecto, casos de prueba y resultados de las pruebas)
Gerente Funcional /Usuario
 Participarn del comité de Gerencia de EAPSA y el Comité de
Lider
proyectos de la PMO.
 Aprobar los activos de la organización del proyecto.
 Aprobacioón de los entregables funcionales del proyecto
(alcance del proyecto)
 Aprobacióon de la solicitud de control de cambios.
Sponsor  Aprobacióon del plan del proyecto y del cronograma integral
del proyecto.
 Participar del comité de Gerencia de EAPSA y el Comité de
 Encargado de la realización de los pases a producción.
 Validar el documento tecnico de la solucion (mapeo de datos,
arquitectura, etc)
Responsable de
Producción (EAPSA)  Realizar la reversión del pase a producción en caso de que un
nuevo pase afecte la disponibilidad de la aplicación o se haya
identificado un problema grave en la funcionalidad modificada
que afecte su uso normal por parte de los usuarios.
 Elaborar los entregables bajo su responsabilidad.
 Validar que se hayan considerado todas las dependencias (de
codigo y/o permisos ) de la solucioón y las modificaciones
adicionales en otros móodulos de ser necesarias
 Absolveruelve consultas del proveedor y del responsable del
Analista de Sistemas proyecto para la elaboracion del diseño funcional.
(EAPSA)  Analizar las observaciones en la fase de pruebas para
determinar si el origen del error es por parte de EAPSA o
Proveedor
 Instalacion y configuracioón de PC's para el proveedor
 Coordinación con el área de PRODUCCIOÓN para la
aprobación del documento técnico
Responsable Seguridad de  Certificar la solución implementada técnicamente desde la
la Información (EAPSA) perspectiva de Riesgos y Seguridad de la información, según
aplique el alcance del proyecto.
 Firmar el Acta de Aceptación del Producto dando conformidad

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
a las Prueba de Seguridad realizadas.
 Elaborar el reporte de Riesgo Operacional previo a la fase de

Responsable de Riesgos
construcción y darle seguimiento.
 Certificar la solución implementada desde la perspectiva de
Comunicaciones, según aplique el alcance del proyecto.
Responsable de Soporte  Proveer del software y hardware necesario para el proyecto.
(EAPSA)  Otorgar accesos/facilidades requeridos por los distintos
involucrados del proyecto para permitirles cumplir con las
actividades que tienen asignadas.
 Coordinar con los responsables de proyecto e involucrados
claves para resolver restricciones y/o optimizar la gestión de
recursos, riesgos, alcance, cronograma y presupuesto,
controlando posibles desviaciones respecto al plan.
 Consolidar los informes de avance y final de los proyectos para
presentarlos al Comité de Proyectos.
 Presentar las solicitudes de cambio derivadas al Comité de
proyectos.
 Informar en el Comité de Proyectos mediante métricas de
Responsable de la Oficina gestión el desempeño de los proyectos, proponiendo cambios
de Gestion de Proyectos en los planes de acción para los casos en que los indicadores
sean desfavorables.
 Presentarcion del Estado del Proyecto al comité de Gerencia y
comité de proyectos.
 Control y seguimiento al avance del proyecto para el
cumplimiento de los plazos previstos y cumpla con los objetivos
del proyecto.
 Validar que los entregables sean aprobados por el gerente
sponsor antes de pasar a la siguiente fase del proyecto.
5. TÉRMINOS DE ATENCIÓN
Responsabilidades de las partes
Se requiere del compromiso de ambas partes para alcanzar el éxito del proyecto, por tanto
ambos deben asumir un compromiso de confidencialidad de información relativo a datos, formas
de trabajo, conocimientos, y/o aspectos que formen parte de sus activos de negocio de
cualquiera de las partes.
XXX se compromete a asegurar la confiabilidad y seguridad de la información obtenida para la

atención del proyecto, en contraparte, EAPSA se responsabiliza de la correcta aplicación de los
planes de mejora, así como de no divulgar con terceros los conocimientos, metodologías y
prácticas de proveedor ejercidos durante la atención del proyecto, salvo que medie autorización
expresa.
Dado el caso, la parte afectada deberá informar el caso al Comité de Seguimiento del Proyecto a
fin que redimensione el alcance de la prestación a niveles acordes con el plazo y participación
estimada de profesionales para su atención.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
5.1.1. Por EAPSA.
Siendo el éxito del proyecto responsabilidad de las partes involucradas, EAPSA deberá proveer
las siguientes tareas y/o facilidades:
1. Proveer un ambiente para la realización del kick-off de inicio del proyecto, reunión a la
que deberán asistir los Responsables del Proyecto para revisar y ratificar los alcances,
operativa y términos de atención del proyecto.
2. Brindar las facilidades del caso para la realización del Análisis de Requerimientos:
a. Durante el Kick-off definir los interlocutores válidos por cada proyecto, cuya
participación deberá ser a tiempo completo.
b. Proveer a XXX la información y documentación requerida.
3. Asignar interlocutores válidos para la definición de los requerimientos del proyecto con
una dedicación no menor al 50% durante las etapas de Análisis y Diseño, con el objeto
que explique, absuelva consultas, y valide los avances de diseño del equipo del
proveedor.
4. Estos interlocutores podrán estar acompañados de usuarios o técnicos especialistas en
temas específicos, debiendo ser los mismos que formularon los requerimientos y
aprobaron el diseño, quienes participen y lideren la etapa de Pruebas de EAPSA con
una dedicación al 100% en esta etapa.
5. Informar la planificación o ejecución de alguna actividad o proyecto en EAPSA o
entidades afectas al presente proyecto, que genere una dependencia con el presente,
ello con el objeto de identificar y monitorear los posibles impactos y riesgos que se
pudieran generar.
6. Revisar y aprobar los Entregables o documentos presentados por XXX dentro del plazo
establecido por el Cronograma del Proyecto o en caso de no establecerlo, en un plazo
máximo de 3 días hábiles. En caso EAPSA no comunique sus observaciones dentro de
dicho plazo, procederá una aprobación automática cuya acta impresa deberá ser
firmada en los siguientes 3 días, y habilitando a XXX de continuar con las actividades
subsecuentes.
7. Atender los pagos al proveedor en función a las Condiciones Comerciales precisadas en
el presente documento
8. Brindar las facilidades del caso para la realización de las Pruebas de EAPSA bajo las
siguientes consideraciones:
a. Proveer el set de pruebas (data y casuística) para la elaboración de los casos de
prueba.
b. Proveer el hardware y software necesario durante las Pruebas (Internas de XXX y de
EAPSA) para la operación del sistema en condiciones similares a las reales en
Producción.
c. Habilitar posiciones de trabajo en el local del EAPSA para realizar labores de análisis,
diseño y pruebas en general.
d. Asignar las cuentas y permisos de acceso a los entornos requeridos.
e. Asegurar la participación de usuarios probadores a tiempo completo durante la etapa
de Pruebas del EAPSA
9. EAPSA tendrá a bien emitir una Carta indicando el cumplimiento del Proyecto ANTES
DEL PLAZO si XXX finaliza el proyecto en mención antes o en los días estipulados en el
cronograma de cada proyecto.
5.1.2. Por XXX
Por su parte, el proveedor se obliga a atender las siguientes tareas o funciones:

1. Efectuar el desarrollo de la solución de BI (DATAMART DE OPERACIONES) de
acuerdo a los alcances funcionales y técnicos establecidos en esta propuesta y diseño
aprobado.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
2. Ejecutar el proyecto dentro de los términos de tiempo establecidos en el Cronograma

del Proyecto.
3. Presentación de los Entregables comprometidos en las fechas señaladas por el
Cronograma detallado del Proyecto, así también subsanar en paralelo a la revisión, las
observaciones que EAPSA formule.
4. Mantener la supervisión mediante reuniones de seguimiento al avance de los trabajos,
reunión en la que deberán participar los Responsables del Proyecto o personas
delegadas por los mismos.
5. Construir una solución alineado a estándares y buenas prácticas para proyectos de
inteligencia de negocio.
6. La actuación del equipo de desarrollo de XXX dentro de las Pruebas de EAPSA será de
soporte, debiendo absolver consultas y solucionar observaciones que EAPSA formule.
7. Atender las incidencias que se presenten durante la etapa de Post-Implantación, dentro
de los plazos más breves posibles y considerando las prioridades operativas que
comunique EAPSA alineada a la garantía del producto.
8. Informar al Comité Operativo y Gerencial los avances del proyecto.
5.2. Cumplimiento de Plazos
La planificación considera la atención de las actividades y plazos establecidos en el Cronograma

del Proyecto tanto por parte del equipo de XXX como por EAPSA (en especial aquellas
actividades que condicionan el avance de XXX). En caso de incumplimiento de plazos por causas
imputables a XXX, el esfuerzo que demande su recuperación será asumido por XXX sin que se
modifique la fecha de término del proyecto. (¿y si modifican la fecha de téermino?).? Así también,
en caso el incumplimiento no sea imputable a XXX, las actividades subsecuentes y plazo del
proyecto se ampliarán por el tiempo de atraso incurrido, lo cual significará una re-planificación
que deberá ser formalizada mediante Acta de Control de Cambio, debiendo EAPSA reconocer el
pago de los costos derivados de esta ampliación y cuyo importe se calculará en función a las
jornadas extras por colaborador asignado al proyecto multiplicado por la tarifa que corresponda.
(vVer cláausula novena y séptima (7.5) del contrato marco)
5.3. Confidencialidad de la información
El proveedor XXX se obliga y compromete a proceder de forma estrictamente confidencial con

toda la información recibida y generada en la provisión de este proyecto a EAPSA. Este acuerdo
de confidencialidad se mantendrá vigente por tiempo indefinido luego de producida la aceptación
del proyecto y con ello, el término del contrato con EAPSA. (Vver cláausula déecimo quinta del
contrato marco.)
5.4. Caso fortuito o fuerza mayor
EAPSA podrá conceder una prórroga de tiempo adicional al pactado por cada proyecto, si por
causa fortuita o fuerza mayor, ajena a la voluntad de XXX debidamente justificada a satisfacción
de EAPSA, el proyecto no pudiera concluirse en el plazo especificado. (Vver cláausula del
contrato marco)
5.5. Suspensión del Proyecto
Si por decisión de EAPSA el proyecto se suspendiese, los plazos del proyecto se extenderán por
plazo igual al de la suspensión, con la retribución económica en función al precio y plazo total
original. (Vver claáusula del contrato marco)

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
5.6. Propiedad intelectual
XXX cederá a favor de EAPSA los derechos de propiedad intelectual de todos los artefactos que
constituyen la solución de mejora a implementar o implementada una vez EAPSA otorgue la
conformidad correspondiente. (Vver cláausula vigésima del contrato marco)
5.7. Procedimiento para las modificaciones
Cualquier variación a los requerimientos originalmente formulados del proyecto o definiciones de

diseño aprobados, solo tendrá efecto de atención en la medida que sea aprobado mediante una
Gestión de Cambio y bajo el procedimiento señalado en el numeral del mismo nombre del
presente documento, siendo éeste el único canal válido y aplicable para incorporar nuevos
trabajos dentro de los alcances de cada proyecto.
5.8. Condiciones de Inicio.
1. El proyecto inicia cuando el cliente apruebe el Plan de Dirección del Proyecto, Cronograma,
Alcance del Producto.
2. El proyecto deberá iniciar con una reunión de Kick-off en la que las partes deban presentar a
los responsables del proyecto y equipo de trabajo. En esta reunión se expondrán los términos
de atención del proyecto, así también se presentarán a los Responsables del proyecto,
quienes suscribirán el Acta de Constitución del Proyecto.
5.9. Condiciones de término del proyecto.
Cada proyecto se dará por terminado

1. Al completarse los Entregables comprometidos para el Proyecto.
2. En caso se decida posponer la fase de implementación de la solución o actividades
subsiguientes, por un plazo mayor a 3 días hábiles, en cuyo caso deberá reprogramarse
mediante una Gestión de Cambio o atender las fases pendientes mediante un nuevo
proyecto complementario.
3. La suspensión de la fase de implementación y/o fases subsiguientes por motivos ajenos a
XXX bajo los considerandos expuestos precedentemente, no afecta la conclusión del proyecto
y servicio comprometido, ni la obligación del Cliente de atender los pagos correspondientes al
proyecto contratado, considerando su ejecución hasta el último día que registre actividad el
Cronograma del Proyecto. Cualquier actuación posterior de XXX con relación al proyecto
deberá atenderse mediante un Control de Cambio que amplíe los alcances y cronograma del
proyecto o nuevo Proyecto.
(Vver cláausula déecimoa cuarta del contrato marco)
5.10. Garantía
XXX ofrece una garantía por la solución implementada por un plazo de 06 meses contabilizados
a partir del pase a producción, aprobación, entrega del DATAMART de Operaciones. En tal
sentido, XXX se compromete a subsanar los malfuncionamientos que reporte el Cliente por error
de construcción de los componentes de integración y explotación desarrollados por XXX, sin
embargo, es importante precisar que la Garantía no aplica a los siguientes casos:
1. Cuando se presentan situaciones operativas no previstas en el análisis ni modelo

propuesto, surgidos a partir de la ocurrencia de nuevos eventos, cambios en la organización,
cambios normativos o del contexto del proceso, entre otros.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
2. Cuando no se cuenta con la infraestructura requerida para que la solución opere

eficientemente.
3. Cuando el personal que opera el sistema no lo hace apropiadamente
4. Cuando una vez implementada la solución, subsisten procedimientos que no estén
alineados con la nueva operativa que persigue la solución.
5. Casos de mejora del sistema con características no previstas en la propuesta o diseño
aprobado.
6. Vacíos funcionales, indefiniciones, o validaciones no especificadas en los alcances del
proyecto o diseño aprobado.
7. Malfuncionamientos originados por la mala configuración del hardware o software base
a cargo de EAPSA.
8. Malfuncionamiento originado por cambios en las estructuras de las fuentes utilizadas
y/o data inconsistente que no hayan sido evidenciadas en el análisis de datos (Nuevos casos
presentados).
9. Malfuncionamiento originado en cambios a los procesos desarrollados por personal
ajeno a XXX, en cuyo caso los componentes afectos pierden en automático la garantía.
Ante la reiteración de incidencias acusadas por el Cliente, cuya responsabilidad no se origine en

la actuación de XXX, sino en agentes ajenos a eéste, XXX podrá facturar el tiempo invertido en el
análisis de causa y diagnóstico realizado en función a las jornadas invertidas y tarifa formulada
en la presente propuesta.
6. Control y Seguimiento del Proyecto
A efecto de establecer una permanente comunicación y coordinación de las partes involucradas en el

proyecto, la gestión del proyecto deberá atender las siguientes actividades de supervisión:
6.1. Informe periódico de avance.

Los informes de avance del proyecto se presentarán durante los Comités operativos y
Gerenciales. Esta información corresponderá al Cronograma del Proyecto registrado en
archivo Project, medido el avance en porcentaje con corte a la víspera del Comité (al cierre
semanal), debiendo ser remitido mediante correo electrónico al responsable del proyecto
por parte de EAPSA, quien a su vez será el responsable de distribuir la información a las
instancias de seguimiento competentes al interior de su organización.
6.2. Seguimiento de desviaciones

Significativas
Los informes de avance del proyecto, deberán indicar el porcentaje de desviación del
proyecto, respecto a lo planificado.
A continuación, se presenta una clasificación del nivel de impacto según la magnitud de la

desviación, para determinar quienes participaran en la elaboración del plan de acción:
Nro. Umbral en desviación de: Acción a Tomar Involucrados

1 Impacto Bajo: Retrasos de Reunión Equipo de Proyecto Comité Operativo
cronograma menor al 5% del
esfuerzo estimado.
2 Impacto Medio: Retrasos de Reunión Comité de Gerencia Comité Gerencia
cronograma entre el 5% y el
10% del esfuerzo estimado.
3 Impacto Alto: Retrasos de Reunión Comité de Proyectos Comité de Proyectos

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
cronograma mayor a 10% (Gerencia General)

del esfuerzo estimado.
6.3. Corte de Evaluación - NO Aplica
7. CONTROL DE CAMBIO
7.1. Cambios
Se denomina Cambio cuando se agrega, modifica o elimina el alcance de la funcionalidad original

del proyecto, que puede afectar la línea base de la estimación del tiempo y/o costo original
aprobado.
Esta variación, estará sometida a las siguientes limitaciones:
1. Deberán mantenerse sustancialmente las condiciones para la ejecución del proyecto.

2. Deberá guardarse el equilibrio financiero del proyecto para ambas partes.
3. Debe reconocerse a favor de las partes los incrementos de costos derivados de las
modificaciones aceptadas.
7.2. Clasificación del cambio
Los cambios o variaciones podrán calificarse como:

 Bajo:
Retrasos de cronograma menor al 5% del esfuerzo estimado.
 Medio:
Retrasos de cronograma entre el 5% y el 10% del esfuerzo estimado.
 Alto:
Retrasos de cronograma mayor a 10% del esfuerzo estimado.
7.3. Acta de Control de Cambio para la

Aprobación de la Solicitud de Cambios de Alcance del Proyecto
Acta en la que se describe y aprueba la variación de alguna característica del proyecto. Este
documento contendrá, por lo menos los siguientes datos:
o Descripción del cambio
o Documento anexo (Solicitud de cambios de alcance del proyecto)
o Estado de aprobación o desaprobación.
8. GESTIOÓN DE COMUNICACIONES
Nombres y
Rol Responsabilidad
Apellidos
Gerente Sponsor Gerente XXXX  Aprobacióon de los entregables
funcionales del proyecto (alcance

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
del proyecto)
 Aprobacióon de la solicitud de
control de cambios.
 Aprobacioón del plan del proyecto y
del cronograma integral del
proyecto.
 Aprobacióon de los Manuales de
usuario y de Instalacióon.
 Aprobación del informe de cierre
del proyecto.
 Participa del comité de Gerencia de
EAPSA y el Comité de proyectos
de la PMO.
Responsable del proyecto Por definir  Elaborar el Plan de Proyecto,
definiendo para ello el alcance del
 Manejar adecuadamente la relación
con la contraparte técnica y
funcional del proyecto.
 Coordinar las necesidades de las
áreas usuarias.
 Atiende consultas, y gestiona las
facilidades requeridas por los
Analistas del proveedor.
 Gestiona para cada entregable las
aprobaciones pertinentes al interior
de EAPSA.
 Analiza la(s) causa(s) de la(s)
observación(es) producida(s) en
Certificación para indicar la
responsabilidad del proveedor o de
EAPSA.
 Supervisar en forma directa la
ejecución del Plan detallado del
Proyecto integral.
 Administrar y controlar los recursos
asignados al proyecto.
 Seguimiento y Control para que el
Proyecto integral se lleve a cabo en
los plazos previstos y con la calidad
adecuada.
 Elaborar/Revisar el plan del
proyecto y lo presenta al gerente
sponsor para su aprobacion.
 Identificar problemas, ejecuta los
planes de accioón frente a los
riesgos identificados.
 Informar el status semanal del
proyecto, hitos alcanzados,
problemas a los stakeholders del
proyecto y a los ejecutivos de la
Oficina de Gestióon de proyectos
(PMO).

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
 Convocar a las reuniones del

comité operativo y el comité de
Gerentes.
 Asignar los responsables de cada
actividad.
 Validar las facturas emitidas por el
proveedor.
 Elaborar y reportar a la gerencia
usuaria/sponsor las solicitudes de
control de cambios.
 Verificar que la solución técnica
propuesta corresponda al objetivo
del proyecto.
 Confirmar que la solución técnica
propuesta haga un uso eficiente de
los recursos de la aplicación.
 Validar que se hayan considerado
todas las dependencias (de código
y/o permisos) de la solución y las
modificaciones adicionales en otros
módulos de ser necesarias.
 Garantizar que el rendimiento de la
Analista de Sistemas Hector aplicación no se vea impactado en
forma negativa por la solución
propuesta.
 Coordinar con el desarrollador
interno o externo (proveedor) las
actividades propias del área de
Sistemas (alcance, control de
cambios, pruebas).
 Informar al responsable del
proyecto las desviaciones en el
cronograma, costo y alcance.
 Elaborar los entregables bajo su
responsabilidad.
 Encargado de la elaboracion del
plan de pruebas.
 Encargado de la realización de las
Jorge pruebas funcionales en el ambiente
Analista funcional EAPSA
de pre-producción.
 Participar de las reuniones para
definir el alcance del proyecto.
Gerente Funcional Pedro  Aprobacióon de los entregables
funcionales del proyecto (alcance
del proyecto)
 Participan del comité de Gerencia
de EAPSA y el Comité de
 Aprobar los activos de la
organización del proyecto.
 Realizar la aceptación del producto
luego de la aprobación de las

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
pruebas de certificación firmando el

Acta de Aceptación del Producto.
 Certificar la solución implementada

técnicamente desde la perspectiva
de Riesgos y Seguridad de la
información, según aplique el
Responsable de Seguridad
Liliana alcance del proyecto.
de la información
 Firmar el Acta de Aceptación del
Producto dando conformidad a las
Prueba de Seguridad realizadas.
 Planificar y validar el cumplimiento

de las revisiones de control de la
calidad del producto, considerando
los estándares establecidos por
Responsable de EAPSA.
Aseguramiento de la Maríia  Realizar las pruebas en el ambiente
calidad de calidad.
 Informar las no conformidades
encontradas.
 Hacer seguimiento al cierre de las
no conformidades.
 Encargado de la realización de
los pases
 a producción.
 Realizar la reversión del pase a
Responsable de producción en caso de que un
Roberto nuevo pase afecte la disponibilidad
Produccióon
de la aplicación o se haya
identificado un problema grave en
la funcionalidad modificada que
afecte su uso normal por parte de
los usuarios.
 Certificar la solución implementada
desde la perspectiva de
Comunicaciones, según aplique el
alcance del proyecto.
 Proveer del software y hardware
Responsable de necesario para el proyecto.
Samuel
Tecnologiía
 Otorgar accesos/facilidades
requeridos por los distintos
involucrados del proyecto para
permitirles cumplir con las
actividades que tienen asignadas.
 Elaborar el reporte de Riesgo
Analista de Riesgos Gabriel Operacional previo a la fase de
construcción y darle seguimiento.
Analista Téecnico (EAPSA) Roxana  Verificar que la solución técnica
propuesta corresponda al objetivo
del proyecto.
 Confirmar que la solución técnica

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
propuesta haga un uso eficiente de

los recursos de la aplicación.
 Validar que se hayan considerado
todas las dependencias (de código
y/o permisos) de la solución y las
modificaciones adicionales en otros
módulos de ser necesarias.
 Garantizar que el rendimiento de la
aplicación no se vea impactado en
forma negativa por la solución
propuesta.
 Coordinar con el desarrollador
interno o externo (proveedor) las
actividades propias del área de
Sistemas (alcance, control de
cambios)
 Elaborar el plan de actividades
(cronograma y presupuesto)
requeridas para la implementación
de Sistemas.
 Informar al responsable del
proyecto las desviaciones en el
cronograma, costo y alcance.
 Realizar visitas periódicas con el fin
de monitorear el status general del
proyecto.
 Establecer y mantener
comunicación constante entre
Ejecutivo de Cuenta (XXX) Nathali ambas empresas a fin de recibir
sugerencias, observaciones,
inquietudes o insatisfacciones.
 Medir el nivel de cumplimiento y
satisfacción del cliente con
respecto a los servicios prestados.
Gerente del proyecto XXX Roberto  Asegurar la disponibilidad de los
recursos que aseguren el éxito del
proyecto.
 Informar el avance de los proyectos
en el Comité de Gerencia del
Servicio.
Analista Funcional XXX Percy  Elaborar el Plan de Proyecto,
definiendo para ello el alcance del
 De forma conjunta con el Jefe de
Proyecto define la organización del
proyecto y elabora los planes de
soporte.
 Informar al jefe de proyecto sobre
la evolucioón del desarrollo del
proyecto identificando problemas y
posibles riesgos.
 Participar en la ejecución del plan
detallado del proyecto.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
 Sostener reuniones periódicas con

el Responsable del proyecto de
EAPSA y los analistas funcionales
involucrados según amerite.
 Responsable del análisis, diseño
funcional del proyecto.
 Analizar y completar la
documentación funcional.
 Transferir la documentación y
conocimiento funcional al equipo de
Sistemas de EAPSA para que
puedan realizar las actividades de
soporte y continuidad de negocio.
Analista Técnico XXX Christian  Sostener reuniones, según amerite,
con el Responsable del proyecto de
EAPSA y los analistas
téecnicos/funcionales involucrados.
 Responsable del análisis, diseño
técnico del proyecto.
 Efectuar la construccióon
cumpliendo con los estándares.
 Elaborar la documentacion téecnica
de la Solucióon
 Elaborar y/o actualizar los
documentos relacionados con el
Desarrollo de la solucióon.
 Construir los componentes de
integracióon y explotacioón
necesarios en el desarrollo de la
solucióon.
 Dar soporte, debiendo absolver
consultas y solucionar
observaciones que EAPSA formule
durante su etapa de pruebas.
Jefe de Proyecto XXX David  Supervisar en forma directa la
ejecución del Plan detallado del
Proyecto.
 Administrar y controlar los recursos
asignados al proyecto.
 Controlar que el Proyecto se lleve a
cabo en los plazos previstos y con
la calidad adecuada.
 Revisar y aprobar el plan del
proyecto.
 Identificar problemas, riesgos y
tomar acciones de forma preventiva
 Informar el avance de los proyectos
al Comité Operativo.
 Realizar las estimaciones y elabora
el cronograma de trabajo
 Realizar el análisis de impacto de la
solicitud de cambios de alcance del

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Proyecto.
8.1. Canales de Comunicación
Las comunicaciones, documentos, artefactos, y actas serán remitidos a través del correo
electrónico, teniendo validez formal este canal para todo efecto.
Alternativamente, y sóolo para los documentos y artefactos en que las partes así lo convengan,
se podrá utilizar el Jira como medio de comunicación y aprobación.
8.2. Matriz de Comunicaciones
Se ha desarrollado la matriz de comunicaciones, considerando en ella los flujos de información

permanentes. En ella se puede apreciar los generadores de la información y los receptores,
también se establece el medio y/o formato en el cual se entrega la información, así como los
responsables de la revisión y aprobación de cada uno de los entregables del proyecto.
Leyenda:
* Quien crea el correo / documento
R Quien revisa el documento
√ Quien aprueba el documento
Parte Interesada
Responsable QA
Jefe de Proyecto (XXX)
Gerente de Proyecto (XXX)

Responsable Seguridad
Analista de Sistemas
Sponsor
Analista Funcional (XXX)
Analista Tecnico (XXX)

Responsable de Producción
Gerente Funcional
Analista Funcional
Fase Documentos
Responsable de proyecto
Incepción Plan de Dirección del Proyecto * * √R R

Cronograma LB2 *R *R √ R R
Análisis Diagrama de Arquitectura R R √ *
R
Fichas de Reportes y/o Tableros R R √ √ R R *
Documento de Especificaciones R R √ R R R *
Funcionales (REF)
Diseño Modelo de Datos R R √R *
Diccionario de Datos R R √R *
Dimensionamiento de BD R R √R *
Documento de Especificaciones R R √R *
Técnicas (RET Preliminar)
Construcció Informe de Pruebas Unitarias (RPU) R R √R *
n
Informe de Pruebas Integrales (RPI) R R √R *
Ficha de Información Modelo Lógico R R √R *
(Framework Manager)

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Plan de Certificación *R R √ √ *R *R *R *R *R * *

Documento de Especificaciones R R √R *
Técnicas (RET Final)
Transición Acta de Aceptación del Producto * √ R
Pase Manual de Usuario R R √ R R R *
Producción
Manual de Instalación R R R √ *
R
Informe de Cierre del Proyecto *R R √ R
(*) La relación de los entregables se detalla en la sección 4.3 Entregables de Ingeniería.
8.3. Interdependencias con Otros Proyectos
Fecha de
Nº Nombre del Proyecto Empresa Dependencia
Impacto
DEPENDENCIA ENTRADA: Son los Proyectos que dependemos.
Abr-14 Limpieza de
1 Reestructuracion RUT TGA
datos
DEPENDENCIA SALIDA: Son los Proyectos que dependen de este Proyecto.
9. GESTIÓN DE LA CALIDAD DEL PROCESO Y PRODUCTO
Cada componente construido y sistema en conjunto será sometido a verificaciones de calidad al

interior del equipo de implementación de XXX y con EAPSA para su aprobación.
EAPSA ha definido las siguientes pruebas de calidad y clasificado las posibles observaciones que se
reciban, teniendo cada uno un tratamiento definido:
9.1. Aseguramiento de Calidad del Proceso
El proyecto establece un Proceso de Desarrollo a seguir, el mismo que a su vez define los
Entregables en cada una de sus fases. El Aseguramiento de la Calidad del Proceso es un
proceso de verificación interna del proveedor que tiene como objeto velar que cada una de
dichas fases y actividades se encuentren alineados con las prácticas y estándares
definidos, con impacto directo en la calidad de la solución final.
9.2. Aseguramiento de Calidad del Producto.
El proyecto establece una serie de Entregables que describen la evolución y características

del sistema objeto de atención del proyecto, debiendo eéstos ser sometidos a revisiones y
aprobaciones por los Responsables del Proyecto, y dentro de un calendario de entregas
establecido en el Cronograma detallado del Proyecto, el cual deberá ser acatado
escrupulosamente.
El proveedor ha considerado conveniente incluir dentro de la gestión de calidad del

proyecto, las siguientes actividades de verificación:

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
9.2.1. Revisión de Pares
No aplica
9.2.2. Pruebas Unitarias e integrales
Se realizaráan pruebas a los componentes que conforman el producto a entregar

durante la fase de construcción. Estas pruebas estarán lideradas por el equipo de
desarrollo del proyecto (XXX) que incluirá pruebas unitarias e Integrales a nivel
técnico y funcional.
9.2.3. Pruebas de Transición
El Plan del Proyecto considera días dedicados a ejecutar las Pruebas de

certificación, actividad de responsabilidad de EAPSA (Aseguramiento de la calidad,
producción, Seguridad de la Información y Usuarios funcionales) y en el que
deberá participar directamente los Interlocutores definidos para el proyecto, así
como se recomienda también lo haga, personal informático del área de sistemas de
EAPSA, cuyo objeto es que verifiquen y validen el funcionamiento de los
componentes construidos (ETL, Jobs, Modelo lógico y reportes) en concordancias
con las definiciones de diseño. Estas pruebas se realizarán con data creada
conforme a la configuración real con la que operará el sistema en Producción. Estas
pruebas deberán realizarse dentro del tiempo estimado en la propuesta en la fase de
Transición de procesos desarrollados
9.3. Tipos de Observaciones
XXX prevé la ocurrencia de distintos tipos de observaciones durante las pruebas

planificadas para el proyecto, estableciendo el siguiente procedimiento de clasificación y
atención:
9.3.1. Malfuncionamiento o errores
Ante la ocurrencia de malfuncionamientos o errores durante las pruebas a

desarrollar, estos deben clasificarse por su origen con relación directa a la
responsabilidad de atención:
a. Error generado en componentes construidas o modificadas por el proyecto.
La fase de construcción prevé el desarrollo de Pruebas Internas con la finalidad
de detectar cualquier malfuncionamiento y subsanarlo, aún así, si durante las
Pruebas EAPSA se detectase errores en la operación del producto, diferencias
del DATAMART de Operaciones respecto al diseño aprobado, la corrección
será de responsabilidad de XXX quien dará atención inmediata a las acciones
que correspondan.
b. Error originado por hardware, software base
Para la realización de la certificacióon, EAPSA, deberá proveer del hardware y
software base debidamente configurado y afinado a fin se pueda montar y
operar la solucióon construida y probar sin problemas. En caso de detectarse
problemas derivados de malfuncionamientos del hardware o software base
provisto, las pruebas serán suspendidas y EAPSA deberá subsanarlas en forma
inmediata. En caso el problema originado persista en un plazo mayor a 3 días,
las pruebas deberán ser replanificadas y acordadas por ambas partes.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
9.3.2. Observación de rendimiento (tiempo de respuesta)
Ante la observación de tiempos excesivos en la ejecución de procesos y/o tiempos

de respuesta, se determina su origen:
a. Originado por querys de acceso a base de datos, desarrollados por XXX.
Si se detectasen deficiencias en los tiempos de respuesta o procesamiento
producto de consultas (querys) poco óptimas, la subsanación será de
responsabilidad de XXX quien dará atención inmediata a las mejoras que
correspondan.
b. Originado por componentes desarrollados por XXX. Si durante las Pruebas
Internas o del Cliente se detectasen lentitud excesiva en los procesos
construidos por XXX, la corrección será de responsabilidad de XXX quien dará
atención inmediata a las acciones que correspondan.
En caso los componentes deficientes no sean provistos por XXX la subsanación
de deficiencias será de responsabilidad del Cliente.
c. Originado por hardware, servicio de comunicaciones o concurrencia.
EAPSA ha definido la arquitectura requerida para la operación del sistema. En
caso de detectarse deficiencias de rendimiento por hardware insuficiente,
servicios de comunicación inestables o de poca capacidad de transmisión,
conflictos de software, o problemas de concurrencia en base de datos, éstos
deberán ser resueltos en forma inmediata por eEAPSA de manera que no
entorpezca, retrase o impida la realización de las pruebas programadas. En
caso el problema originado persista en un plazo mayor a 3 días, las pruebas
deberán ser replanificadas y acordadas por ambas partes.
9.3.3. Observaciones a validaciones y/o consistencias
El proyecto prevé durante la fase de Anaálisis y Disenño la definición de reglas de

validación y consistencias de input para las funcionalidades a construir, condiciones
que serán incluidas en la documentacion entregada, siendo revisados y validados
por EAPSA. En caso durante las Pruebas de EAPSA se observe errores en
validaciones o consistencias definidas, o la operatividad de éestas difiera de las
especificaciones registradas en el documento funcional, la corrección será de
responsabilidad de XXX quien dará atención inmediata a las acciones que
correspondan.
En caso EAPSA defina nuevos definiciones o validación durante la fase de
transición, por la extemporaneidad en su definición, estas serán consideradas como
nuevos requerimientos de mejora, estando XXX exonerado de atenderlas, por tanto
no inhabilita ni condiciona la aprobacióon de las pruebas en curso.
9.3.4. Observaciones a vacíos funcionales y/o definiciones ambiguas
En caso el EAPSA durante la fase de transición observe malfuncionamientos

originados en vacíos en definiciones aprobadas, por la extemporaneidad de su
formulación, eéstos se considerarán como nuevos requerimientos de mejora,
estando XXX exonerado de atenderlas.
9.3.5. Observaciones de mejora
Refiere a especificaciones que complementan y mejoran las características del

Datamart, pero que no han sido definidas oportunamente ni consideradas en los
documentos de especificaciones funcionales y por tanto, corresponde a nuevos
requerimientos de mejora, de tratamiento o atención de responsabilidad de EAPSA.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Es importante precisar que estas observaciones no deben ser consideradas como

deficiencias de construcción o requerimiento pendiente de atención, siendo facultad
de XXX atenderlas o no, por tanto no inhabilita ni condiciona la aprobación de las
pruebas en curso.
9.4. Tratamiento a Observaciones
Las correcciones dependiendo del responsable de atención conforme a las definiciones de

los numerales precedentes, recibirá el siguiente tratamiento:
9.4.1. De responsabilidad XXX
XXX atenderá las observaciones en paralelo al desarrollo de las Pruebas de EAPSA

y con resultado verificable dentro del plazo programado para tal actividad. La nueva
versión del componente subsanado debe ser revisada por EAPSA para la
aprobación correspondiente.
9.4.2. De responsabilidad de EAPSA
Habiéndose establecido que estos errores u observaciones no son de

responsabilidad de XXX su ocurrencia no deben afectar la aprobación de las
pruebas en curso.
Adicionalmente, considerando que su atención es de responsabilidad de EAPSA y
que podría darse en oportunidad posterior a la conclusión del proyecto, el Informe de
Pruebas únicamente se limitará a registrar su ocurrencia con la observación de
“Atención de responsabilidad del Cliente”, no significando ningún servicio pendiente
de XXX, ni debiendo condicionar la aprobación de las pruebas ni al Acta de
Aceptación del Sistema.
9.5. Nuevos requerimientos del Proyecto.
Estos obedecen a requerimientos no contemplados en el alcance del proyecto o

definiciones formulados por EAPSA en forma extemporánea a la aprobación del alcance del
producto. Su atención es de estricta competencia de EAPSA, manteniéndose el proyecto al
margen de estos, y siendo la Gestión de Cambio el único procedimiento válido para su
incorporación al proyecto, y siendo facultad XXX aceptarlos o no, pudiendo reformular a
cambio los términos de atención del proyecto.
10. INFRAESTRUCTURA

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
10.1. Recursos Materiales que el Cliente

proporcionará
1. Coordinar lugares físicos para el equipo de XXX (sede Lima)
2. Requerimientos de 3 equipos informáticos con las siguientes características:

a. Procesador: INTEL CORE, Porcesador (3M cache, 1.80 GHz)
b. Memoria RAM:8.0 GB
c. Almacenamiento: 250GB
d. Sistema Operativo: Windows XP SP3 64 bits
3. Dar acceso al personal de XXX (3 recursos ) en los siguientes servicios, por un perido de 7
meses:
a. SVN
b. Servidor Wiki
c. JIRA
d. Base de datos Wari (branch desarrollo Datamart a
e. Correo interno
f. Perfil Internet de Sistemas
g. Teléfono
4. Implementar ambiente de base de datos de desarrollo Wari(actualización de base de datos)
5. Crearse cuentas de base de datos con el perfil de DEVELOPER_FACTORIES para el equipo

de XXX.
6. Implementar ambiente de desarrollo Datamart:

a. Instalar sistema operativo (Servidor DATAMART)
b. Instalar y configurar herramienta de BI
c. Creación de cuentas en ambientes (accesos)
7. Instalación de Datastage, Cognos, DB2…, en los ambientes de producción, desarrollo y pre-

producción, al iniciar a la construcción.
8. Compra de licencias
11. GESTIÓN DE RIESGOS
Los siguientes son los riesgos del proyecto inicialmente detectados y que deberán ser mitigados
durante la ejecución del mismo:

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
IDENTIFICACIÓN ANÁLISIS ESTRATEGIA DE RESPUESTA

Fecha Descripción del Hitos/Entregables Probabili Impact Impacto Exp al Tipo de Cuando de Responsabl Plan de
Registro Riesgo afectados dad % o (hh) (1 al 5) Riesgo Estrategia la Estrategia e del Riesgo Contingencia
Definir y publicar
en el plan del
trabajo, las fechas
Disponibilidad de programadas de
Documento de
los usuarios e MEDIA Franco participación de los
30/10/2013 Especificaciones 4 ALTA Mitigar 30/10/2013
involucrados 40.0% usuarios claves,
Funcionales
claves del proyecto así como el
compromiso de los
stakeholders
participantes.
Alta interacción en
la fase de análisis
con el Líder
Usuario y Líder TI a
Cambios en los
fin de minimizar la
requerimientos Plan de Dirección del BAJA Franco
30/10/2013 3 MEDIO Mitigar 30/10/2013 probabilidad de
iniciales del Proyecto 30.0%
que presente
usuario
controles de
cambio durante el
proceso de diseño
y construcción.
Inestabilidad de los
servidores de Base - Construcción ETL
ALTA
30/10/2013 de Datos, - Construcción 4 ALTA Aceptar 30/10/2013 Jose
80.0%
Datastage y/o Reportes
Cognos
Disponibilidad
oportuna de los
ambientes para - Certificación MEDIA
30/10/2013 4 ALTA Mitigar 30/10/2013 Jose
Pruebas del - Pase a Producción 60.0%
usuario o Puesta
en Producción
Transferencia de
Ausencia del Líder BAJA Responsable
30/10/2013 4 ALTA Aceptar 30/10/2013 información de
Usuario o Líder TI 20.0% del Proyecto
inmediato
Identificar
oportunamente en
la fase de
Alta desviación de elaboración el
tiempo en el impacto
ALTA
06/11/2013 proyecto por Fase Incepción 3 MEDIO Aceptar 06/11/2013 Viviana relacionado a
80%
actividades de posibles
limpieza de datos actividades de
limpieza de datos
que impacta al
proyecto.

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
Comunicar
oportunamente a
Incremento de toda la
control de cambios organización los
como módulos
consecuencia de considerarados en
Documento de Harry
requerimientos en el Datamart de
especificaciones ALTA Ceéspedes,
06/11/2013 paralelo que afecte 2 BAJO Mitigar 06/11/2013 Operaciones para
funcionales/ 80% Gabriel
la data y/o objetos Construcción que informen los
Bendezuú
de BD requerimientos
considerados en el relacionados e
alcance del Identificar los
proyecto proyectos que
tienen
interdependencia.
Los riegos deberán registrarse y monitorearse a través de un Tablero de Riesgos, que deberá ser
revisado durante la presentación del Informe de Seguimiento en los Comités Operativos. En caso un
riesgo de alto impacto, no pueda ser mitigado a pesar de las acciones preventivas desplegadas, los
Responsables del Proyecto podrán convocar un Comité Gerencial de urgencia con el propósito de
escalar el riesgo y el plan de acción.
12. GESTIÓON DE LA CONFIGURACIOÓN

El versionamiento de los entregables del proyecto se administraráa en el SVN. Y las versiones finales
de los entregables se cargaraán en la herramienta Sciforma.
13. PLAN DE CAPACITACIÓN
13.1. Alcance de la capacitación
El alcance de este plan está dado por el tipo de capacitación:

 Capacitación a Usuarios: Funcional (se desarrollaráa en paralelo a la certificación de
Sistemas y antes del inicio de las pruebas del usuario)
 Capacitación a Sistemas: Técnico (se desarrollaráa una transferencia de conocimiento
durante el desarrollo del proyecto)
La cantidad de sesiones de capacitación dependerá de la capacidad máxima que soporte la

infraestructura brindada por EAPSA, siendo la cantidad sugerida de una sesión (modificable
dependiendo de la cantidad de usuarios).
13.2. Actividades Previas a la Capacitación
Material de capacitación: XXX elaborará una demo de las funcionalidades de los reportes
del DATAMART de OPERACIONES necesarios para la capacitación.
Recursos: XXX coordinará los recursos necesarios para la presentación y/o taller de
capacitación.
Accesos a la solución de BI: Se utilizará el entorno de certificación para la capacitación.
La logística: EAPSA será responsable de proveer los recursos necesarios para la
capacitación según lo requerido y coordinado con XXX

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013
13.3. Grupo de Usuarios a capacitar
Lo define y convoca EAPSA. (De 10 a 15 usuarios funcionales a capacitar.)
13.4. Programación de Capacitación
Las fechas que se indiquen en el Cronograma del proyecto.
13.5. Ejecución de Capacitación
XXX utilizará la lista de asistencia remitida por EAPSA para tener la relación de los usuarios
que asistirán a la capacitación.
13.6. Después de Capacitación

No aplica
14. ANEXOS
Se presenta la relación de Artefactos de Gestión y Entregables del Proyecto que se adjuntan a la
presente.
Anexo1. Cronograma LB1

Plantilla - Plan de Direccion Del Proyecto

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

Plantilla - Plan de Direccion Del Proyecto

Cargado por

Copyright:

Formatos disponibles

PLAN DE DIRECCIÓN DE PROYECTO

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

HISTORIAL DE LAS REVISIONES

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 2 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 3 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

6.1. INFORME PERIÓDICO DE AVANCE.....................................................................................22

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 4 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

D. SISTEMA OPERATIVO: WINDOWS XP SP3 64 BITS...........................................................34

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 5 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

Con respecto a la seguridad de la herramienta, este considera usuarios, perfiles y acceso a

Para poder implementar el proyecto de manera adecuada, el desarrollo incluirá el uso de la

Gerente Sponsor: XXX

2. OBJETIVOS DEL PROYECTO

 Contar con información estadística consistente (tenencias, ganancia de capital, negociación,

3.1. Alcance del Producto.

o El DATAMART DE OPERACIONES a desarrollar considera los siguientes componentes:

a. Cinco (5) tablas de hechos:

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 6 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

b. Quince (13) dimensiones:

 Carga de Datos considerada desde el año 2003 en adelante.

 Tableros de Control - Se estiman 2 Tableros de Control

e. Métricas (ver diseño funcional)

f. KPI (Indicadores de Negocio) (ver diseño funcional)

3.2. Procesos del Negocio.

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 7 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

3 EAPSA brindaráa las condiciones laborales necesarias para el desarrollo del

17 XXX y EAPSA responderán las observaciones o consultas efectuadas por ambas

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 8 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

XXX se compromete que durante el desarrollo del proyecto efectuará la

3.4. Acotaciones del Proyecto.

El Proyecto no contempla las siguientes labores:

La presente propuesta ha sido elaborada en función a la documentación alcanzada por EAPSA.

3.5. Restricciones del Proyecto

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 9 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

4. PLAN DEL PROYECTO

4.1 Cronograma del Proyecto

<Incluir Cronograma Project>

El cronograma en detalle se presenta como anexo en el artefacto denominado “Proyecto Datamart

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 10 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

4.2 Documentos de Gestión

Documentos de Gestión Compartido

4.3 Entregables de Ingeniería

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 11 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

4.4 Proceso de aprobación de Entregables.

4.5 Actuación de los responsables del Proyecto

Por parte de EAPSA:

Nombres y Apellidos Rol EAPSA E-mail Teléfono

Rev.: 4.0 Fecha Efectiva: 22/11/2013 Pág. 12 de 37

7.3.2.02.R29 Versión: 1.0 Fecha: 14/08/2013

Por parte del Proveedor: XXX

Nombres y Apellidos Rol Proveedor E-mail Teléfono