Guía OKR de re:Work: lo que finanzas necesita

Este artículo empieza donde empieza tu trabajo real: con el archivo que ya llegó. Cubre cómo limpiar los datos de OKR cuando vienen de otro equipo, la matemática de puntaje que la guía de re:Work evita, y -el problema que transforma una revisión trimestral de decorativa a útil- cómo vincular el scorecard de OKRs a la varianza real en el modelo financiero cuando ese modelo vive en un archivo separado.

Cuando el archivo que te llega no tiene el formato que necesitas

Si eres el analista de FP&A que recibe los puntajes de OKR de otro equipo, la primera tarea no es calcular nada - es convertir lo que llegó en algo que se pueda calcular. Estos son los tres problemas más frecuentes y cómo resolverlos sin rehacer el archivo manualmente cada trimestre.

Problema 1: nombres de departamento inconsistentes entre trimestres

El equipo que actualizó el tracker en Q1 escribió "Ventas". El que lo actualizó en Q2 escribió "ventas" o "Equipo de Ventas". Tus AVERAGEIFS devuelven cero sin ningún mensaje de error visible - el número aparece, simplemente está mal.

La solución es una tabla de normalización en un tab Assumptions con dos columnas: el nombre tal como llega en los datos crudos (columna G) y el nombre canónico que usan tus fórmulas (columna H). Luego agrega una columna auxiliar en el tab de datos que normaliza el nombre antes de que lo lean las fórmulas:

=IFERROR(VLOOKUP(TRIM(LOWER(B2)), Assumptions!$G:$H, 2, 0), TRIM(B2))

TRIM elimina espacios extra, LOWER iguala mayúsculas y minúsculas, y el IFERROR devuelve el nombre original si no encuentra match - lo que te permite identificar los valores nuevos que aún no están en la tabla de normalización en lugar de silenciarlos.

Problema 2: puntajes en formato texto en lugar de número

Alguien escribió "0.6" con formato de texto o pegó los datos desde un PDF exportado. Tus AVERAGEIFS ignoran esas celdas sin avisar, y el promedio resultante parece plausible pero está calculado sobre menos filas de las que debería. Es el tipo de error que no se detecta mirando el número - solo se detecta cuando alguien pregunta en la reunión por qué el puntaje de Operaciones bajó de 0.78 a 0.61 sin que nadie lo reportara.

Detecta el problema con una columna de validación antes de que el dato entre al cálculo:

=IF(ISNUMBER(D2), D2, IFERROR(VALUE(D2), "ERROR: revisar D" & ROW()))

Si la celda ya es número, la pasa directo. Si es texto convertible, lo convierte. Si no es ninguna de las dos, devuelve un mensaje que apunta exactamente a la celda problemática. Usa esta columna como fuente para tus AVERAGEIFS, no la columna original.

Problema 3: KRs que cambiaron de nombre a mitad del período

El equipo de Ventas renombró su key result de "$18.5M ARR nuevo" a "ARR neto nuevo Q2" en la semana 7. Tu comparación trimestral toma los dos nombres como dos KRs distintos y duplica la cuenta - o, si haces un delta, compara entidades que no son la misma.

No hay una fórmula que resuelva esto automáticamente porque requiere un juicio que solo tú puedes hacer: ¿el KR cambió de nombre o cambió de definición? Lo que sí puedes hacer es agregar una columna KR_ID en el tab de datos - un identificador numérico corto que se mantiene estable aunque el nombre del KR cambie - y usar ese ID como clave en las comparaciones entre trimestres en lugar del nombre:

=IFERROR(
  AVERAGEIFS('Q2_OKRs'!D:D,'Q2_OKRs'!F:F,Dept_Rollup!$C2,'Q2_OKRs'!C:C,"Aspirational") -
  AVERAGEIFS('Q1_OKRs'!D:D,'Q1_OKRs'!F:F,Dept_Rollup!$C2,'Q1_OKRs'!C:C,"Aspirational"),
  "-"
)

Donde la columna F es KR_ID. El ID hay que asignarlo una vez al inicio del año - es trabajo manual, pero elimina dos horas de arqueología de fórmulas al final de cada trimestre.

Si el archivo que recibes no tiene los headers que el tracker necesita: agrega una pestaña de transformación entre el archivo crudo y el tab de cálculo. Esa pestaña mapea los headers que llegan a las columnas que tu lógica espera, normaliza nombres de departamento con VLOOKUP contra la tabla de Assumptions, y convierte puntajes en texto a número con VALUE(). Es una pestaña que construyes una vez por fuente de datos, no por trimestre.

La matemática de puntaje que la guía de re:Work evita

Una vez que los datos están limpios, el segundo problema es el cálculo. El insight más útil de la documentación de re:Work es la distinción entre OKRs committed y aspirational:

Promediar puntajes entre un equipo con cuatro OKRs committed y otro con siete aspirational produce un número que parece preciso y no dice nada. La solución es separar dos métricas que no deberían mezclarse:

1. Tasa de cumplimiento de OKRs committed - ¿llegaste a 0.95 o más en los obligatorios?

=COUNTIFS('Q2_OKRs'!C:C,"Committed",'Q2_OKRs'!D:D,">=0.95") / COUNTIF('Q2_OKRs'!C:C,"Committed")

Cualquier resultado por debajo del 80% es una conversación, no una nota al pie del board pack.

2. Puntaje ponderado de OKRs aspirational por departamento

Agregar una columna de peso (escala 1-3) y usar promedio ponderado en lugar de promedio directo es la mejora más impactante que puedes hacerle a cualquier tracker. Un OKR de Ventas con key results para $18.5M ARR nuevo, retención del 92% y "higiene de CRM mejorada" no debería pesar esos tres de forma idéntica:

=SUMPRODUCT(
  ('Q2_OKRs'!B:B=Assumptions!$B$4)*('Q2_OKRs'!C:C="Aspirational")*'Q2_OKRs'!D:D*'Q2_OKRs'!E:E
) /
SUMPRODUCT(
  ('Q2_OKRs'!B:B=Assumptions!$B$4)*('Q2_OKRs'!C:C="Aspirational")*'Q2_OKRs'!E:E
)

Fórmula de array, sin columnas auxiliares. Columna D es puntaje (0.0-1.0), columna E es peso (1-3). La guía de re:Work no la menciona - y es la razón más frecuente por la que un tracker subestima los KRs de ingresos frente a los de proceso.

Muestra ambas métricas en el resumen ejecutivo. No las combines en un solo número para la board.

Estructura del tracker: cinco tabs

La guía de re:Work no prescribe un template. Esta estructura produce algo que puedes poner frente a un CFO sin tener que explicar el archivo:

El tab Financial_Bridge es el que falta en la mayoría de los trackers. Y es el que cambia el tipo de pregunta que hace el CFO en la reunión.

Financial_Bridge: cómo cambia la conversación con el CFO

Sin el bridge, la revisión trimestral tiene este patrón: el CFO abre el deck de OKRs, ve que Ventas tiene un puntaje committed de 0.6, y pregunta "¿y eso cómo se relaciona con la varianza de ingresos que cerramos?" Nadie tiene la respuesta en esa reunión porque son dos archivos distintos que nadie conectó. La conversación se convierte en un ejercicio de reconciliación en vivo que consume veinte minutos y termina con un "lo revisamos y lo mandamos después."

Con el bridge, esa conversación no ocurre. En su lugar ocurre esta:

CFO: El OKR committed de ARR nuevo tiene 0.6 y la varianza versus presupuesto es -40%. ¿El target del OKR estaba alineado con el forecast desde el inicio?

Analista: No - el flag de calibración lo marcó en semana 4. El equipo de Estrategia definió el OKR de ARR en enero con un target de $18.5M, pero el presupuesto de Ventas que firmamos en diciembre era $17.0M. Nunca se cotejaron. El puntaje de 0.6 refleja el target del OKR, no el del presupuesto.

CFO: ¿Y contra presupuesto?

Analista: 65% - varianza de -$5.8M sobre $17.0M.

Esa es la clase de precisión que hace que una revisión trimestral sea útil. El bridge la hace posible porque tiene en una sola fila el OKR score, el KPI financiero real, el presupuesto del período y la varianza, todo referenciando los mismos números del cierre oficial.

Así se ve el tab en la práctica:

La fórmula para traer el puntaje committed del equipo desde Q2_OKRs:

=IFERROR(
  AVERAGEIFS('Q2_OKRs'!D:D,
             'Q2_OKRs'!B:B,Financial_Bridge!A2,
             'Q2_OKRs'!C:C,"Committed"),
  "-"
)

Y el flag de calibración inconsistente - un OKR aspirational con puntaje alto y varianza financiera negativa significativa en el mismo KPI indica que el target del OKR no estaba alineado con el forecast desde enero:

=IF(AND(C2>0.85, H2<-0.15), "⚠ Revisar calibración", "OK")

Cómo jalar los KPIs financieros cuando el modelo vive en un archivo separado

Este es el punto donde la mayoría de los trackers quedan incompletos. Tienes dos opciones:

Opción A: IMPORTRANGE directo

=IMPORTRANGE("URL_del_modelo","P&L!B15")

Funciona para dashboards de lectura pasiva. Para un Financial_Bridge que vas a presentar a un CFO tiene dos problemas operativos: si alguien mueve la celda del ingreso real de B15 a C15 en el modelo de origen, el bridge lee el dato incorrecto sin ningún aviso visible. Y en una reunión con conectividad inestable, IMPORTRANGE que no carga es un riesgo innecesario.

Opción B: tabla de staging con fecha de actualización (el método que funciona para modelos que cambian)

Una tabla FinData en un tab dedicado donde pegas los valores del modelo una vez por período de reporte:

En Financial_Bridge, el real y el presupuesto se jalan con INDEX/MATCH sobre esta tabla usando el KPI_ID como clave:

=IFERROR(
  INDEX(FinData!$C:$D,
        MATCH(Financial_Bridge!$B2, FinData!$A:$A, 0),
        IF(Financial_Bridge!$I$1="Q1", 1, 2)),
  "-"
)

Donde Financial_Bridge!$I$1 contiene el trimestre activo - el mismo patrón de celda de control que usas en Assumptions.

La ventaja de esta separación: cuando el modelo financiero cambia de estructura - que ocurre con cada reorganización de tabs o cada vez que alguien consolida dos líneas del P&L - solo tienes que actualizar FinData, no rastrear referencias rotas en cinco tabs.

Aviso de integridad antes de la reunión

Agrega una celda de validación en la parte superior de Financial_Bridge que compare la fecha de actualización de FinData contra el cierre mensual más reciente:

=IF(
  MAX(FinData!$G:$G) < DATE(YEAR(TODAY()), MONTH(TODAY())-1, 25),
  "⚠ FinData desactualizada - verificar antes de presentar",
  "✓ Datos al " & TEXT(MAX(FinData!$G:$G),"DD/MM/YYYY")
)

Ese aviso aparece antes de que empieces a leer los números - que es el momento en que importa, no después de la reunión.

Cuándo actualizar FinData

La pregunta práctica es cuándo hacerlo. La respuesta más eficiente: el mismo día en que cierras los libros del mes. Si tienes cierre mensual el día 20, FinData se actualiza el 20 o el 21 - no antes, porque los números no son finales, y no una semana después, porque para entonces el bridge ya no refleja el período que acaban de cerrar.

Ese timing resuelve la segunda pregunta que hace cualquier CFO: "¿por qué el puntaje OKR de Ventas no coincide con la varianza que tenemos en el estado de resultados?" La respuesta deja de ser "porque son archivos distintos" y pasa a ser "porque FinData usa los mismos números del cierre que firmamos el 20."

Si esa disciplina no existe en el equipo, el artículo no puede crearla por ti - pero el aviso de integridad sí hace visible cuándo falta, que es el primer paso para que alguien la adopte.

El costo de mantenimiento trimestral

Un tracker construido así funciona. El problema real aparece al inicio de cada trimestre: copiar tabs, actualizar named ranges, reparar referencias rotas cuando alguien renombró un equipo a mitad de año, reconstruir las fórmulas de Dept_Rollup si cambió la estructura organizacional. Son 2-3 horas de arqueología de fórmulas en exactamente el momento en que también estás cerrando libros y preparando la board pack.

ModelMonkey puede reconstruir estas cadenas de AVERAGEIFS entre tabs, detectar desajustes de referencia cuando un nombre de departamento cambia, y armar la lógica de puntaje ponderado desde cero. Los juicios de valor - cómo pesar un OKR committed de headcount contra un target de ingresos de estirón cuando ambos están en el mismo scorecard del CFO - siguen siendo tuyos.

Para el framework completo de fórmulas conectando este tipo de tracker a ruteo de escenarios, la guía OKR Sheets cubre el aspecto estructural con más detalle.

Preguntas frecuentes

¿Cuál es la diferencia práctica entre OKRs committed y aspirational en un scorecard financiero? Los committed tienen target 1.0 y su incumplimiento requiere explicación inmediata - son equivalentes a un número de ingresos comprometido en el forecast o un plan de headcount aprobado por el board. Los aspirational tienen target 0.7; un puntaje de 0.5 no es un fracaso, es señal de que el objetivo fue suficientemente ambicioso. La distinción importa para el puntaje agregado: mezclarlos en un solo promedio elimina toda la señal. En el Financial_Bridge, los OKRs committed son los que se comparan directamente contra varianza de P&L - un committed de ARR con puntaje 0.6 y una varianza de ingresos de -40% son el mismo problema expresado en dos lenguajes distintos.

¿Por qué IMPORTRANGE no es suficiente para conectar el bridge al modelo financiero? IMPORTRANGE funciona bien para dashboards de lectura pasiva, pero en un Financial_Bridge que vas a presentar a un CFO tiene dos problemas operativos. Primero, si la celda que referencias se mueve en el modelo de origen, el bridge lee el dato incorrecto sin ningún aviso visible. Segundo, IMPORTRANGE requiere que el archivo de origen esté en caché; en una reunión con conectividad inestable, eso es un riesgo innecesario. La tabla FinData con pegado manual y fecha de actualización es más trabajo una vez al mes, pero produce un archivo que puedes presentar offline y auditar sin abrir otro archivo.

¿Cómo sé si el puntaje OKR de un equipo es inconsistente con la varianza financiera real? El flag de calibración en Financial_Bridge lo detecta automáticamente: un OKR aspirational con puntaje mayor a 0.85 y una varianza financiera negativa mayor al 15% en el mismo KPI significa que el target del OKR no estaba alineado con el forecast. En la práctica, esto ocurre cuando el equipo de Estrategia define los OKRs en enero sin consultar el modelo financiero - el target del OKR de ARR y el número del presupuesto de Ventas nunca se cotejaron. El bridge hace visible esa inconsistencia antes de que llegue a la board.

¿Qué hago si el archivo de OKRs que recibo no tiene los headers que el tracker necesita? Agrega una pestaña de transformación entre el archivo crudo y el tab de cálculo. Esa pestaña mapea los headers que llegan - sea cual sea su nombre - a las columnas que tu lógica espera, normaliza nombres de departamento con VLOOKUP contra la tabla de Assumptions, y convierte puntajes en texto a número con VALUE(). Es una pestaña que construyes una vez por fuente de datos, no por trimestre.

¿Esta estructura escala para equipos de 50 a 500 personas? Sí, con un ajuste: en organizaciones de más de 200 personas, Dept_Rollup empieza a mezclar departamentos con estructuras OKR muy distintas - Ingeniería con doce KRs técnicos aspirationals y Finanzas con tres KRs committed de reporting. En ese punto conviene agregar una columna de función en Assumptions (Comercial / Operaciones / Soporte / Corporativo) y mostrar en Summary la tasa de committed compliance por función, no solo por departamento. La lógica de fórmula no cambia; solo añades un nivel de agrupación.

¿Cómo vinculo la revisión de OKRs al ciclo de cierre mensual sin duplicar trabajo? Trata la actualización de FinData como parte del checklist de cierre - el mismo día que se firma el P&L del mes, se actualiza la tabla de staging. Eso tiene dos efectos: el bridge siempre usa los números del cierre oficial, no datos preliminares, y la revisión de OKRs se ancla al mismo ritmo del reporting financiero en lugar de operar como un proceso paralelo sin conexión. Para equipos con cierre mensual, eso significa revisar los OKRs en la misma reunión donde se presenta el P&L - no en una reunión separada con un deck de PowerPoint que nadie conecta al modelo.