Machine Translated by Google

Yamakawa, P., Rees, G., Quispe, J., Carrión, J., Luis, K. y Guevara, J. (marzo,2014). Pegaso Perú: un
proyecto retrasado (A). Revista de casos de enseñanza de tecnologías de la información (4) págs. [27­33]. (AR44732)

PEGASO PERÚ: UN PROYECTO RETARDADO (A)

Peter Yamakawa, Gareth H Rees, Julio Quispe, José Carrión, Kenny Luis y Julio Guevara.

Revista de casos de enseñanza de tecnología de la información (2014) 4, 27–33. doi:10.1057/jittc.2014.3;

publicado en línea el 11 de marzo de 2014

RESUMEN EJECUTIVO

Brunella Noli, Gerente General de una consultora peruana (Pegaso Perú) repasa la historia de una

Proyecto de TI con problemas para el cliente Casa Master Center (CMC). El proyecto tiene un retraso de 11 meses y CMC

es un cliente cada vez más descontento. La reseña de Noli, que comienza con la venta y relata la evolución del proyecto.

alcance, contrato e implementación, descubre una serie de problemas. Noli busca resolver estos problemas

sin incurrir en costes adicionales. Le preocupa que la relación con el cliente se esté deteriorando rápidamente y teme que

esto dañe la reputación de Pegaso.

Este caso está basado en hechos reales en organizaciones reales. Las identidades de las partes involucradas han

Se ha modificado, junto con otra información clave, para preservar el anonimato.

Palabras clave

Gestión de proyectos; proyecto de cierre; gestión de recursos humanos.

INTRODUCCIÓN

Muy temprano el lunes 22 de febrero de 2010, Brunella Noli, Gerente General de Pegaso Perú pensó

sobre el proyecto Casa Master Center (CMC), que había salido mal. Su directora de proyecto, Ana Pérez,

había dimitido recientemente. Noli, un experimentado ingeniero informático, había estado tentado a hacerse cargo de la

proyecto naufragando ella misma, sino que pidió al Gerente de Operaciones de Pegaso, Rafael León, que lo asumiera.

Ahora, preparándose para una reunión con León para revisar el plan de trabajo, Noli estaba revisando el proyecto

archivo. Tenía dos preocupaciones principales:

1) Noli necesitaba comprender qué había salido mal para poder salvar la relación con

CMC.

2) CMC le debía a Pegaso una cantidad sustancial: el pago final del proyecto retrasado.

Al 22 de febrero, sólo faltaba completar la fase de prueba. Sin embargo, al completar esta fase

requeriría la cooperación de un cliente que actualmente no coopera.

1
Machine Translated by Google

PEGASO Y PEGASO PERÚ

Pegaso, una empresa uruguaya de cuatro años de antigüedad, empleaba a 170 personas en cinco países (Uruguay, Argentina, Chile,

Perú y Estados Unidos). Una oficina de ventas en Sao Paulo, Brasil, cumplió su contrato exclusivo con una empresa multinacional.

Pegaso ofreció soluciones tecnológicas a SAP aprovechando la reputación de SAP

y aceptación en muchas industrias. Aproximadamente 500 empresas habían implementado la tecnología SAP

en América Latina, sin embargo, muchos productos SAP están subutilizados. Esto dejó un nicho para que Pegaso apuntara a empresas pequeñas.

y medianas empresas.

Pegaso se especializó en aplicaciones de Business Intelligence. La firma utilizó la herramienta Business Objects de SAP

desarrollar herramientas de planificación como paneles de control, cuadros de mando integrales e informes. La firma adapta SAP

Herramienta Business One para desarrollar aplicaciones de automatización, integración de procesos y gestión de

redes de distribuidores, concesionarios o filiales. Pegaso también construyó la Gestión de Relaciones con el Cliente

(CRM) soluciones y servicios CRM básicos para la gestión de campañas de marketing y contactos comerciales.

Brunella Noli había trabajado anteriormente como consultora con Arthur Andersen en Perú, incluido un período

en un proyecto de integración SAP con consultores de sistemas de Pegaso Uruguay. Seleccionado cuidadosamente para liderar

Pegaso Perú como Gerente General y con una participación accionaria como socio de Pegaso, Noli había creado el Perú

organización. Consideró esto como un logro importante en una carrera basada en una serie de éxitos.

proyectos. Como competente multitarea, asumió funciones operativas y de gobernanza, mientras que su

Su personalidad competitiva impulsó su ambición de convertir a Pegaso Perú en la empresa de TI nacional más grande del Perú.

negocio de consultoría.

Pegaso Perú ahora tenía 25 empleados a tiempo completo y había creado una lista considerable de subcontratistas aprobados.

El departamento de Operaciones estaba formado por Business Intelligence, CRM y Enterprise Resource.

Unidades de servicio de planificación (ERP). Administración y Finanzas supervisó Recursos Humanos, Contabilidad

y Finanzas, y el Departamento de Ventas era responsable de Ventas, Gestión de Recursos y

Marketing. El organigrama de Pegaso Perú se presenta en el ANEXO 1.

La base de clientes de Pegaso estaba formada por empresas de sectores como el comercio minorista, el suministro de gas, el transporte,

seguros y gobierno local (ver ANEXO 2). La mayoría de los proyectos duraron cuatro o cinco meses, pero

Pegaso había asumido y completado algunos proyectos más importantes y pretendía hacer más de estos lucrativos

proyectos. Pegaso cobraba entre 400 y 500 nuevos soles (entre 140 y 175 dólares estadounidenses) por día y por persona.

asignar consultores a medida que estuvieran disponibles y llenar los vacíos de experiencia de la lista de aprobados

contratistas. Varios consultores internos de alto nivel, que tenían mucha experiencia, comandaron

considerablemente más que la tasa de cargo promedio.

Pegaso recibió pedidos a través de referencias, reincorporación y licitaciones competitivas. consultores de ventas

se reunió con los clientes para conocer sus necesidades y luego describió cómo Pegaso podría implementar productos listos para usar o

soluciones personalizadas. Los ingenieros de sistemas y el personal de implementación aclararon el alcance del proyecto y

planificó e implementó los proyectos. Por lo general, el personal técnico llegaba después de una evaluación inicial.

se firmó el contrato. Los contratos de Pegaso se dividieron en dos partes. La primera parte especifica el tiempo necesario para alcanzar el alcance.

2
Machine Translated by Google

el trabajo que culminaría en un Business Blue Print (BBP) que incluiría un trabajo detallado

cronograma para la implementación. Se firmó un segundo contrato cuando el cliente estuvo de acuerdo con el cronograma de BBP y los hitos

clave. Los detalles clave del BBP de Pegaso Perú para CMC se encuentran en el ANEXO

3.

CENTRO CASA MAESTRO (CMC)

CMC era un minorista de materiales de construcción y mejoras para el hogar, cuyos procesos internos se convirtieron en

más complejo a medida que crecía. En particular, la elaboración de presupuestos requería mayor precisión, dado el gran número de

artículos que almacenaba en un número cada vez mayor de tiendas. Así, el proceso presupuestario de CMC se estaba volviendo

difícil de manejar e ineficiente, y sus proyecciones futuras a menudo eran poco confiables. Alta rotación entre los

personal administrativo (en quien CMC invirtió mucho tiempo y capacitación), significó que la mayoría de los

Los trabajadores responsables de preparar los presupuestos eran jóvenes e inexpertos.

Cada septiembre, los departamentos de CMC establecen sus presupuestos para el año siguiente. Se calcularon los presupuestos

basado en los resultados del año anterior, con proyecciones desarrolladas utilizando cálculos estadísticos de crecimiento. Cada

de las nueve tiendas de CMC y sus analistas de planificación del área de ventas (algunos de los cuales eran nuevos en el trabajo) utilizaron

Hojas de cálculo individuales de Excel para compilar registros históricos y generar proyecciones. las finanzas

El departamento compiló manualmente estos presupuestos departamentales en un documento presupuestario anual completo.

La empresa en rápido crecimiento necesitaba definitivamente una herramienta informática para agilizar este proceso.

En diciembre de 2008, CMC buscó cambiar sus procesos de planificación a tiempo para el presupuesto del próximo año.

redondo. La empresa ahora agrupó sus nueve tiendas por fecha de establecimiento: el grupo 1 estaba formado por tiendas

más de dos años, las tiendas del Grupo 2 tenían entre 1 y 2 años, y las tiendas del Grupo 3 eran aquellas con menos

más de un año en funcionamiento. Se creó una unidad de Planificación e Inteligencia Empresarial, encabezada por Janet

Sam. Esta unidad ahora era responsable del proceso de pronóstico y planificación comercial de CMC, incluyendo

establecimiento de objetivos de ventas, estimación de márgenes, facturación y proyecciones desagregadas en cada punto del

cadenas de valor de las tiendas. Sam dirigió y coordinó los procesos de planificación de gastos de los departamentos y

tiendas, y también fue responsable de diseñar e implementar el marketing anual de todas las categorías.

de bienes vendidos, análisis de importaciones y encuestas a clientes de la empresa. Janet Sam se convertiría así en

el punto clave de contacto entre CMC y Pegaso Perú. Relaciones claves en la organización de CMC

La estructura se presenta en el ANEXO 4.

BRUNELLA NOLI REVISA EL EXPEDIENTE DEL PROYECTO CMC

Brunella Noli volvió al expediente para leer las notas del departamento de ventas.

Ana Pérez, representante de la unidad de Ventas de Pegaso, había sido recomendada para el Área Comercial de CMC

Gerente, José Barrantes, a través de un amigo de la universidad. Pérez señaló que Barrantes había entendido la necesidad

para software de planificación y presupuestación, pero no sabía qué herramienta se adaptaría mejor a la nueva presupuestación

proceso que CMC planeaba instituir. Pérez recomendó las herramientas SAP modificadas de Pegaso. Su informe

Describió sucintamente las necesidades de CMC y su solución propuesta: SAP R/3 Business Integration &

Submódulo de Planificación (BIP) (ver ANEXO 5). Este software permitiría una planificación presupuestaria integrada

3
Machine Translated by Google

hasta cinco años por delante. La nota de Pérez también enfatizó por qué CMC era una nueva iniciativa potencialmente importante.

cliente de Pegaso. Al leer esto, Noli asintió. De hecho, CMC era justo el tipo de empresa a la que se dirigía Pegaso: pequeña hoy,

grande mañana (y con gran necesidad de los servicios de Pegaso) y el éxito con este cliente mejoraría enormemente su reputación

en la industria peruana de consultoría de TI.

Siguiendo leyendo, Noli vio que poco después de la reunión de contacto de ventas en diciembre de 2008, José Barrantes conoció

con el gerente de TI de CMC, Eddie Tortuga, para conocer sus puntos de vista sobre la implementación de BIP a la luz de las

Requisitos de TI actuales y futuros.

Este fue el primer proyecto SAP BIP de Pegaso Perú. De hecho, pocas empresas en Perú habían implementado BIP

para presupuestar. Algunas empresas multinacionales habían heredado este módulo de sus empresas matrices,

y unas pocas empresas nacionales habían contratado costosos consultores internacionales para implementar BIP. noli

se había sentido seguro sobre el proyecto porque el equipo incluiría un consultor senior experimentado,

Jorge Cubas, quien tenía amplia experiencia en aplicaciones presupuestarias en general y varios años de experiencia

Experiencia con SAP R/3. Cubas estaba muy ocupada con otros contratos de Pegaso en ese momento y estaba

por lo tanto no está disponible para las fases iniciales de este proyecto. Sacarlo del otro trabajo habría

comprometió su negocio en curso y, además, era uno de los consultores más caros que

Pegaso usado. Noli había decidido que en la fase inicial de planificación del trabajo, Cubas jugaría un papel

función de supervisión únicamente; mediante el cual revisaría el resultado del trabajo dejando el proyecto del día a día

gestión y recopilación de datos al director de proyecto asignado. Ella no sintió que esto

comprometer la calidad general y el progreso del proyecto. Noli programó a Cubas para sumarse al proyecto

tiempo completo al inicio de la fase de implementación del proyecto, y le pidió a Ana Pérez que liderara el proyecto.

Pérez había asumido el papel con entusiasmo. Proveniente de ventas, no tenía mucha experiencia en

SAP Business Intelligence Projects, pero había vendido las soluciones SAP de Pegaso. Noli se había sentido confiada

que Pérez ejecutaría el proyecto sin problemas.

Ahora Brunella Noli examinaba el contrato firmado en febrero de 2009. Poco podía hacer

hacer al respecto: lo que se firmó, se firmó. Como era habitual en Pegaso, la asesora de ventas (Ana

Pérez) había trabajado estrechamente con el cliente. Sin embargo, el contrato de CMC difería del habitual de Pegaso.

práctica, en el sentido de que su BBP incluía una disposición según la cual el trabajo se entregaría según fuera necesario, para una evaluación final.

Precio fijo. El contrato también contenía cláusulas estándar de penalización y de incumplimiento, que permitían

el cliente a retener los pagos y a que los costes de demora corran a cargo del responsable.

Ahora Noli pasó a los informes de seguimiento del proyecto. Mientras leía, sintió una sensación de inquietud; ella debería

les hemos prestado más atención cuando fueron presentados.

Como Cubas no estaba disponible, otra especialista de SAP, Priscilla Ugaz, se unió al equipo para realizar la

trabajo de alcance y registro de los requisitos del cliente. Este fue un ascenso significativo para Ugaz, quien

Anteriormente trabajó como pasante en un departamento diferente, con Jorge Cubas. Ugaz era nuevo en

presupuestación y planificación, pero se esperaba que Ugaz trajera algunos de los expertos especializados en SAP de Cuba.

4
Machine Translated by Google

conocimientos en las fases iniciales. Así, Ana Pérez y Priscilla Ugaz habían llevado a cabo la mayor parte del

trabajo de apertura.

CMC nombró a Janet Sam para liderar el proyecto de implementación del módulo SAP BIP. Tanto Janet Sam como José Barrantes

(el patrocinador del proyecto) consultaron con Eddie Tortuga sobre cuestiones de hardware.

Poco después de la firma del contrato, Ana Pérez y Priscilla Ugaz recorrieron las instalaciones de CMC, recogiendo

la información requerida para, en el lenguaje de SAP, “construir” el BBP. El BBP detalló todo el trabajo a realizar

realizado, en base a los requerimientos del cliente que Ugaz recopiló. Ugaz no estaba familiarizado con algunos de

la terminología necesaria y no sabía cómo confirmar los requisitos del cliente. Ella tampoco preguntó

muchas preguntas adicionales y, por lo tanto, produjo documentación incorrecta o incompleta. Este

La fase de definición de requisitos le había tomado dos meses, pero el plan del proyecto especificaba que este paso debería

se han completado en un mes. En abril de 2009, el proyecto ya había caído un 15%. noli

Se preguntó por qué no se había dado cuenta de este hecho importante cuando revisó por primera vez los informes de progreso.

Ahora, Noli advirtió que Jorge Cubas había rechazado el BBP de Ugaz, diciendo que las proyecciones de datos eran

No es lo que había esperado. Siguiendo leyendo, Noli supuso que Priscilla Ugaz había reelaborado todo el BBP,

no sólo debían abordarse los puntos críticos que Cubas indicó. El nuevo documento tardó tres

¡Más meses para completar! En julio de 2009, los datos ya estaban compilados como Cuba quería, pero el

El proyecto había avanzado ya en el tiempo reservado para su ejecución.

Curiosamente, el informe no reveló ningún indicio de que CMC se hubiera quejado alguna vez. Noli se preguntó por qué.

ya que el contrato especificaba plazos firmes. En cambio, transcurridos seis meses, José Barrantes

recibió y aprobó el BBP en nombre de CMC, aparentemente sin quejas sobre el proyecto

sobrepasado, a pesar de que se suponía que el trabajo estaría terminado en agosto de 2009.

A continuación, Noli revisó rápidamente los informes de seguimiento de la implementación para verificar los períodos de ejecución del proyecto.

suspensión. Normalmente, Noli sólo aprobaría la suspensión de un proyecto si determina que el cliente

no pudieron cumplir con sus compromisos. Sin embargo, el proyecto CMC había sido suspendido varias veces.

En octubre de 2009, durante la fase final de implementación, Ana Pérez solicitó la baja por maternidad. noli

nombró un gerente de proyecto temporal para reemplazar a Pérez durante su licencia. el nuevo proyecto

Se instó al gerente a mantener el proyecto en marcha para cumplir con la nueva fecha estimada de finalización de

diciembre de 2009. Sin embargo, para su decepción, Brunella Noli tuvo que aprobar un proyecto

suspensión menos de dos meses después, cuando CMC notificó que varios miembros del personal serían

de vacaciones desde mediados de diciembre de 2009 hasta bien entrado enero de 2010. Entre los vacacionistas se encontraba Janet

Sam y Eddie Tortuga. Ahora, leyendo las notas, Noli recordó que había creído que poco progreso

podría hacerse si los líderes del proyecto de CMC no estuvieran allí para apoyarlo en persona. Ella suspendió el

proyecto hasta marzo de 2010.

Ahora era el 22 de febrero de 2010. En las últimas semanas, las cosas realmente habían comenzado a desmoronarse. A principios de febrero,

Ana Pérez regresó de su baja por maternidad, pero poco después presentó su dimisión. Con una vista de

cerrar el proyecto lo más rápido posible, Noli nombró a Rafael León, especialista en operaciones, para que se hiciera cargo

5
Machine Translated by Google

encima. Noli le explicó a un colega: “Como Gerente de Operaciones de Pegaso, León tiene la autoridad

cerrar el proyecto”.

Pronto, León informó que CMC había solicitado nuevas capacidades de generación de informes, que Pegaso no había planeado.

Desafortunadamente, el contrato había especificado que CMC podía solicitar tales mejoras y

que Pegaso Perú haría el trabajo sin costo extra. Después de evaluar estas solicitudes y evaluar

el tiempo necesario para su finalización, León le pidió a Noli que agregara más recursos al proyecto antes de que

reanudado. Se llegó a un acuerdo con CMC para que junio de 2010 sería la finalización del nuevo proyecto.

fecha (once meses después de la fecha límite original de agosto de 2009).

¿Cómo fue que el contrato le dio tanto poder al cliente? Pensándolo bien, Brunella Noli ahora

entendió que, si bien Priscilla Ugaz había creído que la mayor parte del trabajo sobre el desarrollo de informes

y la finalización se había detallado en el BBP, había incertidumbre con respecto al resultado general del cliente.

necesidades de informes. Por lo tanto, las especificaciones finales para la función de informe se pospusieron deliberadamente hasta el

Se podría conocer el número real de informes. Noli había hablado de este tema con Ana Pérez y habían

acordó permitir la disposición en el BBP que autorizaba a CMC a solicitar informes adicionales durante el

fase de implementación del proyecto. Esta cláusula fue ahora el detonante de las solicitudes de nuevos informes. CMC tenía

tuvo mucho tiempo para considerar sus necesidades de presentación de informes, ya que el proyecto había durado casi un año más de

planificado. Quizás con el tiempo, las expectativas de CMC para el sistema habían crecido más allá de lo que inicialmente

previsto en el BBP.

Un golpe en la puerta hizo que Noli levantara la vista; Era Rafael León. Fue directo al grano, afirmando que

él y otros miembros del equipo de implementación sospechaban que CMC estaba tratando de aprovechar más la

contrato que el previsto y acordado informalmente entre Ana Pérez y José Barrantes. Allá

No se había realizado una evaluación previa del tiempo y los recursos necesarios para ninguno de los informes adicionales.

sean solicitados. León añadió un comentario alarmante:

“Si siguen pidiendo nuevos informes, nunca terminaremos el proyecto. ¿Cómo les decimos eso?

¿No aceptaremos requisitos que no se comprometieron originalmente en el BBP?”

La respuesta de Brunella Noli a León fue brusca:

“Para terminar depende de cuántas personas más asignemos. Pero CMC no está obligada a pagar

más, porque estamos muy por encima del cronograma. ¡Debemos cerrar esto lo antes posible!

6
Machine Translated by Google

EXHIBICIÓN 1

Organigrama de Pegaso Perú

Administración General

Brunella Noli
1

yo
1

Jefe de operaciones Administración y Gestión de ventas

Gestión financiera
rafael leon Clotilde Matos Arturo Guinea

1 1 1

Inteligencia de Negocios
Ana Pérez­ Recursos humanos Ventas

(anteriormente en Ventas)

CRM Responsabilidad CRM

ERP Finanzas _ Marketing

7
Machine Translated by Google

ANEXO 2

Resumen de la cartera de clientes de Pegaso Perú

Pegaso Perú factura aproximadamente $US 1 millón al año, compuesto por grandes y pequeños proyectos en todo

una gama de industrias. El proyecto Casa Master Center (CMC) fue considerado grande para los estándares de

Pegaso Perú. La Tabla E2.1 proporciona datos de un gran proyecto típico para cada sector, en comparación con el

Proyecto CMC.

Cuadro E2.1 Grandes proyectos de Pegaso Perú por sector

Industria Plazo medio Valor ($US) Personal Asignado

Minorista 18 semanas $ 52, 500 5

Gas de petróleo 14 semanas $ 60.000 5

Productos cosméticos 15 semanas $ 50.000 3

Seguro 18 semanas $ 56.000 4

Casa Maestro Centro 18 semanas $ 42.000 4

CMC fue considerado un proyecto grande y fue importante porque;

• Era un cliente nuevo y potencialmente grande,

• El módulo SAP (Planificación y Consolidación de Negocios) no se solicita con frecuencia,

• El éxito de este proyecto daría prestigio a la industria de Pegaso Perú.

El plazo para este tipo de proyecto es generalmente de 3 a 4 meses y los clientes suelen solicitar

adiciones al rendimiento y la funcionalidad después de la instalación inicial y la experiencia del usuario.

8
Machine Translated by Google
ANEXO 3
Cláusulas clave del Business Blueprint (BBP) de Pegaso Perú / Casa Master Center (CMC)
RESUMEN EJECUTIVO
La fase/diseño del plan de negocio es un estudio de los requisitos descritos en el alcance
y el documento de declaración del proyecto. Su propósito es crear un modelo de análisis,
procesos de conversión, un esquema de extracción y carga de datos requeridos, un
diseño de un modelo conceptual que respalde las necesidades de información
comercial de Marketing y Operaciones y analice las necesidades de informes con
paneles de funcionalidad. utilizando el software SAP Business Objects.
Para la elaboración de este documento se realizaron sesiones con los
patrocinadores y usuarios del proyecto, seleccionados de las áreas clave de Marketing,
Operaciones y Finanzas. Estas sesiones tuvieron como objetivos:
• Asistir en cuestiones relativas a los procesos de cada módulo y la organización general
para obtener una visión integral de CMC y sus requerimientos de información y
establecer un modelo integral. • Conocer de los patrocinadores del
proyecto y de los usuarios
la información sobre los requisitos y procesos involucrados.
• Desarrollar un modelo de definición de datos de las necesidades de información para
los usuarios de cada módulo.
• Ayudar a identificar los detalles funcionales y casos de negocio de cada módulo.
La aprobación de este documento indica el inicio de la fase de construcción del
proyecto. Esta fase consistirá en la implementación de la plataforma, la implementación
del modelo que cumpla con los requerimientos de información y todos los
procesos de carga de datos.
Sin embargo, al final de este documento se incluyen una serie de informes y tablas de
datos adicionales que pueden definirse en la tercera parte de la fase de Construcción
cuando se puedan determinar necesidades más precisas.
Estos informes y definiciones de tablas están cubiertos por la información contenida
en este documento.
PLAZOS Y REQUISITOS INICIALES
Para continuar, el proyecto SAP Business Objects BI requiere:
1. Acceso a la Red CASA MASTER CENTER (CMC).
2. Disponibilidad del conocimiento funcional del negocio de CMC para validar el modelo
conceptual, las decisiones de diseño funcional y abordar preguntas específicas que
puedan surgir durante la etapa de construcción.
3. Disponibilidad y acceso a la plataforma tecnológica CMC, servidores de
bases de datos para repositorios y servidores de aplicaciones comerciales
provisionales de Data Mart y herramientas de Business Objects, servicios de datos de
SAP y plataforma de BI de SAP Business Objects.
Abril de 2009: Recursos técnicos de CMC y conocimiento avanzado de las fuentes de
datos necesarios para la validación del modelo de datos en Commercial Data Mart.
También se requieren poderes de toma de decisiones para abordar cuestiones específicas
que puedan surgir durante la etapa de construcción.
Mayo de 2009: Disponibilidad y acceso a los recursos técnicos y funcionales
de CMC para pruebas integrales de la solución. Esto requiere la participación de
usuarios de dos funciones a tiempo completo para la validación de informes,
paneles de control para confirmar la exactitud de la información y un recurso
técnico a tiempo completo para una revisión de los procesos ETL y los tiempos de
ejecución de consultas.
PAGOS
Se pagará el 25% del precio tras la aceptación de este BBP por parte de CMC.
El 75% del precio se pagará al completar todos los hitos clave y la implementación
completa de la solución del proyecto.
9
INFORME EXCLUSIONES Y CONTINGENCIA
El alcance detallado del proyecto se encuentra en el Anexo 1 ­ Declaración de alcance
de CASA MASTER CENTER (CMC). Este documento había sido revisado y
aprobado por CMC y Pegaso.
Sin embargo, aquellos problemas específicos para los cuales no se han identificado
datos de origen dentro de los sistemas transaccionales no se incluirán en los procesos
comerciales y ahora quedarán fuera de los objetivos del proyecto.
Al alcance funcional del proyecto se suma el desarrollo de 15 informes de Web
Intelligence y 2 Dashboards de SAP Business Objects. Para revisar los detalles de los
informes y paneles solicitados, consulte los archivos adjuntos en el "Apéndice 4 ­
Definición de informes y paneles". Importante: Hasta la fecha, CMC solo
pudo definir 10 informes y 1 tabla de datos: Otros informes y tablas de datos previstos
en las últimas partes de este documento deben definirse y enviarse a Pegaso en la
tercera parte de la fase de Construcción.
HITOS CLAVE Y RESPONSABILIDADES
1. CMC deberá entregar a los consultores de Pegaso los informes que contengan
indicadores básicos actualmente vigentes (ventas, objetivos e inventario) con el
mínimo nivel de detalle para el proceso de carga de datos, su validación y
definición de informes. Esta información debe enviarse a más tardar el 20 de
abril de 2009. La fuente de datos que permite la replicación de estos informes
debe estar contenida en el repositorio para que el equipo de Pegaso pueda
cargar la solución de BI.
2. CMC debe proporcionar un conjunto de datos razonable (tres meses para todos
store) en el entorno Staging cuando comienzan las tareas de desarrollo de
aplicaciones (5 de mayo de 2009) para realizar pruebas y Pegaso puede validar la
calidad de los procesos de carga.
3. CMC debe proporcionar a Pegaso el guión de prueba completo a más tardar.
del 2 de junio de 2009.
Abril: CMC y Pegasus apoyaron el esquema que debe definir la seguridad del
usuario antes del 16 de mayo de 2009.
Mayo: la solución de documentación técnica se crea utilizando herramientas estándar de
SAP Business Objects. Pegaso es responsable de presentar esta documentación
el 9 de marzo de 2012.
RESTRICCIONES y RIESGOS
Las RESTRICCIONES son factores que el equipo del proyecto no tiene autoridad para
cambiar y, si no se planifican ni se incluyen en el cronograma, pueden afectar
gravemente el éxito del proyecto:
• Cambio de estructura de los Sistemas de Recursos.
• Cambios en la plataforma tecnológica. • Rotación
del personal de CMC en las actividades del proyecto. •
Disponibilidad de personal del CMC. •
Rotación de personal en Pegaso •
Disponibilidad de personal de Pegaso
Los RIESGOS son factores que pueden tener un impacto negativo en el proyecto.
• Incapacidad de tener acceso a los sistemas CMC. • No
tener la plataforma tecnológica disponible cuando sea necesaria. • Incapacidad para
coordinar reuniones con usuarios funcionales, lo que retrasaría el proyecto.
• Plazos de aprobación del CMC para detener el inicio de alguna etapa. • Las fuentes de
datos no están disponibles.
• Imposibilidad de contar con usuarios técnicos con conocimientos avanzados del
fuentes de datos involucradas
Machine Translated by Google

ANEXO 4

Organigrama de Casa Master Center

CEO

Finanzas / Administración Adquisitivo Gerente comercial

José Barrantes

Planificación y Negocios
Unidad de Inteligencia
Janet Sam

ÉL
Eddie Tortuga

Gerentes de tienda

10
Machine Translated by Google

ANEXO 5

Conceptos básicos de los módulos R/3 de SAP

SAP AG inició sus operaciones en 1972 y alcanzó el éxito en la década de 1980 con su solución SAP R/2 Enterprise Planning. El nombre
de la empresa, SAP, significa Sistemas, Aplicaciones y Productos en Procesamiento de Datos.

A mediados de la década de 1990, SAP tenía dos productos principales en el mercado de software empresarial: el sistema mainframe R/
2 y el cliente/servidor R/3 (la "R" era para "procesamiento de datos en tiempo real" y la 3 era para software de 3 niveles). ). Esta nueva
arquitectura es compatible con múltiples plataformas y sistemas operativos, como Microsoft Windows o
UNIX. SAP R/3 se lanzó oficialmente el 6 de julio de 1992 y la versión 3.1 se convirtió en el primer software ERP habilitado para Internet
de la empresa en el mercado.

El software Enterprise Resource Planner (comúnmente conocido como ERP) es un concepto que comenzó en la década de 1970 y
estaba destinado a proporcionar soluciones computarizadas para integrar y automatizar procesos comerciales en las oficinas
administrativas de las empresas, como los departamentos financieros, de logística o de recursos humanos. Para SAP un proceso de
negocio es la cadena funcional completa involucrada en las prácticas comerciales, sea cual sea el módulo, aplicación, sistema o servicio
web que tenga que lidiar con él. Esto significa, específicamente para SAP R/3
sistemas, que la cadena de proceso podría ejecutarse a través de diferentes módulos.

SAP R/3 está organizado en distintos módulos funcionales, que cubren las funciones típicas implementadas en una organización. Los
módulos más utilizados fueron Finanzas y Control, Recursos Humanos, Gestión de Materiales, Ventas y Distribución y Planificación de
la Producción. Cada módulo maneja tareas comerciales específicas por sí solo, pero está vinculado a los demás cuando corresponde.
Como R/3 opera en tiempo real, cuando se realizan nuevas entradas en el sistema, los enlaces de aplicaciones lógicas actualizarán
simultáneamente los módulos relacionados para que la empresa pueda reaccionar a la información y los cambios inmediatos. Este tipo
de actualización reduce la
La sobrecarga del procesamiento y la comunicación manual y permite a las empresas reaccionar rápidamente, lo que hace que el
software SAP R/3 y las soluciones SAP Business Intelligence sean herramientas muy valiosas para la planificación ejecutiva y la toma
de decisiones.

Hacia finales de la década de 1990, SAP estaba desarrollando módulos adicionales y algunas de las funcionalidades solicitadas para
estos módulos eran comunes a diferentes sectores industriales. Así, SAP introdujo una gama de módulos organizados por unidades de
negocio, uno de los cuales fue SAP Business Intelligence (BI), que incluye SAP Business Information Warehouse y SAP Knowledge
Warehouse, una solución que captura, combina y organiza datos de una variedad de módulos internos. y fuentes externas y lo pone a
disposición de los procesos de toma de decisiones.

En 2004, SAP había reposicionado su estrategia de productos y sus soluciones, con el módulo SAP R/3 como base.
una cartera más amplia de soluciones integradas basadas en web que incluye SAP Business Suite, un nombre común que ahora se
utiliza para las soluciones SAP R/3 en todas las empresas. Consulte la Figura 1 para ver la cartera de productos SAP 2002.

Fig. 1 Portafolio de productos SAP 2002.

FUENTE: Hernández, JA, Keogh, J. y Martínez, F. (2006). Manual de SAP R/3, 3ª ed. Nueva York:
McGraw­Hill.

11