Así resume una empresa del sector hotelero la migración de su equipo de ServiceDesk Plus a Jira Service Management. La transferencia de datos se realizó en dos fases y requirió algunas personalizaciones. Lo más difícil fue conseguir el apoyo de las partes interesadas sin defraudar a los técnicos más experimentados.
Este estudio de caso abarca tanto lo que la empresa migró con Help Desk Migration como la forma en que conservar el historial de incidencias ayudó al equipo a obtener apoyo para la nueva plataforma.
Por qué la empresa migró de ServiceDesk Plus
La empresa se propuso modernizar la prestación de sus servicios de TI e integrarlos en un único Centro de Ayuda. El software de gestión de incidencias existente no era compatible con el marco de gestión de servicios de TI (ITSM) que el equipo tenía en mente.
El equipo de TI tenía los siguientes requisitos para el nuevo sistema:
Enrutamiento de servicios descentralizado
Desvío automatizado de tickets mediante artículos de conocimiento integrados
Estructuras SLA claras
Contexto completo, con tickets vinculados directamente a los usuarios y los activos del sistema
Uno de los criterios provino de los propios empleados de TI: conservar los tickets antiguos. Años de incidencias resueltas proporcionaban el contexto técnico en el que se basaban los técnicos, y no podían generar informes sin datos históricos. Empezar de cero con un servicio de asistencia de TI vacío no era una opción.
Alcance de la migración: Los datos en cifras
Entradas
Usuarios (solicitantes)
Agentes
Empresas
Desafíos durante la migración a Jira Service Management
Lo difícil no fue migrar los boletos, sino transferirlos sin perder lo que los hacía útiles.
-
1
La historia era innegociable.
Los técnicos necesitaban cerrar los tickets para solucionar problemas e informar. Si el equipo perdía datos históricos, podían poner en riesgo el soporte interno del proyecto.
-
2
Las capturas de pantalla estaban integradas en las conversaciones.
Las imágenes insertadas en los hilos de los tickets no se habrían transferido a Jira Service Management de forma predeterminada. Sin ellas, muchos tickets perderían la evidencia que respalda la solución.
-
3
Las firmas de correo electrónico saturaban los hilos de conversación.
Muchas de las imágenes insertadas eran logotipos de firmas de correo electrónico, no capturas de pantalla.
-
4
Las resoluciones no tenían un domicilio directo.
En ServiceeDesk Plus, una resolución es un registro independiente con su propio autor y fecha. Jira Service Management no tiene un campo equivalente, por lo que la solución y el crédito correspondiente corrían el riesgo de perderse.
-
5
Los campos no coincidían.
El equipo tuvo que asignar los campos de origen a los campos de destino, y no todos los campos tenían una contraparte.
-
6
El trabajo no podía parar.
Mientras el equipo transfería los datos históricos, seguían llegando nuevos tickets a ServiceDesk Plus.
-
7
La gente tenía que venir.
El equipo necesitaba el respaldo de las partes interesadas para la nueva plataforma sin defraudar a los técnicos experimentados.
ServicioeDesk Plus frente a Jira Service Management: Mapeo de datos
ServiceDesk Plus y Jira Service Management nombran y estructuran los mismos datos de mesa de ayuda de forma diferente. A continuación, se muestra cómo se cotejaron los registros entre ambas plataformas. Las filas marcadas con (personalizado) corresponden a personalizaciones realizadas para esta migración.
| ServicioeDesk Plus | Jira Service Management | ¿Qué cambia? |
|---|---|---|
| Solicitudes | Entradas | Los tipos y estados de las solicitudes deben existir en el proyecto Jira Service Management y estar mapeados antes de la migración |
| Solicitantes | Clientes | El nombre, el correo electrónico y la organización se transfieren; los números de teléfono y los campos personalizados de contacto no tienen cabida en los clientes Jira Service Management |
| Departamentos | Organizaciones | Los clientes se agrupan por organización en lugar de por departamento |
| Técnicos | Agentes | Los agentes se configuran primero en Jira Service Management ; varios técnicos pueden asignarse a un solo agente |
| Conversaciones y notas | Comentarios públicos y privados | Los comentarios conservan su autor, configuración de privacidad y fecha de creación |
| Resolución | Comentarios del público | JiraEl campo Resolución de personalizada. |
| Imágenes en línea | Archivos adjuntos | Las imágenes insertadas en línea se convirtieron en archivos adjuntos |
| Grupos de apoyo | Etiquetas | Los boletos no tienen campo de grupo, por lo que cada boleto recibió una etiqueta para su grupo personalizado. |
Cómo se personalizó la migración
El equipo de TI realizó primero las pruebas y luego solicitó la personalización. Ejecutaron varias migraciones de demostración gratuitas en tickets de muestra y revisaron cómo se veían los datos en la plataforma de destino.
Cada prueba demostró las deficiencias de la configuración predeterminada y la necesidad de una personalización. Por ello, nuestros ingenieros técnicos desarrollaron cada ajuste que se detalla a continuación como un trabajo personalizado, basado en los datos reales del cliente.
| Opción | Lo que hizo | Por qué el equipo lo necesitaba |
|---|---|---|
| Imágenes en línea en archivos adjuntos | Se han convertido las imágenes incrustadas en las conversaciones de los tickets en archivos adjuntos | De lo contrario, las capturas de pantalla se habrían perdido |
| Resolución para comentarios públicos | Cada resolución se añadió como comentario público, manteniendo al técnico que la redactó como autor y su fecha de envío original | La solución permanece en el hilo del ticket, atribuida al técnico correcto en el momento adecuado |
| Etiqueta por grupo | Se agregó una etiqueta a cada ticket migrado según su grupo en ServiceDesk Plus | El grupo original permanece visible y se puede buscar en Jira Service Management |
| Migración delta | Tickets transferidos creados o actualizados después de la migración completa | El equipo siguió trabajando en ServiceDesk Plus hasta el cambio, sin interrupción en los datos |
Resultados de la migración Jira Service Management
El nuevo Centro de Ayuda de la compañía se puso en marcha con su historial intacto. La migración se realizó en dos etapas: una migración completa y, posteriormente, una migración incremental que incluyó todo lo creado entretanto.
Consejos de expertos de la empresa de hostelería
Por qué el equipo recomienda Help Desk Migration:
"Soporte rápido y competente. La herramienta es fácil de usar y más económica que improvisar tus propios scripts de migración. Además, las pruebas son gratuitas."
Consejos para equipos que planifican una migración:
Deja que la herramienta gestione los datos
Con una herramienta automatizada, la transferencia de datos se convierte en la parte más sencilla del proyecto. El éxito depende de todo lo que la rodea: la planificación, la comunicación y las personas involucradas.
Equilibra tus partes interesadas
Involucre a la combinación adecuada de partes interesadas en el proyecto. Necesita su apoyo para la nueva plataforma, pero no a expensas de los técnicos experimentados que dependen del sistema de tickets anterior.
Prométete a mantener la historia, y luego cúmplela
Conservar el historial de incidencias fue fundamental para la gestión del cambio. Demostró al equipo que una nueva plataforma no les haría perder años de información.
Conserva la historia, gana el equipo
Para este equipo de TI, los tickets históricos eran más que simples datos. Conservarlos era una promesa hecha a los técnicos, y cumplirla ayudó a todo el equipo a aceptar la nueva plataforma.
Tus técnicos te harán la misma pregunta: ¿qué pasa con nuestros tickets antiguos? Respóndela antes de que empiece el proyecto. Prueba una migración de demostración gratuita y muestra a tu equipo sus propios tickets en la nueva plataforma.
