¿Es posible implantar un ERP de forma ágil? - Webinar PMI. Luis Carrasco

  • 4,104 views
Uploaded on

Presentación utilizada en el Webinar del PMI sobre métodos ágiles del 17 de febrero de 2011 …

Presentación utilizada en el Webinar del PMI sobre métodos ágiles del 17 de febrero de 2011

https://plus.google.com/111838161734108867236?rel=author

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,104
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
160
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. WEBINAR CONJUNTO MÉTODOS ÁGILES Y SUS APLICACIONES http://www.foundshit.com ¿Es posible implantar un ERP de forma ágil? Luis Carrasco Delphin Project Hunting 17 de febrero 2011
  • 2. Contenidos
    • Presentación
    • Cómo es un proyecto ERP
    • Implantar un ERP a lo tradicional
    • Debe haber otra forma
    • Conclusiones
  • 3. Presentación www.linkedin.com/in/luiscu www.nodotic.com Luis Carrasco Formado como Ingeniero de Telecomunicaciones por la UPC, Executive MBA por EAE y CPIM de APICS ( American Production and Inventory Control Society ) Tengo 20 años de experiencia profesional en tecnología y sistemas de información, la mayoría de ellos en su aplicación a la gestión empresarial. Actualmente en Delphin Project Hunting, una consultora especializada en definición y gestión de proyectos TIC. Anteriormente trabajé para Accenture (Manager) y Grupo Monsanto (responsable de IT en EMEA de una de las empresas del grupo). Más en: @nodoTIC http://slideshare.net/luiscu http://www.delicious.com/luiscu www.google.com/reader/shared/luiscu Contacto: http://www.linkedin.com/groups?gid=923077 luiscu [email_address] +34668861601
  • 4. Cómo es un proyecto ERP
    • PRODUCTO ERP
      • “ Pesado”, monolítico, cerrados
      • Orientado a ser configurado no programado .
      • Partes muy interdependientes entre sí
      • Arquitecturas tecnológicas obsoletas heredadas y para compatibilidad de versiones
      • Modelos de Licencias complejos
    • IMPLANTADOR
      • Perfiles especializados con roles muy específicos
      • Modelo de negocio “vender horas” habitualmente
      • Muy separado el equipo de ventas del de implantación
    • CLIENTE
      • Casi nunca hay alguien con visión única
      • Múltiples departamentos con objetivos a veces contrapuestos
      • Poca dedicación al proyecto (tienen su día a día)
    • PROYECTO
      • Alto impacto en la organización
      • Crítico - afecta a las operaciones del negocio
      • Difícil aislar objetivos
      • Larga duración: +riesgo de cambios
      • Muy costoso definir el alcance funcional en detalle por anticipado
      • Siempre con contratos a precio cerrado
  • 5. Implantar un ERP a lo tradicional Tradicionalmente se ha seguido un enfoque de implantación predictivo (en cascada)… Original de www.agile-spain.org Efectos : “del estudiante”, “patada a seguir”, “haberlo dicho antes”, …
  • 6. Implantar un ERP a lo tradicional … y no parece que estemos teniendo mucho éxito 2010 ERP Report: http://nodotic.me/1xak ERP Failures and Lawsuits list: http://nodotic.me/1xai
  • 7. … y es que pretender captar de forma abstracta lo que una empresa necesita (sus requerimientos de negocio ) y que esos requerimientos (suponiendo que se hayan captado bien) no cambien durante proyectos tan largos es… difícil .
  • 8. Debe haber otra forma
  • 9. Debe haber otra forma
  • 10. Debe haber otra forma El manifiesto por el desarrollo ágil del software Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan
    • Respetar a las personas , porque el equipo es quien conoce cómo mejorar el proceso en que trabaja.
    • Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
    • Aplazar el compromiso , retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
    • Crear conocimiento , tener feedback regular con el cliente para alinearse con sus expectativas.
    • Hacer entregas rápidas , para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
    • Desarrollar con calidad interna , de manera que el producto pueda ir creciendo con una velocidad sostenida.
    • Optimizar la totalidad del proceso , mejorar el proceso de creación del producto, desde la idea hasta su entrega.
    Principios Lean http://www.agilemanifesto.org/iso/es/manifesto.html http://www.agile-spain.org
  • 11. Debe haber otra forma … que en la práctica se traduce en:
    • Equipo :
      • Pequeños
      • Multidisciplinar y multi rol
      • Jerarquía débil (autogestionado)
    • Planificación y control :
      • Diaria
      • Medida continua y visible
      • Test como concepto central
      • Mejora continua (retrospectivas de Scrum por ejemplo)
    • Comunicación :
      • Simple y Visual (Kanban, diagramas burn down , …)
      • Reuniones cara a cara, cortas y frecuentes
      • Documentación la mínima, mejor prototipos o el software funcionando
    • Ejecución :
      • Incremental en plazos cortos y entregas pequeñas totalmente funcionales
      • Mínimo WIP (trabajo en curso)
      • Flujo, flujo, flujo
      • Poco énfasis en definir/acotar desde el principio (no “cerrar” el alcance funcional) porque se asume que siempre habrá cambios
  • 12. Debe haber otra forma Pero atención a los impedimentos específicos de los proyectos ERP que dificultan la utilización de enfoques ágiles:
  • 13. Debe haber otra forma Impedimentos específicos proyectos ERP: Difícil de encontrar un interlocutor único con visión de negocio completa y autoridad (el product owner de Scrum ) Es complicado aislar bloques de funcionalidad separable (o funciona todo o no funciona nada) lo que dificulta hacer entregas incrementales de bloques funcionalmente operativos Entornos de desarrollo y configuración donde no es fácil prototipar y tener entornos autónomos Gran interdependencia de elementos lo que exige un gran esfuerzo de testeo (pruebas de regresión) cada vez que se libera una nueva funcionalidad Equipos de implantación grandes y con perfiles muy especializados (técnicos vs funcionales y especialización por módulos) Toma de decisiones lenta (necesario consenso entre departamentos) y frecuentemente con implicaciones políticas Difícil venderlo. Por el alto impacto en la organización, la alta dirección está implicada, y exige contratos leoninos a precio x alcance cerrado con los proveedores Dependencia elevada entre tareas de diferentes equipos - resta flexibilidad de planificación. Los productos ERP arrastran una historia desde el punto de vista de arquitectura tecnológica que los hace poco flexibles a cambios continuos
  • 14. Debe haber otra forma Dónde podemos actuar: Puedes contribuir a este mapa mental y descargártelo en http://nodotic.me/1xun
  • 15. Debe haber otra forma Dónde podemos actuar: Puedes contribuir a este mapa mental y descargártelo en http://nodotic.me/1xun
  • 16. Debe haber otra forma Dónde podemos actuar: Puedes contribuir a este mapa mental y descargártelo en http://nodotic.me/1xun
  • 17. Debe haber otra forma Dónde podemos actuar: Puedes contribuir a este mapa mental y descargártelo en http://nodotic.me/1xun
  • 18. Conclusiones
    • Un proyecto de implantación de un ERP no es lo más propicio para aplicar metodologías o enfoques ágiles de forma integral:
      • Rigideces de entorno tecnológico y producto
      • Dificultad de obtener visión global en el cliente
      • Especialización de consultores
    • No obstante, siendo conscientes de los impedimentos específicos, sí que se pueden aplicar determinados principios ágiles, entre los que destacarían:
      • Mejorar comunicación y visibilidad de información de proyecto
      • Integrar/implicar al cliente en el equipo de trabajo
      • Uso de prototipos vs diseños funcionales/técnicos
      • Habilitación de zonas ágiles en el proyecto (p.e. tomas de requerimientos, desarrollo de informes, …)
  • 19. GRACIAS
    • Esta presentación se puede utilizar libremente siempre que menciones la procedencia/autor y que cualquier obra derivada en la que la utilices esté bajo estos mismos derechos.
    • http://creativecommons.org/licenses/by-sa/3.0/es/
    Esta presentación se puede descargar desde mi blog personal www.nodoTIC.com Material gráfico y herramientas: www.agile-spain.org http://panorama-consulting.com http://xmind.net http://www.foundshit.com En este documento he utilizado material encontrado en la red de uso autorizado, en principio, para este tipos de presentaciones. He intentado referenciar a los autores en la medida de mis posibilidades. En cualquier caso si crees que hay algún tipo de recurso para el que no estoy autorizado, házmelo saber en [email_address]
  • 20. BONUS  http://nodotic.me/1xgn Original de Geek and Poke Sobre reuniones y reporting de proyecto