Migrar el ERP a la nube: Ocho razones para fracasar

Pasar por alto la dependencia de los datos

La migración de datos es un aspecto crítico para el éxito de la implementación de un ERP, incluso de un ERP SaaS. Y puesto que los datos de la organización procedentes de varios sistemas de TI son interdependientes, pasar por alto los problemas de dependencia de los datos y la integración puede causar fácilmente el fracaso de la implementación.

Un proceso de migración de datos interrumpido puede provocar problemas de dependencia de datos y fallos en cascada, afirma Mike Leone, analista senior de Enterprise Strategy Group.

«Esto es especialmente cierto con flujos de trabajo complejos en varios módulos en los que la mayoría de los datos, si no todos, deben ser migrados a la vez», dijo.

No abordar la resistencia al cambio  

La resistencia al cambio –que las personas expresan de múltiples maneras, como creando soluciones para evitar el nuevo sistema– es una causa común de fracaso en la implantación de un ERP en la nube.

La gente se siente cómoda con los sistemas conocidos, incluso si esos sistemas no les sirven, dijo Leone. Muchos no están dispuestos a perder lo que conocen.

«Con los costos cada vez más controlados, aceptar el hecho de que ya no pueda acceder a una función que estaba acostumbrado a utilizar... puede ser una píldora difícil de tragar», dijo Leone.

Hacer que TI se apropie del proyecto

Una de las principales razones de los fracasos en la migración a la nube de ERP es tratar la migración como si fuera solo un proyecto técnico y pasar por alto los componentes de reingeniería de los procesos empresariales.

«[La implementación de un ERP en la nube] realmente debe ser dirigida por el negocio, con el grupo de TI desempeñando un papel de facilitación», dijo Frank Scavo, un socio de Avasant, una firma de consultoría en El Segundo, California.

No planificar

Otra causa potencial de fracaso es pensar que el despliegue de un ERP en la nube es una fruta fácil de conseguir, por lo que no es necesario planificar. Esto es un error.

«Planifique, planifique, planifique y luego planifique un poco más», dice Ed Featherston, distinguido tecnólogo de Cloud Technology Partners, una consultora con sede en Boston.

Todo proyecto tecnológico necesita un buen diseño y planificación, y eso incluye el ERP SaaS, dijo Featherston. Los sistemas de ERP son complejos, con muchas piezas móviles que hay que manipular.

«Hay que asegurarse de que se han planificado todas las tareas y procesos necesarios», afirma Featherston.

Optar por demasiadas funciones, demasiado pronto 

El síndrome del objeto brillante es un peligro cuando se pasa al ERP en la nube, al igual que en otros ámbitos tecnológicos. Los equipos deben ser moderados a la hora de elegir las funciones iniciales.

«Intentar hervir el océano es otra fuente potencial de problemas», afirma Featherston.

Los equipos de proyecto deben resistir la tentación de reemplazar los sistemas existentes que están funcionando con todas las nuevas características brillantes del ERP SaaS, dijo Featherston. Añadir complejidad a un proceso de migración ya complejo no suele acabar bien.

«Esto no significa que no se puedan aprovechar más funciones en algún momento, pero primero hay que conseguir que la línea de base funcione, y luego hacer un análisis y una planificación adecuados de los siguientes pasos», dijo.

Pensar que un ERP SaaS significa ignorar la seguridad

Los hackers atacan cada vez más las infraestructuras en la nube, por lo que el hecho de que una organización se pase a SaaS no significa que los equipos de TI y de seguridad de la información puedan estar tranquilos.

La seguridad es siempre un riesgo en un proyecto de ERP, incluso con el ERP en la nube, dijo Featherston. Es fundamental comprender el modelo de responsabilidad compartida de la nube. En última instancia, la seguridad sigue siendo responsabilidad de la organización.

«Está la seguridad de la propia implementación del ERP, que recae básicamente en el proveedor, pero usted controla quién tiene acceso a los datos, [lo que] puede proporcionar inadvertidamente un punto de entrada», dijo.

Los equipos de TI que pasan a un modelo de ERP SaaS deben ser siempre conscientes de estos riesgos, especialmente en lo que respecta a los puntos de acceso de los usuarios, dijo Featherston.

«Se trata de superficies de ataque que deben protegerse y supervisarse, y debe haber un plan de respuesta en caso de que se produzca una brecha», dijo.

No planificar los procesos de soporte

Los procesos de soporte que ha desarrollado el departamento de TI interno y los que ofrecerá el proveedor de ERP SaaS no siempre están alineados. Por ejemplo, el paso a la nube está destinado a aligerar la necesidad de soporte interno del ERP. Sin embargo, las organizaciones tendrán que crear procesos que detallen exactamente lo que requiere el modelo de responsabilidad compartida. ¿Se van a replicar en la nube todas las funciones de soporte del sistema local o tendrá que haber alguna persona o personas que se encarguen de las excepciones?

«He visto a muchas organizaciones no tener en cuenta cómo funcionará el servicio de asistencia técnica cuando el ERP migre a la nube», afirma Featherston.

Es especialmente importante entender los procesos exactos para que todos sepan qué hacer y qué parte es responsable si, o cuando, se producen interrupciones.

Un área común: ¿Con qué frecuencia realiza el proveedor de SaaS copias de seguridad de los datos o toma instantáneas en comparación con lo que el departamento de TI interno ha estado haciendo con un sistema local? Las expectativas desalineadas podrían ser un desastre, por ejemplo, si la gente espera un objetivo de punto de recuperación de grano fino que capture los cambios en los datos cada tres o cinco minutos, mientras que el proveedor de la nube asume que una vez por hora o dos veces al día es suficiente.

«Desde el punto de vista de la recuperación, muchas organizaciones terminan con procesos de recuperación de desastres y continuidad del negocio que no necesariamente se alinean con el proveedor de la nube ERP», dijo Featherston. «Las organizaciones necesitan asegurarse de que sus procesos y acuerdos de nivel de servicio están alineados con lo que el proveedor está proporcionando».

Esto garantiza que alguna de las partes interesadas –el proveedor, la TI interna, la seguridad de la información interna u otra parte interesada– no deje nada sin protección.

Conectividad inadecuada

Pasar por alto la conectividad es una vía rápida para el fracaso del ERP en la nube.

Los equipos de compras y de TI pueden olvidar a veces que un sistema en la nube significa que una organización depende mucho más de tener una conexión de red fiable, dijo Scavo.

«Si la red se cae, el sistema se cae, así que asegúrese de pasar algún tiempo evaluando la fiabilidad de su red», dijo Scavo.

En algunos casos, las organizaciones querrán establecer una opción de red secundaria o de reserva.

Comprender las necesidades de ancho de banda es fundamental, dijo Featherston.

«¿Cuántos datos entran y salen, y son las tuberías lo suficientemente grandes?», indicó.

Por último, pero no por ello menos importante, los equipos de TI deben volver a comprobar que el ERP en la nube está recibiendo todos los datos que necesita.

«Algunas conexiones pueden no haber sido consideradas o pensadas y no lo serán hasta que la información necesaria ya no aparezca en un informe», dijo Featherston.