✒️Los factores de éxito y fracaso en una Implementación SAP

FACTORES DE ÉXITO Y FRACASO EN UNA IMPLEMENTACIÓN SAP

FACTORES DE ÉXITO

• Después de implementar SAP en una empresa, en tiempo y presupuesto, es necesario hacernos las siguientes preguntas para realmente saber si fue exitosa o no:

1. El alcance inicial fue completado o se tuvieron que sacar procesos de alcance para lograrlo?
2. Cómo son las cosas ahora que la empresa salió en vivo?
3. Está funcionando bien el sistema?
4. Están totalmente entrenados los usuarios finales?
5. Se necesita apoyo de la consultoría para mantener el día a día de la empresa?

• Factores que determinan el ÉXITO de una implementación SAP:

1. COMUNICACIÓN: buena comunicación entre los miembros del proyecto. Que sea específica, exacta, oportuna. Para ello es ideal que los lugares de trabajo estén físicamente juntos. Para disminuir los costos del cliente, las empresas consultoras tercerizan los desarrollos ABAP.
2. APOYO TOTAL DE LA DIRECCIÓN: compromiso y apoyo para el proyecto. La dirección debe demostrar que la implementación de SAP es importante. Participación activa en la planificación y dirección del proyecto. Involucrarse en todos los niveles en cuanto a toma de decisiones y actividades diarias.
3. ALCANCE APROPIADO: SAP debe ser implementado (módulos a instalarse) según las necesidades del negocio.
4. MOTIVAR, APRECIAR, PREMIAR A LAS PERSONAS: para que trabajen duro. Para sentir motivación es importante que el líder de proyecto se involucre día a día en las actividades.
5. MANEJAR EL CAMBIO: Los cambios son buenos. Sin embargo la gente le teme debido a que esto representa inseguridad en el trabajo.
6. ENCONTRAR A LOS MEJORES RECURSOS: contar con personal experimentado pues así lo requiere el software por ser tan integrado. Gente se puede ir de la empresa debido a la pérdida de motivación y al cambio que se experimenta. El cliente y la dirección deben estar involucrados en la contratación del equipo que llevará el proyecto.
7. POLÍTICA: cada proyecto de sistemas que se realiza tiene involucradas cuestiones políticas. Es importante que éstas no descarrilen el proceso de implementación.

ERRORES MÁS COMUNES

• No dedicar tiempo suficiente a: *el entendimiento claro de los actuales procesos de negocio, *Diseño de nuevos procesos, *Validación de datos.
• Diseño de nuevos procesos que no pueden ejecutarse en el sistema.
• Mala administración del cambio organizacional
• Falta de compromiso por parte de los usuarios (ejecutivos, procesos de negocio, sistemas).
• Mala administración de alcance de proyecto
• Mala estimación de los requerimientos de hardware.

BUENAS PRÁCTICAS PARA MINIMIZAR RIESGOS

• Usar metodologías de Administración de Proyectos
• Hacer reuniones de planeación estratégica para asegurar la alineación de objetivos.
• Hacer encuestas de satisfacción de los clientes internos
• Crear métricas para evaluar el desempeño
• Usar metodologías para el establecimiento de prioridades
• Realizar auditorías financieras y post-implementación
• Programas de desarrollo de liderazgo
• Incluir al Ejecutivo de Sistemas como parte del Comité Ejecutivo.

ERRORES CLÁSICOS EN UN PROYECTO DE IMPLEMENTACIÓN DE SOFTWARE

I. ERRORES RELACIONADOS CON LAS PERSONAS

1. MOTIVACIÓN DÉBIL: la falta de motivación es el factor crucial para la falta de éxito de un proyecto. A más motivación, mayor productividad y calidad.
2. PERSONAL MEDIOCRE: el que una persona individualmente no sea capaz y tampoco aporte positivamente a su equipo es la mayor causa de improductividad.
3. EMPLEADOS PROBLEMÁTICOS INCONTROLADOS: el trabajar con un empleado problemático amenaza la velocidad de desarrollo del proyecto.
4. HAZAÑAS: las hazañas en el proyecto por parte de los desarrolladores de software pueden tener más cosas buenas que malas.
5. AÑADIR MÁS PERSONAL A UN PROYECTO RETRASADO: el error más clásico. Hacer esto retrasa aún más y quita productividad al personal que originalmente estaba en el proyecto.
6. OFICINAS REPLETAS Y RUIDOSAS: debería haber silencio y privacidad.
7. FRICCIONES ENTRE CLIENTES Y DESARROLLADORES: los clientes piensan que los desarrolladores no cooperan cuando no entregan el proyecto como prometido o cuando no llevan a cabo el plan de desarrollo que el cliente pidió. Por su parte los desarrolladores opinan que los clientes piden cosas irreales o modificaciones cuando el proyecto ya se fijó.
8. EXPECTATIVAS POCO REALISTAS: tener expectativas realistas es uno de los 5 puntos claves para que un proyecto de implementación de software tenga éxito.
9. FALTA DE UN PROMOTOR EFECTIVO DEL PROYECTO: se necesita un promotor de alto nivel para soportar el desarrollo rápido del proyecto. Debe tener una planificación realista, control de cambios e introducción de nuevos métodos de desarrollo.
10. FALTA DE PARTICIPACIÓN DE LOS IMPLICADOS: comprende promotores, ejecutivos, responsables y miembros del equipo, personal de ventas, usuarios finales y clientes.
11. FALTA DE PARTICIPACIÓN DEL USUARIO: la razón número 1 para que el proyecto salga exitoso es la parte del usuario.
12. POLÍTICA ANTES QUE DESARROLLO: los políticos están especializados en la gestión. Se centran en las relaciones con sus directivos. Se centran en explorar y reunir info.
13. ILUSIONES: se deben tener bases, planificación coherente y no solo ilusiones.

II. ERRORES RELACIONADOS CON LOS PROCESOS: malgastan el talento y esfuerzo del personal y ralentizan los proyectos.

14. PLANIFICACIÓN EXCESIVAMENTE OPTIMISTA: predispone a que el proyecto falle por infravalorar el proyecto. Se disminuye la planificación efectiva, se reducen actividades críticas para el desarrollo y el análisis de requerimiento o diseño. Supone excesiva presión para los desarrolladores y por tanto su moral y productividad.

15. GESTIÓN DE RIESGOS INSUFICIENTES: debe haber una gestión activa de los riesgos. si una cosa va mal entonces el proyecto irá de rápido a lento.

16. FALLOS DE LOS CONTRATADOS: las empresas contratan la parte de un proyecto con externos cuando tienen prisa para hacer el trabajo en casa. Pero el trabajo por parte de los contratados en entregado tarde, sin calidad, fallas. No hay que abandonar el plan. Crear un plan alterno. Codificar y corregir.

17. PLANIFICACIÓN INSUFICIENTE: planificar para conseguir desarrollo rápido.

18. ABANDONO D ELA PLANIFICACIÓN BAJO PRESIÓN: el equipo de desarrollo no debe abandonar el proyecto cuando surge un problema en la planificación. Crear un plan alterno. Codificar y corregir.

19. PÉRDIDA DE TIEMPO EN EL INICIO DIFUSO: es el tiempo que transcurre antes de que comience el proyecto. En el proceso de aprobar y hacer el presupuesto.

20. ESCATIMAR EN LAS ACTIVIDADES INICIALES: no hay que acortar las actividades no esenciales como lo son el análisis de requerimiento, arquitectura y diseño.

21. DISEÑO INADECUADO: parte de escatimar en las actividades iniciales. Se debe determinar el diseño, con tiempo y considerar alternativas de diseño.

22. ESCATIMAR EN EL CONTROL DE CALIDAD: no hay que eliminar las revisiones del diseño y código. No eliminar la planificación de pruebas ni hacer pruebas superficiales.

23. CONTROL INSUFICIENTE DE LA DIRECTIVA: la directiva debe detectar a tiempo los retrasos del plan, tener control del proyecto. Ver si va por buen camino.

Antes de entregar un producto hay que prepararlo, mejorar su rendimiento, imprimir la documentación final, incorporar entradas de ayuda, pulir programa de instalación, eliminar funciones que no estarán listas.

24. OMITIR TAREAS NECESARIAS EN LA ESTIMACIÓN: hay que guardar datos de proyectos anteriores.

25. PLANIFICAR PONERSE AL DÍA MÁS ADELANTE: si el producto que estamos construyendo cambia, entonces también el tiempo para construirlo.

26. PROGRAMACIÓN A DESTAJO: el camino al desarrollo rápido NO es la codificación rápida, libre y como salga.

III. ERRORES DE LA FORMA EN LA QUE SE DEFINE EL PRODUCTO

27. EXCESO DE REQUERIMIENTOS: la eficiencia es igual a lo que es necesario. La planificación del software puede ser innecesariamente larga.

28. CAMBIO DE LAS PRESTACIONES: los proyectos sufren en 25% cambios en requerimientos a lo largo de su vida. Un cambio así puede aumentar en tiempo la misma cantidad.

29. DESARROLLADORES METICULOSOS: el plan de desarrollo puede alargarse si los desarrolladores diseñan o implementan algo nuevo en el plan debido a la nueva tecnología o lenguaje.

30. TIRAS Y AFLOJES EN LA NEGOCIACIÓN: ocurre cuando un directivo aprueba el retraso de un plan y se añaden tareas nuevas después de un cambio de plan.

31. DESARROLLO ORIENTADO A LA INVESTIGACIÓN: el riesgo de fallo es alto cuando el diseñador sobrepasa los límites de la ingeniería en más de 2 áreas a la vez. Si el proyecto fuerza los límites de la informática porque necesita la creación de nuevos algoritmos o tecnologías entonces no estamos desarrollando software. estamos investigando en software.

IV. ERRORES RELACIONADOS CON EL USO CORRECTO O INCORRECTO DE LA TECNOLOGÍA MODERNA

32. SÍNDROME DE PANACEA: el equipo de proyecto NO debe aferrarse a una sola nueva técnica, tecnología o proceso rígido.

33. SOBREESTIMACIÓN DE LAS VENTAJAS DEL EMPLEO DE NUEVAS HERRAMIENTAS O MÉTODOS: el reutilizar el código de proyectos anteriores es un caso de sobreestimación de mejoras. Aunque la técnica sea efectiva, el tiempo que se gana no es grande. Los beneficios de las nuevas técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas.

34. CAMBIAR DE HERRAMIENTAS A MITAD DEL PROYECTO: no es recomendable hacerlo pues la curva de aprendizaje, rehacer el trabajo y herramientas nuevas anulan cualquier beneficio.

35. FALTA DE CONTROL AUTOMÁTICO DEL CÓDIGO FUENTE: si no hay código fuente los desarrolladores deben coordinar su trabajo manualmente. ponerse de acuerdo para poner la última versión de cada archivo en el directorio maestro y verificarlos con los demás antes de copiarlas en seste directorio. si no hacen esto, el nuevo código se desarrolla con interfaces desfasadas, y hay que rediseñar el código.