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