Cuando Finanzas Tiene que Pedirle Permiso a Ingeniería para Cambiar un Precio, Algo Salió Mal
Cómo sacamos los precios del código y los pusimos en manos de Finanzas — sin tickets, sin PRs, sin esperas.
Cuando Finanzas Tiene que Pedirle Permiso a Ingeniería para Cambiar un Precio, Algo Salió Mal
La historia de cómo sacamos los precios del código y los pusimos en manos de quienes los deben gestionar.
Cada trimestre, el equipo de Finanzas necesitaba actualizar una tarifa.
Cada trimestre, levantaban un ticket con Ingeniería.
Cada trimestre, Ingeniería lo atendía cuando podía.
Esta es la historia de cómo eso dejó de pasar — y lo que encontramos antes de que lo hiciera.
Nos contrataron para migrar el sistema de análisis de ingresos de una plataforma de seguridad en la nube a una arquitectura moderna. A las pocas semanas, empezamos a desmontarlo para entender cómo funcionaban realmente los precios.
Los precios habían vivido dentro del repositorio de Ingeniería desde 2021. No en una hoja de cálculo. No en una tabla que alguien pudiera abrir. En código — archivos con tarifas escritas como números literales, gestionados por ingenieros, desplegados como software.
Cinco años de cambios de precios se habían acumulado ahí. Cada uno era una revisión, un merge, un despliegue a producción. Finanzas levantaba tickets. Ingeniería los resolvía cuando podía.
Finanzas había estado pidiendo permiso para cambiar sus propios números durante cinco años.
Cuando sacamos todas esas tarifas del código y las pusimos sobre la mesa, algo se hizo visible que antes no lo era.
Un incremento de precio del 118% sin ninguna documentación. Había estado corriendo en producción, aplicado a cálculos de ingresos reales, desde 2025. Nadie en el equipo actual sabía que estaba ahí.
Lo encontramos porque nuestra validación mostraba una brecha — rastreamos hacia atrás a través de los datos hasta encontrar una tarifa aproximadamente el doble de lo que cualquiera esperaba. Nunca había sido escrita en ningún lado. Simplemente existía, en silencio, aplicándose a cada factura.
Eso es lo que producen cinco años de cambios de precios en código: una historia que nadie puede leer.
Lo que seguíamos repitiendo era esto: los precios son datos. Se estaban almacenando como código.
Los datos deben ser editables por las personas que los gestionan. El código debe ser manejado por ingenieros. Cuando almacenas los precios como código, Finanzas pierde la capacidad de gestionar sus propios números — no porque no sean de confianza, sino porque el sistema nunca fue construido para que lo tocaran.
Los ingenieros se convierten en guardianes involuntarios. Finanzas se vuelve dependiente del ciclo de sprint de otra persona para hacer trabajo que es fundamentalmente suyo.
Cómo saber si tienes este problema
El patrón no es raro. Estas son las señales:
- Finanzas abre un ticket para cambiar una sola tarifa. Incluso una pequeña. Incluso una que ya han cambiado antes.
- Los precios viven en archivos
.sqlo macros Jinja — no en una tabla, no en una hoja de cálculo, sino en código. - La única forma de entender el historial de tarifas es leer
git blame. - Hay un número en producción que nadie del equipo actual puede explicar.
- Un cambio de precio requiere un PR, una revisión y un despliegue antes de estar activo.
Si dos o tres de esas señales se cumplen, es casi seguro que tus precios están en el lugar equivocado.
El primer paso fue mover cada tarifa a una tabla.
Una fila por tarifa. Una columna para la fecha de vigencia. Todo el historial que había estado disperso en años de cambios de código era de repente visible en un solo lugar — cinco años de cambios de tarifas, en orden, legible por cualquiera.
Agregar una nueva tarifa significaba agregar una fila. Las tarifas anteriores quedaban en su lugar. El sistema siempre sabía qué tarifa aplicaba en cualquier fecha. Sin coordinación requerida, sin riesgo de perder el historial.
Finanzas ya podía editar la tabla. Pero todavía necesitaban acceso a la base de datos para hacerlo — lo que significaba que todavía necesitaban a Ingeniería.
Entonces dimos un paso más.
Movimos las tablas de precios a Sigma, la herramienta de dashboards que Finanzas ya usaba todos los días. Actualizar una tarifa significaba abrir una interfaz conocida, seleccionar de un dropdown, escribir un número, guardar. El mismo sistema que usaban para los reportes. El mismo login. Nada nuevo que aprender.
Los dropdowns importaban más que la interfaz. Sin ellos, un error de tipeo en el nombre de un producto o en el código de una región rompería los cálculos de ingresos en silencio — resultados incorrectos, sin error, sin advertencia. Los dropdowns restringían cada campo a valores válidos. Finanzas solo podía ingresar cosas que el modelo ya entendía.
Eso es lo que hace que el autoservicio sea genuinamente seguro: no confiar en que se ingresarán los valores correctos, sino hacer que los valores incorrectos sean imposibles de ingresar.
El stack era Snowflake para el data warehouse, dbt para la capa de transformación, y Sigma para la interfaz de Finanzas — pero el patrón funciona en cualquier lugar donde Finanzas tenga una herramienta que pueda escribir directamente en tu warehouse.
La primera vez que Finanzas actualizó una tarifa por su cuenta, tardó tres minutos.
Sin ticket. Sin esperas. Sin conversación sobre prioridades de sprint.
Seleccionaron el producto. Ingresaron la tarifa. Definieron la fecha de vigencia. Guardaron. Corrieron la query de validación de la guía que les dejamos. Cerraron el tab.
Cuándo no aplica este patrón
No todo cambio de precios pertenece a una tabla. La distinción que importa: ¿es una actualización de tarifa, o cambia cómo el modelo calcula?
Las actualizaciones de tarifa — un precio nuevo, un multiplicador modificado, un descuento revisado — son datos. Pertenecen a una tabla que Finanzas puede editar. La lógica del modelo no cambia; solo cambian los inputs.
Los cambios estructurales son distintos. Una nueva línea de producto que introduce una dimensión de precios que antes no existía. Un nuevo modelo de facturación que requiere nueva lógica de transformación. Una expansión regional que cambia cómo se calculan los niveles, no solo cuáles son las tarifas. Esos siguen siendo de Ingeniería — porque no estás actualizando un valor, estás cambiando cómo funciona el sistema.
La prueba: si una entrada incorrecta en la tabla produciría un número malo pero el modelo seguiría funcionando, eso es un dato. Si una entrada incorrecta podría romper el modelo o producir resultados sin sentido de forma silenciosa, eso es territorio de Ingeniería.
La mayoría de los cambios de precios del día a día pasan la primera prueba. Los que no la pasan serán obvios.
Preguntas frecuentes
¿Necesito Sigma específicamente, o funciona cualquier herramienta de BI?
Necesitas una herramienta de BI que pueda escribir de vuelta en tu warehouse — no solo leer de él. Sigma tiene esto integrado para Snowflake. Otras herramientas en este espacio (Omni, algunas configuraciones de Looker) también lo soportan. La herramienta específica importa menos que la capacidad: Finanzas necesita poder guardar un valor directamente en una tabla que tus modelos dbt puedan leer. Si tu herramienta de BI actual no puede hacer eso, necesitarás una herramienta diferente o una capa de formularios ligera sobre tu warehouse.
¿Qué pasa con las trazas de auditoría? ¿Cómo sabemos quién cambió qué?
Aquí es donde el patrón temporal da sus frutos. Como cada fila de tarifa tiene una fecha de vigencia en lugar de sobrescribir el valor anterior, el historial completo siempre está en la tabla. Sabes cada tarifa que estuvo activa y cuándo. Para efectos de cumplimiento, puedes añadir registro de auditoría a nivel de warehouse encima — el historial de consultas de Snowflake, por ejemplo, captura quién ejecutó qué escritura y en qué momento. El resultado es más trazable que el código: git blame requiere leer diffs; una tabla con fechas de vigencia es solo una consulta.
¿Qué pasa si Finanzas comete un error?
De la misma forma en que se detecta cualquier error de datos: validación. Creamos una consulta de validación que Finanzas ejecuta después de cada actualización — verifica que la nueva tarifa esté dentro de los rangos esperados, que los códigos de producto y región sean válidos, y que la fecha de vigencia no entre en conflicto con filas existentes. Los desplegables eliminan la clase de error más común (claves foráneas inválidas). La consulta de validación detecta cualquier otra cosa antes de que llegue a los reportes de producción. Ningún sistema elimina el error humano por completo; este hace que los errores sean visibles de inmediato, en lugar de dejarlos correr silenciosamente durante años.
Antes de construir algo así, hazte una pregunta: ¿quién debería ser dueño de este dato cuando ya no estés?
Si la respuesta es un equipo de negocio — Finanzas, RevOps, Sales Ops — debe vivir en algún lugar que puedan editar sin pedir ayuda. Si estás recibiendo tickets de Ingeniería para cambios de valores rutinarios, el dato está en el lugar equivocado.
No todo le corresponde a Finanzas. Las nuevas líneas de producto, las nuevas estructuras de precios, las nuevas regiones — esas cambian la forma en que el modelo calcula. Esas siguen siendo de Ingeniería.
Pero, ¿un incremento de tarifa? ¿Un ajuste de descuento? ¿Un nuevo multiplicador regional? Eso es un dato. Debe vivir en una tabla, en manos de quienes lo decidieron.
Finanzas nos miró como si hubiéramos hecho un milagro. No esperaban poder actualizar los precios por su cuenta. Nadie les había dicho que era posible.
No hicimos ningún milagro. Solo dejamos de guardar sus datos en nuestro código.
Clarivant construye infraestructura de analytics que los equipos de negocio pueden operar de verdad. clarivant.ai
Temas
Arturo Cárdenas
Fundador y Chief Data Analytics & AI Officer
Arturo es un consultor senior en analítica e IA que ayuda a empresas medianas y grandes a eliminar el caos de datos para desbloquear claridad, velocidad y ROI medible.
