Saltar al contenido

Framework SkilLab

SHIFT Lens: cinco lentes para leer cualquier iniciativa de cambio (Celemi Cayenne)

Stakeholders · Hypothesis · Initiative · Friction · Time

SHIFT Lens (Stakeholders · Hypothesis · Initiative · Friction · Time) es un framework SkilLab para estructurar una iniciativa de cambio organizacional en cinco dimensiones testables antes del roll-out. Cada dimensión exige respuesta explícita del sponsor, y cada lente faltante es fuente previsible de falla posterior.

Diagrama del framework SHIFT Lens: cinco lentes para leer cualquier iniciativa de cambio (Celemi Cayenne)

Las cinco lentes

Stakeholders. Quién gana, quién pierde, quién decide. Mapa explícito de poder e interés. Sin stakeholder mapping, el cambio choca con vetos invisibles.

Hypothesis. Qué hipótesis el cambio prueba. “Si hacemos X, observaremos Y”. Sin hipótesis explícita, el cambio se vuelve articulación política sin criterio de evaluación.

Initiative. Qué iniciativa concreta prueba o niega la hipótesis. Piloto mínimo viable, no roll-out total. Sin piloto, falla cara e innecesaria.

Friction. Dónde aparecerá la inercia organizacional. Puntos de traba previsibles: política, procesos, sistemas, cultura. Mapear antes evita sorpresa de campo.

Time. En qué ventana se evalúa la hipótesis. 90 días, 6 meses, 12 meses. Sin plazo de prueba explícito, la iniciativa entra en loop infinito.

Cómo aplicarlo

Aplica SHIFT Lens como briefing de una página antes de aprobar cualquier iniciativa de cambio organizacional. El sponsor responde a las cinco preguntas en texto. Sponsors que se atascan en Hypothesis o Time suelen ser los que más se quejan de “falta de ejecución” después.

Celemi Cayenne es el complemento experiencial. Los equipos conducen cambio simulado y usan SHIFT Lens en el debrief para nombrar lo que faltó.

Posts relacionados

Cuándo usar

  • Antes de aprobar roll-out de iniciativa de transformación organizacional.
  • Para preparar un sponsor que necesita defender cambio internamente.
  • En retrospectiva post-cambio para identificar lo que faltó en el diseño.

Cuándo NO usar

  • Cambios operacionales menores donde el over-engineering cuesta más que el error.
  • Iniciativas técnicas aisladas sin implicación organizacional.