Mantener la adopción con responsable cuando el equipo de proyecto se va
Un caso de adopción ficticio: el proyecto cerró en plazo; la curva de adopción se aplanó un mes después.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Responsables operativos con nombre para el proceso, la plataforma, los datos, la adopción y el resultado de negocio; un registro de fricción que alimenta un único backlog gobernado; una cadencia de releases; y una revisión mensual de la adopción que decide.
El equipo de proyecto se disolvió en el go-live. Los tickets de soporte se acumulan, los workarounds se extienden y nadie responde de si el nuevo proceso se sigue o se mejora.
¿Quién es responsable de la adopción, del proceso y de la plataforma cuando acaba el proyecto, y cómo cambia el diseño lo que cuesta a los usuarios?
Traspasar cada responsabilidad del proyecto a un responsable operativo con nombre antes del go-live, y tratar la fricción recurrente como entrada de diseño con responsable y release, no como volumen de soporte.
Un despliegue de CRM terminó en plazo y el equipo de proyecto pasó a otros trabajos. Tres meses después, el service desk atiende las peticiones una a una, los usuarios han creado workarounds para las aprobaciones lentas y los datos que faltan, los responsables vuelven poco a poco a las exportaciones y las peticiones de cambio llegan al equipo de plataforma sin nadie que las priorice.
02La realidad · situación actual
Cómo se trabaja realmente hoy.
- Todos los roles del proyecto desaparecieron en el go-live
- Tickets de soporte atendidos uno a uno, nunca analizados
- Workarounds que se extienden sin que nadie los registre
- El equipo de plataforma decide las prioridades por defecto
- La adopción no se revisa desde el informe del go-live
03Enfoque
No la respuesta obvia, sino el enfoque.
Un service desk responde las preguntas de una en una. Sin un responsable que cambie el diseño, la misma fricción vuelve cada semana.
- 01Mapear las responsabilidades del proyecto
Listar lo que hacía el equipo de proyecto y tiene que continuar.
Director del programa - 02Nombrar responsables operativos
Responsables de proceso, plataforma, datos, adopción y negocio, antes del go-live.
Responsable de negocio - 03Abrir el registro de fricción
Tickets recurrentes, workarounds y excepciones, clasificados por tipo.
Responsable de adopción - 04Gobernar el backlog
Un único backlog, priorizado por el responsable del proceso, con una cadencia de releases.
Responsable del proceso - 05Revisar la adopción cada mes
Señales por nivel, con decisiones y responsables.
Responsable de adopción
04Valor por rol
Qué aporta, recibe y decide cada rol.
| Rol | Aporta | Recibe | Decide | No debería tener que |
|---|---|---|---|---|
| Responsable del proceso | Prioridades, decisiones sobre los cambios | Fricción clasificada por tipo y volumen | Qué cambia en el proceso | Leer tickets de soporte en bruto |
| Responsable de la plataforma | Releases, salud técnica | Un backlog priorizado con responsables | Cómo se implementan los cambios | Decidir las prioridades por defecto |
| Responsable de adopción | Señales, capacitación, el registro de fricción | Un foro que decide | Qué se reporta y qué se escala | Asumir correcciones que corresponden a otros responsables |
05Dimensión clave · Traspaso de responsabilidades y ciclo de fricción
De los roles de proyecto a los responsables operativos, y de la fricción al backlog
Cada responsabilidad que tenía el proyecto recibe un responsable operativo y una cadencia. La fricción recurrente se registra con su causa, su tipo y su acción.
- Decisiones de proceso
Autoridad de diseño del proyectoResponsable del procesoRevisión mensual del proceso - Configuración y releases
Equipo de construcción del proyectoResponsable de la plataformaEn cada release - Capacitación y señales de adopción
Responsable del cambio en el proyectoResponsable de adopciónRevisión mensual de la adopción - Definiciones y calidad de los datos
Frente de datos del proyectoResponsable del dato por conceptoForo mensual de datos - Soporte local y feedback
Usuarios clave del proyectoReferentes localesSemanal durante los primeros meses
| Fricción | Causa | Tipo | Acción |
|---|---|---|---|
| Las aprobaciones de descuento esperan días | Un único umbral para cualquier operación | Proceso | Escalonar las aprobaciones por importe |
| La dirección del cliente se vuelve a teclear | Los datos del ERP no se muestran en el CRM | Sistema / integración | Mostrar la dirección de referencia |
| Exportaciones del pipeline los lunes | No hay vista de revisión | UX / modelo operativo | Crear el espacio de revisión |
Esas tres fricciones habían generado la mayoría de los tickets de soporte. Corregirlas hizo más que cualquier recordatorio.
06Señales de adopción
Cómo sabemos que funciona: cada señal con su responsable.
| Señal | Nivel | Responsable | Significado | Acción |
|---|---|---|---|---|
| Fricciones cerradas por una release | N5 · Mejora | Responsable del proceso | El diseño está mejorando | Revisar el impacto de la release en la señal relacionada |
| Categorías de tickets recurrentes | N5 · Mejora | Responsable de adopción | Fricción que el diseño no ha resuelto | Llevarla al registro de fricción con su causa |
| Exportaciones antes de las revisiones de gestión | N3 · Adopción en la gestión | Responsable de negocio | La gestión se está saliendo del sistema | Averiguar qué le falta a la vista |
07Las contrapartidas
Opciones creíbles, evaluadas frente a estas premisas.
Solo service desk
Procesos estables con pocos cambios
Coste: La fricción se atiende, nunca se corrigeMantener indefinidamente el equipo de proyecto
Justo después de un go-live grande
Coste: La responsabilidad sigue siendo temporalResponsables operativos con nombre, registro de fricción y backlog gobernado
Cualquier sistema que deba seguir mejorando
Coste: Responsables con tiempo, un registro y una cadencia de revisión08La segunda capa
Preguntas que cambian el diseño.
Responsabilidad
- ¿Quién es responsable de los cambios tras el go-live?
- ¿Quién es responsable de la adopción, y qué puede decidir?
- ¿Quién es responsable de cada concepto de datos?
Fricción
- ¿Dónde se registran los workarounds recurrentes?
- ¿Quién clasifica la fricción por causa?
- ¿Qué correcciones entran en la siguiente release?
Cadencia
- ¿Qué foro revisa la adopción?
- ¿Con qué frecuencia hay releases?
- ¿Cuándo se revisa el propio diseño?
09Decisiones y entregables
Qué produce el trabajo.
- 01Modelo de traspaso de responsabilidades
- 02Registro de fricción
- 03Backlog gobernado posterior al go-live
- 04Cadencia de releases
- 05Revisión mensual de la adopción