Transformación de ServiceNow a Jira Service Management
MRI Software emprendió este viaje de ServiceNow a Jira Service Management y consiguió un entorno más simple, eficaz y rentable.
Comparando la migración con la transformación ITSM
Compartir en redes sociales
Comparando la migración con la transformación ITSM: cuando la renovación de plataformas no soluciona los problemas
Zoi Raskou
Publicado el 30 de julio de 2026
Actualizado por última vez en 7 de agosto de 2026
15 min de lectura
Zoi Raskou
Publicado el 30 de julio de 2026
Actualizado por última vez en 7 de agosto de 2026
15 min de lectura
Analizamos por qué una migración sencilla puede reproducir las ineficiencias existentes y cómo un enfoque transformador aporta valor duradero al negocio.
Si estás frustrado con tu plataforma de gestión de servicios, probablemente estés pensando en cambiarla. Quizá los costes de las licencias se hayan vuelto difíciles de justificar. Tal vez el valor prometido de tu CMDB nunca llegó a materializarse por completo. O quizás tus equipos trabajan en torno a la herramienta en lugar de trabajar con ella. Sea cual sea el motivo, la decisión no es solo escoger una nueva plataforma, sino cómo afrontar el cambio en sí mismo.
Esa elección importa más de lo que la mayoría de los líderes creen. Y tomar la decisión equivocada es uno de los errores más caros que una empresa puede cometer.
Por qué el instinto de migrar suele ser insuficiente
Cuando las organizaciones deciden renovar su plataforma de ITSM, el instinto natural es tratarlo como un ejercicio técnico. Mapean sus procesos, encuentran las funciones equivalentes en la nueva herramienta, transfieren los datos, forman a sus equipos y arrancan. Es lo que comúnmente se conoce como migración "lift and shift", el enfoque más habitual en las transiciones de ITSM empresariales.
Es una opción atractiva. La migración parece de menor riesgo. Preserva lo que ya existe, lo que mantiene a los usuarios cómodos y evita la fricción percibida en la gestión del cambio. En teoría, parece un camino sencillo de A a B.
Pero si tu plataforma actual no aporta valor, la tecnología por sí sola no es lo que está frenando a tu organización. Son los procesos, los hábitos arraigados en torno a ella y la falta de alineación organizativa. Migrar esos mismos procesos y hábitos a una nueva herramienta no soluciona nada de eso. Simplemente reproduce tus problemas existentes en un entorno nuevo, además de introducir nuevos problemas imprevistos. Esto puede deberse a diferencias de compatibilidad, de funcionalidad o a disparidades entre las funcionalidades del origen y del destino. Has pagado por una transformación, pero has entregado una copia incompleta o defectuosa.
El resultado es previsible: en seis a doce meses, los equipos vuelven a plantear las mismas quejas. La adopción sigue siendo irregular. Surgen nuevas frustraciones por la novedad de la herramienta y su funcionalidad poco ágil. Los problemas de visibilidad de los datos no desaparecen. Y ahora has invertido un presupuesto importante en un programa que no ha marcado la diferencia. Se podría argumentar que, en conjunto, la experiencia ha sido negativa.
¿Qué implica realmente una transformación ITSM?
Una transformación en la gestión de servicios parte de un supuesto diferente. En lugar de preguntar "¿Cómo podemos replicar lo que tenemos en la nueva herramienta?", debemos plantearnos "¿Cómo sería una buena gestión de servicios para nuestra organización y cómo podemos construirla?”
El enfoque cambia de la tecnología a los resultados, definiendo el futuro modelo operativo, entendiendo cómo deben entregarse los servicios y determinando la experiencia que necesitan la empresa y sus usuarios. Solo entonces las organizaciones deben considerar cómo las herramientas, los procesos y la automatización pueden facilitar esa visión. Al comenzar con los resultados empresariales deseados en lugar de la implementación técnica, las organizaciones evitan recrear ineficiencias existentes en una nueva plataforma y, en su lugar, establecen las bases para un éxito a largo plazo.
Esta distinción puede parecer filosófica, pero tiene consecuencias muy prácticas en la forma en que se estructura el programa, quiénes participan, cuánto tiempo lleva y qué logra en última instancia.
Una transformación considera el cambio de plataforma como una oportunidad para empezar de cero. No para desechar el conocimiento institucional, sino para cuestionar procesos, flujos de trabajo y configuraciones acumuladas durante años y preguntarse si realmente sirven al negocio. Muchas empresas descubren que una proporción significativa de sus personalizaciones en ITSM no responde a una necesidad genuina del negocio, sino a que alguien las construyó hace años para abordar casos extremos o problemas aislados, que con el tiempo se fueron acumulando. Estas personalizaciones implican costes de mantenimiento, dificultan las actualizaciones y ocultan lo que las mejores prácticas de ITIL recomendarían de forma natural.
La transformación aborda la situación actual de las empresas y diseña un camino para llevarlas a donde quieren estar, eliminando la complejidad acumulada. Simplifica, estandariza y moderniza los procesos clave de ITSM, establece un enfoque centrado en el valor para el negocio que evita una personalización excesiva y, de manera crucial, prepara a la organización para aprovechar capacidades como la IA y la automatización, que requieren datos limpios, estructurados y formas de trabajar coherentes para funcionar correctamente.
Nada de eso sucede automáticamente al cambiar de plataforma. Requiere un diseño consciente, la participación activa de todas las partes y un enfoque estructurado para el cambio.
El papel de la gestión del cambio organizacional y por qué no es negociable
De todos los elementos que diferencian una transformación de una migración, el más importante es la Gestión del Cambio Organizacional (GCO). También es el elemento que más se subestima o se omite por completo en los procesos tecnológicos.
La GCO es más que un plan de comunicación o un calendario de formación. Es un esfuerzo sostenido, estructurado y un cambio cultural para acompañar a las personas en la adopción del cambio, comunicando la visión y los beneficios esperados para construir la confianza, la alineación para que la adopción perdure mucho después de la puesta en marcha.
En la práctica, esto implica involucrar a los profesionales adecuados en el momento oportuno. Establecer la realidad del trabajo actual y los resultados deseados en sesiones de descubrimiento con los líderes. Celebrar reuniones de dirección para aprender sobre el conocimiento institucional e integrar elementos de las herramientas y procesos que funcionan. Escuchar a los equipos, sus frustraciones, sus ideas, sus necesidades.
Colaborar antes de tomar decisiones de configuración e incorporar sus comentarios en la solución, creando valor. Finalmente, se trata de crear una solución centrada en lo que la empresa quiere lograr y de definir un camino que garantice el resultado, la longevidad de la solución y su adopción.
Esto es importante porque las plataformas de ITSM afectan a casi todos en una organización. Un cambio en la forma en que se reportan incidentes, en cómo se satisfacen las solicitudes o en cómo se aprueban los cambios tiene implicaciones para todos los equipos, porque todos dependen del soporte de TI. Si las personas adecuadas no han participado en la definición de las nuevas formas de trabajo, las resistirán. Y la resistencia en ITSM no es solo un inconveniente. También conlleva una mala adopción, soluciones alternativas y una degradación en la calidad de los datos que socava el valor de toda la inversión. Además del coste del retraso y del impacto que una mala solución de ITSM puede tener en la productividad general de la organización. La resistencia a la transformación también puede contribuir a costes ocultos más difíciles de medir. Las empresas que dejan pasar la oportunidad de modernizarse e innovar se quedan atrás. La tecnología puede estar en marcha, pero la transformación se ha estancado y la oportunidad se ha perdido.
Las cinco fases de la transformación en la gestión de servicios
Comprender cómo se estructura una transformación bien diseñada ayuda a ilustrar por qué produce resultados diferentes a los de una migración. En esencia, un programa de transformación pasa por cinco fases distintas, cada una de las cuales se complementa con la anterior.
La integración es donde se establece la base. Esta fase se enfoca más en las personas que en la tecnología: identificar quiénes serán afectados por la transformación, generar confianza con una participación estructurada de todos, formar grupos directivos con la autoridad adecuada y alinearse con los objetivos antes de comenzar cualquier diseño de solución. Las organizaciones que se saltan esta fase tendrán una base muy débil. Sin una alineación a nivel directivo, cada decisión de diseño se convierte en una negociación y cada puesta en marcha en una batalla por la adopción.
El diseño sigue un modelo iterativo centrado en el descubrimiento. En lugar de documentar lo que existe y reconstruirlo en otro lugar, cuestiona los procesos actuales mediante sprints de decisiones y talleres estructurados, donde el equipo trabaja en las opciones que definirán el nuevo modelo de gestión de servicios. El objetivo no es preservar la complejidad heredada, sino llegar a una solución orientada a las necesidades reales del negocio, a las buenas prácticas de ITIL y a las capacidades de la plataforma. Esta fase produce requisitos claros para la implementación y un diseño de la solución moldeado por todo el equipo.
La fase de implementación y validación adopta un enfoque iterativo para garantizar que la solución se alinea con los objetivos de la organización. La configuración se construye de forma incremental, se prueba y se refina en función del feedback directo. No se trata de una secuencia lineal de construir y probar; es un ciclo. El feedback informa de los cambios, que se vuelven a probar antes de avanzar. El resultado es una configuración de la plataforma validada por las personas que la usarán, no simplemente aprobada por un gestor de proyectos.
Empoderar a las personas es una fase casi exclusiva de la transformación. En lugar de una formación estándar para el usuario final en la semana antes de la puesta en marcha, esta fase desarrolla una capacidad genuina dentro de la organización mediante habilitación basada en roles, formación en gestión de soluciones y el tipo de confianza que permite a los equipos hacerse cargo de la plataforma en lugar de depender indefinidamente del soporte externo. Esta es la diferencia entre un equipo que puede evolucionar su modelo de gestión de servicios a medida que cambian las necesidades y uno que presenta un ticket de soporte cada vez que necesita ajustar un flujo de trabajo.
Los beneficios cierran el ciclo. Un programa de transformación debe medir el éxito desde el principio: productividad, costes, tasas de adopción, preparación para la IA, seguimiento y reportes en función de esas métricas. Esta fase garantiza que la inversión realizada en la transformación da resultados documentados y visibles que justifiquen el enfoque y sirvan de base para la siguiente etapa.
Cómo definir si necesitas una migración o una transformación
No todos los proyectos de ITSM requieren un programa de transformación completo. Si tus procesos están bien diseñados, tus datos están limpios y solo hay que cambiar la tecnología, puede que lo más adecuado sea una migración más específica. Pero en la práctica, esa descripción se aplica solo a unas pocas organizaciones grandes. También depende de la plataforma a la que te vayas a trasladar. No todas las plataformas son compatibles con una transferencia directa de datos.
Las preguntas de diagnóstico sinceras que hay que plantearse son:
¿Tus procesos actuales son adecuados o has ido acumulando soluciones provisionales y excepciones a lo largo de los años? Si tus equipos suelen salir de la herramienta para realizar su trabajo, por ejemplo, mediante correos electrónicos, hojas de cálculo o canales informales, no solo no funciona la plataforma. Tampoco lo hace el diseño del proceso.
¿Tienen tus equipos de gestión de servicios y de negocio una visión común de qué se considera un buen resultado? Si el departamento de TI y el resto de la organización tienen expectativas diferentes en cuanto a los niveles de servicio, los tiempos de respuesta y los procesos de cumplimiento, un simple cambio de plataforma no bastará para cerrar esa brecha, ya que es algo más que un problema tecnológico.
¿Están de acuerdo tus altos directivos con los objetivos de gestión de servicios, no solo en términos de reducción de costes, sino también en resultados empresariales? Los programas de transformación tienen éxito cuando están impulsados por una intención estratégica. Si el programa es responsabilidad exclusiva de TI y solo tiene como objetivo reducir costes, nunca se liberará el valor para el conjunto de la organización.
Si las respuestas sinceras a estas preguntas revelan problemas que van más allá de la tecnología, una migración no los resolverá. Pero una transformación sí. Vale la pena tener clara esta distinción antes de comprometerse con un enfoque. Si no puedes adoptar una perspectiva imparcial, tal vez merezca la pena solicitar un análisis a un socio de soluciones.
La cuestión no es solo hacia dónde estás enfocado, sino dónde quieres llegar como organización
La decisión de abandonar una plataforma ITSM obsoleta es algo a lo que se enfrentan cada vez más empresas. La combinación de costes crecientes, una obtención de valor limitada y funcionalidades de IA inaccesibles está llevando a los responsables a replantearse si su inversión actual está justificada y muchos llegan a la conclusión de que no.
Pero el valor de la próxima decisión no dependerá de la plataforma que elijas. Dependerá de cómo abordes la transición. Una migración te lleva a una nueva plataforma. Una transformación te lleva a un modelo operativo mejor, más sencillo, más estandarizado, más alineado y preparado para aprovechar las posibilidades de la gestión moderna de servicios.
Si eres un alto directivo que está evaluando sus opciones, la pregunta más importante que debes plantearte no es "¿a qué herramienta debemos pasarnos?", sino "¿qué tipo de organización de gestión de servicios queremos ser y estamos preparados para construirla adecuadamente?".
Escrito por
Responsable de consultoría técnica