Insights / Ratio · Vigilia
Analytics and BI without the big-data theater
Most companies do not have big data. They have messy data and three questions they need answered every morning. Here is what analytics and business intelligence actually are at that scale, and when the heavy tools earn their keep.
Three words that get mixed up
Analytics is the computation: margin after a cost floor, exchange difference kept apart from profit, days of stock, revenue re-dated to the month the work happened. It is rules, applied to the record, every time, the same way.
Business intelligence is the delivery: the screen the owner opens at 8 a.m., the statement the accountant receives on the first of the month, the alert when a price expires. BI is analytics with a schedule and an audience.
Big data is a volume problem: billions of events, streams, models trained on history. Real, valuable, and almost never the situation of a company with fifty customers and a thousand orders a month. Buying big-data tools for that is theater. It costs money and it delays the two things above.
Where the value actually is
In our experience the value of analytics for an operating company comes from three unglamorous places.
- Writing the rules down. Every business already computes margin, commissions, FX and stock in someone's head or in a cell formula. When those rules become code with tests, they stop drifting between people and between months. The first week of any analytics project is usually spent discovering that two people compute the same number differently.
- Re-dating. Accounting systems record when an invoice was issued or paid. Owners think in terms of when the work happened, when the goods left, when the cost was incurred. Moving the same facts onto the dates the business lives by is where "the P&L does not match reality" gets solved.
- Freshness. A number that is right but three days old is a different product from a number that is right now. Pricing, stock and cash want minutes. Statements want days. Knowing which is which decides the architecture.
The layering that works
Three layers, each reading the one below it, none of them clever.
- Record
- One governed database. Customers, orders, payments, prices, accounts. Fed by data entry that a person confirms. This is Tabula's job, or your ERP's, if it is disciplined.
- Rules
- Code that computes the derived numbers from the record and writes the results back, versioned and tested. Not a spreadsheet, not a prompt. This is Ratio.
- Screens
- Dashboards and statements that only read. One view for the owner, one per team. Refreshed at the pace the data changes. This is Vigilia, or Power BI, Looker Studio or Metabase reading the same tables.
The point of the separation is that a dashboard never computes anything. If two screens disagree, the bug is in one place. If the owner asks the AI agent for the margin, it reads the same figure the screen shows. There is exactly one version of every number.
When the heavy tools do make sense
Event volumes in the hundreds of millions (clickstreams, sensors, ad impressions). Machine learning on years of history where the pattern is not a rule anyone can write. Dozens of analysts querying at once. A group of companies consolidating many systems. In those cases a warehouse, a stream processor and a proper semantic layer are the right tools, and we build with them.
The tell is simple: if you can describe the number you want as a sentence, you need rules, not a data lake. "Margin per order after the supplier's cost and a 4% floor" is a rule. "Which customers are about to churn" might be a model. Start with the rules. They are cheaper, they are auditable, and they are usually the whole problem.
What to measure first
Cash by account, today. Receivables by customer and age. Margin by product or order, with the rule that produced it visible. Stock or capacity in days. Whatever the owner already asks for on Monday morning, in whatever form they currently get it. Everything else can wait until those four are trusted.