💰 Tener cuentas no es tener presupuesto
Muchas áreas de tecnología en Colombia pueden mostrar un inventario extenso. Tienen una herramienta para mover datos, otra para almacenarlos, otra para consultarlos y otra para visualizarlos. Cuando alguien pregunta cómo está organizado el flujo de información, la respuesta suele ser ese mismo inventario.
El problema no está en que falten herramientas, sino en que nadie trazó el plano que las conecta.
La arquitectura de datos es el diseño que define cómo se recoge la información en la empresa, cómo se transforma, cómo viaja entre sistemas y cómo llega a las personas que toman decisiones. No es el catálogo de lo que hay. Es el plano que determina para qué sirve cada pieza y cómo se relacionan.
Piense en una persona que maneja sus finanzas con cuatro cuentas bancarias, dos billeteras digitales y una hoja de cálculo actualizada a medias. El dinero está repartido, algunas cuentas tienen movimiento y otras están abiertas sin propósito claro. Tener muchas cuentas no es tener un presupuesto. Sin un plan que diga para qué sirve cada cuenta, el dinero está disperso aunque esté en bancos formales.
Algo similar ocurre en empresas donde conviven un data warehouse, un data lake, varias bases operacionales y herramientas de visualización que cada área escogió por separado. El stack de datos, que son todas las piezas tecnológicas que una organización usa para gestionar su información, existe y es visible. Pero sin un diseño que defina cómo se conectan, quién es responsable de cada dato, cómo viaja la información de un sistema al siguiente y qué reglas aplican en cada punto del flujo, ese stack no es arquitectura.
Las fricciones de esa acumulación se ven en el trabajo diario. El área financiera tiene sus cifras y el área comercial tiene las suyas. Cuando se cruzan en una reunión, los números no coinciden y nadie sabe cuál tabla es la oficial. Se generan reprocesos manuales para conciliar lo que dos herramientas reportan diferente sobre el mismo período.
IBM Think señala que el 94% de los líderes de datos identifican la ausencia de una arquitectura definida como uno de sus principales desafíos.
Primero mapee qué herramientas de datos tiene la empresa, para qué sirve cada una y quién la controla. Luego identifique en qué puntos los datos de distintas fuentes deberían coincidir pero no lo hacen. Después defina una sola fuente oficial para cada dato clave del negocio. Por último asigne a alguien la responsabilidad de mantener ese mapa actualizado, no de seguir sumando herramientas.
¿Cuántas versiones del mismo dato circulan en su empresa antes de que alguien decida cuál es la correcta? 💰
→ Explora el hub de FinOps en Datos →
Versión en inglés
💰 Having Accounts Is Not Having a Budget
Many technology departments in Colombia can show an extensive inventory. They have a tool to move data, another to store it, another to query it, and another to visualize it. When someone asks how the information flow is organized, the answer usually is that same inventory.
The problem is not that tools are missing, but that no one traced the blueprint that connects them.
Data architecture is the design that defines how information is collected in the company, how it's transformed, how it travels between systems, and how it reaches the people who make decisions. It's not the catalog of what there is. It's the blueprint that determines what each piece is for and how they relate.
Think of someone managing their finances with four bank accounts, two digital wallets, and a half-updated spreadsheet. Money is scattered, some accounts have movement and others are open with no clear purpose. Having many accounts is not having a budget. Without a plan saying what each account is for, the money is dispersed even though it's in formal banks.
Something similar happens in companies where a data warehouse, a data lake, multiple operational databases, and visualization tools that each area chose separately coexist. The data stack, which are all the technological pieces an organization uses to manage its information, exists and is visible. But without a design that defines how they connect, who is responsible for each piece of data, how information travels from one system to the next, and what rules apply at each point in the flow, that stack is not architecture.
The friction from that accumulation shows in daily work. The finance department has its numbers and the commercial department has theirs. When they cross paths in a meeting, the numbers don't match and no one knows which table is official. Manual reprocessing is generated to reconcile what two tools report differently about the same period.
IBM Think points out that 94% of data leaders identify the absence of a defined architecture as one of their main challenges.
First map what data tools the company has, what each is for, and who controls it. Then identify at which points data from different sources should match but don't. Then define a single official source for each key business data point. Finally assign someone the responsibility to keep that map updated, not to keep adding tools.
How many versions of the same data circulate in your company before someone decides which is correct? 💰