Octubre
2008 FIUBA – Administración y Control de Proyectos II
Administración de Proyectos de
Implementación de Paquetes
Fases de Project Management
Ejecución y Control Organización Inicio (Alcance) Visión Cierre Proyecto Aprobado Alcance Aprobado Planificación Aprobada Proyecto Finalizado Proyecto Cerrado
Octubre 2008 Administración del Cambio Organización/ Ejecución y Control
Fases de Implementación Paquete
1. Necesidad 2. Selección de Producto/ Proveedor 3. Implementación Inicio (Alcance) Visión
Visión
Octubre 2008
Visión
Situaciones posibles:
1. Desarrollar algo propio o adquirir un paquete.
2. Desarrollar algo propio está descartado. Sé quiere un paquete,
pero no se sabe cual.
3. Implementar un paquete determinado.
No es momento de definir producto y proveedor, sin embargo
hay excepciones:
Lineamientos corporativospueden definir:
La utilización de un paquete determinado
La contratación de un proveedor determinado
Si la Visión se aprueba en función de sus costos y beneficios,
en este momento debería hacer un rápido análisis de
mercado.
Qué productos existen? , Clientes que poseen?
Qué valores se manejan?
Desarrollo propio o Paquete?
Característica Desarrollo Propio Paquete
Best Practices Investigar y analizar Ya incorporadas
Desarrollo En general, proyecto más riesgoso. Mayor probabilidad de defectos. Es el core de la compañía? Proyecto más corto.
Se puede ver operando en otras instalaciones y obtener referencias.
Menos defectos y una estabilización más corta.
Costos: variable, a veces ofrece más de lo que necesito. Costos de mantenimiento Equipo propio Actualizaciones periódicas disponibles.
Riesgo de volverse dependiente de un proveedor ( y perder poder de negociación)
Octubre
2008 FIUBA – Administración y Control de Proyectos II
Alcance
Definición del Alcance
Se tiene que definir Alcance del proyecto:
Requerimientos
Solución (Alternativas)
Etapas
Calendario
Tenemos que elegir:
Producto
Octubre 2008
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Empresa Proveedores Definir Requerimientos Investigar Productos y Proveedores Seleccionar Producto y Proveedor Proponer: •Solución •Etapas •Calendario Propuesta económica Revisar Requerimientos (si fuese necesario) No siempre se
formalizan
Definición del Alcance
Propuesta económica relacionada con
Alcance del Proyecto
Los paquetes son adaptables y esto facilita la definición
del alcance.
Excepto alguna adecuación vía desarrollo
(customizacion) evidente y necesaria que se detecte en
el momento del Alcance, toda otra customización
Octubre 2008
+
Solución
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Producto BaseProducto Adaptado al entorno del Cliente
Parametrización
Extensiones vía Desarrollos Custom (“Customizaciones”)
Desarrollos
Definición del Alcance
Mantenimiento más costoso:
•
No se pueden aplicar las actualizaciones del producto
(o su aplicación requiere un evaluación preliminar
importante)
•
Una actualización puede dejar sin uso una
customización
Desarrollo más costoso
Riesgo de perder soporte y garantía del
producto
Octubre 2008
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Alternativas de Implementación
Alternativa de
Solución Producto Standard
Parametrizado Customizaciones Evaluación
La empresa se adapta al producto parametrizado
en un 100% Completo Ninguna
La empresa se adapta al producto parametrizado,
con algunas excepciones En su
mayoría Pocas
La empresa toma como base el producto, pero desarrolla varias customizaciones para hacerlo a su medida
Básico Gran
cantidad
Ideal (salvo que implique cambio cultural importante)
Recomendado
No recomendada
Definición del Alcance
Utilizar los procesos propuestos por el
producto, que normalmente
implementan las mejores prácticas de
la industria (Best Practices)
Modificar (via customs) únicamente
aquellos requerimientos que no puedan
ser cubiertos por el Producto Standard
y que sean centrales al negocio
Octubre 2008
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Los proyectos de implementación de paquetes
tienen algunas similitudes
Estandarización del proceso, que facilita
estimación,
identificación de riesgos,
definición de la solución
Otros costos:
Mantenimiento del producto
Infraestructura para su puesta en producción
Definición del Alcance
¿Qué es el TCO (Total Cost of
Ownership)?
Modelo para calcular el costo total de una
adquisición teniendo en cuenta los costos y
beneficios, ya sea directos e indirectos
relacionados con la adquisición, el
desarrollo o el uso de componentes de IT
Desarrollado por el Gartner Group en 1987
Octubre 2008
75.46 - Administración y Control de Proyectos II
Definición del Alcance
¿Qué abarca el análisis del TCO?
Licencias
Por usuario,
por procesador,
por usuario concurrente, etc.
Renovación de las licencias
Actualizaciones
Soporte
On Call, On Site
Capacitación
Definición del Alcance
El producto ofrece gran cantidad de
funcionalidades integradas:
¿Cuáles conviene implementar?
¿Cuáles dejar afuera?
Alternativas:
Implementación por etapas ofrece menos riesgo
cambio cultural menor,
proyecto más reducido
Implementación Big Bang, mayor riesgo
cambio cultural mayor,
proyecto más extenso
Puede ser conveniente si se requiere un cambio
Octubre 2008
Arrastra problemas adicionales
Lo que no se implemente tendrá que
conectarse con lo actual vía interfases
Con costo de:
Desarrollo,
Operaciones, y
Mantenimiento.
75.46 - Administración y Control de Proyectos II
Octubre 2008
Organización – El Equipo
Equipo de trabajo interdisciplinario:
Especialistas en el Producto
Usuarios Clave
Conocedores del negocio
Quedarán con el conocimiento de la
parametrización del producto
Especialistas en Sistemas Actuales
¿Quién es el Líder de Proyecto?
75.46 - Administración y Control de Proyectos II
Organización – El Equipo
Representante Proveedor Representante Usuarios Clave Representante Sistemas Líder de Proyecto Usuarios Líder de Proyecto Sistemas Steering Comitee Comité Ejecutivo Equipos de Trabajo Desarrollos -Relevamiento -Propuesta Solución -Definiciones -Aceptación -Capacitación sobre -Relevamiento -Customizaciones -Interfaces Equipos de Trabajo Usuarios Equipos de Trabajo Proveedor Líder de Proyecto Proveedor Gerentes de Proyecto
Octubre 2008
No hay un único Líder de Proyecto.
Todos los interesados están representados
El Líder de Proyecto Sistemas tendrá que coordinar diversos
grupos, según las especialidades de desarrollo y los sistemas afectados.
En este ejemplo se omitió la participación de Infraestructura,
probablemente participe como parte del Equipo de Sistemas o bien un Líder de Proyecto adicional.
Conflicto:
Los especialistas en sistemas actuales sienten que pierden poder y pasarán a ser prescindibles.
Si el Proyecto tuviese tamaño importante, podrían definirse
responsables por módulos.
75.46 - Administración y Control de Proyectos II
Octubre 2008
Ejecución - El Proceso
Definir requerimientos Capacitar sobre Producto Standard Efectuar Análisis de Gap Especificar Solución -Proceso propuesto-Casos de Uso de la solución planteada -Parametrizaciones requeridas (alto nivel) -Customizaciones requeridas (alto nivel) -Interfaces requeridas
-Migraciones/Cargas iniciales requeridas -Qué escenarios
quedan cubiertos con alguna función estándar del producto. -Qué escenarios deberán ser cubiertos por un desarrollo custom. -Proceso actual -Lista de requerimientos
-Escenarios de uso (CU de alto nivel): - Actuales - Nuevos (requeridos) Especificar / Desarrollar Parametrizaciones Especificar / Desarrollar Customs Especificar / Desarrollar Interfaces y Migraciones Realizar Pruebas de integración Realizar Pruebas de aceptación Release -Capacitación -Estrategia implementación -Instalación -Migraciones
Ejecución - El Proceso
La infraestructura debe definirse e instalarse en
forma temprana.
Se puede avanzar con pruebas sobre la instalación con una
parametrización básica y estándar En forma temprana
Controlar en todo momento que las customis sean
las mínimas necesarias.
Incorporar al Equipo alguien con alto poder de
decisión para tomar decisiones sobre cambios en los
procesos actuales y dirimir conflictos entre áreas.
Controlar las customizaciones y hacerlas aprobar por
un comité de alto nivel, presentando una justificación
de la misma.
Octubre 2008
Alta interdependencia
necesidad de gran coordinación entre los distintos
grupos involucrados
Testing del producto consiste de:
Prueba de procesos, validando
parametrizaciones,
customs e
interfaces
Pruebas de atributos de calidad del producto
performance,
seguridad
recuperación
…..
75.46 - Administración y Control de Proyectos II
Administración del Cambio
Impulsar un proceso de Administración del Cambio
para todos los niveles involucrados
.
Cambios en los procesos.
Cambios en la estructura de poder
Personas imprescindibles dejarán de serlo
Los especialistas en sistemas actuales sienten que pierden
poder
Revisar todos los conceptos de la clase de
Administración del Cambio
Octubre 2008
Caso Hershey Foods
Objetivos:
Instalar un ERP
Integrar varias aplicaciones legacy dispares
para el manejo de pedidos,
inventario y
RRHH
en una única plataforma.
comienzo 1996
Trabajaron en Hershey
4 consultoras y
el departamento de IT para instalar
SAP AG R/3,
Manugistics Group con su producto de planeamiento, y
Siebel Systems con su producto de promociones de precio.
El costo del proyecto estimado entre u$s112 y 115 millones
75.46 - Administración y Control de Proyectos II
Caso Hershey Foods
En Julio de 1999,
con la implementación 3 meses atrasada,
Hershey salió a producción con la conversión de un viejo
legacy al nuevo SAP AG R/3
Dos meses después de la implementación completada
todavía se estaba corrigiendo errores en el sistema
Las ventas de la compañía cayeron
en su tercer cuatrimestre, la época de mayor venta, en más
del 12%.
Junto con ello,
hubo una caída del 18% de la facturación comparado con el
año anterior
y un incremento del stock del 29%,
mientras que su tiempo de entrega para pedidos paso de 5
Octubre 2008
El tiempo de implementación original
estaba estimado en 48 meses y
fue recortado a 30 meses por razones desconocidas
sin pensar que los módulos de R/3 debían integrarse con
software de otros dos vendedores
La consecuencia de la compresión del tiempo de
implementación fue
que se dedicó poco tiempo a prueba de los módulos y
entrenamiento de usuarios
Estos son los dos problemas más comunes en este tipo
de implementaciones,
calendario ambicioso y
entrenamiento insuficiente, que combinado crea un desastre
en la organización.
75.46 - Administración y Control de Proyectos II
Caso Hershey Foods
Debido a la complejidad del R/3,
cualquier implementación que implique customs
para conectarse con otros productos tiene efectos
inesperados, difíciles de encontrar y corregir.
Un año le tomo a Hershey corregir todos los
errores de implementación y volver a operar
normalmente y con ganancias.
En este proyecto, la reducción drástica de los
tiempos de implementación de 48 a 30 meses
fue la mayor contribuyente al desastre
Octubre 2008
75.46 - Administración y Control de Proyectos II
