Analytics is not the point
Nobody wants a dashboard. They want to know whether something needs doing, and then to do it.
That is obvious, and the industry has spent twenty years arranging itself as though it were not. Because getting to a number used to be hard - the extract, the model, the joins, the choice of visual, the argument about the definition - the work of analytics became the subject of analytics. Projects are scoped in dashboards delivered. Teams are measured on reports built. Skilled people spend the day assembling the thing, not on what the thing was for.
That was a reasonable response to a real difficulty. It is no longer a reasonable place to leave the attention, because the difficulty is what is going away: collecting the data and building the view are becoming routine, and routine is what a platform and its agents are for.
What is left is the part that was always the point.
What a BI tool is, structurally
Point it at your systems, model the data, build the dashboards, share them. It is a layer over the places where the work actually happens.
That position is its strength and its problem. It can sit over anything and does not care what produced the data; everything below follows from being outside.
- It is behind. A copy taken on a schedule, or a live query into a source that was not designed to answer it. Either way the number on the screen and the state of the business are two different things, and everyone learns to discount accordingly.
- Its definitions are its own. Revenue in the BI tool is what the modeller said it is. When that disagrees with the operational system, the meeting is about which number is right rather than about what to do.
- It cannot act. It found the deviation. Now somebody opens a messenger, a task tracker and a third system - and most findings do not survive that trip.
- Access is modelled twice. Who may see which rows is decided in the source and again in the BI tool, and the two drift.
What is different here
The analytics is inside the systems, not over them. The CRM, the request queue, the price list and the project portfolio are applications on this platform, and the reporting reads their records where they are. No copy, no sync window, no reconciliation.
One definition of a metric, for everything. What counts as revenue is stated once, in the semantic layer, and read from there by the chart, the table, the Excel export and the AI employee. The argument moves from whose number is right to is that the right definition, and that one gets settled once. See Data engine.
Access is the platform's, not a second model. The platform compiles row-level rules and column masks into the query plan, so a regional director opens the same dashboard as everybody else and sees their own rows. There is no second policy to keep in step.
And a finding can become work without leaving the screen. Comment on it where the data is, mention the person who knows, raise the task, watch its status come back into the same view. That loop is the difference: Inside the work.
It is a real BI, not a reporting screen. Its own engine, its own storage, live or extract execution, the chart types, cross-filtering, calculated fields - see Analytics. Being part of the platform adds to that; it does not stand in for capability.
Who has to be an expert before the first answer
This difference outweighs the feature lists.
Every serious BI tool is, underneath, an instrument for a trained analyst. The power is real, and so is the training: which join, at which cardinality, in which aggregation context; which of forty settings on that visual; why the total does not match when you add that field. Nobody learns it by accident. So "self-service BI" has meant self-service for the analyst for twenty years, and the business still asks, and still waits.
The tool is powerful and the bottleneck is a person. Every organisation running one knows the queue, and the requests that were never made because the queue exists.
Here the assistant does the setting-up. You say what you want to see; it builds it against your model, your definitions and your access. What you need to know is what you want to know.
And it is not autopilot. Everything the assistant touched is an ordinary setting you can open: the sort, the format, the filter, the colour rule, the field roles, the query behind the chart. The depth is all there - the semantic model, calculated fields, the chart definition, the execution mode
- and if you are the analyst who knows what you want, nothing stands between you and it. Go as deep as you would in Power BI or Qlik.
The two together are the point. The floor is lower and the ceiling is not. A person who has never modelled anything gets a correct answer; a person who has modelled for fifteen years is not being held back by a tool that decided they should not need to.
Anyone could always drag a chart. What changes is that being right no longer requires knowing which of the forty checkboxes makes it right.
How this sits with the BI you already run
You do not have to choose between the BI you run and this one.
Nothing gets switched off. The reports your business runs on keep running, against the sources they already read. Nobody has to declare a cutover date, and nobody has to rebuild forty dashboards before anything here is useful.
The same sources, so you can run them side by side. Whatever your Power BI or Qlik reads - the warehouse, the operational databases, the files on the share - this reads too, natively. So the comparison is an experiment instead of an argument: build the same report here, over the same data, and see whether the numbers agree, how long each took to build, and which one you would rather change next quarter.
Parity on the things that decide these projects. Not every feature either product accumulated in twenty years: a semantic model with one shared definition of a metric, row-level security and column masking, live and extract execution over the same model, cross-filtering and drill-down, calculated fields, scheduled refresh, and Excel that opens as a real workbook. That list is what most evaluations come down to, and it is the list to check us against.
And one place people start from. Your teams already open a portal or an app page. A link to the Qlik dashboard sits next to the native one, so "where is the report" has a single answer for however long you run both, which for most companies is a long time.
Dashboards here are not tied to applications. Connect any source - a database, a warehouse, a REST service, files - and build dashboards over it with no application involved. The platform is an ordinary BI over data that has nothing to do with it.
And data from anywhere can be joined. Your operational data here, your warehouse there, a spreadsheet somebody maintains, a service with an API - into one model, reported on together. That is the part a BI tool over five systems is for, and it is here too. See Sources and storage.
Meanwhile every new process arrives with its reporting. Anything built here is queryable the moment it exists, so the dashboards for it are not a follow-on project. That is where the advantage shows, not in a feature comparison.
The decision is yours, per case
Both are true at once: your BI keeps working, and this is a real BI. So you decide on the axes that should decide it:
- Money. Licences per seat for people who open one report a month, against reporting that comes with the platform.
- Quality of the answer. Data read where it lives, one definition of a metric, and access rules that are the platform's and not a second model kept in step, against a copy on a schedule and definitions maintained twice.
- Convenience. Whether the person who finds something can do anything about it without leaving the screen.
Report by report, not as a migration. Some things move because they are better here; some stay because they are better there; and the ones that stay are still a source like any other.
The question that separates them
When your analyst finds the problem on Thursday afternoon, what happens next?
In one architecture the answer involves three other tools and a hope. In the other, the thread is on the number, the task is on the board, the owner has been notified in the channel they read, and the status is back on the same screen by Friday.
Gathering the data and assembling the view were never the value; they were the toll you paid to reach it, and for twenty years the toll was high enough that everybody mistook it for the road. Hand that part to the platform and the agents, and what a company gets back is attention: noticing, deciding and acting.
Next
Company knowledge base - what all of this does to the knowledge your company has about itself.
And the block itself: Analytics - what the built-in stack does, and Analytics inside the work for the part a separate tool structurally cannot do.