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.
Punto Clave
Durante cinco años, Finanzas levantaba un ticket cada vez que necesitaba cambiar una tarifa. Ingeniería lo atendía cuando podía. Al migrar el sistema de análisis de ingresos de esta plataforma de seguridad en la nube, sacamos los precios del repositorio, los aplanamos en una tabla, y le dimos a Finanzas una interfaz en Sigma para gestionarlos directamente. En el proceso, encontramos un incremento del 118% sin documentar que había estado corriendo en silencio en producción.
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 del 118% sin documentar, corriendo en silencio en producción desde 2025 — uno de 15 bugs silenciosos que encontramos durante la migración.
Eso es lo que producen cinco años de cambios de precios en código: una historia que nadie puede leer.
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 eran más importantes que cualquier otra parte de 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. Los valores incorrectos no se rechazaban con un mensaje de error: simplemente era imposible ingresarlos.
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.
¿Cuánto tiempo toma implementar autoservicio de precios?
La infraestructura base — dbt seeds, tablas de dimensiones y configuración de Sigma input tables — tomó unas dos semanas en nuestro proyecto. La primera tarifa era editable por Finanzas en tres días de haber empezado. El resto del tiempo se dedicó a expandir la cobertura a todas las líneas de producto y validar paridad con el sistema legacy.
¿Este enfoque funciona sin Sigma?
El patrón es agnóstico a la herramienta. Los input tables de Sigma proveen la interfaz de escritura, pero cualquier herramienta de BI que pueda escribir a una tabla de base de datos funciona. Lo clave es la capa de dbt seeds que valida los inputs antes de que lleguen al modelo de datos. Hemos visto patrones similares con formularios de Streamlit e incluso Google Sheets conectadas a Snowflake vía external tables.
¿Qué pasa cuando hay que cambiar una tarifa de precios?
Finanzas abre Sigma, selecciona la tarifa desde un dropdown (alimentado con datos de dimensiones en vivo — sin entrada de texto libre), ingresa el nuevo valor y guarda. El dbt seed toma el cambio en la siguiente corrida. El cambio queda versionado, auditable y reversible. Sin ticket, sin PR, sin deployment.
¿Cómo se previenen entradas de precios inválidas?
Validación por dropdown alimentada por tablas de dimensiones en vivo. Cada valor seleccionable — región, producto, plan, cuenta — viene de un modelo de dimensión dbt. Si un valor no existe en el pipeline, no aparece en el dropdown. Los typos y entradas inválidas no se rechazan con un error; simplemente no es posible ingresarlos.
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.
Este es el tipo de problema para el que fue construida nuestra práctica de Financial Analytics — sacar la lógica de precios del código y llevarla a infraestructura que Finanzas pueda operar.
La implementación completa — Sigma input tables conectados a dbt seeds con validación por dropdown — está en Analítica de Autoservicio para Equipos de Finanzas.
Si tu equipo de Finanzas todavía levanta tickets para cambiar una tarifa, podemos poner eso en sus manos en semanas. Agenda una llamada.
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.
