Our own platform for reporting and for capturing data. It sits on your business data model, runs on your own infrastructure and works alongside Fabric, Databricks or Power BI. What it is, when it fits and what it costs is all below.
The Customer Reporting Platform is a web environment that does two things. It
shows the numbers and it lets the people who know the content capture data
themselves: budgets, rates, mappings, classifications. The two come apart. You
can take the full platform, or only the data capture side alongside the
reporting you already have.
You sign in at an address carrying your own name, you see your logo and your
colours and you open the same screen on your phone as at your desk.
It does not get in the way of what is already there. If your data runs on
Microsoft Fabric, on Databricks, in Azure or in a data warehouse we built, the
platform connects to it. It replaces no platform and it asks for no migration.
It runs at several clients. A car dealer group tracks sales, stock, days in
stock and margin in it. An investment company consolidates its holdings in it,
with result, balance sheet and cash flow, in English. Every environment looks
different, because the reporting follows the business rather than a template.
The fastest way to judge it is to see it. There is a demo environment with
sample numbers at
crp.demo.ambitionbi.eu. Sign in with
demo / demo and look around yourself, on your laptop and on your
phone. If you would rather go through it with us against your own situation,
ask for a demo.
The platform calculates nothing of its own. It reads from the top layer of a
business data model: the layer that holds what revenue
means, when an order counts as done and which two customer numbers are the
same customer. The values people pick from when capturing data come from that
same layer, so what someone enters lines up with what exists in the model.
What you capture is held in the platform and enters the data model at the next
refresh as a source, the way an ERP or a CRM does. From there it runs through
the same layers as every other source and arrives in the reporting.
So that model layer has to exist. Where a data warehouse is already in place,
we look per component at what stays and what has to be added. Usually the
definition layer turns out to be the missing piece: a warehouse built the way
the systems store things can run for years and still not answer the question of
what revenue is. What you have and what is needed comes out of the
Business Data Scan, with the amount attached.
Where that model runs is your call. Microsoft Fabric, Databricks, Azure SQL or
the data warehouse we build: the platform connects to it.
If you are already on Power BI, Fabric or Databricks, the reporting stays where
it is. What is missing is the place where people capture data that lives in no
source system.
A budget. An allocation key. The mapping from ledger account to reporting line.
The classification that decides which heading an article falls under. Power BI,
Fabric and Databricks read data; they capture nothing themselves. The answer
inside Microsoft is a separate application on Dataverse, with its own build and
its own licences beside it.
So in practice that data sits in Excel, goes round by email and nobody is sure
which version is the latest. Here it goes into a screen that knows the agreed
definitions. From there it enters the data model as a source, feeding the
reporting you already have.
This stays a small component. It concerns the handful of people who maintain
the data, not everyone who reads the reporting. It does require the definition
layer underneath to hold up. Where it does not, that is the first piece of
work and it is in the scan.
If you want the reporting here as well, everything below sits in the same
environment, with per-person control over who sees and changes what. Reasons
clients choose this:
If you are on Microsoft Fabric at F64 capacity or above, your readers already
need no separate licence. The cost argument falls away. What is left is the
rest: the data capture, the view on every phone and an environment under your
own name. If those do not outweigh the reporting you already have, do not do
it.
If you have ten or twenty readers who all hold a licence already, Power BI is
simpler and cheaper. The portal is not the conversation then. The data capture
side may still be worth having.
In Excel anything goes. A category that does not exist, a rate in the wrong
column, a file from last month: the sheet accepts it and says nothing. Two
weeks later a report is wrong and somebody spends an afternoon working out why.
In this platform's data management it works like this:
The platform runs on your own infrastructure. On a server that belongs to you,
or in your own cloud environment, Azure for instance. Never with us.
That makes the questions where does our data sit, what happens if the supplier
disappears and can we ever leave answerable from the setup itself. The database
is yours. Your IT security policy applies. Your own arrangements for securing
and restoring data cover this environment the way they cover the rest of your
systems.
That it can be moved sits in the way it is built. The code carries no
addresses, passwords or settings belonging to one environment; those are held
separately, per environment. On a move, the data warehouse is rebuilt from the
source systems and then placed next to the old environment on counts and on
amounts, so it is demonstrable that the same thing comes out. The procedure for
that is written down and travels with it.
If NIS2 or your accountant brings questions about suppliers, this is the
simplest shape to answer them in: we supply the application, you manage the
environment it runs on.
Beyond sign-in, you can open the platform only to the networks you know. To the
rest of the internet it is then invisible.
The engagement costs the same. A business data model with reporting in this
platform is the same work as a business data model with reporting in Power BI,
and falls in the same size band. What an engagement costs
Where only the data capture side goes alongside a data platform already in
place, the amount depends on what that environment can already carry. Where the
data model connects, the work is small. Where the definition layer underneath
is missing, that work is part of it. What it comes to in your case is settled
at the end of the Business Data Scan.
External costs do differ. With Power BI you pay user licences, currently around
€12 per user per month at Microsoft. Here you pay for the server or the cloud
environment it runs on. That stands in your name. Those costs do not climb
with the number of readers.
Look around yourself at crp.demo.ambitionbi.eu with demo / demo, or tell us who needs to look at it and at what. We will show you the platform with numbers in it that resemble yours.
We bring the numbers from all your systems together in one data model. Your reporting adds up and everyone works from the same figures.
