Pegaso Perú: un proyecto atrasado (A) y B)

Abstracto
Brunella Noli, gerente general de una firma consultora peruana (Pegaso
Perú), revisa la historia de un proyecto de TI con problemas para el cliente
Casa Master Center (CMC). El proyecto tiene 11 meses de retraso y CMC es
un cliente cada vez más infeliz. La revisión de Noli, que comienza con la
venta y relata el alcance, el contrato y la implementación del proyecto,
revela una serie de problemas. Noli busca resolver estos problemas sin
incurrir en costos adicionales. Le preocupa que la relación con el cliente se
deteriore rápidamente y teme que esto pueda dañar la reputación de
Pegaso. Un segundo caso B de una página relata lo que sucedió a
continuación. Este caso se basa en eventos reales en organizaciones reales.
Las identidades de las partes involucradas se han cambiado, junto con otra
información clave, para preservar el anonimato.
Introducción
Muy temprano el lunes 22 de febrero de 2010, Brunella Noli, Gerente
General de Pegaso Perú, pensó en el proyecto Casa Master Center (CMC),
que había ido mal. Su gerente de proyecto, Ana Pérez, había renunciado
recientemente. Noli, una experimentada ingeniera informática, había
tenido la tentación de hacerse cargo del proyecto fallido ella misma, pero
en cambio le pidió al Gerente de Operaciones de Pegaso, Rafael León, que
lo asumiera. Ahora, en preparación para una reunión con León para revisar
el plan de trabajo, Noli estaba revisando el archivo del proyecto. Ella tenía
dos preocupaciones principales:
(1) Noli necesitaba entender qué había salido mal para poder salvar la
relación con CMC.
(2) CMC adeudaba a Pegaso una cantidad sustancial: pago final del proyecto
retrasado.
A partir del 22 de febrero, solo la fase de prueba debía completarse. Sin
embargo, completar esta fase requeriría la cooperación de un cliente que
actualmente no coopera.
Pegaso y Pegaso Perú
Pegaso, una compañía uruguaya de 4 años, empleaba a 170 personas en
cinco países (Uruguay, Argentina, Chile, Perú y Estados Unidos). Una oficina
de ventas en Sao Paulo, Brasil, atendió su contrato exclusivo con una
compañía multinacional. Pegaso ofreció soluciones de tecnología SAP,
aprovechando la reputación y aceptación de SAP en muchas industrias.
Aproximadamente 500 empresas implementaron la tecnología SAP en
Latinoamérica, pero muchos productos SAP infrautilizados. Esto dejó un
nicho para Pegaso para apuntar a pequeñas y medianas empresas.
Pegaso se especializó en aplicaciones de Business Intelligence (BI). La
empresa utilizó la herramienta Business Objects de SAP para desarrollar
herramientas de planificación, como tableros, cuadros de mando e
informes. La empresa adapta la herramienta Business One de SAP para
desarrollar aplicaciones de automatización, integración de procesos y
gestión de redes de distribuidores, distribuidores o filiales. Pegaso también
creó soluciones de gestión de relaciones con los clientes (CRM) y servicios
básicos de CRM para gestionar campañas de marketing y contactos de
ventas.
Brunella Noli había trabajado anteriormente como consultora con Arthur
Andersen en Perú, incluyendo un hechizo en un proyecto de integración de
SAP con consultores de sistemas de Pegaso Uruguay. Seleccionado para
liderar a Pegaso Perú como su Gerente General y tener una participación
como socio en Pegaso, Noli había establecido la organización en Perú. Ella
consideró esto como un gran logro en una carrera basada en una serie de
proyectos exitosos. Como una multitarea competente, asumió roles
operativos y de gobierno, mientras que su personalidad competitiva
impulsó su ambición de desarrollar Pegaso Perú en el mayor negocio
interno de consultoría de TI de Perú.
Pegaso Perú ahora tenía 25 empleados a tiempo completo y había creado
una lista considerable de subcontratistas aprobados. El Departamento de
Operaciones constaba de unidades de servicio de BI, CRM y planificación de
recursos empresariales (ERP). Administración y Finanzas supervisó
Recursos Humanos, Contabilidad y Finanzas, y el Departamento de Ventas
se encargó de Ventas, Gestión de recursos y Marketing. El organigrama de
Pegaso Perú se presenta en la Figura 1.
La base de clientes de Pegaso consistió en firmas en industrias tales como
comercio minorista, suministro de gas, transporte, seguros y gobierno local
(consulte el Apéndice A). La mayoría de los proyectos duraron 4 o 5 meses,
pero Pegaso había asumido y completado algunos proyectos más grandes,
y tenía como objetivo hacer más de estos proyectos lucrativos. Pegaso
cobró alrededor de 400-500 nuevos soles (US $ 140-175) por día por
persona, asignando consultores mientras estaban disponibles y llenando
vacíos de experiencia de la lista de contratistas aprobados. Varios
consultores internos de alto nivel, que tenían mucha experiencia,
comandaban considerablemente más que la tasa de carga promedio.
Pegaso recibió pedidos a través de referencias, reingreso y licitación
competitiva. Los consultores de ventas se reunieron con los clientes para
conocer sus necesidades, y luego describieron cómo Pegaso podría
implementar soluciones personalizadas o listas para usar. Los ingenieros del
sistema y el personal de implementación aclararon el alcance del proyecto
y planificaron e implementaron los proyectos. Por lo general, los técnicos
fueron traídos después de que se firmó un contrato inicial. Los contratos de
Pegaso se dividieron en dos partes. La primera parte especificó el tiempo
necesario para determinar el alcance del trabajo que culminaría en un
Business Blue Print plan de negocios (BBP) que incluiría un programa de
trabajo detallado 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 Pegaso Perú BBP para CMC se encuentran en el
Apéndice B.
Casa Master Center (CMC)
CMC era un minorista de materiales de construcción y mejoras para el
hogar, cuyos procesos internos se volvieron más complejos a medida que
crecía. La presupuestación, en particular, requería una mayor precisión,
dada la gran cantidad de artículos que almacenaba en un número creciente
de tiendas. Por lo tanto, el proceso de presupuestación de CMC se estaba
volviendo difícil de manejar e ineficiente, y sus proyecciones hacia adelante
a menudo no eran confiables. La alta rotación entre el personal
administrativo (en quien CMC invirtió mucho tiempo y capacitación) indica
que la mayoría de los trabajadores responsables de preparar los
presupuestos eran jóvenes e inexpertos.
Cada septiembre, los departamentos de CMC establecen sus presupuestos
para el próximo año. Los presupuestos se calcularon sobre la base de los
resultados del año anterior, con proyecciones desarrolladas usando
cálculos estadísticos de crecimiento. Cada una 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) usaban hojas de cálculo individuales de Excel
para compilar registros históricos y generar proyecciones. El departamento
de finanzas compiló manualmente estos presupuestos departamentales en
un documento de presupuesto anual completo. La empresa en rápido
crecimiento definitivamente necesitaba una herramienta informática para
simplificar este proceso.
En diciembre de 2008, CMC buscó cambiar sus procesos de planificación a
tiempo para la ronda presupuestaria del próximo año. La compañía ahora
agrupaba sus nueve tiendas por fecha de establecimiento: el Grupo 1
consistía en tiendas de más de 2 años, las tiendas del Grupo 2 tenían de 1 a
2 años y las tiendas del Grupo 3 eran aquellas con menos de un año de
funcionamiento. Se estableció una unidad de Planificación e Inteligencia
Comercial, encabezada por Janet Sam. Esta unidad ahora era responsable
del proceso de previsión y la planificación comercial de CMC, incluidos el
establecimiento de objetivos de ventas, la estimación de márgenes, la
facturación y las proyecciones desglosadas en cada punto de las cadenas de
valor de las tiendas. Sam dirigió y coordinó los procesos de planificación de
gastos de departamentos y tiendas, y también fue responsable de diseñar
e implementar la comercialización anual de todas las categorías de
productos vendidos, análisis de importación y encuestas de clientes para la
empresa. Janet Sam se convertiría así en el punto de contacto clave entre
CMC y Pegaso Perú. Las relaciones clave en la estructura organizacional de
CMC se presentan en la Figura 2.

Brunella Noli revisa el archivo del proyecto CMC

Brunella Noli regresó al archivo para leer las notas del Departamento de
Ventas.
Ana Pérez, representante de la unidad de ventas de Pegaso, había sido
recomendada al gerente comercial de CMC, José Barrantes, a través de un
amigo de la universidad. Pérez señaló que Barrantes había entendido la
necesidad de un software de planificación y presupuestación, pero no sabía
qué herramienta sería más adecuada para el nuevo proceso de
presupuestación que CMC planeaba instituir. Pérez recomendó las
herramientas SAP modificadas de Pegaso. Su informe resumió
sucintamente las necesidades de CMC y su solución propuesta: el
submódulo SAP R/3 Business Integration & Planning (BIP) (ver Apéndice C).
Este software permitiría una planificación presupuestaria integrada hasta
por 5 años más. La nota de Pérez también enfatizaba por qué CMC era un
nuevo cliente potencialmente importante para Pegaso. Leyendo esto, Noli
asintió. De hecho, CMC era simplemente el tipo de empresa al que
apuntaba Pegaso: pequeño 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.
Al leer, Noli vio que poco después de la reunión de contacto de ventas en
diciembre de 2008, José Barrantes se reunió con el gerente de TI de CMC,
Eddie Tortuga, para conocer su opinión sobre la implementación de BIP a la
luz de los requisitos de TI actuales y futuros de CMC.
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 algunas compañías nacionales habían contratado a consultores
internacionales caros para implementar BIP. Noli se había sentido confiado
sobre el proyecto porque el equipo incluiría un experimentado consultor
senior, Jorge Cubas, que tenía una amplia experiencia en aplicaciones
presupuestarias en general y varios años de experiencia con SAP R/3. Cubas
estaba extremadamente ocupado en otros contratos de Pegaso en ese
momento, y por lo tanto no estaba disponible para las fases iniciales de este
proyecto. Sacarlo del otro trabajo habría comprometido sus negocios en
curso, y además era uno de los consultores más caros que usaba Pegaso.
Noli había decidido que, en la primera fase de planificación del trabajo,
Cubas desempeñaría un rol de supervisión, por el cual revisaría la salida del
trabajo dejando la administración del proyecto y la recopilación de datos
diarias al gerente de proyecto asignado. Ella no creía que esto pudiera
comprometer la calidad general y el progreso del proyecto. Noli programó
a Cubas para unirse al proyecto a tiempo completo al inicio de la fase de
implementación del proyecto, y le pidió a Ana Pérez que lidere el proyecto.
Pérez asumió el papel con entusiasmo. Procedente de las ventas, no tenía
mucha experiencia en proyectos SAP BI, pero había vendido las soluciones
SAP de Pegaso. Noli confiaba en que Pérez dirigiría el proyecto sin
problemas.
Ahora Brunella Noli miró el contrato que se firmó en febrero de 2009. Poco
podía hacer al respecto, lo que se firmó se firmó. Como era típico de Pegaso,
la consultora de ventas (Ana Pérez) había trabajado estrechamente con el
cliente. Sin embargo, el contrato de CMC difería de la práctica habitual de
Pegaso, 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, por un precio fijo final. El
contrato también contenía cláusulas estándar de penalización e
incumplimiento, lo que permite al cliente retener los pagos y los costos de
demora a cargo de la parte responsable.
Ahora Noli recurrió a los informes de monitoreo del proyecto. Mientras leía,
sintió una sensación de inquietud; debería haberlos tomado más en cuenta
cuando se presentaron.
Como Cubas no estaba disponible, otra especialista en SAP, Priscilla Ugaz,
se unió al equipo para llevar a cabo el trabajo de alcance y el registro de los
requisitos del cliente. Esta fue una promoción importante para Ugaz, quien
anteriormente trabajó como pasante en un departamento diferente, con
Jorge Cubas. Ugaz era nuevo en el presupuesto y la planificación, pero se
esperaba que Ugaz trajera parte del conocimiento especializado de SAP de
Cuba a las fases iniciales. Por lo tanto, Ana Pérez y Priscilla Ugaz habían
llevado a cabo la mayor parte del trabajo de apertura.
CMC designó a Janet Sam para dirigir 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 asuntos de hardware.
Poco después de la firma del contrato, Ana Pérez y Priscilla Ugaz recorrió
las instalaciones de CMC, recopilando la información requerida para, en el
lenguaje SAP, 'compilar' el BBP. El BBP detalló todo el trabajo a realizar, de
acuerdo con los requisitos del cliente que Ugaz reunió. Ugaz no estaba
familiarizado con la terminología necesaria y no sabía cómo confirmar los
requisitos del cliente. Tampoco hizo muchas preguntas adicionales y, por lo
tanto, produjo cierta documentación incorrecta o incompleta. La fase de
definición de estos requisitos le había llevado 2 meses, pero el plan del
proyecto especificó que este paso debería haberse completado en 1 mes.
En abril de 2009, el proyecto ya había caído un 15%. Noli se preguntó por
qué no había notado este hecho importante cuando revisó por primera vez
los informes de progreso.
Ahora, Noli notó que Jorge Cubas había rechazado el BBP de Ugaz, diciendo
que las proyecciones de datos no eran lo que él había esperado.
Continuando con la lectura, Noli supuso que Priscilla Ugaz había
reelaborado todo el BBP, no solo los puntos críticos que Cubas indicó que
era necesario abordar. El documento nuevo tardó 3 meses más en
completarse. Para julio de 2009, los datos ahora se compilaban como Cubas
lo quería, pero el proyecto se había movido bastante dentro del tiempo
reservado para la implementación.
Curiosamente, el informe no reveló ninguna indicación de que CMC alguna
vez se haya quejado. Noli se preguntó por qué, ya que el contrato
especificaba plazos firmes. En cambio, después de 6 meses, José Barrantes
recibió y aprobó el BBP en nombre de CMC, aparentemente sin quejas
sobre el exceso de proyectos, aunque se suponía que el trabajo estaría
terminado en agosto de 2009.
Luego, Noli revisó rápidamente los informes de monitoreo de
implementación para verificar los períodos de suspensión del proyecto.
Normalmente, Noli solo aprobaría una suspensión del proyecto si
determinara que el cliente no podría cumplir con sus compromisos. Sin
embargo, el proyecto de CMC había sido suspendido varias veces.
En octubre de 2009, durante la fase final de implementación, Ana Pérez
solicitó licencia de maternidad. Noli nombró a un gerente de proyecto
temporal para hacerse cargo de Pérez durante su licencia. Se instó al nuevo
gerente de proyecto 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 una suspensión del
proyecto menos de 2 meses después, cuando CMC varios miembros del
personal estarían de vacaciones desde mediados de diciembre de 2009
hasta bien entrado enero de 2010. Los veraneantes incluyeron a Janet Sam
y Eddie Tortuga. Ahora, al leer las notas, Noli recordó que había creído que
se podía hacer poco progreso si los líderes del proyecto de CMC no estaban
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 la licencia de maternidad, pero poco después presentó su
renuncia. Con el objetivo de cerrar el proyecto lo más rápido posible, Noli
nombró a Rafael León, un especialista en operaciones, para asumir el
control. Noli explicó a un colega: "Como Gerente de Operaciones de Pegaso,
León tiene la autoridad para cerrar el proyecto".
Pronto, Leon informó que CMC había solicitado nuevas capacidades de
informes, para lo cual Pegaso no había planificado. Desafortunadamente,
el contrato especificó que CMC podría solicitar tales mejoras y que Pegaso
Perú haría el trabajo sin costo adicional. Después de evaluar estas
solicitudes y evaluar el tiempo necesario para completarlas, León le pidió a
Noli que agregue más recursos al proyecto antes de reanudarlo. Se llegó a
un acuerdo con CMC de que junio de 2010 sería la fecha de finalización del
nuevo proyecto (11 meses después de la fecha límite original de agosto de
2009).
¿Cómo fue que el contrato le dio al cliente tanto poder? Pensando en ello,
Brunella Noli ahora entendió que, aunque Priscilla Ugaz había creído que la
mayoría del trabajo sobre el desarrollo y finalización de informes había sido
detallado en el BBP, había incertidumbre con respecto a las necesidades
generales de informes del cliente. Por lo tanto, las especificaciones finales
para la función de informe se difirieron deliberadamente hasta que se
conoció la cantidad real de informes. Noli había discutido este tema con
Ana Pérez, y habían acordado permitir la provisión en el BBP que daba
derecho a CMC a solicitar informes adicionales durante la fase de
implementación del proyecto. Esta cláusula ahora fue el desencadenante
de las nuevas solicitudes de informes. CMC tuvo suficiente tiempo para
considerar sus necesidades de informes, ya que el proyecto duró casi un
año más de lo planeado. Tal vez con el tiempo, las expectativas de CMC para
el sistema habían crecido más allá de lo que inicialmente se había previsto
en el BBP.
Un golpe en la puerta hizo que Noli levantara la mirada; fue Rafael Leon.
Llegó directamente al grano, afirmando que él y otros en el equipo de
implementación sospechaban que CMC estaba tratando de sacar más
provecho del contrato de lo que se había previsto y acordado
informalmente entre Ana Pérez y José Barrantes. No se había realizado una
evaluación previa del tiempo y los recursos requeridos para ninguno de los
informes adicionales, en caso de que se soliciten. Leon agregó un
comentario alarmante:
Si siguen pidiendo nuevos informes, nunca terminaremos el proyecto.
¿Cómo les decimos que no aceptaremos requisitos a los que no se
comprometió originalmente en BBP?
La respuesta de Brunella Noli a Leon fue abrupta:
Para terminar depende de cuántas personas más asignamos. Pero CMC no
está obligado a pagar más, porque estamos muy por sobre el cronograma.
¡Debemos cerrar esto lo más pronto posible!
Apéndice A
Resumen de la cartera de clientes de Pegaso Perú
Pegaso Perú factura aproximadamente $ 1 millón por año, compuesto por
proyectos grandes y pequeños en una amplia gama de industrias. El
proyecto CMC fue considerado grande según los estándares de Pegaso
Perú. La Tabla A1 proporciona datos de un proyecto grande típico para cada
sector, en comparación con el proyecto CMC.
CMC se consideró un gran proyecto y fue importante porque:
● era un cliente nuevo y potencialmente grande,
● el módulo de SAP (planificación y consolidación empresarial) no se solicita
con frecuencia,
● el éxito con este proyecto traería la industria de Pegaso Perú prestigio.
El marco de tiempo para este tipo de proyecto generalmente es de 3 a 4
meses y los clientes generalmente solicitan adiciones al rendimiento y la
funcionalidad luego de la instalación inicial y la experiencia del usuario.

Apéndice B
Cláusulas clave del Pegaso Perú / CMC BBP
Resumen ejecutivo
La fase/diseño de BBP es una encuesta de los requisitos descritos en el
alcance del proyecto y el documento de declaración. Su objetivo es crear
un modelo de análisis, un proceso de conversión, un esquema de la
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 encuestas sobre las necesidades de informes con paneles de
funciones y funcionalidad utilizando el software SAP Business Objects.
Para compilar este documento, se realizaron sesiones con los
patrocinadores y usuarios del proyecto que fueron seleccionados de las
áreas clave de Marketing, Operaciones y Finanzas. Estas sesiones tenían los
objetivos de:
● Asistir con problemas relacionados con los procesos de cada módulo y la
organización general con el fin de obtener una visión integral de CMC y sus
requisitos de información y establecer un modelo integral.
● Determinación de los patrocinadores del proyecto y los usuarios que
informan los requisitos y los 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 el negocio casos para 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 requisitos de información
y todos los procesos de carga de datos. Sin embargo, al final de este
documento hay una provisión para un número 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 tabla están cubiertos por la información
contenida en este documento.

Marcos de tiempo iniciales y requisitos

Para continuar, el proyecto SAP Business Objects BI requiere:
1. Acceso a la red de CMC.
2. Disponibilidad del conocimiento comercial funcional de CMC para validar
el modelo conceptual, las decisiones de diseño funcional y para abordar
preguntas específicas que puedan surgir durante la etapa de construcción.
3. Disponibilidad y acceso a la plataforma de tecnología CMC,
Servidores de base de datos para repositorio y Data Mart Staging Servidores
de aplicaciones empresariales y Business Objects Tools, SAP Data Services y
SAP Business Objects BI Platform.
Abril de 2009: recursos técnicos de CMC y conocimiento avanzado de las
fuentes de datos requeridas para la validación comercial del Mart Data del
modelo de datos. También se requieren poderes de toma de decisiones
para abordar preguntas 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 realizar pruebas exhaustivas de la solución. Esto requiere la
participación de dos usuarios funcionales de tiempo completo para la
validación de informes, tableros, para confirmar la exactitud de la
información y un recurso técnico de tiempo completo para una revisión de
procesos de extracción, transformación y carga, y tiempos de ejecución de
consultas.
Pagos
El 25% del precio se pagará una vez que CMC acepte este BBP.
El 75% del precio se pagará al completar todos los hitos clave y la
implementación completa de la solución del proyecto.
Reportar exclusiones y contingencias
El alcance detallado del proyecto se encuentra en el Anexo 1: Declaración
de alcance para CMC. Este documento ha sido revisado y aprobado por CMC
y Pegaso.
Sin embargo, para 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.
Además del alcance funcional del proyecto están el desarrollo de 15
informes de Web Intelligence y 2 paneles de SAP Business Objects. Para
revisar los detalles de los informes y paneles requeridos, consulte los
archivos adjuntos en 'Apéndice 4 - Definición de informes y paneles'.
Importante: Hasta la fecha, CMC solo podía definir 10 informes y 1 tabla de
datos: otros informes y tablas de datos aprovisionados en el las últimas
partes de este documento deben definirse y enviarse a Pegaso en la tercera
parte de la fase de Construcción.
Hitos y responsabilidades clave
1. CMC debe entregar a los consultores de Pegaso los informes que
contienen los indicadores básicos actualmente válidos (ventas, objetivos e
inventario) con el nivel mínimo de detalle para el proceso de carga de datos,
su validación y definición de informes. Esta información debe enviarse
antes del 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 (3 meses para
todas las tiendas) en el entorno de etapas cuando las tareas de desarrollo
de aplicaciones comiencen (5 de mayo de 2009) para las pruebas y Pegaso
pueda validar la calidad de los procesos de carga.
3. CMC debe proporcionar a Pegaso el Script de prueba completo a más
tardar el 2 de junio de 2009.
Abril: CMC y Pegasus apoyaron el hecho de que el esquema 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 las
herramientas estándar de SAP Business Objects. Pegaso es responsable de
enviar 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 e incluyen en el marco de
tiempo pueden afectar gravemente el éxito del proyecto:
● Los sistemas de recursos cambian de estructura.
● cambios en la plataforma tecnológica.
● rotación del personal de CMC en las actividades del proyecto.
● disponibilidad del personal de CMC.
● rotación de personal en Pegaso.
● Disponibilidad del 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 necesario.
● Incapacidad para coordinar reuniones con usuarios funcionales, lo que
retrasaría el proyecto.
● Plazos para las aprobaciones de CMC para detener el inicio de alguna
etapa.
● Las fuentes de datos no están disponibles.
● Incapacidad de tener usuarios técnicos con conocimiento avanzado de las
fuentes de datos involucradas

Apéndice C
Conceptos básicos de los módulos R / 3 de SAP
SAP AG comenzó a operar en 1972 y se convirtió en un é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: sistema mainframe R/2 y
cliente/servidor R/3 (la 'R' era para 'procesamiento de datos en tiempo real'
y '3' era para ' 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 compañía
en el mercado.
El software ERP es un concepto que comenzó en la década de 1970 y estaba
destinado a proporcionar soluciones computarizadas para integrar y
automatizar los procesos comerciales en las oficinas administrativas de las
empresas, como los departamentos de finanzas, logística o recursos
humanos. Para SAP, un proceso comercial es la cadena funcional completa
involucrada en las prácticas comerciales, cualquiera que sea el módulo, la
aplicación, el sistema o el servicio web que tenga que tratar con ella. Esto
significa, específicamente para los sistemas SAP R/3, que la cadena de
proceso podría ejecutarse en diferentes módulos.
SAP R / 3 está organizado en distintos módulos funcionales, que cubren las
funciones típicas de una organización. Los módulos más utilizados fueron:
Control Financiero y Financiero, 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í mismo, pero está vinculado a
los demás cuando corresponda. Como R / 3 opera en tiempo real, cuando
se realizan nuevas entradas en el sistema, los enlaces lógicos de la
aplicación 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 sobrecarga de procesamiento y
comunicación manual y permite a las empresas reaccionar rápidamente, lo
que hace que el software SAP R / 3 y las soluciones de SAP Business
Intelligence sean herramientas muy valiosas para la planificación ejecutiva
y la toma de decisiones.
Hacia el final 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 de la industria. Así, SAP introdujo una
gama de módulos organizados por unidades de negocio, uno de los cuales
era SAP BI que incluye SAP Business Information Warehouse y SAP
Knowledge Warehouse, una solución que captura, combina y organiza
datos de una variedad de fuentes internas y externas y lo hace disponible
para los procesos de toma de decisiones.
Para 2004, SAP había reposicionado su estrategia y soluciones de
productos, con el módulo SAP R / 3 apuntalando una cartera de soluciones
integradas más amplia basada en web que incluye SAP Business Suite, un
nombre común que ahora se utiliza para las soluciones SAP R / 3 en todos
los negocios . Ver la Figura C1 para la cartera de productos de SAP 2002.
Pegaso Peru: an overdue project (B)
Brunella Noli, como socia de Pegaso y Gerente General de Pegaso Perú, era
la única responsable de cualquier decisión de cancelación o recuperación
de un proyecto relacionada con las operaciones peruanas. El 22 de febrero
de 2010 se había reunido con Rafael Leon para decidir cómo completar el
proyecto de CMC para que Pegaso pudiera cobrar su pago final. Sin
embargo, en las semanas y días siguientes, el trabajo progresó lentamente.
CMC siguió solicitando nuevos informes y, como resultado, no se cumplió
el plazo revisado de junio de 2010; otra extensión fue permitida. En octubre
de 2010, las solicitudes de nuevos informes se habían detenido y el sistema
estaba listo para la prueba. Rafael Leon le pidió a CMC que asignara el
tiempo y los recursos necesarios para permitir una prueba completa e
ininterrumpida. Leon sintió que la líder del proyecto de CMC, Janet Sam,
sería la persona ideal para capacitar a los usuarios de CMC. Sam tenía un
conocimiento sustancial del proyecto y fue autorizado para aprobar el
cierre del proyecto en nombre de CMC. Leon solicitó que la prueba se
complete a principios de diciembre de 2010.
En un correo electrónico, Janet Sam argumentó que no tenían suficientes
personas para operar una prueba, porque su ciclo presupuestario interno y
los procesos estaban en marcha. Esa era la prioridad actual de la unidad,
ocupando todo el tiempo de personal disponible. Rafael inmediatamente
envió esta respuesta a Brunella Noli. Una vez más, Noli decidió suspender
el proyecto hasta que el personal de CMC tenga tiempo para completar las
pruebas, informar errores y respaldar el nuevo sistema.
En diciembre, un fondo de capital privado peruano invirtió en CMC,
convirtiéndose en su mayor accionista. La compañía recapitalizada anunció
que en marzo de 2011 comenzarían una expansión de 15 tiendas. Al mismo
tiempo, cambió su nombre comercial para convertirse en la cadena de Casa
Perú.
En febrero de 2011, Janet Sam informó a Pegaso que no se habían realizado
pruebas del sistema. El personal de CMC había tenido problemas para
introducir los datos de prueba en el módulo y no se habían compilado los
informes de depuración o de usuario. Brunella Noli se hizo cargo
inmediatamente del proyecto y mantuvo una reunión tensa con Janet Sam.
Noli había reprendido a Sam por las asignaciones de recursos de CMC. A
medida que aumentaba la tensión, Noli declaró: 'No voy a hablar de esto
contigo. Creo que necesito hablar con tu jefe al respecto. "Janet respondió
con firmeza:" Estoy a cargo de la unidad de planificación y si involucras a mi
jefe en este asunto, me iré".
Noli se dirigió al jefe de Sam, José Barrantes, ya que consideraba que
completar el proyecto para mantener la reputación de Pegaso era cada vez
más importante. Acordaron una nueva fecha para finalizar el proyecto:
mayo de 2011. Poco después de este acuerdo, CMC anunció que Janet Sam
había renunciado y se había nombrado un reemplazo: una persona que
tenía poca experiencia en TI o planificación y presupuesto, que no podía
entrenar otros usuarios del sistema y que no pudo supervisar la prueba del
nuevo sistema y los procedimientos.
En marzo de 2011, Brunella Noli asignó recursos adicionales para capacitar
al personal de CMC, lo que permitió una prueba del sistema para la
aprobación final. En el último minuto, sin embargo, CMC argumentó que no
podían probar el sistema porque el supervisor de pruebas entrenado por
Pegaso había renunciado. CMC afirmó además que no tenían personal
capaz de ejecutar la prueba del sistema.
Los entrenadores de Pegaso informaron otras noticias alarmantes: CMC
ahora parecía estar operando un sistema diferente para presupuestar y
prever. Posiblemente, lo habían desarrollado internamente cuando el
proyecto Pegaso había sido suspendido.
Una noche avanzada, a mediados de abril de 2011, mientras sacaba su auto
del parque, Brunella Noli se preguntó si Pegaso alguna vez recibiría un pago
final de CMC. Al 75% del valor del proyecto, era una suma sustancial de
aproximadamente el 3% de la facturación anual de Pegaso, pero lo que más
la preocupaba era el costo de la reputación y el potencial de una derrota
personal.