Cambio y Adopción
El go-live es donde empieza la adopción, no donde termina.
Diseño las rutinas, los responsables, la capacitación y los mecanismos de feedback que convierten un nuevo sistema comercial en la forma en que la organización trabaja de verdad.
Cinco fases con el go-live dentro, no al final. Se pueden leer como un plan de proyecto —donde el trabajo se detiene en el go-live— o como un diseño de adopción, en el que el sistema pasa a usarse, a ganarse la confianza, a gestionar el negocio desde él y a mejorar.
Adoptar
Las revisiones de gestión funcionan desde el sistema; los puentes temporales se congelan; los atajos se ven.
- Responsable
- Responsable de negocio y mandos directos
- Señal de que funciona
- Revisiones con evidencia del sistema; los atajos disminuyen
- Si se omite esta fase
- El sistema está en producción; el negocio sigue funcionando en otra parte
La formación explica el sistema. La adopción cambia cómo opera el negocio.
La adopción es el paso de un modelo operativo diseñado a un hábito de trabajo real. Por eso se diseña junto con el proceso, los roles y las rutinas de gestión, no se añade después.
Número de accesosAsistencia a formacionesUn email de lanzamientoCampos obligatoriosPedir a los usuarios que dejen de quejarseObligar a las personas a usar un sistema que no les da nada
- Valor por rolCada rol recibe algo del proceso al que se le pide alimentar.
- Comportamiento de gestiónLos responsables revisan, deciden y hacen seguimiento desde el sistema.
- Cumplimiento del procesoEl trabajo avanza por los estados y decisiones previstos.
- Racionalización de herramientasLos trackers paralelos se clasifican, se sustituyen y se retiran en una fecha.
- Responsabilidad claraAlguien es responsable de la adopción, del proceso y de la plataforma tras el go-live.
- Datos útilesUn dato registrado es un dato usado: por quien lo introduce o por una decisión concreta.
- Fricción medibleLos workarounds se registran, se clasifican y tienen responsable.
- RefuerzoLas revisiones, el reconocimiento y los objetivos premian el comportamiento diseñado.
- MejoraLo que cuesta a los usuarios cambia el diseño, release a release.
- 01Las personas adoptan lo que sus responsables revisan.
El sistema que la gente usa es el sistema desde el que la dirección gestiona el negocio.
Cadencia de gestión - 02Una hoja de cálculo paralela suele ser una señal, no solo un problema de disciplina.
Averigua qué hace antes de decidir cuándo deja de usarse.
Herramientas paralelas - 03Acceder no es adoptar.
Mide si el trabajo y las decisiones pasan por el proceso.
Medición de la adopción - 04Los workarounds repetidos son señales de arquitectura.
La fricción es feedback de diseño antes que un problema de disciplina.
Ciclo de fricción
Del modelo diseñado al hábito de trabajo.
Nueve movimientos que tratan la adopción como trabajo de diseño. Los cuatro primeros ocurren antes del go-live y deciden si merece la pena seguir el nuevo proceso; los tres últimos deciden si sigue mejorando cuando el equipo del proyecto ya se ha ido.
01Entender el rol
¿Qué necesita conseguir realmente este rol?
Partir de la semana de la persona, no de las pantallas del sistema.
- Objetivos
- Decisiones
- Herramientas actuales
- Atajos
- Dificultades
- Incentivos
Un atajo del que la gente depende es un requisito que nadie escribió
Entender el rol
¿Qué necesita conseguir realmente este rol?
Partir de la semana de la persona, no de las pantallas del sistema.
- Objetivos
- Decisiones
- Herramientas actuales
- Atajos
- Dificultades
- Incentivos
Perfil del rolUn atajo del que la gente depende es un requisito que nadie escribió
Definir el valor para el rol
¿Qué le aporta el nuevo proceso a esta persona?
Valor expresado desde el lado del usuario, no del reporting.
- Menos coordinación manual
- Contexto de cliente más claro
- Decisiones más rápidas
- Menos tareas duplicadas
- Mejor priorización
Mapa de valor por rolSi el nuevo proceso solo aporta valor al reporting, los usuarios lo vivirán como administración
Eliminar trabajo innecesario
¿Qué campos, pasos y actividades duplicadas pueden desaparecer?
La adopción mejora cuando el diseño pide menos.
- Datos que ya existen
- Valores derivables
- Automatización
- Tareas obsoletas
- Reporting paralelo
Backlog de reducción de fricciónUn dato obligatorio no garantiza un buen dato
Alinear las rutinas de gestión
¿Qué reuniones y decisiones deben funcionar desde el nuevo sistema?
La gente adopta lo que su responsable revisa.
- Revisión del pipeline
- Forecast
- Revisión del rendimiento de clientes
- Revisión de recuperación
Ritmo de gestiónSi la reunión de gestión ocurre fuera del sistema, el sistema operativo real está fuera del sistema
Capacitar sobre trabajo real
¿Qué debe poder hacer cada rol el primer día?
Tarea real + decisión real + proceso real—no pantallas.
- El escenario
- La decisión
- La acción
- Dónde ocurre en el sistema
- Qué pasa después
Plan de capacitación por rolLa formación no puede reparar incentivos que hacen irracional usar el sistema
Retirar herramientas paralelas
¿Qué comportamiento antiguo debe desaparecer?
Cada herramienta paralela se clasifica antes de retirarla.
- Hojas de cálculo
- Trackers duplicados
- CRM en la sombra
- Ficheros de reporting local
- Hojas de aprobación manuales
Plan de retirada de herramientasUna hoja de cálculo paralela suele ser una señal, no solo un problema de disciplina
Medir la adopción real
¿Se está siguiendo realmente el proceso?
Iniciar sesión no es adoptar.
- Procesos completados
- Cumplimiento por etapa
- Decisiones requeridas
- Uso por la dirección
- Datos usados para decidir
- Comportamiento de elusión
Cuadro de mando de adopciónUna señal sin responsable ni acción es solo un gráfico
Capturar la fricción
¿Dónde hace el diseño que el trabajo sea innecesariamente difícil?
Los atajos repetidos son señales de arquitectura.
- Pasos manuales repetidos
- Atajos
- Campos sin usar
- Aprobaciones lentas
- Estados confusos
- Automatización que falta
Registro de friccionesUna desviación es feedback de diseño antes que un problema de disciplina
Mejorar
¿Quién es responsable de los cambios tras el go-live?
El go-live es un traspaso, no un final.
- Responsable de proceso y de producto
- Backlog
- Ritmo de releases
- Gobierno
- Revisión
Ciclo de mejora continuaCuando se cierra el proyecto, la responsabilidad no debe cerrarse con él
El sistema está en marcha. El negocio funciona en otra parte.
Rara vez son problemas de formación. Debajo hay un rol que no recibe nada a cambio, un responsable que revisa desde un fichero o un proceso sin responsable tras el go-live.
El CRM está técnicamente en producción, pero los responsables siguen revisando el negocio con hojas de cálculo.
Lo que suele faltarUna cadencia de gestión que funcione desde el sistemaLos comerciales registran datos que nadie usa, ni siquiera ellos.
Lo que suele faltarValor por rol y una decisión concreta por campoLa formación explica pantallas en lugar de las decisiones que toman las personas.
Lo que suele faltarCapacitación construida sobre escenarios realesLos campos obligatorios se llenan de valores de relleno.
Lo que suele faltarMenos campos, derivados y condicionales, usados donde se registranLos trackers locales recrean en silencio el antiguo modelo operativo.
Lo que suele faltarUn inventario clasificado de herramientas paralelas con fechas de retiradaLa adopción se reporta como número de accesos.
Lo que suele faltarSeñales de cumplimiento del proceso y de uso en la gestiónLos usuarios crean workarounds porque el proceso es demasiado lento.
Lo que suele faltarUn registro de fricción que alimente un backlog gobernadoLa responsabilidad termina cuando cierra el proyecto.
Lo que suele faltarResponsables de proceso, plataforma y adopción con nombre tras el go-live
Entregables que convierten un modelo nuevo en la forma normal de trabajar.
Cada uno sustituye una suposición —«ya lo usarán cuando estén formados»— por algo que se puede asignar a un responsable y comprobar.
- Mapa de valor por rolQué aporta, recibe y decide cada rol, y qué no debería tener que hacer
- Modelo de roles y responsablesQuién usa, gestiona, es responsable y da soporte al nuevo proceso
- Hipótesis de adopciónQué comportamiento debe cambiar, en quién y cómo lo veremos
- Capacitación por rolEscenario → decisión → acción → sistema → resultado, por rol
- Modelo de referentes localesContexto local y feedback, sin asumir la responsabilidad formal
- Cadencia de gestiónQué revisiones funcionan desde el sistema y con qué evidencia
- Plan de retirada de herramientasCada herramienta paralela clasificada, congelada y retirada en una fecha
- Plan de despliegueOleadas ordenadas por preparación, no solo por calendario
- Modelo de cumplimientoQué estados, decisiones y evidencias exige el proceso
- Cuadro de mando de adopciónDel acceso a la adopción del modelo operativo, cada señal con responsable
- Registro de fricciónFricción, causa, tipo y acción, como feedback de diseño
- Backlog posterior al go-liveCambios priorizados con un responsable y una release
- Modelo de gobiernoQuién puede cambiar el proceso, la plataforma y las reglas
- Ciclo de mejora continuaUsar → medir → fricción → priorizar → cambiar → liberar
- Cadencia de revisión de la adopciónQuién revisa las señales, cuándo y qué decide
Si un rol solo aporta, los datos se quedan obsoletos.
Seis roles, cuatro preguntas cada uno. Cambia al diseño orientado al reporting para ver lo que la mayoría de despliegues pide realmente a las personas.
Comercial
- Aporta
- Estado de la oportunidad, siguiente paso, contexto del cliente
- Recibe
- Una vista completa de la cuenta, trabajo priorizado, menos coordinación manual
- Decide
- La siguiente acción comercial
- No debería tener que
- Volver a teclear a mano datos del ERP
Lo que este rol aporta le vuelve como algo que usa. Por eso los datos se mantienen al día.
Las personas adoptan el modelo operativo que sus responsables usan de verdad.
Si la reunión de gestión ocurre fuera del sistema, el sistema operativo real está fuera del sistema. La misma revisión, de dos maneras:
- Datos del CRMActuales, con responsable, visibles para todos en la revisión
- Revisión de gestiónSobre la vista de pipeline compartida
- DecisiónRegistrada donde está el trabajo
- AcciónUna tarea con responsable y fecha
- Actualización del CRMLa revisión de la semana que viene parte de las decisiones de esta
Cada decisión deja evidencia en el sistema, así que actualizarlo merece la pena.
Rutinas que deben funcionar desde el sistema
| Rutina | La pregunta | Evidencia en el sistema | Qué cambia cuando se traslada al sistema |
|---|---|---|---|
| Revisión semanal de pipeline | ¿Qué oportunidades necesitan ayuda esta semana? | Etapa, siguiente paso, antigüedad en la etapa, última actividad | Las oportunidades estancadas y los siguientes pasos que faltan se ven antes de la reunión |
| Reunión de forecast | ¿Qué vamos a cerrar y qué lo cambiaría? | Categorías de forecast, ajustes con motivo, cobertura | Los ajustes quedan registrados, así que el criterio se puede revisar |
| Revisión de resultados por cliente | ¿Qué clientes crecen, caen o están en silencio? | Segmentos, objetivo frente a real, actividad reciente | Los planes de cuenta y las acciones de recuperación viven junto a la cuenta |
| Revisión de recuperación | ¿Está funcionando cada plan de recuperación? | Acciones de recuperación, responsables, fechas límite, resultado | Un plan sin siguiente acción queda a la vista como tal |
La capacitación sigue el trabajo real, no las pantallas.
Preparación para el primer día por rol, ensayada con los escenarios que cada persona encontrará el lunes.
- “Haz clic en Cuentas.”
- “Haz clic en Nuevo.”
- “Completa estos campos.”
- “Haz clic en Guardar.”
Explica el sistema. Nadie sale sabiendo qué tiene que decidir.
«Un cliente pide una oferta. ¿Qué haces? ¿Qué decisión estás tomando? ¿Qué información necesitas? ¿Qué pasa después?»
Tarea real + decisión real + proceso real. Las pantallas aparecen donde el trabajo las necesita.
Un cliente pide una oferta de una nueva línea de producto.
¿Es una oportunidad nueva o parte de una existente? ¿Está el precio dentro de mis atribuciones?
Crear o actualizar la oportunidad y solicitar la oferta.
Oportunidad → solicitud de oferta; la comprobación de precio se ejecuta al enviar.
La oferta llega al cliente, o la aprobación va a la persona adecuada con el motivo.
Una hoja de cálculo paralela suele ser una señal, no solo un problema de disciplina.
Retirar una herramienta empieza por averiguar qué hace. Algunas revelan una capacidad que falta; otras son análisis legítimo; otras, costumbre. Cada una recibe un veredicto y una fecha.
- CRM
- Pipeline en hoja de cálculo
- Tracker local
- Forecast manual
El CRM es uno de cuatro sitios donde podría estar la verdad.
- CRM
- Un puente temporal y controlado
Un solo puente, con responsable y fecha de congelación.
- CRM
- Herramientas analíticas gobernadas
El análisis continúa, sobre datos gobernados, no sobre copias.
- 01Descubrir
Localizar cada tracker, fichero y sistema paralelo del que depende la gente, y quién lo usa y para qué.
- 02Clasificar
Decidir por herramienta: necesaria temporalmente, sustituida, integrada o retirada.
- 03Migrar
Trasladar el valor legítimo —vistas, campos, rutinas— al modelo operativo.
- 04Congelar
La herramienta antigua pasa a solo lectura en una fecha acordada; las excepciones requieren un aprobador.
- 05Retirar
Archivarla, retirar los accesos y vigilar las señales de atajo.
Clasificar antes de retirar
Hoja semanal de pipeline
- Para qué sirve
- La revisión de los lunes del responsable
- Qué revela
- Ninguna vista del CRM sostiene la cadencia de revisión
- Veredicto
- Sustituida
- Acción
- Crear la vista de revisión; hacer dos revisiones en paralelo; congelar el fichero
- Responsable
- Responsable comercial
- Necesaria temporalmente
- Sustituida
- Integrada
- Retirada
Acceder no es adoptar. Mide si el proceso se sigue.
Seis niveles, del acceso a la mejora. La mayoría de informes de adopción se queda en el segundo. Selecciona un nivel para ver qué muestra y qué se le escapa.
Adopción en la gestión
¿Se toman las decisiones con evidencia del sistema?
- Señal
- Revisiones desde el sistema, decisiones registradas en los propios registros
- Si dejas de medir aquí
- Los responsables pueden seguir guardando una copia privada
Señales de adopción
Cada señal tiene un responsable, un significado y una acción. Sin umbrales universales: lo que es bueno depende del proceso y de la unidad.
| Señal | Nivel | Responsable | Significado | Acción |
|---|---|---|---|---|
| Oportunidades con una siguiente acción válida | N2 · Cumplimiento del proceso | Responsable comercial | Las oportunidades se trabajan, no solo se registran | Revisar en la revisión semanal de pipeline las que no tienen siguiente acción |
| Antigüedad en la etapa | N2 · Cumplimiento del proceso | Responsable comercial | Dónde espera el trabajo, o dónde no se actualizan las etapas | Ayudar, escalar o recualificar las oportunidades estancadas |
| Registros que se saltan el ciclo de vida previsto | N2 · Cumplimiento del proceso | Responsable del proceso | El proceso se omite o no encaja | Clasificar el atajo: fricción de diseño o disciplina |
| Revisiones de gestión hechas desde el CRM | N3 · Adopción en la gestión | Responsable de negocio | El sistema operativo real está dentro del sistema | Trasladar la siguiente rutina; retirar su hoja de cálculo |
| Uso de hojas de cálculo paralelas | N4 · Adopción del modelo operativo | Responsable de adopción | Falta una capacidad o persiste una costumbre | Clasificar la herramienta; congelarla o cubrir el hueco |
| Registros sin responsable | N2 · Cumplimiento del proceso | Responsable del dato | Trabajo sobre el que nadie va a actuar | Asignar por regla; corregir la regla, no solo el registro |
| Tareas completadas | N3 · Adopción en la gestión | Mando directo | Las acciones decididas se llevan a cabo | Revisar las acciones vencidas en la siguiente revisión |
| Volumen de excepciones | N2 · Cumplimiento del proceso | Responsable del proceso | Dónde el diseño y la realidad no coinciden | Llevar las excepciones recurrentes al registro de fricción |
| Estados del proceso reabiertos | N2 · Cumplimiento del proceso | Responsable del proceso | Traspasos que fallan al primer intento | Corregir los criterios de entrada de la etapa receptora |
| Datos usados en decisiones posteriores | N3 · Adopción en la gestión | Responsable del dato | Campos que se ganan su sitio | Eliminar o derivar los campos que ninguna decisión usa |
Los workarounds repetidos son señales de arquitectura.
La fricción se registra con su causa y su tipo, y se entrega al responsable de lo que la provoca, para que la elimine la próxima release y no el próximo recordatorio.
- “Los usuarios vuelven a teclear la dirección del cliente.”
Los datos del ERP no están disponibles donde se trabaja.
Sistema / integración
Mostrar los datos de referencia allí donde ocurre el trabajo.
- “Los responsables exportan el pipeline cada lunes.”
Ninguna vista del CRM sostiene la cadencia de revisión.
UX / modelo operativo
Diseñar un espacio de revisión para esa rutina.
- “Los descuentos pequeños esperan días a ser aprobados.”
Un único umbral para cualquier tamaño de operación.
Proceso
Escalonar la aprobación por importe; aprobar por regla los pequeños.
- “La mayoría de registros lleva un valor de relleno en un campo obligatorio.”
El valor no se conoce en esa etapa.
Datos
Hacer el campo condicional a la etapa en la que se conoce.
- “Los comerciales registran actividades en bloque los viernes por la tarde.”
El reconocimiento cuenta actividades, no resultados.
Política / incentivos
Revisar qué se reconoce; dejar de contar actividades.
El ciclo de mejora continua
- Tickets de soporte
- Señales de uso
- Excepciones del proceso
- Feedback de los responsables
- Medidas de adopción
- Cambios en el negocio
- 01Usar
- 02Medir
- 03Fricción
- 04Priorizar
- 05Cambiar
- 06Liberar
Usar
Una sola lista, priorizada por el responsable del proceso y liberada con una cadencia fija.
Desplegar según la preparación, no solo según el calendario.
Siete factores deciden si una unidad hace de piloto, se prepara o espera. Selecciona una unidad: el resultado se deriva de su valoración.
Equipo implicado; los datos necesitan limpieza y hay una variación local sin decidir.
- Preparación del procesoPreparada
- Preparación de los datosParcialmente preparada
- Patrocinio de la direcciónPreparada
- Preparación de los usuariosParcialmente preparada
- Variación localParcialmente preparada
- Preparación de la integraciónPreparada
- Capacidad de soportePreparada
Preparación específica de los factores parciales y, después, despliegue
El patrón de despliegue global
Un despliegue global es estandarización más preparación local más aprendizaje controlado: el núcleo se diseña una vez, se aprende de él y se ajusta entre oleadas.
Estandarización+Preparación local+Aprendizaje controlado
- 01Diseño del núcleo
Ciclo de vida, roles y rutinas diseñados una sola vez
Estandarización - 02Piloto
Una unidad preparada, con el equipo de proyecto presente
Aprendizaje controlado - 03Aprender
La fricción y las señales del piloto cambian el núcleo
Aprendizaje controlado - 04Adaptar la variación controlada
Solo diferencias locales registradas
Estandarización - 05Desplegar por unidad
Oleadas ordenadas por preparación
Preparación local - 06Estabilizar
Primeras semanas con soporte local, puentes congelados
Preparación local - 07Medir
Adopción comparada por nivel, leída en su contexto local
Aprendizaje controlado - 08Mejorar
Un backlog gobernado y compartido entre unidades
Estandarización
Cómo se gobierna la variación local: Modelo Operativo Digital
¿Quién es responsable del sistema cuando acaba el proyecto?
Cada responsabilidad que tenía el proyecto necesita un responsable operativo antes del go-live; si no, la curva de adopción se aplana el mes en que el equipo se va.
Equipo de proyecto→Responsables operativos con nombre
- Responsable del proceso
Es responsable de El proceso de extremo a extremo, sus estados, reglas y excepciones
No Cómo los implementa la plataforma
- Responsable de la plataforma
Es responsable de Configuración, releases, soporte y salud técnica
No Las reglas de negocio y las prioridades
- Responsable del dato
Es responsable de Definiciones y calidad en origen, por concepto
No Los informes construidos encima
- Responsable de adopción
Es responsable de Las señales de adopción, la capacitación y el registro de fricción
No Las correcciones: son del responsable de lo que provoca la fricción
- Responsable de negocio
Es responsable de El resultado, la cadencia de gestión y el refuerzo
No Las decisiones de configuración
- Referente local
Es responsable de Feedback local, soporte de primer nivel, contexto e interpretación
No Decisiones de proceso o de sistema: esas se escalan
Referente local ≠ responsable del proceso ≠ responsable del sistema
Un referente local no es quien asistió a más formación. Los referentes aportan contexto local y feedback; la responsabilidad formal sigue en manos de los responsables del proceso y de la plataforma.
- Referente local
- Feedback local
- Soporte de primer nivel
- Interpretación del proceso en contexto
- Escalado
- Revisión de las señales de adopción locales
No hace Decide el proceso ni cambia el sistema
- Responsable del proceso
- Es responsable del diseño del proceso
- Decide cambios y excepciones
- Es responsable de los KPI del proceso
No hace Configura la plataforma
- Responsable del sistema
- Es responsable de la configuración y las releases
- Implementa los cambios aprobados
- Mantiene sana la plataforma
No hace Decide las reglas de negocio
Seis despliegues, una pregunta: ¿arraiga la nueva forma de trabajar?
Escenarios B2B globales sintéticos. Dos casos existentes se leen aquí desde la óptica de la adopción; cuatro casos nuevos abordan los trackers paralelos, un despliegue en varias filiales, los campos obligatorios y los responsables tras el go-live.
- Caso 01Caso seleccionadoInventario y retirada de herramientas en la sombra
De los trackers paralelos al CRM en un equipo comercial
El equipo tiene CRM, pero la gestión diaria sigue dependiendo de trackers en hojas de cálculo, ficheros locales de clientes, forecasts fuera del sistema y reporting manual.
¿Qué hace cada tracker que el CRM no hace, y qué tiene que trasladarse, cambiar o desaparecer antes de que el equipo trabaje desde un solo sistema?
CRMHojas de cálculo (en retirada)Herramienta analíticaHerramientas de colaboraciónRevenue OperationsModelo Operativo Digital - Caso 02Preparación, oleadas y referentes locales
Diseñar la adopción de un CRM desplegado en varias filiales
Un CRM global se despliega en filiales con distinta madurez, roles, procesos históricos, calidad de datos, herramientas locales y hábitos de gestión.
¿Cómo equilibrar el estándar global con la preparación local, para que cada filial adopte el mismo modelo sin que el despliegue ignore de dónde parte?
CRM globalERP localesTrackers locales (en retirada)Plataforma de datosModelo Operativo DigitalArquitectura de Sistemas y CRM - Caso 03Caso de modelo operativo · óptica de adopciónRutinas trasladadas, herramientas retiradas
De herramienta CRM a plataforma operativa comercial
El CRM está implantado, pero los mandos llevan el negocio desde hojas de cálculo y cada equipo interpreta las etapas a su manera.
¿Qué rutinas, responsabilidades y herramientas paralelas deciden si el negocio opera a través del CRM o a su alrededor?
CRMHojas de cálculo (en retirada)Plataforma de datosHerramientas de colaboraciónModelo Operativo DigitalRevenue Operations - Caso 04Caso de RevOps · óptica de adopciónAdopción en la gestión
Llevar la cadencia de gestión comercial desde el CRM
A los comerciales se les pide mantener el CRM al día, pero todas las reuniones de gestión se hacen desde hojas de cálculo—así que el sistema se mantiene para nadie.
¿Qué foros de gestión deben funcionar desde el CRM, y cómo sabemos que lo hacen?
CRMPlataforma de datosHerramientas de colaboraciónRevenue OperationsModelo Operativo Digital - Caso 05Auditoría de campos y valor por rol
De los campos obligatorios a datos que la gente usa
Para forzar la adopción, se hicieron obligatorios la mayoría de los campos de la oportunidad. Los registros están completos y llenos de valores de relleno en los que nadie confía.
¿Qué datos necesita de verdad cada decisión, y cómo obtenerlos sin pedir a la gente que teclee lo que no sabe?
CRMERPPlataforma de datosArquitectura de ProcesosDatos e Integraciones - Caso 06Traspaso de responsabilidades y ciclo de fricción
Mantener la adopción con responsable cuando el equipo de proyecto se va
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?
CRMService deskBacklog de cambiosPlataforma de datosModelo Operativo DigitalAutomatización
Toda petición de adopción tiene una segunda capa.
La petición visible es donde empieza el diseño, no donde termina.
“Los usuarios necesitan formación antes del go-live.”
Organizar sesiones pantalla a pantalla para todos los usuarios.
4 de 5 preguntas a la vista
Tareas del primer día por rol, no un recorrido por todas las pantallas.
La adopción no es una fase posterior al diseño. Todas las capacidades le dan forma.
Cambio y Adopción
- Modelo Operativo Digital
El modelo operativo define roles, decisiones y responsabilidades; la adopción los convierte en hábitos de trabajo.
- Arquitectura de Procesos
Un proceso rediseñado solo existe cuando la gente trabaja así; por eso el valor por rol se diseña con el proceso.
- Revenue Operations
Las rutinas de gestión son donde la adopción se gana o se pierde; la cadencia comercial funciona desde el sistema.
- Arquitectura de Sistemas y CRM
Una plataforma que encaja con cómo vende la gente se adopta; una que replica el organigrama se esquiva.
- Datos e Integraciones
Volver a teclear datos es fricción; los datos de referencia en el contexto de trabajo la eliminan.
- Automatización
Eliminar pasos manuales forma parte del diseño de la adopción: la automatización quita trabajo antes de que la formación lo explique.
Decisiones de arquitectura
Casos y artículos
La adopción no es formación, comunicación ni número de accesos. Es la transición diseñada del modelo operativo al hábito de trabajo:
- Valor por rol
- Rutinas de gestión
- Capacitación
- Retirada de herramientas
- Medición
- Fricción
- Responsables
- Mejora
Diseñar la adopción dentro de la solución, para que el nuevo modelo se convierta en la forma normal de trabajar.
El go-live es donde empieza la adopción, no donde termina.
En producción en plazo, ¿y todavía funcionando con hojas de cálculo?
- ¿Qué revisión de gestión sigue funcionando fuera del sistema?
- ¿Qué recibe cada rol a cambio de lo que registra?
- ¿Quién es responsable del proceso ahora que el proyecto ha terminado?