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

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

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

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

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

20. BONUS  http://nodotic.me/1xgn Original de Geek and Poke Sobre reuniones y reporting de proyecto