Metodología de implementación de ERP para grandes empresas y holdings

Metodología de implementación de ERP para grandes empresas y holdings

Para grandes empresas y holdings.

Esta metodología está diseñada para migraciones de SAP y Oracle a 1C. También es adecuada para migrar de sistemas 1C heredados a otros más modernos (por ejemplo, de 1C:UPP a 1C:ERP).

*No apta para el sector público ni para pequeñas empresas.

La mayoría de los proyectos de implementación fracasan porque el cliente no comprende que es necesario dedicar suficiente tiempo al proyecto y trabajar en él con prontitud, o no está preparado para ello. Por desgracia, un equipo no puede llegar, configurarlo todo y marcharse. Es el cliente quien debe aportar la información, hacer ajustes, probar los resultados, tomar las decisiones clave a medida que avanza el proyecto y aceptar el trabajo terminado. Nuestra metodología nos permite llevar el proyecto hasta obtener resultados, mientras que el cliente participa en cada etapa, está informado y puede influir en el proceso, de modo que obtiene exactamente lo que quería.

Todo proyecto debe cumplir los plazos, ajustarse al presupuesto y alcanzar sus objetivos.

El objetivo de todo cliente es

1) pasar al nuevo sistema a tiempo y dentro del presupuesto,

2) preservar los procesos clave, críticos para el negocio, sin perder eficiencia,

3) mantener las personalizaciones del nuevo sistema al mínimo, ya que siempre implican desarrollo adicional y costos de soporte futuros.

Implementar un nuevo sistema es, ante todo, consultoría. Antes, las implementaciones las dirigían los desarrolladores; hoy, la mayor parte del trabajo la realizan los analistas. Cuanto mejor sea el análisis, menos personalizaciones se necesitarán.

Tareas clave del proyecto:

Etapa 1: Diseño.

- Analizar los procesos de negocio actuales de la empresa y documentarlos para que el contratista y el cliente compartan una visión única de todos los procesos.

- Modelar estos procesos en el nuevo sistema. Esto significa tomar documentos y procesos reales e intentar reproducirlos en el nuevo sistema. Hacemos una demostración al cliente y, según los resultados, registramos los «cuellos de botella» (brechas funcionales) que impedirían que el sistema funcionara correctamente.

Cuando es necesario migrar datos del sistema antiguo al nuevo, hay que acordar el alcance de los datos que se migrarán y desarrollar las herramientas de migración.

Etapa 2: Desarrollo.

Una vez identificadas las brechas críticas, desarrollamos las soluciones y las acordamos con el cliente, mostrándole cada semana los resultados de nuestro trabajo para que entienda qué recibirá y también pueda orientar el desarrollo.

Etapa 3: Operación piloto.

Un problema frecuente: el desarrollo está terminado y los datos cargados, pero el sistema no funciona por errores. Por eso se necesitan pruebas integrales.

Realizamos 3 tipos de pruebas:

Pruebas internas: una ejecución completa del sistema de principio a fin con nuestros propios recursos, dirigida por los arquitectos técnico y funcional.

Pruebas externas: la misma ejecución, pero esta vez junto con el cliente. En este punto el cliente puede solicitar ajustes.

Pruebas de aceptación: preparamos casos de prueba paso a paso y el cliente recorre por su cuenta todo el proceso para comprobar cómo funciona el sistema.

Según los resultados, corregimos los errores, preparamos manuales de usuario y capacitamos a los empleados.

Etapa 4: Explotación productiva.

Siempre acompañamos el proyecto de 3 a 6 meses después de la puesta en marcha, mientras los empleados se acostumbran al sistema.

Lo mejor es presentar al cliente toda la información del proyecto (planes, cronogramas, objetivos y resultados) en forma de presentación. Así el cliente se forma una primera imagen del resultado. Normalmente los clientes no se dan cuenta de que ellos también tendrán que realizar determinados trabajos. Una presentación lo deja claro.

La implementación no puede dejarse solo en manos del equipo del contratista. Al mostrar el alcance del trabajo conjunto, establecemos en la práctica las reglas de las que depende el éxito del proyecto. A continuación se muestra una tabla con la participación de los empleados del cliente.

El patrocinador del proyecto aprueba las decisiones finales, asigna el presupuesto y recibe el proyecto en su conjunto.

El director de proyecto es el administrador de todo el proyecto. Por ejemplo, el proveedor no tiene autoridad dentro de la empresa del cliente, por lo que se necesita un director de proyecto interno que pueda exigir la disciplina necesaria a sus subordinados.

Los usuarios clave son los responsables de las áreas principales en las que implementamos el sistema. Suelen ser jefes de departamento. Por ejemplo, si implementamos el módulo de finanzas, se trata del director financiero (CFO), y así sucesivamente.

Experto en el sistema desde el que se migra. Es un especialista técnico que prepara los datos del sistema actual para su migración al nuevo.

Especialistas de TI que trabajan con sistemas externos, otorgan los accesos necesarios, proporcionan herramientas internas y realizan los trabajos de servidor requeridos.

Durante la implementación siempre debemos respetar el cronograma y el presupuesto. Sin embargo, la gente suele querer tomar su antiguo sistema, personalizado a lo largo de muchos años, y trasladarlo íntegramente al nuevo, añadiendo de paso nuevos requisitos; es decir, tomar 1C y convertirlo en SAP. Pero seamos realistas: no se puede lograr en seis meses o un año lo que llevó muchos años y presupuestos enormes construir. En esos casos, los costos de personalización superan entre 3 y 4 veces el presupuesto.

Entonces, ¿cómo decidir qué hacer para ajustarse al presupuesto?

Así es como resolvemos este conflicto.

Proponemos clasificar todos los procesos de negocio por su criticidad.

• Alta: procesos sin los cuales la empresa «se paraliza» y no puede operar.
• Media: procesos cuya ausencia ralentiza el trabajo.
• Baja: peticiones deseables, funciones de comodidad y mejoras opcionales.

El presupuesto suele cubrir los procesos de prioridad alta y parte de los de prioridad media. Los de criticidad baja se aplazan para el desarrollo posterior del sistema.

Nuestra experiencia demuestra que es posible completar la implementación a tiempo y dentro del presupuesto previsto entregando los elementos de prioridad alta y media. No obstante, en la puesta en marcha normalmente solo están implementados los de criticidad alta. Solo después de la puesta en marcha se sigue perfeccionando el sistema, durante un año, dos o incluso 10 años.

Si se intenta hacerlo todo a la vez, el proyecto se atascará y no cumpliremos ni el cronograma ni el presupuesto.

Por eso:

1. implementamos primero los elementos de prioridad alta;
2. terminamos los de prioridad media durante la explotación productiva;
3. después seguimos perfeccionando el sistema durante años, según sea necesario.

Este enfoque por fases ofrece las mejores posibilidades de lograr el resultado deseado.

Nuestros diez años de experiencia en TI nos han permitido desarrollar una metodología que responde a las preguntas clave del proyecto: cómo implementar la automatización en plazo y dentro del presupuesto, con una personalización mínima y preservando los procesos de negocio críticos y la eficiencia.

Casos de éxito de ERP