✒️SAP / Los factores de éxito y fracaso en una Implementación SAP Por María Pronotti

Factores de éxito de una implementación SAP

Ante una implementación SAP que finaliza en tiempo y con lo presupuestado, deberíamos preguntarnos:

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

Si hemos puesto estas preguntas en perspectiva, podremos realmente definir el exito.

Factores que determinan el éxito relativo de un proyecto: (desde la base hacia arriba en la pirámide)

1. Comunicación: Buena comunicación entre los miembros del equipo del proyecto. La clave es que la comunicación sea buena, específica, exacta y oportuna. Para ello lo ideal sería que los integrantes del equipo estén físicamente juntos. (Cuando los desarrolladores ABAP son externos, se tiene éxito pero con horas de consultoría sin fin que el cliente paga debido a este método.)
2. Apoyo total de la dirección: Debe haber compromiso total y absoluto y apoyo para el proyecto. Si la Dirección no muestra, tanto en palabras como en hechos que la implementación de SAP es importante para los miembros del equipo, usuarios finales y así sucesivamente, entonces el proyecto fracasará. Las maneras en que la Dirección proporciona apoyo al proyecto, es por participación activa en la planificación y dirección del proyecto.
3. Alcance Apropiado. No se puede implementar todos los módulos que SAP ofrece, SAP debe ser implementado según las necesidades del negocio.
4. Motivar, apreciar y premiar a las personas: Además el líder del proyecto debe estar involucrado en el día a día para que as personas que forman parte del equipo tengan esa sensación.
5. Manejar el Cambio: Hacer entender a las personas que los cambios son algo bueno no es sencillo. Las personas normalmente tienen miedo del cambio en los negocios ya que tienen miedo por su seguridad en el trabajo y desgraciadamente así es.
6. Encontrar a los mejores recursos: Para implementar SAP es necesario contar con personal idóneo y experimentado. La pérdida de motivación asociada con los altos niveles de cambio puede derivar en que personal con mucha experiencia se vaya de la empresa. El cliente y la dirección deben estar involucrados en el proceso de contratación del equipo que llevará adelante el proyecto. Si se experimentan en SAP despúes se van en busca de mejores condiciones laborales o mejores sueldos. Si se van provocan retraso en tiempos de entrega.
7. Política: Es importante asegurarse que la política y las agendas ocultas de esta, no descarrilen el proceso de implementación.

Errores más comunes en implementación de SAP.

• No dedicar suficiente tiempo a el entendimiento claro de los actuales procesos de negocio. Al Diseño de los nuevos procesos. A la Validación de Datos.
• Diseño de nuevos procesos que no pueden ejecutarse en el Sistema.
• Mala administración del "cambio organizacional": Es una estrategia normativa que hace referencia a la necesidad de un cambio.
• Falta de compromiso por parte de los usuarios: Ejecutivos, procesos de negocio, sistemas.
• Mala administración del "alcance del proyecto". es la suma total de todos los productos y sus requisitos o características.
• Mala estimación de los requerimientos de hardware.

Buenas prácticas para minimizar riesgos:

• Usar Metodologías de Administración de Proyectos.
• Llevar a cabo regularmente reuniones de planeación estratégica para asegurar alineación de objetivos.
• Conducir encuestas de satisfacción de los clientes internos.
• Crear y usar métricas para evaluación del desempeño.
• Usar metodologías para establecimiento de prioridades.
• Realizar auditorías financieras.
• Usar programas de desarrollo de liderazgo.
• Incluir al Ejecutivo de Sistemas como parte del Comité Ejecutivo.
• Conducir auditorías post-implemmentación.

Errores clásicos en un proyecto de implementación de SW:

1996 Steve MacConell: Dijo: Errores clasicos: Aquellos que se han repetido tantas veces, y por tanta gente, que deberían ser previsibles y seimpre se deberían gestionar.

• Errores realcionados con las personas:

Motivación debil: Mayor efecto sobre la productividad y la calidad.
Personal mediocre: Capacidad individual, asi como su relación con el equipo -> mayor influenciaa en la productividad.
Empleados problemáticos incontrolados: Amenza velocidad de desarrollo.
Hazañas: Desarrolladores énfasis en hazañas. Pero lo que hacen tiene más de malo que de bueno.
Añadir mas personal a un proyecto retrasado. Puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros.
Oficinas repletas y ruidosas
Fricciones entre los clientes y los desarrolladores. Problemas con fijar bien el alcance.
Expectativas poco realistas. Estas son una de los 5 factores principales necesarios para asegurar el éxito de los proyectos.
Falta de un promotor efectivo del proyecto: Para soportar muchos de los aspectos del desarrollo rápido se necesita un promotor de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.
Falta de participación de los implicados:
Falta de participación del usuario
Política antes de desarrollo: Los políticos están especializados en la gestión, centrándose en las relaciones con sus directivos. Los investigadores se centran en explorar y reunir información.
Ilusiones: Cosas como estas "Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tien"
Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificación coherente y pueden ser la raíz de más problemas en el SW que todas las otras causas combinadas.

• Errores relacionados con los procesos

Estos errores ralentizan a los proyectos por que malgastan el talento y el esfuerzo del personal.
Planificación excesivamente optimista. predisponde a minimizar planificación, análisis y diseño. Supone excesiva presión a los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad.
Gestión de riesgos insuficientes: El fallo de no gestionar uno solo de estosriesgos es un error clásico.
Fallos de los contratados: El problema no esta en el abandono del plan, si no en no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir.
Planificación insuficiente: Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.
Abandono de la planificación bajo presión: Problema No tener plan alternativo.
Perdida de tiempo en el inicio difuso: Es el tiempo que transcurre antes de que comience el proyecto: este tiempo generalmente se pierde en el proceso de aprobar y hacer el presupuesto.
Escatimar en las actividades iniciales: Los proyectos que se aceleran intentando acortar las actividades no esenciales, y puesto que el análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles.
Diseño inadecuado: Escatimar tiempo en el diseño generan un diseño indeterminado.
Escatimar en el control de calidad. Generalmente cuando hay prisa, se saca revisiones de diseño y de código, planificación, pruebas. Solo se hacen pruebas superficiales.
Control insuficiente de la directiva: Poco control de la directiva a tiempo se abandonan cuando el proyecto comenzó a tener problemas.
Convergencia prematura o excesivamente frecuente: Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentación final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalación, eliminar las funciones que no van a estar listas a tiempo y demas.
Omitir tareas necesarias en la estimación: El esfuerzo omitido suele aumentar el plan de desarrollo en un 20% o 30%.

Planificar ponerse al día más adelante: Despues nunca se hace!
Otro tipo de error en la reestimación se debe a cambios en el producto. Si el producto que estamos construyendo cambiar, la cantidad de tiempo necesaria para construirlo cambiará también.
Programación a destajo: Algunas organizaciones creen que la codificación rápida, libre, tal como salga, es el camino hacia un desarrollo rápido.
Exceso de Requerimientos. Algunos proyectos tienen más requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de los que es necesario, y puede generar una planificación del SW muy larga.
Cambio de prestaciones: Si hemos pasado los requerimientos excesivos, los proyectos sufren como media un 25% de cambios en los requerimientos a lo largo de su vida. Esto implica un aumento en el plan...
Desarrolladores meticulosos: A veces quieren probar su propia implementación de un utilidad bonita pero innecesaria:Esfuerzos en diseño, implementación, prueba, documentación y mantenimiento innecesarias y pueden alargar el plan.
Tiras y aflojes en la negociación: Cuando un directivo aprueba un retraso porque viene mas lento de lo previsto, se empiezan a agregar nuevas tareas. Todo lleva mas retraso.
Desarrollo orientado a la investigación: Si el proyecto fuerza los límites de la informática por que necesita la creación de nuevos algoritmos o de nuevas tecnologías de computación, no estamos desarrollando SW, estamos investigando en SW y estos tiempos no son predecibles.

• Errores relacionados con el uso correcto o incorrecto de la tecnología moderna.

Sindrome de la panacea:Si un equipo de proyecto se aferra solo a una nueva técnica, una nueva tecnología o un proceso rígido, y espera resolver con ellos sus problemas de planificación, esta equivocado.
Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos. Las organizaciones mejorar raramente su productividad a grandes saltos. Los beneficios de las nuevas técnicas son parcialmente desplazados por las curvas de aprendizaje. Un caso especial es la reutilización de código aveces no se gana tanto como se espera.
Cambiar de herramientas a mitad del proyecto. Puede ser que cambiemos de version del mismo producto, pero cuando estamos a mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.
Falta de control automático del código fuente: Manejo de versiones.