Sustituir un sistema CAFM parece bastante sencillo a primera vista. Elegir una nueva solución, exportar los datos del sistema anterior, importarlos al nuevo y seguir trabajando.

Ojalá una migración fuera así de sencilla.

Un sistema CAFM que lleva diez o quince años en uso contiene mucho más que una serie de registros en una base de datos. Contiene edificios y espacios, activos, contratos y documentos, pero también procesos, responsabilidades, interfaces, información histórica y, con bastante frecuencia, alguna que otra solución provisional que ya nadie recuerda muy bien por qué se introdujo.

Trasladar todo esto de un sistema a otro no es, por tanto, una simple tarea informática. También es una oportunidad para plantearse una pregunta que suele quedar relegada por las exigencias del día a día: ¿realmente queremos seguir trabajando de esta manera?

El éxito de una migración CAFM no se mide por la fidelidad con la que se haya reproducido el sistema anterior en el nuevo. Una migración tiene éxito cuando la organización puede trabajar después de forma más eficiente, con información de mayor calidad y procesos que realmente se ajustan a la forma en que las personas necesitan trabajar.

Sin embargo, en la práctica, hay una serie de errores que se repiten una y otra vez.

Error n.º 1: empezar sin tener claro por qué se cambia de sistema

Error n.º 2: migrarlo todo simplemente porque existe

Error n.º 3: asumir que una exportación contiene todo lo que se ve en el sistema anterior

Error n.º 4: intentar cambiar demasiadas cosas a la vez

Error n.º 5: esperar demasiado para involucrar a los usuarios

La buena noticia es que ninguno de estos errores es inevitable. La mayoría pueden evitarse antes incluso de que el primer conjunto de datos salga del sistema anterior.

Error n.º 1: empezar sin tener claro por qué se cambia de sistema

La primera pregunta en una migración CAFM no debería ser: ¿cómo sacamos los datos?

Debería ser: ¿por qué estamos cambiando de sistema?

Normalmente existe una buena razón. Quizá el software actual ya no se desarrolla o ha dejado de recibir soporte. Tal vez los costes hayan aumentado, falten funcionalidades importantes, los informes ya no respondan a las necesidades, el soporte sea insuficiente o los procesos existentes se hayan vuelto innecesariamente complejos.

Sea cual sea el motivo, debe marcar los siguientes pasos.

Si el sistema actual complica innecesariamente el mantenimiento, la migración debería mejorar ese proceso. Si resulta difícil acceder a la información, la nueva solución debería facilitar su localización y uso. Si los informes periódicos siguen requiriendo varias exportaciones, correcciones manuales y combinar información procedente de distintas fuentes, la migración es una buena oportunidad para preguntarse por qué.

Sin unos objetivos claros, sin embargo, resulta sorprendentemente fácil reproducir lo que ya existe.

Se mantienen las mismas estructuras. Sobreviven los mismos procesos. A veces, incluso las mismas soluciones provisionales encuentran un nuevo hogar.

El sistema es nuevo. Los motivos por los que se sustituyó el anterior siguen ahí.

Cómo evitarlo

Antes de entrar en los detalles de la migración, defina qué debería funcionar realmente mejor después del cambio.

Identifique los puntos débiles de la situación actual, determine qué procesos deben mejorar y acuerde qué requisitos son importantes para el funcionamiento futuro. A continuación, defina cómo comprobará si el cambio ha dado los resultados esperados.

De este modo, el proyecto contará con un punto de referencia claro para las decisiones posteriores.

Error n.º 2: migrarlo todo simplemente porque existe

Hay una idea sorprendentemente persistente en los proyectos de migración: si un dato existe, debe ser importante.

Es comprensible. Al fin y al cabo, alguien lo introdujo, lo mantuvo o lo importó en algún momento. Algún motivo tendría.

Quizá sí. En 2014.

Las bases de datos CAFM crecen con el tiempo. Los edificios cambian, los espacios se reorganizan, los activos se sustituyen, los contratos vencen y las responsabilidades pasan de unas personas a otras. También cambian las convenciones de nomenclatura, y la información puede gestionarse de forma distinta según el departamento o la ubicación. Algunos datos se mantienen cuidadosamente actualizados. Otros siguen existiendo principalmente porque nadie ha tenido nunca un motivo para cuestionarlos.

Y no todos los problemas son visibles al examinar un registro de forma aislada.

Un activo puede figurar como fuera de servicio y, al mismo tiempo, seguir teniendo asignadas tareas de mantenimiento activas. Por separado, ambos registros pueden parecer perfectamente válidos. Pero ¿cuál refleja la situación real? Esto debe aclararse antes de decidir qué información se trasladará al nuevo sistema.

Migrarlo todo simplemente porque está disponible puede parecer la opción más segura. No se pierde nada y no es necesario tomar decisiones difíciles antes de realizar la transferencia. El problema es que el nuevo sistema puede empezar a funcionar arrastrando información obsoleta, contradictoria o innecesaria del anterior.

Por tanto, no toda la información debe recibir el mismo tratamiento. Dependiendo de su relevancia, calidad y utilidad futura, los datos pueden transferirse directamente, depurarse o consolidarse, conservarse en un archivo o dejarse atrás de forma deliberada. En algunos casos, reconstruir un área a partir de una base de datos limpia puede resultar más útil que transferir información obsoleta o incompleta.

¿Qué datos deben migrarse realmente?

Estas no son reglas automáticas. Un «activo en uso» no tiene por qué pasar al nuevo sistema simplemente porque su estado indique que está activo, del mismo modo que un registro antiguo no tiene por qué archivarse automáticamente solo por su antigüedad. También importan su finalidad, su calidad, sus dependencias y el uso que tendrá en el futuro.

Cómo evitarlo

Decida qué información merece formar parte de la migración y en qué estado debe llegar.

Revise qué información sigue siendo relevante, qué registros están obsoletos o incompletos, dónde existen duplicados y qué conjuntos de datos no se han mantenido de forma fiable.

Pregúntese si la información histórica es realmente necesaria para los procesos futuros o si únicamente debe seguir estando accesible por motivos de documentación o cumplimiento normativo.

Transferir correctamente datos de fiabilidad dudosa no hace que sean más fiables. Solo significa que la transferencia ha funcionado.

Error n.º 3: asumir que una exportación contiene todo lo que se ve en el sistema anterior

«Tenemos los datos».

Esa frase tranquiliza menos de lo que parece.

Lo que los usuarios ven en un sistema CAFM consolidado no tiene por qué coincidir con lo que se obtiene al exportar sus datos. La información que aparece en la aplicación puede depender de tablas vinculadas, valores calculados o de la lógica interna del sistema. Una exportación puede contener los registros individuales y, al mismo tiempo, dejar fuera los identificadores y las relaciones que les dan sentido.

Por ejemplo, una puerta cortafuegos puede aparecer en el sistema anterior junto con su ubicación, calendario de inspecciones, proveedor de servicios responsable y último informe de inspección, todo ello accesible desde el mismo registro. Sin embargo, en segundo plano esta información puede almacenarse en tablas distintas o estar conectada mediante referencias internas. Si la exportación contiene los registros individuales pero no esas referencias, tanto la puerta como el documento estarán presentes, pero no habrá una forma fiable de volver a relacionarlos.

Los datos se han extraído. El contexto que los hacía útiles, no.

Y extraer la información es solo la mitad del trabajo.

Incluso una extracción completa debe encajar en el sistema de destino. Los campos, clasificaciones, valores de estado, identificadores y jerarquías pueden estar estructurados de forma diferente. Un valor de origen como «Estado 3» no puede transferirse sin más si no se ha definido qué significa en el sistema de destino. Lo mismo ocurre con las relaciones: saber que dos registros están vinculados no indica automáticamente al nuevo sistema cómo debe representar esa conexión.

Cómo evitarlo

Trabaje desde el principio con una exportación real en lugar de confiar únicamente en lo que se ve en la aplicación.

Compruebe qué identificadores, clasificaciones, asignaciones y relaciones están realmente disponibles fuera del sistema anterior. Aclare el acceso a la base de datos, las opciones de exportación, las interfaces y la documentación técnica antes de que la migración dependa de ellos.

A continuación, defina cómo debe representarse la información extraída en el sistema de destino. El mapeo determina dónde debe ir cada información, mientras que las reglas de transformación establecen cómo deben interpretarse o convertirse los valores. Las relaciones y las excepciones también necesitan reglas claras.

Y pruebe esas reglas antes de realizar la transferencia definitiva.

Empiece con un conjunto de datos representativo, realice la migración y valide el resultado. Por ejemplo, si debe transferirse un conjunto definido de activos técnicos, debería ser posible comprobar qué ha llegado realmente al nuevo sistema y explicar cualquier diferencia.

Si algo no es correcto, corrija los datos de origen o la regla de migración correspondiente en lugar de modificar registros individuales en el sistema de destino. Después, vuelva a ejecutar la migración.

Una corrección que desaparece con la siguiente ejecución de la migración nunca fue realmente una corrección.

Detectar estas limitaciones durante las pruebas le da tiempo para solucionarlas.

Error n.º 4: intentar cambiar demasiadas cosas a la vez

Un nuevo sistema CAFM abre nuevas posibilidades.

Y las posibilidades tienen la curiosa costumbre de convertirse en requisitos del proyecto.

Ya que la organización va a migrar de todos modos, ¿por qué no rediseñar también el mantenimiento? E introducir procesos móviles. Y reconstruir las interfaces. Y reorganizar la gestión de contratos. Y depurar veinte años de datos históricos. Y quizá modificar algunos flujos de trabajo, aprovechando que todo el mundo ya está involucrado.

Todo ello puede tener sentido.

Hacerlo todo al mismo tiempo, quizá no.

Cada tema adicional parece manejable por separado. Pero cuando se acumulan suficientes en una misma fase del proyecto, el «ya que estamos» empieza a generar una cantidad considerable de trabajo.

A medida que aumenta el alcance, también lo hacen las dependencias. Un cambio en un área puede afectar a decisiones que ya se habían tomado en otra. Si, además, los requisitos siguen cambiando, es necesario revisar decisiones, adaptar trabajos ya realizados y la implementación en su conjunto resulta cada vez más difícil de controlar.

Cómo evitarlo

Decida qué es necesario para empezar a trabajar de forma fiable y qué puede incorporarse más adelante.

Las estructuras básicas y los datos esenciales pueden abordarse primero. Los procesos, interfaces y funcionalidades adicionales pueden introducirse después en etapas razonables. Esto no significa necesariamente que el proyecto en su conjunto sea pequeño. Significa que un proyecto grande se vuelve manejable.

Y, sobre todo, permite obtener resultados utilizables desde una fase temprana. Un proceso puede implementarse, probarse, evaluarse y ajustarse antes de abordar el siguiente gran bloque.

Hay una diferencia considerable entre oír que un proyecto avanza y poder utilizar ya sus primeros resultados.

Pero una implementación por fases solo funciona si está claro quién es responsable de tomar cada decisión. Alguien debe decidir sobre los requisitos del negocio. Alguien debe establecer las prioridades. Alguien debe resolver las cuestiones relacionadas con los datos y aprobar los cambios.

Los cargos concretos variarán de una organización a otra. Lo importante es que, cuando haya que tomar una decisión, todo el mundo sepa quién puede tomarla.

Error n.º 5: esperar demasiado para involucrar a los usuarios

Hay una forma muy sencilla de descubrir problemas en un proceso perfectamente diseñado sobre el papel: dárselo a alguien que realmente tenga que utilizarlo.

Quienes trabajan a diario con un sistema CAFM detectan detalles que pueden pasar fácilmente desapercibidos en talleres y diagramas de procesos. Un campo está en el lugar equivocado. Encontrar información importante lleva demasiado tiempo. Un flujo de trabajo que parecía perfectamente lógico durante la planificación resulta innecesariamente complicado en el uso diario.

Si los usuarios no conocen el nuevo sistema hasta poco antes de la puesta en marcha, estos descubrimientos llegan bastante tarde.

Para entonces, los procesos ya están configurados, las decisiones están tomadas y los cambios que tres meses antes habrían sido relativamente sencillos afectan de repente a la formación, la documentación, las pruebas y el calendario del proyecto.

Cómo evitarlo

Involucre a los futuros usuarios con suficiente antelación para que sus comentarios puedan incorporarse realmente al proyecto.

Mostrarles resultados intermedios les permite comprobar cómo funcionan en la práctica las nuevas estructuras y procesos, así como señalar problemas que pueden no resultar evidentes desde una perspectiva puramente técnica.

No necesitan participar en todas las reuniones. Pero sí deberían contar con momentos claramente definidos para aportar sus comentarios a lo largo de la migración. Esto también les permite familiarizarse progresivamente con el nuevo entorno en lugar de encontrárselo por primera vez poco antes de la puesta en marcha.

Una mejor migración empieza con mejores decisiones

Una migración CAFM no debería evaluarse por la cantidad de datos transferidos. Lo importante es que el nuevo sistema empiece a funcionar con información fiable, relaciones coherentes entre los datos y menos problemas heredados.

 

En speedikon FM AG acompañamos a nuestros clientes durante todo el proceso de migración y aplicamos nuestra experiencia a los requisitos, dependencias y condiciones técnicas específicas de cada proyecto. Con speedikon® C, los datos, procesos y la información relevante pueden integrarse en un único entorno de software, creando una base flexible para las operaciones futuras.

¿Está pensando en sustituir su sistema CAFM actual? Póngase en contacto con nuestros expertos para hablar sobre su proyecto de migración.

Más información en nuestro whitepaper

¿Quiere profundizar en el tema? Nuestro whitepaper le guía a través de las principales etapas de un cambio de sistema, desde la definición de los objetivos y la evaluación de los datos existentes hasta el mapeo, las pruebas, la validación y el cutover.

Solicite gratuitamente su ejemplar y descubra qué aspectos conviene tener en cuenta antes, durante y después de la transición.