mejora del proceso de softwarematerias.fi.uba.ar/7546/material/implantacion_paquetes_v...caso...
TRANSCRIPT
07/05/2009
1
v2
Mayo
2009 FIUBA – Administración y Control de Proyectos II
Administración de Proyectos de
Implementación de Paquetes
v2
Mayo
2009
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
Administración del Cambio
07/05/2009
2
v2
Mayo
2009
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
v2
Mayo
2009 FIUBA – Administración y Control de Proyectos II
Visión
4
07/05/2009
3
v2
Mayo
2009
Visión
Situaciones posibles:1. Desarrollar algo propio2. Adquirir 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 corporativos pueden 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?
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
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 tener 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)
Cambio Cultural Bajo/ Medio Alto
Expectativas
07/05/2009
4
v2
Mayo
2009 FIUBA – Administración y Control de Proyectos II
Alcance
v2
Mayo
200975.46 - Administración y Control de Proyectos II
Definición del Alcance
Se tiene que definir Alcance del proyecto:
Requerimientos
Solución (Alternativas)
Etapas
Calendario
Tenemos que elegir:
Producto
Proveedor
07/05/2009
5
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Empresa Proveedores
Definir
Requerimientos
Investigar Productos y Proveedores
SeleccionarProducto y Proveedor
Proponer:•Solución•Etapas•Calendario
Propuesta
económica
RevisarRequerimientos(si fuese necesario)
No siempre se formalizan
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
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 (customs)
evidente y necesaria que se detecte en el momento del
Alcance, toda otra adecuación debería quedar excluida.
07/05/2009
6
v2
Mayo
2009
+
Solución
75.46 - Administración y Control de Proyectos II
Definición del Alcance
Producto Base
Producto Adaptado
al entorno del Cliente
Parametrización
Extensiones vía
Desarrollos Custom
Desarrollos
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
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 custom
Desarrollo más costoso
Riesgo de perder soporte y garantía del
producto
07/05/2009
7
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
Definición del AlcanceAlternativas de Implementación
Alternativa de Solución
Producto Standard
ParametrizadoCustomizaciones 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íaPocas
La empresa toma como base el producto, pero desarrolla varias customs para hacerlo a su medida
BásicoGran
cantidad
Ideal (salvo que
implique cambio
cultural
importante)
Recomendado
No recomendada
v2
Mayo
2009
Definición del Alcance
Utilizar los procesos propuestos por el
producto
Que normalmente implementan las
mejores prácticas de la industria (Best
Practices)
Modificar (vía customs)
únicamente aquellos requerimientos que
no puedan ser cubiertos por el Producto
Standard y que sean centrales al negocio
75.46 - Administración y Control de Proyectos II
07/05/2009
8
v2
Mayo
2009
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
v2
Mayo
2009
75.46 - Administración y Control de Proyectos II
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
.
07/05/2009
9
v2
Mayo
200975.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
v2
Mayo
2009
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 importante en los procesos de la compañía
75.46 - Administración y Control de Proyectos II
07/05/2009
10
v2
Mayo
2009
Definición del Alcance
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
v2
Mayo
2009 FIUBA – Administración y Control de Proyectos II
Organización
20
07/05/2009
11
v2
Mayo
2009
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
v2
Mayo
2009
Organización – El Equipo
Representante Proveedor
Representante Usuarios Clave
Representante Sistemas
Líder de ProyectoUsuarios
Líder de Proyecto Sistemas
Steering
Comitee
Comité
Ejecutivo
Equipos de Trabajo
Desarrollos
-Relevamiento
-Propuesta Solución
-Parametrización
-Definiciones
-Aceptación
-Capacitación sobre
parametrización
-Relevamiento
-Customizaciones
-Interfaces
-Migraciones
Equipos de Trabajo
Usuarios
Equipos de Trabajo
Proveedor
Líder de Proyecto Proveedor
Gerentes de
Proyecto
07/05/2009
12
v2
Mayo
2009
Organización – El Equipo
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
v2
Mayo
2009 FIUBA – Administración y Control de Proyectos II
Ejecución y Control
24
07/05/2009
13
v2
Mayo
2009
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)
-customsrequeridas (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 /DesarrollarParametrizaciones
Especificar /DesarrollarCustoms
Especificar /Desarrollar Interfaces y Migraciones
Realizar Pruebas
de integración
Realizar Pruebas
de aceptaciónRelease
-Capacitación
-Estrategia
implementación
-Instalación
-Migraciones
v2
Mayo
2009
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 customs 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 customs y hacerlas aprobar por un comité de alto nivel, presentando una justificación de la misma.
07/05/2009
14
v2
Mayo
2009
Ejecución - El Proceso
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
v2
Mayo
2009
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
75.46 - Administración y Control de Proyectos II
07/05/2009
15
v2
Mayo
2009
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
v2
Mayo
2009
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 a 12 días.
75.46 - Administración y Control de Proyectos II
07/05/2009
16
v2
Mayo
2009
Caso Hershey Foods
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
v2
Mayo
2009
Caso Hershey Foods
Debido a la complejidad del R/3,
cualquier implementación que implique customspara 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
75.46 - Administración y Control de Proyectos II
07/05/2009
17
v2
Mayo
200975.46 - Administración y Control de Proyectos II
Fin